Computer < applications in terminology ? Data categories

From: Syd Bauman
Date: Sat, 16 Apr 2005 03:26:00 -0400

James --
First off, thank you for doing this. This will make the use of the
CVS version of the source ODDs much more accessible to lots of
people. Overall I think it looks very good. Specific nit-picks are
inserted left-aligned below, interspersed with the XML source which
is indented by 6 or more columns, with some general comments at the
end. Hope this is readable and helpful.

This level of

is unnecessary. All of its children could be the
direct children of instead.
README for TEI P5 CVS
I'm concerned that the title and the content don't match. The content
gives lots of (very good) information on using the Makefile on a
GNU/Linux or other unixy system. But it doesn't say anything about
* what and how to get from CVS
* where to put it
* how to update it
* what all those files are for
* how to submit suggestions or patches
* other things I may not have thought of
I'm not suggesting you need to write all this ever, let alone before
the file is released. I think your "keep it simple to start" policy
is fine. But I am suggesting that either the title should be less
ambitious or specific placeholder

s should be inserted to be
filled in later.

This file contains some basic information about the
files included in the P5 module, and what can be
Is it called a "module" (by Sourceforge)?
generated from them. The Source/ folder is by far the
s/folder/directory/, no? (If so, everywhere.)
most important. This contains the source files for the
P5 version of the TEI Guidelines and Schema. These are
s/Schema/associated schemas/
organised in folders by chapter of the Guidelines, and
each contain one or more file in ODD (One Document Does
it all) format. This is an XML format developed by the
TEI for creating guidelines and schema.

Last sentence: "This is a TEI format specifically intended for writing
Guidelines about encoding, from which schemas and reference
documentation can be automatically extracted." or some such.

I think using type= of

is probably a good idea. In P3 they were
required, but because an SGML defaulting mechanism not available in P4
was used, the content model was loosened in P4 to make them optional.
Indeed there are cases (and the P3 Guidelines themselves were a
perfect example) where type= didn't serve a useful purpose, so there's
a pretty strong argument for leaving it optional. But nonetheless, I
personally think it can often be quite helpful, at least for the
humans.
Generating Other Formats

A Makefile is provided to generate HTML versions of
the guidelines, DTDs and schemas, amongst various
"... of the guidelines, schemas, and DTDs, amongst various ..."
other possibilities. There are a number of
variables that one can change at the beginning of
the Makefile. These are:

TEISERVER
This is the eXist server storing TEI files
used by the 'fasicule' target. You must have
Shouldn't that be fasicule or
some such? :-)
internet access to this target. By default this
"either internet access or a locally served TEI eXist database to use
this"
is >http://www.tei-c.org.uk/Query/

PREFIX
This is the default location under which you
wish to install files locally if you use the
'install' target. By default this is
/usr/local/tei
We (TEI internal documentation writers) really need to develop and
document a convention for encoding all sorts of things, among them
file paths. I'm thinking at the moment. Any
thoughts?
XSL
This is the location of the XSLT stylesheets
required for the transformation of ODD files.
By default this is a URL pointing to target="http://www.tei-c.org/stylesheet"
>http://www.tei-c.org/stylesheet
however, if you want to use a local copy of the
stylesheets you may wish to change this.
Possible options include the folder for the CVS
copy of the stylesheets, or
/usr/share/xml/tei/stylesheet which is the
location used by the debian package for TEI
s/debian/Debian/

stylesheets.

The makefile has a number of requirements, these
include internet access (or a local copy of the
stylesheets), and up-to-date versions of the perl,
jing, trang, xmllint and xsltproc programs. If you
do not have these installed then many of the make
targets will not work. Fortunately, there is a
target which will check to make sure you have these
installed: 'make check'.

Perhaps make check ?
Maybe make check ?
In truth (as I say above), we need a general purpose documentation
schema, and perhaps it should contain special purpose elements for
things like file names, file paths, URLs (that are not references),
system commands, error messages, command output, etc.
I think I'd encode all the following as triplets:

Makefile Targets

Check
Usage: make check

This target checks to see whether you have perl, jing,
trang, xmllint and xsltproc installed.

Makefile Targets
Check
Usage: make check
This target checks to see whether you
have perl, jing, trang, xmllint and xsltproc
Missing the Oxford comma after "xmllint".
installed.
Default
Usage: make
This is the default target and creates
the TEI P5 DTDs, Schemas and HTML version of
"the TEI P5 schemas in RelaxNG & DTD and the HTML version of"
the Guidelines.
Convert
I had not even taken notice of this one, let alone ever used it. :-)
Usage: make convert
This target creates the TEI P5 DTDs and
Schemas.
As with "default".
DTDs
Usage: make dtds
This target creates DTDs for TEI P5 in
the DTD/ folder.
Schemas
Usage: make schemas
This target creates RelaxNG Schemas for
TEI P5 in the Schema/ folder.
HTML
Usage: make html
This target creates an HTML version of
the TEI Guidelines in the Guidelines/ folder.
XML
The output of this target (Guidelines.xml) as intended to be the
Guidelines expressed in TEI Lite. Thus perhaps this label should be
"TEI Lite" or some such.
Usage: make xml
This target creates a TEI P5 XML version
s/TEI P5 XML/TEI Lite (P5)/
of the Guidelines as Guidelines.xml in the
current (P5) folder.
"current directory (i.e., P5/)."
Split
Usage: make split
This target creates a set of TEI P5 XML
files that are a version of the Guidelines
split into chapters, in the split/ folder.
The output of this target is also XML, but is not TEI Lite (as with
the 'xml' target), but rather still ODD. The important thing here
(IMHO) is that the resulting files have had entity references
resolved.
exist
Usage: make exist
This target updates a locally running
copy of the eXist XML database with the TEI
files. The files are added via the SOAP
interface and the database is assumed to be
running at the target="http://localhost:8080/"
>http://localhost:8080/ URL.
Should this really be a ref with a target=? What happens if one clicks
on it?
Clean
Usage: make clean
This target removes most of the files
created by the other targets.
Install
Usage: make install
This target installs a separate local
copy of the DTDs, Schema, and HTML version of
the guidelines under the file path given by the
PREFIX variable.
May want to add "(See , above.)", and then put an
id=PFX on the entry for that variable.

I gather you've ignored the dist, valid, validate, test, pdf, and
fasicule targets on purpose. Probably reasonable. But what about
"html-web" target? Do you know the difference between it and "html"?
(I don't -- I know it's the same except for slightly different
stylesheets, but even having glanced at the stylesheets and scanned
the results, I don't know what or why is really different. I suspect
the -web version is intended to have a useful navigation bar down the
left-hand column.)
I think the order of targets might use some thought. I'm inclined to
suggest that the more complex targets that call others be listed
later, so they can just refer to the previous ones. E.g. that 'make
convert' is the same as 'make dtds; make schemas'. Either that or just
list 'em in alphabetical order. (Then what do you do with "default",
or my suggestion that the label for 'xml' be "Lite"? Hmmm...)
Again, I'm really glad you're doing this. It's a Good Thing(tm :-).
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
Received on Sat Apr 16 2005 - 03:26:05 EDT

From James.Cummings at computing-services.oxford.ac.uk Sat Apr 16 18:57:31 2005 From: James.Cummings at computing-services.oxford.ac.uk (James Cummings) Date: Sat, 16 Apr 2005 23:57:31 +0100 Subject: [tei-council] CVS README In-Reply-To: <16992.48648.567828.308516@emt.wwp.brown.edu> Message-ID: <4261985B.1020401@computing-services.oxford.ac.uk>

From: James Cummings
Date: Sat, 16 Apr 2005 23:57:31 +0100

Syd Bauman wrote:
>

> This level of

is unnecessary. All of its children could be the
> direct children of instead.
I've noticed I've often a tendency towards unnecessarily overnesting.
> README for TEI P5 CVS
> I'm concerned that the title and the content don't match.
What about "CVS P5 Module README File" ?
The content
> gives lots of (very good) information on using the Makefile on a
> GNU/Linux or other unixy system. But it doesn't say anything about
> * what and how to get from CVS
> * where to put it
> * how to update it
In my view, if they are reading this file, then they've already
got the P5 Module from CVS and don't need instructions for getting
it. The proper place for this information, I'd think is the TEI
CVS page http://sourceforge.net/cvs/?group_id=106328 though this
also links to the sourceforge Basic Introduction to CVS I'd prefer
not duplicate the information that the better qualified provide.
> * what all those files are for
> * how to submit suggestions or patches
These two I agree with, but should either go in a README for
each CVS module or somehow in an overall one. (But since
you have to check out each module individually, an overall
one is impossible and I'm assuming the TEI CVS page
http://sourceforge.net/cvs/?group_id=106328 I suppose.
> Is it called a "module" (by Sourceforge)?
Yup. I think to distinguish from the stable releases you
can download which they call 'packages'.
> generated from them. The Source/ folder is by far the
> s/folder/directory/, no? (If so, everywhere.)
Strangely I originally wrote directory and changed it to folder for
some unknown reason.
> P5 version of the TEI Guidelines and Schema. These are
> s/Schema/associated schemas/
Done.
> Last sentence: "This is a TEI format specifically intended for writing
> Guidelines about encoding, from which schemas and reference
> documentation can be automatically extracted." or some such.
Done.
>

> I think using type= of

is probably a good idea. In P3 they were
> required, but because an SGML defaulting mechanism not available in P4
> was used, the content model was loosened in P4 to make them optional.
> Indeed there are cases (and the P3 Guidelines themselves were a
> perfect example) where type= didn't serve a useful purpose, so there's
> a pretty strong argument for leaving it optional. But nonetheless, I
> personally think it can often be quite helpful, at least for the
> humans.
As someone who often overuses @type I'm happy to do so -- but what
type are these divisions?
> "... of the guidelines, schemas, and DTDs, amongst various ..."
Done.
> Shouldn't that be fasicule or
> some such? :-)
Done.
> "either internet access or a locally served TEI eXist database to use
> this"
Done.
> /usr/local/tei
> We (TEI internal documentation writers) really need to develop and
> document a convention for encoding all sorts of things, among them
> file paths. I'm thinking at the moment. Any
> thoughts?
I've done that for now; perhaps

 ?



>               copy of the stylesheets, or


>               /usr/share/xml/tei/stylesheet which is the



and here



>               location used by the debian package for TEI


> s/debian/Debian/



Done.



>             installed: 'make check'.


> Perhaps make check ? 


> Maybe make check   ?



Used  for now.



> I think I'd encode all the following as triplets:


>   


>    Check


>    Usage: make check


>    This target checks to see whether you have perl, jing,


>    trang, xmllint and xsltproc installed.



>   


Done.


>  



> Missing the Oxford comma after "xmllint".


Done.



> "the TEI P5 schemas in RelaxNG & DTD and the HTML version of"


Done.



>             Convert


> I had not even taken notice of this one, let alone ever used it. :-)



Since it was a simple one I included it.



> As with "default".


Done.



>             XML


> The output of this target (Guidelines.xml) as intended to be the


> Guidelines expressed in TEI Lite. Thus perhaps this label should be


> "TEI Lite" or some such.


That means to me that this would produce a version of the TEI Lite 


DTD/Schema/Guidelines not that it produces P5 Guidelines in Lite.


Not sure what it should be then.



> s/TEI P5 XML/TEI Lite (P5)/


Done.


> "current directory (i.e., P5/)."


Done.


> The output of this target is also XML, but is not TEI Lite (as with


> the 'xml' target), but rather still ODD. The important thing here


> (IMHO) is that the resulting files have had entity references


> resolved.


Done.



>               running at the 

>                 target="http://localhost:8080/"


>                 >http://localhost:8080/ URL.


> Should this really be a ref with a target=? What happens if one clicks


> on it?



It takes you to the Jetty server (if you've not embedded eXist into 


Cocoon and are using the default).  I could change this to


http://localhost:8080/exist/ which would point to the local


exist homepage.  In fact, But really this target uses 


http://localhost:8080/cocoon/services/Admin?WSDL so assumes


use of sebastian's packages.  Perhaps I should remove reference to it?



> May want to add "(See , above.)", and then put an


> id=PFX on the entry for that variable.



Done.


> I gather you've ignored the dist, valid, validate, test, pdf, and


> fasicule targets on purpose. Probably reasonable. But what about


> "html-web" target? Do you know the difference between it and "html"?


> (I don't -- I know it's the same except for slightly different


> stylesheets, but even having glanced at the stylesheets and scanned


> the results, I don't know what or why is really different. I suspect


> the -web version is intended to have a useful navigation bar down the


> left-hand column.)



Yes, I ignored those because I thought it less likely that people would


need them (or those that would won't need help). Test, in specific, uses


software which 'make check' doesn't test for (and which it turns out I


didn't have installed).



> I think the order of targets might use some thought. I'm inclined to


> suggest that the more complex targets that call others be listed


> later, so they can just refer to the previous ones. E.g. that 'make


> convert' is the same as 'make dtds; make schemas'. Either that or just


> list 'em in alphabetical order. (Then what do you do with "default",


> or my suggestion that the label for 'xml' be "Lite"? Hmmm...)



Yeah, I thought about that kind of thing as well -- but perhaps it


should follow whatever order is in the Makefile (or that changed


to such an ordered principle...)  My order was based mostly on my


perception of frequency of use.



-James


_______________________________________________


tei-council mailing list


tei-council_at_lists.village.Virginia.EDU


http://lists.village.Virginia.EDU/mailman/listinfo/tei-council


Received on Sat Apr 16 2005 - 18:57:24 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Apr 21 08:05:12 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 21 Apr 2005 14:05:12 +0200
Subject: [tei-council] Agenda items, documents for Paris meeting
Message-ID: 

From: Christian Wittern 

Date: Thu, 21 Apr 2005 14:05:12 +0200

Dear Council meeting,

As you know, the TEI Technical Council will hold a two-day meeting

starting a week from now on April 28th 1400 local time in Paris.

In preparation for that meeting, I would like to ask you to send me

any items that needs to be put on the agenda for discussion.  Also,

any documents the Council is expected to review should be available as

soon as possible -- experience shows that having time to think over it

can make a huge difference.

Please look also at the action items in

http://www.tei-c.org.uk/Council/tcm16.xml?style=printable 

and act as necessary.

Looking forward to seeing all of you 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 Thu Apr 21 2005 - 08:05:18 EDT

From jawalsh at indiana.edu  Fri Apr 22 09:36:59 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Fri, 22 Apr 2005 08:36:59 -0500
Subject: [tei-council] Update on revisions to Chapter 24, The Independent Header (SH)
Message-ID: 

From: John A. Walsh 

Date: Fri, 22 Apr 2005 08:36:59 -0500

Hi all,

Below is an update on work on Ch. 24, along with the spreadsheet 

discussed in our last conference call.  I sent this out last night, but 

I think it got blocked because I included attachments.  The previously 

attached documents are now available as links at:

http://www.dlib.indiana.edu/~jawalsh/tmp/council/ch24Update.xml (this 

update in TEI format)

http://www.dlib.indiana.edu/~jawalsh/tmp/council/teiHeaderMappings.sxc 

(Open Office format)

http://www.dlib.indiana.edu/~jawalsh/tmp/council/teiHeaderMappings.xls 

(Excel format)

John

Update on revisions to Chapter 24, The Independent Header (SH)

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

Natasha Smith and I have been working to revise and update Chapter

24 on the Independent Header. We were told by the editors that, since

there is no evidence that independent headers are actually used by the

TEI community, we should remove references to independent headers but

retain and update the still valuable information regarding mapping from

the TEI Header to other metadata formats, such as MARC. The eventual

goal is to eliminate this chapter and incorporate the metadata mapping

information into Chapter 5, "The TEI Header."

We have completed the task of editing the chapter to remove

references to independent headers, and we have begun the work of

revising and updating the metadata mapping sections. To facilitate the

process of updating the metadata mapping information, we have created a

spreadsheet of the TEI Header elements, in their various hierarchical

contexts. This spreadsheet will be used by library catalogers and

metadata experts to indicate mappings to other metadata standards, such

as MARC and Dublin Core. The completed spreadsheet could also be used to

generate a reference table for the P5 Guidelines. The spreadsheet is

pretty comprehensive but does not yet include the msDescription

elements. Also note that the spreadsheet refers to P4 documentation

rather than P5. I feel that the P4 documentation is, at this point,

easier to use and fuller with examples and so will be more useful to the

catalogers and metadata experts, who are not necessarily TEI experts. We

have recruited some catalogers and metadata experts to help with this

process, but we haven't yet given them the spreadsheet and set them to

work.

Next Steps:

    1. Give catalogers the spreadsheet to document mappings from TEI

       Header to MARC and Dublin Core.

    2. Draft a section that discusses use of namespaces to incorporate

       other metadata standards into TEI.

    3. Assemble all the parts and revise for improved organization and 

style.

    4. Seek feedback from TEI in Libraries group and wider TEI community.

The spreadsheet is attached in Open Office and Excel format.

| John A. Walsh, Associate Director for Projects and Services

| Digital Library Program / Indiana University Libraries

| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405

| Voice:812-855-8758 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 Fri Apr 22 2005 - 09:37:03 EDT

From Julia_Flanders at Brown.edu  Fri Apr 22 14:52:39 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Fri, 22 Apr 2005 14:52:39 -0400
Subject: [tei-council] Agenda items, documents for Paris meeting
In-Reply-To: 
Message-ID: 

From: Julia Flanders 

Date: Fri, 22 Apr 2005 14:52:39 -0400

I was asked to circulate a summary of the PB workgroup's results to 

date. Terry's report which he put together for the November 

conference call is actually quite complete and contains examples 

which are now visible (for a while they were malfunctioning); see:

http://www.tei-c.org/Activities/PB/pbr01.html

In Safari, you'll need to view source to see the examples. Firefox 

shows them properly.

The other action item to me concerned the TEI wiki. I'm happy to 

report that Sebastian, Lou, and James Cummings (and perhaps unseen 

others at Oxford) have set up wiki software which is now accessible 

both from http://www.tei-c.org/wiki and http://www.tei-c.org.uk/wiki. 

There's a link to the wiki from the main TEI site (on the navigation 

bar). James, Matt Zimmerman, and Daniel O'Donnell have done some very 

good work setting up an area devoted to stylesheets, with some good 

models for people to emulate, and I've put the call for stylesheets 

up. I'm waiting another couple of days while they work out a few more 

details before announcing both the wiki and the call for stylesheets 

on TEI-L, but I think it's just about as good as complete. The wiki 

also contains spaces for the SIGs and a few other areas, and of 

course anyone can create new spaces as needed. The wiki group agreed 

to keep things fairly open for the time being (anyone can register an 

account and make changes) but to keep an eye on things and see how it 

goes.

Best, Julia

At 2:05 PM +0200 4/21/05, Christian Wittern wrote:

>Dear Council meeting,

>Please look also at the action items in

>http://www.tei-c.org.uk/Council/tcm16.xml?style=printable

>and act as necessary.

>

>Looking forward to seeing all of you 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

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Apr 22 2005 - 14:52:59 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sat Apr 23 03:00:36 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 23 Apr 2005 09:00:36 +0200
Subject: [tei-council] Agenda items, documents for Paris meeting
In-Reply-To: 
Message-ID: 

From: Christian Wittern 

Date: Sat, 23 Apr 2005 09:00:36 +0200

Julia Flanders edu> writes:

> I was asked to circulate a summary of the PB workgroup's results to

> date. Terry's report which he put together for the November conference

> call is actually quite complete and contains examples which are now

> visible (for a while they were malfunctioning); see:

>

> http://www.tei-c.org/Activities/PB/pbr01.html

Thank you, this looks very interesting.  

>

> In Safari, you'll need to view source to see the examples. Firefox

> shows them properly.

>

> The other action item to me concerned the TEI wiki. I'm happy to

> report that Sebastian, Lou, and James Cummings (and perhaps unseen

> others at Oxford) have set up wiki software which is now accessible

> both from http://www.tei-c.org/wiki and

> http://www.tei-c.org.uk/wiki. 

Cocoon insists that you need a slash at the end of these URLs.  Again,

this looks very nice and useful.  I hope the community will use 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 Sat Apr 23 2005 - 03:00:41 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Apr 24 05:03:57 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 24 Apr 2005 11:03:57 +0200
Subject: [tei-council] P5 Howto - how?
Message-ID: 

From: Christian Wittern 

Date: Sun, 24 Apr 2005 11:03:57 +0200

Council members,

Having spent a fair amount of time trying to get P5 customizations

according to the P5 Howto working, the only thing I can say is, it does not

seem to work as advertised, at least not on my system.

Here is the ODD fragment I am trying to use, it lives in steininschriften.odd:

I have a P5 CVS tree from SF, do a "make install" and get some errors,

since there are some namespace-related bugs in the XSL that generates

the Guidelines, but I do end up having a schema/relaxng/p5 and schema/dtd/p5

subdirectory in /usr/local/tei/.

Now trying to run Roma (from the P5 dir in the CVS tree, after having

put fix_rnc_whitespace.pl on the path:

~/src/tei/P5/Roma --schema=/usr/local/tei/schema/relaxng/p5/ --nodtd --debug --xsl=http://www.tei-c.org/stylesheet/base steininschriften.odd  mySchemas

========= 2005-04-24 10:54:13.N Roma starts, info:

Test for software: xmllint, xsltproc, trang, and perl

/sw/bin/xmllint

/sw/bin/xsltproc

/Users/chris/bin/trang

/usr/bin/perl

TEI stylesheet tree: http://www.tei-c.org/stylesheet/base

Results to: mySchemas

Process steininschriften.odd to create stone{.dtd|.xsd|.doc.xml|.rng|.rnc} in mySchemas

========= 2005-04-24 10:54:13.N Roma starts, execution:

1. make Relax NG from ODD

warning: failed to load external entity "http://www.tei-c.org/stylesheet/base/p5/odds/odd2odd.xsl"

cannot parse http://www.tei-c.org/stylesheet/base/p5/odds/odd2odd.xsl

warning: failed to load external entity "stone.compiled.odd"

unable to parse stone.compiled.odd

stone.rng:1: parser error : Document is empty

^

stone.rng:1: parser error : Start tag expected, '<' not found

^

2. make Relax NG compact from XML

/Users/chris/tmp/HD/mySchemas/stone.rng:1: fatal: Document root element is missing.

ERROR:  trang fails.

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

Roma seems to look for a file odd2odd.xsl which is nowhere to be

found, not in the CVS tree and not on the server and fails miserably.

Now, the second option is to run the online version, so I go to

http://www.tei-c.org.uk, upload my file, click on "Submit Query" and

proceed to "Schemas".  Trying to generate a schema results in the

message:

Time to give you a schema

MESSAGES

/tmp/f3a07941ebdaa21bb2e1e9d6fb0f7b7c.tmp:5:36: error: reference to undefined pattern "TEI"

Schema

Could not create schema

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

This makes sense, since when I look at the Modules page, there seems

to be no module selected at all, at least no one shows up in the

list. I suspect that the input file has not been parsed correctly.

I wonder if I am doing something wrong here?  Have other council

members been successful in proceeding according to the Howto?

Slightly desperated,

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 Apr 24 2005 - 05:04:04 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Apr 24 06:33:15 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 24 Apr 2005 12:33:15 +0200
Subject: [tei-council] P5 Howto - how?
In-Reply-To: 
Message-ID: 

From: Christian Wittern 

Date: Sun, 24 Apr 2005 12:33:15 +0200

Update:

I retrieved Roma V.1.11 from SF and successfully generated a schema

with that version.

Just for the record...

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 Apr 24 2005 - 06:33:22 EDT

From Syd_Bauman at Brown.edu  Sun Apr 24 08:22:45 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 24 Apr 2005 08:22:45 -0400
Subject: [tei-council] P5 Howto - how?
In-Reply-To: 
Message-ID: <17003.36757.764722.863741@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sun, 24 Apr 2005 08:22:45 -0400

CW> I retrieved Roma V.1.11 from SF and successfully generated a

CW> schema with that version.

I have been having similar problems with 1.13 myself. Even though

Sourceforge will do a very nice job showing the differences[1], it

can be quite difficult to figure out. I believe (but I'm not sure)

that one of the major changes between 1.11 and 1.13 is that the

former generated the 'compiled.rng' file by applying

expandincludes.xsl to the .rng file that was the output of step 1

"make Relax NG from ODD"; the latter tries to generate the

'compiled.rng' file by applying odd2odd.xsl to the ODD file specified

on the Roma commandline (and fails for lack of odd2odd.xsl).

So it looks like backing out to 1.11 will *run* as long as the value

of --xsl= is set to a local directory. (If you want to use the web

for --xsl, try commenting out line 132.) I.e., it looks like all the

component parts that 1.11 calls exist. However, I don't know that

there haven't been significant changes to the .xsl files that are

called that depend on them being called in the way they are by 1.13

instead of by 1.11. It is certainly worth a try, though (and I plan

to do so right after breakfast ... :-)

CW> [Error from Roma web interface] makes sense, since when I look at

CW> the Modules page, there seems to be no module selected at all, at

CW> least no one shows up in the list. I suspect that the input file

CW> has not been parsed correctly.

I got this error once out of the two times I generated a schema via

the web yesterday. I fixed it very quickly by manually adding the

required modules: core, tei, header, & textstructure.

Notes

-----

[1] Try, e.g.,

http://cvs.sourceforge.net/viewcvs.py/tei/P5/Roma?sortby=date&r1=text&tr1=1.11&r2=text&tr2=1.13&diff_format=h

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Apr 24 2005 - 08:22:49 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Apr 24 12:25:32 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 24 Apr 2005 18:25:32 +0200
Subject: [tei-council] Draft agenda for AFNOR meeting 4/28-4/29
Message-ID: 

From: Christian Wittern 

Date: Sun, 24 Apr 2005 18:25:32 +0200

TEI Council Members,

This is the draft agenda for the TEI Council meeting to be held April

28th and 29th at AFNOR, Paris.  Please report any omissions as soon as

possible.

Please read through the following, and bring it along for the meeting.

Expected members to participate:

Syd Bauman, Alejandro Bia, Lou Burnard, James Cummings, Matthew

Driscoll, Julia Flanders, Laurent Romary, Natasha Smith, Susan

Schreibman, Edward Vanhoutte, John Walsh, Perry Willett, Christian

Wittern.

Sebastian Rahtz will not be able to participate.

Agenda:

1. Review of minutes from 3/29, adaption of agenda.

2. Principles of attribute usage in P5 (EDW86)

3. Principles of class definitions in P5 (EDW87)

-- in both cases we want to leave the meeting knowing that Council has

   read and understood the proposals for action contained; and that it

   either agrees to them or proposes alternatives

4. New work items

-- biblItem (Syd was supposed to be doing this)

-- PhysBib stuff (from Julia)

-- Revisions to Roma (assuming I can get the damn thing to work)

-- there may be others 

   (I have just been spending 10 days with people working on stone

   inscriptions from China and they say they want to describe their

   stones, with TEI)

5. Chapter Reviews

6. WG Reports

7. Other items

-- 
 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 Apr 24 2005 - 12:25:35 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Apr 24 12:28:52 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 24 Apr 2005 18:28:52 +0200
Subject: [tei-council] P5 Howto - how?
In-Reply-To: <17003.36757.764722.863741@emt.wwp.brown.edu>
Message-ID: 

From: Christian Wittern 

Date: Sun, 24 Apr 2005 18:28:52 +0200

Syd Bauman edu> writes:

>

> CW> [Error from Roma web interface] makes sense, since when I look at

> CW> the Modules page, there seems to be no module selected at all, at

> CW> least no one shows up in the list. I suspect that the input file

> CW> has not been parsed correctly.

>

> I got this error once out of the two times I generated a schema via

> the web yesterday. I fixed it very quickly by manually adding the

> required modules: core, tei, header, & textstructure.

Yes, but then what is the point of uploading the customization?

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 Apr 24 2005 - 12:28:58 EDT

From lou.burnard at computing-services.oxford.ac.uk  Sun Apr 24 19:18:12 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 25 Apr 2005 00:18:12 +0100
Subject: [tei-council] Draft agenda for AFNOR meeting 4/28-4/29
In-Reply-To: 
Message-ID: <426C2934.3030008@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Mon, 25 Apr 2005 00:18:12 +0100

What time will the meeting start on the 28th?

I apologise in advance for being late -- my train is due to arrive GdN 

at 1250, so I doubt if I will be able to get to Afnor till 2 pm at the 

earliest.

a bientot!

Lou

Christian Wittern wrote:

>TEI Council Members,

>

>This is the draft agenda for the TEI Council meeting to be held April

>28th and 29th at AFNOR, Paris.  Please report any omissions as soon as

>possible.

>

>Please read through the following, and bring it along for the meeting.

>

>

>

>Expected members to participate:

>

>Syd Bauman, Alejandro Bia, Lou Burnard, James Cummings, Matthew

>Driscoll, Julia Flanders, Laurent Romary, Natasha Smith, Susan

>Schreibman, Edward Vanhoutte, John Walsh, Perry Willett, Christian

>Wittern.

>

>

>Sebastian Rahtz will not be able to participate.

>

>

>Agenda:

>

>1. Review of minutes from 3/29, adaption of agenda.

>

>2. Principles of attribute usage in P5 (EDW86)

>

>3. Principles of class definitions in P5 (EDW87)

>

>-- in both cases we want to leave the meeting knowing that Council has

>   read and understood the proposals for action contained; and that it

>   either agrees to them or proposes alternatives

>

>4. New work items

>-- biblItem (Syd was supposed to be doing this)

>-- PhysBib stuff (from Julia)

>-- Revisions to Roma (assuming I can get the damn thing to work)

>-- there may be others 

>   (I have just been spending 10 days with people working on stone

>   inscriptions from China and they say they want to describe their

>   stones, with TEI)

>

>

>5. Chapter Reviews

>

>6. WG Reports

>

>7. Other items

>

> 

>  

>

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Apr 24 2005 - 19:17:37 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Apr 25 05:34:04 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 25 Apr 2005 11:34:04 +0200
Subject: [tei-council] Draft agenda for AFNOR meeting 4/28-4/29
In-Reply-To: <426C2934.3030008@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Mon, 25 Apr 2005 11:34:04 +0200

Lou Burnard oxford.ac.uk> writes:

> What time will the meeting start on the 28th?

We agreed to start at 1400, so you have 70 minutes to come to AFNOR:-)

>

> I apologise in advance for being late -- my train is due to arrive GdN

> at 1250, so I doubt if I will be able to get to Afnor till 2 pm at the

> earliest.

>

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 Apr 25 2005 - 05:34:17 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Apr 26 20:34:32 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 27 Apr 2005 01:34:32 +0100 (BST)
Subject: [tei-council] not a report
Message-ID: <20050427003432.D36D92268A@webmail218.herald.ox.ac.uk>

From: Sebastian Rahtz 

Date: Wed, 27 Apr 2005 01:34:32 +0100 (BST)

 ('binary' encoding is not supported, stored as-is)
I cannot offer a formal report, but I would like to note for the council's

interest that I have reimplemented a fair chunk of the way Roma works

in order to meet some long-standing objectives.

Roma used to work as follows: from a ODD specification, we derived

a Relax NG schema, which used the inclusion/overriding features of Relax

to implement the change/add/delete  features of ODD. This schema was then

flattened and simplified for translation into W3C Schema and DTD. This was

getting increasingly clumsy, and I could not  implement some vital things,

like the ability to override the datatype of a class attribute at an element

level.

The new Roma works in two stages. First, it reads the ODD specification,

and combines it with the original P5 material as needed. So all the 

delete/add/change

rules are applied on the spot to the source. We end up with a  flattened

subset of P5 which can be directly translated to Relax NG (and thence to 

W3C Schema)

or to DTD with a simpler transform, making no use of the Relax NG inclusion

overriding/features.

Why is this good?

 a) at the odd2odd stage, class attributes are applied to the elements, 

by value

rather than reference, so that they can be overridden

 b) DTD can be created directly, rather than via trang from the Relax 

schema,

 which means I get things working properly eg when elements are deleted.

I have tested this fairly exhaustively, and am in the process

of writing documentation for Roma/intro to ODD, a first draft of

which will hopefully appear in your inboxes before you go to Paris.

I am happy to say that I have also revised all my XSL stylesheets

(changing the names of all files as I went along), redocumented

all the parameters, redone the web interface for choosing values for

them, and implemented XSLTdoc for all the files (do a google

search to see what XSLTdoc is).

Why can't you see any of this? cos the bit of wet string

between here and the rest of the world does not permit

me to do more than send safety copies of my work to Lou,

who _may_ be able to disentangle it all, or maybe not

-- 
Sebastian Rahtz    
Oxford University Computing Services
& JISC Open Source Advisory Service
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Apr 26 2005 - 20:34:44 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Apr 27 04:09:31 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 27 Apr 2005 10:09:31 +0200
Subject: [tei-council] not a report
In-Reply-To: <20050427003432.D36D92268A@webmail218.herald.ox.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Wed, 27 Apr 2005 10:09:31 +0200

Sebastian Rahtz oxford.ac.uk> writes:

> I cannot offer a formal report, but I would like to note for the council's

> interest that I have reimplemented a fair chunk of the way Roma works

> in order to meet some long-standing objectives.

This looks great, thanks a lot (I hope to test it later today on my

train to Paris)

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 Apr 27 2005 - 04:09:52 EDT

From Syd_Bauman at Brown.edu  Mon May  2 10:10:56 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 2 May 2005 10:10:56 -0400
Subject: [tei-council] travel reimbursement form
Message-ID: <17014.13552.2218.678830@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Mon, 2 May 2005 10:10:56 -0400

You can find slightly different versions of the travel reimbursement

form at

  http://www.tei-c.org/Members/TEI_travel_form.pdf

and 

  http://www.tei-c.org/travel_form.pdf

The former one has slightly larger type, and is therefore a bit

easier to use, but the latter one is a bit easier to get. The only

real difference I noticed was the address to which to send the form,

which is in Norway, and therefore both are now wrong. I believe the

correct address would be

 Text Encoding Initiative Consortium

 Attn: Daniel Pitti

 319 Alderman Library

 P.O. Box 400115

 University of Virginia

 Charlottesville, Virginia 22904-4115

(I will double-check with Daniel and post here only if that address

is significantly incorrect.)

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue May 03 2005 - 13:32:23 EDT

From Julia_Flanders at Brown.edu  Mon May  2 14:38:39 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Mon, 2 May 2005 14:38:39 -0400
Subject: [tei-council] travel reimbursement
Message-ID: 

From: Julia Flanders 

Date: Mon, 2 May 2005 14:38:39 -0400

Dear Council members,

The travel reimbursement form may be found at

http://www.tei-c.org/travel_form.pdf

This form still carries the old TEI administrative address in Norway. 

An updated form will be posted shortly, but in the meantime please 

note that all reimbursement requests should be sent to the following 

address:

Text Encoding Initiative Consortium

Institute for Advanced Technology in the Humanities

319 Alderman Library

P.O. Box 400115

University of Virginia

Charlottesville, Virginia 22904-4115

Please attach your original receipts, including boarding passes, 

ticket stubs, and meal receipts. If you paid TEI-related expenses for 

someone else (e.g. if you paid for someone else's lunch at AFNOR), 

please enclose a note mentioning this so that it's clear to Daniel 

how the costs are justified.

Thanks--Julia

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue May 03 2005 - 13:32:32 EDT

From James.Cummings at computing-services.oxford.ac.uk  Sun May  1 18:12:02 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Mon, 02 May 2005 00:12:02 +0200
Subject: [tei-council] Photos
Message-ID: <42755432.7020109@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Mon, 02 May 2005 00:12:02 +0200

In case anyone was interested in some of the photos I took of council

members while in Paris, they are online.  I was putting my other photos

online so thought I'd do so with these as well.

http://oucs-jamesc.oucs.ox.ac.uk:8080/gallery/Tei-Council-2005-04/

-James

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue May 03 2005 - 13:32:41 EDT

From lou.burnard at computing-services.oxford.ac.uk  Tue May  3 17:20:48 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 3 May 2005 22:20:48 +0100
Subject: [tei-council] Photos
In-Reply-To: <42755432.7020109@computing-services.oxford.ac.uk>
Message-ID: <4ee3e3dbf68b679785649291dfa79eb1@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Tue, 3 May 2005 22:20:48 +0100

Not to be outdone....

http://www.burnards.net/Paris/

L

On 1 May 2005, at 23:12, James Cummings wrote:

> In case anyone was interested in some of the photos I took of council

> members while in Paris, they are online.  I was putting my other photos

> online so thought I'd do so with these as well.

>

> http://oucs-jamesc.oucs.ox.ac.uk:8080/gallery/Tei-Council-2005-04/

>

> -James

>

> _______________________________________________

> tei-council mailing list

> tei-council_at_lists.village.Virginia.EDU

> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

>

>

 From the Macmini at Burnard Towers

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue May 03 2005 - 17:23:38 EDT

From lou.burnard at computing-services.oxford.ac.uk  Wed May  4 12:36:31 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 04 May 2005 17:36:31 +0100
Subject: [tei-council] edw87 updated; edw86 less so
Message-ID: <4278FA0F.7070501@oucs.ox.ac.uk>

From: Lou Burnard 

Date: Wed, 04 May 2005 17:36:31 +0100

I hope everyone had a bearable journey home (and a nice sunny weekend 

too), and thanks for all the input.

I've made a start on updating the two working papers we spent the first 

part of the meeting on, as far as I can. The changes needed to edw87 

were fairly straightforward, and I had made enough notes to give me 

confidence I have done that one right. There were quite a few 

suggestions for edw87 (as far as I recall) for which input from others 

is neded, so I am less confident that I have done that right.

No doubt the minutes will reveal all, when they appear.

Onward and upward!

Lou

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed May 04 2005 - 12:40:58 EDT

From Julia_Flanders at Brown.edu  Wed May  4 13:45:17 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Wed, 4 May 2005 13:45:17 -0400
Subject: [tei-council] PB group, new chair
Message-ID: 

From: Julia Flanders 

Date: Wed, 4 May 2005 13:45:17 -0400

I am happy to report that Murray McGillivray has agreed to take over 

the leadership of the PB workgroup. I've forwarded him the Council's 

recommendations for things the group should look at. If anyone has 

additional thoughts, please send them along.

Best wishes, Julia

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed May 04 2005 - 13:45:23 EDT

From Syd_Bauman at Brown.edu  Wed May  4 22:05:34 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 4 May 2005 22:05:34 -0400
Subject: [tei-council] first draft of minutes of 2005-04-28/29 meeting available
Message-ID: <17017.32622.51973.739412@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Wed, 4 May 2005 22:05:34 -0400

First draft of minutes is now available at

   http://www.tei-c.org/Council/tcm17.xml?style=printable

but is deliberately not linked from the Council index page (or

anywhere else) yet. Everyone should please read them (particularly

searching for your own name or initials or the string "[?") and post

any corrections, additions, omissions, deletions, complaints, etc.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed May 04 2005 - 22:05:38 EDT

From lou.burnard at computing-services.oxford.ac.uk  Thu May  5 13:02:16 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 05 May 2005 18:02:16 +0100
Subject: [tei-council] first draft of minutes of 2005-04-28/29 meeting available
In-Reply-To: <17017.32622.51973.739412@emt.wwp.brown.edu>
Message-ID: <427A5198.8040905@oucs.ox.ac.uk>

From: Lou Burnard 

Date: Thu, 05 May 2005 18:02:16 +0100

Thanks for these Syd. I've now made some updates, clarifying points of 

uncertainty to the best of my ability and removing one or two typos. The 

only thing I cannot help with is the item that reads

tei.numeric ? missed something here?

as I don't remember what it was that was being discussed at this point. 

Unless anyone else can remember, I suggest you should delete this from 

the record!

The revised draft is at

 http://www.tei-c.org/Council/tcm17.xml

as usual.

Thanks again to all Council members for your active participation -- and willingness to take on new burdens! -- at what was definitely a very productive meeting.

Lou

Syd Bauman wrote:

>First draft of minutes is now available at

>   http://www.tei-c.org/Council/tcm17.xml?style=printable

>but is deliberately not linked from the Council index page (or

>anywhere else) yet. Everyone should please read them (particularly

>searching for your own name or initials or the string "[?") and post

>any corrections, additions, omissions, deletions, complaints, etc.

>

>_______________________________________________

>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 May 05 2005 - 13:03:29 EDT

From Julia_Flanders at Brown.edu  Thu May  5 13:59:37 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 5 May 2005 13:59:37 -0400
Subject: [tei-council] first draft of minutes of 2005-04-28/29 meeting available
In-Reply-To: <427A5198.8040905@oucs.ox.ac.uk>
Message-ID: 

From: Julia Flanders 

Date: Thu, 5 May 2005 13:59:37 -0400

The point on tei.numeric that I remember was that we were going to 

consider whether we needed a TEI data type that could accommodate 

more specific kinds of numeric data....? I remember Laurent 

suggesting a tei.formula (or something to that effect), which could 

be what this is gesturing towards.

EDW86 seems to be malformed and can't be read at the moment, so I 

can't jog my memory by looking at the list of proposed datatypes.

best, Julia

>tei.numeric ? missed something here?

>

>as I don't remember what it was that was being discussed at this 

>point. Unless anyone else can remember, I suggest you should delete 

>this from the record!

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu May 05 2005 - 13:59:42 EDT

From lou.burnard at computing-services.oxford.ac.uk  Thu May  5 15:44:02 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 5 May 2005 20:44:02 +0100
Subject: [tei-council] first draft of minutes of 2005-04-28/29 meeting available
In-Reply-To: 
Message-ID: <6330b2d3c9db3a066fde449be8ea2f24@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Thu, 5 May 2005 20:44:02 +0100

On 5 May 2005, at 18:59, Julia Flanders wrote:

> The point on tei.numeric that I remember was that we were going to 

> consider whether we needed a TEI data type that could accommodate more 

> specific kinds of numeric data....? I remember Laurent suggesting a 

> tei.formula (or something to that effect), which could be what this is 

> gesturing towards.

>

> EDW86 seems to be malformed and can't be read at the moment, so I 

> can't jog my memory by looking at the list of proposed datatypes.

>

Aaargh! Thanks for pointing this out -- I have now fixed the stupid 

tagging error.

Here's the text I added to edw86  which I think expresses what we were 

discussing:

The suggested tei.numeric is a deliberately vague general class, 

intended to encompass a number of more precise datatypes (analogous 

therefore to tei.tempexp). For example, we might want to restrict some 

attribute values to a quantity which might be represented either as a 

real number in the range 0 to 1 or as a percentage; in other cases, it 

might make no sense to have any non-integral value, or to permit a 

negative value. We have nothing analogous to the valList to express 

these constraints on numeric values.

Lou "thumbs" Burnard

> best, Julia

>

>> tei.numeric ? missed something here?

>>

>> as I don't remember what it was that was being discussed at this 

>> point. Unless anyone else can remember, I suggest you should delete 

>> this from the record!

> _______________________________________________

> tei-council mailing list

> tei-council_at_lists.village.Virginia.EDU

> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

>

>

 From the Macmini at Burnard Towers

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu May 05 2005 - 15:46:55 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu May  5 18:48:37 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 06 May 2005 07:48:37 +0900
Subject: [tei-council] first draft of minutes of 2005-04-28/29 meeting available
In-Reply-To: <17017.32622.51973.739412@emt.wwp.brown.edu>
Message-ID: 

From: Christian Wittern 

Date: Fri, 06 May 2005 07:48:37 +0900

Syd Bauman edu> writes:

> First draft of minutes is now available at

>    http://www.tei-c.org/Council/tcm17.xml?style=printable

> but is deliberately not linked from the Council index page (or

> anywhere else) yet. Everyone should please read them (particularly

> searching for your own name or initials or the string "[?") and post

> any corrections, additions, omissions, deletions, complaints, etc.

Thanks a lot, Syd.  This looks like a pretty fair summary of our work.

Here is a small nit to pick:

Meetings were held at AFNOR (room 34), from 14:15 to 18:00 on Thu 28

and from 09:05 to 16:51 on Fri 29, with a lunch break from 12:30 to

13:45. Because her purse had been stolen in Paris, Susan Schreibman

was unable to attend on Saturday; Laurent Romary left at 12:28 on

Saturday

Saturday --> Friday

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 05 2005 - 18:48:46 EDT

From Syd_Bauman at Brown.edu  Thu May  5 19:16:39 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 5 May 2005 19:16:39 -0400
Subject: [tei-council] first draft of minutes of 2005-04-28/29 meeting available
In-Reply-To: 
Message-ID: <17018.43351.201800.497555@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Thu, 5 May 2005 19:16:39 -0400

> Thanks a lot, Syd. This looks like a pretty fair summary of our

> work. Here is a small nit to pick:

> 

> Saturday --> Friday

Whoah! Guess I was more jet-lagged than I thought.

Fixed, thanks.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu May 05 2005 - 19:16:44 EDT

From lou.burnard at computing-services.oxford.ac.uk  Fri May  6 08:58:46 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 06 May 2005 13:58:46 +0100
Subject: [tei-council] ODD manual
Message-ID: <427B6A06.2060403@oucs.ox.ac.uk>

From: Lou Burnard 

Date: Fri, 06 May 2005 13:58:46 +0100

I have now found time to unpack some of the goodies Sebastian has been 

despatching from the other side of the world. One is a preliminary draft 

for a "TEI Customization Handbook" which aims to set out all you need in 

order to adapt the TEI for your own needs.  He intended to distribute 

this to the Council before the Paris meeting, but the PDF file he sent 

was stripped by the listserv in virginia, and I was too preoccupied with 

other things to do anything about sending out an alternative.

Anyway, please visit http://www.tei-c.org/ODD/Manual/ now to see the 

draft in question.

I think the doc is a good start but needs quite a bit more work. The 

tone is closer to that of TD , the reference chapter of P5 (which it 

overlaps somewhat) than of -- say -- the TEI Lite tutorial: I feel that 

it needs to be chattier and more accessible, with plenty of simpler 

examples before hitting people with e.g. xinclude. Above all, it should 

take a more "cookbook" style approach e.g. in presenting Roma.  I think 

the order of presentation is wrong: dtd and relaxng wrappers should be 

relegated to an appendix.  The lists of classes currently in the 

appendix are necessary, but probably should be referenced from here, not 

included in the document, as we will soon have far too many such lists 

to cope with.

But I think the coverage is right: do Council members have suggestions 

for other topics they think such a document really must address, bearing 

in mind the distinction we made at the Paris meeting between

(a) reference documentation in the P5 Guidelines (TD, CF)

(b) tutorial introductions (this document)

Lou

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri May 06 2005 - 09:00:13 EDT

From Laurent.Romary at loria.fr  Fri May  6 09:29:12 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Fri, 6 May 2005 15:29:12 +0200
Subject: [tei-council] ODD manual
In-Reply-To: <427B6A06.2060403@oucs.ox.ac.uk>
Message-ID: 

From: Laurent Romary 

Date: Fri, 6 May 2005 15:29:12 +0200

Having just gone through the document, I actually think it of great 

help for ODD beginners. I would just suggest not to blur the picture 

with the first sections related to DTDs and Schemas. I would move them 

as appendices to the main document. I would also make a stringer view 

on the fact that point 3 is the recommended one when listing the ways 

of customizing the TEI.

Best,

Laurent

Le 6 mai 05, ? 14:58, Lou Burnard a ?crit :

> I have now found time to unpack some of the goodies Sebastian has been 

> despatching from the other side of the world. One is a preliminary 

> draft for a "TEI Customization Handbook" which aims to set out all you 

> need in order to adapt the TEI for your own needs.  He intended to 

> distribute this to the Council before the Paris meeting, but the PDF 

> file he sent was stripped by the listserv in virginia, and I was too 

> preoccupied with other things to do anything about sending out an 

> alternative.

>

> Anyway, please visit http://www.tei-c.org/ODD/Manual/ now to see the 

> draft in question.

>

> I think the doc is a good start but needs quite a bit more work. The 

> tone is closer to that of TD , the reference chapter of P5 (which it 

> overlaps somewhat) than of -- say -- the TEI Lite tutorial: I feel 

> that it needs to be chattier and more accessible, with plenty of 

> simpler examples before hitting people with e.g. xinclude. Above all, 

> it should take a more "cookbook" style approach e.g. in presenting 

> Roma.  I think the order of presentation is wrong: dtd and relaxng 

> wrappers should be relegated to an appendix.  The lists of classes 

> currently in the appendix are necessary, but probably should be 

> referenced from here, not included in the document, as we will soon 

> have far too many such lists to cope with.

>

> But I think the coverage is right: do Council members have suggestions 

> for other topics they think such a document really must address, 

> bearing in mind the distinction we made at the Paris meeting between

> (a) reference documentation in the P5 Guidelines (TD, CF)

> (b) tutorial introductions (this document)

>

> 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 Fri May 06 2005 - 09:31:10 EDT

From Julia_Flanders at Brown.edu  Fri May  6 13:22:31 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Fri, 6 May 2005 13:22:31 -0400
Subject: [tei-council] ODD manual
In-Reply-To: <427B6A06.2060403@oucs.ox.ac.uk>
Message-ID: 

From: Julia Flanders 

Date: Fri, 6 May 2005 13:22:31 -0400

I really enjoyed reading this document (!?!). I agree, it will 

benefit from being made even more accessible, and from explaining 

things in a bit more detail. But overall I think it's a really good 

start.

A few points for revision which you may already have noted:

--move the explanation of the mode= attribute on  to 

precede the discussion of adding a new element, since that example 

uses the mode= attribute; might even want to have a little section 

heading there like "modifications to the schema" or whatever, with a 

topic sentence like "You can add, replace, remove, or change elements 

using the mode= attribute on ..."

--I think you need to briefly describe the nature, usage, and 

implications of the tei class system at some point fairly early on, 

or at least mention that it exists and point the reader to the 

appendix. (And even in that case, the appendix in its current form 

doesn't discuss any issues surrounding the use of classes--for 

instance, making sure the novice knows that an element may belong to 

more than one class, or that the classes have no relation to the 

modules. So some more extended discussion of how it all works would 

be great.) I first noticed the need in section 4 (Writing ODD 

specifications) in the example of adding a new element, where it 

points out that you can specify what class(es) the new element will 

be added to. By the time we get to the example of adding the  

element the need is more acute. For instance, when reading through 

the example, I find myself wondering what the implications of 

including an element in a particular class are: does it mean that it 

gets to use certain attributes? can one add an element to any class 

at will or is there a possibility of producing something that is 

self-contradictory at a technical level (that is, it's not just 

silly--it doesn't work). I don't think (anticipating a possible 

objection) that the class system needs to be presented in huge detail 

to bog the reader down, just a brief explanation to anticipate these 

kinds of questions, with a pointer to some more complete account 

elsewhere.

--I was glad to see the sentence (after that example) "There is no 

need to specify a module for the element to appear in, as this would 

not be used for anything." and in fact I thought it could have been 

stated even earlier, after that first  example (that was 

where the question occurred to me). Perhaps this sentence could be 

placed together with "For objects which are not new, you should 

specify the module in which it was originally defined" right near the 

beginning of the section on modifications. At the moment, 

instructions like these are scattered through as comments on 

examples, rather than being given together as a set of principles--I 

wonder whether the latter might be a useful approach (perhaps with 

reminders as glosses/commentary on specific examples).

--the  example takes several readings to grasp; I think it's 

confusing partly because it's sort of a meta-example, and this isn't 

made absolutely clear in the prose. (I even misread "This 

document..." as meaning "the document you're about to see in the next 

example" rather than "the document you're reading", and I think that 

it could also be made much clearer that the  element is not 

a TEI element. Possible rewrite for that sentence: "The document you 

are now reading, for instance, pulls in tables created by automatic 

processes using a non-TEI element :

[example]

This  element needs to be able to appear almost everywhere, 

so we want to add it to a TEI class whose members are permitted 

almost everywhere; tei.Incl does this job nicely."

--Appendix C, TEI Macros needs more explanatory prose, and also needs 

to make clearer what the stuff in the green boxes is. This section is 

more or less opaque to a novice.

At whatever point in the revision process you think it would be 

useful, I'd be glad to send a list of things that need clarification 

for a more novice reader (i.e. if you want to do the revisions you 

suggest first, I could do a pass on the results).

Best wishes, Julia

At 1:58 PM +0100 5/6/05, Lou Burnard wrote:

>I have now found time to unpack some of the goodies Sebastian has 

>been despatching from the other side of the world. One is a 

>preliminary draft for a "TEI Customization Handbook" which aims to 

>set out all you need in order to adapt the TEI for your own needs. 

>He intended to distribute this to the Council before the Paris 

>meeting, but the PDF file he sent was stripped by the listserv in 

>virginia, and I was too preoccupied with other things to do anything 

>about sending out an alternative.

>

>Anyway, please visit http://www.tei-c.org/ODD/Manual/ now to see the 

>draft in question.

>

>I think the doc is a good start but needs quite a bit more work. The 

>tone is closer to that of TD , the reference chapter of P5 (which it 

>overlaps somewhat) than of -- say -- the TEI Lite tutorial: I feel 

>that it needs to be chattier and more accessible, with plenty of 

>simpler examples before hitting people with e.g. xinclude. Above 

>all, it should take a more "cookbook" style approach e.g. in 

>presenting Roma.  I think the order of presentation is wrong: dtd 

>and relaxng wrappers should be relegated to an appendix.  The lists 

>of classes currently in the appendix are necessary, but probably 

>should be referenced from here, not included in the document, as we 

>will soon have far too many such lists to cope with.

>

>But I think the coverage is right: do Council members have 

>suggestions for other topics they think such a document really must 

>address, bearing in mind the distinction we made at the Paris 

>meeting between

>(a) reference documentation in the P5 Guidelines (TD, CF)

>(b) tutorial introductions (this document)

>

>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 Fri May 06 2005 - 13:22:36 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri May  6 22:04:25 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 07 May 2005 11:04:25 +0900
Subject: [tei-council] ODD manual
In-Reply-To: 
Message-ID: 

From: Christian Wittern 

Date: Sat, 07 May 2005 11:04:25 +0900

Julia Flanders edu> writes:

> I really enjoyed reading this document (!?!). I agree, it will benefit

> from being made even more accessible, and from explaining things in a

> bit more detail. But overall I think it's a really good start.

Having briefly read through the document, I can only second Julia's

statement.  I wish we had this document available a week before the

Council meeting...  Naturally, I now hope that the new [Rr]oma will be

beginning to take orders soon:-)

The appendices about the tei classes and macros are extremely

valuable, this is material I long tried to find without success.  Is

this reflecting the current state of 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 Fri May 06 2005 - 22:04:36 EDT

From Syd_Bauman at Brown.edu  Sat May  7 19:00:52 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 7 May 2005 19:00:52 -0400
Subject: [tei-council] CVS README
In-Reply-To: <4261985B.1020401@computing-services.oxford.ac.uk>
Message-ID: <17021.18596.791121.964838@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sat, 7 May 2005 19:00:52 -0400

James --

  Where is the current version of the CVS P5 Module README (or

whatever it's called) file?

  Thanks

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sat May 07 2005 - 19:00:57 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon May  9 02:07:44 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 09 May 2005 15:07:44 +0900
Subject: [tei-council] P5, roma and bibl[Item|Struct]
Message-ID: 

From: Christian Wittern 

Date: Mon, 09 May 2005 15:07:44 +0900

Council members,

In trying to follow the fine manual on ODD and actually develop some

of my customizations toward P5, I tried to provide myself with a

usable roma today.  To this end, I followed the following steps:

- updated my CVS tree of the TEI modules on SF

- copied a version of the P5 to a temporary location (did not want to

  mess up the working directory)

- extracted the files from Sebastian (p5.tar.gz and xsl.tar.gz) over

  this, both for the files from 4/27 and those of 4/28; the xsl files

  went into a previously created installation at /usr/local/share/xml/tei/stylesheet

- I did issue a make after setting my XSL to the above directory /base/p5 in

  the Makefile. 

- This gave me functional stuff (I think) in $P5/Split and

  $P5/Schemas, but the build of the html version of the Guidelines

  still failes (due to Sebastians restructuring of the directory

  structure of the Stylesheets section, I think)

- Since the various exist related scripts called from the Makefile did

  not seem to work with my version of exist, I created and populated

  the TEI collection by hand.

- I now used the new roma script Sebastian send with the other files

  on 4/27. 

- This gave me RN[GC] and DTD files, but the XSD production ended with

  the message that "biblStruct" was not defined.

I now went back to the non-patched version of the TEI SF tree and

grepped through the Source directories, this indeed turned up both

references to biblStruct and biblItem in CO/ (and possibly

elsewhere).   I wonder why we do have  in here and why it

seems to be more priviliged than ? 

This seems to be the last(?) stumbling block here and I would hope

that Syd or Lou will be able to remove it...

If you followed me so far, you might want to try it yourself; to make

this possible, I moved the stylesheets into exist as well, my

invocation of roma (I renamed roma to roma-new) is then:

h roma-new --teiserver=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/ --xsl=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/stylesheet Test/testlite.odd

called from the P5 directory.

The relevant output portion is as follows:

========= 2005-05-09 15:04:08 Roma starts, info:

Test for software: xmllint, xsltproc, trang, and perl

/sw/bin/xmllint

/sw/bin/xsltproc

/Users/chris/bin/trang

/usr/bin/perl

TEI database server: http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/

TEI stylesheet tree: http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/stylesheet

Results to: RomaResults

Process Test/testlite.odd to create testlite{.dtd|.xsd|.doc.xml|.rng|.rnc} in RomaResults

========= 2005-05-09 15:04:10.N Roma starts, execution:

1. make Relax NG from ODD

2. make Relax NG compact from XML

3. make XSD from Relax NG and then mangle XSD

/private/tmp/P5/RomaResults/testlite.rng:4364: error: reference to undefined pattern "biblStruct"

ERROR:  trang fails.

This was a fatal error. 2005-05-09 15:04:35.N

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 May 09 2005 - 02:07:49 EDT

From lou.burnard at computing-services.oxford.ac.uk  Mon May  9 04:43:59 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 09 May 2005 09:43:59 +0100
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: 
Message-ID: <427F22CF.1050305@oucs.ox.ac.uk>

From: Lou Burnard 

Date: Mon, 09 May 2005 09:43:59 +0100

Christian Wittern wrote:

> Council members,

> 

[...]

> - This gave me functional stuff (I think) in $P5/Split and

>   $P5/Schemas, but the build of the html version of the Guidelines

>   still failes (due to Sebastians restructuring of the directory

>   structure of the Stylesheets section, I think)

The xsl files guidelines.xsl and guidelines-print.xsl in the P5 

directory need to be changed to reference the new stylesheet directory 

name -- I got that far last night!

[...]

> I now went back to the non-patched version of the TEI SF tree and

> grepped through the Source directories, this indeed turned up both

> references to biblStruct and biblItem in CO/ (and possibly

> elsewhere).   I wonder why we do have  in here and why it

> seems to be more priviliged than ? 

> 

This is very odd. Syd did remove biblStruct from the CVS tree, but I 

thought I had prevailed on him to put it  back. Certainly it seems to be 

there now (I just did a CVS update to check). Can you confirm that there 

is a line declaring it in your copy of P5/fileents.dtd ?

> This seems to be the last(?) stumbling block here and I would hope

> that Syd or Lou will be able to remove it...

> 

> If you followed me so far, you might want to try it yourself; to make

> this possible, I moved the stylesheets into exist as well, my

> invocation of roma (I renamed roma to roma-new) is then:

> 

>

I am lost in admiration!

  sh roma-new 

--teiserver=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/ 

--xsl=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/stylesheet 

Test/testlite.odd

> 

> called from the P5 directory.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Mon May 09 2005 - 04:45:39 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon May  9 08:50:55 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 09 May 2005 21:50:55 +0900
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: <427F22CF.1050305@oucs.ox.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Mon, 09 May 2005 21:50:55 +0900

Lou Burnard oxford.ac.uk> writes:

> Christian Wittern wrote:

>> I now went back to the non-patched version of the TEI SF tree and

>> grepped through the Source directories, this indeed turned up both

>> references to biblStruct and biblItem in CO/ (and possibly

>> elsewhere).   I wonder why we do have  in here and why it

>> seems to be more priviliged than ? 

>

> This is very odd. Syd did remove biblStruct from the CVS tree, but I

> thought I had prevailed on him to put it  back. Certainly it seems to

> be there now (I just did a CVS update to check). Can you confirm that

> there is a line declaring it in your copy of P5/fileents.dtd ?

OK, now I understand.  The file in CVS (1.7) is dated 4/21 (on my

system), the one in Sebastians "patch" 4/7 and probably older.  What a

mess.  Here is the relevant part of the Changelog:

----------------------------

revision 1.7

date: 2005/04/15 15:30:45;  author: sbauman;  state: Exp;  lines: +13 -10

Re-instate .

----------------------------

revision 1.6

date: 2005/04/11 16:41:30;  author: louburnard;  state: Exp;  lines: +1 -0

SPQR's changes from Dili

What I do not understand is why there is still a biblitem even in the

latest version? And what about references to these things in the other

files?

Well, I'll just give it another try.

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 May 09 2005 - 08:51:01 EDT

From lou.burnard at computing-services.oxford.ac.uk  Mon May  9 08:54:13 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 09 May 2005 13:54:13 +0100
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: 
Message-ID: <427F5D75.70107@oucs.ox.ac.uk>

From: Lou Burnard 

Date: Mon, 09 May 2005 13:54:13 +0100

The problem is that Sebastian's files won't reflect any changes made to 

CVS after he left. Which is why I am being a bit careful about just 

uploading them all without checking. Since there are a lot of them, this 

takes time...

Christian Wittern wrote:

> Lou Burnard oxford.ac.uk> writes:

> 

> 

>>Christian Wittern wrote:

>>

>>>I now went back to the non-patched version of the TEI SF tree and

>>>grepped through the Source directories, this indeed turned up both

>>>references to biblStruct and biblItem in CO/ (and possibly

>>>elsewhere).   I wonder why we do have  in here and why it

>>>seems to be more priviliged than ? 

>>

>>This is very odd. Syd did remove biblStruct from the CVS tree, but I

>>thought I had prevailed on him to put it  back. Certainly it seems to

>>be there now (I just did a CVS update to check). Can you confirm that

>>there is a line declaring it in your copy of P5/fileents.dtd ?

> 

> 

> OK, now I understand.  The file in CVS (1.7) is dated 4/21 (on my

> system), the one in Sebastians "patch" 4/7 and probably older.  What a

> mess.  Here is the relevant part of the Changelog:

> ----------------------------

> revision 1.7

> date: 2005/04/15 15:30:45;  author: sbauman;  state: Exp;  lines: +13 -10

> Re-instate .

> ----------------------------

> revision 1.6

> date: 2005/04/11 16:41:30;  author: louburnard;  state: Exp;  lines: +1 -0

> SPQR's changes from Dili

> 

> What I do not understand is why there is still a biblitem even in the

> latest version? And what about references to these things in the other

> files?

> 

> Well, I'll just give it another try.

> 

> 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 May 09 2005 - 08:55:45 EDT

From Syd_Bauman at Brown.edu  Mon May  9 14:16:18 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 9 May 2005 14:16:18 -0400
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: 
Message-ID: <17023.43250.121807.807560@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Mon, 9 May 2005 14:16:18 -0400

I am planning to take James' HOWTO and, pretending I've never done

this before, build a P5 following the instructions. I plan to report

both my findings on how good the instructions are, and the status of

the buildability of P5 and status of stuff. However, you (CW)

have beaten me to the latter, and so far as I can tell, you're

description of the problem is right.

Lou is correct, I did put  back into the P5 source.

> What I do not understand is why there is still a biblitem even in

> the latest version?

I wasn't aware there is any reason to take it out. Lou's (and, since

he has now prevailed upon me, my) thinking is that Council will need

to look at both of these elements and decide which one(s) stay in P5.

Obviously since our Paris meeting Council will be waiting to hear

from me about my success or failuer of the P5 bibliography first.

(About which I hope to have something intelligent to say at our 08

Jul conference call.)

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Mon May 09 2005 - 14:16:22 EDT

From sschreib at umd.edu  Mon May  9 17:45:15 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Mon, 9 May 2005 17:45:15 -0400
Subject: [tei-council] problems with online Roma
Message-ID: <200505092145.AJC07737@md2.mail.umd.edu>

From: Susan Schreibman 

Date: Mon, 9 May 2005 17:45:15 -0400

>

hi all -- I'm not sure this ever got to the council list as it got bumped at

UVA -- if it did, forgive for reposting

 * * * 

>I've been trying to get the new version of Roma to work for me a couple of 

>times, and I keep stalling. I tried both using Firefox and IE on a PC using

XP. The >first submit button works fine on 

>http://tei.oucs.ox.ac.uk/Roma/.

>

>But then, after I fill up my details under

>http://tei.oucs.ox.ac.uk/Roma/

startroma.php

>

>and press submit, I don't go to another form, nor do I get some type of 

>success message - so I am not sure if after pressing submit I should be 

>taken to another page, or I should choose an option myself from the tabs 

>across the top.

>

>I decided to go to the Modules tab myself, and I got the following error 

>message. This is the second time I've tried using the new interface, and I 

>have come up against the same problem (at first I thought it might just be 

>internet gremlins). Perhaps I am doing something wrong. If I am, perhaps I 

>could help to make the Customization Handbook clearer so that others don't 

>make the same mistake. I also could not seem to get help to work.

>

>susan

>

>

>Warning: file(http://localhost:8080/cocoon/Query//modules.xq) 

>[function.file]: failed to 

>open stream: HTTP request failed! HTTP/1.1 404 Not Found in 

>/usr/share/tei-roma/roma/roma.php on line 554

>

>Warning: join() 

>[function.join]: Bad 

>arguments. in /usr/share/tei-roma/roma/roma.php on line 554

>

>Warning: DOMDocument::loadXML() 

>[function.loadXML]: Empty 

>string supplied as input in /usr/share/tei-roma/roma/roma.php on line 554

>

>Warning: importNode() expects parameter 1 to be DOMNode, null given in 

>/usr/share/tei-roma/roma/roma.php on line 555

>

>Warning: appendChild() expects parameter 1 to be DOMNode, null given in 

>/usr/share/tei-roma/roma/roma.php on line 556

>

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Mon May 09 2005 - 17:45:12 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon May  9 07:36:36 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 09 May 2005 12:36:36 +0100
Subject: [tei-council] ODD manual
In-Reply-To: 
Message-ID: <427F4B44.2020007@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 09 May 2005 12:36:36 +0100

Christian Wittern wrote:

> I wish we had this document available a week before the

>Council meeting...

>

that was indeed the intention, and the writing was done in time.

Sadly, email is not as reliable as it might be.

>  Naturally, I now hope that the new [Rr]oma will be

>beginning to take orders soon:-)

>  

>

I'm going to Australia on 22nd May, and I expect to find

some networking there which will let me do some serious

uploads.

>The appendices about the tei classes and macros are extremely

>valuable, this is material I long tried to find without success.  Is

>this reflecting the current state of P5?

>  

>

it is automatically generated from the P5 on my computer;

not all of which is even in CVS yet. I need to do some delicate merging

when I get online.

-- 
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 May 10 2005 - 05:30:27 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon May  9 08:05:54 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 09 May 2005 13:05:54 +0100
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: 
Message-ID: <427F5222.4090600@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 09 May 2005 13:05:54 +0100

Christian Wittern wrote:

>- This gave me functional stuff (I think) in $P5/Split and

>  $P5/Schemas, but the build of the html version of the Guidelines

>  still failes (due to Sebastians restructuring of the directory

>  structure of the Stylesheets section, I think)

>  

>

that's expected, yes. My whole stylesheet collection

is restructured and mangled and breaks almost all

existing wrapper stylesheets :-}

>- This gave me RN[GC] and DTD files, but the XSD production ended with

>  the message that "biblStruct" was not defined.

>  

>

this is an ongoing issue with the source tree, that the bibl* work

is only half-complete. you just have to work around it for now. I cannot

say for certain why my setup works, I must have done

some temporary hack to get it working.

>If you followed me so far, you might want to try it yourself; to make

>this possible, I moved the stylesheets into exist as well, my

>invocation of roma (I renamed roma to roma-new) is then:

>

>sh roma-new --teiserver=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/ --xsl=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/stylesheet Test/testlite.odd

>

>  

>

you have no idea now happy it makes me to see 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 Tue May 10 2005 - 05:32:08 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon May  9 08:22:20 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 09 May 2005 13:22:20 +0100
Subject: [tei-council] ODD manual
In-Reply-To: <427B6A06.2060403@oucs.ox.ac.uk>
Message-ID: <427F55FC.7070200@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 09 May 2005 13:22:20 +0100

Lou Burnard wrote:

> TEI Lite tutorial: I feel that it needs to be chattier and more 

> accessible, with plenty of simpler examples before hitting people with 

> e.g. xinclude. Above all, it should take a more "cookbook" style 

> approach e.g. in presenting Roma.  

yes, I agree that the Roma section remains skeletal. I would much 

appreciate considerably more text in this area.

> I think the order of presentation is wrong: dtd and relaxng wrappers 

> should be relegated to an appendix.

that was one of things I was hoping to get comments on, about how 

important it was to mention this, and in what order.

perhaps surprisingly, I feel more strongly than most of you seem to that 

the Relax Wrapper Method

is worth explaining. It is the more likely route to take if you want to 

pull TEI into another scheme.

> The lists of classes currently in the appendix are necessary, but 

> probably should be referenced from here, not included in the document, 

> as we will soon have far too many such lists to cope with.

the reference lists are a detail we can sort out later, I think

Lou, since I am now working in other areas for the rest of my time here 

(ie worrying about writing talks

to give in Australia....), feel free to hack the document around as much 

as you see fit.

-- 
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 May 10 2005 - 05:33:13 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon May  9 08:38:06 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 09 May 2005 13:38:06 +0100
Subject: [tei-council] ODD manual
In-Reply-To: 
Message-ID: <427F59AE.5030909@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 09 May 2005 13:38:06 +0100

Julia Flanders wrote:

>  For instance, when reading through the example, I find myself 

> wondering what the implications of including an element in a 

> particular class are: does it mean that it gets to use certain 

> attributes? can one add an element to any class at will or is there a 

> possibility of producing something that is self-contradictory at a 

> technical level (that is, it's not just silly--it doesn't work). I 

> don't think (anticipating a possible objection) that the class system 

> needs to be presented in huge detail to bog the reader down, just a 

> brief explanation to anticipate these kinds of questions, with a 

> pointer to some more complete account elsewhere. 

You have come across, I think, a tension in this document which is 

caused by not knowing what what else

people will have read when they come to this stuff.  My intention in 

writing it is that it will appear in a book

about the TEI, which would be self-contained (ie, not mandate access to 

the complete Guidelines). So an earlier chapter would

have explained the class system and answered your (entirely sensible) 

questions.

of course, the big chapter in the Guidelines will need lots of rewriting 

in this area too.

how to predict whether what you do will cause self-contradictory results 

is a thorny issue,

which Laurent's folks raised too. Yesterday I made an Odd which deleted 

 but not .

Not surprisingly, the schema was invalid. All my tools so far fail to 

give much help in warning me

this was a dumb thing to do.

-- 
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 May 10 2005 - 05:34:26 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon May  9 19:28:41 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 10 May 2005 00:28:41 +0100
Subject: [tei-council] ODD manual
In-Reply-To: 
Message-ID: <427FF229.2040608@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Tue, 10 May 2005 00:28:41 +0100

Of course,  really the best thing everyone can do is actually try to write

an ODD for themselves, and test whether

a) they can express what they need

b) the result comes out as expected

adding more real-life examples to the manual would be a great help.

if you do get it working, really watch out for b). If one of you

cannot come up with an ODD spec which makes the tools

fall over in a complete heap, I'd be very surprised.

ebastian

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue May 10 2005 - 05:36:16 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue May 10 07:31:45 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 10 May 2005 20:31:45 +0900
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: <427F5222.4090600@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Tue, 10 May 2005 20:31:45 +0900

Sebastian Rahtz oxford.ac.uk> writes:

>>

>>sh roma-new --teiserver=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/ --xsl=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/stylesheet Test/testlite.odd

>>

>>  

>>

> you have no idea now happy it makes me to see this.....

>

You are welcome, of course, but with the recent snapshots of eXist this really

is as easy as it can get -- no magic Cocoon vodoo, no knocking on

wood, no feng-shui and no you name it...

I wish the same could be said of roma, but for now I will just sit

back and remain silent until things calmed down.

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 May 10 2005 - 07:32:00 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue May 10 08:31:44 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 10 May 2005 13:31:44 +0100
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: <17023.43250.121807.807560@emt.wwp.brown.edu>
Message-ID: <4280A9B0.1040703@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Tue, 10 May 2005 13:31:44 +0100

Syd Bauman wrote:

>I am planning to take James' HOWTO and, pretending I've never done

>this before, build a P5 following the instructions. I plan to report

>both my findings on how good the instructions are, and the status of

>the buildability of P5 and status of stuff. 

>

I wouldn't do this for another 2 weeks, if I was you.

You'll just find bugs I have already fixed, probably....

-- 
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 May 11 2005 - 05:38:08 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue May 10 08:40:33 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 10 May 2005 13:40:33 +0100
Subject: [tei-council] problems with online Roma
In-Reply-To: <200505092145.AJC07737@md2.mail.umd.edu>
Message-ID: <4280ABC1.8050202@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Tue, 10 May 2005 13:40:33 +0100

Susan Schreibman wrote:

>

>  

>

>>and press submit, I don't go to another form, nor do I get some type of 

>>success message - so I am not sure if after pressing submit I should be 

>>taken to another page, or I should choose an option myself from the tabs 

>>across the top.

>>    

>>

the latter. its a modal system, not a linear wizard

>>I decided to go to the Modules tab myself, and I got the following error 

>>message. This is the second time I've tried using the new interface, and I 

>>have come up against the same problem (at first I thought it might just be 

>>internet gremlins). Perhaps I am doing something wrong. 

>>

no, I think public roma remains broke.

>> I also could not seem to get help to work.

>>

>>    

>>

it probably does not do what you think. it simply makes help

text visible on each form

-- 
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 May 11 2005 - 05:38:53 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed May 11 18:56:31 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 12 May 2005 07:56:31 +0900
Subject: [tei-council] P5, roma and bibl[Item|Struct] (Solved!!)
In-Reply-To: 
Message-ID: 

From: Christian Wittern 

Date: Thu, 12 May 2005 07:56:31 +0900

Christian Wittern zinbun.kyoto-u.ac.jp> writes:

> Sebastian Rahtz oxford.ac.uk> writes:

>

>>>sh roma-new --teiserver=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/ --xsl=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/stylesheet Test/testlite.odd

>> you have no idea now happy it makes me to see this.....

>>

>

> I wish the same could be said of roma, but for now I will just sit

> back and remain silent until things calmed down.

Or so I wrote, but I just could not keep my hands off -- and I finally

found that the problem was a missing &biblstru; in Source/CO/CO.odd.

With this in place I can now finally build my own, custom made,

shining schemas out of my ODDs.  Heureka!

On the way to this, I have learnt quite a lot about the various nuts

and bolts alleyways, unexpected views and hidden traps of Roma.  I now

think I now why the system bears this name...

What still puzzles me is that the declaration for biblStruct was

missing in all files, but it was only during the XSD build with trang

that this problem showed.  Roma would go ahead happily and build RNG

and DTD for me out of these faulty files and pretending they were fine

without a blinker.  This is what Julia and Sebastian alluded to

earlier, I think.  So maybe trang could in fact be used to detect at

least some of the more obvious bullets in ones own foot?!

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 May 11 2005 - 18:56:38 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed May 11 23:43:58 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 12 May 2005 12:43:58 +0900
Subject: [tei-council] roma testrive
Message-ID: 

From: Christian Wittern 

Date: Thu, 12 May 2005 12:43:58 +0900

Dear Council members, 

Now that I finally are in a position to testdrive roma, I came up with

something that looks like a bug, but might as well be a

misunderstanding:

In my odd, I have the following snippet:

which I put after all the other moduleRefs.

Invoking my shiny new roma, I get:

/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:2920: error: multiple definitions of "name" without "combine" attribute

/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:3926: error: multiple definitions of "note" without "combine" attribute

/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:7672: error: multiple definitions of "language" without "combine" attribute

/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:16468: error: multiple definitions of "#start" without "combine" attribute

All these look like things that exist both in tei and mods, but surely

they should be distinguished by their namespace?!

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 May 11 2005 - 23:44:05 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed May 11 07:33:45 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 11 May 2005 12:33:45 +0100
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: 
Message-ID: <4281ED99.8080504@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Wed, 11 May 2005 12:33:45 +0100

Christian Wittern wrote:

>

>I wish the same could be said of roma, but for now I will just sit

>back and remain silent until things calmed down.

>

>  

>

if you use a decent setup, then

 apt-get install tei-roma

will do the job.... (in due course)

-- 
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 May 12 2005 - 07:40:50 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed May 11 21:33:54 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Thu, 12 May 2005 02:33:54 +0100
Subject: [tei-council] P5, roma and bibl[Item|Struct] (Solved!!)
In-Reply-To: 
Message-ID: <4282B282.9050509@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Thu, 12 May 2005 02:33:54 +0100

Christian Wittern wrote:

>Or so I wrote, but I just could not keep my hands off -- and I finally

>found that the problem was a missing &biblstru; in Source/CO/CO.odd.

>  

>

that figures.

>On the way to this, I have learnt quite a lot about the various nuts

>and bolts alleyways, unexpected views and hidden traps of Roma.  I now

>think I now why the system bears this name...

>  

>

it is excellent to know that you are finding all this out, as

you'll now be able to write lots of documentation....

> Roma would go ahead happily and build RNG

>and DTD for me out of these faulty files and pretending they were fine

>without a blinker. 

>

you're hitting lazy evaluation. the reference is not checked until

runtime.

> This is what Julia and Sebastian alluded to

>earlier, I think.  So maybe trang could in fact be used to detect at

>least some of the more obvious bullets in ones own foot?!

>  

>

informally, yes. but there is a big difficulty in relating the error message

from trang back to the source ODD, which is what you really want. You

got enough information about biblStruct to know where to look, but

you are on the very high end of the scale of expertise by now, and most

people wouldn't have a clue.

The revised Roma that you are now running does do a lot more than

before to work around your attempts to shoot yourself.  If you

opt to delete , and there is a content model of

we used to make  a  to make this work, but

that meant the DTD ended up with ()*. So now I detect  is no

longer available, and zap the entire  clause. The code

which does this (template "simplifyRelax" in odd2odd.xsl) is not

foolproof, and may need  tweaking, but it covers the simpler cases.

-- 
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 May 12 2005 - 07:45:06 EDT

From Syd_Bauman at Brown.edu  Thu May 12 10:12:57 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 12 May 2005 10:12:57 -0400
Subject: [tei-council] P5, roma and bibl[Item|Struct] (Solved!!)
In-Reply-To: <4282B282.9050509@computing-services.oxford.ac.uk>
Message-ID: <17027.25705.833205.662785@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Thu, 12 May 2005 10:12:57 -0400

> >Or so I wrote, but I just could not keep my hands off -- and I

> >finally found that the problem was a missing &biblstru; in

> >Source/CO/CO.odd.

> >

> that figures.

Do you mean the &biblstru.odd; reference? It *is* in the current copy

in the CVS tree, right? I see it on line 3472.

I hope you're using and old version Christian; otherwise we have

problems. I just spent half an hour tracking through this stuff, and

as far as I can tell, it's there.

For those interested in some of the cool stuff we get from

Sourceforge (which partially makes up for these kinds of headaches),

check out

  http://cvs.sourceforge.net/viewcvs.py/tei/P5/Source/CO/co.odd?r1=1.4&r2=1.5

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu May 12 2005 - 10:13:01 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu May 12 18:25:09 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 13 May 2005 07:25:09 +0900
Subject: [tei-council] P5, roma and bibl[Item|Struct] (Solved!!)
In-Reply-To: <17027.25705.833205.662785@emt.wwp.brown.edu>
Message-ID: 

From: Christian Wittern 

Date: Fri, 13 May 2005 07:25:09 +0900

Syd Bauman edu> writes:

>> >Or so I wrote, but I just could not keep my hands off -- and I

>> >finally found that the problem was a missing &biblstru; in

>> >Source/CO/CO.odd.

>> >

>> that figures.

>

> Do you mean the &biblstru.odd; reference? It *is* in the current copy

> in the CVS tree, right? I see it on line 3472.

>

> I hope you're using and old version Christian; otherwise we have

> problems. I just spent half an hour tracking through this stuff, and

> as far as I can tell, it's there.

No, I applied Sebastians "patch", (as I explained at the beginning of

this thread) that is, I just copied everything he sent over the CVS

checkout, which was one reason for all this mess.  

>

> For those interested in some of the cool stuff we get from

> Sourceforge (which partially makes up for these kinds of headaches),

> check out

>   http://cvs.sourceforge.net/viewcvs.py/tei/P5/Source/CO/co.odd?r1=1.4&r2=1.5

Yes, of course, but in this case it did not really help.  Sebastian, I

hope you are back to using CVS soon:-)

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 12 2005 - 18:25:22 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu May 12 18:29:17 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 13 May 2005 07:29:17 +0900
Subject: [tei-council] P5, roma and bibl[Item|Struct] (Solved!!)
In-Reply-To: <4282B282.9050509@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Fri, 13 May 2005 07:29:17 +0900

Sebastian Rahtz oxford.ac.uk> writes:

> it is excellent to know that you are finding all this out, as

> you'll now be able to write lots of documentation....

As you see, for the moment I am spending my time kicking the tires,

which seems to through a lot of dust.

> The revised Roma that you are now running does do a lot more than

> before to work around your attempts to shoot yourself.  If you

> opt to delete , and there is a content model of

>

>  

>

> we used to make  a  to make this work, but

> that meant the DTD ended up with ()*. 

Wouldn't it be easier to post-fix that in the DTD, if that gives you

overall a cleaner production line?

> So now I detect  is no

> longer available, and zap the entire  clause. The code

> which does this (template "simplifyRelax" in odd2odd.xsl) is not

> foolproof, and may need  tweaking, but it covers the simpler cases.

I have not yet been brave enough to delve into odd2odd in any

detail:-)

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 12 2005 - 18:29:21 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri May 13 02:48:44 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 13 May 2005 07:48:44 +0100
Subject: [tei-council] roma testrive
In-Reply-To: 
Message-ID: <42844DCC.6040603@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Fri, 13 May 2005 07:48:44 +0100

Christian Wittern wrote:

>Dear Council members, 

>	       

>

>which I put after all the other moduleRefs.

>

>Invoking my shiny new roma, I get:

>/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:2920: error: multiple definitions of "name" without "combine" attribute

>/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:3926: error: multiple definitions of "note" without "combine" attribute

>/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:7672: error: multiple definitions of "language" without "combine" attribute

>/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:16468: error: multiple definitions of "#start" without "combine" attribute

>

>All these look like things that exist both in tei and mods, but surely

>they should be distinguished by their namespace?!

>

>  

>

No, because these are the names of Relax patterns, which are

not namespaced. Only the _elements_ (and attributes) have a namespace.

This is an annoyance, which it is hard to work around without renaming the

patterns on one side of another.

The start thing is a pain.   do something like this:

In case I added support for this after I send you the files before, I'm

sending you privately fresh copies of the XSLT on my system.

-- 
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 May 13 2005 - 05:30:29 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun May 15 21:46:27 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 16 May 2005 02:46:27 +0100
Subject: [tei-council] P5, roma and bibl[Item|Struct] (Solved!!)
In-Reply-To: 
Message-ID: <4287FB73.4090707@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 16 May 2005 02:46:27 +0100

Christian Wittern wrote:

>As you see, for the moment I am spending my time kicking the tires,

>which seems to through a lot of dust.

>  

>

shows they are well travelled

>

>>we used to make  a  to make this work, but

>>that meant the DTD ended up with ()*. 

>>    

>>

>

>Wouldn't it be easier to post-fix that in the DTD, if that gives you

>overall a cleaner production line?

>  

>

My current view is that this *is* the cleaner production line, doing

all the work at the odd2odd stage, so that resulting expanded ODD

is easy to translate to schema or DTD. We could imagine writing a direct

ODD to W3C schema, for instance.

Naturally, the whole ODD-processing production line can

be re-implemented in the future if anyone ever has a proper

computer scientist to assign to the job. If I was doing a risk

analysis of the TEI, I'd say that one of the problems of P5 is that

we are too dependent on  single tool chain, just as we were with P4.

It's one of the reason why I favour promoting "native" use of Relax NG,

as it gives an alternative technology. Of course, it still depends on the

base ODD to Relax conversion, but I am fairly confident that this is stable

and replicable.

-- 
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 May 16 2005 - 05:30:35 EDT

From Syd_Bauman at Brown.edu  Mon May 16 14:50:29 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 16 May 2005 14:50:29 -0400
Subject: [tei-council] Photos
In-Reply-To: <4ee3e3dbf68b679785649291dfa79eb1@computing-services.oxford.ac.uk>
Message-ID: <17032.60277.660535.790063@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Mon, 16 May 2005 14:50:29 -0400

> Not to be outdone....

Well, I've already been outdone by both James and Lou, but to

contribute my small bit ...

http://bauman.zapto.org/gallery/TEI_Council_Paris_2005

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Mon May 16 2005 - 14:50:33 EDT

From Julia_Flanders at Brown.edu  Fri May 20 10:58:25 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Fri, 20 May 2005 10:58:25 -0400
Subject: [tei-council] Funding for Multilingual TEI
Message-ID: 

From: Julia Flanders 

Date: Fri, 20 May 2005 10:58:25 -0400

I've just had email from Harold Short, mentioning a funding 

opportunity which might be valuable for the TEI.

The ALLC has a "project support" scheme which provides funding of 

about 5000 pounds for relevant projects. Harold has indicated that 

the ALLC would be very interested in funding a proposal from the TEI 

to do some work on some aspect of "Multilingual TEI". He also says 

that the ALLC Committee has indicated a willingness to receive an 

application for double the normal funding limit (i.e. a total of 

10000 GBP).  He suggests that such a project might serve as a pilot 

for a larger-scale application to the EU.

I'm also posting this to the TEI Board, since they need to be 

involved in the larger strategic decisions. I've proposed that we 

might designate a small group with a representative from the Board 

and at least one from the Council, to take charge of putting together 

the proposal.

But the question of what would be the most important area to focus on 

is up to the Council to determine. Is there an appropriately sized 

chunk of work we could identify, that such a proposal could fund?

Best wishes, Julia

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri May 20 2005 - 10:58:31 EDT

From Julia_Flanders at Brown.edu  Fri May 20 16:22:23 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Fri, 20 May 2005 16:22:23 -0400
Subject: [tei-council] more on internationalization
Message-ID: 

From: Julia Flanders 

Date: Fri, 20 May 2005 16:22:23 -0400

Syd and I were talking about this issue a little more, and it seemed 

to us that two valuable ways to increase the multilinguality of the 

TEI universe would be:

1. Provide the TEI tagset in several languages other than English

--complete the existing provision for tag names and attributes in 

German, French, and Spanish

--add to this list of languages, perhaps to include Italian, a 

Scandinavian language, an Eastern European language?

2. Provide the P5 how-to, ODD manual, and an Introduction to TEI 

document in several languages other than English

It would also be nice to translate the Guidelines themselves, but 

that would be beyond the scope of this initial funding. And I think 

covering more languages is in some ways more useful than covering 

more information--for one thing, diplomatically, it sends a stronger 

signal of inclusiveness, and doesn't ask us to decide which language 

is most important to start with.

I don't have a sense of how much work is involved in either task; 

ideally, we would use the funding to leverage some volunteer time. 

How much time did it take to translate the tagset into German or 

French or Spanish?

Best wishes, Julia

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri May 20 2005 - 16:22:29 EDT

From Syd_Bauman at Brown.edu  Fri May 20 16:28:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 20 May 2005 16:28:11 -0400
Subject: [tei-council] more on internationalization
In-Reply-To: 
Message-ID: <17038.18523.9421.66382@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Fri, 20 May 2005 16:28:11 -0400

> --complete the existing provision for tag names and attributes in

> German, French, and Spanish

My fault for leading you astray there, Julia. To my (limited)

knowledge, we only have markup names in German and Spanish, no French.

We have all 3 for the Roma (web) interface. I am not sure how

complete the lists of German and Spanish markup names are.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri May 20 2005 - 16:28:15 EDT

From edward.vanhoutte at kantl.be  Fri May 20 16:31:00 2005
From: edward.vanhoutte at kantl.be (Edward Vanhoutte)
Date: Fri, 20 May 2005 22:31:00 +0200
Subject: [tei-council] more on internationalization
In-Reply-To: 
Message-ID: <428E4904.2050702@kantl.be>

From: Edward Vanhoutte 

Date: Fri, 20 May 2005 22:31:00 +0200

I think a third valuable way is the translation of the on-line workshops 

which could come out of project 'TEI by example. Creating a toolkit for 

teaching text encoding' which was submitted in february to the ALLC 

project support programme by Melissa Terras and myself and which was 

widely supported by many of you.

Edward

Julia Flanders wrote:

> Syd and I were talking about this issue a little more, and it seemed 

> to us that two valuable ways to increase the multilinguality of the 

> TEI universe would be:

>

> 1. Provide the TEI tagset in several languages other than English

> --complete the existing provision for tag names and attributes in 

> German, French, and Spanish

> --add to this list of languages, perhaps to include Italian, a 

> Scandinavian language, an Eastern European language?

>

> 2. Provide the P5 how-to, ODD manual, and an Introduction to TEI 

> document in several languages other than English

>

> It would also be nice to translate the Guidelines themselves, but that 

> would be beyond the scope of this initial funding. And I think 

> covering more languages is in some ways more useful than covering more 

> information--for one thing, diplomatically, it sends a stronger signal 

> of inclusiveness, and doesn't ask us to decide which language is most 

> important to start with.

>

> I don't have a sense of how much work is involved in either task; 

> ideally, we would use the funding to leverage some volunteer time. How 

> much time did it take to translate the tagset into German or French or 

> Spanish?

>

> Best wishes, Julia

> _______________________________________________

> tei-council mailing list

> tei-council_at_lists.village.Virginia.EDU

> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

>

-- 
================
Edward Vanhoutte
Coordinator
Centrum voor Teksteditie en Bronnenstudie - CTB (KANTL)
Centre for Scholarly Editing and Document Studies
Associate Editor, Literary and Linguistic Computing
Koninklijke Academie voor Nederlandse Taal- en Letterkunde
Royal Academy of Dutch Language and Literature
Koningstraat 18 / b-9000 Gent / Belgium
tel: +32 9 265 93 51 / fax: +32 9 265 93 49
edward dot vanhoutte at kantl dot be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri May 20 2005 - 16:34:20 EDT

From James.Cummings at computing-services.oxford.ac.uk  Fri May 20 17:44:46 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 20 May 2005 22:44:46 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
Message-ID: <428E5A4E.2020302@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Fri, 20 May 2005 22:44:46 +0100

Julia Flanders wrote:

> 1. Provide the TEI tagset in several languages other than English

> --complete the existing provision for tag names and attributes in 

> German, French, and Spanish

> --add to this list of languages, perhaps to include Italian, a 

> Scandinavian language, an Eastern European language?

Could I point out a type of language that is under-represented here?

Although I don't know any oriental language, it strikes me that they

(perhaps Japanese) would be quite interesting to have the TEI tagset

in such a language.  This would also encourage take-up of TEI in

oriental text-encoding projects.  Of course, I'm suggesting this

with only a sliver of a guess about the possible problems in taxonomy, 

etc.  But if this really is the brave new world of Unicode, then it 

seems to me that something very non-western in its character set should 

be included.

I'm not necessarily suggesting this as a proposed output for any 

particular funding bid, but something we should keep in mind.

-James

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri May 20 2005 - 17:44:39 EDT

From Syd_Bauman at Brown.edu  Fri May 20 20:01:31 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 20 May 2005 20:01:31 -0400
Subject: [tei-council] more on internationalization
In-Reply-To: <428E5A4E.2020302@computing-services.oxford.ac.uk>
Message-ID: <17038.31323.343827.318387@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Fri, 20 May 2005 20:01:31 -0400

> Could I point out a type of language that is under-represented here?

> Although I don't know any oriental language, ...

Absolutely! In the conversation Julia refers to we had spoken about

oriental and other languages briefly, but were not sure the EU (or

ALLC) was interested in funding these.

Doesn't mean they're not important, though. I don't know what funding

agencies there are in, say, Japan, Taiwan, India, Egypt, etc., but it

might be interesting to think about simultaneously hitting several,

in a sense saying "look, these folks are getting it translated to

*their* language, what about you"? Just a thought.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri May 20 2005 - 20:01:35 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat May 21 05:35:45 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 21 May 2005 10:35:45 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: <17038.18523.9421.66382@emt.wwp.brown.edu>
Message-ID: <428F00F1.5060507@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sat, 21 May 2005 10:35:45 +0100

Syd Bauman wrote:

>>--complete the existing provision for tag names and attributes in

>>German, French, and Spanish

>>    

>>

>

>My fault for leading you astray there, Julia. To my (limited)

>knowledge, we only have markup names in German and Spanish, no French.

>We have all 3 for the Roma (web) interface. I am not sure how

>complete the lists of German and Spanish markup names are.

>  

>

Some names are in French, but a lot remains to be done

of 487 elements in the database, 484 are in German and Spanish,

127 in Catalan and 125 in French.

-- 
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 May 21 2005 - 22:57:03 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat May 21 05:38:31 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 21 May 2005 10:38:31 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
Message-ID: <428F0197.60802@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sat, 21 May 2005 10:38:31 +0100

Julia Flanders wrote:

>

> 1. Provide the TEI tagset in several languages other than English

> --complete the existing provision for tag names and attributes in 

> German, French, and Spanish

It would also help a lot, of course, to translate the  or  

for each element and attribute.

Without that, its not clear whether anyone will use the translated names.

> I don't have a sense of how much work is involved in either task; 

> ideally, we would use the funding to leverage some volunteer time. How 

> much time did it take to translate the tagset into German or French or 

> Spanish?

The German took about 2 man weeks, I think. But that was problematic, 

because Arno was

not very familiar with the territory, and Christian thinks some of his 

words are not right.

So each translation needs a reviewer.

-- 
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 May 21 2005 - 22:57:09 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun May 22 05:34:16 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 22 May 2005 18:34:16 +0900
Subject: [tei-council] more on internationalization
In-Reply-To: <428F0197.60802@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Sun, 22 May 2005 18:34:16 +0900

Julia,

I think this is an excellent opportunity.

Sebastian Rahtz oxford.ac.uk> writes:

> Julia Flanders wrote:

>

>>

>> 1. Provide the TEI tagset in several languages other than English

>> --complete the existing provision for tag names and attributes in

>> German, French, and Spanish

>

> It would also help a lot, of course, to translate the  or

>  for each element and attribute.

> Without that, its not clear whether anyone will use the translated

> names.

I second this.  Even translated tag-names might be difficult to

understand due to the necessary terseness.  Translated tag-names also

open the door to all kinds of misunderstandings when talking about the

tags; but I do see the neccessity.  

 and  on the other hand are slightly more verbose and

with things like oxygen, they can even be displayed directly to the

encoder while doing the work.  BTW, I have been wondering if the

current ODDs do allow for multiple, multilingual  and 

elements?  

I know of a group in Taiwan that might be interested to chime in with

Chinese, and even for Japanese I could try to do something, if this

sounds interesting.  Getting funding for this over here, is probably a

different story

> The German took about 2 man weeks, I think. But that was problematic,

> because Arno was

> not very familiar with the territory, and Christian thinks some of his

> words are not right.

> So each translation needs a reviewer.

Ideally the translator should be familiar with the TEI Guidelines and

text encoding.  And yes, the budget should allow for a review process.

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 May 22 2005 - 05:34:23 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun May 22 10:16:07 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 22 May 2005 15:16:07 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
Message-ID: <42909427.8020800@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 22 May 2005 15:16:07 +0100

Christian Wittern wrote:

> and  on the other hand are slightly more verbose and

>with things like oxygen, they can even be displayed directly to the

>encoder while doing the work.  BTW, I have been wondering if the

>current ODDs do allow for multiple, multilingual  and 

>elements?  

>  

>

hmm. that needs some thought.

-- 
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 May 22 2005 - 10:19:00 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun May 22 10:19:45 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 22 May 2005 15:19:45 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
Message-ID: <42909501.6060604@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 22 May 2005 15:19:45 +0100

Christian Wittern wrote:

>

>  

> and  on the other hand are slightly more verbose and

>with things like oxygen, they can even be displayed directly to the

>encoder while doing the work.  BTW, I have been wondering if the

>current ODDs do allow for mult

>

this is important, by the way, as it gives an immediate visibly

useful demo of the work. In fact, keeping tag names in English

but translaating the  is arguably the most useful thing to do.

-- 
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 May 22 2005 - 10:22:34 EDT

From lou.burnard at computing-services.oxford.ac.uk  Sun May 22 11:27:46 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 22 May 2005 16:27:46 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
Message-ID: 

From: Lou Burnard 

Date: Sun, 22 May 2005 16:27:46 +0100

On 22 May 2005, at 10:34, Christian Wittern wrote:

>>

>> It would also help a lot, of course, to translate the  or

>>  for each element and attribute.

>> Without that, its not clear whether anyone will use the translated

>> names.

>

> I second this.  Even translated tag-names might be difficult to

> understand due to the necessary terseness.  Translated tag-names also

> open the door to all kinds of misunderstandings when talking about the

> tags; but I do see the neccessity.

>  and  on the other hand are slightly more verbose and

> with things like oxygen, they can even be displayed directly to the

> encoder while doing the work.  BTW, I have been wondering if the

> current ODDs do allow for multiple, multilingual  and 

> elements?

They should do.

I also think it is *much* more useful  to translate e.g. the desc and 

gloss elements than it is to simply translate the tagnames.  Now that 

we have gone to the effort of making it possible for systems to take 

full advantage of the doc umentation within an ODD, providing it in 

languages other than English is definitely the way to go.

 From the Macmini at Burnard Towers

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun May 22 2005 - 11:31:14 EDT

From Syd_Bauman at Brown.edu  Sun May 22 16:05:18 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 22 May 2005 16:05:18 -0400
Subject: [tei-council] more on internationalization
In-Reply-To: 
Message-ID: <17040.58878.18583.934942@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sun, 22 May 2005 16:05:18 -0400

> I also think it is *much* more useful to translate e.g. the desc

> and gloss elements than it is to simply translate the tagnames.

While I'm not as confident as Lou seems to be, I think this is

probably the better way to go, too. There are lots of tag and

attribute names that are not initially obvious even to a native

English speaker. Changing them to something that's not initially

obvious in the reader's native language would help less than

providing a brief prose explanation in the reader's native language. 

I haven't thought through how this fits into the funding question,

but it is important.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun May 22 2005 - 16:05:26 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon May 23 10:05:34 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 23 May 2005 15:05:34 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: <17040.58878.18583.934942@emt.wwp.brown.edu>
Message-ID: <4291E32E.4030706@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 23 May 2005 15:05:34 +0100

Syd Bauman wrote:

>

>I haven't thought through how this fits into the funding question,

>but it is important.

>

>  

>

I think it potentially makes the job easier, to translate a sentence of 

text rather

than agonzing over with  should be in Chinese or Berber.  Almost

anyone can do the former, but the latter requires someone used to tagging,

I think.

the file teinames.xml in the Sourceforge I18N area

has the infrastructure ready for this to work, with some

Spanish translattions by Alejandro.

-- 
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 May 23 2005 - 10:09:27 EDT

From Julia_Flanders at Brown.edu  Mon May 23 10:09:57 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Mon, 23 May 2005 10:09:57 -0400
Subject: [tei-council] more on internationalization
In-Reply-To: <17040.58878.18583.934942@emt.wwp.brown.edu>
Message-ID: 

From: Julia Flanders 

Date: Mon, 23 May 2005 10:09:57 -0400

This sounds good to me as well.

So, for how many languages could we translate  and  (and 

perhaps tag names as well, or perhaps not) for $20,000? If 

translating the tag names alone, imperfectly, took two weeks, would 

one month per language for the initial translation, plus something 

for the review, be enough?

And how much would that month reasonably cost us?

To identify the translators, would it be worth our posting a call on 

TEI-L, announcing the proposal and indicating that we're seeking 

translators who would be willing to contribute some time (i.e. they'd 

get paid, but probably not fully for what their time is worth)? and 

also reviewers? Or would we prefer to identify translators ourselves?

Best, Julia

At 4:05 PM -0400 5/22/05, Syd Bauman wrote:

>>  I also think it is *much* more useful to translate e.g. the desc

>>  and gloss elements than it is to simply translate the tagnames.

>

>While I'm not as confident as Lou seems to be, I think this is

>probably the better way to go, too. There are lots of tag and

>attribute names that are not initially obvious even to a native

>English speaker. Changing them to something that's not initially

>obvious in the reader's native language would help less than

>providing a brief prose explanation in the reader's native language.

>

>I haven't thought through how this fits into the funding question,

>but it is important.

>

>_______________________________________________

>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 23 2005 - 10:10:07 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon May 23 10:13:28 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 23 May 2005 15:13:28 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
Message-ID: <4291E508.30601@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 23 May 2005 15:13:28 +0100

Julia Flanders wrote:

>

> So, for how many languages could we translate  and  (and 

> perhaps tag names as well, or perhaps not) for $20,000? If translating 

> the tag names alone, imperfectly, took two weeks,

dont trust that report of mine. I'd have to ask Arno

> would one month per language for the initial translation, plus 

> something for the review, be enough?

>

I think thats too much.  I think a competent person would translate the 

necessary 1000 or so sentences in

a week.  say that cost $1000, we could do 20 languages.  be more 

pessimistic and double that,

and we still could commission 10 translations.

> And how much would that month reasonably cost us?

>

> To identify the translators, would it be worth our posting a call on 

> TEI-L, announcing the proposal and indicating that we're seeking 

> translators who would be willing to contribute some time (i.e. they'd 

> get paid, but probably not fully for what their time is worth)? and 

> also reviewers? Or would we prefer to identify translators ourselves?

I think its worth asking on TEI-L. Other people may have experience

of commissioning translation, or be able to offer to do it themselves.

of course, we cant do nowt until the editors confirm the  and 

 texts are

stable....

-- 
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 May 23 2005 - 10:16:23 EDT

From mjd at hum.ku.dk  Mon May 23 10:27:08 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Mon, 23 May 2005 16:27:08 +0200
Subject: [tei-council] more on internationalization
In-Reply-To: 
Message-ID: <4292045C.16098.17CF072@localhost>

From: M. J. Driscoll 

Date: Mon, 23 May 2005 16:27:08 +0200

Just wanted to say that I think this is all a very good 

idea and will gladly contribute; I could, for example, 

arrange for translations into Danish (or some other 

Scandinavian language) and, say, Bulgarian (or Czech).

MJD

> This sounds good to me as well.

> 

> So, for how many languages could we translate  and

>  (and perhaps tag names as well, or perhaps not) for

> $20,000? If translating the tag names alone, imperfectly,

> took two weeks, would one month per language for the initial

> translation, plus something for the review, be enough?

> 

> And how much would that month reasonably cost us?

> 

> To identify the translators, would it be worth our posting a

> call on TEI-L, announcing the proposal and indicating that

> we're seeking translators who would be willing to contribute

> some time (i.e. they'd get paid, but probably not fully for

> what their time is worth)? and also reviewers? Or would we

> prefer to identify translators ourselves?

> 

> Best, Julia

> 

> At 4:05 PM -0400 5/22/05, Syd Bauman wrote:

> >>  I also think it is *much* more useful to translate e.g.

> >>  the desc and gloss elements than it is to simply

> >>  translate the tagnames.

> >

> >While I'm not as confident as Lou seems to be, I think this

> >is probably the better way to go, too. There are lots of

> >tag and attribute names that are not initially obvious even

> >to a native English speaker. Changing them to something

> >that's not initially obvious in the reader's native

> >language would help less than providing a brief prose

> >explanation in the reader's native language.

> >

> >I haven't thought through how this fits into the funding

> >question, but it is important.

> >

> >_______________________________________________

> >tei-council mailing list

> >tei-council_at_lists.village.Virginia.EDU

> >http://lists.village.Virginia.EDU/mailman/listinfo/tei-coun

> >cil

> 

> _______________________________________________

> tei-council mailing list

> tei-council_at_lists.village.Virginia.EDU

> http://lists.village.Virginia.EDU/mailman/listinfo/tei-counc

> il

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Mon May 23 2005 - 10:26:18 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon May 23 18:46:13 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 24 May 2005 07:46:13 +0900
Subject: [tei-council] more on internationalization
In-Reply-To: <4291E32E.4030706@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Tue, 24 May 2005 07:46:13 +0900

Sebastian Rahtz oxford.ac.uk> writes:

> I think it potentially makes the job easier, to translate a sentence

> of text rather

> than agonzing over with  should be in Chinese or Berber.  Almost

> anyone can do the former, but the latter requires someone used to tagging,

> I think.

-- I had the same example in mind ;-)

>

> the file teinames.xml in the Sourceforge I18N area

> has the infrastructure ready for this to work, with some

> Spanish translattions by Alejandro.

To me the file under sf/P5 looks much more complete.  however, I do

not see es there, only s. Are they (in current TEI

editorial praxis) mutually exclusive, or what is there relationship?

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 May 23 2005 - 18:46:20 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon May 23 18:48:40 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 24 May 2005 07:48:40 +0900
Subject: [tei-council] more on internationalization
In-Reply-To: 
Message-ID: 

From: Christian Wittern 

Date: Tue, 24 May 2005 07:48:40 +0900

Julia Flanders edu> writes:

> To identify the translators, would it be worth our posting a call on

> TEI-L, announcing the proposal and indicating that we're seeking

> translators who would be willing to contribute some time (i.e. they'd

> get paid, but probably not fully for what their time is worth)? and

> also reviewers? Or would we prefer to identify translators

> ourselves?

I think one way to proceed would to form a subcommitee (not necessary

only from the Council) for handling this and leave the details on how

to proceed to them.  However, we should define our requirements before,

e.g. what languages we want to cover etc. 

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 May 23 2005 - 18:48:44 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon May 23 19:08:46 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 24 May 2005 00:08:46 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
Message-ID: <4292627E.5070600@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Tue, 24 May 2005 00:08:46 +0100

Christian Wittern wrote:

>

>>the file teinames.xml in the Sourceforge I18N area

>>has the infrastructure ready for this to work, with some

>>Spanish translattions by Alejandro.

>>    

>>

>

>To me the file under sf/P5 looks much more complete.  

>

no, they are the same. just some formatting differences. I will

delete the one under P5

>however, I do

>not see es there, only s. Are they (in current TEI

>editorial praxis) mutually exclusive, or what is there relationship?

>  

>

a good question. no, they are not mutually exclusive,

and I think Lou and Laurent would claim to know the difference,

but I am not convinced that they are used consistently.  

is used for attributes in the way  is used for elements,

so far as I can see.

-- 
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 May 23 2005 - 19:11:42 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon May 23 19:21:12 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 24 May 2005 00:21:12 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
Message-ID: <42926568.2020904@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Tue, 24 May 2005 00:21:12 +0100

Christian Wittern wrote:

>I think one way to proceed would to form a subcommitee (not necessary

>only from the Council) for handling this and leave the details on how

>to proceed to them.  However, we should define our requirements before,

>e.g. what languages we want to cover etc. 

>

>  

>

since Alejandro did so much work already, I think it would be well

worth finishing Spanish.  I also think French should be done, for 

historical reasons.

After that, how to decide on priorities?

 * How many Danes doing text encoding cannot read English?

 * how many Bulgarians do text encoding?

 * can we ever get the encoding right for Chinese?

 * what's the best language for India?

I think we may have to be driven by who comes forward.

what's the timescale on this application, Julia?

My main worry about starting this exercise is that it provides a distraction

from P5, and is impacted by it. Since the elements and attributes for P5

are not frozen yet, is it sensible to start translating? yes, 99% of it 

will be unchanged,

but there is a management problem if we are trying to merge material into

a moving target.

Note the discussions around Ghent-time about where to store this stuff.

Back then we were thinking that the translations should be external

(as in current teinames.xml), mainly because attributes are repeated so 

much.

However, then we talked about names, and I think we mostly agreed that 

"type"

always means the same thing; but is its / the same in each 

case?

how much do we normalize the description of attributes; and if we don't, how

do we avoid translating the same text hundreds of times?

-- 
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 May 23 2005 - 19:24:25 EDT

From Laurent.Romary at loria.fr  Mon May 23 23:25:19 2005
From: Laurent.Romary at loria.fr (Laurent.Romary_at_loria.fr)
Date: Tue, 24 May 2005 05:25:19 +0200
Subject: [tei-council] more on internationalization
In-Reply-To: <42926568.2020904@computing-services.oxford.ac.uk>
Message-ID: <1116905119.42929e9f22530@www.loria.fr>

From: 

Date: Tue, 24 May 2005 05:25:19 +0200

Selon Sebastian Rahtz oxford.ac.uk>:

> since Alejandro did so much work already, I think it would be well

> worth finishing Spanish.  I also think French should be done, for

> historical reasons.

As a matter of fact, there is already a group of French colleagues who have been

working on some kind of translation activities for a few month. We have recently

made them move to consider the translation of P5 element descriptions and/or to

prepare introductory material in French. We also asked for them to consider

compiling examples that would feed  with more French looking data.

Lou should meet them when he goes to Lyon at the end of this month.

> My main worry about starting this exercise is that it provides a distraction

> from P5, and is impacted by it. Since the elements and attributes for P5

> are not frozen yet, is it sensible to start translating? yes, 99% of it

> will be unchanged,

> but there is a management problem if we are trying to merge material into

> a moving target.

I agree with this, this is why the first emergency is to have a document

planning those translation activities (list of "stable chapters", priorities,

etc.).

Laurent

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Mon May 23 2005 - 23:25:30 EDT

From Laurent.Romary at loria.fr  Tue May 24 02:45:24 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Tue, 24 May 2005 08:45:24 +0200
Subject: [tei-council] more on internationalization
In-Reply-To: <4292627E.5070600@computing-services.oxford.ac.uk>
Message-ID: <84f94aa8aa7f60c40fcd27b82be8072f@loria.fr>

From: Laurent Romary 

Date: Tue, 24 May 2005 08:45:24 +0200

It is probably a good time to state their meaning more precisely. 

Basically (and under Lou's control):

-  makes explicit the name that is encoded in the tag name 

(respStmt -> responsability statement); in a sense it provides a term 

(a noun phrase that can be used to designate the corresponding concept)

-  is the definitional field for the element. It is where a TEI 

user should find the reference information for it.

Best,

Laurent

Le 24 mai 05, ? 01:08, Sebastian Rahtz a ?crit :

>> however, I do

>> not see es there, only s. Are they (in current TEI

>> editorial praxis) mutually exclusive, or what is there relationship?

>>

> a good question. no, they are not mutually exclusive,

> and I think Lou and Laurent would claim to know the difference,

> but I am not convinced that they are used consistently.  

> is used for attributes in the way  is used for elements,

> so far as I can see.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue May 24 2005 - 02:47:38 EDT

From mjd at hum.ku.dk  Tue May 24 03:25:25 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Tue, 24 May 2005 09:25:25 +0200
Subject: [tei-council] more on internationalization
In-Reply-To: <42926568.2020904@computing-services.oxford.ac.uk>
Message-ID: <4292F305.12687.49B458@localhost>

From: M. J. Driscoll 

Date: Tue, 24 May 2005 09:25:25 +0200

> After that, how to decide on priorities?

> 

>  * How many Danes doing text encoding cannot read English? 

Probably not many, but then there aren't that many Danes 

doing text encoding. The point, though, is that just 

because people _can_ use something in a foreign language 

doesn't mean they wouldn't prefer to have it in their own, 

and the question we should rather be asking is how many 

Danes (Swedes, Germans, whatever) would be doing text 

encoding if the schemes and tools were available to them in 

their own languages. Even Microsoft's worked that one out.

*

>  how many Bulgarians do text encoding?

Any number of them, as you'll discover in October. But here 

the everybody-speaks-English-don't-they?-attitude is even 

less appropriate, since in Bulgaria, as in most of the 

world, everybody doesn't speak English (thank God), and 

shouldn't have to. Which I thought was the whole point of 

this exercise.

MJD

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue May 24 2005 - 03:24:29 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue May 24 04:09:33 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 24 May 2005 09:09:33 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: <84f94aa8aa7f60c40fcd27b82be8072f@loria.fr>
Message-ID: <4292E13D.1070805@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Tue, 24 May 2005 09:09:33 +0100

Laurent Romary wrote:

> It is probably a good time to state their meaning more precisely. 

> Basically (and under Lou's control):

> -  makes explicit the name that is encoded in the tag name 

> (respStmt -> responsability statement); in a sense it provides a term 

> (a noun phrase that can be used to designate the corresponding concept)

> -  is the definitional field for the element. It is where a TEI 

> user should find the reference information for it.

>

o  should have been used relatively rarely? it seems to have 

been (ab)used to describe  entries, eg

        indicates what kind of section is changing at this 

milestone.

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

          page breaks in the reference edition.

this should have been , right?

It won't be hard to do an analysis of  all this, but I think it

may mean some global changes.

-- 
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 May 24 2005 - 04:13:06 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue May 24 04:47:59 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 24 May 2005 09:47:59 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: <4292F305.12687.49B458@localhost>
Message-ID: <4292EA3F.5060206@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Tue, 24 May 2005 09:47:59 +0100

M. J. Driscoll wrote:

> But here 

>the everybody-speaks-English-don't-they?-attitude is even 

>less appropriate, since in Bulgaria, as in most of the 

>world, everybody doesn't speak English (thank God), and 

>shouldn't have to. Which I thought was the whole point of 

>this exercise.

>

indeed. so what is the algorithm for priorititizing languages? we can choose

between:

 1 easy to do (ie we know someone who can control the work, like Laurent 

for French or Alejandro for Spanish)

 2 number of native speakers (in which case Bahasa might be on the list)

 3 number of known interests in text encoding (er, thats hard.)

 4 perception of "importance" of language (er, thats hard too)

 5 sticking pins in a world map

to my mind, no 1 is the practical choice. no sense in picking, say, 

Korean and then

not being able to locate a good person.

if we ask the ALLC for money to try and do (say) 6 languages,

then we can ask the members first and then  TEI-L second

for bids.

-- 
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 May 24 2005 - 04:50:59 EDT

From Laurent.Romary at loria.fr  Tue May 24 05:12:18 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Tue, 24 May 2005 11:12:18 +0200
Subject: [tei-council] more on internationalization
In-Reply-To: <4292E13D.1070805@computing-services.oxford.ac.uk>
Message-ID: <818bac0274670fbfa40f08a7e013840f@loria.fr>

From: Laurent Romary 

Date: Tue, 24 May 2005 11:12:18 +0200

You got it right, Sebastian. At least we should try to use the two 

elements as consistantly as possible in future element description and 

correct mismatches progressively as we see them (that could be part of 

the chapter reviewing check list).

Laurent

Le 24 mai 05, ? 10:09, Sebastian Rahtz a ?crit :

> Laurent Romary wrote:

>

>> It is probably a good time to state their meaning more precisely. 

>> Basically (and under Lou's control):

>> -  makes explicit the name that is encoded in the tag name 

>> (respStmt -> responsability statement); in a sense it provides a term 

>> (a noun phrase that can be used to designate the corresponding 

>> concept)

>> -  is the definitional field for the element. It is where a TEI 

>> user should find the reference information for it.

>>

>

> so  should have been used relatively rarely? it seems to have 

> been (ab)used to describe  entries, eg

>

>    

>        

>        indicates what kind of section is changing at this 

> milestone.

>

>

>      

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

>      

>        

>

>          

>          page breaks in the reference edition.

>        

>        

>

>

> this should have been , right?

>

> It won't be hard to do an analysis of  all this, but I think it

> may mean some global changes.

>

> -- 

> 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 May 24 2005 - 05:13:54 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue May 24 05:14:19 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 24 May 2005 10:14:19 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: <818bac0274670fbfa40f08a7e013840f@loria.fr>
Message-ID: <4292F06B.4060301@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Tue, 24 May 2005 10:14:19 +0100

Laurent Romary wrote:

> You got it right, Sebastian. At least we should try to use the two 

> elements as consistantly as possible in future element description and 

> correct mismatches progressively as we see them (that could be part of 

> the chapter reviewing check list).

>

are chapter reviewers reading XML source, or formatted results?

-- 
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 May 24 2005 - 05:17:21 EDT

From Laurent.Romary at loria.fr  Tue May 24 05:22:09 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Tue, 24 May 2005 11:22:09 +0200
Subject: [tei-council] more on internationalization
In-Reply-To: <4292F06B.4060301@computing-services.oxford.ac.uk>
Message-ID: 

From: Laurent Romary 

Date: Tue, 24 May 2005 11:22:09 +0200

Le 24 mai 05, ? 11:14, Sebastian Rahtz a ?crit :

> Laurent Romary wrote:

>

>> You got it right, Sebastian. At least we should try to use the two 

>> elements as consistantly as possible in future element description 

>> and correct mismatches progressively as we see them (that could be 

>> part of the chapter reviewing check list).

>>

> are chapter reviewers reading XML source, or formatted results?

>

My experience with the print dictionary chapter shows that you have no 

choice: you need to go through the various files to understand 

precisely what action is to be taken for each element or class.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue May 24 2005 - 05:23:28 EDT

From Julia_Flanders at Brown.edu  Tue May 24 09:44:41 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Tue, 24 May 2005 09:44:41 -0400
Subject: [tei-council] more on internationalization
In-Reply-To: <4292EA3F.5060206@computing-services.oxford.ac.uk>
Message-ID: 

From: Julia Flanders 

Date: Tue, 24 May 2005 09:44:41 -0400

I would suggest that we make a longer list of languages in which we 

know text encoding work is being done (as determined, for instance, 

by the range of countries in which we have members), and use this as 

a master list to track our progress. That list could be cast into 

rough groups:

--highest priority: languages where there is a great deal of TEI work 

being done;

--middle priority: languages where there is some TEI work being done;

--low priority: languages where there is little or no TEI work being 

done but where we believe there is potential;

--not on the list: languages where we believe having a translation 

would not have any appreciable influence at the moment (e.g. Tlingit)

Then submit a call and see what proposals we receive. We could fund 

all the proposals in our high-priority group, and keep the others for 

a more substantial EU proposal, or a proposal to another funding 

body. Creating a master plan in this way would help us make a 

persuasive funding proposal and also provide a sense of long-term 

goals and progress.

It may be in any case that the ALLC wishes to give priority in any 

case to European languages (I can check on this with Harold). I'll 

also check on the timeline to see whether this proposal can wait 

until P5 issues have been firmed up.

best, Julia

At 9:47 AM +0100 5/24/05, Sebastian Rahtz wrote:

>M. J. Driscoll wrote:

>

>>  But here the everybody-speaks-English-don't-they?-attitude is even 

>>less appropriate, since in Bulgaria, as in most of the world, 

>>everybody doesn't speak English (thank God), and shouldn't have to. 

>>Which I thought was the whole point of this exercise.

>>

>

>indeed. so what is the algorithm for priorititizing languages? we can choose

>between:

>

>1 easy to do (ie we know someone who can control the work, like 

>Laurent for French or Alejandro for Spanish)

>2 number of native speakers (in which case Bahasa might be on the list)

>3 number of known interests in text encoding (er, thats hard.)

>4 perception of "importance" of language (er, thats hard too)

>5 sticking pins in a world map

>

>to my mind, no 1 is the practical choice. no sense in picking, say, 

>Korean and then

>not being able to locate a good person.

>

>if we ask the ALLC for money to try and do (say) 6 languages,

>then we can ask the members first and then  TEI-L second

>for bids.

>

>--

>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 May 24 2005 - 09:44:50 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue May 24 20:45:08 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 25 May 2005 09:45:08 +0900
Subject: [tei-council] more on internationalization
In-Reply-To: 
Message-ID: 

From: Christian Wittern 

Date: Wed, 25 May 2005 09:45:08 +0900

Julia Flanders edu> writes:

> I would suggest that we make a longer list of languages in which we

> know text encoding work is being done (as determined, for instance, by

> the range of countries in which we have members), and use this as a

> master list to track our progress. That list could be cast into rough

> groups:

> --highest priority: languages where there is a great deal of TEI work

>   being done;

> --middle priority: languages where there is some TEI work being done;

> --low priority: languages where there is little or no TEI work being

>   done but where we believe there is potential;

> --not on the list: languages where we believe having a translation

>   would not have any appreciable influence at the moment

>   (e.g. Tlingit)

This sounds like a good strategy, except that I think it would benefit

from trying to be a bit more foreword looking by not only assess the

current membership, but also areas where the TEI sees a potential (or

a need) to develop more.  

I can tell you from years of experience that TEI is a hard sell in

China, Taiwan and Japan -- for many reasons, but prominent among them

the perceived un-accessibility due to text and examples coming from

western languages and perceived "centeredness in a western mind-set".

So while you will probably find Chinese and Japanese at the very

bottom of the list in terms of members from countries using these

languages, it would benefit the long-term strategy of the TEI to

consider these languages for the proposal, in the case the ALLC would

consider supporting them.  One could of course always say if they are

interested, they should be looking for their own funding

opportunities, but since they are not interested...  

Another possibility would be to offer a matching-funds scheme to

extend the reach we can have with this initial grant?

>

> Then submit a call and see what proposals we receive. We could fund

> all the proposals in our high-priority group, and keep the others for

> a more substantial EU proposal, or a proposal to another funding

> body. Creating a master plan in this way would help us make a

> persuasive funding proposal and also provide a sense of long-term

> goals and progress.

If we think of approaching the EU, languages that could not possibly

supported by the EU could be given a higher priority for the ALLC

proposal. 

>

> It may be in any case that the ALLC wishes to give priority in any

> case to European languages (I can check on this with Harold). I'll

> also check on the timeline to see whether this proposal can wait until

> P5 issues have been firmed up.

I think it is quite timely for this issue to come up now, so that we

can make sure P5 supports this kind of internationalization

technically and conceptually.  Hopefully the appearance of some

translations and their apparent usefulness will then spur others to

come.  

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 May 24 2005 - 20:45:18 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed May 25 22:13:15 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 26 May 2005 11:13:15 +0900
Subject: [tei-council] TEI and ISO 639-6
Message-ID: 

From: Christian Wittern 

Date: Thu, 26 May 2005 11:13:15 +0900

Dear Council members,

A friend send me an email, which contained the following sentence,

attributed to  Debbie Garside of linguaphone ICT:

"Links to the TEI have already been established and the model that is

currently being created  for ISO 639-6 will take on board the needs of

these industries."

He asked me for further clarification and I have to admit here that I

do remember faintly that this came up once (although the link to

ethnologue does seem stronger), but I do not remember that we did

establish some formal relationship -- Can somebody help me here?

(I am a bit embarrassed with this and have thought for a while that we

need a better way to keep track of these issues -- a search interface

to the minutes and WG documents would probably be a great improvement)

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 May 25 2005 - 22:13:21 EDT

From Syd_Bauman at Brown.edu  Thu May 26 00:00:28 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 26 May 2005 00:00:28 -0400
Subject: [tei-council] TEI and ISO 639-6
In-Reply-To: 
Message-ID: <17045.18908.159191.211732@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Thu, 26 May 2005 00:00:28 -0400

I have no recollection of this at all. A search, however, reveals

that Lou posted "[Fwd: Re: Language codes]" to tei-chars on

2004-06-16 13:15+0100, to which there was only 1 reply by Martin

Duerst approx 22 hours later. This posting discusses a draft of

ISO 639-6.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu May 26 2005 - 00:00:36 EDT

From Laurent.Romary at loria.fr  Thu May 26 02:43:01 2005
From: Laurent.Romary at loria.fr (Laurent.Romary_at_loria.fr)
Date: Thu, 26 May 2005 08:43:01 +0200
Subject: [tei-council] TEI and ISO 639-6
In-Reply-To: 
Message-ID: <1117089781.42956ff576438@www.loria.fr>

From: 

Date: Thu, 26 May 2005 08:43:01 +0200

I do hope it is not related to the fact that we have regular exchanges in the

ISO framework, since I personally do not remember making the link with the TEI.

There are several ongoing projects related to further parts of ISO 639, and the

difficulties to reconcile the Ethnologue and Linguasphere groups (to simplify

the matter) would make me suggest to adopt a stand-by position regarding the

topic.

Best,

Laurent

Selon Christian Wittern zinbun.kyoto-u.ac.jp>:

>

> Dear Council members,

>

> A friend send me an email, which contained the following sentence,

> attributed to  Debbie Garside of linguaphone ICT:

>

> "Links to the TEI have already been established and the model that is

> currently being created  for ISO 639-6 will take on board the needs of

> these industries."

>

> He asked me for further clarification and I have to admit here that I

> do remember faintly that this came up once (although the link to

> ethnologue does seem stronger), but I do not remember that we did

> establish some formal relationship -- Can somebody help me here?

>

> (I am a bit embarrassed with this and have thought for a while that we

> need a better way to keep track of these issues -- a search interface

> to the minutes and WG documents would probably be a great improvement)

>

> 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

>

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu May 26 2005 - 02:43:08 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu May 26 18:56:30 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 27 May 2005 07:56:30 +0900
Subject: [tei-council] TEI and ISO 639-6
In-Reply-To: <1117089781.42956ff576438@www.loria.fr>
Message-ID: 

From: Christian Wittern 

Date: Fri, 27 May 2005 07:56:30 +0900

Laurent.Romary_at_loria.fr writes:

> I do hope it is not related to the fact that we have regular exchanges in the

> ISO framework, since I personally do not remember making the link with the TEI.

> There are several ongoing projects related to further parts of ISO 639, and the

> difficulties to reconcile the Ethnologue and Linguasphere groups (to simplify

> the matter) would make me suggest to adopt a stand-by position regarding the

> topic.

Thanks Laurent.  It thus seems that somebody tries to capitalize on a

non-existing link with the TEI.  If nothing else, it proves at least

that the TEI seems to be thought of as heavy enought to be used in

such a manouever.

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 26 2005 - 18:56:38 EDT

From lou.burnard at computing-services.oxford.ac.uk  Fri May 27 03:57:40 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 27 May 2005 08:57:40 +0100
Subject: [tei-council] TEI and ISO 639-6
In-Reply-To: 
Message-ID: <9427861c06d050a1343941826b34c172@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Fri, 27 May 2005 08:57:40 +0100

I met the lady mentioned as the source of this rumour at an ISO meeting 

somewhere last year (Jeju?  Lisbon? it's all a blur)  and had a brief 

conversation with her about the TEI's proposals on language 

identification, mentioning in particular Christian's name as the head 

of the relevant TEI  work group and the fact that we were adopting an 

ISDO multipart identifier approach. As is my wont I also doubtless made 

warm and encouraging noises about the TEI always being willing to work 

with other communities and steal those ideas which we liked. I then 

participated in a meeting of the ISO workgroup concerned (SC4/WG2 I 

think?) and witnessed at first hand the awful mess which is ISO 639-6 

at present. To my partially-informed eye, the proposals coming out of 

the Linguasphere lobby (which was heavily represented at this meeting) 

looked  inappropriate for TEI use (or any one else's really); a point 

which I made in the meeting. I was also struck by the very unseemly way 

in which the politics of the meeting were handled. So, I agree with 

Laurent, this is a can of worms we should keep our nose out of. 

(Irrelevant linguistic note for Laurent:  if you "stand by" you are 

usually holding back from action but expecting to receive orders to 

proceed at short notice: cf "back up"; I think a better idiom here 

would be that we recommend a  "stand off" or "hands off" position)

Lou (just back from Croatia and catching up on email)

On 26 May 2005, at 23:56, Christian Wittern wrote:

> Laurent.Romary_at_loria.fr writes:

>

>> I do hope it is not related to the fact that we have regular 

>> exchanges in the

>> ISO framework, since I personally do not remember making the link 

>> with the TEI.

>> There are several ongoing projects related to further parts of ISO 

>> 639, and the

>> difficulties to reconcile the Ethnologue and Linguasphere groups (to 

>> simplify

>> the matter) would make me suggest to adopt a stand-by position 

>> regarding the

>> topic.

>

> Thanks Laurent.  It thus seems that somebody tries to capitalize on a

> non-existing link with the TEI.  If nothing else, it proves at least

> that the TEI seems to be thought of as heavy enought to be used in

> such a manouever.

>

> 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

>

>

 From the Macmini at Burnard Towers

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri May 27 2005 - 04:04:10 EDT

From Syd_Bauman at Brown.edu  Sun May 29 13:51:12 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 29 May 2005 13:51:12 -0400
Subject: [tei-council] Dr. Julia
Message-ID: <17050.272.505003.743056@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sun, 29 May 2005 13:51:12 -0400

Congratulations to Julia H. Flanders, Director of the Women Writers

Project and Chair of the TEI Consortium. Julia received her Ph.D. in

English from Brown University just over half an hour ago.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun May 29 2005 - 13:51:17 EDT

From Syd_Bauman at Brown.edu  Wed Jun  1 23:54:32 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 1 Jun 2005 23:54:32 -0400
Subject: [tei-council] attributes/datatypes action item progress report
Message-ID: <17054.33528.315110.391865@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Wed, 1 Jun 2005 23:54:32 -0400

In Paris y'all tasked me with going through all TEI attributes and

attempting to classify each as a particular datatype, noting those

that are singular or for some other reason don't fall into a datatype

well, and considering what datatypes are needed, what extra

constraints are needed, etc.

I had hoped to finish going through them by today. I'm almost there.

This turns out to be an enormous task, for which I've put off several

other things (e.g., shopping for a digital camera, meeting with David

Durand about SA).

There are 541 separate attributes to be considered. Of those, I've

examined *all* 298 non-"text" attributes, and along the way an

additional 17 of the "text" ones. I had put the "text" ones off until

last because for the most part these are going to be textual

attributes that we've already considered in both EDW79 and EDW86, and

thus should be pretty easy. (Although, as I say it, I'm worried those

may be "famous last words" :-)

(BTW, I put "text" in quotes because I think that the keyword "text"

should occur in the TEI schemas only once: in the declaration of the

macro 'tei.text' (or whatever we decide to call it). In attribute

declarations the keyword "token" or "xsd:token" should be used

instead.[1] In element declarations, tei.text should be used.[2])

I plan to finish up the "text" attributes in the next day or two, and

hope to write up a report shortly thereafter.

Notes

-----

[1] The only difference between "token" and "xsd:token" is that param

    patterns can only be used to restrict the latter, not the former.

    I.e., 

    element file {

       attribute name { xsd:token { maxLength = "32" } },

       attribute type { "alias" | "folder" | "plain" },

       empty

    }

    is a valid declaration, but the same thing without "xsd:" causes

    an error.

[2] tei.text = mixed { g* }

    This is because wherever what we used to call PCDATA is allowed,

    the  element must be permitted, in case a non-Unicode

    character is required. There are some exceptions, I suppose.

    E.g., it's hard to imagine the content of  requiring

    characters outside of Unicode.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Jun 01 2005 - 23:54:39 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jun  7 15:54:41 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 07 Jun 2005 20:54:41 +0100
Subject: [tei-council] documentation for XSLT stylesheets
Message-ID: <42A5FB81.8000504@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Tue, 07 Jun 2005 20:54:41 +0100

I'd appreciate it if a few of you could test my new stylesheet documentation

at http://www.tei-c.org.uk/Stylesheets/teic/ and points south. This is

the outcome

of my work in Timor seriously restructuring the stylesheets, and I hope

the result is more useable and useful. As you'll find, there is

 1 general documentation

 2 detailed documentation of parameters you can change

 3 generated javadoc-like interface to stylesheet source

 4 stylebear web form for generating customizations.

2, 3 and 4 are generated from the documentation embedded in the

stylesheets, using xsltdoc

(for which thanks to Christian for the pointer).

-- 
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 Jun 07 2005 - 15:54:47 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Jun  7 18:52:19 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 08 Jun 2005 07:52:19 +0900
Subject: [tei-council] documentation for XSLT stylesheets
In-Reply-To: <42A5FB81.8000504@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Wed, 08 Jun 2005 07:52:19 +0900

Sebastian Rahtz oxford.ac.uk> writes:

> I'd appreciate it if a few of you could test my new stylesheet documentation

> at http://www.tei-c.org.uk/Stylesheets/teic/ and points south. This is

> the outcome

> of my work in Timor seriously restructuring the stylesheets, and I hope

> the result is more useable and useful. 

Very glad to see you back here:-)

I would definitely say so, this looks like a big improvement over what

we had before.  The organization and presentation of the material also

looks pretty understandable -- I will have to test it more thoroughly

next time when I try to use the new stylesheets:-)  

The template listing is particularily welcome , which makes the whole

thing a lot easier to navigate.  One thing though, the links from

there do not seem to work: They do have a #foobar anchor link, but

this does not seem to correspond to the one used in the target page,

so all links end up at the top of the page.

Anyway, thanks a lot for your efforts in this area,

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 07 2005 - 18:52:29 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jun  8 01:58:59 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 08 Jun 2005 06:58:59 +0100
Subject: [tei-council] documentation for XSLT stylesheets
In-Reply-To: 
Message-ID: <42A68923.2030205@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Wed, 08 Jun 2005 06:58:59 +0100

Christian Wittern wrote:

>The template listing is particularily welcome , which makes the whole

>thing a lot easier to navigate.  One thing though, the links from

>there do not seem to work: They do have a #foobar anchor link, but

>this does not seem to correspond to the one used in the target page,

>so all links end up at the top of the page.

>  

>

can you me more precise? I cant see what you mean.

-- 
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 Jun 08 2005 - 01:59:11 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jun  8 03:05:16 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 08 Jun 2005 16:05:16 +0900
Subject: [tei-council] documentation for XSLT stylesheets
In-Reply-To: <42A68923.2030205@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Wed, 08 Jun 2005 16:05:16 +0900

Sebastian Rahtz oxford.ac.uk> writes:

> Christian Wittern wrote:

>

>>The template listing is particularily welcome , which makes the whole

>>thing a lot easier to navigate.  One thing though, the links from

>>there do not seem to work: They do have a #foobar anchor link, but

>>this does not seem to correspond to the one used in the target page,

>>so all links end up at the top of the page.

>>  

>>

>

> can you me more precise? I cant see what you mean.

Sure.  I am on the Functions/Templates list page at 

http://www.tei-c.org.uk/Stylesheets/teic/xsltdoc/functionTemplateList.html

Now, let say I want to inspect the "addID" template in [fo], the third

in this list.  The link on this page is to

http://www.tei-c.org.uk/Stylesheets/teic/xsltdoc/common/tei-param.xsl.xd.html#d94e1698

but if I click there, I am taken to the top of the page 

http://www.tei-c.org.uk/Stylesheets/teic/xsltdoc/common/tei-param.xsl.xd.html

as it turns out, there does not seem to be something about "addID" on

this page at all.  The same is also true for the few other things I

clicked on on this page.

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 Jun 08 2005 - 03:05:22 EDT

From James.Cummings at computing-services.oxford.ac.uk  Wed Jun  8 04:37:36 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 08 Jun 2005 09:37:36 +0100
Subject: [tei-council] documentation for XSLT stylesheets
In-Reply-To: 
Message-ID: <42A6AE50.5030206@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Wed, 08 Jun 2005 09:37:36 +0100

Christian Wittern wrote:

> as it turns out, there does not seem to be something about "addID" on

> this page at all.  The same is also true for the few other things I

> clicked on on this page.

I think that is the problem, because some of the other ones I tried worked fine.

-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 Jun 08 2005 - 04:38:01 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jun  8 11:23:21 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 08 Jun 2005 16:23:21 +0100
Subject: [tei-council] documentation for XSLT stylesheets
In-Reply-To: 
Message-ID: <42A70D69.9090000@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Wed, 08 Jun 2005 16:23:21 +0100

>http://www.tei-c.org.uk/Stylesheets/teic/xsltdoc/functionTemplateList.html

>

>Now, let say I want to inspect the "addID" template in [fo], the third

>in this list.  The link on this page is to

>

>http://www.tei-c.org.uk/Stylesheets/teic/xsltdoc/common/tei-param.xsl.xd.html#d94e1698

>

>but if I click there, I am taken to the top of the page 

>

>http://www.tei-c.org.uk/Stylesheets/teic/xsltdoc/common/tei-param.xsl.xd.html

>

>as it turns out, there does not seem to be something about "addID" on

>this page at all. 

>  

>

hmm. now I see what you mean. This is a bug in the xsltdoc stuff. I'll

see what I can 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 Wed Jun 08 2005 - 11:23:25 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Jun 10 04:14:57 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 10 Jun 2005 17:14:57 +0900
Subject: [tei-council] Excuse from Council duties for Edward Vanhoutte
Message-ID: 

From: Christian Wittern 

Date: Fri, 10 Jun 2005 17:14:57 +0900

Dear Council members,

Edward has asked to be excused from his duties to the TEI Council

until the end of the year -- he said he needs the time to write up his

PhD thesis.  Fortunately, though, part of his thesis will focus on

issues relevant to chap. 18 and 19:

He writes:

> A critical evaluation of the TEI options for scholarly editing (ch. 18

> & 19) is planned for the third and last section of my thesis, which

> should be written in October-November.

So we will count on this as a contribution to P5 (and review of PH and

TC)!

As for his other responsibilities:

> So, if it's possible, I'd like to be ecxused from any formal

> responsibilities I've taken on. This is the study of the certainty

> issue in the TEI encoding and the review of chapters PH, TC, PR.

If I am not mistaken, we need thus mainly help with the review of the

one-page-chapter 8, PR.

Best wishes to Edward for a successful writing session!

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 10 2005 - 04:15:16 EDT

From lou.burnard at computing-services.oxford.ac.uk  Sat Jun 11 10:50:16 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 11 Jun 2005 15:50:16 +0100
Subject: [tei-council] Further ruminations on index
Message-ID: <42AAFA28.6030202@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Sat, 11 Jun 2005 15:50:16 +0100

In response to Michael Beddow's comments on the proposed revision for 

the  element, I have now redrafted the section in question, but  

in the process, I hit on two other questions on which Council's opinions 

would be much appreciated:

a) the  element, used to mark the point where a  div typically 

containing an index or toc is to be generated, currently has no way of 

specifying headers or footers for the generated div, other than by the 

use of the global n attribute. That overloading seems to be inadequate, 

as well as potentially falling foul of all the other known problems 

inherent in text-valued attributes.  I therefore propose to change the 

content of divGen from  "empty" to  "zero-or-more elements from the 

tei.divtop class". Any objections/counter suggestions?

b) the  element currently has a close relative called  

which is used when the indexed point is a span. The only difference 

between the two is that the latter has an additional attribute "to" 

which indicates the end of the  span. It seems to me that this is a 

rather cumbersome method of doing the job. Furthermore, since  

(and therefore ) can now be nested recursively, the content 

model gets a little complicated. It occurs to me that we could simplify 

matters by (a) removing  (b) defining an attribute "scope" or 

"range" or even "target" on  with a default value of "here" but 

with the option to include any URL.

If you share my view that this might be a good idea, bear in mind that 

we will need to do the same thing for all the other xxxSpan elements 

(,  etc.) , which is partly why I have not implemented 

it yet.  What do you think?

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sat Jun 11 2005 - 10:55:38 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jun 12 06:32:30 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 12 Jun 2005 11:32:30 +0100
Subject: [tei-council] Further ruminations on index
In-Reply-To: <42AAFA28.6030202@computing-services.oxford.ac.uk>
Message-ID: <42AC0F3E.6010404@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 12 Jun 2005 11:32:30 +0100

Lou Burnard wrote:

> a) the  element, used to mark the point where a  div typically

> containing an index or toc is to be generated, currently has no way of

> specifying headers or footers for the generated div, other than by the

> use of the global n attribute. That overloading seems to be

> inadequate, as well as potentially falling foul of all the other known

> problems inherent in text-valued attributes.  I therefore propose to

> change the content of divGen from  "empty" to  "zero-or-more elements

> from the tei.divtop class". Any objections/counter suggestions?

It strikes me as a cleaner way to proceed. Speaking as an implementor,

it would make my life easier not having

to maintain a separate place where the heading is specified

>

> b) the  element currently has a close relative called

>  which is used when the indexed point is a span. The only

> difference between the two is that the latter has an additional

> attribute "to" which indicates the end of the  span. It seems to me

> that this is a rather cumbersome method of doing the job. Furthermore,

> since  (and therefore ) can now be nested

> recursively, the content model gets a little complicated. It occurs to

> me that we could simplify matters by (a) removing  (b)

> defining an attribute "scope" or "range" or even "target" on 

> with a default value of "here" but with the option to include any URL.

I seem to recall suggesting the same thing a few months back when this

came up before, so I like 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 Jun 12 2005 - 06:32:49 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jun 18 07:45:36 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 18 Jun 2005 12:45:36 +0100
Subject: [tei-council] tei skeletons
Message-ID: <42B40960.8030601@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sat, 18 Jun 2005 12:45:36 +0100

no, not the ones in cupboards, the ones you load in your editor to start

off a new document.

I want to make a collection of these (in P5) as a Debian package, and to

make ready for Emacs and oXygen.

I have a simple one for vanilla TEI, but would like suggestions for

others, probably with associated schemas.

Ideas? contributions? bad plan?

-- 
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 Jun 18 2005 - 07:45:44 EDT

From Laurent.Romary at loria.fr  Sat Jun 18 07:59:19 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Sat, 18 Jun 2005 13:59:19 +0200
Subject: [tei-council] tei skeletons
In-Reply-To: <42B40960.8030601@computing-services.oxford.ac.uk>
Message-ID: <9f2e970be069a18c9a6ed10e1d23ea10@loria.fr>

From: Laurent Romary 

Date: Sat, 18 Jun 2005 13:59:19 +0200

Hi Seb,

Do you mean something like this (for a dictionary)? :

                 ...

                 ...

                     ..

                     ...

                 ...

Le 18 juin 05, ? 13:45, Sebastian Rahtz a ?crit :

> no, not the ones in cupboards, the ones you load in your editor to 

> start

> off a new document.

>

> I want to make a collection of these (in P5) as a Debian package, and 

> to

> make ready for Emacs and oXygen.

> I have a simple one for vanilla TEI, but would like suggestions for

> others, probably with associated schemas.

>

> Ideas? contributions? bad plan?

>

> -- 

> 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 Sat Jun 18 2005 - 07:59:37 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jun 18 08:13:02 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 18 Jun 2005 13:13:02 +0100
Subject: [tei-council] tei skeletons
In-Reply-To: <9f2e970be069a18c9a6ed10e1d23ea10@loria.fr>
Message-ID: <42B40FCE.6060802@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sat, 18 Jun 2005 13:13:02 +0100

yes, precisely. what is the corresponding ODD?

-- 
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 Jun 18 2005 - 08:13:19 EDT

From Laurent.Romary at loria.fr  Sat Jun 18 08:30:46 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Sat, 18 Jun 2005 14:30:46 +0200
Subject: [tei-council] tei skeletons
In-Reply-To: <42B40FCE.6060802@computing-services.oxford.ac.uk>
Message-ID: 

From: Laurent Romary 

Date: Sat, 18 Jun 2005 14:30:46 +0200

The ODD is the standard print dictionary chapter specification. Is 

there a need to provide something more specific (like requiring at 

least one entry within a div)?

Le 18 juin 05, ? 14:13, Sebastian Rahtz a ?crit :

> yes, precisely. what is the corresponding ODD?

>

> -- 

> 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 Jun 18 2005 - 08:30:48 EDT

From lou.burnard at computing-services.oxford.ac.uk  Sat Jun 18 09:10:34 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 18 Jun 2005 14:10:34 +0100
Subject: [tei-council] tei skeletons
In-Reply-To: <42B40960.8030601@computing-services.oxford.ac.uk>
Message-ID: <42B41D4A.3080209@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Sat, 18 Jun 2005 14:10:34 +0100

Sebastian Rahtz wrote:

>no, not the ones in cupboards, the ones you load in your editor to start

>off a new document.

>

>I want to make a collection of these (in P5) as a Debian package, and to

>make ready for Emacs and oXygen.

>I have a simple one for vanilla TEI, but would like suggestions for

>others, probably with associated schemas.

>

>Ideas? contributions? bad plan?

>

>  

>

One for a manuscript description would be useful, I think. Matthew?

L

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sat Jun 18 2005 - 09:14:54 EDT

From James.Cummings at computing-services.oxford.ac.uk  Sat Jun 18 11:16:38 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sat, 18 Jun 2005 08:16:38 -0700
Subject: [tei-council] tei skeletons
In-Reply-To: <42B41D4A.3080209@computing-services.oxford.ac.uk>
Message-ID: <42B43AD6.1050808@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Sat, 18 Jun 2005 08:16:38 -0700

Lou Burnard wrote:

> Sebastian Rahtz wrote:

> 

>> no, not the ones in cupboards, the ones you load in your editor to start

>> off a new document.

>>

>> I want to make a collection of these (in P5) as a Debian package, and to

>> make ready for Emacs and oXygen.

>> I have a simple one for vanilla TEI, but would like suggestions for

>> others, probably with associated schemas.

>>

>> Ideas? contributions? bad plan?

>>

>>  

>>

> One for a manuscript description would be useful, I think. Matthew?

Since it involves a change of root element, a teiCorpus one might be a 

good example.  It could be a longer one also including a blank 

 element in the header, maybe example langUsage and category, 

and then more than one TEI element with some basic linguistic tagging 

in it?  Sort of a start your own linguistic corpus skeleton?

-James

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sat Jun 18 2005 - 11:16:38 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jun 18 18:47:14 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 18 Jun 2005 23:47:14 +0100
Subject: [tei-council] tei skeletons
In-Reply-To: <42B43AD6.1050808@computing-services.oxford.ac.uk>
Message-ID: <42B4A472.2030704@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sat, 18 Jun 2005 23:47:14 +0100

James Cummings wrote:

>

> Since it involves a change of root element, a teiCorpus one might be a

> good example.  It could be a longer one also including a blank

>  element in the header, maybe example langUsage and category,

> and then more than one TEI element with some basic linguistic tagging

> in it?  Sort of a start your own linguistic corpus skeleton?

this is out of my territory. can you supply?

-- 
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 Jun 18 2005 - 18:47:35 EDT

From James.Cummings at computing-services.oxford.ac.uk  Sat Jun 18 20:03:28 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sat, 18 Jun 2005 17:03:28 -0700
Subject: [tei-council] tei skeletons
In-Reply-To: <42B4A472.2030704@computing-services.oxford.ac.uk>
Message-ID: <42B4B650.5050005@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Sat, 18 Jun 2005 17:03:28 -0700

Sebastian Rahtz wrote:

> James Cummings wrote:

> 

> 

>>Since it involves a change of root element, a teiCorpus one might be a

>>good example.  It could be a longer one also including a blank

>> element in the header, maybe example langUsage and category,

>>and then more than one TEI element with some basic linguistic tagging

>>in it?  Sort of a start your own linguistic corpus skeleton?

> 

> 

> this is out of my territory. can you supply?

> 

I am happy to do so, though (as lou comments privately) on reflection 

most people editing Corpora probably don't do so as a teiCorpus 

document to begin with, and so maybe a skeleton is a bit silly.  But, 

I might argue, it would act as a reminder that one could do so.  If it 

was just very basic and didn't include langUsage, category etc.  but 

just the basic structural divisions, then it is just a reiteration of 

the basic template so I'm not sure if it is very helpful.

But I'm supposed to be listening to Ian Lancashire, so just append the 

basic structural version here.  If others think doing one with 

examples of basic corpus elements would be useful, then I'm happy to 

do so.  (Though really just more example texts seem better)

-James

-----

                 ...

                 ...

                 ...

                 ...

                     ...

                     ...

                     ...

                     ...

                     ...

                     ...

                     ...

                     ...

                     ...

                     ...

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sat Jun 18 2005 - 20:03:28 EDT

From Julia_Flanders at brown.edu  Mon Jun 20 23:56:32 2005
From: Julia_Flanders at brown.edu (Julia Flanders)
Date: Mon, 20 Jun 2005 23:56:32 -0400
Subject: [tei-council] help with certainty?
Message-ID: <42B78FF0.10700@brown.edu>

From: Julia Flanders 

Date: Mon, 20 Jun 2005 23:56:32 -0400

Edward Vanhoutte has had to withdraw from working on the certainty 

issue, and I'm wondering whether any other member of the TEI council has 

a secret hankering to work on this issue with me. If not I can take a 

stab on my own, but would welcome a co-investigator.

Best, Julia

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Mon Jun 20 2005 - 23:56:35 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jun 22 22:23:10 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 23 Jun 2005 11:23:10 +0900
Subject: [tei-council] preparing for next council call
Message-ID: 

From: Christian Wittern 

Date: Thu, 23 Jun 2005 11:23:10 +0900

Dear Council members,

In the midst of the rainy season, Kyoto is dump, hot and almost

unbearable, especially after the paradise-like athmosphere of British

Columbia.  

If my memory serves me right (unlikely as that might seem under these

conditions), we agreed to hold the next conference on July 8, 1300

UTC, although the minutes of our Paris meeting at

http://www.tei-c.org.uk/Council/tcm17.xml?style=printable are silent

about that.

In preparation for this, I would like to ask everybody to look at the

minutes, especially at the action items and, in the spirit of item 10

on that list, please report on the progress here to this list *prior*

to the call. 

In addition to that, "Input for TEI P5: a summary" at

http://www.tei-c.org.uk/Drafts/edw83.xml does mention a few additional

assigments of chapters, but we have failed to track the progress.  I

dont see mentioned the assignment of "11 Transcriptions of Speech" to

Thomas Schmidt, Hamburg -- this is based on information by Andreas

Witt -- does it have any substance?

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 Jun 22 2005 - 22:23:15 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Thu Jun 23 03:44:16 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Thu, 23 Jun 2005 08:44:16 +0100 (BST)
Subject: [tei-council] preparing for next council call
In-Reply-To: 
Message-ID: <20050623074416.1F20E2DE1F@webmail217.herald.ox.ac.uk>

From: Sebastian Rahtz 

Date: Thu, 23 Jun 2005 08:44:16 +0100 (BST)

 ('binary' encoding is not supported, stored as-is)
> If my memory serves me right (unlikely as that might seem under these

> conditions), we agreed to hold the next conference on July 8, 1300

> UTC

I am not sure if I can make this, as I am at a conference

in Manchester. I won't know until I get there whether I'll

be able to get to a useable phone. Maybe, maybe not.

I think we should make some firm decisions about 

the translation proposal at this meeting.

Did you know that http://tei.oucs.ox.ac.uk/Roma/ produces

HTML documentation for your schema now? PDF, not quite yet,

it does not want to run LaTeX...

-- 
Sebastian Rahtz    
Oxford University Computing Services
& JISC Open Source Advisory Service
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Jun 23 2005 - 03:44:28 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Thu Jun 23 18:07:48 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Thu, 23 Jun 2005 23:07:48 +0100
Subject: [tei-council] roma and documentation and I18N
Message-ID: <42BB32B4.8040202@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Thu, 23 Jun 2005 23:07:48 +0100

I have just reengineered the way Roma does internationalization, and the

way it does documentation.

The result should be closer to what one would expect. If you now visit

http://tei.oucs.ox.ac.uk/Roma/,

make a customization, change the language, and request HTML

documentation, you will see what

I mean. Schemas will also now pick up translated  strings, so

they'll then appear in eg oXygen.

What was the change, you ask? I now run the I18N process _after_ making

an ODD2ODD expansion

of the original ODD. It simplifies things a lot.

-- 
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 Jun 23 2005 - 18:08:38 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Jun 26 07:15:15 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 26 Jun 2005 20:15:15 +0900
Subject: [tei-council] Re: roma, documentation, i18n
In-Reply-To: <42BBD6E2.5040302@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Sun, 26 Jun 2005 20:15:15 +0900

Sebastian, Council members,

Sebastian and I are discussing proposals for how to maintain

translations of  and  elements.  

Sebastian Rahtz oxford.ac.uk> writes:

> Christian Wittern wrote:

>

>>One way would be to allow multiple  and  elements in the

>>ODD, but it would be difficult to maintain, I guess.

>>  

>>

> its possible, I suppose.

>

> I think we should discuss this by email, decide on a plan,

> and ratify it at the council phone call

My stab at this would be to maintain the stuff in a stripped down ODD

file, one per target language, which has a  for each

element, in change mode and the only change is to provide the 

or  elements in the target language.  You could easily generate

such a beast and pull in the current english one for reference, if

desired.

These files should then be kept on SF in the I18N module. Does that

sound doable?  Or are there any better ideas?

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 Jun 26 2005 - 07:15:11 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jun 26 09:40:36 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 14:40:36 +0100
Subject: [tei-council] Re: roma, documentation, i18n
In-Reply-To: 
Message-ID: <42BEB054.2080705@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 26 Jun 2005 14:40:36 +0100

Christian Wittern wrote:

>My stab at this would be to maintain the stuff in a stripped down ODD

>file, one per target language, which has a  for each

>element, in change mode and the only change is to provide the 

>or  elements in the target language.  You could easily generate

>such a beast and pull in the current english one for reference, if

>desired.

>  

>

this coincides nicely with a conversation I had with Lou on Friday,

where we came to the same conclusion. One advantage is that

if the changes are written as a genuine ODD file, the person

working on it can generate test schemas and documentation locally.

However, for general use, we periodically merge all the separate I18N

files into the main P5 source, and enhance the processors to

do the right thing with multple  and 

>These files should then be kept on SF in the I18N module. 

>  

>

yes, this sounds good, to let someone else pick up just the translations

and work

on them.

of course, we have the perpetual problem that when a new element is added,

or the  is altered in the English original, we have to bring all

the translations

into sync.

dont forget attributes, and vallists, by the way

-- 
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 Jun 26 2005 - 09:41:43 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jun 26 14:04:56 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 19:04:56 +0100
Subject: [tei-council] another agenda item
Message-ID: <42BEEE48.4030308@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 26 Jun 2005 19:04:56 +0100

I'd like us to re-discuss, albeit at not too much length,

the schema by which P5 gets "released" to the public.

At present, there are the following ways in which a change

gets pushed out:

 1 on Sourceforge, in CVS. any one monitoring CVS gets the gory fixes,

which are not even guarenteed to be internally consistent

 2 on Sourceforge, as file releases. these are zip files containing the

P5 materials in a supposedly runtime tree structure

 3 on the TEI web site, in the form of the HTML version of the Guidelines

 4 on the web, as the eXist database behind Roma, also used for the

/Query/tag.xq?name=foo interface;

   noting that Roma conceptually lives on both tei.oucs.ox.ac.uk and on

tei-c.org.uk, which can be kept apart

 5 in Debian packages

 6 bundled in TEI Emacs

 7 in TEI Knoppix CDs and DVDs

of these, only the first and second are clear; #1 happens when anyone

makes a change; and #2 happens

when the Council authorizes a new numbered release. The others happen

currently at mostly my whim,

and sometimes at Lou's whim.  This isn't right, and I do admit that its

quite largely my fault.

I think we should have clearer rules on what triggers any of these

releases

(since only #1 is really a Release").

If someone would like to write down a set of rules, and the Council

agrees to them,

I promise to abide by them in future....

-- 
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 Jun 26 2005 - 14:06:17 EDT

From Syd_Bauman at Brown.edu  Sun Jun 26 16:18:08 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 26 Jun 2005 16:18:08 -0400
Subject: [tei-council] another agenda item
In-Reply-To: <42BEEE48.4030308@computing-services.oxford.ac.uk>
Message-ID: <17087.3456.464155.297244@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sun, 26 Jun 2005 16:18:08 -0400

>  1. on Sourceforge, in CVS. any one monitoring CVS gets the gory

>     fixes, which are not even guarenteed to be internally consistent

>  2. on Sourceforge, as file releases. these are zip files containing the

>     P5 materials in a supposedly runtime tree structure

>  3. on the TEI web site, in the form of the HTML version of the Guidelines

>  4. on the web, as the eXist database behind Roma, also used for

>     the /Query/tag.xq?name=foo interface; noting that Roma

>     conceptually lives on both tei.oucs.ox.ac.uk and on tei-c.org.uk,

>     which can be kept apart

>  5. in Debian packages

>  6. bundled in TEI Emacs

>  7. in TEI Knoppix CDs and DVDs

> of these, only the first and second are clear; #1 happens when

> anyone makes a change; and #2 happens when the Council authorizes a

> new numbered release.

One thing missing here is the issue of where bug fixes fit in. It makes 

sense for the editors to be able to push out file releases of this sort 

without pestering the Council.

We also haven't distinguish between the fairly frequent "releases"

that happen as we make minor updates (especially within the

development process) and the more formal increments (e.g. P5.1, P6,

etc.). It seems to me that the Council should be directly involved in

the major updates (e.g., new chapter, significant change to class

system, etc.), and not involved in the minor development updates or

bug-fix updates. Not so sure about the intermediate ones.

> (since only #1 is really a Release").

I don't think #1 is a release -- it's the current work repository. #2

is the only thing that is really a "release" at the moment. What is

lacking is an agreement on what should trigger a new file release in

Sourceforge (i.e., a new #2). I'd propose that in this pre-release

protion of P5's lifecycle, pretty much any significant change

(including bug fixes) that results in a self-consistent, self-

validating, working version of the Guidelines should trigger a new

release on Sourceforge. 

Whether or not Council should be directly involved in this triggering

is an open question in my mind. I'm inclined to say no for small

things, yes for larger things, and just to trust the editors'

judgement as to what's small and what's large.

Personally I would like to see 3 & 4 follow 2 fairly quickly; i.e.,

shortly (hopefully measured in minutes to hours) after a new

Sourceforge file release is made available, that version is

propagated to the TEI website, both as HTML and in the eXist

database.

I presume that our build process all but requires that 5 follow 1. As

for 6 & 7 these are "products" of your making, and it seems to me you

get to decide what version of the pre-release of P5 they use.

Personally I'd be inclined to have them follow #2, also, but at

whatever pace you determine.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Jun 26 2005 - 16:18:13 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jun 26 16:27:43 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 21:27:43 +0100
Subject: [tei-council] another agenda item
In-Reply-To: <17087.3456.464155.297244@emt.wwp.brown.edu>
Message-ID: <42BF0FBF.8080300@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 26 Jun 2005 21:27:43 +0100

Syd Bauman wrote:

>One thing missing here is the issue of where bug fixes fit in. It makes 

>sense for the editors to be able to push out file releases of this sort 

>without pestering the Council.

>  

>

yes; it needs  articulating what a "release" is. I think the council

should approve release 1.0 and 1.1, but that the editors can release

1.1.1 and 1.1.2

>We also haven't distinguish between the fairly frequent "releases"

>that happen as we make minor updates (especially within the

>development process) and the more formal increments (e.g. P5.1, P6,

>etc.). It seems to me that the Council should be directly involved in

>the major updates (e.g., new chapter, significant change to class

>system, etc.), and not involved in the minor development updates or

>bug-fix updates. Not so sure about the intermediate ones.

>  

>

I agree. It's just slightly hard to be sure how to classify some changes

>

>>(since only #1 is really a Release").

>>    

>>

>

>I don't think #1 is a release -- it's the current work repository. #2

>is the only thing that is really a "release" at the moment

>

yes, my typo. I meant "#2"

>I'd propose that in this pre-release

>protion of P5's lifecycle, pretty much any significant change

>(including bug fixes) that results in a self-consistent, self-

>validating, working version of the Guidelines should trigger a new

>release on Sourceforge. 

>  

>

I could buy that. If its OK that this could happen every week or two

at times.

>Personally I would like to see 3 & 4 follow 2 fairly quickly; i.e.,

>shortly (hopefully measured in minutes to hours) after a new

>Sourceforge file release is made available, that version is

>propagated to the TEI website, both as HTML and in the eXist

>database.

>  

>

agreed.  they need much better automation

>I presume that our build process all but requires that 5 follow 1.

>

not sure I follow that? can you expand?

-- 
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 Jun 26 2005 - 16:28:55 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jun 26 16:39:00 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 21:39:00 +0100
Subject: [tei-council] exemplars
Message-ID: <42BF1264.7060407@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 26 Jun 2005 21:39:00 +0100

Further to the "skeletons" thread, I have created 10 exemplars of TEI P5

use; currently available as a Debian package (tei-p5-exemplars)

and in CVS as P5/Exemplars. They comprise an ODD specification, and a

skeleton XML file;

the ODD is expanded to DTD/XSD/RNG/RNC in the Debian package, of

course.  These files are called

up Emacs, for examples, when you ask to create a "TEI for Drama" file;

it would be easy to imagine them

in oXygen doing the same thing.

I make no great claims for the excellence of these creatures, and will

not be at all offended

if people say "throw them all away and use these ones instead". but I do

think the idea is

important, and I'd be keen to get someone else working on them.

(blame Lou for the name, by the way)

-- 
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 Jun 26 2005 - 16:40:32 EDT

From Syd_Bauman at Brown.edu  Sun Jun 26 16:42:58 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 26 Jun 2005 16:42:58 -0400
Subject: [tei-council] which version of the stylesheets?
Message-ID: <17087.4946.143837.806952@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sun, 26 Jun 2005 16:42:58 -0400

If I'm being an idiot I apologize in advance and blame the weather

for my inability to think. But is there any easy way to ascertain

which version of Sebastian's stylesheets are bundled with oXygen 6.0?

Is it really version 2.1 (which is the highest number associated with

the word "version" when I grep for it)? Is there some documentation I

should have read that would have told me?

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Jun 26 2005 - 16:43:02 EDT

From James.Cummings at computing-services.oxford.ac.uk  Sun Jun 26 16:50:31 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 26 Jun 2005 21:50:31 +0100
Subject: [tei-council] exemplars
In-Reply-To: <42BF1264.7060407@computing-services.oxford.ac.uk>
Message-ID: <42BF1517.7090509@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Sun, 26 Jun 2005 21:50:31 +0100

Sebastian Rahtz wrote:

> the ODD is expanded to DTD/XSD/RNG/RNC in the Debian package, of

> course.  These files are called

Is there are reason why the odd files should be included btw? 

Shouldn't there be examples of odd files as well?  Or are these in 

another package?

-James

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Jun 26 2005 - 16:50:42 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jun 26 16:53:03 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 21:53:03 +0100
Subject: [tei-council] which version of the stylesheets?
In-Reply-To: <17087.4946.143837.806952@emt.wwp.brown.edu>
Message-ID: <42BF15AF.5050308@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 26 Jun 2005 21:53:03 +0100

For the record, only version 5.0.9 onwards is supported by the author...

-- 
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 Jun 26 2005 - 16:54:16 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jun 26 16:55:09 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 21:55:09 +0100
Subject: [tei-council] exemplars
In-Reply-To: <42BF1517.7090509@computing-services.oxford.ac.uk>
Message-ID: <42BF162D.3040105@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 26 Jun 2005 21:55:09 +0100

James Cummings wrote:

> Sebastian Rahtz wrote:

>

>> the ODD is expanded to DTD/XSD/RNG/RNC in the Debian package, of

>> course.  These files are called

>

>

> Is there are reason why the odd files should be included btw?

> Shouldn't there be examples of odd files as well?  Or are these in

> another package?

my packaging error, sorry.

before I go to fix it, what do you think the right location is?

-- 
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 Jun 26 2005 - 16:56:21 EDT

From James.Cummings at computing-services.oxford.ac.uk  Sun Jun 26 17:03:26 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 26 Jun 2005 22:03:26 +0100
Subject: [tei-council] exemplars
In-Reply-To: <42BF162D.3040105@computing-services.oxford.ac.uk>
Message-ID: <42BF181E.6000501@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Sun, 26 Jun 2005 22:03:26 +0100

Sebastian Rahtz wrote:

> James Cummings wrote:

> 

> 

>>Sebastian Rahtz wrote:

>>

>>

>>>the ODD is expanded to DTD/XSD/RNG/RNC in the Debian package, of

>>>course.  These files are called

>>

>>

>>Is there are reason why the odd files should be included btw?

>>Shouldn't there be examples of odd files as well?  Or are these in

>>another package?

> 

> 

> my packaging error, sorry.

> 

> before I go to fix it, what do you think the right location is?

Good question.  /usr/share/xml/tei/schema/odds/ ?

or /usr/share/doc/tei/odds/ ?

-James

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Jun 26 2005 - 17:03:28 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jun 26 17:21:21 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 22:21:21 +0100
Subject: [tei-council] exemplars
In-Reply-To: <42BF181E.6000501@computing-services.oxford.ac.uk>
Message-ID: <42BF1C51.8040009@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 26 Jun 2005 22:21:21 +0100

James Cummings wrote:

>

> Good question.  /usr/share/xml/tei/schema/odds/ ?

> or /usr/share/doc/tei/odds/ ?

I'm inclining to the former

-- 
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 Jun 26 2005 - 17:22:34 EDT

From Syd_Bauman at Brown.edu  Sun Jun 26 17:41:51 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 26 Jun 2005 17:41:51 -0400
Subject: [tei-council] exemplars
In-Reply-To: <42BF1C51.8040009@computing-services.oxford.ac.uk>
Message-ID: <17087.8479.882119.785101@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sun, 26 Jun 2005 17:41:51 -0400

> > Good question.  /usr/share/xml/tei/schema/odds/ ?

> > or /usr/share/doc/tei/odds/ ?

> 

> I'm inclining to the former

I don't think of an ODD as a schema; perhaps it's a schema

description, but not a schema.

I think I'd lean towards

  /usr/share/xml/tei/odds/

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Jun 26 2005 - 17:41:56 EDT

From Syd_Bauman at Brown.edu  Sun Jun 26 17:59:39 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 26 Jun 2005 17:59:39 -0400
Subject: [tei-council] Re: which version of the stylesheets?
In-Reply-To: <42BF17A9.3090708@oxygenxml.com>
Message-ID: <17087.9547.440952.184705@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sun, 26 Jun 2005 17:59:39 -0400

> Help->About->Components -- Frameworks -- TEI XSL. It is 2.1.

Right! Thank you. Yes, and I notice something I've mentioned before

as a problem -- that the version of the TEI DTDs is listed as "P4",

whereas it really should be more precise: P4:2004-07.

Sebastian -- is version 2.1 still available anywhere?

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Jun 26 2005 - 17:59:44 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jun 26 18:04:16 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 23:04:16 +0100
Subject: [tei-council] Re: which version of the stylesheets?
In-Reply-To: <17087.9547.440952.184705@emt.wwp.brown.edu>
Message-ID: <42BF2660.6010109@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 26 Jun 2005 23:04:16 +0100

Syd Bauman wrote:

>>Help->About->Components -- Frameworks -- TEI XSL. It is 2.1.

>>    

>>

>

>Right! Thank you. Yes, and I notice something I've mentioned before

>as a problem -- that the version of the TEI DTDs is listed as "P4",

>whereas it really should be more precise: P4:2004-07.

>

>Sebastian -- is version 2.1 still available anywhere?

>

>  

>

Deep in Perforce, somewhere. Issued 2003-09-17, so thats

prehistory.

-- 
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 Jun 26 2005 - 18:05:29 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Jun 26 18:37:43 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 27 Jun 2005 07:37:43 +0900
Subject: [tei-council] Re: roma, documentation, i18n
In-Reply-To: <42BEB054.2080705@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Mon, 27 Jun 2005 07:37:43 +0900

Sebastian Rahtz oxford.ac.uk> writes:

>>

> this coincides nicely with a conversation I had with Lou on Friday,

> where we came to the same conclusion. One advantage is that

> if the changes are written as a genuine ODD file, the person

> working on it can generate test schemas and documentation locally.

> However, for general use, we periodically merge all the separate I18N

> files into the main P5 source, and enhance the processors to

> do the right thing with multple  and 

What would be the advantage of pulling this into the main P5 source?

I see only added maintainance cost with no real benefit.  You could as

easily pull them out and merge them into the tree on runtime.

>

>>These files should then be kept on SF in the I18N module. 

>>  

>>

> yes, this sounds good, to let someone else pick up just the translations

> and work

> on them.

>

> of course, we have the perpetual problem that when a new element is added,

> or the  is altered in the English original, we have to bring all

> the translations

> into sync.

Yeah, well.  If this happens, we trigger a notice to the

tei-translators mailing list, I assume.

>

> dont forget attributes, and vallists, by the way

But attributes should be covered within the elementSpec, shouldnt

they.

What to do about vallists is an interesting question that needs to be

discussed.

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 Jun 26 2005 - 18:37:38 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Jun 26 18:46:23 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 27 Jun 2005 07:46:23 +0900
Subject: [tei-council] another agenda item
In-Reply-To: <17087.3456.464155.297244@emt.wwp.brown.edu>
Message-ID: 

From: Christian Wittern 

Date: Mon, 27 Jun 2005 07:46:23 +0900

Syd Bauman edu> writes:

>>  1. on Sourceforge, in CVS. any one monitoring CVS gets the gory

>>     fixes, which are not even guarenteed to be internally consistent

>>  2. on Sourceforge, as file releases. these are zip files containing the

>>     P5 materials in a supposedly runtime tree structure

>>  3. on the TEI web site, in the form of the HTML version of the Guidelines

>>  4. on the web, as the eXist database behind Roma, also used for

>>     the /Query/tag.xq?name=foo interface; noting that Roma

>>     conceptually lives on both tei.oucs.ox.ac.uk and on tei-c.org.uk,

>>     which can be kept apart

>>  5. in Debian packages

>>  6. bundled in TEI Emacs

>>  7. in TEI Knoppix CDs and DVDs

>

>> of these, only the first and second are clear; #1 happens when

>> anyone makes a change; and #2 happens when the Council authorizes a

>> new numbered release.

Did we have this policy?  If not, I assume we should introduce it:-)

To me, anything above 2 is merely derived and does not need additional

authorization or whatever, it just needs to be part of the workflow.

Most of that could be triggered automatically, I assume.  The timing

of 7, on the other hand would presumably not depend on the release

state, but more on the need to have such a beast at a certain time

(e.g. for classes, conference, members meeting etc.)

Roma OTOH would quite closely follow the CVS version, right?

>

> One thing missing here is the issue of where bug fixes fit in. It makes 

> sense for the editors to be able to push out file releases of this sort 

> without pestering the Council.

Bug fixes go inot CVS immediately.  They do not necessarily trigger a

new release -- maybe a minor release if they are serious.

> We also haven't distinguish between the fairly frequent "releases"

> that happen as we make minor updates (especially within the

> development process) and the more formal increments (e.g. P5.1, P6,

> etc.). It seems to me that the Council should be directly involved in

> the major updates (e.g., new chapter, significant change to class

> system, etc.), and not involved in the minor development updates or

> bug-fix updates. Not so sure about the intermediate ones.

Thas sounds goot to me.

>

>

>> (since only #1 is really a Release").

>

> I don't think #1 is a release -- it's the current work repository. #2

> is the only thing that is really a "release" at the moment. What is

> lacking is an agreement on what should trigger a new file release in

> Sourceforge (i.e., a new #2). I'd propose that in this pre-release

> protion of P5's lifecycle, pretty much any significant change

> (including bug fixes) that results in a self-consistent, self-

> validating, working version of the Guidelines should trigger a new

> release on Sourceforge.

Then you might end up with frequent new snapshots, which might be of

mixed quality (cf the eXist development model).  I assume that people

interested that much in the day-to-day development could as easily

follow the CVS.

Apart from that, I think it would make sense to delegate the timings

of the other releases to Sebastian (or whoever is involved), they do

not seem to fall directly into the area of the work the council is

supervising.

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 Jun 26 2005 - 18:46:18 EDT

From Syd_Bauman at Brown.edu  Mon Jun 27 00:40:35 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 27 Jun 2005 00:40:35 -0400
Subject: [tei-council] another agenda item
In-Reply-To: 
Message-ID: <17087.33603.667507.593350@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Mon, 27 Jun 2005 00:40:35 -0400

> Did we have this policy? If not, I assume we should introduce it:-)

I didn't think so, and as I said, I don't think it's necessarily the

right way to proceed. 

> > I'd propose that in this pre-release protion of P5's lifecycle,

> > pretty much any significant change (including bug fixes) that

> > results in a self-consistent, self- validating, working version

> > of the Guidelines should trigger a new release on Sourceforge.

> 

> Then you might end up with frequent new snapshots, which might be

> of mixed quality (cf the eXist development model). I assume that

> people interested that much in the day-to-day development could as

> easily follow the CVS.

What is the eXist development model?

In any case, the logic behind my suggestion was that although the

content of the snapshot releases might be mixed in nature, we'd only

make snaphots of "working" versions of the Guidelines, specifically

to avoid poor-quality snapshots. The idea being that CVS followers

take their chances, but snapshot downloaders should get the newest we

can provide that we know is at least rudimentarily OK.

Another policy to add on top would be to say that we don't make a new

snapshot unless not only is it a self-validating, self-consistent,

consistent version, but it is in some way better than the previous

snapshot. 

> Apart from that, I think it would make sense to delegate the

> timings of the other releases to Sebastian (or whoever is

> involved), they do not seem to fall directly into the area of the

> work the council is supervising.

While it may be Sebastian who does the actual work, I believe that

Council should set the basic principles or Guidelines, and the

editors should decide when snapshots are in order according to them.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Mon Jun 27 2005 - 00:40:40 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Jun 27 01:18:21 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 27 Jun 2005 14:18:21 +0900
Subject: [tei-council] another agenda item
In-Reply-To: <17087.33603.667507.593350@emt.wwp.brown.edu>
Message-ID: 

From: Christian Wittern 

Date: Mon, 27 Jun 2005 14:18:21 +0900

Syd Bauman edu> writes:

> What is the eXist development model?

To provide a snapshot every couple of (days|weeks) to make it easier

to follow development.

The downside of this is that in most cases it is too frequent for most

people to follow.  

>

> In any case, the logic behind my suggestion was that although the

> content of the snapshot releases might be mixed in nature, we'd only

> make snaphots of "working" versions of the Guidelines, specifically

> to avoid poor-quality snapshots. The idea being that CVS followers

> take their chances, but snapshot downloaders should get the newest we

> can provide that we know is at least rudimentarily OK.

That implies that we will need to have some kind of QA process before

the snapshot release, not just packaging.

>

> Another policy to add on top would be to say that we don't make a new

> snapshot unless not only is it a self-validating, self-consistent,

> consistent version, but it is in some way better than the previous

> snapshot. 

>

>

>> Apart from that, I think it would make sense to delegate the

>> timings of the other releases to Sebastian (or whoever is

>> involved), they do not seem to fall directly into the area of the

>> work the council is supervising.

>

> While it may be Sebastian who does the actual work, I believe that

> Council should set the basic principles or Guidelines, and the

> editors should decide when snapshots are in order according to them.

Right.  The quote above relates to the other derived releases (debian,

DVD) Sebastian was asking about.

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 Jun 27 2005 - 01:18:26 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Jun 27 04:16:29 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 27 Jun 2005 09:16:29 +0100
Subject: [tei-council] another agenda item
In-Reply-To: <17087.33603.667507.593350@emt.wwp.brown.edu>
Message-ID: <42BFB5DD.502@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 27 Jun 2005 09:16:29 +0100

Syd Bauman wrote:

>In any case, the logic behind my suggestion was that although the

>content of the snapshot releases might be mixed in nature, we'd only

>make snaphots of "working" versions of the Guidelines, specifically

>to avoid poor-quality snapshots. 

>  

>

thats fine, of course.

>Another policy to add on top would be to say that we don't make a new

>snapshot unless not only is it a self-validating, self-consistent,

>consistent version, but it is in some way better than the previous

>snapshot. 

>  

>

what changes would one make which would not make the thing "better"?

any bug fix makes the system better for someone.

-- 
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 Jun 27 2005 - 04:17:39 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Jun 27 04:30:44 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 27 Jun 2005 09:30:44 +0100
Subject: [tei-council] another agenda item
In-Reply-To: 
Message-ID: <42BFB934.30003@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 27 Jun 2005 09:30:44 +0100

Christian Wittern wrote:

>Roma OTOH would quite closely follow the CVS version, right?

>  

>

would it? I really think we want more clarity on this sort of thing.

when someone comes to the web site and accesses the P5 HTML Guidelines,

and then uses the Query interface (or Roma), they should really get the

same result, I think. Either CVS *or* the current minor release *or* the

current

major release. Not a mixture.

>

>Then you might end up with frequent new snapshots, which might be of

>mixed quality (cf the eXist development model).  I assume that people

>interested that much in the day-to-day development could as easily

>follow the CVS.

>  

>

the flaw there is that we do not, so everyone tells me, have

a documented or easy to use system for people to work with

the CVS sources. If you assure me that Joe Fairly Clued-Up Encoder

can do a cvs update, and then generate schemas or read the documentation,

then its OK; but I keep being told the opposite...

>Apart from that, I think it would make sense to delegate the timings

>of the other releases to Sebastian (or whoever is involved), they do

>not seem to fall directly into the area of the work the council is

>supervising.

>  

>

Things like the TEI Knoppix CD is a separate activity, I agree. But

unless the TEI Consortium fully endorses distribution methods

other then CVS and SF File Releases, we are not in a healthy state.

As it stands, we are in a  fairly ridiculous position that only

Debian Linux users get a decent service; to make matters worse,

the releases of the various  formats are not under the control of

the editors, since neither of them has the infrastructure to

prepare and release the materials.

One solution would be create a new job of Release Manager,

who determined when and how minor releases happened; the

Council would be consulted on major releases; the editors

would be left to coordinate the actual code work in the background.

I am not confident that the system as of today works; neither of

the editors is able to keep up with the current work plan, let alone

take on more work, the public is getting confused messages

about versions from  all over the place, and the council is not

visibly taking charge.

-- 
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 Jun 27 2005 - 04:31:57 EDT

From lou.burnard at computing-services.oxford.ac.uk  Mon Jun 27 04:27:28 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 27 Jun 2005 09:27:28 +0100
Subject: [tei-council] another agenda item
In-Reply-To: 
Message-ID: <42BFB870.10708@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Mon, 27 Jun 2005 09:27:28 +0100

Christian Wittern wrote:

>

>To provide a snapshot every couple of (days|weeks) to make it easier

>to follow development.

>The downside of this is that in most cases it is too frequent for most

>people to follow.  

>  

>

I agree. A nightly build is too frequent, particularly if we continue 

with the current spasmodic rate of progress.

>>In any case, the logic behind my suggestion was that although the

>>content of the snapshot releases might be mixed in nature, we'd only

>>make snaphots of "working" versions of the Guidelines, specifically

>>to avoid poor-quality snapshots. The idea being that CVS followers

>>take their chances, but snapshot downloaders should get the newest we

>>can provide that we know is at least rudimentarily OK.

>>    

>>

>

>That implies that we will need to have some kind of QA process before

>the snapshot release, not just packaging.

>  

>

What would we need beyond the current "make; make validate; make test" 

cycle?

>  

>

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Mon Jun 27 2005 - 04:34:00 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Jun 27 04:33:11 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 27 Jun 2005 09:33:11 +0100
Subject: [tei-council] Re: roma, documentation, i18n
In-Reply-To: 
Message-ID: <42BFB9C7.5020808@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 27 Jun 2005 09:33:11 +0100

Christian Wittern wrote:

>What would be the advantage of pulling this into the main P5 source?

>I see only added maintainance cost with no real benefit.  You could as

>easily pull them out and merge them into the tree on runtime.

>  

>

perhaps its matter of semantics; if the main ODD processing

software expects to find the various language-specific s

in site in the main document, then it does not much matter whether

the merge is at runtime or at source. I just want to avoid a "normal"

ODD processor from having to know about the language modules.

>  

>

>>dont forget attributes, and vallists, by the way

>>    

>>

>

>But attributes should be covered within the elementSpec, shouldnt

>they.

>

>  

>

and the classSpecs.

-- 
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 Jun 27 2005 - 04:34:22 EDT

From lou.burnard at computing-services.oxford.ac.uk  Mon Jun 27 04:35:31 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 27 Jun 2005 09:35:31 +0100
Subject: [tei-council] Re: roma, documentation, i18n
In-Reply-To: <42BFB9C7.5020808@computing-services.oxford.ac.uk>
Message-ID: <42BFBA53.4040702@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Mon, 27 Jun 2005 09:35:31 +0100

It's also a philosophical point. ODD is "one" document does it all. In a 

semi-normative document like P5 you need to have one canonical 

translation for each language, and the logical place to store that 

canonical translation is in the canon. I see the language module files 

which Sebastian is talking about as being exactly analogous to other 

non-canonical schema modifications.

Theres a whole lot of quality control issues here too, of course: at 

what point and how does who decide that translation x is canonical, and 

can therefore be merged into the source?

I also think it's important for a useful to be able to see other 

translations. If, for example, I were translating into Italian, I would 

probably find a pre-existing French translation helpful.

Lou

 Sebastian Rahtz wrote:

>Christian Wittern wrote:

>

>  

>

>>What would be the advantage of pulling this into the main P5 source?

>>I see only added maintainance cost with no real benefit.  You could as

>>easily pull them out and merge them into the tree on runtime.

>> 

>>

>>    

>>

>perhaps its matter of semantics; if the main ODD processing

>software expects to find the various language-specific s

>in site in the main document, then it does not much matter whether

>the merge is at runtime or at source. I just want to avoid a "normal"

>ODD processor from having to know about the language modules.

>

>  

>

>> 

>>

>>    

>>

>>>dont forget attributes, and vallists, by the way

>>>   

>>>

>>>      

>>>

>>But attributes should be covered within the elementSpec, shouldnt

>>they.

>>

>> 

>>

>>    

>>

>and the classSpecs.

>

>

>  

>

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Mon Jun 27 2005 - 04:42:00 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Jun 27 07:44:58 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 27 Jun 2005 12:44:58 +0100
Subject: [tei-council] another agenda item
In-Reply-To: <42BFB870.10708@computing-services.oxford.ac.uk>
Message-ID: <42BFE6BA.4020203@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 27 Jun 2005 12:44:58 +0100

Lou Burnard wrote

>>

>

> I agree. A nightly build is too frequent, particularly if we continue

> with the current spasmodic rate of progress.

lets not continue like that, then....  let's have a roadmap, with dated

milestones,

and stick to it.

>

> What would we need beyond the current "make; make validate; make test"

> cycle?

o long as everyone has that cycle working properly, then its OK. but we

have

had a fair degree of difficulty in getting more than one development system

in sync with any others...

-- 
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 Jun 27 2005 - 07:46:10 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Jun 27 07:46:57 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 27 Jun 2005 12:46:57 +0100
Subject: [tei-council] Re: roma, documentation, i18n
In-Reply-To: <42BFBA53.4040702@computing-services.oxford.ac.uk>
Message-ID: <42BFE731.6020407@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 27 Jun 2005 12:46:57 +0100

Lou Burnard wrote:

>

> Theres a whole lot of quality control issues here too, of course: at

> what point and how does who decide that translation x is canonical,

> and can therefore be merged into the source?

agreed, this is a question. by supporting language modules externally

and internally, we would

have a cleanish system for supporting this notion.

-- 
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 Jun 27 2005 - 07:48:11 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Jun 27 23:36:15 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 28 Jun 2005 12:36:15 +0900
Subject: [tei-council] ITS@W3C  (was:Re: roma, documentation, i18n)
In-Reply-To: <42BFB9C7.5020808@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Tue, 28 Jun 2005 12:36:15 +0900

Council members,

As it happens, I had a long conversation with Felix Sasaki yesterday,

who joined the W3C host in Japan this April and works there on i18n

issues.  He mentioned work going on at the W3C at the ITS

(Internationalization Tag Set,

cf. http://www.w3.org/International/its/) group, which seems to have

some overlap with our problem here. The mission statement for the

group is as follows:

Mission: Develop a set of elements and attributes that can be used

with new DTDs/Schemas to support the internationalization and

localization of documents; and provide best practice techniques for

developers of DTDs/Schemas that show how to enable

internationalization of their documents.

They are not ready and it might be overkill, but it seems to me that

we should monitor this.

He asked also if somebody from the TEI would be interested to join

this group; we also discussed if the TEI could/should consider to

enter into some formal relation with the W3C.  I would be interested

in opinions from the Council members on the desirability of such a

development.

Sebastian Rahtz oxford.ac.uk> writes:

> Christian Wittern wrote:

>

>>What would be the advantage of pulling this into the main P5 source?

>>I see only added maintainance cost with no real benefit.  You could as

>>easily pull them out and merge them into the tree on runtime.

>>  

>>

> perhaps its matter of semantics; if the main ODD processing

> software expects to find the various language-specific s

> in site in the main document, then it does not much matter whether

> the merge is at runtime or at source. I just want to avoid a "normal"

> ODD processor from having to know about the language modules.

>

>>>dont forget attributes, and vallists, by the way

>>But attributes should be covered within the elementSpec, shouldnt

>>they.

>>

> and the classSpecs.

-- 
 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 27 2005 - 23:36:21 EDT

From lou.burnard at computing-services.oxford.ac.uk  Tue Jun 28 04:00:49 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 28 Jun 2005 09:00:49 +0100
Subject: [tei-council] ITS@W3C
In-Reply-To: 
Message-ID: <42C103B1.6030208@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Tue, 28 Jun 2005 09:00:49 +0100

Well, this does seem to overlap quite a lot... and it would be nice if 

we could persuade W3C to adopt ODD oor something like it...  I met Felix 

at Extreme last year and formed a high opinion of him, so I think 

working with him might be well worthwhile.

If we were to set up with W3C something like the existing liaison with 

ISO, would we be able to say that the TEI runs the internet?

Seriously, tho. Yes, I agree that this would be worth pursuing, and I am 

willing to help pursue it, or persuade Sebastian to, assuming either of 

us can find the time.

Lou

Christian Wittern wrote:

>Council members,

>

>As it happens, I had a long conversation with Felix Sasaki yesterday,

>who joined the W3C host in Japan this April and works there on i18n

>issues.  He mentioned work going on at the W3C at the ITS

>(Internationalization Tag Set,

>cf. http://www.w3.org/International/its/) group, which seems to have

>some overlap with our problem here. The mission statement for the

>group is as follows:

>

>Mission: Develop a set of elements and attributes that can be used

>with new DTDs/Schemas to support the internationalization and

>localization of documents; and provide best practice techniques for

>developers of DTDs/Schemas that show how to enable

>internationalization of their documents.

>

>

>They are not ready and it might be overkill, but it seems to me that

>we should monitor this.

>

>He asked also if somebody from the TEI would be interested to join

>this group; we also discussed if the TEI could/should consider to

>enter into some formal relation with the W3C.  I would be interested

>in opinions from the Council members on the desirability of such a

>development.

>

>Sebastian Rahtz oxford.ac.uk> writes:

>

>  

>

>>Christian Wittern wrote:

>>

>>    

>>

>>>What would be the advantage of pulling this into the main P5 source?

>>>I see only added maintainance cost with no real benefit.  You could as

>>>easily pull them out and merge them into the tree on runtime.

>>> 

>>>

>>>      

>>>

>>perhaps its matter of semantics; if the main ODD processing

>>software expects to find the various language-specific s

>>in site in the main document, then it does not much matter whether

>>the merge is at runtime or at source. I just want to avoid a "normal"

>>ODD processor from having to know about the language modules.

>>

>>    

>>

>>>>dont forget attributes, and vallists, by the way

>>>>        

>>>>

>

>  

>

>>>But attributes should be covered within the elementSpec, shouldnt

>>>they.

>>>

>>>      

>>>

>>and the classSpecs.

>>    

>>

>

>  

>

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Jun 28 2005 - 04:05:30 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jun 28 04:25:25 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 28 Jun 2005 09:25:25 +0100
Subject: [tei-council] ITS@W3C
In-Reply-To: 
Message-ID: <42C10975.2040901@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Tue, 28 Jun 2005 09:25:25 +0100

I would rank getting closer to the W3C as pretty important. The work put

into the ODD

system will be as nothing if it has no impact on the real world.

I'm more than happy to put effort into this; if Lou tells me I can treat it

as part of my job, I can join the working group and represent the TEI.

-- 
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 Jun 28 2005 - 04:26:38 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Jun 28 05:04:24 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 28 Jun 2005 18:04:24 +0900
Subject: [tei-council] ITS@W3C
In-Reply-To: <42C103B1.6030208@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Tue, 28 Jun 2005 18:04:24 +0900

Lou Burnard oxford.ac.uk> writes:

> Well, this does seem to overlap quite a lot... and it would be nice if

> we could persuade W3C to adopt ODD oor something like it...  I met

> Felix at Extreme last year and formed a high opinion of him, so I

> think working with him might be well worthwhile.

It seems to be a bit optimistic to me to assume they will adopt ODD,

but one could give it a try.  If Sebastian could join that WG for the

TEI that would be great. 

>

> If we were to set up with W3C something like the existing liaison with

> ISO, would we be able to say that the TEI runs the internet?

Sure. And that is the last step before world domination.

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 28 2005 - 05:04:53 EDT

From Julia_Flanders at Brown.edu  Tue Jun 28 16:07:03 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Tue, 28 Jun 2005 16:07:03 -0400
Subject: [tei-council] working on certainty
Message-ID: 

From: Julia Flanders 

Date: Tue, 28 Jun 2005 16:07:03 -0400

While I am happy to continue to work on certainty, I will not be able 

to complete a review/report on this by July 1, now that Edward is no 

longer able to work with me  on it. I'll try to get this done before 

the conference call, but probably not much before.

best wishes, Julia

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Jun 28 2005 - 16:07:08 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Jun 28 18:21:17 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 29 Jun 2005 07:21:17 +0900
Subject: [tei-council] working on certainty
In-Reply-To: 
Message-ID: 

From: Christian Wittern 

Date: Wed, 29 Jun 2005 07:21:17 +0900

Julia Flanders edu> writes:

> While I am happy to continue to work on certainty, I will not be able

> to complete a review/report on this by July 1, now that Edward is no

> longer able to work with me  on it. I'll try to get this done before

> the conference call, but probably not much before.

Julia, thank you for your efforts.  I think we will be fine if we can

get a status report for the conference call, maybe combined with an

estimate of the remaining work and time schedule.

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 28 2005 - 18:21:21 EDT

From Laurent.Romary at loria.fr  Wed Jun 29 02:29:00 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Wed, 29 Jun 2005 08:29:00 +0200
Subject: [tei-council] ITS@W3C
In-Reply-To: <42C10975.2040901@computing-services.oxford.ac.uk>
Message-ID: 

From: Laurent Romary 

Date: Wed, 29 Jun 2005 08:29:00 +0200

I would strongly support this idea!

Laurent

Le 28 juin 05, ? 10:25, Sebastian Rahtz a ?crit :

> I would rank getting closer to the W3C as pretty important. The work 

> put

> into the ODD

> system will be as nothing if it has no impact on the real world.

>

> I'm more than happy to put effort into this; if Lou tells me I can 

> treat it

> as part of my job, I can join the working group and represent the TEI.

>

> -- 

> 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 Jun 29 2005 - 02:32:00 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Jun 30 01:40:53 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 30 Jun 2005 14:40:53 +0900
Subject: [tei-council] [AIR] action item report: Epigraphical encoding
Message-ID: 

From: Christian Wittern 

Date: Thu, 30 Jun 2005 14:40:53 +0900

Dear Council members,

This is a report about my follow up to section 8.4 of the minutes at

http://www.tei-c.org.uk/Council/tcm17.xml?style=printable 

I have been looking around to see what people in the epigraphical

field been doing.  Elli Mylonas pointed me to a number of ressources,

among other things the EpiDoc group and a mailing list, both run by

Tom Elliot.  He responded today, after more than a month, that he will

be following up soon.  

I looked briefly at EpiDoc, which looks like it could use a lot of

work. On the upside, they came up with Guidelines of their own for

their user community and some stylesheets to get things going.

Development seems to be rather slow.   I will work further with them

and will see if a common base for further development can be found.

There are some projects, most notably the Aphrodisias project at Kings

College etc.

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 30 2005 - 01:40:59 EDT

From jawalsh at indiana.edu  Fri Jul  1 13:09:13 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Fri, 1 Jul 2005 12:09:13 -0500
Subject: [tei-council] Re: next conference call of TEI council
In-Reply-To: 
Message-ID: <410EA325-18A4-4CE8-8E34-F3AD3B469CD6@indiana.edu>

From: John A. Walsh 

Date: Fri, 1 Jul 2005 12:09:13 -0500

Christian,

I've scheduled the conference call for next week at 1300 UTC.

The instructions (number, code, etc.) remain the same:

When dialing into the conference bridge??from

Long Distance................. DIAL   1-812-856-3550 ........ at  

recording enter your 4-digit pass code followed by pound (#) sign.

Participants Code: 0920

John

| John A. Walsh, Associate Director for Projects and Services

| Digital Library Program / Indiana University Libraries

| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405

| Voice:812-855-8758 Fax:812-856-2062 edu>

On Jun 22, 2005, at 8:31 PM, Christian Wittern wrote:

>

> Hi John,

>

> If memory serves me right, we agreed to hold the next conference call

> on July 8, usual time (= 1300 UTC).  Does that conform with your

> recollections?  If so, I would appreciate if you could set up the call

> and notify us of the procedures.

>

> Thanks for prividing this to the TEI:-)

>

> 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 Jul 01 2005 - 13:09:26 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Jul  1 19:03:40 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 02 Jul 2005 08:03:40 +0900
Subject: [tei-council] Re: next conference call of TEI council
In-Reply-To: <410EA325-18A4-4CE8-8E34-F3AD3B469CD6@indiana.edu>
Message-ID: 

From: Christian Wittern 

Date: Sat, 02 Jul 2005 08:03:40 +0900

Thanks John,

o we will talk on July 8th at the usual time. 

As mentioned previously, I would like to see reports on action items

previous to the call.  In your reports, which might be brief, please

indicate where you are seeking input from the council.  In addition to

that, please give me items you want to see on the agenda.  So far I

have

- principles for publication of snapshots etc. of P5

  Status: a proposal from Sebastian and subsequent discussion, we need to come

  to a decision.

- I18N infrastructure for translations of gloss and desc, vallists etc

  Status: some discussion, but no proposal yet - need to consider

  aligning with W3C ITS effort.

Anything else?

All the best,

Christian

"John A. Walsh" edu> writes:

> Christian,

>

> I've scheduled the conference call for next week at 1300 UTC.

>

> The instructions (number, code, etc.) remain the same:

>

> When dialing into the conference bridge??????from

>

> Long Distance................. DIAL   1-812-856-3550 ........ at

> recording enter your 4-digit pass code followed by pound (#) sign.

>

> Participants Code: 0920

>

> John

> | John A. Walsh, Associate Director for Projects and Services

> | Digital Library Program / Indiana University Libraries

> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405

> | Voice:812-855-8758 Fax:812-856-2062 edu>

>

> On Jun 22, 2005, at 8:31 PM, Christian Wittern wrote:

>

>>

>> Hi John,

>>

>> If memory serves me right, we agreed to hold the next conference call

>> on July 8, usual time (= 1300 UTC).  Does that conform with your

>> recollections?  If so, I would appreciate if you could set up the call

>> and notify us of the procedures.

>>

>> Thanks for prividing this to the TEI:-)

>>

>> All the best,

>>

>> Christian

>>

>> -- 

>>  Christian Wittern

>>  Institute for Research in Humanities, Kyoto University

>>  47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

>>

>

>

>

>

-- 
 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 Jul 01 2005 - 19:03:46 EDT

From jawalsh at indiana.edu  Sat Jul  2 06:15:10 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Sat, 2 Jul 2005 05:15:10 -0500
Subject: [tei-council] Oxygen P5 Instructions
Message-ID: <1E9CCE26-ADDE-474C-B8A4-7AE5CD7CF707@indiana.edu>

From: John A. Walsh 

Date: Sat, 2 Jul 2005 05:15:10 -0500

Hi all,

In response to action item " Instructions for using a P5 grammar in  

oXygen," I've posted instructions for setting up P5 grammars in the  

Oxygen XML Editor.

HTML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/ 

oxygenValidationInstructions.html

TEI/XML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/ 

oxygenValidationInstructions.xml

John

| John A. Walsh, Associate Director for Projects and Services

| Digital Library Program / Indiana University Libraries

| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405

| Voice:812-855-8758 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 Sat Jul 02 2005 - 08:50:53 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jul  2 10:56:01 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 02 Jul 2005 15:56:01 +0100
Subject: [tei-council] Oxygen P5 Instructions
In-Reply-To: <1E9CCE26-ADDE-474C-B8A4-7AE5CD7CF707@indiana.edu>
Message-ID: <42C6AB01.2020400@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sat, 02 Jul 2005 15:56:01 +0100

John A. Walsh wrote:

> Hi all,

>

> In response to action item " Instructions for using a P5 grammar in 

> oXygen," I've posted instructions for setting up P5 grammars in the 

> Oxygen XML Editor.

>

> HTML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/

> oxygenValidationInstructions.html

> TEI/XML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/

> oxygenValidationInstructions.xml

>

any reason not to put this on the TEI web site?

-- 
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 Jul 02 2005 - 10:56:11 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jul  2 18:05:06 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 02 Jul 2005 23:05:06 +0100
Subject: [tei-council] directory layout of a TEI distribution
Message-ID: <42C70F92.3080708@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sat, 02 Jul 2005 23:05:06 +0100

Some of us have been having a discussion with the oXygen folks about

a common layout for TEI-related files (docs, schemas, dtds, skeleton files,

kitchen sink etc). Christian rightly said that the Council should be

discussing this,

so here goes.

The following diagram shows the layout I am using for my Debian Linux

packages

(starting at /usr/share).

The xml/tei tree is pretty well mandated by conformance to standards

for Debian (though please point out any really silly stuff), but the doc

tree

is more open for discussion.  How should the HTML guidelines relate to

the skeletons?

what should the "skeletons" be called? where is the documentation for

these exemplars?

should I use "p4" or "P4" consistently?

I'd like to absolutely clear on this before the phone call at the latest,

so if you can tear yourselves away from Pink Floyd at Live8 for a few

minutes...

hare

|-- doc

|   `-- tei

|       |-- P4

|       |   `-- Figures

|       |-- P5

|       |-- Pictures

|       |-- skeletons

|       |   |-- p4

|       |   `-- p5

|       `-- web

|           `-- Query

`-- xml

    `-- tei

        |-- odd

        |-- schema

        |   |-- dtd

        |   |   |-- p4

        |   |   `-- p5

        |   |-- relaxng

        |   |   |-- p4

        |   |   `-- p5

        |   `-- xsd

        |       `-- p5

        `-- stylesheet

            |-- base

            |   |-- p4

            |   |   |-- common

            |   |   |-- fo

            |   |   |-- html

            |   |   `-- latex

            |   `-- p5

            |       |-- common

            |       |-- fo

            |       |-- html

            |       `-- latex

            |-- odds

            |-- slides

            `-- teic

38 directories

-- 
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 Jul 02 2005 - 18:05:12 EDT

From Syd_Bauman at Brown.edu  Sat Jul  2 18:37:40 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 2 Jul 2005 18:37:40 -0400
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C70F92.3080708@computing-services.oxford.ac.uk>
Message-ID: <17095.5940.562704.110577@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sat, 2 Jul 2005 18:37:40 -0400

Does SyncRO Soft need to know the layout of the doc/ hierarchy? I was

under the (perhaps mistaken) impression they were interested in our

hammering down the tei/schema/ and tei/stylesheet directories layout

and canonical web location, so that they can mirror that layout and

point to the canonical location from their frameworks/ directory.

> share

> |-- doc

> |   `-- tei

> |       |-- P4

> |       |   `-- Figures

> |       |-- P5

> |       |-- Pictures

> |       |-- skeletons

> |       |   |-- p4

> |       |   `-- p5

> |       `-- web

> |           `-- Query

I understand what's in doc/tei/P4/Figures, and I even undertand why

it's named "Figures/" (as is customary in the TEI depot and website)

as opposed to "figures/" (which would be far more common, if not

customary, in Debian). But I don't understand why there isn't such a

directory inside /doc/tei/P5/, nor what is in doc/tei/Pictures. I

can look, of course, but not everyone on this list has a Debian

system with your stuff on it handy, and I still don't understand

a) why it's there ... this stuff isn't needed to read the Guidelines,

   is it? and

b) why we have GIF files instead of PNGs. Are GIFs back to being

   politically acceptable now?

What is in skeletons/? What are web/ and web/Query? (Which I don't

have.) 

> `-- xml

>     `-- tei

>         |-- odd

Perhaps this directory should be called /xml/tei/src/ instead? And

shouldn't there be a p5/ child of this directory? That way, if & when

the Board permits the source of P4 to be public, or if & when there

ever are ODDs for P6 (or perhaps a P5.1 beast) we could put it in

this directory, too

>         |-- schema

>         |   |-- dtd

>         |   |   |-- p4

>         |   |   `-- p5

>         |   |-- relaxng

>         |   |   |-- p4

>         |   |   `-- p5

My objection to there being RelaxNG schema for P4 still holds.[1]

I doubt I'm going to win this one, but there should at least be a

README file reminding users that technically, a DOCTYPE declaration

is required in P4, IMHO. (Or, we should create a P4.1 that drops that

requirement.) 

>         |   `-- xsd

>         |       `-- p5

>         `-- stylesheet

>             |-- base

>             |   |-- p4

>             |   |   |-- common

>             |   |   |-- fo

>             |   |   |-- html

>             |   |   `-- latex

>             |   `-- p5

>             |       |-- common

>             |       |-- fo

>             |       |-- html

>             |       `-- latex

>             |-- odds

>             |-- slides

>             `-- teic

Obviously, you're the stylesheet dude, you organize these as you see

fit. But I'm awfully curious ... why is it that odds/, slides/, and

teic/ are at the root level, and are not each split up into p4/ and

p5? (OK, I understand odds/ not being split, as those stylesheets

have nothing to do with the P4 ODD language; but one can write slides

in P4 or P5, no? We have hundreds of P4 files and dozens of P5 files

on the tei-c website, no?)

Note

----
[1] For those who did not get a copy of my 2003-10-12 mail to the
    Debian-layout-designers, here's what it said:
        Since P4 is inextricably tied to DTDs, and no instance can be
        TEI P4 conformant unless it has a DOCTYPE declaration that
        points to a DTD (and it's valid against that DTD), I would
        say that schemas for P4 in languages other than DTD should
        not be provided.
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sat Jul 02 2005 - 18:37:45 EDT

From Syd_Bauman at Brown.edu  Sat Jul  2 20:15:22 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 2 Jul 2005 20:15:22 -0400
Subject: [tei-council] some reports in
Message-ID: <17095.11802.296394.473670@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sat, 2 Jul 2005 20:15:22 -0400

Julia's review of Chapter 9, base prose for verse, is now available at

http://www.tei-c.org/Council/ChapterReviews/VE.xml?style=printable.

BTW, don't blame Julia for it's being a day later than promised. She

sent it to me & Susan to put up on Thu, it was my confusion that

caused the delay.

My first cut at attributes and datatypes is available at 

http://www.tei-c.org/Drafts/edw90.xml?style=printable. I'm afraid the

database of devilish details I had hoped to have ready for you is not

quite up to snuff. You can see an out-of-date version (link is in the

paper), but it's just too painful to make the current stuff live

right now. Hopefully in two or three days.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sat Jul 02 2005 - 20:15:26 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul  3 06:42:11 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 03 Jul 2005 11:42:11 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <17095.5940.562704.110577@emt.wwp.brown.edu>
Message-ID: <42C7C103.5070409@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 03 Jul 2005 11:42:11 +0100

Syd Bauman wrote:

>Does SyncRO Soft need to know the layout of the doc/ hierarchy?

>

they need the skeleton files, which I currently have in doc

>I understand what's in doc/tei/P4/Figures

>

i need to look at this again

>What is in skeletons/?

>

exemplars

> What are web/ and web/Query? (Which I don't

>have.) 

>  

>

the material for eXist connection

>

>  

>

>>`-- xml

>>    `-- tei

>>        |-- odd

>>    

>>

>

>Perhaps this directory should be called /xml/tei/src/ instead?

>

could be

> And

>shouldn't there be a p5/ child of this directory?

>

yes, I agree now that you mention it

>

>

>My objection to there being RelaxNG schema for P4 still holds.[1]

>  

>

its just tei lite....

-- 
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 Jul 03 2005 - 06:42:21 EDT

From James.Cummings at computing-services.oxford.ac.uk  Sun Jul  3 08:11:56 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 03 Jul 2005 13:11:56 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C70F92.3080708@computing-services.oxford.ac.uk>
Message-ID: <42C7D60C.1030809@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Sun, 03 Jul 2005 13:11:56 +0100

Sebastian Rahtz wrote:

> How should the HTML guidelines relate to

> the skeletons?

> what should the "skeletons" be called? where is the documentation for

> these exemplars?

For the record, I view 'skeletons' and 'exemplars' as completely 

different things.  The skeleton gives you an empty skeleton framework 

for starting a particular type of document quickly, whereas an 

exemplar acts as a detailed example with text demonstrating and 

explaining particular markup solutions.

> should I use "p4" or "P4" consistently?

Yes.  That is, it should be consistent, whichever is more official?

On the below:  Although I'm used to the way the debian packages are 

structured at the moment.  Should the rational be to divide by 

aspect(?) and then by version, or by version and then aspect of the TEI.

So: TEI -- P4-- Guidelines

      |      |-- Skeletons

      |

      |----P5 -- Guidelines

            |-- Skeletons

or

    TEI -- Guidelines -- P4

      |           |------P5

      |

      | -- Skeletons -- P4

                  | --- P5

In comparing the Doc tree and the schema and stylesheet tree don't we 

seem to be mixing and matching both of these two types of layout?

(i.e. p4/common p5/common etc.)

I'm assuming that keeping the versions entirely separate is beneficial 

in terms of version control, thus perhaps it should be 

doc/tei/p4/skeletons and xml/tei/p4/odd|schema|stylesheet and 

xml/tei/p5/odd|schema|stylesheet

Just my two pence after staying up too late watching Live8.

-James

> 

> share

> |-- doc

> |   `-- tei

> |       |-- P4

> |       |   `-- Figures

> |       |-- P5

> |       |-- Pictures

> |       |-- skeletons

> |       |   |-- p4

> |       |   `-- p5

> |       `-- web

> |           `-- Query

> `-- xml

>     `-- tei

>         |-- odd

>         |-- schema

>         |   |-- dtd

>         |   |   |-- p4

>         |   |   `-- p5

>         |   |-- relaxng

>         |   |   |-- p4

>         |   |   `-- p5

>         |   `-- xsd

>         |       `-- p5

>         `-- stylesheet

>             |-- base

>             |   |-- p4

>             |   |   |-- common

>             |   |   |-- fo

>             |   |   |-- html

>             |   |   `-- latex

>             |   `-- p5

>             |       |-- common

>             |       |-- fo

>             |       |-- html

>             |       `-- latex

>             |-- odds

>             |-- slides

>             `-- teic

> 

> 38 directories

> 

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Jul 03 2005 - 08:11:57 EDT

From Syd_Bauman at Brown.edu  Sun Jul  3 11:46:07 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 3 Jul 2005 11:46:07 -0400
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C7C103.5070409@computing-services.oxford.ac.uk>
Message-ID: <17096.2111.324392.413116@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sun, 3 Jul 2005 11:46:07 -0400

Sebastian Rahtz writes:

> they need the skeleton files, which I currently have in doc

Ah, right.

> >What is in skeletons/?

> exemplars

Hmmm... not that it's a big deal, in part because there aren't that

many places to look for such things, but an exemplar is typically

more than a skeleton. Any reason not to either

a) put skeletons in there, or

b) call the directory "exemplars/" or "examples/"?

> the material for eXist connection

Is this going to SyncRO Soft, too?

> >My objection to there being RelaxNG schema for P4 still holds.[1]

> >

> its just tei lite....

I was under the impression that we were agreed that customizations

would not go in the general xml/schema/[language]/[release]/

directory. I'm very confident we agreed they would not be in the same

Debian package. In either case, I have concerns about the idea of

putting only TEI Lite (or any other particular customizations, for

that matter) in a directory that is parallel to one that has the

entire set of TEI schema files. At the very least it seems that would

be quite confusing to users.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Jul 03 2005 - 11:46:11 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul  3 12:49:29 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 03 Jul 2005 17:49:29 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C7D60C.1030809@computing-services.oxford.ac.uk>
Message-ID: <42C81719.8010206@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 03 Jul 2005 17:49:29 +0100

James Cummings wrote:

>

> For the record, I view 'skeletons' and 'exemplars' as completely

> different things.  The skeleton gives you an empty skeleton framework

> for starting a particular type of document quickly, whereas an

> exemplar acts as a detailed example with text demonstrating and

> explaining particular markup solutions.

ah. I blame Lou, he told me to use the word "exemplar". you want me to

revert to "skeletons"?

>

>> should I use "p4" or "P4" consistently?

>

>

> Yes.  That is, it should be consistent, whichever is more official?

I think the system from which we are starting, the Debian standards,

would seldom

use uppercase, so probably should be "p4" passim

>

>

> On the below:  Although I'm used to the way the debian packages are

> structured at the moment.  Should the rational be to divide by

> aspect(?) and then by version, or by version and then aspect of the TEI.

the Debian agreement seemed to be to do aspect/version.

>

> In comparing the Doc tree and the schema and stylesheet tree don't we

> seem to be mixing and matching both of these two types of layout?

hmm. you are probably right. they should be the same

I am reluctant to switch the stylesheets again, though.

ugh

-- 
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 Jul 03 2005 - 12:50:41 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul  3 12:53:30 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 03 Jul 2005 17:53:30 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <17096.2111.324392.413116@emt.wwp.brown.edu>
Message-ID: <42C8180A.2070008@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 03 Jul 2005 17:53:30 +0100

Syd Bauman wrote:

>

>Any reason not to either

>a) put skeletons in there, or

>b) call the directory "exemplars/" or "examples/"?

>  

>

I don't have strong feelings about the name. And I am ambivalent

over whether it comes under "doc" or "xm". I sort of incline to the latter

now...

>

>  

>

>>the material for eXist connection

>>    

>>

>

>Is this going to SyncRO Soft, too?

>  

>

no.

>

>I was under the impression that we were agreed that customizations

>would not go in the general xml/schema/[language]/[release]/

>directory.

>

where do they go, then?

> I'm very confident we agreed they would not be in the same

>Debian package.

>

yes, sure. but thats another issue. this tree represents

an amalgamation of lots of files

> In either case, I have concerns about the idea of

>putting only TEI Lite (or any other particular customizations, for

>that matter) in a directory that is parallel to one that has the

>entire set of TEI schema files. At the very least it seems that would

>be quite confusing to users.

>  

>

I see the concern. what do you suggest?

-- 
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 Jul 03 2005 - 12:54:03 EDT

From James.Cummings at computing-services.oxford.ac.uk  Sun Jul  3 13:08:55 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 03 Jul 2005 18:08:55 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C81719.8010206@computing-services.oxford.ac.uk>
Message-ID: <42C81BA7.3090509@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Sun, 03 Jul 2005 18:08:55 +0100

Sebastian Rahtz wrote:

> James Cummings wrote:

> 

> 

>>For the record, I view 'skeletons' and 'exemplars' as completely

>>different things.  The skeleton gives you an empty skeleton framework

>>for starting a particular type of document quickly, whereas an

>>exemplar acts as a detailed example with text demonstrating and

>>explaining particular markup solutions.

> 

> 

> ah. I blame Lou, he told me to use the word "exemplar". you want me to

> revert to "skeletons"?

Well, as long as we are consistent, I don't mind terribly.  It might 

be good to have a collection of actual exemplars or examples.    I.e. 

throughout the Guidelines we have examples of use.  Now usually those 

examples are clearly defined demonstrations of the elements under 

discussion, but often involving all sorts of other elements. Should we 

have (or is there) an easy way to get some sort of index of examples? 

  (i.e. Show me all the examples using  or ).  Would that 

be helpful to users, or am I off my rocker?

-James

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Jul 03 2005 - 13:09:05 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul  3 18:39:41 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 03 Jul 2005 23:39:41 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C81BA7.3090509@computing-services.oxford.ac.uk>
Message-ID: <42C8692D.2040002@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 03 Jul 2005 23:39:41 +0100

I have revised my proposal, with the results appended

I have not changed the XSL layout, as it has a fair few ramifications

for me to clean up.

hare

|-- doc

|   `-- tei

|       |-- html

|       |   |-- base

|       |   |   |-- p4

|       |   |   |   `-- Figures

|       |   |   `-- p5

|       |   `-- exemplars

|       |       `-- p5

|       |-- web

|       |   `-- Query

|       `-- xml

|           `-- exemplars

|               `-- p5

`-- xml

    `-- tei

        |-- odd

        |   `-- exemplars

        |       |-- p4

        |       `-- p5

        |-- schema

        |   |-- dtd

        |   |   |-- p4

        |   |   `-- p5

        |   |-- relaxng

        |   |   |-- p4

        |   |   `-- p5

        |   `-- xsd

        |       `-- p5

        `-- stylesheet

            |-- base

            |   |-- p4

            |   |   |-- common

            |   |   |-- fo

            |   |   |-- html

            |   |   `-- latex

            |   `-- p5

            |       |-- common

            |       |-- fo

            |       |-- html

            |       `-- latex

            |-- odds

            |-- slides

            `-- teic

44 directories

-- 
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 Jul 03 2005 - 18:39:44 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul  3 18:49:05 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 03 Jul 2005 23:49:05 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C81BA7.3090509@computing-services.oxford.ac.uk>
Message-ID: <42C86B61.5000909@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 03 Jul 2005 23:49:05 +0100

James Cummings wrote:

> Should we have (or is there) an easy way to get some sort of index of

> examples?  (i.e. Show me all the examples using  or ). 

> Would that be helpful to users, or am I off my rocker?

>

>

apart for the examples which are not well-formed (not many of these at

all now), it would be easy

run a script over the rest and build an index. I can't recall off hand,

I don't think we currently

generate an anchor in the online system for examples, but it would be

trivial to do so.

of course, the entry for  would be huge....

do others want 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 Sun Jul 03 2005 - 18:49:08 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Jul  3 19:03:22 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 04 Jul 2005 08:03:22 +0900
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C8692D.2040002@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Mon, 04 Jul 2005 08:03:22 +0900

Sebastian Rahtz oxford.ac.uk> writes:

> I have revised my proposal, with the results appended

>

> I have not changed the XSL layout, as it has a fair few ramifications

> for me to clean up.

Hmm.  Now the exemplars are scattered all over the place, which will

make it difficult to get a coherent view of them... Honestly, I would

see them as part of the documentation (documenting different aspects)

and thus would prefer to see them in one tree under doc/tei/examplars.

On a slightly different note, where are users supposed to put the

stuff they get from Roma?  At least for oXygen, that should also fit

into the overall framework, shouldnt it? 

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 Jul 03 2005 - 19:05:21 EDT

From Syd_Bauman at Brown.edu  Sun Jul  3 21:33:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 3 Jul 2005 21:33:11 -0400
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C7D60C.1030809@computing-services.oxford.ac.uk>
Message-ID: <17096.37335.871356.300761@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sun, 3 Jul 2005 21:33:11 -0400

James Cummings writes:

> Yes. That is, it should be consistent, whichever is more official?

I think "P" is more official, but the reason may be a poor one --

that back in the old days one or both editors used a system that

didn't permit lowercase letters in filenames. For use in the Debian

world I think standardizing on "p" is probably the better way to go. 

> On the below: Although I'm used to the way the debian packages

> are structured at the moment. Should the rational be to divide by

> aspect(?) and then by version, or by version and then aspect of

> the TEI.

I think there's a lot to be said for version then aspect, but at

least as far as the /usr/share/xml/tei/ tree is concerned, I don't

think we really have a choice in that Debian already has a pretty

firm plan for where things should go, and we don't want to be the odd

man out.

You are right, though, it does appear a little inconsistent. 

More on this soon; I just noted that more mail on this thread has

arrived.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Jul 03 2005 - 21:33:16 EDT

From Syd_Bauman at Brown.edu  Sun Jul  3 21:52:53 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 3 Jul 2005 21:52:53 -0400
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C8692D.2040002@computing-services.oxford.ac.uk>
Message-ID: <17096.38517.295386.134376@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sun, 3 Jul 2005 21:52:53 -0400

Where in this proposal do the ODD source files to P5 go, if at all?

Into /usr/share/xml/tei/odd/? (Which, in the oXygen world, will be

../oxygen/frameworks/tei/odd/.)

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Jul 03 2005 - 21:52:57 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Jul  4 02:32:02 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 04 Jul 2005 07:32:02 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: 
Message-ID: <42C8D7E2.5080008@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 04 Jul 2005 07:32:02 +0100

Christian Wittern wrote:

>

>

>Hmm.  Now the exemplars are scattered all over the place, which will

>make it difficult to get a coherent view of them...

>

but thats inevitable, surely? the runtime files, the documentation (two

forms),

and the source don't belong in the same tree, once you start down the

Linux-like route.

> Honestly, I would

>see them as part of the documentation (documenting different aspects)

>and thus would prefer to see them in one tree under doc/tei/examplars.

>  

>

but they are also runtime files (schemas). which I currently

put under schema/relaxng/p5, but now I see that it does not

seem quite right

its difficult to reconcile the "debian package" view, which

has no problem with all the files in one directory, because the

package metadata discriminates, and the "human" view

which wants to put files in lots of small directories so that they

can be more easily moved around

>On a slightly different note, where are users supposed to put the

>stuff they get from Roma?  At least for oXygen, that should also fit

>into the overall framework, shouldnt it? 

>  

>

either

   share/tei/xml/schema/relaxng/p5/local

or

   share/tei/xml/schema/relaxng/local

I am not sure which. Is it subsidiary to p5

or in parallel?

of course, many people on Linux won't have access to that tree

at all.

-- 
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 Jul 04 2005 - 02:32:25 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Jul  4 02:33:41 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 04 Jul 2005 07:33:41 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <17096.38517.295386.134376@emt.wwp.brown.edu>
Message-ID: <42C8D845.10706@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 04 Jul 2005 07:33:41 +0100

Syd Bauman wrote:

>Where in this proposal do the ODD source files to P5 go, if at all?

>Into /usr/share/xml/tei/odd/? (Which, in the oXygen world, will be

>../oxygen/frameworks/tei/odd/.)

>

>  

>

share/xml/tei/odd/base/p5

-- 
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 Jul 04 2005 - 02:33:46 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Jul  4 03:26:48 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 04 Jul 2005 16:26:48 +0900
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C8D7E2.5080008@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Mon, 04 Jul 2005 16:26:48 +0900

Sebastian Rahtz oxford.ac.uk> writes:

> Christian Wittern wrote:

>

>>

>>

>>Hmm.  Now the exemplars are scattered all over the place, which will

>>make it difficult to get a coherent view of them...

>>

> but thats inevitable, surely? the runtime files, the documentation (two

> forms),

> and the source don't belong in the same tree, once you start down the

> Linux-like route.

>

>> Honestly, I would

>>see them as part of the documentation (documenting different aspects)

>>and thus would prefer to see them in one tree under doc/tei/examplars.

>>  

>>

> but they are also runtime files (schemas). which I currently

> put under schema/relaxng/p5, but now I see that it does not

> seem quite right

>

> its difficult to reconcile the "debian package" view, which

> has no problem with all the files in one directory, because the

> package metadata discriminates, and the "human" view

> which wants to put files in lots of small directories so that they

> can be more easily moved around

On Debian, you could at least use symlinks from somewhere in the doc

substree to all these other places.  But maybe I am just being

stubborn and this is not needed at all... 

>

>>On a slightly different note, where are users supposed to put the

>>stuff they get from Roma?  At least for oXygen, that should also fit

>>into the overall framework, shouldnt it? 

>>  

>>

> either

>    share/tei/xml/schema/relaxng/p5/local

> or

>    share/tei/xml/schema/relaxng/local

> I am not sure which. Is it subsidiary to p5

> or in parallel?

Rather subsidiary, I would think.

>

> of course, many people on Linux won't have access to that tree

> at all.

Wouldnt it be rather

/usr/local/share/tei/xml/schema whatever

on these systems?

Anyway, I just wanted to be sure that we do have a "recommended

location", since that will probably make it easier to write tutorials,

software etc.

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 04 2005 - 03:26:57 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Jul  4 08:35:29 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 04 Jul 2005 21:35:29 +0900
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: 
Message-ID: 

From: Christian Wittern 

Date: Mon, 04 Jul 2005 21:35:29 +0900

Christian Wittern zinbun.kyoto-u.ac.jp> writes:

>>>Hmm.  Now the exemplars are scattered all over the place, which will

>>>make it difficult to get a coherent view of them...

>>>

>> but thats inevitable, surely? the runtime files, the documentation (two

>> forms),

>> and the source don't belong in the same tree, once you start down the

>> Linux-like route.

>>

>>> Honestly, I would

>>>see them as part of the documentation (documenting different aspects)

>>>and thus would prefer to see them in one tree under doc/tei/examplars.

>>>  

>>>

>> but they are also runtime files (schemas). which I currently

>> put under schema/relaxng/p5, but now I see that it does not

>> seem quite right

>>

>> its difficult to reconcile the "debian package" view, which

>> has no problem with all the files in one directory, because the

>> package metadata discriminates, and the "human" view

>> which wants to put files in lots of small directories so that they

>> can be more easily moved around

Well yes, now that I have thought of this a bit more, I think a way

out of this would be to have a HTML page for each exemplar that

documents its use and links to the relevant files for the inspection

of the user.  What do you think, Sebastian?

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 04 2005 - 08:35:33 EDT

From nsmith at email.unc.edu  Mon Jul  4 22:23:59 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Mon, 4 Jul 2005 22:23:59 -0400
Subject: [tei-council] ITS@W3C  (was:Re: roma, documentation, i18n)
In-Reply-To: 
Message-ID: <065c01c58108$9a3170a0$6401a8c0@lib.unc.edu>

From: Natasha Smith 

Date: Mon, 4 Jul 2005 22:23:59 -0400

I fully support this move and hope we will be successful in forming a good

working relationship with W3C. And thank you to Sebastian for agreeing to

put effort - and time! - into it.

on the related topic and following-up the conversation of 5/23-5/24 about

the priority of languages. I agree with Christian that we might be more

interested in investing in regions/languages that are not yet covered to the

extent they should be - as they have real potential (ex., Japan, China,

Korea.) But I understand that the practicality and reality (I can start with

as simple as finding not just *a* translator, but a reliable one) might

change the priority list and its order.

Finally, I wanted to check what we already have on the site and remembering

that tei has been translated at some point to Russian, I did search and

discovered the following broken links on http://www.tei-c.org.uk/Lite/

http://www.tei-c.org.uk/Lite/teiu5_fr.tei

http://www.tei-c.org.uk/Lite/teiu5_zh.xsw

http://www.tei-c.org.uk/Lite/teiu5_kr.tei

http://www.tei-c.org.uk/Lite/teiu5_ru.rtf

also, in http://www.tei-c.org.uk/Software/ there is a link to TEI Tools by

Boris Tobotras that is password-protected:

http://xtalk.price.ru/SGML/TEItools/index-en.html

best, n

----- Original Message ----- 

From: "Christian Wittern" zinbun.kyoto-u.ac.jp>

To: village.Virginia.EDU>

Sent: Monday, June 27, 2005 11:36 PM

Subject: [tei-council] ITS_at_W3C (was:Re: roma, documentation, i18n)

>

> Council members,

>

> As it happens, I had a long conversation with Felix Sasaki yesterday,

> who joined the W3C host in Japan this April and works there on i18n

> issues.  He mentioned work going on at the W3C at the ITS

> (Internationalization Tag Set,

> cf. http://www.w3.org/International/its/) group, which seems to have

> some overlap with our problem here. The mission statement for the

> group is as follows:

> 

> Mission: Develop a set of elements and attributes that can be used

> with new DTDs/Schemas to support the internationalization and

> localization of documents; and provide best practice techniques for

> developers of DTDs/Schemas that show how to enable

> internationalization of their documents.

> 

>

> They are not ready and it might be overkill, but it seems to me that

> we should monitor this.

>

> He asked also if somebody from the TEI would be interested to join

> this group; we also discussed if the TEI could/should consider to

> enter into some formal relation with the W3C.  I would be interested

> in opinions from the Council members on the desirability of such a

> development.

>

> Sebastian Rahtz oxford.ac.uk> writes:

>

> > Christian Wittern wrote:

> >

> >>What would be the advantage of pulling this into the main P5 source?

> >>I see only added maintainance cost with no real benefit.  You could as

> >>easily pull them out and merge them into the tree on runtime.

> >>

> >>

> > perhaps its matter of semantics; if the main ODD processing

> > software expects to find the various language-specific s

> > in site in the main document, then it does not much matter whether

> > the merge is at runtime or at source. I just want to avoid a "normal"

> > ODD processor from having to know about the language modules.

> >

> >>>dont forget attributes, and vallists, by the way

>

> >>But attributes should be covered within the elementSpec, shouldnt

> >>they.

> >>

> > and the classSpecs.

>

> -- 

>  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 Jul 04 2005 - 22:24:06 EDT

From nsmith at email.unc.edu  Mon Jul  4 22:36:03 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Mon, 4 Jul 2005 22:36:03 -0400
Subject: [tei-council] [AIR] action item report: Epigraphical encoding
In-Reply-To: 
Message-ID: <068201c5810a$49b08b50$6401a8c0@lib.unc.edu>

From: Natasha Smith 

Date: Mon, 4 Jul 2005 22:36:03 -0400

Christian:

just wanted to add one cent to your report - it happened that I talked to

Hugh Cayless (one of the initial developers of EpiDoc and a really great

guy - he might a wonderful source for you) and he mentioned that there is a

wiki set-up, but not open to the public, at least yet. And as far as i

understand the most active developer at the moment is Gabriel Bodard, at

Kings (?)

n

----- Original Message ----- 

From: "Christian Wittern" zinbun.kyoto-u.ac.jp>

To: village.Virginia.EDU>

Sent: Thursday, June 30, 2005 1:40 AM

Subject: [tei-council] [AIR] action item report: Epigraphical encoding

>

> Dear Council members,

>

> This is a report about my follow up to section 8.4 of the minutes at

> http://www.tei-c.org.uk/Council/tcm17.xml?style=printable

>

> I have been looking around to see what people in the epigraphical

> field been doing.  Elli Mylonas pointed me to a number of ressources,

> among other things the EpiDoc group and a mailing list, both run by

> Tom Elliot.  He responded today, after more than a month, that he will

> be following up soon.

>

> I looked briefly at EpiDoc, which looks like it could use a lot of

> work. On the upside, they came up with Guidelines of their own for

> their user community and some stylesheets to get things going.

> Development seems to be rather slow.   I will work further with them

> and will see if a common base for further development can be found.

> There are some projects, most notably the Aphrodisias project at Kings

> College etc.

>

> 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

>

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Mon Jul 04 2005 - 22:36:09 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Jul  5 00:58:18 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 05 Jul 2005 13:58:18 +0900
Subject: [tei-council] [AIR] action item report: Epigraphical encoding
In-Reply-To: <068201c5810a$49b08b50$6401a8c0@lib.unc.edu>
Message-ID: 

From: Christian Wittern 

Date: Tue, 05 Jul 2005 13:58:18 +0900

"Natasha Smith" unc.edu> writes:

> Christian:

>

> just wanted to add one cent to your report - it happened that I talked to

> Hugh Cayless (one of the initial developers of EpiDoc and a really great

> guy - he might a wonderful source for you) and he mentioned that there is a

> wiki set-up, but not open to the public, at least yet. And as far as i

> understand the most active developer at the moment is Gabriel Bodard, at

> Kings (?)

Natasha, thank you for this information.  I will follow up on this.

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 05 2005 - 00:58:39 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Jul  5 01:13:45 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 05 Jul 2005 14:13:45 +0900
Subject: [tei-council] some reports in
In-Reply-To: <17095.11802.296394.473670@emt.wwp.brown.edu>
Message-ID: 

From: Christian Wittern 

Date: Tue, 05 Jul 2005 14:13:45 +0900

Syd Bauman edu> writes:

> Julia's review of Chapter 9, base prose for verse, is now available at

> http://www.tei-c.org/Council/ChapterReviews/VE.xml?style=printable.

> BTW, don't blame Julia for it's being a day later than promised. She

> sent it to me & Susan to put up on Thu, it was my confusion that

> caused the delay.

Now that tei-c.org is up again, we can even get it from the US source.

Thanks to Julia for very useful suggestions in improving the chapter.

For the purpose of discussion, I will paste Julia's document in here

and add my comments:

JF>1. Fixes

JF>1.1. Make  legal within 

JF>

JF>Research by both the Women Writers Project and the Menota Project

JF>indicates that there are cases where passages of verse appear directly

JF>within the flow of prose, embedded within a paragraph, and not

JF>enclosed within a quotation. Examples include cases where the text

JF>shifts from verse to prose in mid-sentence (as in Nordic prosimetrum

JF>texts; see ???Document Structure??? in The Menota Handbook) or where a

JF>speaker in a fictional context begins to compose poetry orally in the

JF>middle of a speech.

Agreed.  I have stumbled over this one a number of times. This should be fixed.

JF>

JF>1.2. Eliminate numbered 

JF>

JF>On same basis as eliminating numbered 
.

Do we get rid of the latter?  Even if not, I am all in favor of

eliminating enumerated .

JF>2. Expansions

JF>2.1. Add attributes

JF>

JF>The Henrik Ibsen project has extended the TEI to add the following attributes to the a.metrical class:

JF>

JF>    * met and realMet : for identifying the ideal and real metrical scheme for the line or line group

JF>    * rhyme and realRhyme : for identifying the ideal and real rhyme scheme for the line group

JF>    * an and realAn : for identifying ideal and real patterns of

JF>    anacruses (unstressed syllables preceding the first stressed

JF>    syllable in a line) for a line or line group

JF>

JF>

JF>The Ibsen project leaves the original TEI real attribute untouched,

JF>but this new scheme renders it redundant (replacing it with

JF>realMet). Of these three attribute pairs, probably the first two are

JF>most generally useful to the TEI community; we have asked the Ibsen

JF>group to give a more detailed rationale for an and realAn, which seem

JF>to replicate the same kind of information as met and realMet.

We should probably consider this in the context of the discussion of

all the other attributes.

JF>

JF>

JF>The Ibsen project defines these as CDATA attributes...

JF>2.2. Stressed vowels

JF>

JF>David Birnbaum mentioned that in his poetry markup he needs to mark

JF>stressed vowels, in addition to the ordinary metrical information for

JF>the line. He suggests a  element, but has not yet elaborated

JF>on this suggestion. We've requested further information from him on

JF>this point.

I wonder how that would be used.  Would you do something like

here 

JF>

JF>

JF>3. Clarifications and discussion

JF>3.1. Verse and overlap

JF>

JF>Martin Mueller suggested that we add a section to the verse chapter

JF>that explicitly addresses overlap in the context of verse, since the

JF>presence of verse lines heightens the likelihood of routine overlap

JF>problems that also occur elsewhere. At present, overlap is discussed

JF>only as a byproduct of segmentation (e.g. to capture part-lines and

JF>encoding of metrical feet). If it were instead broken out into a

JF>subsection of its own, we could also:

JF>

JF>

JF>    * discuss the fact that verse by its nature is more likely to incur overlap problems;

JF>    * point out a few of the most likely overlap issues (encoding of

JF>    quotations and sentences, but also thematic tagging if that is

JF>    present);

JF>

JF>    * list the most common ways of handling these situations

JF>    (fragmentation of quotations using next and prev; the possibility

JF>    of using part on elements other than ; use of milestone

JF>    elements for things like sentence boundaries

JF>

JF>

JF>For some parts of this we might just point to elsewhere in the

JF>Guidelines, but the pointers should be there so that people are aware

JF>of the issues and their solution.

This looks like a useful addition to the chapter to me.  

>

> My first cut at attributes and datatypes is available at 

> http://www.tei-c.org/Drafts/edw90.xml?style=printable. I'm afraid the

> database of devilish details I had hoped to have ready for you is not

> quite up to snuff. You can see an out-of-date version (link is in the

> paper), but it's just too painful to make the current stuff live

> right now. Hopefully in two or three days.

Thanks Syd!

There is a link to your harddisk in that paper (for the W3C regex),

but the php link now seems to be live now, right.

>

> _______________________________________________

> 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 05 2005 - 01:13:52 EDT

From pwillett at umich.edu  Tue Jul  5 08:12:09 2005
From: pwillett at umich.edu (Perry Willett)
Date: Tue, 5 Jul 2005 08:12:09 -0400
Subject: [tei-council] some reports in
In-Reply-To: 
Message-ID: <000c01c5815a$c776f970$922bd38d@CLUBSODA>

From: Perry Willett 

Date: Tue, 5 Jul 2005 08:12:09 -0400

I also agree with the proposal to eliminate numbered lgs, but I don't recall

ever agreeing to give up numbered divs. I would argue strongly in favor of

keeping them.

Perry Willett

University of Michigan

pwillett_at_umich.edu

-----Original Message-----

JF>

JF>1.2. Eliminate numbered 

JF>

JF>On same basis as eliminating numbered 
.

Do we get rid of the latter?  Even if not, I am all in favor of

eliminating enumerated .

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Jul 05 2005 - 08:12:17 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jul  5 08:22:07 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 05 Jul 2005 13:22:07 +0100
Subject: [tei-council] some reports in
In-Reply-To: <000c01c5815a$c776f970$922bd38d@CLUBSODA>
Message-ID: <42CA7B6F.50803@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Tue, 05 Jul 2005 13:22:07 +0100

Perry Willett wrote:

>I also agree with the proposal to eliminate numbered lgs, but I don't recall

>ever agreeing to give up numbered divs. I would argue strongly in favor of

>keeping them.

>  

>

why are numbered divs ok but numbered lgs not?

I too don't recall the subject being discussed formally.

ebastian

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Jul 05 2005 - 08:24:19 EDT

From Syd_Bauman at Brown.edu  Tue Jul  5 08:28:37 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 5 Jul 2005 08:28:37 -0400
Subject: [tei-council] some reports in
In-Reply-To: 
Message-ID: <17098.31989.406811.774447@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Tue, 5 Jul 2005 08:28:37 -0400

> There is a link to your harddisk in that paper (for the W3C regex),

Whoa! Thank you. Fixed. (At least on UVA site; I can't sync UK

mirror.)

> but the php link now seems to be live now, right.

Not quite; it is a live, working link, but to old dead data -- well,

not dead, but 2 days out of date, with at least a dozen errors. I

hope to have a fixed version up shortly (measured in hours, not days)

which will be "live", in that if I make any corrections from that

point on I would make them in MySQL, and you'd see the correction

immediately.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Jul 05 2005 - 08:28:41 EDT

From pwillett at umich.edu  Tue Jul  5 08:32:43 2005
From: pwillett at umich.edu (Perry Willett)
Date: Tue, 5 Jul 2005 08:32:43 -0400
Subject: [tei-council] some reports in
In-Reply-To: <42CA7B6F.50803@computing-services.oxford.ac.uk>
Message-ID: <000e01c5815d$a7060b60$922bd38d@CLUBSODA>

From: Perry Willett 

Date: Tue, 5 Jul 2005 08:32:43 -0400

I've never encountered a need to nest s. 

Perry

-----Original Message-----

From: Sebastian Rahtz

[mailto:sebastian.rahtz_at_computing-services.oxford.ac.uk] 

Sent: Tuesday, July 05, 2005 8:22 AM

To: Perry Willett

Cc: 'TEI Council'

Subject: Re: [tei-council] some reports in

Perry Willett wrote:

>I also agree with the proposal to eliminate numbered lgs, but I don't

recall

>ever agreeing to give up numbered divs. I would argue strongly in favor of

>keeping them.

>  

>

why are numbered divs ok but numbered lgs not?

I too don't recall the subject being discussed formally.

ebastian

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Jul 05 2005 - 08:32:51 EDT

From Syd_Bauman at Brown.edu  Tue Jul  5 08:34:07 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 5 Jul 2005 08:34:07 -0400
Subject: [tei-council] some reports in
In-Reply-To: <000c01c5815a$c776f970$922bd38d@CLUBSODA>
Message-ID: <17098.32319.737813.600607@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Tue, 5 Jul 2005 08:34:07 -0400

> I also agree with the proposal to eliminate numbered lgs, but I

> don't recall ever agreeing to give up numbered divs. I would argue

> strongly in favor of keeping them.

I believe (although I could be mistaken) that Julia meant that the

argument for dropping numbered s is parrallel to the argument for

dropping numbered s, and thus need not be repeated in her paper.

(Rather than that we have already decided to drop numbered s,

which to my knowledge we have discussed briefly but never even

seriously considered, let alone decided).

She should be back from her trip sometime on Wed, so if I'm wrong

she'll hopefully be able to correct me before the 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 05 2005 - 08:34:13 EDT

From nsmith at email.unc.edu  Tue Jul  5 08:44:26 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Tue, 5 Jul 2005 08:44:26 -0400 (Eastern Daylight Time)
Subject: [tei-council] some reports in
In-Reply-To: <000c01c5815a$c776f970$922bd38d@CLUBSODA>
Message-ID: 

From: Natasha Smith 

Date: Tue, 5 Jul 2005 08:44:26 -0400 (Eastern Daylight Time)

> I also agree with the proposal to eliminate numbered lgs, but I don't recall

> ever agreeing to give up numbered divs. I would argue strongly in favor of

> keeping them.

I join Perry on both issues, i.e. in favor of eliminating numbered s

and *keeping* numbered s. I consider it's very important that the

latter was also supported by the "TEI in the Libraries" group that - FYI -

is revived as we speak.

n

> -----Original Message-----

> JF>

> JF>1.2. Eliminate numbered 

> JF>

> JF>On same basis as eliminating numbered .

> 

> Do we get rid of the latter?  Even if not, I am all in favor of

> eliminating enumerated .

> 

> 

> 

> _______________________________________________

> 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 05 2005 - 08:45:45 EDT

From Laurent.Romary at loria.fr  Tue Jul  5 08:43:52 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Tue, 5 Jul 2005 14:43:52 +0200
Subject: [tei-council] some reports in
In-Reply-To: <17098.32319.737813.600607@emt.wwp.brown.edu>
Message-ID: 

From: Laurent Romary 

Date: Tue, 5 Jul 2005 14:43:52 +0200

I would strongly suggest to decouple the two arguments (i.e. numbered 

lgs vs. numbered divs). There are quite a few projects (comprising the 

TEI spec in ODD itself) that are using numbered divs as opposed to very 

few occurances of numbered lgs. As a consequence, I see it an easy 

decision to drop numbered lgs, but (even if I do not like numbered 

divs) would be more coutious in taking a similar decisions for 

divisions.

Laurent

Le 5 juil. 05, ? 14:34, Syd Bauman a ?crit :

>> I also agree with the proposal to eliminate numbered lgs, but I

>> don't recall ever agreeing to give up numbered divs. I would argue

>> strongly in favor of keeping them.

>

> I believe (although I could be mistaken) that Julia meant that the

> argument for dropping numbered s is parrallel to the argument for

> dropping numbered s, and thus need not be repeated in her paper.

> (Rather than that we have already decided to drop numbered s,

> which to my knowledge we have discussed briefly but never even

> seriously considered, let alone decided).

>

> She should be back from her trip sometime on Wed, so if I'm wrong

> she'll hopefully be able to correct me before the conference call.

>

> _______________________________________________

> 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 05 2005 - 08:46:29 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jul  5 09:10:23 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 05 Jul 2005 14:10:23 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: 
Message-ID: <42CA86BF.9080901@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Tue, 05 Jul 2005 14:10:23 +0100

Christian Wittern wrote:

>

>On Debian, you could at least use symlinks from somewhere in the doc

>substree to all these other places. 

>

symlinks are such a pain for portability, though

>

>

>Wouldnt it be rather

>

>/usr/local/share/tei/xml/schema whatever

>

>on these systems?

>  

>

yes, probably. we only care about what's below "share", whether thats

/usr or /usr/local.

ebastian

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Jul 05 2005 - 09:12:33 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Jul  5 18:44:46 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 06 Jul 2005 07:44:46 +0900
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C8692D.2040002@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Wed, 06 Jul 2005 07:44:46 +0900

Sebastian Rahtz oxford.ac.uk> writes:

> I have revised my proposal, with the results appended

>

> I have not changed the XSL layout, as it has a fair few ramifications

> for me to clean up.

Now that I have given up my reservations against the following

proposal -- and I have not seen any other objections so far -- I

wonder if we can agree on this structure?  I would like to see it used

in 

 * an archive downloadable from SF

 * a live location on the TEI websites and/or on the SF HTML area

 * included in XML editors like oXygen 

 * etc., etc.

Please think through this and voice any concerns now!

One issue that came to my mind is how to root it on Windows. C;/share/

looks a bit silly, so maybe we want c;/TEI/ for the root of the tree.

This does not matter for oXygen of course, but might be of concern to

generic installations. 

>

> share

> |-- doc

> |   `-- tei

> |       |-- html

> |       |   |-- base

> |       |   |   |-- p4

> |       |   |   |   `-- Figures

> |       |   |   `-- p5

> |       |   `-- exemplars

> |       |       `-- p5

> |       |-- web

> |       |   `-- Query

> |       `-- xml

> |           `-- exemplars

> |               `-- p5

> `-- xml

>     `-- tei

>         |-- odd

>         |   `-- exemplars

>         |       |-- p4

>         |       `-- p5

>         |-- schema

>         |   |-- dtd

>         |   |   |-- p4

>         |   |   `-- p5

>         |   |-- relaxng

>         |   |   |-- p4

>         |   |   `-- p5

>         |   `-- xsd

>         |       `-- p5

>         `-- stylesheet

>             |-- base

>             |   |-- p4

>             |   |   |-- common

>             |   |   |-- fo

>             |   |   |-- html

>             |   |   `-- latex

>             |   `-- p5

>             |       |-- common

>             |       |-- fo

>             |       |-- html

>             |       `-- latex

>             |-- odds

>             |-- slides

>             `-- teic

>

> 44 directories

>

>

> -- 

> 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

-- 
 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 05 2005 - 20:58:06 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jul  5 18:02:50 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 05 Jul 2005 23:02:50 +0100
Subject: [tei-council] directory layout again
Message-ID: <42CB038A.9070603@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Tue, 05 Jul 2005 23:02:50 +0100

After much agonizing, I am still unhappy with this directory layout for

the TEI, and

I want to propose a radical new direction. viz, split TEI P4 ("TEI

Classic") and

TEI P5 ("TEI Low Fat") into entirely separate, parallel, applications.

So, on a Linux system, you

might see

  /usr/share/xml/teiclassic

  /usr/share/xml/tei

  /usr/share/xml/docbook

  /usr/share/xml/xhtml

o there would be no "p4" or "p5" layers anywhere, you would just choose

a tree at the top level to work with. It simplifies lots of things, and

makes it

easier to document. I cannot think of a situation where we mingle P4 and P5.

What do folks think? I know the big problem is that only one thing can

be called "tei",

so either P4 or P5 gets a new name. I believe that P5 should get the

"tei" name, since

it is where we are working, and we have started on our 0.1 release.

-- 
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 Jul 05 2005 - 20:58:07 EDT

From Syd_Bauman at Brown.edu  Tue Jul  5 21:35:43 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 5 Jul 2005 21:35:43 -0400
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: 
Message-ID: <17099.13679.488888.552903@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Tue, 5 Jul 2005 21:35:43 -0400

> Please think through this and voice any concerns now!

I'm thinking, but I probably will not get to post on this until late

tomorrow, at the earliest.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Jul 05 2005 - 21:35:52 EDT

From Syd_Bauman at Brown.edu  Tue Jul  5 21:42:46 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 5 Jul 2005 21:42:46 -0400
Subject: [tei-council] directory layout again
In-Reply-To: <42CB038A.9070603@computing-services.oxford.ac.uk>
Message-ID: <17099.14102.247157.507822@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Tue, 5 Jul 2005 21:42:46 -0400

I thought we'd already expressed this preference, and Mark Johnson

essentially nuked it, pointing out that all the other Debian XML

installations follow the /usr/share/[name]/schema/dtd/[versions]/

kind of pattern (most notably DocBook).

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Jul 05 2005 - 21:42:50 EDT

From Syd_Bauman at Brown.edu  Tue Jul  5 22:17:26 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 5 Jul 2005 22:17:26 -0400
Subject: [tei-council] attribute/datatype data updated
Message-ID: <17099.16182.187769.211850@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Tue, 5 Jul 2005 22:17:26 -0400

The database of TEI attributes and their suggsted datatypes has been

updated. I fixed dozens of errors, but I have this knawing feeling

that I introduced a couple of new ones. :-)

In any case, follow the link to the PHP interface from ED W 90, which

has also been updated a teeny bit (on the UVA server, which seems to

be down again), and is at

  http://www.tei-c.org/Drafts/edw90.xml?style=printable

  http://www.tei-c.org.uk/Drafts/edw90.xml?style=printable

I think it is probably a bit much to ask every Council member to look

at all 541 entries before Fri morning. But every Council member

should certainly read ED W 90 (and feel free to ask questions on or

off list if there are parts you don't understand -- or to suggest

corrections to any explanations that are hard to understand, etc.)

and at least scan the database of attributes. Search for the

attributes you care about. Scan for "?"; sort the list by suggested

declaration and look for weird ones; look through those that are

declared as tei.data.code to see if there are any you think should be

tei.data.key or tei.data.enumerated; etc.

Perhaps later we should set up an actual review process.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Jul 05 2005 - 22:17:30 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jul  6 00:55:19 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 06 Jul 2005 05:55:19 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <17099.14102.247157.507822@emt.wwp.brown.edu>
Message-ID: <42CB6437.6020502@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Wed, 06 Jul 2005 05:55:19 +0100

Syd Bauman wrote:

>I thought we'd already expressed this preference, and Mark Johnson

>essentially nuked it, pointing out that all the other Debian XML

>installations follow the /usr/share/[name]/schema/dtd/[versions]/

>kind of pattern (most notably DocBook).

>  

>

but on reading the Debian XML policy again, it says clearly

that you can NOT have versions of stylesheets.  so we break

their rules with what I proposed  a few days ago. and our p4/p5 are

not really _versions_ of the stylesheets

We could still

have [name]/schema/dtd/[version], but then it will be /0.1, /0.2 etc

though I'd suggest its not needed,

its possible that I could break up just the stylesheet tree into

top-level "tei" and "teiclassic", I suppose

-- 
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 Jul 06 2005 - 00:55:40 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jul  6 01:05:23 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 06 Jul 2005 06:05:23 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: 
Message-ID: <42CB6693.1030704@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Wed, 06 Jul 2005 06:05:23 +0100

Christian Wittern wrote:

>One issue that came to my mind is how to root it on Windows. C;/share/

>looks a bit silly, so maybe we want c;/TEI/ for the root of the tree.

>This does not matter for oXygen of course, but might be of concern to

>generic installations. 

>  

>

I don't know much about Windows conventions, but c:\tei does not

look normal to me. Windows just doesn't create new stuff at the root,

does it?

omeone who uses it might like to comment.

-- 
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 Jul 06 2005 - 01:05:48 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jul  6 07:58:10 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 06 Jul 2005 20:58:10 +0900
Subject: [tei-council] Agenda for TEI Council conference call on Friday 2005-07-08, 1300 UTC
Message-ID: 

From: Christian Wittern 

Date: Wed, 06 Jul 2005 20:58:10 +0900

TEI Council Members and Editors:

This is the agenda for the conference call the TEI Council will

hold Friday, July 8th, 2005 at 1300 UTC.

Please read through the following, in advance of the call.  

INSTRUCTIONS for conference call:

Participants will dial in to +1 812 856 3550.

When prompted, enter the code "0920" followed by "#".

Expected members to participate:

Syd Bauman, Alejandro Bia, Lou Burnard, James Cummings, Matthew

Driscoll, Julia Flanders, Sebastian Rahtz, Laurent Romary, Natasha

Smith, John Walsh, Perry Willett, Christian Wittern.

Susan Schreibman excused herself while en-route to Ireland,

Edward Vanhoutte is busy working on his thesis while we talk.

Agenda:

5 items, not more than 10-20 minutes apiece.

-----------------------------------------------------

1) Review of the minutes and action items (10 min)

   Minutes of the meeting are at

         http://www.tei-c.org/Council/tcm17.html. 

         To speed up the review of action items, *please report to the

         council list* before the call! 

         We will discuss the reports here as necessary.

------------------------------------------------------------

2) Review of WG etc. progress (10 min) : 

  Standoff Markup,  Feature Structures, Physical

  Bibliography, biblItem, IHS

        Same her, please do report to the list!

-----------------------------------------------------

3) P5 progress:  (20 min)

- principles for publication of snapshots etc. of P5

  Status: a proposal from Sebastian and subsequent discussion, we need to come

  to a decision.

- directory layout:  

        Status: several conflicting proposals. Hope we sort some of this out

        before the call.

- I18N infrastructure for translations of gloss and desc, vallists etc

  Status: some discussion, but no proposal yet - need to consider

  aligning with W3C ITS effort (I (CW) hope to have some news on this

  by Thursday JTS)

- on Attributes and Datatypes (EDW90)

        http://www.tei-c.org.uk/Drafts/edw90.xml?style=printable

        Please read through this and comment, preferably to the list.

-----------------------------------------------------

4) Other business  (5 minutes)

   TBA

-----------------------------------------------------

5) Meetings: (5 minutes)

   Next call, members meeting preparations.

-- 
 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 06 2005 - 07:58:24 EDT

From pwillett at umich.edu  Wed Jul  6 08:20:47 2005
From: pwillett at umich.edu (Perry Willett)
Date: Wed, 6 Jul 2005 08:20:47 -0400
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42CB6693.1030704@computing-services.oxford.ac.uk>
Message-ID: <000301c58225$267b1ad0$922bd38d@CLUBSODA>

From: Perry Willett 

Date: Wed, 6 Jul 2005 08:20:47 -0400

I'm no expert here, but I think the Windows convention is to install either

in "c:\Program Files" or "c:\Documents and Settings". Although not a

program, I would think the former is more appropriate. It's no problem to

install at root, however.

Perry

-----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: Wednesday, July 06, 2005 1:05 AM

To: Christian Wittern

Cc: TEI Council

Subject: Re: [tei-council] directory layout of a TEI distribution

Christian Wittern wrote:

>One issue that came to my mind is how to root it on Windows. C;/share/

>looks a bit silly, so maybe we want c;/TEI/ for the root of the tree.

>This does not matter for oXygen of course, but might be of concern to

>generic installations. 

>  

>

I don't know much about Windows conventions, but c:\tei does not

look normal to me. Windows just doesn't create new stuff at the root,

does it?

omeone who uses it might like to comment.

-- 
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 Jul 06 2005 - 08:20:53 EDT

From mjd at hum.ku.dk  Wed Jul  6 09:02:01 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Wed, 06 Jul 2005 15:02:01 +0200
Subject: [tei-council] some reports in
In-Reply-To: <000e01c5815d$a7060b60$922bd38d@CLUBSODA>
Message-ID: <42CBF269.9756.151EAF5@localhost>

From: M. J. Driscoll 

Date: Wed, 06 Jul 2005 15:02:01 +0200

> I've never encountered a need to nest s. 

> 

> Perry

Just to this one point, I nest s all the time, for 

example where a stanza consists of two half-stanzas, as in 

skaldic poetry, or in carols and similar poetry where there 

is a burden or refrain, which is part of, but separate 

from, the verse to which it is attached. I never, on the 

other hand, use numbered s, or numbered s for that 

matter (having been told not to by a certain LB).

MJD

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Jul 06 2005 - 09:02:09 EDT

From pwillett at umich.edu  Wed Jul  6 10:33:01 2005
From: pwillett at umich.edu (Perry Willett)
Date: Wed, 6 Jul 2005 10:33:01 -0400
Subject: [tei-council] some reports in
In-Reply-To: <42CBF269.9756.151EAF5@localhost>
Message-ID: <000f01c58237$9fa26780$922bd38d@CLUBSODA>

From: Perry Willett 

Date: Wed, 6 Jul 2005 10:33:01 -0400

Thanks, Matthew, I should have added that almost all of my encoding has been

from 19th century sources, which are about as conventional as you can get.

Perry

-----Original Message-----

From: tei-council-bounces_at_lists.village.Virginia.EDU

[mailto:tei-council-bounces_at_lists.village.Virginia.EDU] On Behalf Of M. J.

Driscoll

Sent: Wednesday, July 06, 2005 9:02 AM

To: 'TEI Council'

Subject: RE: [tei-council] some reports in

> I've never encountered a need to nest s. 

> 

> Perry

Just to this one point, I nest s all the time, for 

example where a stanza consists of two half-stanzas, as in 

skaldic poetry, or in carols and similar poetry where there 

is a burden or refrain, which is part of, but separate 

from, the verse to which it is attached. I never, on the 

other hand, use numbered s, or numbered 
s for that 

matter (having been told not to by a certain LB).

MJD

_______________________________________________

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 06 2005 - 10:33:08 EDT

From Julia_Flanders at Brown.edu  Wed Jul  6 14:59:57 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Wed, 6 Jul 2005 14:59:57 -0400
Subject: [tei-council] some reports in
In-Reply-To: <000e01c5815d$a7060b60$922bd38d@CLUBSODA>
Message-ID: 

From: Julia Flanders 

Date: Wed, 6 Jul 2005 14:59:57 -0400

Does this mean that if you did need to nest s you would want to 

have numbered ones available? I am aware of quite a number of 

projects that do nest  fairly extensively (none of which use 

numbered  ).

At 8:32 AM -0400 7/5/05, Perry Willett wrote:

>I've never encountered a need to nest s.

>

>Perry

>

>

>-----Original Message-----

>From: Sebastian Rahtz

>[mailto:sebastian.rahtz_at_computing-services.oxford.ac.uk]

>Sent: Tuesday, July 05, 2005 8:22 AM

>To: Perry Willett

>Cc: 'TEI Council'

>Subject: Re: [tei-council] some reports in

>

>Perry Willett wrote:

>

>>I also agree with the proposal to eliminate numbered lgs, but I don't

>recall

>>ever agreeing to give up numbered divs. I would argue strongly in favor of

>>keeping them.

>>

>>

>

>why are numbered divs ok but numbered lgs not?

>

>I too don't recall the subject being discussed formally.

>

>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 Wed Jul 06 2005 - 15:00:06 EDT

From pwillett at umich.edu  Wed Jul  6 15:33:04 2005
From: pwillett at umich.edu (Perry Willett)
Date: Wed, 6 Jul 2005 15:33:04 -0400
Subject: [tei-council] some reports in
In-Reply-To: 
Message-ID: <004401c58261$8a8c3450$922bd38d@CLUBSODA>

From: Perry Willett 

Date: Wed, 6 Jul 2005 15:33:04 -0400

Hmm, well, as I say, I haven't encountered them (to my relief). I guess if

on the witness stand and forced to answer, I would say I wouldn't use

numbered lgs. ("Aha!" exclaims opposing counsel triumphantly.) Still, I

stick to wanting numbered divs. 

Perry (haunted by the hobgoblins of his inconsistency).

-----Original Message-----

From: tei-council-bounces_at_lists.village.Virginia.EDU

[mailto:tei-council-bounces_at_lists.village.Virginia.EDU] On Behalf Of Julia

Flanders

Sent: Wednesday, July 06, 2005 3:00 PM

To: tei-council_at_lists.village.Virginia.EDU

Subject: RE: [tei-council] some reports in

Does this mean that if you did need to nest s you would want to 

have numbered ones available? I am aware of quite a number of 

projects that do nest  fairly extensively (none of which use 

numbered  ).

At 8:32 AM -0400 7/5/05, Perry Willett wrote:

>I've never encountered a need to nest s.

>

>Perry

>

>

>-----Original Message-----

>From: Sebastian Rahtz

>[mailto:sebastian.rahtz_at_computing-services.oxford.ac.uk]

>Sent: Tuesday, July 05, 2005 8:22 AM

>To: Perry Willett

>Cc: 'TEI Council'

>Subject: Re: [tei-council] some reports in

>

>Perry Willett wrote:

>

>>I also agree with the proposal to eliminate numbered lgs, but I don't

>recall

>>ever agreeing to give up numbered divs. I would argue strongly in favor of

>>keeping them.

>>

>>

>

>why are numbered divs ok but numbered lgs not?

>

>I too don't recall the subject being discussed formally.

>

>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

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Jul 06 2005 - 15:33:11 EDT

From lou.burnard at computing-services.oxford.ac.uk  Wed Jul  6 16:55:51 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 06 Jul 2005 21:55:51 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <42CB038A.9070603@computing-services.oxford.ac.uk>
Message-ID: <42CC4557.9050501@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Wed, 06 Jul 2005 21:55:51 +0100

Sebastian Rahtz wrote:

>So, on a Linux system, you

>might see

>

>  /usr/share/xml/teiclassic

>  /usr/share/xml/tei

>  /usr/share/xml/docbook

>  /usr/share/xml/xhtml

>

>so there would be no "p4" or "p5" layers anywhere, you would just choose

>a tree at the top level to work with. It simplifies lots of things, and

>makes it

>easier to document. I cannot think of a situation where we mingle P4 and P5.

>

>What do folks think? I know the big problem is that only one thing can

>be called "tei",

>so either P4 or P5 gets a new name. I believe that P5 should get the

>"tei" name, since

>it is where we are working, and we have started on our 0.1 release.

>

>  

>

Just for the record, I think this is a brilliant idea.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Jul 06 2005 - 17:00:38 EDT

From James.Cummings at computing-services.oxford.ac.uk  Wed Jul  6 17:33:34 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 06 Jul 2005 22:33:34 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <42CC4557.9050501@computing-services.oxford.ac.uk>
Message-ID: <42CC4E2E.9080003@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Wed, 06 Jul 2005 22:33:34 +0100

Lou Burnard wrote:

> Sebastian Rahtz wrote:

> 

>> So, on a Linux system, you

>> might see

>>

>>  /usr/share/xml/teiclassic

>>  /usr/share/xml/tei

>>  /usr/share/xml/docbook

>>  /usr/share/xml/xhtml

>>

>> so there would be no "p4" or "p5" layers anywhere, you would just choose

>> a tree at the top level to work with. It simplifies lots of things, and

>> makes it

>> easier to document. I cannot think of a situation where we mingle P4 

>> and P5.

>>

>> What do folks think? I know the big problem is that only one thing can

>> be called "tei",

>> so either P4 or P5 gets a new name. I believe that P5 should get the

>> "tei" name, since

>> it is where we are working, and we have started on our 0.1 release.

> 

> Just for the record, I think this is a brilliant idea.

I think it is a good idea... though I must admit some apprehensions 

with the name teiclassic.

-James

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Jul 06 2005 - 17:33:26 EDT

From nsmith at email.unc.edu  Wed Jul  6 17:56:34 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Wed, 6 Jul 2005 17:56:34 -0400 (Eastern Daylight Time)
Subject: [tei-council] directory layout again
In-Reply-To: <42CC4E2E.9080003@computing-services.oxford.ac.uk>
Message-ID: 

From: Natasha Smith 

Date: Wed, 6 Jul 2005 17:56:34 -0400 (Eastern Daylight Time)

> >>  /usr/share/xml/teiclassic

> >>  /usr/share/xml/tei

> >>  /usr/share/xml/docbook

> >>  /usr/share/xml/xhtml

i liked this idea for its lucidity. there were many good ideas along the

way, but not once they clashed and contradicted. this one gave a

prospective to look at the structure in a much more clear way - at least

to me. Classic? hmmm, why not leave it as p4? Everybody know what it is,

only if we want to raise it to the rank of living classics...

n

> >> so there would be no "p4" or "p5" layers anywhere, you would just choose

> >> a tree at the top level to work with. It simplifies lots of things, and

> >> makes it

> >> easier to document. I cannot think of a situation where we mingle P4 

> >> and P5.

> >>

> >> What do folks think? I know the big problem is that only one thing can

> >> be called "tei",

> >> so either P4 or P5 gets a new name. I believe that P5 should get the

> >> "tei" name, since

> >> it is where we are working, and we have started on our 0.1 release.

> > 

> > Just for the record, I think this is a brilliant idea.

> 

> I think it is a good idea... though I must admit some apprehensions 

> with the name teiclassic.

> 

> -James

> _______________________________________________

> 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 06 2005 - 17:56:54 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jul  6 18:47:01 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 07 Jul 2005 07:47:01 +0900
Subject: [tei-council] directory layout again
In-Reply-To: <42CB038A.9070603@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Thu, 07 Jul 2005 07:47:01 +0900

Sebastian Rahtz oxford.ac.uk> writes:

>   /usr/share/xml/teiclassic

>   /usr/share/xml/tei

>   /usr/share/xml/docbook

>   /usr/share/xml/xhtml

>

Hmm, what do you do when P6 comes along?  Or do we just continue with

P5 forever?

   /usr/share/xml/teip4

   /usr/share/xml/teip5

   /usr/share/xml/docbook

   /usr/share/xml/xhtml

On systems that allow this, you could then do a symlink from

  /usr/share/xml/tei

to the one you want to call that.

Having said that, I kind of prefer the one-tree-does-it-all solution.

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 06 2005 - 18:47:06 EDT

From lou.burnard at computing-services.oxford.ac.uk  Wed Jul  6 18:59:59 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 06 Jul 2005 23:59:59 +0100
Subject: [tei-council] directory layout again
In-Reply-To: 
Message-ID: <42CC626F.7010903@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Wed, 06 Jul 2005 23:59:59 +0100

I think the idea is that when P6 comes along, P5 becomes the 

"teiclassic" -- in other words, that the names are kind of symlinks.

Another option would be to rename P5 as "teirenaissance" I suppose...

Christian Wittern wrote:

>Sebastian Rahtz oxford.ac.uk> writes:

>

>  

>

>>  /usr/share/xml/teiclassic

>>  /usr/share/xml/tei

>>  /usr/share/xml/docbook

>>  /usr/share/xml/xhtml

>>

>>    

>>

>

>Hmm, what do you do when P6 comes along?  Or do we just continue with

>P5 forever?

>

>   /usr/share/xml/teip4

>   /usr/share/xml/teip5

>   /usr/share/xml/docbook

>   /usr/share/xml/xhtml

>

>On systems that allow this, you could then do a symlink from

>  /usr/share/xml/tei

>to the one you want to call that.

>

>Having said that, I kind of prefer the one-tree-does-it-all solution.

>

>Christian

>  

>

>  

>

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Jul 06 2005 - 18:59:59 EDT

From James.Cummings at computing-services.oxford.ac.uk  Wed Jul  6 19:09:57 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 07 Jul 2005 00:09:57 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <42CC626F.7010903@computing-services.oxford.ac.uk>
Message-ID: <42CC64C5.7020902@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Thu, 07 Jul 2005 00:09:57 +0100

Lou Burnard wrote:

> I think the idea is that when P6 comes along, P5 becomes the 

> "teiclassic" -- in other words, that the names are kind of symlinks.

> 

> Another option would be to rename P5 as "teirenaissance" I suppose...

I was envisioning that teiclassic (or tei-p4 or whatever) would always 

only just contain TEI P4 (and previous P-versions?) and the from TEI 

P5 onwards the tei package would just stay and get new numerical 

version numbers. So tei 1.5 (or whatever) becomes tei 1.6, 1.6.1, etc. 

  Installing earlier versions of the tei package is easy (as long as 

they remain available).  So P6 never arrives, but the guidelines 

continue to develop.  If in 5 years you want to install the P5 version 

you just install an earlier version of the same package.

Or are we tied permanently to fixed P-Versions?

Just curious,

-James

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Jul 06 2005 - 19:10:01 EDT

From lou.burnard at computing-services.oxford.ac.uk  Wed Jul  6 19:21:42 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 07 Jul 2005 00:21:42 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <42CC64C5.7020902@computing-services.oxford.ac.uk>
Message-ID: <42CC6786.1060708@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Thu, 07 Jul 2005 00:21:42 +0100

Yes! I like this idea *even better* !!

Lou (who neever wants to have to explain what "P" is short for again)

James Cummings wrote:

> Lou Burnard wrote:

>

>> I think the idea is that when P6 comes along, P5 becomes the 

>> "teiclassic" -- in other words, that the names are kind of symlinks.

>>

>> Another option would be to rename P5 as "teirenaissance" I suppose...

>

>

> I was envisioning that teiclassic (or tei-p4 or whatever) would always 

> only just contain TEI P4 (and previous P-versions?) and the from TEI 

> P5 onwards the tei package would just stay and get new numerical 

> version numbers. So tei 1.5 (or whatever) becomes tei 1.6, 1.6.1, etc. 

>  Installing earlier versions of the tei package is easy (as long as 

> they remain available).  So P6 never arrives, but the guidelines 

> continue to develop.  If in 5 years you want to install the P5 version 

> you just install an earlier version of the same package.

>

> Or are we tied permanently to fixed P-Versions?

>

> Just curious,

> -James

> _______________________________________________

> 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 06 2005 - 19:21:32 EDT

From lou.burnard at computing-services.oxford.ac.uk  Wed Jul  6 19:32:42 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 07 Jul 2005 00:32:42 +0100
Subject: [tei-council] Oxygen P5 Instructions
In-Reply-To: <42C6AB01.2020400@computing-services.oxford.ac.uk>
Message-ID: <42CC6A1A.4040505@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Thu, 07 Jul 2005 00:32:42 +0100

Sebastian Rahtz wrote:

>

>>TML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/

>>oxygenValidationInstructions.html

>>TEI/XML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/

>>oxygenValidationInstructions.xml

>>

>>    

>>

>any reason not to put this on the TEI web site?

>

>

>  

>

I can't think of any, so I have done put it there 

(http://www.tei-c.org/Software/ now links to it). John, plz object if 

you wish to.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Jul 06 2005 - 19:32:32 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jul  6 22:44:26 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 07 Jul 2005 11:44:26 +0900
Subject: [tei-council] directory layout again
In-Reply-To: <42CC64C5.7020902@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Thu, 07 Jul 2005 11:44:26 +0900

James Cummings oxford.ac.uk> writes:

> I was envisioning that teiclassic (or tei-p4 or whatever) would always

> only just contain TEI P4 (and previous P-versions?) and the from TEI

> P5 onwards the tei package would just stay and get new numerical

> version numbers. So tei 1.5 (or whatever) becomes tei 1.6, 1.6.1,

> etc. Installing earlier versions of the tei package is easy (as long

> as they remain available).  So P6 never arrives, but the guidelines

> continue to develop.  If in 5 years you want to install the P5 version

> you just install an earlier version of the same package.

>

>

That's what I meant when I said "going on with P5 forever". 

Of course, what this burns down to is that we can't introduce changes

that are not backward compatible.

> Or are we tied permanently to fixed P-Versions?

This is more of a marketing issue, I assume.

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 Jul 06 2005 - 22:44:33 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jul  6 22:48:04 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 07 Jul 2005 11:48:04 +0900
Subject: [tei-council] Oxygen P5 Instructions
In-Reply-To: <42CC6A1A.4040505@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Thu, 07 Jul 2005 11:48:04 +0900

Lou Burnard oxford.ac.uk> writes:

> Sebastian Rahtz wrote:

>>>TML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/

>>>oxygenValidationInstructions.html

>>>TEI/XML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/

>>>oxygenValidationInstructions.xml

>>any reason not to put this on the TEI web site?

> I can't think of any, so I have done put it there

> (http://www.tei-c.org/Software/ now links to it). John, plz object if

> you wish to.

The "replacement set" you mention in the oXygen paragraph there, is

that using the "old" layout, or is it the one we are discussing? And

did you find a good location to put the "live" version of that

framework, that is, the version the catalog in oXygen will link to?

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 Jul 06 2005 - 22:48:10 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jul  6 22:52:53 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 07 Jul 2005 11:52:53 +0900
Subject: [tei-council] [AIR] Review of "Default Text Structure" and "Simple Analytic Mechanism" not ready:-(
Message-ID: 

From: Christian Wittern 

Date: Thu, 07 Jul 2005 11:52:53 +0900

Council members,

Still not being able to find the notes I scribbled down during the

long train rides and lonely evenings on the road to Paris, I have to

apologize that my review for the above mentioned chapters is not yet

ready:-(  I will redo it and post to the list as soon as I can find

some time for this, which will be not before the tomorrows call, but

hopefully before the following one.

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 Jul 06 2005 - 22:52:59 EDT

From Syd_Bauman at Brown.edu  Wed Jul  6 23:53:49 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 6 Jul 2005 23:53:49 -0400
Subject: [tei-council] directory layout again
In-Reply-To: 
Message-ID: <17100.42829.950864.161741@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Wed, 6 Jul 2005 23:53:49 -0400

While I don't like explaining what the "P" stands for either, I am

going to have to sit down and study this for awhile to figure out how

it fits into the Debian guidelines before I decide whether I think

it's a good idea or not. Which I hope to try to do before the

conference call, but it's going to be tough.

And I really *hate* the name "teiclassic". If we do end up with this

high-level versioning, let's make it tei4/ and tei5/, eh?

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Jul 06 2005 - 23:53:54 EDT

From lou.burnard at computing-services.oxford.ac.uk  Thu Jul  7 04:26:37 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 07 Jul 2005 09:26:37 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <17100.42829.950864.161741@emt.wwp.brown.edu>
Message-ID: <42CCE73D.5060802@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Thu, 07 Jul 2005 09:26:37 +0100

Syd Bauman wrote:

>

>And I really *hate* the name "teiclassic". If we do end up with this

>high-level versioning, let's make it tei4/ and tei5/, eh?

>

>_

>

Sorry, but I disagree. We've suffered from years from having a tag 

called tei.2 -- let's make the naming reflect the reality of the 

situation. There is P4 which we have agreed to freeze and to maintain in 

parallel for a few years, and there is the current version of the TEI, 

which is (as it happens) P5. It might become P6 one day, but it *is* 

currently the TEI proposals. If someone asks "what does the TEI say 

about c haracter encoding" the correct answer is what it says in P5, 

possibly with a back reference to what it used to say in P4.  So I think 

that P4 is the "marked case" as linguists say and should have a 

different name. I'm not married to "teiclassic" but it does convey what 

I think we want to say about this other version rather well --despite 

the associations with a well known marketing fiasco!

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Jul 07 2005 - 04:31:39 EDT

From James.Cummings at computing-services.oxford.ac.uk  Thu Jul  7 05:14:45 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 07 Jul 2005 10:14:45 +0100
Subject: [tei-council] [AIR] Review of "Default Text Structure" and "Simple Analytic Mechanism" not ready:-(
In-Reply-To: 
Message-ID: <42CCF285.7060605@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Thu, 07 Jul 2005 10:14:45 +0100

Christian Wittern wrote:

> Council members,

> 

> Still not being able to find the notes I scribbled down during the

> long train rides and lonely evenings on the road to Paris, I have to

> apologize that my review for the above mentioned chapters is not yet

> ready:-(  I will redo it and post to the list as soon as I can find

> some time for this, which will be not before the tomorrows call, but

> hopefully before the following one.

On that note, I have a couple actions outstanding from the Paris meeting.

Chapter Reviews:

DR (Drama) -- I've read through it twice and approached people I thought might 

have had problems using it.  I can up with a series of hypothetical "should 

there be a better way of doing X" questions mainly based on the fact that DR is 

meant to be used for any type of performance and not just drama and have 

forwarded them to Perry (whom I'm collaborating with), but we've both been very 

busy so I don't think we'll have any concrete recommendations by tomorrow.

ND (Names & Dates) -- I approached the Ontology SIG in case they had any input 

on this, and while "Feeding back recommendations to P5" is one of the items on 

their agenda, they have not yet come to any conclusions.  I think that one of 

the considerations is Julia and Perry's investigation of @reg on naming 

elements.  Genealogists using XML that I approached (as a subject field using 

names and dates extensively in specific ways) suggested some changes, and some 

seemed to feel that the dating mechanisms could be improved.  (Specifically 

mechanisms for indicating that an event happened notBefore, Before, After, 

notAfter, a particular date.  Or that it definitely happened in a particular 

dateRange but that this was a range only because it was unknown rather than 

actually being a range.  Or the *bizarre* situation of not wanting YearMonth 

datatype but a YearDay: where you know something took place on the 14th of a 

particular year but not what month. (As I said, bizarre, and I think not catered 

for in W3C datatypes?))  In general there *are* ways of indicating these things 

in TEI dates, though some are rather clunky, and these sorts of dates are the 

types which are used in genealogy a lot.   I have yet to come up with any 

concrete proposals, suggestions or thoughts about names and dates, or discuss 

them with Perry.  Mea Culpa.

README:

I'm about half-way through writing a README for the CVS Stylesheets module, and 

thought while I'm at it to do one for the other modules (or one for all CVS 

modules that can create the individual ones).  This isn't a highly contentious 

issue though and so I'll finish before the conference call after this one. Mea 

Culpa.

Apologies for my tardiness with these issues, I apologise for them now so that I 

don't need to waste people's time during the conference call doing so.

-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 07 2005 - 05:16:18 EDT

From James.Cummings at computing-services.oxford.ac.uk  Thu Jul  7 06:31:38 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 07 Jul 2005 11:31:38 +0100
Subject: [tei-council] attribute/datatype data updated
In-Reply-To: <17099.16182.187769.211850@emt.wwp.brown.edu>
Message-ID: <42CD048A.6030204@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Thu, 07 Jul 2005 11:31:38 +0100

Syd Bauman wrote:

> The database of TEI attributes and their suggsted datatypes has been

> updated. I fixed dozens of errors, but I have this knawing feeling

> that I introduced a couple of new ones. :-)

> 

> In any case, follow the link to the PHP interface from ED W 90, which

> has also been updated a teeny bit (on the UVA server, which seems to

> be down again), and is at

>   http://www.tei-c.org/Drafts/edw90.xml?style=printable

>   http://www.tei-c.org.uk/Drafts/edw90.xml?style=printable

> 

> I think it is probably a bit much to ask every Council member to look

> at all 541 entries before Fri morning. But every Council member

> should certainly read ED W 90 (and feel free to ask questions on or

> off list if there are parts you don't understand -- or to suggest

> corrections to any explanations that are hard to understand, etc.)

> and at least scan the database of attributes. Search for the

> attributes you care about. Scan for "?"; sort the list by suggested

> declaration and look for weird ones; look through those that are

> declared as tei.data.code to see if there are any you think should be

> tei.data.key or tei.data.enumerated; etc.

Why is tei.data.duration set up defaultly not to allow plurals?  Things take 3 

weeks (or longer :-) ) not 3 week.  I think in addition to wk/yr/week/year/month 

there should be wks/yrs/weeks/years/months.  I would abbreviate month as 

mnth/mnths, if I did at all.

Some random thoughts on http://dev.stg.brown.edu/staff/Syd_Bauman/edw90.php :

@calendar = What about Lunar & Solar (as more vague types of astronomical?), 

Gregorian? I believe the Tibetan calendar is different from the Chinese one. I 

would personally like 'Regnal' since many of the dates I've used are in an 

English Regnal calendar.  (I.e. 5 Edward III for the 5th year of the reign of 

Edward III).  'Fiscal' could be another type of calendar, since that fixes each 

month a a specific number of weeks to facilitate economic comparisons.  Maybe 

'Liturgical'...but there are different ones depending on faith.  There are 

others at http://en.wikipedia.org/wiki/List_of_calendars

@character on   Are 'Shaky', 'Thick' and 'Regular' the appropriate 

palaeographic terms?  I realise it has tei.data.token as well, but surely 

something can be 'Thin' but not 'Shaky'?  (Sounds like milkshakes...)

@cols/@columns = I've not looked at this at all, but it just seems strange that 

these are different datatypes.  So I just mention it to remind me to look at it!

@date on  = Why not tei.data.temporalExpression?

@ed on  = point to xml:id on  maybe?

@exact = I think I agree with the comment.

@feature on  = should include tei.data.token ?

@form on  = Should other formats be included? video.MPEG7 audio.MP3? 

Or does this relate only to the physical form?  Also, what about 'webpage'?

@place = Should these include tei.data.token for transcriptions of non-standard 

objects?

@type on  = Would 'data' or some such be a possibility for recordings 

that are of data that is not either audio or video? Not sure if anyone would use it.

@type on  = ugh.  Shouldn't 'acronym' go into the list with title/org/etc. 

since is both the reason for an abbr while also the method?  Why is 

superscription by itself?  Is the list allowing just one of each of these 

values, or can something be suspension and contraction?

@type on  = Should possible values use industry standard abbreviations 

or be human readable: WA - wide angle, HA - high angle, LA - low angle, CU - 

close up, Bird's-Eye View, ECU - extreme close up, LS - long shot, OTS - over 

the shoulder (as in interviews), pan (left-to-right or right-to-left), tilt (up 

and down) zoom (in or out).  These of course can be combined and don't include 

other camera effects and cuts (like 'fade to black', etc.).

@unit on  = 'folio'?

@value on  = why tei.data.pointer?  I must not understand how that works.

@zone = tei.timezone ?

Just things which occurred to me while scanning through,

-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 07 2005 - 06:33:09 EDT

From Syd_Bauman at Brown.edu  Thu Jul  7 07:32:50 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 7 Jul 2005 07:32:50 -0400
Subject: [tei-council] Agenda for TEI Council conference call on Friday 2005-07-08, 1300 UTC
In-Reply-To: 
Message-ID: <17101.4834.457671.934781@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Thu, 7 Jul 2005 07:32:50 -0400

> This is the agenda for the conference call the TEI Council will

> hold Friday, July 8th, 2005 at 1300 UTC.

To find out when that is in your timezone, visit

http://www.timeanddate.com/worldclock/personal.html?cities=137,231,105,878,136,195,141,339,69,48,287,538&year=2005&month=7&day=8&hour=13&min=0&sec=0&p1=0

I think that hits everyone. Let me know if there are any timezones

I've missed. :-)

> INSTRUCTIONS for conference call:

> 

> Participants will dial in to +1 812 856 3550.

> 

> When prompted, enter the code "0920" followed by "#".

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Jul 07 2005 - 07:32:53 EDT

From Syd_Bauman at Brown.edu  Thu Jul  7 08:00:50 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 7 Jul 2005 08:00:50 -0400
Subject: [tei-council] directory layout again
In-Reply-To: <42CCE73D.5060802@computing-services.oxford.ac.uk>
Message-ID: <17101.6514.660395.934356@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Thu, 7 Jul 2005 08:00:50 -0400

> Sorry, but I disagree. We've suffered from years from having a tag

> called tei.2 -- let's make the naming reflect the reality of the

> situation.

I'm not sure I see that the name of the root element and the name of

the directory that holds the Guidelines/schemas/whatever that deal

with that root element are such that they'd cause the same suffering.

E.g., the language XHTML has both a version 1.0 and a version 1.1 in

separate directories in /usr/share/xml/xhtml/schema/dtd/, but in both

cases the root element is "html".

> There is P4 which we have agreed to freeze and to maintain in

> parallel for a few years, and there is the current version of the

> TEI, which is (as it happens) P5.

While I understand the sentiment, I think it is premature to call

that which will be released as P5 "current".

> It might become P6 one day, but it *is* currently the TEI

> proposals.

I think this, mostly through our sluggishness, is wishful thinking.

After all, that which will eventually be released as P5 still has a

chapter on the structure of its DTDs; still refers to base,

additional, and axillary tagsets all over; still shows users how to

invoke tagsets using DOCTYPE and parameter entity declarations; still

has source data in attributes; does not mention XInclude; still has

chapters on conformance and modification that make no sense anymore;

etc. While I think there are a few things (character set issues,

feature structures, manuscript description, and tagset documentation

jump to mind) where we can point to a chapter of P5 as a reasonable

current recommendation, P5 as a whole cannot, IMHO, enjoy that

privilege.

> So I think that P4 is the "marked case" as linguists say and should

> have a different name. I'm not married to "teiclassic" but it does

> convey what I think we want to say about this other version rather

> well --despite the associations with a well known marketing fiasco!

While this may well be the case in some number of months when P5 does

become the current version, I still don't think naming directories

like this is necessarily a good idea. (Although setting up symlinks

like this might be.) A user's documents that conform TEI P7 still

conform to TEI P7 even after TEI P8 comes out and P7 is considered

obsolete. As a user, I don't want to do a system upgrade and find

that my files are no longer valid and no longer can be properly

processed because TEI changed what they consider current. In some

sense, what's current to me (the user) is what *I'm using*, not what

TEI is recommending.

That said, I realize that such a system if created without symlinks

(or aliases or whatever), in which only the numbered versions are

accessible is a bit unusual. The current version of Emacs is in

"emacs21/"; but "emacs" is symlinked to it. When the installed

version becomes 22, the symlink is updated such that if I do nothing,

I get the new version.

This is not the case with /usr/share/xml/, though, is it? I see

different versions of DocBook, SVG, and XHTML in that directory, but

no symlinks so that there is a static "current" version.

Gotta go ...

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Jul 07 2005 - 08:00:54 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Thu Jul  7 09:15:41 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Thu, 07 Jul 2005 14:15:41 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <17101.6514.660395.934356@emt.wwp.brown.edu>
Message-ID: <42CD2AFD.5020507@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Thu, 07 Jul 2005 14:15:41 +0100

Syd Bauman wrote:

>While I understand the sentiment, I think it is premature to call

>that which will be released as P5 "current".

>  

>

We've released version 0.1.  What more could we do?

>

>After all, that which will eventually be released as P5 still has a

>chapter on the structure of its DTDs; still refers to base,

>additional, and axillary tagsets all over; still shows users how to

>invoke tagsets using DOCTYPE and parameter entity declarations; still

>has source data in attributes; 

>

so the documentation has not caught up. thats not unusual

(albeit not good)

>does not mention XInclude

>

why would it do that, by the way?

>

>  

>

-- 
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 Jul 07 2005 - 09:16:18 EDT

From jawalsh at indiana.edu  Thu Jul  7 10:18:30 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Thu, 7 Jul 2005 09:18:30 -0500
Subject: [tei-council] directory layout again
In-Reply-To: <42CD2AFD.5020507@computing-services.oxford.ac.uk>
Message-ID: <1E2183A6-71CA-4A59-91F9-D0ABC37D54CE@indiana.edu>

From: John A. Walsh 

Date: Thu, 7 Jul 2005 09:18:30 -0500

> Syd Bauman wrote:

>

>

>> While I understand the sentiment, I think it is premature to call

>> that which will be released as P5 "current".

>>

>>

>>

> We've released version 0.1.  What more could we do?

Typically when something is 0.1, it's not recommended for production  

use, but offered for more daring early implementers.  I think it's  

fair to say that P4 remains the current production version of TEI and  

that P5 is the current development version of TEI.  So Syd's point is  

a good one.  While P5 remains some distance from a 1.0 release, we  

should not recommend P5 as the current production version to the  

community at large.  I wish we were closer to 1.0, and I share in the  

responsibility for us not being there yet, but we're still a ways off.

>

>

>>

>> After all, that which will eventually be released as P5 still has a

>> chapter on the structure of its DTDs; still refers to base,

>> additional, and axillary tagsets all over; still shows users how to

>> invoke tagsets using DOCTYPE and parameter entity declarations; still

>> has source data in attributes;

>>

>>

> so the documentation has not caught up. thats not unusual

> (albeit not good)

>

>

>> does not mention XInclude

>>

>>

> why would it do that, by the way?

>

>

>

>>

>>

>>

>>

>

>

> -- 

> 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 Thu Jul 07 2005 - 10:18:35 EDT

From lou.burnard at computing-services.oxford.ac.uk  Thu Jul  7 12:56:44 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 07 Jul 2005 17:56:44 +0100
Subject: [tei-council] Brief report on P5 changes since last meeting
Message-ID: <42CD5ECC.8090905@oucs.ox.ac.uk>

From: Lou Burnard 

Date: Thu, 07 Jul 2005 17:56:44 +0100

The P5 changelog shows the following activities since 1 May 05

1. Revised versions of MS chapter checked in

2. Work on correcting content models for biblStruct and respStmt

3. New  element added (but not yet fully documented)

4. Make  a chunk rather than a phrase

5. Benchmark (test suite) files revised and checked

6. New spec for , including new spanning class, new 

    element, removal of . Made P5 itself conform to new spec, 

for  which, please see http://www.tei-c.org/P5/Guidelines/CO.html#CONOIX

I have also been working on some of the outstanding SF queries, and

fixing errors where they appear, e.g.

- phraseSeq macro now defined explicitly instead of intermediate macro

   (which used sequence instead of alternation for some reason)

- made content model of  same as that of add (specialPara)

- made content model of  same as that of other divtop elements 

(phraseSeq)

- changed content model of  to paraContent and removed its value 

attribute

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Jul 07 2005 - 12:53:28 EDT

From nsmith at email.unc.edu  Thu Jul  7 13:01:50 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Thu, 7 Jul 2005 13:01:50 -0400 (Eastern Daylight Time)
Subject: [tei-council] Review of HD/SH (TEIHeader) and CO (Elements Available in All TEI Documents)
Message-ID: 

From: Natasha Smith 

Date: Thu, 7 Jul 2005 13:01:50 -0400 (Eastern Daylight Time)

Hello:

Below is a very brief report on our work on:

A. CO (Elements Available in All TEI Documents)

1.	JW and NS went through the whole chapter independently sharing

comments as they progressed first past through CO with notes for suggested changes.

2.	We scheduled a conf call for July 11 (several work-related travels

made it impossible to schedule anything earlier)

3.	Our opinion that the most work (and effort) will go not into

revision of element-by-element (and their attributes) but in restructuring

and logical reorganization of the chapter itself. We think about different

approaches in organizing and listing all the elements:

a.  by model classes (in cases when one element belongs to more than one

class, we can refer to the fist occurence)

b. alpha list of all elements (too long!)

c. both (in one chapter - by classes first and then a running alha list)

d. other suggestions are welcome

4. We plan to submit a report and proposal for the chapter revamp by the

end of August  

B. Header chapters

1.	We worked on updating and refining the header spreadsheet

2.	Finalized the group of catalogers and received their time

commitment

3.	Sent out the excel spreadsheet to the group of catalogers for

their mapping guidance and comments.

4.	Set-up a group conference call for July.

all the best, ns

Natasha (Natalia) Smith

Digitization Librarian

Wilson Library, CB#3990

University of North Carolina at Chapel Hill

Chapel Hill, NC 27514-8890

email: natalia_smith_at_unc.edu

tel. (919) 962-9590

fax (919) 962-4452

http://docsouth.unc.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 07 2005 - 13:02:04 EDT

From Syd_Bauman at Brown.edu  Thu Jul  7 19:47:24 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 7 Jul 2005 19:47:24 -0400
Subject: [tei-council] attribute/datatype data updated
In-Reply-To: <42CD048A.6030204@computing-services.oxford.ac.uk>
Message-ID: <17101.48908.557175.196308@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Thu, 7 Jul 2005 19:47:24 -0400

James, thanks so much for the thoughtful feedback!

> Why is tei.data.duration set up defaultly not to allow plurals?

> Things take 3 weeks (or longer :-) ) not 3 week. I think in

> addition to wk/yr/week/year/month there should be

> wks/yrs/weeks/years/months. I would abbreviate month as

> mnth/mnths, if I did at all.

I thought about this for only a few seconds, and thought that the

unit being used is a thing, in the singular, of which there may be

multiples, which cause us to use the plural. More importantly, the

capability to use the plural only makes sense for those which are

derived from abbreviations of English words: year, month, and week.

Everything else is a symbol from Comité International des

Poids et Mesures, and as such is really already plural, and can't be

expressed with an "s" appended. (The speed limit is 100 km/h, not

kms/hr.) 

Should there be plurals for year, month, and week? (I don't think I

care.) Should we bother with abbreviations of those three? (It's

easier for the editors if we don't :-)

> @calendar = What about Lunar & Solar (as more vague types of

> astronomical?), Gregorian? I believe the Tibetan calendar is

> different from the Chinese one. I would personally like 'Regnal'

> since many of the dates I've used are in an English Regnal

> calendar. (I.e. 5 Edward III for the 5th year of the reign of

> Edward III). 'Fiscal' could be another type of calendar, since that

> fixes each month a a specific number of weeks to facilitate

> economic comparisons. Maybe 'Liturgical'...but there are different

> ones depending on faith. There are others at

> http://en.wikipedia.org/wiki/List_of_calendars

All good suggestions, I think. Is there a more definitive list

somewhere that we should use as a basis?

> @character on  Are 'Shaky', 'Thick' and 'Regular' the

> appropriate palaeographic terms? I realise it has tei.data.token as

> well, but surely something can be 'Thin' but not 'Shaky'? (Sounds

> like milkshakes...)

I certainly don't know. I just copied the list from the "suggested

values include" in the tagdoc.

> @cols/@columns = I've not looked at this at all, but it just seems

> strange that these are different datatypes. 

Oh dear. These three are completely screwed up. I'll fix 'em right

after dinner.

> @date on  = Why not tei.data.temporalExpression?

This is what we call in the encoding world an "error". As is obvious

by the additional constraint, it's supposed to be

tei.data.temporalExpression. 

> @ed on  = point to xml:id on  maybe?

Won't work in the general case of having more than one edition

encoded in the same file. There are a lot of ed= attributes that need

to refer to a controlled vocabulary. I think we need to create an

 or some such in the .

> @feature on  = should include tei.data.token ?

I'm inclined to think so, but again, I was just copying what is

currently present in the declaration of that attribute.

> @form on  = Should other formats be included? video.MPEG7

> audio.MP3? Or does this relate only to the physical form? Also,

> what about 'webpage'?

I think only physical form, but to be honest, not only don't I know,

I don't think it has been thought through very thoroughly yet by

anyone. 

> @place = Should these include tei.data.token for transcriptions of

> non-standard objects?

(I presume you mean of , , or .) Same answer as for

feature= of , I think.

> @type on  = ugh. ... Is the list allowing just one of each

> of these values, or can something be suspension and contraction?

I'm really not sure what is the right way to go with this one. I

suspect that in the end, we'll need to use a looser model than the

one I've sketched (the values for which were pretty much copied from

the current declaration, BTW), if for no other reason than ODD won't

be able to support this kind of thing, it least not soon enough for

immediate use.

However, that said, I think it *is* useful to think about the

semantics of type= of , through its syntax, even if we end up

loosening the syntax later.

Here's what I sketched out, with whitespace improved for (human)

readability: 

| list { 

|      ( "suspension" | "contraction" | "brevigraph" | "acronym" | tei.data.token )?,

|      ( "superscription" | tei.data.token )?,

|      ( "title" | "organization" | "geographic" | tei.data.token )?

|      }

This means 0 or 1 from each group, in the order specified. So

  type="suspension superscription title"

  type=""

  type="acronym organization"

are all valid even if you removed the "tei.data.token"s, but

  type="title contraction"

would not be. With the "tei.data.token"s there, the only constraint

is that there be no more than 2 internal sequences of whitespace.

I.e., 

  type="a b c"

is OK, but 

  type="a b c d"

is not.

> Shouldn't 'acronym' go into the list with title/org/etc. since is

> both the reason for an abbr while also the method? 

I have to admit, I hadn't thought of acronym as a reason. (This

from the guy who came up with "consideration, resolution, and

progress". :-)

> Why is superscription by itself?

Seemed to be in a category by itself. But I think the real question

is why is superscription in the list of values at all? Seems like a

detail best left to rend= to me.

> @type on  = Should possible values use industry standard

> abbreviations or be human readable:

Darn good question, to which I don't have an actual answer. But I

think one guideline for us to apply is that brevity is not itself a

goal unless the value is going to appear a lot, in which case it can

become pretty important. (E.g., if  were called , it

wouldn't be much of a loss, because it doesn't generally occur very

often; if  were called , it could get really annoying

really fast.)

> @unit on  = 'folio'?

> 

> @value on  = why tei.data.pointer? I must not understand how that works.

Nope, you understand, you've just stumbled into another error.

> @zone = tei.timezone ?

Yes, personally I think that since there are 2 zone= attributes and

the list of timezones is potentially a pain to maintain, it may make

good sense to give this one its own datatype, 'tei.data.timezone'.

> Just things which occurred to me while scanning through,

I'm glad you scanned! Thanks. I hope to send a repair report in an

hour or so.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Jul 07 2005 - 19:47:32 EDT

From Syd_Bauman at Brown.edu  Thu Jul  7 20:53:33 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 7 Jul 2005 20:53:33 -0400
Subject: [tei-council] attribute/datatype data updated
In-Reply-To: <17101.48908.557175.196308@emt.wwp.brown.edu>
Message-ID: <17101.52877.519425.496316@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Thu, 7 Jul 2005 20:53:33 -0400

OK, I've fixed

  columns= of 

  cols= of 

  cols= of 

  date= of 

as James pointed out, and also

  dateCreated= of 

  dateUpdated= of 

  value= of 

  from= of 

  notAfter= of 'tei.datable'

  notBefore= of 'tei.datable'

all of which really looked like a cut-and-paste error, and

  max= of 

  value= of 

  value= of 

  xml:id= of 'tei.global'

  xml:lang= of 'tei.global'

which I can't tell why they were screwed up.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Jul 07 2005 - 20:53:37 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Jul  7 21:35:13 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 08 Jul 2005 10:35:13 +0900
Subject: [tei-council] attribute/datatype data updated
In-Reply-To: <17101.48908.557175.196308@emt.wwp.brown.edu>
Message-ID: 

From: Christian Wittern 

Date: Fri, 08 Jul 2005 10:35:13 +0900

Syd Bauman edu> writes:

> James, thanks so much for the thoughtful feedback!

>

>

>> Why is tei.data.duration set up defaultly not to allow plurals?

>> Things take 3 weeks (or longer :-) ) not 3 week. I think in

>> addition to wk/yr/week/year/month there should be

>> wks/yrs/weeks/years/months. I would abbreviate month as

>> mnth/mnths, if I did at all.

How about d (day), w (week), m (month), y (year); these tokens then do

not take plural forms.

> I thought about this for only a few seconds, and thought that the

> unit being used is a thing, in the singular, of which there may be

> multiples, which cause us to use the plural. More importantly, the

> capability to use the plural only makes sense for those which are

> derived from abbreviations of English words: year, month, and week.

> Everything else is a symbol from Comité International des

> Poids et Mesures, and as such is really already plural, and can't be

> expressed with an "s" appended. (The speed limit is 100 km/h, not

> kms/hr.) 

>

> Should there be plurals for year, month, and week? (I don't think I

> care.) Should we bother with abbreviations of those three? (It's

> easier for the editors if we don't :-)

Have you looked at

http://www.w3.org/TR/xpath-functions/#durations-dates-times, which

devotes a whole section to Durations, Dates and Times.  Certainly

worthwhile to stay compatible with that. XPath in turn references ISO

8601, but being from the ISO this is not available on the web, so I

can't check what they say. 

On a related note, in Chinese you have a cycle of 60 days which is

used as a reference (sometimes in paralell) to the year/month system.

There should be a place for this as well, ideally.

>

>

>> @calendar = What about Lunar & Solar (as more vague types of

>> astronomical?), Gregorian? I believe the Tibetan calendar is

>> different from the Chinese one. I would personally like 'Regnal'

>> since many of the dates I've used are in an English Regnal

>> calendar. (I.e. 5 Edward III for the 5th year of the reign of

>> Edward III). 'Fiscal' could be another type of calendar, since that

>> fixes each month a a specific number of weeks to facilitate

>> economic comparisons. Maybe 'Liturgical'...but there are different

>> ones depending on faith. There are others at

>> http://en.wikipedia.org/wiki/List_of_calendars

>

> All good suggestions, I think. Is there a more definitive list

> somewhere that we should use as a basis?

I doubt that you can do with a global list.  

>

>> @ed on  = point to xml:id on  maybe?

>

> Won't work in the general case of having more than one edition

> encoded in the same file. There are a lot of ed= attributes that need

> to refer to a controlled vocabulary. I think we need to create an

>  or some such in the .

Yes, that is true.  I have always wondered where this dangling @ed

points to.

>> @form on  = Should other formats be included? video.MPEG7

>> audio.MP3? Or does this relate only to the physical form? Also,

>> what about 'webpage'?

form does not look like the right thing for these, I would expect

something like mimetype for such things. Might worth be looking at

stuff like METS, since that is where they deal with what is out in the

wild. 

On the whole, it looks like we need to spend a bit more time on this...

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 07 2005 - 21:35:20 EDT

From abia at umh.es  Fri Jul  8 05:26:47 2005
From: abia at umh.es (Alejandro Bia)
Date: Fri, 08 Jul 2005 11:26:47 +0200
Subject: [tei-council] Not able to connect to today's call...
Message-ID: <5.2.0.9.0.20050708110335.03b9d488@mussol.umh.es>

From: Alejandro Bia 

Date: Fri, 08 Jul 2005 11:26:47 +0200

Dear council members,

I'm currently ill and away from work (and off-line most of the time).

My health has deteriorated since I came back from Canada three weeks ago.

Apparently, recovering may take long. I hope not.

I'll let you know.

I won't be able to take part of today's conference call.

I'm really sorry.

Alex.-

---------------------------------------------------------

ALEJANDRO BIA-PLATAS

e-mail: abia_at_umh.es

   Departamento de Estad?stica, Matem?tica e Inform?tica

   Universidad Miguel Hern?ndez

   Edificio Torretamarit

   Avenida de la Universidad s/n, E-03202, Elche, ESPA?A

   http://www.umh.es/

   Tel: +34 966658542

   Fax: +34 966658715

   Tel?fono m?vil: +34 610806427

--------------------------------------------------------- 

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Jul 08 2005 - 05:34:38 EDT

From Syd_Bauman at Brown.edu  Fri Jul  8 06:13:17 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 8 Jul 2005 06:13:17 -0400
Subject: [tei-council] Not able to connect to today's call...
In-Reply-To: <5.2.0.9.0.20050708110335.03b9d488@mussol.umh.es>
Message-ID: <17102.20925.27541.436899@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Fri, 8 Jul 2005 06:13:17 -0400

We hope you feel better soon, Alejandro.

Thanks for letting us know.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Jul 08 2005 - 06:13:22 EDT

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Jul  8 07:21:25 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 08 Jul 2005 20:21:25 +0900
Subject: [tei-council] Not able to connect to today's call...
In-Reply-To: <5.2.0.9.0.20050708110335.03b9d488@mussol.umh.es>
Message-ID: 

From: Christian Wittern 

Date: Fri, 08 Jul 2005 20:21:25 +0900

Alejandro Bia es> writes:

> Dear council members,

>

> I'm currently ill and away from work (and off-line most of the time).

> My health has deteriorated since I came back from Canada three weeks ago.

> Apparently, recovering may take long. I hope not.

> I'll let you know.

>

> I won't be able to take part of today's conference call.

> I'm really sorry.

I am very sorry to hear that, Alejandro.  Hope you will be better

soon.  In the meantime, take good care and relax.

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 Jul 08 2005 - 07:21:32 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jul  8 07:35:53 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 12:35:53 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <17101.6514.660395.934356@emt.wwp.brown.edu>
Message-ID: <42CE6519.2040108@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Fri, 08 Jul 2005 12:35:53 +0100

I hope some of you can look at this in the next 90 minutes. Its my directory

layout for all TEI-related packages, as of today. I believe that all the

material

is now internally consistent. I have not yet submitted to Sourceforge

hare/

|-- doc

|   |-- tei-emacs

|   |-- tei-oxygen

|   |-- tei-p4-lite

|   |   `-- doc

|   |-- tei-p4-schema

|   |-- tei-p4-xsl

|   |-- tei-p5-database

|   |-- tei-p5-exemplars

|   |   |-- html

|   |   `-- xml

|   |-- tei-p5-schema

|   |-- tei-p5-source

|   |-- tei-p5-test

|   |-- tei-p5-xsl

|   |   `-- xsltdoc

|   |       |-- common

|   |       |-- fo

|   |       |-- html

|   |       `-- latex

|   |-- tei-roma

|   |-- tei-teaching

`-- xml

    |-- tei

    |   |-- custom

    |   |   |-- odd

    |   |   |-- schema

    |   |   |   |-- dtd

    |   |   |   |-- relaxng

    |   |   |   `-- xsd

    |   |   `-- templates

    |   |-- odd

    |   |   |-- Source

    |   |   |   |-- AB

    |   |   |   |-- AI

    |   |   |   |-- BIB

    |   |   |   |-- CC

    |   |   |   |-- CE

    |   |   |   |-- CF

    |   |   |   |-- CH

    |   |   |   |-- CO

    |   |   |   |-- COL

    |   |   |   |-- DEDICATION

    |   |   |   |-- DI

    |   |   |   |-- DR

    |   |   |   |-- DS

    |   |   |   |-- DT

    |   |   |   |-- FD

    |   |   |   |-- FM1

    |   |   |   |-- FS

    |   |   |   |-- FT

    |   |   |   |-- GD

    |   |   |   |-- HD

    |   |   |   |-- IN

    |   |   |   |-- MD

    |   |   |   |-- MS

    |   |   |   |-- ND

    |   |   |   |-- NH

    |   |   |   |-- PARTIND

    |   |   |   |-- PH

    |   |   |   |-- PREFS

    |   |   |   |-- REFCLA

    |   |   |   |-- REFENT

    |   |   |   |-- REFTAG

    |   |   |   |-- SA

    |   |   |   |-- SG

    |   |   |   |-- SH

    |   |   |   |-- ST

    |   |   |   |-- TC

    |   |   |   |-- TD

    |   |   |   |-- TE

    |   |   |   |-- TS

    |   |   |   |-- VE

    |   |   |   `-- WD

    |   |   `-- Tools

    |   |-- schema

    |   |   |-- dtd

    |   |   |   `-- p4

    |   |   `-- relaxng

    |   |       `-- p4

    |   |-- stylesheet

    |   |   |-- common

    |   |   |-- fo

    |   |   |-- html

    |   |   |-- latex

    |   |   |-- odds

    |   |   `-- slides

    |   `-- xquery

    `-- teip4

        |-- custom

        |   |-- schema

        |   |   |-- dtd

        |   |   `-- relaxng

        |   `-- templates

        |-- schema

        |   `-- dtd

        `-- stylesheet

            |-- common

            |-- fo

            |-- html

            |-- latex

            `-- slides

-- 
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 Jul 08 2005 - 07:36:24 EDT

From James.Cummings at computing-services.oxford.ac.uk  Fri Jul  8 07:47:53 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 08 Jul 2005 12:47:53 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <42CE6519.2040108@computing-services.oxford.ac.uk>
Message-ID: <42CE67E9.4060808@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Fri, 08 Jul 2005 12:47:53 +0100

Sebastian Rahtz wrote:

> I hope some of you can look at this in the next 90 minutes. Its my directory

> layout for all TEI-related packages, as of today. I believe that all the

> material

> is now internally consistent. I have not yet submitted to Sourceforge

> 

> share/

> |-- doc

I like the doc/ tree, looks much cleaner.

> `-- xml

>     |-- tei

>     |   |-- schema

>     |   |   |-- dtd

>     |   |   |   `-- p4

>     |   |   `-- relaxng

>     |   |       `-- p4

Shouldn't that be p5?

-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 Jul 08 2005 - 07:49:28 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jul  8 07:53:12 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 12:53:12 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <42CE67E9.4060808@computing-services.oxford.ac.uk>
Message-ID: <42CE6928.9040104@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Fri, 08 Jul 2005 12:53:12 +0100

James Cummings wrote:

> 

>

>>     |   |-- schema

>>     |   |   |-- dtd

>>     |   |   |   `-- p4

>>     |   |   `-- relaxng

>>     |   |       `-- p4

>

>

> Shouldn't that be p5?

no. that p4 level was an error.  the files are just in eg 

xml/tei/schema/relaxng

-- 
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 Jul 08 2005 - 07:53:42 EDT

From Syd_Bauman at Brown.edu  Fri Jul  8 08:45:12 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 8 Jul 2005 08:45:12 -0400
Subject: [tei-council] directory layout again
In-Reply-To: <42CE6519.2040108@computing-services.oxford.ac.uk>
Message-ID: <17102.30040.108970.269509@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Fri, 8 Jul 2005 08:45:12 -0400

Sebastian Rahtz writes:

> share/

> |-- doc

> |   |-- tei-emacs

> |   |-- tei-oxygen

> |   |-- tei-p4-lite

> |   |   `-- doc

What goes in share/doc/tei-p4-lite/ vs share/doc/tei-p4-lite/doc/?

> |   |-- tei-p4-schema

> |   |-- tei-p4-xsl

> |   |-- tei-p5-database

> |   |-- tei-p5-exemplars

> |   |   |-- html

> |   |   `-- xml

I think I am completely misunderstanding this. What goes in

tei-p5-exemplars/?

> |   |-- tei-p5-schema

Documentation for the schema? Maybe I'm trying to think too early in

the morning, but what's this?

> |   |-- tei-p5-source

If the source is in ../share/xml/tei/odd/Source/, what's here?

> |   |-- tei-p5-test

> |   |-- tei-p5-xsl

> |   |   `-- xsltdoc

> |   |       |-- common

> |   |       |-- fo

> |   |       |-- html

> |   |       `-- latex

> |   |-- tei-roma

> |   |-- tei-teaching

> `-- xml

>     |-- tei

If we're not going to use ../share/xml/tei/p4/ and

../share/xml/tei/p5/ (which still doesn't follow Debian's desires,

but at least pushes the divide a level deeper), then I think that

this directory, to be parallel to ../share/xml/teip4/ should be named

../share/xml/teip5/. This permits more flexibility in not feeling

tied to backwards compatibility if & when we move to P6. Note that we

could still be backwards compatable, we just would feel less

compelled.

>     |   |-- custom

>     |   |   |-- odd

>     |   |   |-- schema

>     |   |   |   |-- dtd

>     |   |   |   |-- relaxng

>     |   |   |   `-- xsd

>     |   |   `-- templates

>     |   |-- odd

>     |   |   |-- Source

>     |   |   |   |-- AB

>     |	  |   |	  |-- ...

>     |   |   |   `-- WD

>     |   |   `-- Tools

>     |   |-- schema

>     |   |   |-- dtd

>     |   |   |   `-- p4

>     |   |   `-- relaxng

>     |   |       `-- p4

Last time you said this was just TEI P4 Lite, in which case it still

doesn't belong in ../share/xml/tei/schema/, but rather in

../share/xml/teip4/custom/.

>     |   |-- stylesheet

>     |   |   |-- common

>     |   |   |-- fo

>     |   |   |-- html

>     |   |   |-- latex

>     |   |   |-- odds

>     |   |   `-- slides

>     |   `-- xquery

>     `-- teip4

>         |-- custom

>         |   |-- schema

>         |   |   |-- dtd

>         |   |   `-- relaxng

>         |   `-- templates

>         |-- schema

>         |   `-- dtd

>         `-- stylesheet

>             |-- common

>             |-- fo

>             |-- html

>             |-- latex

>             `-- slides

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Jul 08 2005 - 08:45:20 EDT

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jul  8 08:57:50 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 13:57:50 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <17102.30040.108970.269509@emt.wwp.brown.edu>
Message-ID: <42CE784E.5050703@computing-services.oxford.ac.uk>

From: Sebastian Rahtz 

Date: Fri, 08 Jul 2005 13:57:50 +0100

Syd Bauman wrote:

>>share/

>>|-- doc

>>|   |-- tei-emacs

>>|   |-- tei-oxygen

>>|   |-- tei-p4-lite

>>|   |   `-- doc

>>    

>>

>

>What goes in share/doc/tei-p4-lite/ vs share/doc/tei-p4-lite/doc/?

>  

>

fair point. looks like an error

>

>  

>

>>|   |-- tei-p4-schema

>>|   |-- tei-p4-xsl

>>|   |-- tei-p5-database

>>|   |-- tei-p5-exemplars

>>|   |   |-- html

>>|   |   `-- xml

>>    

>>

>

>I think I am completely misunderstanding this. What goes in

>tei-p5-exemplars/?

>  

>

documentaton of the "exemplars" (however you interpret that...)

>>|   |-- tei-p5-schema

>>    

>>

>

>Documentation for the schema? Maybe I'm trying to think too early in

>the morning, but what's this?

>  

>

every "package" gets a doc directory. it may just have a changelog

>>|   |-- tei-p5-source

>>    

>>

>

>If the source is in ../share/xml/tei/odd/Source/, what's here?

>  

>

as above

>

>If we're not going to use ../share/xml/tei/p4/ and

>../share/xml/tei/p5/ (which still doesn't follow Debian's desires,

>but at least pushes the divide a level deeper), then I think that

>this directory, to be parallel to ../share/xml/teip4/ should be named

>../share/xml/teip5/. 

>

if Windows had symlinks, I'd agree.....

>

>Last time you said this was just TEI P4 Lite, in which case it still

>doesn't belong in ../share/xml/tei/schema/, but rather in

>../share/xml/teip4/custom/.

>  

>

yes, that was an error

-- 
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 Jul 08 2005 - 08:58:22 EDT

From mjd at hum.ku.dk  Fri Jul  8 09:01:17 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Fri, 08 Jul 2005 15:01:17 +0200
Subject: [tei-council] Reviews of ms-chapter
In-Reply-To: <17102.30040.108970.269509@emt.wwp.brown.edu>
Message-ID: <42CE953D.10500.1530E57@localhost>

From: M. J. Driscoll 

Date: Fri, 08 Jul 2005 15:01:17 +0200

Bedre sent end aldrig, as we say. Some comments on the 

reviews of the msDescription chapter. A much more detailed 

report will follow.

Reviews, varying in their usefulness, are in from:

1. Dorothy (Dot) Porter, working with Ben Withers, 

professor in Art History, University of Kentucky, who is 

producing an electronic edition of BL Claudius B. iv.

2. Elizabeth Solopova at the Bodleian

3. Torsten Schassan of the Herzog August Bibliothek in 

Wolfenb?ttel

4. Jindrich Marek of the National Library of the Czech 

Republic

5. Gautier Poupeau of the Sorbonne

People who promised reviews but have not delivered them 

are:

Daniel O'Donnell, University of Lethbridge

Fotis Jannidis, Darmstadt (who had in fact previously sent 

fairly detailed comments on the first draft of the chapter)

I have also received comments from Consuelo Dutschke, 

Columbia University Library; the currently available draft 

has in fact been amended to take these into account.

On the whole, the reviews point out a lot of small things 

which are in need fixing, many owing to the nature of the 

ODD system (such as statements in the specifications that 

elements have no attributes other than global and inherited 

ones, when according to the surrounding prose in fact they 

do, and descriptions of standard TEI elements or attributes 

which are inappropriate to manuscripts), but nobody's 

pointed out any major problems/lacks. This I suppose is a 

good thing, since it suggests that we've actually got it 

right. Some classic problems turned up, such as the 

(alleged) inflexibility of the system when dealing with 

legacy data. There were also a number of comments which 

were simply wrong (people saying that you couldn't do 

things you perfectly well can), but which indicate that the 

documentation needs to be better.

One problem which was mentioned by several people has to do 

with the change of  to the standard TEI element 

, one result of which is that it is no longer 

possible to use  to indicate the language of the 

manuscript as a whole ( is allowed within 

individual  elements but is not, unlike 

,  and , phrase-level). There 
<br />
is, of course, nothing to stop you simply writing "Latin 
<br />
with some French" in your <head> element, but for search 
<br />
purposes and so on people want to tag these things. One 
<br />
solution that occurs to me is to have the relevant 
<br />
attributes from <textLang>, viz. langKey and otherLangs, on 
<br />
<msContents>; this could even be a class (textLang?). 
<br />
Another is to make <textLang> phrase-level. Doing either of 
<br />
these would also allow one to encode the languages of the 
<br />
manuscript even if one used the <p> option inside 
<br />
<msContents>, as requested by ES. The inability to have 
<br />
<author> in <head> was also mentioned.
<br />

MJD
<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 Jul 08 2005 - 09:01:30 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jul  8 10:36:04 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 15:36:04 +0100
Subject: [tei-council] face to face re TEI class system
Message-ID: <42CE8F54.3020808@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 08 Jul 2005 15:36:04 +0100</span><br />
</address>

Can I have a show of hands as to who expects/needs/wants to attend this
<br />
devilish face to face to "sort out" the TEI class system?  Lou
<br />
and Syd I take as read, and me. Who else?
<br />

Can I also confirm that this is in Oxford,
<br />
on September 29th and probably 30th too?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Fri Jul 08 2005 - 10:36:35 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jul  8 10:43:00 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 15:43:00 +0100
Subject: [tei-council] directory layout
Message-ID: <42CE90F4.90505@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 08 Jul 2005 15:43:00 +0100</span><br />
</address>

Here is a corrected version. I generated this by making Debian packages
<br />
of all
<br />
the TEI-related stuff I have, and looking at /usr/share/doc/tei* and
<br />
/usr/share/xml/tei*
<br />

If you are Linux geek, and install all my packages, you should find this
<br />
structure
<br />
on your disk. I would expect Mr oXygen to pick up the xml/tei and
<br />
xml/teip4 trees, and
<br />
strip out "odd" and "xquery" nodes.
<br />

My working assumption is that most people are content to fly with this,
<br />
and just let Syd and James poke sticks are fragile details
<br />

hare/
<br />
|-- doc
<br />
|   |-- tei-emacs
<br />
|   |-- tei-oxygen
<br />
|   |-- tei-p4-lite
<br />
|   |-- tei-p4-schema
<br />
|   |-- tei-p4-xsl
<br />
|   |-- tei-p5-database
<br />
|   |-- tei-p5-doc
<br />
|   |   `-- html
<br />
|   |-- tei-p5-exemplars
<br />
|   |   |-- html
<br />
|   |   `-- xml
<br />
|   |-- tei-p5-schema
<br />
|   |-- tei-p5-source
<br />
|   |-- tei-p5-test
<br />
|   |-- tei-p5-xsl
<br />
|   |   `-- xsltdoc
<br />
|   |       |-- common
<br />
|   |       |-- fo
<br />
|   |       |-- html
<br />
|   |       `-- latex
<br />
|   |-- tei-roma
<br />
|   |-- tei-teaching
<br />
|   `-- tei-xsl
<br />
`-- xml
<br />
    |-- tei
<br />
    |   |-- custom
<br />
    |   |   |-- odd
<br />
    |   |   |-- schema
<br />
    |   |   |   |-- dtd
<br />
    |   |   |   |-- relaxng
<br />
    |   |   |   `-- xsd
<br />
    |   |   `-- templates
<br />
    |   |-- odd
<br />
    |   |   |-- Source
<br />
    |   |   |   |-- AB
<br />
    |   |   |   |-- AI
<br />
    |   |   |   |-- BIB
<br />
    |   |   |   |-- CC
<br />
    |   |   |   |-- CE
<br />
    |   |   |   |-- CF
<br />
    |   |   |   |-- CH
<br />
    |   |   |   |-- CO
<br />
    |   |   |   |-- COL
<br />
    |   |   |   |-- DEDICATION
<br />
    |   |   |   |-- DI
<br />
    |   |   |   |-- DR
<br />
    |   |   |   |-- DS
<br />
    |   |   |   |-- DT
<br />
    |   |   |   |-- FD
<br />
    |   |   |   |-- FM1
<br />
    |   |   |   |-- FS
<br />
    |   |   |   |-- FT
<br />
    |   |   |   |-- GD
<br />
    |   |   |   |-- HD
<br />
    |   |   |   |-- IN
<br />
    |   |   |   |-- MD
<br />
    |   |   |   |-- MS
<br />
    |   |   |   |-- ND
<br />
    |   |   |   |-- NH
<br />
    |   |   |   |-- PARTIND
<br />
    |   |   |   |-- PH
<br />
    |   |   |   |-- PREFS
<br />
    |   |   |   |-- REFCLA
<br />
    |   |   |   |-- REFENT
<br />
    |   |   |   |-- REFTAG
<br />
    |   |   |   |-- SA
<br />
    |   |   |   |-- SG
<br />
    |   |   |   |-- SH
<br />
    |   |   |   |-- ST
<br />
    |   |   |   |-- TC
<br />
    |   |   |   |-- TD
<br />
    |   |   |   |-- TE
<br />
    |   |   |   |-- TS
<br />
    |   |   |   |-- VE
<br />
    |   |   |   `-- WD
<br />
    |   |   `-- Tools
<br />
    |   |-- schema
<br />
    |   |   |-- dtd
<br />
    |   |   `-- relaxng
<br />
    |   |-- stylesheet
<br />
    |   |   |-- common
<br />
    |   |   |-- fo
<br />
    |   |   |-- html
<br />
    |   |   |-- latex
<br />
    |   |   |-- odds
<br />
    |   |   `-- slides
<br />
    |   `-- xquery
<br />
    `-- teip4
<br />
        |-- custom
<br />
        |   |-- schema
<br />
        |   |   |-- dtd
<br />
        |   |   `-- relaxng
<br />
        |   `-- templates
<br />
        |-- schema
<br />
        |   `-- dtd
<br />
        `-- stylesheet
<br />
            |-- common
<br />
            |-- fo
<br />
            |-- html
<br />
            |-- latex
<br />
            `-- slides
<br />

102 directories
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Fri Jul 08 2005 - 10:43:31 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Fri Jul  8 10:44:27 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 08 Jul 2005 15:44:27 +0100
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <42CE8F54.3020808@computing-services.oxford.ac.uk>
Message-ID: <42CE914B.2020400@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, 08 Jul 2005 15:44:27 +0100</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev1">> Can I have a show of hands as to who expects/needs/wants to attend this
</em><br />
<em class="quotelev1">> devilish face to face to "sort out" the TEI class system?  Lou
</em><br />
<em class="quotelev1">> and Syd I take as read, and me. Who else?
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Can I also confirm that this is in Oxford,
</em><br />
<em class="quotelev1">> on September 29th and probably 30th too?
</em><br />

If it is taking place in Oxford, then could I attend as well?
<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 Jul 08 2005 - 10:46:02 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jul  8 10:47:46 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 15:47:46 +0100
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <42CE914B.2020400@computing-services.oxford.ac.uk>
Message-ID: <42CE9212.8040109@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 08 Jul 2005 15:47:46 +0100</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> If it is taking place in Oxford, then could I attend as well?
</em><br />

if you promise to vote in the same way as me.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Fri Jul 08 2005 - 10:48:16 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Fri Jul  8 10:50:25 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 08 Jul 2005 15:50:25 +0100
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <42CE9212.8040109@computing-services.oxford.ac.uk>
Message-ID: <42CE92B1.80306@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, 08 Jul 2005 15:50:25 +0100</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev1">> James Cummings wrote:
</em><br />
<em class="quotelev2">>>If it is taking place in Oxford, then could I attend as well?
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> if you promise to vote in the same way as me.
</em><br />

Can you trust my promise?
<br />

<p>So what is this meet-o-matic thing we are going to use to schedule the next meeting?
<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 Jul 08 2005 - 10:52:00 EDT</span>
</div>

From Laurent.Romary at loria.fr  Fri Jul  8 10:49:53 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Fri, 8 Jul 2005 16:49:53 +0200
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <42CE8F54.3020808@computing-services.oxford.ac.uk>
Message-ID: <c7cb1869a27eb3bebf849709d2a89a69@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>: Fri, 8 Jul 2005 16:49:53 +0200</span><br />
</address>

Dear all,
<br />
I take the opportunity of this message to apologize: my shuttle to Lyon 
<br />
airport has been stuck in traffic more than one hour and I have not 
<br />
been able to attend the conf call as expected.
<br />
Concerning the TEI class meeting, I had booked Sept 26-27 for a while 
<br />
on my agenda, but 29-30 is definitely not possible for me: is there a 
<br />
reason why we change the initial plans?
<br />
Best,
<br />
Laurent
<br />

<p>Le 8 juil. 05, ? 16:36, Sebastian Rahtz a ?crit :
<br />

<em class="quotelev1">> Can I have a show of hands as to who expects/needs/wants to attend this
</em><br />
<em class="quotelev1">> devilish face to face to "sort out" the TEI class system?  Lou
</em><br />
<em class="quotelev1">> and Syd I take as read, and me. Who else?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Can I also confirm that this is in Oxford,
</em><br />
<em class="quotelev1">> on September 29th and probably 30th too?
</em><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 />
<em class="quotelev1">> OSS Watch: JISC Open Source Advisory Service
</em><br />
<em class="quotelev1">> http://www.oss-watch.ac.uk
</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.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> Fri Jul 08 2005 - 10:52:47 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jul  8 10:55:47 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 15:55:47 +0100
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <42CE92B1.80306@computing-services.oxford.ac.uk>
Message-ID: <42CE93F3.30607@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 08 Jul 2005 15:55:47 +0100</span><br />
</address>

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Can you trust my promise?
</em><br />

no
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> So what is this meet-o-matic thing we are going to use to schedule the
</em><br />
<em class="quotelev1">> next meeting?
</em><br />

uck it and see.  you should have an email about it
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Fri Jul 08 2005 - 10:56:17 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jul  8 10:58:39 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 15:58:39 +0100
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <c7cb1869a27eb3bebf849709d2a89a69@loria.fr>
Message-ID: <42CE949F.9020807@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 08 Jul 2005 15:58:39 +0100</span><br />
</address>

Laurent Romary wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Concerning the TEI class meeting, I had booked Sept 26-27 for a while
</em><br />
<em class="quotelev1">> on my agenda, but 29-30 is definitely not possible for me: is there a
</em><br />
<em class="quotelev1">> reason why we change the initial plans?
</em><br />

orry, that was me mishearing something, I thought CW said 29th. 26-27
<br />
it is. So far in the holding cell
<br />
are James, Sebastian, Laurent, and Syd and Lou being sought by Interpol.
<br />
Any more takers?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Fri Jul 08 2005 - 10:59:11 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Fri Jul  8 11:05:04 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 8 Jul 2005 16:05:04 +0100 (BST)
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <c7cb1869a27eb3bebf849709d2a89a69@loria.fr>
Message-ID: <20050708150504.8E1ABF4B9@webmail220.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>: Fri, 8 Jul 2005 16:05:04 +0100 (BST)</span><br />
</address>
 ('binary' encoding is not supported, stored as-is)
My diary agrees with Laurent that we had originally specified the date as 26/27 as the date. 
<br />

Sorry we missed you Laurent...
<br />

In message <c7cb1869a27eb3bebf849709d2a89a69_at_loria.<!--nospam-->fr> Laurent Romary 
<br />
<Laurent.Romary_at_loria.<!--nospam-->fr> writes:
<br />
<em class="quotelev1">> Dear all,
</em><br />
<em class="quotelev1">> I take the opportunity of this message to apologize: my shuttle to Lyon 
</em><br />
<em class="quotelev1">> airport has been stuck in traffic more than one hour and I have not 
</em><br />
<em class="quotelev1">> been able to attend the conf call as expected.
</em><br />
<em class="quotelev1">> Concerning the TEI class meeting, I had booked Sept 26-27 for a while 
</em><br />
<em class="quotelev1">> on my agenda, but 29-30 is definitely not possible for me: is there a 
</em><br />
<em class="quotelev1">> reason why we change the initial plans?
</em><br />
<em class="quotelev1">> Best,
</em><br />
<em class="quotelev1">> Laurent
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Le 8 juil. 05, ? 16:36, Sebastian Rahtz a ?crit :
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">> > Can I have a show of hands as to who expects/needs/wants to attend this
</em><br />
<em class="quotelev2">> > devilish face to face to "sort out" the TEI class system?  Lou
</em><br />
<em class="quotelev2">> > and Syd I take as read, and me. Who else?
</em><br />
<em class="quotelev2">> >
</em><br />
<em class="quotelev2">> > Can I also confirm that this is in Oxford,
</em><br />
<em class="quotelev2">> > on September 29th and probably 30th too?
</em><br />
<em class="quotelev2">> >
</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="quotelev2">> > OSS Watch: JISC Open Source Advisory Service
</em><br />
<em class="quotelev2">> > http://www.oss-watch.ac.uk
</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 />
<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 Jul 08 2005 - 11:05:09 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jul  8 11:15:44 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 16:15:44 +0100
Subject: [tei-council] arranging next meeting
In-Reply-To: <42CE8CAA.3070503@oucs.ox.ac.uk>
Message-ID: <42CE98A0.8060100@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 08 Jul 2005 16:15:44 +0100</span><br />
</address>

check out http://www.meetomatic.com/respond.asp?id=6816IM
<br />
if my previous mail has gone astray
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Fri Jul 08 2005 - 11:16:15 EDT</span>
</div>

From jawalsh at indiana.edu  Fri Jul  8 11:41:24 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Fri, 8 Jul 2005 10:41:24 -0500
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <42CE949F.9020807@computing-services.oxford.ac.uk>
Message-ID: <C0D504FF-660E-4F58-8FF2-AA3891A581E4@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, 8 Jul 2005 10:41:24 -0500</span><br />
</address>

Sebastian,
<br />

I'm interested in the class system and believe I could make useful  
<br />
contributions.  If others agree, I'd like to participate in the  
<br />
meeting, though I'm aware there's some concern about keeping the  
<br />
group to a manageable size.  My feelings won't be hurt if I can't be  
<br />
included.
<br />

John
<br />
| John A. Walsh, Associate Director for Projects and Services
<br />
| Digital Library Program / Indiana University Libraries
<br />
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
<br />
| Voice:812-855-8758 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu>
<br />

On Jul 8, 2005, at 9:58 AM, Sebastian Rahtz wrote:
<br />

<em class="quotelev1">> Laurent Romary wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> Concerning the TEI class meeting, I had booked Sept 26-27 for a while
</em><br />
<em class="quotelev2">>> on my agenda, but 29-30 is definitely not possible for me: is there a
</em><br />
<em class="quotelev2">>> reason why we change the initial plans?
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> sorry, that was me mishearing something, I thought CW said 29th. 26-27
</em><br />
<em class="quotelev1">> it is. So far in the holding cell
</em><br />
<em class="quotelev1">> are James, Sebastian, Laurent, and Syd and Lou being sought by  
</em><br />
<em class="quotelev1">> Interpol.
</em><br />
<em class="quotelev1">> Any more takers?
</em><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 />
<em class="quotelev1">> OSS Watch: JISC Open Source Advisory Service
</em><br />
<em class="quotelev1">> http://www.oss-watch.ac.uk
</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> Fri Jul 08 2005 - 11:41:26 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Fri Jul  8 14:01:27 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 8 Jul 2005 14:01:27 -0400
Subject: [tei-council] data screwed up; apologies
Message-ID: <17102.49015.77029.486849@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, 8 Jul 2005 14:01:27 -0400</span><br />
</address>

In response to a question from Sebastian I just took a look at the
<br />
data for ED W 90, and found that it is really screwed up. I'm not at
<br />
all sure what happened (looks like perhaps 1 column of data was
<br />
sorted and the others were not?), but I'll have to go back to a
<br />
previous version and reload, I think. There are dozens of really
<br />
stupid things (like the ones James caught) that I would never have
<br />
said. I'm still finishing up the minutes, but if things go well will
<br />
try to have this fixed by Monday.
<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 Jul 08 2005 - 14:01:35 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Fri Jul  8 17:19:10 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 8 Jul 2005 17:19:10 -0400
Subject: [tei-council] notes from today's conference call
Message-ID: <17102.60878.897985.297771@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, 8 Jul 2005 17:19:10 -0400</span><br />
</address>

The first draft of notes from today's call are up on the web at 
<br />

  http://www.tei-c.org/Council/tcm18.xml?style=printable
<br />

but have not been linked to from the Council index page yet (on
<br />
purpose). I'm hoping everyone will take a look (particularly search
<br />
for your name, your initials, and the string "??") and send any
<br />
corrections here within the next few days.
<br />

Note that I made a few dates for action items up on my own accord.
<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 Jul 08 2005 - 17:19:14 EDT</span>
</div>

From Julia_Flanders at Brown.edu  Fri Jul  8 17:31:00 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Fri, 8 Jul 2005 17:31:00 -0400
Subject: [tei-council] regularizing names
Message-ID: <a06200768bef49ef6ae2c@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 8 Jul 2005 17:31:00 -0400</span><br />
</address>

Here's what Perry and I have come up with concerning the 
<br />
regularization of names.
<br />

We propose, tentatively, that in P5 we handle the regularization of 
<br />
names as follows:
<br />

Name elements (<name> and the other "primary" name elements including 
<br />
<persName>, <placeName>, <orgName>, <geogName>) may carry a reg= 
<br />
attribute, which points to a <regName> element which contains 
<br />
information on regularization. This element might live in the TEI 
<br />
header or in some other convenient place. The datatype for reg= would 
<br />
be tei.data.code. The element name (<regName> as against <reg>) is 
<br />
chosen to help distinguish the function of this regularization 
<br />
structure from other kinds of regularization in the document.
<br />

The nested naming elements such as <foreName>, <surname>, etc.--i.e. 
<br />
those which cannot occur on their own but must be nested inside a 
<br />
primary naming element--would not carry the reg= attribute and cannot 
<br />
be regularized independently. We considered a mechanism for doing 
<br />
this and if any Council members think it would be a good idea we can 
<br />
add this bit.
<br />

The <regName> element may either contain a regularized version of the 
<br />
name as its content, or it may carry a pointer to an external 
<br />
resource (either locally maintained or an authority file external to 
<br />
the project, such as Library of Congress Name Authority files). It 
<br />
could also do both, and we don't see a need to police this choice 
<br />
(e.g. by making these options exclusive).
<br />

The <regName> element would carry three attributes:
<br />
--authority=  indicates what authority, if any, is being used as the 
<br />
source of the regularization, with values such as "NACO", other 
<br />
possibilities
<br />
--url= (or target=) points to an external resource
<br />
--xml:id= allows the element to be pointed to from the naming element 
<br />
in the text.
<br />

Example:
<br />

<regName authority="NACO" xml:id="rn17">Clinton, William J.</regName>
<br />
<regName authority="NACO" xml:id="rn18">Aldrin, Edwin Eugene, Jr.</regName>
<br />

<!-- above <regName> elements may be somewhere in <teiHeader> or <hyperDiv>,
<br />
            and may be part of a new prosopographic element -->
<br />
<!-- ... -->
<br />
<name reg="#rn17">Bill Clinton</name>
<br />
<persName reg="#rn18">Buzz Aldrin</persName>
<br />

We are still concerned about how this use of reg= and <regName> will 
<br />
fit in with other forms of regularization (e.g. spelling). However, 
<br />
since all other uses of reg= will probably now be addressed as child 
<br />
elements, the possibility of confusion is diminished.
<br />

Comments welcome--
<br />

Julia
<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 Jul 08 2005 - 17:31:05 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Jul  8 18:13:11 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 09 Jul 2005 07:13:11 +0900
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <20050708150504.8E1ABF4B9@webmail220.herald.ox.ac.uk>
Message-ID: <ygf8y0h9caw.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 09 Jul 2005 07:13:11 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> My diary agrees with Laurent that we had originally specified the date as 26/27 as the date. 
</em><br />

I have that in my diary as well and think that is what I said at the
<br />
call -- I plan to be there too.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Sorry we missed you Laurent...
</em><br />

Indeed. Scheduling is getting too tight, right?
<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> Fri Jul 08 2005 - 18:13:19 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Jul  8 18:16:37 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 09 Jul 2005 07:16:37 +0900
Subject: [tei-council] directory layout
In-Reply-To: <42CE90F4.90505@computing-services.oxford.ac.uk>
Message-ID: <ygf4qb59c56.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 09 Jul 2005 07:16:37 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Here is a corrected version. I generated this by making Debian packages
</em><br />
<em class="quotelev1">> of all
</em><br />
<em class="quotelev1">> the TEI-related stuff I have, and looking at /usr/share/doc/tei* and
</em><br />
<em class="quotelev1">> /usr/share/xml/tei*
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> If you are Linux geek, and install all my packages, you should find this
</em><br />
<em class="quotelev1">> structure
</em><br />
<em class="quotelev1">> on your disk. I would expect Mr oXygen to pick up the xml/tei and
</em><br />
<em class="quotelev1">> xml/teip4 trees, and
</em><br />
<em class="quotelev1">> strip out "odd" and "xquery" nodes.
</em><br />

And we should have a copy of this "framework" version somewhere at a
<br />
canonical place in the TEI webspace.
<br />

Will you hand that tree over George at oXygen?  You need to speed up,
<br />
since they are about to release a new version.
<br />

<em class="quotelev1">> My working assumption is that most people are content to fly with this,
</em><br />
<em class="quotelev1">> and just let Syd and James poke sticks are fragile details
</em><br />

Please do so:-)
<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> Fri Jul 08 2005 - 18:16:43 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Jul  8 18:36:03 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 09 Jul 2005 07:36:03 +0900
Subject: [tei-council] notes from today's conference call
In-Reply-To: <17102.60878.897985.297771@emt.wwp.brown.edu>
Message-ID: <ygfwto17woc.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 09 Jul 2005 07:36:03 +0900</span><br />
</address>

Thank yo Syd, as usual speedy and accurate work.  Amazing how you can
<br />
do that under these conditions.  I have to apologize for the bad sound
<br />
quality on my side (although I think it is more of a compatibility
<br />
issue; the Oxford trio, as well as John and Natasha came in with
<br />
excellent quality and even Julia was much better audible than you,
<br />
Syd) -- I did a quite thorough search for a headset that I could use
<br />
with a phone at home in the weeks before the call, but those products
<br />
that I tracked down were discontinued. The market does not seem very
<br />
big for this kind of stuff.
<br />

Syd Bauman <Syd_Bauman_at_Brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev1">> The first draft of notes from today's call are up on the web at 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>   http://www.tei-c.org/Council/tcm18.xml?style=printable
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> but have not been linked to from the Council index page yet (on
</em><br />
<em class="quotelev1">> purpose). I'm hoping everyone will take a look (particularly search
</em><br />
<em class="quotelev1">> for your name, your initials, and the string "??") and send any
</em><br />
<em class="quotelev1">> corrections here within the next few days.
</em><br />

What I said -- not very clearly -- about Tom Elliot and the EpiDoc
<br />
people is the following:
<br />
* I had informed them of the project in HD and a plan to produce a
<br />
  customization for that project, with a focus on how to describe the
<br />
  objects
<br />
* Tom responded (after 2 months) and said that this sounds interesting.  He
<br />
  send me some information about what he and others are doing and said
<br />
  that their main aim is more with a "best practice" approach, in other
<br />
  words to guide epigraphers with the encoding, rather than with the
<br />
  description.  There are, according to him debates about where to put
<br />
  these descriptive metadata (header vs. body) and how to do them, so
<br />
  any development here would be welcome.  He was also happy seeing the
<br />
  TEI move into this direction and would welcome (and collaborate on) a possible
<br />
  epDescription chapter in the future.  
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Note that I made a few dates for action items up on my own accord.
</em><br />

Great. We should make it a rule that every action has a date.
<br />

After the call I realized that we somehow dropped the ball on the
<br />
<choice> stuff.  Lou, do you know what the situation is?  We need to
<br />
have a proposal on how to deal with choice, since this seems to be one
<br />
of the biggest unresolved issues in P5.
<br />

All the best and a good weekend to everybody, 
<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> Fri Jul 08 2005 - 18:36:10 EDT</span>
</div>

From Julia_Flanders at brown.edu  Sat Jul  9 13:46:36 2005
From: Julia_Flanders at brown.edu (Julia Flanders)
Date: Sat, 09 Jul 2005 13:46:36 -0400
Subject: [tei-council] regularizing names
In-Reply-To: <1120870078.42cf1ebe6111f@webmail.iu.edu>
Message-ID: <42D00D7C.3070506@brown.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 09 Jul 2005 13:46:36 -0400</span><br />
</address>

John, thanks! Just in case it wasn't clear, we do envision having the 
<br />
option of pointing to an external file (whether locally maintained or 
<br />
maintained somewhere else). Our suggestion was that this pointing happen 
<br />
from the <regName> element--in other words, you always point from <name> 
<br />
(<persName>, etc.) to <regName>, and then the <regName> either tells you 
<br />
what you want to know or points you outward via its url= attribute. It 
<br />
could even do both.
<br />

I think you're right that this overlaps conceptually with key=, and I 
<br />
pondered this a bit yesterday. It seems to me that the distinction 
<br />
between key= and reg= is still that key= is a way of taking you to 
<br />
information about a person, and reg= is a way of providing (or taking 
<br />
you to) information about a name. In the situations Perry is 
<br />
envisioning, where name authority records are the source of information 
<br />
about the name, they also happen to provide that information by 
<br />
providing information about a person. But this is incidental, and might 
<br />
not always be the case.
<br />

I also think your idea about where <regName> might live seems 
<br />
reasonable. I assume that if we do develop a new prosopographic module, 
<br />
it will live in <profileDesc> and this could be incorporated thereunto.
<br />

Best, Julia
<br />

John A. Walsh wrote:
<br />

<em class="quotelev1">>Julia and Perry,
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>This seems to me to be a very elegant solution. 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I'm wondering where in the header these <regName> elements should live.  It
</em><br />
<em class="quotelev1">>seems that <profileDesc> is the logical place, since it groups together lots of
</em><br />
<em class="quotelev1">>other non-bibliographic metadata.  <profileDesc> could include a
</em><br />
<em class="quotelev1">><regularization> (or <regularisation>) element that groups together the many
</em><br />
<em class="quotelev1">><regName> elements.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>And perhaps the guidelines should also discuss the option of pointing to an
</em><br />
<em class="quotelev1">>external file dedicated to name regularizations.  For instance, if my project
</em><br />
<em class="quotelev1">>consists of hundreds of commentaries on Romantic poetry, I don't need to repeat
</em><br />
<em class="quotelev1">><regName authority="LCNAF" id="byron" >Byron, George Gordon Byron,
</em><br />
<em class="quotelev1">>Baron</regName> in every document.  Rather, I could do something like this:
</em><br />
<em class="quotelev1">>"...the dastardly and poisonous malignity of <persName
</em><br />
<em class="quotelev1">>reg="myRegNames.xml#byron">Byron's</persName> most foul and treacherous
</em><br />
<em class="quotelev1">>libel...," pointing to a master myRegNames.xml file.  Of course, this latter
</em><br />
<em class="quotelev1">>approach has some potential overlap with the functionality of @key, if one
</em><br />
<em class="quotelev1">>accepts that the key can be an id in an XML file as well as it could be a id in
</em><br />
<em class="quotelev1">>a database.  But then the TEI is all about choices :-), so I don't see this as a
</em><br />
<em class="quotelev1">>problem.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>John
</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> Sat Jul 09 2005 - 13:45:56 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sat Jul  9 13:48:35 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 9 Jul 2005 13:48:35 -0400
Subject: [tei-council] directory layout again
In-Reply-To: <42CE784E.5050703@computing-services.oxford.ac.uk>
Message-ID: <17104.3571.800176.722834@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, 9 Jul 2005 13:48:35 -0400</span><br />
</address>

Sebastian Rahtz writes:
<br />

<em class="quotelev1">> every "package" gets a doc directory. it may just have a changelog
</em><br />

Thanks for the explanation. It's obvious, once I poke around a bit,
<br />
but to be honest, I'd nevber put 2 and 2 together.
<br />

Will look at revised structure now ... (the one you posted Fri, 08
<br />
Jul 2005 15:43:00 +0100; speak quickly if it's not the most recent)
<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 Jul 09 2005 - 13:48:39 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jul  9 14:08:38 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 09 Jul 2005 19:08:38 +0100
Subject: [tei-council] directory layout
In-Reply-To: <ygf4qb59c56.fsf@chwpb.local>
Message-ID: <42D012A6.3080400@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 09 Jul 2005 19:08:38 +0100</span><br />
</address>

<em class="quotelev1">>And we should have a copy of this "framework" version somewhere at a
</em><br />
<em class="quotelev1">>canonical place in the TEI webspace.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
yes, my idea is to remove all existing DTDs, schemas, stylesheets,
<br />
guidelines
<br />
from the web site and use just one copy in this new tree. obviously,
<br />
redirects from the
<br />
existing locations!
<br />

<em class="quotelev1">>Will you hand that tree over George at oXygen?  You need to speed up,
</em><br />
<em class="quotelev1">>since they are about to release a new version.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
will do
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sat Jul 09 2005 - 14:09:13 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jul  9 14:42:51 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 09 Jul 2005 19:42:51 +0100
Subject: [tei-council] regularizing names
In-Reply-To: <42D00D7C.3070506@brown.edu>
Message-ID: <42D01AAB.1040704@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 09 Jul 2005 19:42:51 +0100</span><br />
</address>

if we're fooling around in there, please can slip in <death> to mirror
<br />
<birth> without further ado?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sat Jul 09 2005 - 14:43:25 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jul  9 17:32:44 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 09 Jul 2005 22:32:44 +0100
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <C0D504FF-660E-4F58-8FF2-AA3891A581E4@indiana.edu>
Message-ID: <42D0427C.5070200@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 09 Jul 2005 22:32:44 +0100</span><br />
</address>

John A. Walsh wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I'm interested in the class system and believe I could make useful 
</em><br />
<em class="quotelev1">> contributions.  If others agree, I'd like to participate in the 
</em><br />
<em class="quotelev1">> meeting, though I'm aware there's some concern about keeping the 
</em><br />
<em class="quotelev1">> group to a manageable size.  My feelings won't be hurt if I can't be 
</em><br />
<em class="quotelev1">> included.
</em><br />

I guess this raises the question of how we're going to structure and run
<br />
this meeting. It's
<br />
probably fair to say that any group larger than 3 or 4 can't just sit
<br />
around the table
<br />
and "discuss". Practical suggestions on how to use the available
<br />
brainpower, please?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sat Jul 09 2005 - 17:33:23 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jul  9 18:34:05 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 09 Jul 2005 23:34:05 +0100
Subject: [tei-council] notes from today's conference call
In-Reply-To: <17102.60878.897985.297771@emt.wwp.brown.edu>
Message-ID: <42D050DD.1050306@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 09 Jul 2005 23:34:05 +0100</span><br />
</address>

on datatypes:
<br />

"Concern was expressed over the general concept of permitting TEI
<br />
datatypes to further constrain or relax underlying W3C datatypes.
<br />
However, the opposite point of view, that it is important not to be
<br />
straight-jacketed by a single set of datatypes primarily intended for
<br />
business applications, was also expressed."
<br />

I am not sure this reflects the discussion. Perhaps
<br />

"Concern was expressed over the use of regexp-based extensions to W3C
<br />
datatypes, particularly in the duration datatype. There was disagreement
<br />
about the general principle of whether or not the TEI should force
<br />
itself to stick to strict W3C datatypes, but it was clear that the issue
<br />
required more discussion".
<br />

but perhaps my rewording is as biased towards my viewpoint as Syd's
<br />
wording is biased towards his :-}
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sat Jul 09 2005 - 18:34:40 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jul  9 18:37:04 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 09 Jul 2005 23:37:04 +0100
Subject: [tei-council] notes from today's conference call
In-Reply-To: <17102.60878.897985.297771@emt.wwp.brown.edu>
Message-ID: <42D05190.3090904@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 09 Jul 2005 23:37:04 +0100</span><br />
</address>

I am not sure this is really correct:
<br />

"There were three suggestions on when such releases would occur: a
<br />
pre-defined timetable; when significant updates occur or have accrued,
<br />
based on the editors' judgement; and at Sebastian's readiness to do so. "
<br />

the third proposal was really that a separate Change Release Manager
<br />
should make the decision. but maybe
<br />
that was not made clear.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sat Jul 09 2005 - 18:37:38 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sat Jul  9 21:50:29 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 9 Jul 2005 21:50:29 -0400
Subject: [tei-council] notes from today's conference call
In-Reply-To: <42D050DD.1050306@computing-services.oxford.ac.uk>
Message-ID: <17104.32485.84319.875725@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, 9 Jul 2005 21:50:29 -0400</span><br />
</address>

Sebastian Rahtz writes:
<br />

<em class="quotelev1">> "Concern was expressed over the general concept of permitting TEI
</em><br />
<em class="quotelev1">> datatypes to further constrain or relax underlying W3C datatypes.
</em><br />
<em class="quotelev1">> However, the opposite point of view, that it is important not to be
</em><br />
<em class="quotelev1">> straight-jacketed by a single set of datatypes primarily intended
</em><br />
<em class="quotelev1">> for business applications, was also expressed."
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I am not sure this reflects the discussion. Perhaps
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> "Concern was expressed over the use of regexp-based extensions to
</em><br />
<em class="quotelev1">> W3C datatypes, particularly in the duration datatype. There was
</em><br />
<em class="quotelev1">> disagreement about the general principle of whether or not the TEI
</em><br />
<em class="quotelev1">> should force itself to stick to strict W3C datatypes, but it was
</em><br />
<em class="quotelev1">> clear that the issue required more discussion".
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> but perhaps my rewording is as biased towards my viewpoint as Syd's
</em><br />
<em class="quotelev1">> wording is biased towards his :-}
</em><br />

Oh dear. You're quite right -- if read as including <valList>s my
<br />
description of your position makes you sound like a madman. My
<br />
apologies.
<br />

You did express it as a general concern, and then focused in on the
<br />
regexps, particularly on tei.data.duration.[1] Would you prefer we
<br />
just focused in on the pattern, perhaps of duration, for the minutes?
<br />
In either case, we may as well use the correct terminology:
<br />

  Concern was expressed over the use of W3C 'pattern' facets,
<br />
  particularly in the datatype 'tei.data.duration'. There was
<br />
  disagreement about the general principle of whether or not the TEI
<br />
  should force itself to stick to strict W3C datatypes, but it was
<br />
  clear that the issue required more discussion.
<br />

Would that do?
<br />

<p>Note
<br />

----
[1] But I was presuming that was merely an example, as there are a
    half-dozen datatypes that are restricted by regexps. On the other
    hand, as mentioned in a previous discussion, I have to admit I
    don't really *like* the pattern I came up with for duration,
    whereas I think I like all the others.
_______________________________________________
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 Jul 09 2005 - 21:50:33 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sat Jul  9 21:52:36 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 9 Jul 2005 21:52:36 -0400
Subject: [tei-council] notes from today's conference call
In-Reply-To: <42D05190.3090904@computing-services.oxford.ac.uk>
Message-ID: <17104.32612.346281.385810@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, 9 Jul 2005 21:52:36 -0400</span><br />
</address>

Sebastian Rahtz writes:
<br />
<em class="quotelev1">> I am not sure this is really correct:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> "There were three suggestions on when such releases would occur: a
</em><br />
<em class="quotelev1">> pre-defined timetable; when significant updates occur or have
</em><br />
<em class="quotelev1">> accrued, based on the editors' judgement; and at Sebastian's
</em><br />
<em class="quotelev1">> readiness to do so. "
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> the third proposal was really that a separate Change Release
</em><br />
<em class="quotelev1">> Manager should make the decision. but maybe that was not made
</em><br />
<em class="quotelev1">> clear.
</em><br />

Certainly wasn't clear to me, but I distinctly heard Christian say
<br />
"Sebastian".
<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 Jul 09 2005 - 21:52:40 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 10 07:14:02 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 10 Jul 2005 12:14:02 +0100
Subject: [tei-council] notes from today's conference call
In-Reply-To: <17104.32485.84319.875725@emt.wwp.brown.edu>
Message-ID: <42D102FA.2090809@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 10 Jul 2005 12:14:02 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>  Concern was expressed over the use of W3C 'pattern' facets,
</em><br />
<em class="quotelev1">>  particularly in the datatype 'tei.data.duration'. There was
</em><br />
<em class="quotelev1">>  disagreement about the general principle of whether or not the TEI
</em><br />
<em class="quotelev1">>  should force itself to stick to strict W3C datatypes, but it was
</em><br />
<em class="quotelev1">>  clear that the issue required more discussion.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Would that do?
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
sure
<br />

<em class="quotelev1">>[1] But I was presuming that was merely an example, as there are a
</em><br />
<em class="quotelev1">>    half-dozen datatypes that are restricted by regexps. On the other
</em><br />
<em class="quotelev1">>    hand, as mentioned in a previous discussion, I have to admit I
</em><br />
<em class="quotelev1">>    don't really *like* the pattern I came up with for duration,
</em><br />
<em class="quotelev1">>    whereas I think I like all the others.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I am such an unthinking person, I can only really get to grips
<br />
to this by example and implementation, so I propose to do
<br />
some experiments by way of comment
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Jul 10 2005 - 07:14:42 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Jul 10 08:30:05 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 10 Jul 2005 08:30:05 -0400
Subject: [tei-council] notes from today's conference call
In-Reply-To: <42D102FA.2090809@computing-services.oxford.ac.uk>
Message-ID: <17105.5325.371678.71043@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, 10 Jul 2005 08:30:05 -0400</span><br />
</address>

Note from 2005-07-08 conference call have been updated with both
<br />
Christian's and Sebastian's corrections. They are still at 
<br />
  http://www.tei-c.org/Council/tcm18.xml?style=printable
<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 Jul 10 2005 - 08:30:09 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sun Jul 10 09:38:44 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 10 Jul 2005 14:38:44 +0100
Subject: [tei-council] notes from today's conference call
In-Reply-To: <42D102FA.2090809@computing-services.oxford.ac.uk>
Message-ID: <42D124E4.7010803@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, 10 Jul 2005 14:38:44 +0100</span><br />
</address>

The action on me, as I understood it at the time was not exactly to
<br />

"look at list of attributes that need to be assassinated, report back to 
<br />
Council which ones are trivial (e.g., because element is empty and there 
<br />
is only 1 such attribute), not difficult, or present real problems that 
<br />
might need this approach"
<br />

but rather to implement assassination in the trivial cases, only 
<br />
reporting back to Council where the victim refused to keel over or might 
<br />
have some shred of a defence against it.
<br />

However, Council will in any case be informed of all cases by virtue of 
<br />
the changelog reports.
<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 Jul 10 2005 - 09:27:55 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 10 18:07:07 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 10 Jul 2005 23:07:07 +0100
Subject: [tei-council] meeting technologies
Message-ID: <42D19C0B.7000705@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 10 Jul 2005 23:07:07 +0100</span><br />
</address>

We had an agenda item last week, missed out because Alex was absent,
<br />
about alternative
<br />
technologies for virtual council meetings.
<br />

I wonder if we can pursue this a little? I spent some time at
<br />
a conference last week at which we were encouraged
<br />
to experiment with various tools, including instant messaging
<br />
and Skype internet telephony. I was surprised to find that
<br />
the instant messaging conversations were quite reasonable
<br />
(we used IRC, but it could be anything).
<br />

Do  you all find the telephony a plausible method of communication?
<br />
Would you be interested in an alternate trial of IM?
<br />

Another more radical alternative would be video conferencing.
<br />
How many of you would be willing to risk that?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Jul 10 2005 - 18:07:48 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Jul 10 21:13:54 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 11 Jul 2005 10:13:54 +0900
Subject: [tei-council] notes from today's conference call
In-Reply-To: <17104.32612.346281.385810@emt.wwp.brown.edu>
Message-ID: <ygfeka6du0d.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 11 Jul 2005 10:13:54 +0900</span><br />
</address>

Syd Bauman <Syd_Bauman_at_Brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev1">> Sebastian Rahtz writes:
</em><br />
<em class="quotelev2">>> I am not sure this is really correct:
</em><br />
<em class="quotelev2">>> 
</em><br />
<em class="quotelev2">>> "There were three suggestions on when such releases would occur: a
</em><br />
<em class="quotelev2">>> pre-defined timetable; when significant updates occur or have
</em><br />
<em class="quotelev2">>> accrued, based on the editors' judgement; and at Sebastian's
</em><br />
<em class="quotelev2">>> readiness to do so. "
</em><br />
<em class="quotelev2">>> 
</em><br />
<em class="quotelev2">>> the third proposal was really that a separate Change Release
</em><br />
<em class="quotelev2">>> Manager should make the decision. but maybe that was not made
</em><br />
<em class="quotelev2">>> clear.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Certainly wasn't clear to me, but I distinctly heard Christian say
</em><br />
<em class="quotelev1">> "Sebastian".
</em><br />

Which could be seen as a kind of shorthand to "Change Release
<br />
Manager", at least that was my intention.
<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> Sun Jul 10 2005 - 21:13:58 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Jul 10 21:23:06 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 11 Jul 2005 10:23:06 +0900
Subject: [tei-council] meeting technologies
In-Reply-To: <42D19C0B.7000705@computing-services.oxford.ac.uk>
Message-ID: <ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 11 Jul 2005 10:23:06 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> We had an agenda item last week, missed out because Alex was absent,
</em><br />
<em class="quotelev1">> about alternative
</em><br />
<em class="quotelev1">> technologies for virtual council meetings.
</em><br />

This came out of a discussion we had in Paris, born out of the
<br />
frustration with the current infrastructure.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I wonder if we can pursue this a little? I spent some time at
</em><br />
<em class="quotelev1">> a conference last week at which we were encouraged
</em><br />
<em class="quotelev1">> to experiment with various tools, including instant messaging
</em><br />
<em class="quotelev1">> and Skype internet telephony. I was surprised to find that
</em><br />
<em class="quotelev1">> the instant messaging conversations were quite reasonable
</em><br />
<em class="quotelev1">> (we used IRC, but it could be anything).
</em><br />

I am very open on this.  I'm not sure, if Skype is up to the task, but
<br />
IM (which I used for a grand total of about 30 minutes to day) sounds
<br />
promising.  
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Do  you all find the telephony a plausible method of communication?
</em><br />
<em class="quotelev1">> Would you be interested in an alternate trial of IM?
</em><br />

I am all in favor on this.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Another more radical alternative would be video conferencing.
</em><br />
<em class="quotelev1">> How many of you would be willing to risk that?
</em><br />

For Mac users, there is always iChat, don't know about others and
<br />
compatibility issues.  
<br />

I suggest that we try some of these things in a small group and report
<br />
our findings to the list.  
<br />

I will volunteer to be part of this and suggest that we collect
<br />
another two or three (including sb from the US) and start discuss
<br />
things among this group.
<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> Sun Jul 10 2005 - 21:23:10 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Jul 10 21:38:38 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 11 Jul 2005 10:38:38 +0900
Subject: [tei-council] regularizing names
In-Reply-To: <42D00D7C.3070506@brown.edu>
Message-ID: <ygf64vidsv5.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 11 Jul 2005 10:38:38 +0900</span><br />
</address>

(I have not seen John's post -- did it go to the list?)
<br />

Julia Flanders <Julia_Flanders_at_brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev1">> I think you're right that this overlaps conceptually with key=, and I
</em><br />
<em class="quotelev1">> pondered this a bit yesterday. It seems to me that the distinction
</em><br />
<em class="quotelev1">> between key= and reg= is still that key= is a way of taking you to
</em><br />
<em class="quotelev1">> information about a person, and reg= is a way of providing (or taking
</em><br />
<em class="quotelev1">> you to) information about a name. In the situations Perry is
</em><br />
<em class="quotelev1">> envisioning, where name authority records are the source of
</em><br />
<em class="quotelev1">> information about the name, they also happen to provide that
</em><br />
<em class="quotelev1">> information by providing information about a person. But this is
</em><br />
<em class="quotelev1">> incidental, and might not always be the case.
</em><br />

But in cases where this is the case, it would be bothersome to have to
<br />
provide both.  We might need a mechanism that allows some control over
<br />
how to handle such cases.
<br />

<em class="quotelev2">>>And perhaps the guidelines should also discuss the option of pointing to an
</em><br />
<em class="quotelev2">>>external file dedicated to name regularizations.  For instance, if my project
</em><br />
<em class="quotelev2">>>consists of hundreds of commentaries on Romantic poetry, I don't need to repeat
</em><br />
<em class="quotelev2">>><regName authority="LCNAF" id="byron" >Byron, George Gordon Byron,
</em><br />
<em class="quotelev2">>>Baron</regName> in every document.  Rather, I could do something like this:
</em><br />
<em class="quotelev2">>>"...the dastardly and poisonous malignity of <persName
</em><br />
<em class="quotelev2">>>reg="myRegNames.xml#byron">Byron's</persName> most foul and treacherous
</em><br />
<em class="quotelev2">>>libel...," pointing to a master myRegNames.xml file.  Of course, this latter
</em><br />
<em class="quotelev2">>>approach has some potential overlap with the functionality of @key, if one
</em><br />
<em class="quotelev2">>>accepts that the key can be an id in an XML file as well as it could be a id in
</em><br />
<em class="quotelev2">>>a database.  But then the TEI is all about choices :-), so I don't see this as a
</em><br />
<em class="quotelev2">>>problem.
</em><br />

We do have a similar case (of referencing information from the text to
<br />
information in the header) with the socalled Gaiji module, where a list
<br />
of character description occurs in the Header, but one might in the
<br />
same way want to keep them in a separate file for collections.  There
<br />
are two (?) possibilities for this I can think of at the moment, 
<br />

* hardcode the reference like in  John's example above:
<br />
  <persName>reg="myRegNames.xml#byron">Byron's</persName>
<br />

* use bar pointers to the header and dereference from there, probably
<br />
  using XInclude:
<br />
  <persName>reg="#byron">Byron's</persName>
<br />

  and in the header:
<br />
  <profileDesc>
<br />
    <xi:include href="myRegnames.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
<br />
  ...
<br />

Of course, this is all up to the encoder, but we might want to include
<br />
an example that demonstrates this.
<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> Sun Jul 10 2005 - 21:38:42 EDT</span>
</div>

From jawalsh at indiana.edu  Sun Jul 10 21:47:05 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Sun, 10 Jul 2005 20:47:05 -0500
Subject: [tei-council] meeting technologies
In-Reply-To: <ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <D3840523-1E00-43E7-A919-54EDE6495755@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>: Sun, 10 Jul 2005 20:47:05 -0500</span><br />
</address>

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I suggest that we try some of these things in a small group and report
</em><br />
<em class="quotelev1">> our findings to the list.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I will volunteer to be part of this and suggest that we collect
</em><br />
<em class="quotelev1">> another two or three (including sb from the US) and start discuss
</em><br />
<em class="quotelev1">> things among this group.
</em><br />

I have an iSight (video camera) and various IM accounts (ICQ, AIM,  
<br />
Yahoo, iChat), so I'd be happy to be part of the test group.
<br />

John
<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="quotelev1">>  Christian Wittern
</em><br />
<em class="quotelev1">>  Institute for Research in Humanities, Kyoto University
</em><br />
<em class="quotelev1">>  47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
</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> Sun Jul 10 2005 - 21:47:22 EDT</span>
</div>

From jawalsh at indiana.edu  Sun Jul 10 21:48:05 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Sun, 10 Jul 2005 20:48:05 -0500
Subject: Fwd: [tei-council] regularizing names
In-Reply-To: <1120870078.42cf1ebe6111f@webmail.iu.edu>
Message-ID: <32F6167B-5D2E-42C3-98D4-C9312EEA3668@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>: Sun, 10 Jul 2005 20:48:05 -0500</span><br />
</address>

Here's my previous reply to Julia.  I meant to send it to the list,  
<br />
but it only went to Julia.
<br />

John
<br />
| John A. Walsh, Associate Director for Projects and Services
<br />
| Digital Library Program / Indiana University Libraries
<br />
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
<br />
| Voice:812-855-8758 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu>
<br />

Begin forwarded message:
<br />

<em class="quotelev1">> From: "John A. Walsh" <jawalsh_at_indiana.edu>
</em><br />
<em class="quotelev1">> Date: July 8, 2005 7:47:58 PM EST
</em><br />
<em class="quotelev1">> To: Julia Flanders <Julia_Flanders_at_Brown.edu>
</em><br />
<em class="quotelev1">> Subject: Re: [tei-council] regularizing names
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Julia and Perry,
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> This seems to me to be a very elegant solution.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I'm wondering where in the header these <regName> elements should  
</em><br />
<em class="quotelev1">> live.  It
</em><br />
<em class="quotelev1">> seems that <profileDesc> is the logical place, since it groups  
</em><br />
<em class="quotelev1">> together lots of
</em><br />
<em class="quotelev1">> other non-bibliographic metadata.  <profileDesc> could include a
</em><br />
<em class="quotelev1">> <regularization> (or <regularisation>) element that groups together  
</em><br />
<em class="quotelev1">> the many
</em><br />
<em class="quotelev1">> <regName> elements.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> And perhaps the guidelines should also discuss the option of  
</em><br />
<em class="quotelev1">> pointing to an
</em><br />
<em class="quotelev1">> external file dedicated to name regularizations.  For instance, if  
</em><br />
<em class="quotelev1">> my project
</em><br />
<em class="quotelev1">> consists of hundreds of commentaries on Romantic poetry, I don't  
</em><br />
<em class="quotelev1">> need to repeat
</em><br />
<em class="quotelev1">> <regName authority="LCNAF" id="byron" >Byron, George Gordon Byron,
</em><br />
<em class="quotelev1">> Baron</regName> in every document.  Rather, I could do something  
</em><br />
<em class="quotelev1">> like this:
</em><br />
<em class="quotelev1">> "...the dastardly and poisonous malignity of <persName
</em><br />
<em class="quotelev1">> reg="myRegNames.xml#byron">Byron's</persName> most foul and  
</em><br />
<em class="quotelev1">> treacherous
</em><br />
<em class="quotelev1">> libel...," pointing to a master myRegNames.xml file.  Of course,  
</em><br />
<em class="quotelev1">> this latter
</em><br />
<em class="quotelev1">> approach has some potential overlap with the functionality of @key,  
</em><br />
<em class="quotelev1">> if one
</em><br />
<em class="quotelev1">> accepts that the key can be an id in an XML file as well as it  
</em><br />
<em class="quotelev1">> could be a id in
</em><br />
<em class="quotelev1">> a database.  But then the TEI is all about choices :-), so I don't  
</em><br />
<em class="quotelev1">> see this as a
</em><br />
<em class="quotelev1">> problem.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> John
</em><br />
<em class="quotelev1">> -- 
</em><br />
<em class="quotelev1">> | John A. Walsh, Associate Director for Projects and Services
</em><br />
<em class="quotelev1">> | Digital Library Program / Indiana University Libraries
</em><br />
<em class="quotelev1">> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
</em><br />
<em class="quotelev1">> | Voice:812-855-8758 Fax:812-856-2062 <mailto:jawalsh_at_indiana.edu>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Quoting Julia Flanders <Julia_Flanders_at_Brown.edu>:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> Here's what Perry and I have come up with concerning the
</em><br />
<em class="quotelev2">>> regularization of names.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> We propose, tentatively, that in P5 we handle the regularization of
</em><br />
<em class="quotelev2">>> names as follows:
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> Name elements (<name> and the other "primary" name elements including
</em><br />
<em class="quotelev2">>> <persName>, <placeName>, <orgName>, <geogName>) may carry a reg=
</em><br />
<em class="quotelev2">>> attribute, which points to a <regName> element which contains
</em><br />
<em class="quotelev2">>> information on regularization. This element might live in the TEI
</em><br />
<em class="quotelev2">>> header or in some other convenient place. The datatype for reg= would
</em><br />
<em class="quotelev2">>> be tei.data.code. The element name (<regName> as against <reg>) is
</em><br />
<em class="quotelev2">>> chosen to help distinguish the function of this regularization
</em><br />
<em class="quotelev2">>> structure from other kinds of regularization in the document.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> The nested naming elements such as <foreName>, <surname>, etc.--i.e.
</em><br />
<em class="quotelev2">>> those which cannot occur on their own but must be nested inside a
</em><br />
<em class="quotelev2">>> primary naming element--would not carry the reg= attribute and cannot
</em><br />
<em class="quotelev2">>> be regularized independently. We considered a mechanism for doing
</em><br />
<em class="quotelev2">>> this and if any Council members think it would be a good idea we can
</em><br />
<em class="quotelev2">>> add this bit.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> The <regName> element may either contain a regularized version of the
</em><br />
<em class="quotelev2">>> name as its content, or it may carry a pointer to an external
</em><br />
<em class="quotelev2">>> resource (either locally maintained or an authority file external to
</em><br />
<em class="quotelev2">>> the project, such as Library of Congress Name Authority files). It
</em><br />
<em class="quotelev2">>> could also do both, and we don't see a need to police this choice
</em><br />
<em class="quotelev2">>> (e.g. by making these options exclusive).
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> The <regName> element would carry three attributes:
</em><br />
<em class="quotelev2">>> --authority=  indicates what authority, if any, is being used as the
</em><br />
<em class="quotelev2">>> source of the regularization, with values such as "NACO", other
</em><br />
<em class="quotelev2">>> possibilities
</em><br />
<em class="quotelev2">>> --url= (or target=) points to an external resource
</em><br />
<em class="quotelev2">>> --xml:id= allows the element to be pointed to from the naming element
</em><br />
<em class="quotelev2">>> in the text.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> Example:
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> <regName authority="NACO" xml:id="rn17">Clinton, William J.</regName>
</em><br />
<em class="quotelev2">>> <regName authority="NACO" xml:id="rn18">Aldrin, Edwin Eugene, Jr.</ 
</em><br />
<em class="quotelev2">>> regName>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> 
</em><br />
<em class="quotelev2">>> 
</em><br />
<em class="quotelev2">>> <name reg="#rn17">Bill Clinton</name>
</em><br />
<em class="quotelev2">>> <persName reg="#rn18">Buzz Aldrin</persName>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> We are still concerned about how this use of reg= and <regName> will
</em><br />
<em class="quotelev2">>> fit in with other forms of regularization (e.g. spelling). However,
</em><br />
<em class="quotelev2">>> since all other uses of reg= will probably now be addressed as child
</em><br />
<em class="quotelev2">>> elements, the possibility of confusion is diminished.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> Comments welcome--
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> Julia
</em><br />
<em class="quotelev2">>> _______________________________________________
</em><br />
<em class="quotelev2">>> tei-council mailing list
</em><br />
<em class="quotelev2">>> tei-council_at_lists.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> Sun Jul 10 2005 - 21:48:10 EDT</span>
</div>

From james.cummings at computing-services.oxford.ac.uk  Mon Jul 11 03:31:11 2005
From: james.cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Mon, 11 Jul 2005 08:31:11 +0100 (BST)
Subject: [tei-council] Re: Meeting technologies
Message-ID: <20050711073111.D5B1C226CA@webmail218.herald.ox.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>: Mon, 11 Jul 2005 08:31:11 +0100 (BST)</span><br />
</address>
 ('binary' encoding is not supported, stored as-is)
John A. Walsh wrote:
<br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> I suggest that we try some of these things in a small group and report
</em><br />
<em class="quotelev2">>> our findings to the list.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> I will volunteer to be part of this and suggest that we collect
</em><br />
<em class="quotelev2">>> another two or three (including sb from the US) and start discuss
</em><br />
<em class="quotelev2">>> things among this group.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I have an iSight (video camera) and various IM accounts (ICQ, AIM,  
</em><br />
<em class="quotelev1">> Yahoo, iChat), so I'd be happy to be part of the test group.
</em><br />

I too use instant messaging (Aim/Yahoo/MSN/Jabber/etc.) and IRC on a daily basis.
<br />

As the most mature of these protocols could I suggest IRC.  The client I use (Linux/Windows) is Gaim  (gaim.sourceforge.net) since it is a multi-protocol client and talks to all of these and more.   But there are IRC clients for almost every operating system...
<br />

When I'm online at the moment I tend to sit in a channel #dm-exec on the irc.freenode.net server for my work with digital medievalist.  However I've just created a channel #tei-c and will simultaneously sit in that channel any time I'm online. (I'm set to auto-join, so no more difficult...Of course that is just in case anyone wants to chat, we would arrange a time if actually meeting ;-))  
<br />
And since I'm at a conference at the moment I really won't be online that much ths week!  
<br />

When I've suggested this before, I believe one of the objections was that it might damage Syd's wrists even more attempting to keep up.
<br />

This is my suggestion, but I'm happy to trial in whatever way people want.
<br />

Best,
<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> Mon Jul 11 2005 - 03:31:18 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Mon Jul 11 16:44:37 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 11 Jul 2005 21:44:37 +0100
Subject: [tei-council] regularizing names
In-Reply-To: <a06200768bef49ef6ae2c@[128.148.157.102]>
Message-ID: <42D2DA35.8040007@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, 11 Jul 2005 21:44:37 +0100</span><br />
</address>

The main problem I have with this is that all the examples cited seem to 
<br />
be about linking the name to a PERSON not to a NAME, in which case the 
<br />
existing key attribute would surely be more appropriate? (That's not to 
<br />
say that having a <regName> child within <person> wouldn't be a good 
<br />
idea). But the only use for having both a reg attribute and a key 
<br />
attribute on a name ought to be for one to regularize the name, and the 
<br />
other to regularize the thing-named. In which case, we have to be able 
<br />
to support the reg attribute on components of names, e.g.
<br />
<name key="JF">
<br />
<forename reg="JULIA">Juley</forename>
<br />
<surname reg="FLANDERS">Flanderes</surname>
<br />
</name>
<br />

<person ident="JF">
<br />
<regName>
<br />
<forename ident="JULIA">Julia</forename>
<br />
<surname ident="FLANDERS">Flanders</surname>
<br />
</regName>
<br />
<!-- other demographic info here -->
<br />
</person>
<br />

[I've used co-labelling here rather than ID/IDREF but the same principle 
<br />
applies]
<br />

in haste
<br />

Lou
<br />
Julia Flanders wrote:
<br />

<em class="quotelev1">> Here's what Perry and I have come up with concerning the 
</em><br />
<em class="quotelev1">> regularization of names.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> We propose, tentatively, that in P5 we handle the regularization of 
</em><br />
<em class="quotelev1">> names as follows:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Name elements (<name> and the other "primary" name elements including 
</em><br />
<em class="quotelev1">> <persName>, <placeName>, <orgName>, <geogName>) may carry a reg= 
</em><br />
<em class="quotelev1">> attribute, which points to a <regName> element which contains 
</em><br />
<em class="quotelev1">> information on regularization. This element might live in the TEI 
</em><br />
<em class="quotelev1">> header or in some other convenient place. The datatype for reg= would 
</em><br />
<em class="quotelev1">> be tei.data.code. The element name (<regName> as against <reg>) is 
</em><br />
<em class="quotelev1">> chosen to help distinguish the function of this regularization 
</em><br />
<em class="quotelev1">> structure from other kinds of regularization in the document.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> The nested naming elements such as <foreName>, <surname>, etc.--i.e. 
</em><br />
<em class="quotelev1">> those which cannot occur on their own but must be nested inside a 
</em><br />
<em class="quotelev1">> primary naming element--would not carry the reg= attribute and cannot 
</em><br />
<em class="quotelev1">> be regularized independently. We considered a mechanism for doing this 
</em><br />
<em class="quotelev1">> and if any Council members think it would be a good idea we can add 
</em><br />
<em class="quotelev1">> this bit.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> The <regName> element may either contain a regularized version of the 
</em><br />
<em class="quotelev1">> name as its content, or it may carry a pointer to an external resource 
</em><br />
<em class="quotelev1">> (either locally maintained or an authority file external to the 
</em><br />
<em class="quotelev1">> project, such as Library of Congress Name Authority files). It could 
</em><br />
<em class="quotelev1">> also do both, and we don't see a need to police this choice (e.g. by 
</em><br />
<em class="quotelev1">> making these options exclusive).
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> The <regName> element would carry three attributes:
</em><br />
<em class="quotelev1">> --authority= indicates what authority, if any, is being used as the 
</em><br />
<em class="quotelev1">> source of the regularization, with values such as "NACO", other 
</em><br />
<em class="quotelev1">> possibilities
</em><br />
<em class="quotelev1">> --url= (or target=) points to an external resource
</em><br />
<em class="quotelev1">> --xml:id= allows the element to be pointed to from the naming element 
</em><br />
<em class="quotelev1">> in the text.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Example:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> <regName authority="NACO" xml:id="rn17">Clinton, William J.</regName>
</em><br />
<em class="quotelev1">> <regName authority="NACO" xml:id="rn18">Aldrin, Edwin Eugene, 
</em><br />
<em class="quotelev1">> Jr.</regName>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> <name reg="#rn17">Bill Clinton</name>
</em><br />
<em class="quotelev1">> <persName reg="#rn18">Buzz Aldrin</persName>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> We are still concerned about how this use of reg= and <regName> will 
</em><br />
<em class="quotelev1">> fit in with other forms of regularization (e.g. spelling). However, 
</em><br />
<em class="quotelev1">> since all other uses of reg= will probably now be addressed as child 
</em><br />
<em class="quotelev1">> elements, the possibility of confusion is diminished.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Comments welcome--
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Julia
</em><br />
<em class="quotelev1">> _______________________________________________
</em><br />
<em class="quotelev1">> tei-council mailing list
</em><br />
<em class="quotelev1">> tei-council_at_lists.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 />

_______________________________________________
<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 Jul 11 2005 - 16:44:44 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jul 12 05:53:57 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 12 Jul 2005 10:53:57 +0100
Subject: [tei-council] release of P5
Message-ID: <42D39335.1050302@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 12 Jul 2005 10:53:57 +0100</span><br />
</address>

In case anyone is wondering, I have got the material ready for this grand
<br />
new release, but I am waiting for confirmation from George Bina that he is
<br />
happy with it all in oXygen.  As soon as he says it works for him, I'll
<br />
make the release on Sourceforge, and make an announcement on TEI-L
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Jul 12 2005 - 05:54:43 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jul 12 18:49:14 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 12 Jul 2005 23:49:14 +0100
Subject: [tei-council] next meeting
Message-ID: <42D448EA.5010102@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 12 Jul 2005 23:49:14 +0100</span><br />
</address>

more than half of you have not been to meetomatic to tell me
<br />
when you can do the next telco....
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Jul 12 2005 - 18:50:03 EDT</span>
</div>

From nsmith at email.unc.edu  Wed Jul 13 13:47:06 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Wed, 13 Jul 2005 13:47:06 -0400 (Eastern Daylight Time)
Subject: [tei-council] Organization of the CO chapter
In-Reply-To: <42D2DA35.8040007@computing-services.oxford.ac.uk>
Message-ID: <Pine.WNT.4.10.10507131341190.3988-100000@AALCD49.lib.unc.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Natasha Smith <nsmith_at_email.unc.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 13 Jul 2005 13:47:06 -0400 (Eastern Daylight Time)</span><br />
</address>

Dear colleagues:
<br />

Per your request, John and I are in the process of reviewing the CO
<br />
chapter (Elements Available in all TEI Documents.) As we mentioned in our
<br />
short report submitted before the last conference call, quite a challenge
<br />
is to decide whether the chapter needs a dramatic reorganization. We would
<br />
like to solicit your ideas and would like to sense a level of
<br />
dissatisfaction (if any) about the current structure of the CO.  
<br />
Thinking more about this, both John and I came up with three possible
<br />
solutions (and/or combinations of them):
<br />

1.	leave the current organization (with some inevitable tweaking to
<br />
bring it up to the conformance with P5). As you know, there are currently
<br />
11 sections in the chapter, which is a lot, but not too overwhelming. Plus
<br />
sections have a really good prose that would be too bad to loose. 
<br />
2.	organize all the elements by model classes 
<br />
3.	provide an alphabetical list of all elements (I would like to have
<br />
it as an option, but not as the only one, but in addition to the #1 or #2)
<br />

What do you think? Any suggestions will be greatly appreciated.
<br />

Best, ns
<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 Jul 13 2005 - 13:48:04 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jul 13 14:12:53 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 13 Jul 2005 19:12:53 +0100
Subject: [tei-council] Organization of the CO chapter
In-Reply-To: <Pine.WNT.4.10.10507131341190.3988-100000@AALCD49.lib.unc.edu>
Message-ID: <42D559A5.9030401@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 13 Jul 2005 19:12:53 +0100</span><br />
</address>

Natasha Smith wrote:
<br />

<em class="quotelev1">>1.	leave the current organization (with some inevitable tweaking to
</em><br />
<em class="quotelev1">>bring it up to the conformance with P5). As you know, there are currently
</em><br />
<em class="quotelev1">>11 sections in the chapter, which is a lot, but not too overwhelming. Plus
</em><br />
<em class="quotelev1">>sections have a really good prose that would be too bad to loose. 
</em><br />
<em class="quotelev1">>2.	organize all the elements by model classes 
</em><br />
<em class="quotelev1">>3.	provide an alphabetical list of all elements (I would like to have
</em><br />
<em class="quotelev1">>it as an option, but not as the only one, but in addition to the #1 or #2)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
#3 can be provided automatically, so there is not much point
<br />
rearranging CO to suit.
<br />

#2 would depend a lot on a really succesful class reworking. and anyway,
<br />
it seems arsy-versy. the chapter should divide up the elements into
<br />
interesting groups ("linking", "naming", whatever), and the class system
<br />
should assist people to follow it.
<br />

personally, I'd cut this chapter down to the inline elements, move "lists"
<br />
to the next chapter, and find a new home for verse and drama.
<br />

6.10 "reference systems" seems somehow out of place too, can that walk
<br />
to chapter 14?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Jul 13 2005 - 14:12:58 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Wed Jul 13 14:27:23 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 13 Jul 2005 14:27:23 -0400
Subject: [tei-council] where is the HOWTO?
Message-ID: <17109.23819.667392.573084@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, 13 Jul 2005 14:27:23 -0400</span><br />
</address>

"Welcome back, Syd"
<br />
Thank you. Sorry for being out-of-touch. Due to a pretty poorly timed
<br />
and annoyingly long (6 hrs) power outage in my home town, and a few
<br />
other circumstances, I basically haven't read e-mail since Monday. So
<br />
if this has been dealt with or answered already, my apologies. Also,
<br />
I see that there are several postings to this list since then, which
<br />
I will be trying to get to over the next few days.
<br />

James -- where is the canonical version of your "HOWTO Build P5" (aka
<br />
"CVS ReadMe") document? There is a copy at ../Council/tcw06.xml, but
<br />

a) I have a vague recollection that you or Lou moved it elsewhere,
<br />
   too?
<br />

b) When I load that file, Cocoon has transformed it from what I
<br />
   believe is supposed to be TEI P5 into plain text (wrapped in
<br />
   <html></html>), rather than lovely styled HTML. I suspect this
<br />
   means there is an error in the encoding, at least as far as
<br />
   Sebastian's stylesheet is concerned. The only error I notice at
<br />
   first glance is an id= that should be an xml:id=, but I don't
<br />
   think that would break the stylesheet.
<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 Jul 13 2005 - 14:27:27 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jul 13 14:32:01 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 13 Jul 2005 19:32:01 +0100
Subject: [tei-council] where is the HOWTO?
In-Reply-To: <17109.23819.667392.573084@emt.wwp.brown.edu>
Message-ID: <42D55E21.9010808@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 13 Jul 2005 19:32:01 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>b) When I load that file, Cocoon has transformed it from what I
</em><br />
<em class="quotelev1">>   believe is supposed to be TEI P5 into plain text (wrapped in
</em><br />
<em class="quotelev1">>   <html></html>), rather than lovely styled HTML. I suspect this
</em><br />
<em class="quotelev1">>   means there is an error in the encoding, at least as far as
</em><br />
<em class="quotelev1">>   Sebastian's stylesheet is concerned. The only error I notice at
</em><br />
<em class="quotelev1">>   first glance is an id= that should be an xml:id=, but I don't
</em><br />
<em class="quotelev1">>   think that would break the stylesheet.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
the Cocoon setup does TEI P4 only at present if it meets *.xml
<br />
(cf discussion on TEI-L).
<br />

I could easily have it do TEI P5 as well, but only if someone
<br />
specifies a naming scheme for files.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Jul 13 2005 - 14:32:20 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Wed Jul 13 15:00:44 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 13 Jul 2005 20:00:44 +0100 (BST)
Subject: [tei-council] where is the HOWTO?
In-Reply-To: <42D55E21.9010808@computing-services.oxford.ac.uk>
Message-ID: <20050713190044.DE7FF2DE04@webmail217.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, 13 Jul 2005 20:00:44 +0100 (BST)</span><br />
</address>
 ('binary' encoding is not supported, stored as-is)
Further to confuse matters I have now rediscovered a document Sebastian drafted
<br />
some time ago (in March I believe) which outlines the production line then in
<br />
force for maintaining P5. This document is now online at
<br />
http://www.tei-c.org/Drafts/edw91.xml 
<br />

It needs to be updated in light of the recent discussions about the release tree
<br />
for P5, but I thought it would be helpful to put its current state up somewhere
<br />
safer than my laptop.
<br />

This means we currently have three somewhat overlapping "how to" documents:
<br />

-- edw91 : how we currently build P5
<br />
-- tcw06 : details on the makefile (James#' doc)
<br />
-- edw88 : how the punter is expected to use P5
<br />

<p>The distinction between the last of these and the others is clear enough, but I
<br />
wonder whether it might not be simpler to roll the second into the first?
<br />

At present tcw06 is in P5 rather than P4 and therefore illegible on the web. As
<br />
I assume James is still revising it, I havent changed that, but it should be done!
<br />

Lou
<br />

<p>In message <42D55E21.9010808_at_computing-services.oxford.ac.uk> Sebastian Rahtz
<br />
<sebastian.rahtz_at_computing-services.oxford.ac.uk> writes:
<br />
<em class="quotelev1">> Syd Bauman wrote:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">> >b) When I load that file, Cocoon has transformed it from what I
</em><br />
<em class="quotelev2">> >   believe is supposed to be TEI P5 into plain text (wrapped in
</em><br />
<em class="quotelev2">> >   <html></html>), rather than lovely styled HTML. I suspect this
</em><br />
<em class="quotelev2">> >   means there is an error in the encoding, at least as far as
</em><br />
<em class="quotelev2">> >   Sebastian's stylesheet is concerned. The only error I notice at
</em><br />
<em class="quotelev2">> >   first glance is an id= that should be an xml:id=, but I don't
</em><br />
<em class="quotelev2">> >   think that would break the stylesheet.
</em><br />
<em class="quotelev2">> >  
</em><br />
<em class="quotelev2">> >
</em><br />
<em class="quotelev1">> the Cocoon setup does TEI P4 only at present if it meets *.xml
</em><br />
<em class="quotelev1">> (cf discussion on TEI-L).
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I could easily have it do TEI P5 as well, but only if someone
</em><br />
<em class="quotelev1">> specifies a naming scheme for files.
</em><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 />
<em class="quotelev1">> OSS Watch: JISC Open Source Advisory Service
</em><br />
<em class="quotelev1">> http://www.oss-watch.ac.uk
</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.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.village.Virginia.EDU
<br />
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
<br />
<span id="received"><dfn>Received on</dfn> Wed Jul 13 2005 - 15:00:48 EDT</span>
</div>

From james.cummings at computing-services.oxford.ac.uk  Wed Jul 13 16:16:10 2005
From: james.cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 13 Jul 2005 21:16:10 +0100 (BST)
Subject: [tei-council] where is the HOWTO?
In-Reply-To: <20050713190044.DE7FF2DE04@webmail217.herald.ox.ac.uk>
Message-ID: <20050713201610.75CF62DE04@webmail217.herald.ox.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, 13 Jul 2005 21:16:10 +0100 (BST)</span><br />
</address>
 ('binary' encoding is not supported, stored as-is)
<em class="quotelev1">> At present tcw06 is in P5 rather than P4 and therefore illegible on the web. As
</em><br />
<em class="quotelev1">> I assume James is still revising it, I havent changed that, but it should be done!
</em><br />
<em class="quotelev1">> 
</em><br />

Sorry for the delay, still away at a conference.  The copy on the web is only missing some notes about the other modules, their makefiles, etc.  Partly I was waiting because of a thought that Sebastian might have been about to change the  makefiles slightly.  Starting on the 25th when I'm back at work I had planned to rewrite it to have a a <div> similar to the existing one for each CVS module.  This could then be used to generate a readme for each one, or be linked to from the tei.sf.net CVS page or somesuch.  At the same time I'll downgrade it to P4.   Unless this no longer sounds like a useful document, or you want me to change it into something else.
<br />

Ave atque vale,
<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> Wed Jul 13 2005 - 16:16:22 EDT</span>
</div>

From james.cummings at computing-services.oxford.ac.uk  Wed Jul 13 16:16:40 2005
From: james.cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 13 Jul 2005 21:16:40 +0100 (BST)
Subject: [tei-council] where is the HOWTO?
In-Reply-To: <[tei-council] where is the HOWTO?>
Message-ID: <20050713201640.E889E2DE04@webmail217.herald.ox.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, 13 Jul 2005 21:16:40 +0100 (BST)</span><br />
</address>
 ('binary' encoding is not supported, stored as-is)
<em class="quotelev1">> At present tcw06 is in P5 rather than P4 and therefore illegible on the web. As
</em><br />
<em class="quotelev1">> I assume James is still revising it, I havent changed that, but it should be done!
</em><br />
<em class="quotelev1">> 
</em><br />

Sorry for the delay, still away at a conference.  The copy on the web is only missing some notes about the other modules, their makefiles, etc.  Partly I was waiting because of a thought that Sebastian might have been about to change the  makefiles slightly.  Starting on the 25th when I'm back at work I had planned to rewrite it to have a a <div> similar to the existing one for each CVS module.  This could then be used to generate a readme for each one, or be linked to from the tei.sf.net CVS page or somesuch.  At the same time I'll downgrade it to P4.   Unless this no longer sounds like a useful document, or you want me to change it into something else.
<br />

Ave atque vale,
<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> Wed Jul 13 2005 - 16:16:52 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jul 13 18:49:14 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 14 Jul 2005 07:49:14 +0900
Subject: [tei-council] Ne release of P5
Message-ID: <ygfeka2coet.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 14 Jul 2005 07:49:14 +0900</span><br />
</address>

Council members,
<br />

Over at the TEI-L, Sebastian posted the announcement for the new
<br />
development release of P5.  All looked very nice, except one line,
<br />
which caught my eye --
<br />

* new <biblItem> element added
<br />

Sebastian, if you look at the minutes from the Paris meeting, you will
<br />
see that there is no agreement to add (or now, keep) biblItem.  In
<br />
fact, we were supposed to debate how the other bibl s can do what
<br />
some people think biblItem is needed for, rather than go with
<br />
biblItem. Syd is doing some work do evaluate this, but was not ready
<br />
last Friday, thus it got postponed.  
<br />

It looks therefore like a PR desaster to me at the moment. We should
<br />
post announcements like the current one first to the council list for
<br />
review and then go public with them, I think.
<br />

The other question is what to do now?  I would propose to post an
<br />
additional note that explains that biblItem has been added, but not
<br />
been approved, so it might go away anytime.  We might then take the
<br />
opportunity to solicit opinions about it as well.
<br />

What do the other council members think?
<br />

All the best,
<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> Wed Jul 13 2005 - 18:49:19 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Wed Jul 13 19:49:46 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 14 Jul 2005 00:49:46 +0100
Subject: [tei-council] Ne release of P5
In-Reply-To: <ygfeka2coet.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <42D5A89A.2000204@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, 14 Jul 2005 00:49:46 +0100</span><br />
</address>

Actually, the note Sebastian posted was written (and signed) by me, so 
<br />
it isn't really fair to blame him for its content.
<br />

I took the view that, since we do have a new element biblItem in this 
<br />
release, it is as well admit to its existence. I don't see that it's a 
<br />
PR disaster -- it's the truth of the current situation that we have some 
<br />
unsatisfactory work which needs further examination -- quite a lot of it 
<br />
in fact, not just this element.
<br />

What harm will there be in later saying "biblItem" removed -- if that's 
<br />
what we decide to do?
<br />

I dont think there's any need to call attention to the fragility of this 
<br />
particular element (I'm sure there are plenty of others equally fragile) 
<br />
but would be curious to know if other council members feel we should do so.
<br />

Lou
<br />

Christian Wittern wrote:
<br />

<em class="quotelev1">>Council members,
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Over at the TEI-L, Sebastian posted the announcement for the new
</em><br />
<em class="quotelev1">>development release of P5.  All looked very nice, except one line,
</em><br />
<em class="quotelev1">>which caught my eye --
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>* new <biblItem> element added
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Sebastian, if you look at the minutes from the Paris meeting, you will
</em><br />
<em class="quotelev1">>see that there is no agreement to add (or now, keep) biblItem.  In
</em><br />
<em class="quotelev1">>fact, we were supposed to debate how the other bibl s can do what
</em><br />
<em class="quotelev1">>some people think biblItem is needed for, rather than go with
</em><br />
<em class="quotelev1">>biblItem. Syd is doing some work do evaluate this, but was not ready
</em><br />
<em class="quotelev1">>last Friday, thus it got postponed.  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>It looks therefore like a PR desaster to me at the moment. We should
</em><br />
<em class="quotelev1">>post announcements like the current one first to the council list for
</em><br />
<em class="quotelev1">>review and then go public with them, I think.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>The other question is what to do now?  I would propose to post an
</em><br />
<em class="quotelev1">>additional note that explains that biblItem has been added, but not
</em><br />
<em class="quotelev1">>been approved, so it might go away anytime.  We might then take the
</em><br />
<em class="quotelev1">>opportunity to solicit opinions about it as well.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>What do the other council members think?
</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="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> Wed Jul 13 2005 - 19:50:30 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jul 13 21:48:28 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 14 Jul 2005 10:48:28 +0900
Subject: [tei-council] Ne release of P5
In-Reply-To: <42D5A89A.2000204@computing-services.oxford.ac.uk>
Message-ID: <ygf8y0acg43.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 14 Jul 2005 10:48:28 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Actually, the note Sebastian posted was written (and signed) by me, so
</em><br />
<em class="quotelev1">> it isn't really fair to blame him for its content.
</em><br />

Sorry, that escaped me. However, I am not blaming him or you, I see
<br />
this as one step towards a better procedure to handle this.
<br />

<em class="quotelev1">> I took the view that, since we do have a new element biblItem in this
</em><br />
<em class="quotelev1">> release, it is as well admit to its existence. I don't see that it's a
</em><br />
<em class="quotelev1">> PR disaster -- it's the truth of the current situation that we have
</em><br />
<em class="quotelev1">> some unsatisfactory work which needs further examination -- quite a
</em><br />
<em class="quotelev1">> lot of it in fact, not just this element.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> What harm will there be in later saying "biblItem" removed -- if
</em><br />
<em class="quotelev1">> that's what we decide to do?
</em><br />

Although P5 is clearly marked as in development, I do think that once
<br />
we said publicly "we added <blurb>" the impression the public will get
<br />
is that we made a decision and plan to go with that.
<br />

Having it sitting in the CVS source without further comment, pending a
<br />
decision is something rather different.  biblItem is a special case in
<br />
that, as I was told by you, it entered life in P5 as a replacement to
<br />
biblStruct, which was a mistake, which caused quite some grief for a
<br />
while.  Thinking of it more clearly in Paris, we decided that we
<br />
probably do not want biblItem, and rather tweak the other three bibl*
<br />
elements.  Given this situation, I think explicitly announcing it as
<br />
"newly added" does give a wrong impression. 
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I dont think there's any need to call attention to the fragility of
</em><br />
<em class="quotelev1">> this particular element (I'm sure there are plenty of others equally
</em><br />
<em class="quotelev1">> fragile) but would be curious to know if other council members feel we
</em><br />
<em class="quotelev1">> should do so.
</em><br />

There are others, I agree, but the situation with these others is
<br />
different from biblItem.
<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> Wed Jul 13 2005 - 21:48:42 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Thu Jul 14 04:01:47 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Thu, 14 Jul 2005 09:01:47 +0100
Subject: [tei-council] Ne release of P5
In-Reply-To: <ygfeka2coet.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <42D61BEB.7000803@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 14 Jul 2005 09:01:47 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>It looks therefore like a PR desaster to me at the moment. We should
</em><br />
<em class="quotelev1">>post announcements like the current one first to the council list for
</em><br />
<em class="quotelev1">>review and then go public with them, I think.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
agreed, it would probably have been sensible to review the
<br />
release note.
<br />

<em class="quotelev1">>The other question is what to do now?  I would propose to post an
</em><br />
<em class="quotelev1">>additional note that explains that biblItem has been added, but not
</em><br />
<em class="quotelev1">>been approved, so it might go away anytime. 
</em><br />
<em class="quotelev1">>
</em><br />

I agree with Lou that it would be counter-productive
<br />
to draw attention to this one element.
<br />

When we put out an announcement saying "the set of elements and
<br />
attributes is now frozen for 1 year", thats the time to really be sure
<br />

<p>sebastian
<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 Jul 14 2005 - 04:04:48 EDT</span>
</div>

From pwillett at umich.edu  Thu Jul 14 09:09:02 2005
From: pwillett at umich.edu (Perry Willett)
Date: Thu, 14 Jul 2005 09:09:02 -0400
Subject: [tei-council] Ne release of P5
In-Reply-To: <ygfeka2coet.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <002401c58875$3799e1b0$922bd38d@CLUBSODA>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Perry Willett <pwillett_at_umich.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 14 Jul 2005 09:09:02 -0400</span><br />
</address>

I think "PR disaster" is a little strong. We should try not to make
<br />
premature announcements, but if we say in the future, "after further
<br />
research, we decided to drop <biblItem> and recommend x instead," I don't
<br />
think people will rise up and call for our heads on a stick. 
<br />

Perry
<br />

<p>-----Original Message-----
<br />
From: tei-council-bounces_at_lists.<!--nospam-->village.Virginia.EDU
<br />
[mailto:tei-council-bounces_at_lists.<!--nospam-->village.Virginia.EDU] On Behalf Of
<br />
Christian Wittern
<br />
Sent: Wednesday, July 13, 2005 6:49 PM
<br />
To: tei-council_at_lists.<!--nospam-->village.Virginia.EDU
<br />
Subject: [tei-council] Ne release of P5
<br />

<p>Council members,
<br />

Over at the TEI-L, Sebastian posted the announcement for the new
<br />
development release of P5.  All looked very nice, except one line,
<br />
which caught my eye --
<br />

* new <biblItem> element added
<br />

Sebastian, if you look at the minutes from the Paris meeting, you will
<br />
see that there is no agreement to add (or now, keep) biblItem.  In
<br />
fact, we were supposed to debate how the other bibl s can do what
<br />
some people think biblItem is needed for, rather than go with
<br />
biblItem. Syd is doing some work do evaluate this, but was not ready
<br />
last Friday, thus it got postponed.  
<br />

It looks therefore like a PR desaster to me at the moment. We should
<br />
post announcements like the current one first to the council list for
<br />
review and then go public with them, I think.
<br />

The other question is what to do now?  I would propose to post an
<br />
additional note that explains that biblItem has been added, but not
<br />
been approved, so it might go away anytime.  We might then take the
<br />
opportunity to solicit opinions about it as well.
<br />

What do the other council members think?
<br />

All the best,
<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
_______________________________________________
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 Jul 14 2005 - 09:09:09 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Thu Jul 14 16:32:55 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 14 Jul 2005 16:32:55 -0400
Subject: [tei-council] meeting technologies
In-Reply-To: <D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>
Message-ID: <17110.52215.774095.934130@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, 14 Jul 2005 16:32:55 -0400</span><br />
</address>

SR> Do you all find the telephony a plausible method of
<br />
SR> communication? Would you be interested in an alternate trial of
<br />
SR> IM?
<br />

I would be happy to try telephony. I would be very happy to have some
<br />
sort of IM system available to us during the conference call, so that
<br />
we can type examples and exact syntax at each other. But I don't
<br />
think I like the idea of IM replacing the call, for a variety of
<br />
reasons, not the least of which is that I have severe bilateral
<br />
wrist tendonitis.
<br />

<p>SR> Another more radical alternative would be video conferencing. How
<br />
SR> many of you would be willing to risk that?
<br />

Not really interested, at least not yet. It doesn't seem like the
<br />
advantages of seeing your smiling face outweigh the pain-in-the-neck
<br />
factor here.
<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 Jul 14 2005 - 16:33:00 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Thu Jul 14 16:52:33 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 14 Jul 2005 16:52:33 -0400
Subject: Fwd: [tei-council] regularizing names
In-Reply-To: <32F6167B-5D2E-42C3-98D4-C9312EEA3668@indiana.edu>
Message-ID: <17110.53393.545709.398079@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, 14 Jul 2005 16:52:33 -0400</span><br />
</address>

JW> And perhaps the guidelines should also discuss the option of
<br />
JW> pointing to an external file dedicated to name regularizations.
<br />
JW> For instance, if my project consists of hundreds of commentaries
<br />
JW> on Romantic poetry, I don't need to repeat <regName
<br />
JW> authority="LCNAF" id="byron" >Byron, George Gordon Byron,
<br />
JW> Baron</regName> in every document. Rather, I could do something
<br />
JW> like this: "...the dastardly and poisonous malignity of <persName
<br />
JW> reg="myRegNames.xml#byron">Byron's</persName> most foul and
<br />
JW> treacherous libel...," pointing to a master myRegNames.xml file.
<br />

One teeny additional point to consider, is that (as currently
<br />
concieved) this would require changing the datatype of reg= from
<br />
tei.data.code (points internally) to tei.data.key (points anywhere).
<br />

Which may mean we should reconsider whether or not reg= should be
<br />
tei.data.code.
<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 Jul 14 2005 - 16:52:38 EDT</span>
</div>

From Julia_Flanders at Brown.edu  Thu Jul 14 17:38:15 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 14 Jul 2005 17:38:15 -0400
Subject: [tei-council] regularizing names
In-Reply-To: <42D2DA35.8040007@computing-services.oxford.ac.uk>
Message-ID: <a062007cdbefc841864df@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 14 Jul 2005 17:38:15 -0400</span><br />
</address>

Perry and I did discuss the possibility of providing regularization 
<br />
of the individual name components; I append our example below.
<br />

Your point about the name linking to a PERSON rather than to a NAME 
<br />
is an interesting problem. The intention of the examples we gave, and 
<br />
their underlying spirit, is that the <regName> element documents a 
<br />
name, not a person; it may point onward to a person (i.e. a name 
<br />
authority record about a person), but it needn't. However, I can see 
<br />
that that pointing inflects the semantics of the <regName> element: 
<br />
it can't simply regularize once it points to an authority record.
<br />

I guess the question is whether this is a practical problem. In the 
<br />
P4 universe, people often use reg= with an implicit semantics of key= 
<br />
(in the sense that a given regularization really does refer to a 
<br />
person, and may even be used explicitly that way) in cases where they 
<br />
have only unique name-person mappings. We regard this as showing want 
<br />
of judgment (because they might in future come across another John 
<br />
Smith) but not as a tagging error, as long as the value of reg= is 
<br />
something like "Smith, John" rather than "jsm0111". In the system 
<br />
we're discussing now, is there a disadvantage to using the same 
<br />
element for both functions? that is, if you want to regularize the 
<br />
name, you can do so; if you want to link to information about a 
<br />
person, you can do so. Is it ever unclear which is happening?
<br />

If you had a document in which there were many different people named 
<br />
John Smith, all spelled and abbreviated in wacky ways, all the 
<br />
references might legitimately point to a single <regName> element 
<br />
that regularized them all simply as names. If you wanted to use 
<br />
<regName> to link these to persons, you would need instead multiple 
<br />
<regName> elements with links to person data. Or you could just use 
<br />
key= if you didn't want to regularize the names at all.
<br />

But I may not be taking sufficient account of the advantages of 
<br />
knowing which is meant, programmatically, without having to draw 
<br />
inferences based on what kind of information is present.
<br />

Here's the example we had come up with for encoding/regularizing name parts:
<br />

<regName xml:id="rn17">Clinton, William J.</regName>
<br />
<regName xml:id="rn18">
<br />
        <regName xml:id="rn18.1">Jones</regName>,
<br />
        <regName xml:id="rn18.2">Herbert</regName>
<br />
        <regName xml:id="rn18.3">Fizzlebaum</regName></regName>
<br />
<!-- above <regName> elements may be somewhere in <teiHeader> or <hyperDiv>,
<br />
            and may be part of a new prosopographic element -->
<br />
<!-- ... -->
<br />
<name reg="#rn17">Bill Clinton</name>
<br />
<persName reg="#rn18"><foreName reg="#rn18.1">Herb</foreName> 
<br />
<foreName reg="#rn18.3">F.</foreName> <foreName 
<br />
reg="#rn18.3">"Fizzy"</foreName> <surname 
<br />
reg="#rn18.1">Jones</surname></persName>
<br />

Julia
<br />

At 9:44 PM +0100 7/11/05, Lou Burnard wrote:
<br />
<em class="quotelev1">>The main problem I have with this is that all the examples cited 
</em><br />
<em class="quotelev1">>seem to be about linking the name to a PERSON not to a NAME, in 
</em><br />
<em class="quotelev1">>which case the existing key attribute would surely be more 
</em><br />
<em class="quotelev1">>appropriate? (That's not to say that having a <regName> child within 
</em><br />
<em class="quotelev1">><person> wouldn't be a good idea). But the only use for having both 
</em><br />
<em class="quotelev1">>a reg attribute and a key attribute on a name ought to be for one to 
</em><br />
<em class="quotelev1">>regularize the name, and the other to regularize the thing-named. In 
</em><br />
<em class="quotelev1">>which case, we have to be able to support the reg attribute on 
</em><br />
<em class="quotelev1">>components of names, e.g.
</em><br />
<em class="quotelev1">><name key="JF">
</em><br />
<em class="quotelev1">><forename reg="JULIA">Juley</forename>
</em><br />
<em class="quotelev1">><surname reg="FLANDERS">Flanderes</surname>
</em><br />
<em class="quotelev1">></name>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">><person ident="JF">
</em><br />
<em class="quotelev1">><regName>
</em><br />
<em class="quotelev1">><forename ident="JULIA">Julia</forename>
</em><br />
<em class="quotelev1">><surname ident="FLANDERS">Flanders</surname>
</em><br />
<em class="quotelev1">></regName>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">></person>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>[I've used co-labelling here rather than ID/IDREF but the same 
</em><br />
<em class="quotelev1">>principle applies]
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>in haste
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Lou
</em><br />
<em class="quotelev1">>Julia Flanders wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>  Here's what Perry and I have come up with concerning the 
</em><br />
<em class="quotelev2">>>regularization of names.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  We propose, tentatively, that in P5 we handle the regularization 
</em><br />
<em class="quotelev2">>>of names as follows:
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  Name elements (<name> and the other "primary" name elements 
</em><br />
<em class="quotelev2">>>including <persName>, <placeName>, <orgName>, <geogName>) may carry 
</em><br />
<em class="quotelev2">>>a reg= attribute, which points to a <regName> element which 
</em><br />
<em class="quotelev2">>>contains information on regularization. This element might live in 
</em><br />
<em class="quotelev2">>>the TEI header or in some other convenient place. The datatype for 
</em><br />
<em class="quotelev2">>>reg= would be tei.data.code. The element name (<regName> as against 
</em><br />
<em class="quotelev2">>><reg>) is chosen to help distinguish the function of this 
</em><br />
<em class="quotelev2">>>regularization structure from other kinds of regularization in the 
</em><br />
<em class="quotelev2">>>document.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  The nested naming elements such as <foreName>, <surname>, 
</em><br />
<em class="quotelev2">>>etc.--i.e. those which cannot occur on their own but must be nested 
</em><br />
<em class="quotelev2">>>inside a primary naming element--would not carry the reg= attribute 
</em><br />
<em class="quotelev2">>>and cannot be regularized independently. We considered a mechanism 
</em><br />
<em class="quotelev2">>>for doing this and if any Council members think it would be a good 
</em><br />
<em class="quotelev2">>>idea we can add this bit.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  The <regName> element may either contain a regularized version of 
</em><br />
<em class="quotelev2">>>the name as its content, or it may carry a pointer to an external 
</em><br />
<em class="quotelev2">>>resource (either locally maintained or an authority file external 
</em><br />
<em class="quotelev2">>>to the project, such as Library of Congress Name Authority files). 
</em><br />
<em class="quotelev2">>>It could also do both, and we don't see a need to police this 
</em><br />
<em class="quotelev2">>>choice (e.g. by making these options exclusive).
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  The <regName> element would carry three attributes:
</em><br />
<em class="quotelev2">>>  --authority= indicates what authority, if any, is being used as 
</em><br />
<em class="quotelev2">>>the source of the regularization, with values such as "NACO", other 
</em><br />
<em class="quotelev2">>>possibilities
</em><br />
<em class="quotelev2">>>  --url= (or target=) points to an external resource
</em><br />
<em class="quotelev2">>>  --xml:id= allows the element to be pointed to from the naming 
</em><br />
<em class="quotelev2">>>element in the text.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  Example:
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  <regName authority="NACO" xml:id="rn17">Clinton, William J.</regName>
</em><br />
<em class="quotelev2">>>  <regName authority="NACO" xml:id="rn18">Aldrin, Edwin Eugene, Jr.</regName>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>  <name reg="#rn17">Bill Clinton</name>
</em><br />
<em class="quotelev2">>>  <persName reg="#rn18">Buzz Aldrin</persName>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  We are still concerned about how this use of reg= and <regName> 
</em><br />
<em class="quotelev2">>>will fit in with other forms of regularization (e.g. spelling). 
</em><br />
<em class="quotelev2">>>However, since all other uses of reg= will probably now be 
</em><br />
<em class="quotelev2">>>addressed as child elements, the possibility of confusion is 
</em><br />
<em class="quotelev2">>>diminished.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  Comments welcome--
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  Julia
</em><br />
<em class="quotelev2">>>  _______________________________________________
</em><br />
<em class="quotelev2">>>  tei-council mailing list
</em><br />
<em class="quotelev2">>>  tei-council_at_lists.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="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 Jul 14 2005 - 17:38:23 EDT</span>
</div>

From sschreib at umd.edu  Thu Jul 14 18:32:02 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Thu, 14 Jul 2005 18:32:02 -0400
Subject: [tei-council] meeting technologies
In-Reply-To: <17110.52215.774095.934130@emt.wwp.brown.edu>
Message-ID: <42D6E7E2.2060101@umd.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Susan Schreibman <sschreib_at_umd.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 14 Jul 2005 18:32:02 -0400</span><br />
</address>

We switched to IM meetings for teiPublisher because the phone calls were 
<br />
too expensive for some of the team. They were far less satisfactory than 
<br />
telephone calls, and writing up minutes took forever as one had to wade 
<br />
through the entire chat session.
<br />

usan
<br />

<p>Syd Bauman wrote:
<br />

<em class="quotelev1">>SR> Do you all find the telephony a plausible method of
</em><br />
<em class="quotelev1">>SR> communication? Would you be interested in an alternate trial of
</em><br />
<em class="quotelev1">>SR> IM?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I would be happy to try telephony. I would be very happy to have some
</em><br />
<em class="quotelev1">>sort of IM system available to us during the conference call, so that
</em><br />
<em class="quotelev1">>we can type examples and exact syntax at each other. But I don't
</em><br />
<em class="quotelev1">>think I like the idea of IM replacing the call, for a variety of
</em><br />
<em class="quotelev1">>reasons, not the least of which is that I have severe bilateral
</em><br />
<em class="quotelev1">>wrist tendonitis.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>SR> Another more radical alternative would be video conferencing. How
</em><br />
<em class="quotelev1">>SR> many of you would be willing to risk that?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Not really interested, at least not yet. It doesn't seem like the
</em><br />
<em class="quotelev1">>advantages of seeing your smiling face outweigh the pain-in-the-neck
</em><br />
<em class="quotelev1">>factor here.
</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.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 />

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742
Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib_at_umd.<!--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> Thu Jul 14 2005 - 18:32:05 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Thu Jul 14 19:08:48 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 15 Jul 2005 00:08:48 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <42D6E7E2.2060101@umd.edu>
Message-ID: <42D6F080.6050603@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 15 Jul 2005 00:08:48 +0100</span><br />
</address>

Susan Schreibman wrote:
<br />

<em class="quotelev1">> We switched to IM meetings for teiPublisher because the phone calls
</em><br />
<em class="quotelev1">> were too expensive for some of the team. They were far less
</em><br />
<em class="quotelev1">> satisfactory than telephone calls, and writing up minutes took forever
</em><br />
<em class="quotelev1">> as one had to wade through the entire chat session.
</em><br />
<em class="quotelev1">>
</em><br />
so have you switched back to phone?
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Thu Jul 14 2005 - 19:09:04 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Thu Jul 14 19:10:11 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 15 Jul 2005 00:10:11 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <17110.52215.774095.934130@emt.wwp.brown.edu>
Message-ID: <42D6F0D3.1020303@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 15 Jul 2005 00:10:11 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">> But I don't
</em><br />
<em class="quotelev1">>think I like the idea of IM replacing the call, for a variety of
</em><br />
<em class="quotelev1">>reasons, not the least of which is that I have severe bilateral
</em><br />
<em class="quotelev1">>wrist tendonitis.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
thats a fair point; i suppose we need a hybrid system; Skype
<br />
would do the job, probably.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>SR> Another more radical alternative would be video conferencing. How
</em><br />
<em class="quotelev1">>SR> many of you would be willing to risk that?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Not really interested, at least not yet. It doesn't seem like the
</em><br />
<em class="quotelev1">>advantages of seeing your smiling face outweigh the pain-in-the-neck
</em><br />
<em class="quotelev1">>factor here.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
why is it a pain?
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Thu Jul 14 2005 - 19:10:30 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Jul 14 20:45:03 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 15 Jul 2005 09:45:03 +0900
Subject: [tei-council] meeting technologies
In-Reply-To: <42D6F0D3.1020303@computing-services.oxford.ac.uk>
Message-ID: <ygfhdewx5gw.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 15 Jul 2005 09:45:03 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Syd Bauman wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> But I don't
</em><br />
<em class="quotelev2">>>think I like the idea of IM replacing the call, for a variety of
</em><br />
<em class="quotelev2">>>reasons, not the least of which is that I have severe bilateral
</em><br />
<em class="quotelev2">>>wrist tendonitis.
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> thats a fair point; i suppose we need a hybrid system; Skype
</em><br />
<em class="quotelev1">> would do the job, probably.
</em><br />

Do you mean for IM? Their phone conferences allow only 4
<br />
participants.  For IM, there surely are other (non-proprietory?)
<br />
options?
<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 Jul 14 2005 - 20:45:20 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Jul 14 20:48:01 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 15 Jul 2005 09:48:01 +0900
Subject: [tei-council] meeting technologies
In-Reply-To: <42D6E7E2.2060101@umd.edu>
Message-ID: <ygfd5pkx5by.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 15 Jul 2005 09:48:01 +0900</span><br />
</address>

Susan Schreibman <sschreib_at_umd.<!--nospam-->edu> writes:
<br />

<em class="quotelev1">> We switched to IM meetings for teiPublisher because the phone calls
</em><br />
<em class="quotelev1">> were too expensive for some of the team. They were far less
</em><br />
<em class="quotelev1">> satisfactory than telephone calls, and writing up minutes took forever
</em><br />
<em class="quotelev1">> as one had to wade through the entire chat session.
</em><br />

Thank you, that is the kind of information I thought we could come up
<br />
with by testing it in a small group. 
<br />

So the one proposal left at the moment would be to use IM in addition
<br />
to our conference calls courtesy of Indiana University?
<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 Jul 14 2005 - 20:48:07 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Jul 14 20:53:35 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 15 Jul 2005 09:53:35 +0900
Subject: [tei-council] regularizing names
In-Reply-To: <a062007cdbefc841864df@[128.148.157.102]>
Message-ID: <ygf8y08x52o.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 15 Jul 2005 09:53:35 +0900</span><br />
</address>

Julia Flanders <Julia_Flanders_at_Brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev1">> If you had a document in which there were many different people named
</em><br />
<em class="quotelev1">> John Smith, all spelled and abbreviated in wacky ways, all the
</em><br />
<em class="quotelev1">> references might legitimately point to a single <regName> element that
</em><br />
<em class="quotelev1">> regularized them all simply as names. If you wanted to use <regName>
</em><br />
<em class="quotelev1">> to link these to persons, you would need instead multiple <regName>
</em><br />
<em class="quotelev1">> elements with links to person data. Or you could just use key= if you
</em><br />
<em class="quotelev1">> didn't want to regularize the names at all.
</em><br />

But in this case, there is no real need to link from regName to the
<br />
record, you could use key= on name to do that and still get away with
<br />
just one regName element in your header.  So maybe the idea of linking
<br />
from the regName to the authority file is not really what you want,
<br />
after all? 
<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 Jul 14 2005 - 20:53:41 EDT</span>
</div>

From sschreib at umd.edu  Fri Jul 15 05:22:29 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Fri, 15 Jul 2005 05:22:29 -0400
Subject: [tei-council] meeting technologies
In-Reply-To: <42D6F080.6050603@computing-services.oxford.ac.uk>
Message-ID: <42D78055.7000403@umd.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Susan Schreibman <sschreib_at_umd.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 15 Jul 2005 05:22:29 -0400</span><br />
</address>

no -- we continued with IM, but we are now looking for grant funding, 
<br />
and one of the line items will be conference calls
<br />

<br />

Sebastian Rahtz wrote:
<br />

<em class="quotelev1">>Susan Schreibman wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>We switched to IM meetings for teiPublisher because the phone calls
</em><br />
<em class="quotelev2">>>were too expensive for some of the team. They were far less
</em><br />
<em class="quotelev2">>>satisfactory than telephone calls, and writing up minutes took forever
</em><br />
<em class="quotelev2">>>as one had to wade through the entire chat session.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>so have you switched back to phone?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742
Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib_at_umd.<!--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 Jul 15 2005 - 05:22:40 EDT</span>
</div>

From sschreib at umd.edu  Fri Jul 15 05:32:06 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Fri, 15 Jul 2005 05:32:06 -0400
Subject: [tei-council] meeting technologies
In-Reply-To: <ygfd5pkx5by.fsf@chwpb.local>
Message-ID: <42D78296.5030904@umd.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Susan Schreibman <sschreib_at_umd.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 15 Jul 2005 05:32:06 -0400</span><br />
</address>

On the other hand, it is very expensive for people phoning from outside 
<br />
the US for an hour and a half -- that seems to be the real problem. The 
<br />
people from Oxford can conference call each other in and then just have 
<br />
one international line to the US, which really does save quite a bit.
<br />

I'm wondering if there is any way left to reduce the costs somehow to 
<br />
others phoning from abroad.
<br />

usan
<br />

<p>Christian Wittern wrote:
<br />

<em class="quotelev1">>Susan Schreibman <sschreib_at_umd.edu> writes:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>We switched to IM meetings for teiPublisher because the phone calls
</em><br />
<em class="quotelev2">>>were too expensive for some of the team. They were far less
</em><br />
<em class="quotelev2">>>satisfactory than telephone calls, and writing up minutes took forever
</em><br />
<em class="quotelev2">>>as one had to wade through the entire chat session.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Thank you, that is the kind of information I thought we could come up
</em><br />
<em class="quotelev1">>with by testing it in a small group. 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>So the one proposal left at the moment would be to use IM in addition
</em><br />
<em class="quotelev1">>to our conference calls courtesy of Indiana University?
</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="quotelev1">>
</em><br />

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742
Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib_at_umd.<!--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 Jul 15 2005 - 05:32:15 EDT</span>
</div>

From Julia_Flanders at Brown.edu  Fri Jul 15 12:35:41 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Fri, 15 Jul 2005 12:35:41 -0400
Subject: [tei-council] meeting technologies
In-Reply-To: <42D78296.5030904@umd.edu>
Message-ID: <a062007d9befd95d28ce0@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 15 Jul 2005 12:35:41 -0400</span><br />
</address>

I also wonder whether we can quantify those costs more precisely, and 
<br />
perhaps subsidize them. Given the cost of things like TEI council 
<br />
meetings, adding a few hundred dollars for conference calls would not 
<br />
be an unreasonable or unmanageable expense, if that's what it 
<br />
amounted to. Can those who paid for the last conference call (or the 
<br />
one before that) take a look at the phone bill and report on the cost?
<br />

Julia
<br />

At 5:32 AM -0400 7/15/05, Susan Schreibman wrote:
<br />
<em class="quotelev1">>On the other hand, it is very expensive for people phoning from 
</em><br />
<em class="quotelev1">>outside the US for an hour and a half -- that seems to be the real 
</em><br />
<em class="quotelev1">>problem. The people from Oxford can conference call each other in 
</em><br />
<em class="quotelev1">>and then just have one international line to the US, which really 
</em><br />
<em class="quotelev1">>does save quite a bit.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I'm wondering if there is any way left to reduce the costs somehow 
</em><br />
<em class="quotelev1">>to others phoning from abroad.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>susan
</em><br />
_______________________________________________
<br />
tei-council mailing list
<br />
tei-council_at_lists.village.Virginia.EDU
<br />
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
<br />
<span id="received"><dfn>Received on</dfn> Fri Jul 15 2005 - 12:35:49 EDT</span>
</div>

From edward.vanhoutte at kantl.be  Fri Jul 15 18:48:56 2005
From: edward.vanhoutte at kantl.be (Edward Vanhoutte)
Date: Sat, 16 Jul 2005 00:48:56 +0200
Subject: [tei-council] meeting technologies
In-Reply-To: <42D78296.5030904@umd.edu>
Message-ID: <42D83D58.2010503@kantl.be>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Edward Vanhoutte <edward.vanhoutte_at_kantl.be>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 16 Jul 2005 00:48:56 +0200</span><br />
</address>

Conference calls usually cost me about 15-20 EUR which is not too bad.
<br />

Edward
<br />

Susan Schreibman wrote:
<br />

<em class="quotelev1">> On the other hand, it is very expensive for people phoning from 
</em><br />
<em class="quotelev1">> outside the US for an hour and a half -- that seems to be the real 
</em><br />
<em class="quotelev1">> problem. The people from Oxford can conference call each other in and 
</em><br />
<em class="quotelev1">> then just have one international line to the US, which really does 
</em><br />
<em class="quotelev1">> save quite a bit.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I'm wondering if there is any way left to reduce the costs somehow to 
</em><br />
<em class="quotelev1">> others phoning from abroad.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> susan
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Christian Wittern wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> Susan Schreibman <sschreib_at_umd.edu> writes:
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev3">>>> We switched to IM meetings for teiPublisher because the phone calls
</em><br />
<em class="quotelev3">>>> were too expensive for some of the team. They were far less
</em><br />
<em class="quotelev3">>>> satisfactory than telephone calls, and writing up minutes took forever
</em><br />
<em class="quotelev3">>>> as one had to wade through the entire chat session.
</em><br />
<em class="quotelev3">>>>   
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> Thank you, that is the kind of information I thought we could come up
</em><br />
<em class="quotelev2">>> with by testing it in a small group.
</em><br />
<em class="quotelev2">>> So the one proposal left at the moment would be to use IM in addition
</em><br />
<em class="quotelev2">>> to our conference calls courtesy of Indiana University?
</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="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />

-- 
================
Edward Vanhoutte
Researcher
University of Antwerp
Associate Editor, Literary and Linguistic Computing
University of Antwerp - CDE
Dept. of Literature
Universiteitsplein 1
b-2610 Wilrijk
Belgium
edward dot vanhoutte at kantl dot be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm
_______________________________________________
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 Jul 15 2005 - 18:50:14 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Jul 15 20:32:44 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 16 Jul 2005 09:32:44 +0900
Subject: [tei-council] meeting technologies
In-Reply-To: <42D83D58.2010503@kantl.be>
Message-ID: <ygfr7dzvbdf.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 16 Jul 2005 09:32:44 +0900</span><br />
</address>

Edward Vanhoutte <edward.vanhoutte_at_kantl.<!--nospam-->be> writes:
<br />

<em class="quotelev1">> Conference calls usually cost me about 15-20 EUR which is not too bad.
</em><br />

When we started doing calls, it was in the area of 5000 Yen (~65 US)
<br />
per call, but with the dropping telecom costs, I think I am down to about
<br />
the same amount as the one reported by Edward. Still, that would be
<br />
in the area of 300 EUR for all participants per call, with 6 calls per
<br />
year about 1800 EUR to put in the budget.  
<br />

It looks like to us the cost of calls is a minor factor, the technical
<br />
quality seems more important to me.  (I am working with Syd offlist
<br />
towards an improvement here, since apparently it has to do with
<br />
specific equipment).
<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> Fri Jul 15 2005 - 20:33:08 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 17 15:43:55 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 17 Jul 2005 20:43:55 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <ygfr7dzvbdf.fsf@chwpb.local>
Message-ID: <42DAB4FB.7070405@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 17 Jul 2005 20:43:55 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>It looks like to us the cost of calls is a minor factor, the technical
</em><br />
<em class="quotelev1">>quality seems more important to me.  
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
Indeed. As it stands, I find the Council calls a) very tiring,
<br />
and b) not very satisfying; and quite a lot of that is not
<br />
really being able to hear what people are saying. If
<br />
its possible to improve that, great.
<br />

But still worth experimenting with
<br />
having an IRC channel ready on the side.
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Jul 17 2005 - 15:44:30 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 17 16:30:32 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 17 Jul 2005 21:30:32 +0100
Subject: [tei-council] the release conundrum
Message-ID: <42DABFE8.2040009@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 17 Jul 2005 21:30:32 +0100</span><br />
</address>

I have tried to streamline our release offerings. We now have
<br />

 a) CVS
<br />
 b) a release which consists of:
<br />
      - debian and RPM packages
<br />
      - SF file releases
<br />
      - a duplicate of a Debian release on the TEI web site.
<br />
        the existing copies of P4 and P5 DTDs and Guidelines have now been
<br />
        removed, and the URLs are now silently redirected to the
<br />
"release" tree.
<br />
 c) packages for Knoppix and Windows Emacs (not in sync yet)
<br />
 d) distribution by oXygen
<br />

we are now at release 0.1.10.
<br />

My view of the process is as follows:
<br />

  1) the editors or their acolytes change CVS as they need to. it is not
<br />
guarenteed to "work" at any given time.
<br />
  2) when a consensus emerges that something interesting has happened,
<br />
or that 6 months has passed,
<br />
       the editors will instruct the release manager (currently me) to
<br />
prepare all the outputs in b) above
<br />
       and release them as close together as possible
<br />
 3) the Knoppix and Emacs releases are a project of TEI Oxford which
<br />
will follow a timetable of their own
<br />
 4) we will all do our best to assist the oXygen people stay in sycn and
<br />
be forewarned of important changes
<br />
 5) the editors do not need permission from the Council to make minimo
<br />
releases (ie 0.1.13), but
<br />
     the council will discuss making a minor release (0.2.0), and the
<br />
council and board will both
<br />
     discuss making a major release (1.0.0)
<br />

I would propose now that we plan to make the 0.2.0 release after the
<br />
class and attribute changes have been
<br />
implemented.
<br />

How does that sound?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Jul 17 2005 - 16:31:00 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 17 17:01:15 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 17 Jul 2005 22:01:15 +0100
Subject: [tei-council] manual for P5
Message-ID: <42DAC71B.6020707@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 17 Jul 2005 22:01:15 +0100</span><br />
</address>

The noisy Bruce D'Arcus complains to me that we don't have any
<br />
info on how to use P5 schemas. And he's right. We have edw88, ODD/Manual/
<br />
and James' HOWTO, all incomplete and unpublished.
<br />

Which hero will step up to the plate and volunteer the two man
<br />
days need to collate the 3 docs above and publish the result?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Jul 17 2005 - 17:01:44 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sun Jul 17 18:02:35 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 17 Jul 2005 23:02:35 +0100
Subject: [tei-council] the release conundrum
In-Reply-To: <42DABFE8.2040009@computing-services.oxford.ac.uk>
Message-ID: <42DAD57B.90304@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, 17 Jul 2005 23:02:35 +0100</span><br />
</address>

This is all fine by me, though just for the record I think I should 
<br />
point out that the editors are right out of acolytes.
<br />

L
<br />

Sebastian Rahtz wrote:
<br />

<em class="quotelev1">> I have tried to streamline our release offerings. We now have
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">>  a) CVS
</em><br />
<em class="quotelev1">>  b) a release which consists of:
</em><br />
<em class="quotelev1">>       - debian and RPM packages
</em><br />
<em class="quotelev1">>       - SF file releases
</em><br />
<em class="quotelev1">>       - a duplicate of a Debian release on the TEI web site.
</em><br />
<em class="quotelev1">>         the existing copies of P4 and P5 DTDs and Guidelines have now been
</em><br />
<em class="quotelev1">>         removed, and the URLs are now silently redirected to the
</em><br />
<em class="quotelev1">> "release" tree.
</em><br />
<em class="quotelev1">>  c) packages for Knoppix and Windows Emacs (not in sync yet)
</em><br />
<em class="quotelev1">>  d) distribution by oXygen
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> we are now at release 0.1.10.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> My view of the process is as follows:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">>   1) the editors or their acolytes change CVS as they need to. it is not
</em><br />
<em class="quotelev1">> guarenteed to "work" at any given time.
</em><br />
<em class="quotelev1">>   2) when a consensus emerges that something interesting has happened,
</em><br />
<em class="quotelev1">> or that 6 months has passed,
</em><br />
<em class="quotelev1">>        the editors will instruct the release manager (currently me) to
</em><br />
<em class="quotelev1">> prepare all the outputs in b) above
</em><br />
<em class="quotelev1">>        and release them as close together as possible
</em><br />
<em class="quotelev1">>  3) the Knoppix and Emacs releases are a project of TEI Oxford which
</em><br />
<em class="quotelev1">> will follow a timetable of their own
</em><br />
<em class="quotelev1">>  4) we will all do our best to assist the oXygen people stay in sycn and
</em><br />
<em class="quotelev1">> be forewarned of important changes
</em><br />
<em class="quotelev1">>  5) the editors do not need permission from the Council to make minimo
</em><br />
<em class="quotelev1">> releases (ie 0.1.13), but
</em><br />
<em class="quotelev1">>      the council will discuss making a minor release (0.2.0), and the
</em><br />
<em class="quotelev1">> council and board will both
</em><br />
<em class="quotelev1">>      discuss making a major release (1.0.0)
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I would propose now that we plan to make the 0.2.0 release after the
</em><br />
<em class="quotelev1">> class and attribute changes have been
</em><br />
<em class="quotelev1">> implemented.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> How does that sound?
</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> Sun Jul 17 2005 - 17:50:43 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 17 17:55:33 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 17 Jul 2005 22:55:33 +0100
Subject: [tei-council] the release conundrum
In-Reply-To: <42DAD57B.90304@computing-services.oxford.ac.uk>
Message-ID: <42DAD3D5.2090302@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 17 Jul 2005 22:55:33 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">> This is all fine by me, though just for the record I think I should
</em><br />
<em class="quotelev1">> point out that the editors are right out of acolytes.
</em><br />

I was referring to myself there.
<br />
   s/acolytes/hangers on/
<br />
or
<br />
   s/acolytes/loose cannons/
<br />
or
<br />
   s/acolytes/rottweilers/
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Jul 17 2005 - 17:56:03 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Jul 17 18:23:25 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 17 Jul 2005 18:23:25 -0400
Subject: [tei-council] the release conundrum
In-Reply-To: <42DAD3D5.2090302@computing-services.oxford.ac.uk>
Message-ID: <17114.55901.307615.819445@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, 17 Jul 2005 18:23:25 -0400</span><br />
</address>

Sebastian's view of the process (reproduced below) sounds good to me,
<br />
too. However, I think 6 months is an enormously long time to wait
<br />
between releases. I'm not suggesting we change the process to 3 or 4
<br />
months, but rather that if 6 months have gone by and nothing
<br />
"interesting" has happened, we need to re-examine either our system
<br />
for making things happen or our criteria for what is and isn't
<br />
"interesting". :-)  (Personally, I'm betting this won't be a problem
<br />
at all.)
<br />

I also think it is vitally important, Sebastian, that you write up
<br />
the procedure for making a release, so that someone else could be the
<br />
release manager without fuss.
<br />

<p>LB> This is all fine by me, though just for the record I think I
<br />
LB> should point out that the editors are right out of acolytes.
<br />

I agree with Lou, and furthermore my ads in the personals for
<br />
"acolyte wanted -- no pay, minimal reward" have gone unanswered for
<br />
weeks. On the other hand, we need to decide at some point who else,
<br />
if anyone, gets R/W access to the CVS tree. E.g., Laurent is working
<br />
on both the dictionary and the terminological databases chapter --
<br />
should he be doing this directly in CVS? David Durand is working on
<br />
the linking chapter -- should he?
<br />

---------
<br />
I have tried to streamline our release offerings. We now have
<br />
 a) CVS
<br />
 b) a release which consists of:
<br />
    - debian and RPM packages
<br />
    - SF file releases
<br />
    - a duplicate of a Debian release on the TEI web site. the
<br />
      existing copies of P4 and P5 DTDs and Guidelines have now been
<br />
      removed, and the URLs are now silently redirected to the
<br />
      "release" tree.
<br />
 c) packages for Knoppix and Windows Emacs (not in sync yet)
<br />
 d) distribution by oXygen
<br />

we are now at release 0.1.10.
<br />

My view of the process is as follows:
<br />

1) the editors or their acolytes change CVS as they need to. it is
<br />
   not guarenteed to "work" at any given time.
<br />

2) when a consensus emerges that something interesting has happened,
<br />
   or that 6 months has passed, the editors will instruct the release
<br />
   manager (currently me) to prepare all the outputs in b) above and
<br />
   release them as close together as possible
<br />

3) the Knoppix and Emacs releases are a project of TEI Oxford which
<br />
   will follow a timetable of their own
<br />

4) we will all do our best to assist the oXygen people stay in sycn
<br />
   and be forewarned of important changes
<br />

5) the editors do not need permission from the Council to make minimo
<br />
   releases (ie 0.1.13), but the council will discuss making a minor
<br />
   release (0.2.0), and the council and board will both discuss
<br />
   making a major release (1.0.0)
<br />

I would propose now that we plan to make the 0.2.0 release after the
<br />
class and attribute changes have been implemented.
<br />

How does that sound?
<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 Jul 17 2005 - 18:23:30 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 17 18:37:38 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 17 Jul 2005 23:37:38 +0100
Subject: [tei-council] the release conundrum
In-Reply-To: <17114.55901.307615.819445@emt.wwp.brown.edu>
Message-ID: <42DADDB2.6050900@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 17 Jul 2005 23:37:38 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>Sebastian's view of the process (reproduced below) sounds good to me,
</em><br />
<em class="quotelev1">>too. However, I think 6 months is an enormously long time to wait
</em><br />
<em class="quotelev1">>between releases. 
</em><br />
<em class="quotelev1">>
</em><br />
Sure, I agree. after 6 months alarm bells should ring
<br />

<em class="quotelev1">>I also think it is vitally important, Sebastian, that you write up
</em><br />
<em class="quotelev1">>the procedure for making a release, so that someone else could be the
</em><br />
<em class="quotelev1">>release manager without fuss.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
there are two, independent, parts to this:
<br />

 a) doing "make dist" on the source, and then releasing the resulting .zip
<br />
      files on Sourceforge; the good folks on SF explain all this
<br />
 b) making Debian packages, installing them, and then exporting the result
<br />
      to the TEI web. trouble is, this means having a working process
<br />
      to create Debian packages on a shared machine. Sadly, we don't
<br />
      possess a machine running Debian which I can set up to do this.
<br />
Currently
<br />
      its on my laptop. Thats BAD.  But I don't quite know how to proceed.
<br />

in general, I really don't like the fact that we have retreated to
<br />
a position in which no-one but me is really familiar with the
<br />
the TEI P5 tool chain and its ramifications. the NSF project
<br />
was supposed to deliver us from that :-}
<br />

<em class="quotelev1">>weeks. On the other hand, we need to decide at some point who else,
</em><br />
<em class="quotelev1">>if anyone, gets R/W access to the CVS tree. E.g., Laurent is working
</em><br />
<em class="quotelev1">>on both the dictionary and the terminological databases chapter --
</em><br />
<em class="quotelev1">>should he be doing this directly in CVS? David Durand is working on
</em><br />
<em class="quotelev1">>the linking chapter -- should he?
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I  believe that commit rights to the CVS tree should be given
<br />
to any member of a TEI working group who asks for them. The
<br />
barrier is getting onto a working group.
<br />

I suspect others will want more "control", but I express the above
<br />
as a personal preference.
<br />

Absolutely yes we want more people checking out the CVS tree,
<br />
and familiarizing themselves with the source and how to use it;
<br />
and that means trusting them to commit code.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Jul 17 2005 - 18:38:05 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Jul 17 21:19:18 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 18 Jul 2005 10:19:18 +0900
Subject: [tei-council] the release conundrum
In-Reply-To: <42DABFE8.2040009@computing-services.oxford.ac.uk>
Message-ID: <ygfll44kj1l.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 18 Jul 2005 10:19:18 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">>  5) the editors do not need permission from the Council to make minimo
</em><br />
<em class="quotelev1">> releases (ie 0.1.13), but
</em><br />
<em class="quotelev1">>      the council will discuss making a minor release (0.2.0), and the
</em><br />
<em class="quotelev1">> council and board will both
</em><br />
<em class="quotelev1">>      discuss making a major release (1.0.0)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I would propose now that we plan to make the 0.2.0 release after the
</em><br />
<em class="quotelev1">> class and attribute changes have been
</em><br />
<em class="quotelev1">> implemented.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> How does that sound?
</em><br />

This does all make good sense to me.  We should aim at a fresh,
<br />
working release for before the Members Meeting, I think (that is,
<br />
around Oct 15?), which will hopefully be 0.2.0 according to the plan
<br />
above.  
<br />

What would be nice to have, as I said before, is a P5 roadmap that
<br />
gives milestones and dates.
<br />

All the best,
<br />

Christian 
<br />

(once again working out of my <soCalled>mobile office</soCalled> at
<br />
Kansai Airport, waiting for a Taifun-delayed flight... )
<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> Sun Jul 17 2005 - 21:19:24 EDT</span>
</div>

From nsmith at email.unc.edu  Sun Jul 17 21:48:09 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Sun, 17 Jul 2005 21:48:09 -0400
Subject: [tei-council] the release conundrum
In-Reply-To: <42DABFE8.2040009@computing-services.oxford.ac.uk>
Message-ID: <00e201c58b3a$c05b7370$27a81798@lib.unc.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Natasha Smith <nsmith_at_email.unc.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 17 Jul 2005 21:48:09 -0400</span><br />
</address>

Sounds like a very reasonable plan to me.
<br />
best, ns
<br />

----- Original Message ----- 
<br />
From: "Sebastian Rahtz" <sebastian.rahtz_at_computing-services.<!--nospam-->oxford.ac.uk>
<br />
To: "TEICouncil" <tei-council_at_lists.<!--nospam-->village.Virginia.EDU>
<br />
Sent: Sunday, July 17, 2005 4:30 PM
<br />
Subject: [tei-council] the release conundrum
<br />

<p><em class="quotelev1">> I have tried to streamline our release offerings. We now have
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  a) CVS
</em><br />
<em class="quotelev1">>  b) a release which consists of:
</em><br />
<em class="quotelev1">>       - debian and RPM packages
</em><br />
<em class="quotelev1">>       - SF file releases
</em><br />
<em class="quotelev1">>       - a duplicate of a Debian release on the TEI web site.
</em><br />
<em class="quotelev1">>         the existing copies of P4 and P5 DTDs and Guidelines have now been
</em><br />
<em class="quotelev1">>         removed, and the URLs are now silently redirected to the
</em><br />
<em class="quotelev1">> "release" tree.
</em><br />
<em class="quotelev1">>  c) packages for Knoppix and Windows Emacs (not in sync yet)
</em><br />
<em class="quotelev1">>  d) distribution by oXygen
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> we are now at release 0.1.10.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> My view of the process is as follows:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>   1) the editors or their acolytes change CVS as they need to. it is not
</em><br />
<em class="quotelev1">> guarenteed to "work" at any given time.
</em><br />
<em class="quotelev1">>   2) when a consensus emerges that something interesting has happened,
</em><br />
<em class="quotelev1">> or that 6 months has passed,
</em><br />
<em class="quotelev1">>        the editors will instruct the release manager (currently me) to
</em><br />
<em class="quotelev1">> prepare all the outputs in b) above
</em><br />
<em class="quotelev1">>        and release them as close together as possible
</em><br />
<em class="quotelev1">>  3) the Knoppix and Emacs releases are a project of TEI Oxford which
</em><br />
<em class="quotelev1">> will follow a timetable of their own
</em><br />
<em class="quotelev1">>  4) we will all do our best to assist the oXygen people stay in sycn and
</em><br />
<em class="quotelev1">> be forewarned of important changes
</em><br />
<em class="quotelev1">>  5) the editors do not need permission from the Council to make minimo
</em><br />
<em class="quotelev1">> releases (ie 0.1.13), but
</em><br />
<em class="quotelev1">>      the council will discuss making a minor release (0.2.0), and the
</em><br />
<em class="quotelev1">> council and board will both
</em><br />
<em class="quotelev1">>      discuss making a major release (1.0.0)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I would propose now that we plan to make the 0.2.0 release after the
</em><br />
<em class="quotelev1">> class and attribute changes have been
</em><br />
<em class="quotelev1">> implemented.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> How does that sound?
</em><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 />
<em class="quotelev1">> OSS Watch: JISC Open Source Advisory Service
</em><br />
<em class="quotelev1">> http://www.oss-watch.ac.uk
</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.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> Sun Jul 17 2005 - 21:48:11 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Jul 18 03:17:37 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 18 Jul 2005 08:17:37 +0100
Subject: [tei-council] the release conundrum
In-Reply-To: <ygfll44kj1l.fsf@chwpb.local>
Message-ID: <42DB5791.7060607@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 18 Jul 2005 08:17:37 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>This does all make good sense to me.  We should aim at a fresh,
</em><br />
<em class="quotelev1">>working release for before the Members Meeting, I think (that is,
</em><br />
<em class="quotelev1">>around Oct 15?), which will hopefully be 0.2.0 according to the plan
</em><br />
<em class="quotelev1">>above.  
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I agree. I think we should make every effort to meet that
<br />
deadline
<br />

<em class="quotelev1">>What would be nice to have, as I said before, is a P5 roadmap that
</em><br />
<em class="quotelev1">>gives milestones and dates.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
+1
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Mon Jul 18 2005 - 03:18:18 EDT</span>
</div>

From sschreib at umd.edu  Mon Jul 18 05:25:30 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Mon, 18 Jul 2005 05:25:30 -0400
Subject: [tei-council] the release conundrum
In-Reply-To: <42DB5791.7060607@computing-services.oxford.ac.uk>
Message-ID: <42DB758A.3080609@umd.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Susan Schreibman <sschreib_at_umd.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 18 Jul 2005 05:25:30 -0400</span><br />
</address>

I agree with so much of what has been said. I think the TEI membership 
<br />
would appreciate knowing how things are progressing on P5, and whether 
<br />
the types of changes/improvements/ in the last release is worth a 
<br />
particular project downloading a new version.
<br />

 From a user's perspective, I expect that they would appreciate releases 
<br />
less frequently, as been mentioned, every 3-6 months so that they don't 
<br />
feel that as soon as they download a new version, another is available. 
<br />
Even if nothing much has been changed in a three or four month period, I 
<br />
expect the membership would appreciate some sort of update report as to 
<br />
what the Council is working on.
<br />

I agree totally a new release before the members' meeting would be great.
<br />

usan
<br />

<p>Sebastian Rahtz wrote:
<br />

<em class="quotelev1">>Christian Wittern wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>This does all make good sense to me.  We should aim at a fresh,
</em><br />
<em class="quotelev2">>>working release for before the Members Meeting, I think (that is,
</em><br />
<em class="quotelev2">>>around Oct 15?), which will hopefully be 0.2.0 according to the plan
</em><br />
<em class="quotelev2">>>above.  
</em><br />
<em class="quotelev2">>> 
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>I agree. I think we should make every effort to meet that
</em><br />
<em class="quotelev1">>deadline
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>What would be nice to have, as I said before, is a P5 roadmap that
</em><br />
<em class="quotelev2">>>gives milestones and dates.
</em><br />
<em class="quotelev2">>> 
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>+1
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742
Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib_at_umd.<!--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> Mon Jul 18 2005 - 05:25:36 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Mon Jul 18 15:26:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 18 Jul 2005 15:26:11 -0400
Subject: [tei-council] meeting technologies
In-Reply-To: <42DAB4FB.7070405@computing-services.oxford.ac.uk>
Message-ID: <17116.595.844748.107987@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, 18 Jul 2005 15:26:11 -0400</span><br />
</address>

SR> why is it [video conferencing] a pain?
<br />

Let's start with purchasing hardware and installing software. Now I
<br />
have to admit, I haven't priced any of those little webcam cameras
<br />
for well over a year, but they were kindof expensive then, and even
<br />
now they certainly aren't free. And personally, I'm not sure what
<br />
advantage there would be for us.
<br />

<p>SR> But still worth experimenting with having an IRC channel ready on
<br />
SR> the side.
<br />

IRC, ICQ/AIM, Gadu-Gadu, Groupwise, Jabber, Yahoo ... whatever. Yes,
<br />
I think trying this is a very good idea.
<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 Jul 18 2005 - 15:26:16 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jul 20 17:52:02 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jul 2005 22:52:02 +0100
Subject: [tei-council] trying TEI P5 with oXygen
Message-ID: <42DEC782.8020006@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 20 Jul 2005 22:52:02 +0100</span><br />
</address>

At first blush, it looks like oXygen 6.1 pays off in its bundling
<br />
of TEI P5 experimental. You can do "New from templates", choose
<br />
from a range of  example setups, and get stuck into writing TEI P5.
<br />

If you haven't tried oXygen yet, and are not averse to closed-source
<br />
software, give it a try. cool stuff.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Jul 20 2005 - 17:53:09 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Jul 24 11:34:07 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 24 Jul 2005 11:34:07 -0400
Subject: [tei-council] ED W 90 data usable again
Message-ID: <17123.46319.187178.256317@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, 24 Jul 2005 11:34:07 -0400</span><br />
</address>

The data table of attributes is now usable again. 
<br />

As a reminder, this is the table that is associated with (and pointed
<br />
to from) ED W 90. It is a rudimentary PHP interface to a MySQL
<br />
database, so that it can be sorted by column.
<br />

I hope to post more about this issue in a few weeks (I'm on vacation,
<br />
then off to a conference, then teaching a TEI workshop), but in the
<br />
meantime Council members should feel free to browse, comment, suggest
<br />
improvements, point out errors, etc.
<br />

http://www.tei-c.org/Drafts/edw90.xml?style=printable, which points
<br />
to
<br />
http://dev.stg.brown.edu/staff/Syd_Bauman/edw90.php
<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 Jul 24 2005 - 11:34:14 EDT</span>
</div>

From edward.vanhoutte at kantl.be  Tue Jul 26 04:33:44 2005
From: edward.vanhoutte at kantl.be (Edward Vanhoutte)
Date: Tue, 26 Jul 2005 10:33:44 +0200
Subject: [tei-council] multilingualism
Message-ID: <42E5F568.3030509@kantl.be>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Edward Vanhoutte <edward.vanhoutte_at_kantl.be>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 26 Jul 2005 10:33:44 +0200</span><br />
</address>

The Russian and Korean version of TEI Lite cannot be accessed from 
<br />
<http://www.tei-c.org/Lite/>. Who will fix it?
<br />

Edward
<br />

-- 
================
Edward Vanhoutte
Researcher
University of Antwerp
Associate Editor, Literary and Linguistic Computing
University of Antwerp - CDE
Dept. of Literature
Universiteitsplein 1
b-2610 Wilrijk
Belgium
edward dot vanhoutte at kantl dot be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm
_______________________________________________
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 Jul 26 2005 - 04:35:18 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Jul 26 04:33:58 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 26 Jul 2005 09:33:58 +0100
Subject: [tei-council] multilingualism
In-Reply-To: <42E5F568.3030509@kantl.be>
Message-ID: <42E5F576.2070406@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, 26 Jul 2005 09:33:58 +0100</span><br />
</address>

Edward Vanhoutte wrote:
<br />

<em class="quotelev1">> The Russian and Korean version of TEI Lite cannot be accessed from 
</em><br />
<em class="quotelev1">> <http://www.tei-c.org/Lite/>. Who will fix it?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Edward
</em><br />
<em class="quotelev1">>
</em><br />
Whoever gets there first!
<br />

The ideal fix should be to process the SGML and RTF formats to something 
<br />
the webserver can do something sensible with; the quick fix would be to 
<br />
wrap them up in a zip so that cocoon doesnt have kittens when trying to 
<br />
serve them forth.
<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 Jul 26 2005 - 04:39:40 EDT</span>
</div>

From edward.vanhoutte at kantl.be  Tue Jul 26 04:49:55 2005
From: edward.vanhoutte at kantl.be (Edward Vanhoutte)
Date: Tue, 26 Jul 2005 10:49:55 +0200
Subject: [tei-council] multilingualism
In-Reply-To: <42E5F576.2070406@computing-services.oxford.ac.uk>
Message-ID: <42E5F933.1020801@kantl.be>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Edward Vanhoutte <edward.vanhoutte_at_kantl.be>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 26 Jul 2005 10:49:55 +0200</span><br />
</address>

Curiously, no German version of the TEI documentation is listed. Does it 
<br />
not exist? (which I doubt).
<br />

Edward
<br />

Lou Burnard wrote:
<br />

Lou Burnard wrote:
<br />

<em class="quotelev1">> Edward Vanhoutte wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> The Russian and Korean version of TEI Lite cannot be accessed from 
</em><br />
<em class="quotelev2">>> <http://www.tei-c.org/Lite/>. Who will fix it?
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> Edward
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> Whoever gets there first!
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> The ideal fix should be to process the SGML and RTF formats to 
</em><br />
<em class="quotelev1">> something the webserver can do something sensible with; the quick fix 
</em><br />
<em class="quotelev1">> would be to wrap them up in a zip so that cocoon doesnt have kittens 
</em><br />
<em class="quotelev1">> when trying to serve them forth.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />

-- 
================
Edward Vanhoutte
Researcher
University of Antwerp
Associate Editor, Literary and Linguistic Computing
University of Antwerp - CDE
Dept. of Literature
Universiteitsplein 1
b-2610 Wilrijk
Belgium
edward dot vanhoutte at kantl dot be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm
_______________________________________________
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 Jul 26 2005 - 04:52:18 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Jul 26 04:56:13 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 26 Jul 2005 09:56:13 +0100
Subject: [tei-council] multilingualism
In-Reply-To: <42E5F933.1020801@kantl.be>
Message-ID: <42E5FAAD.3070402@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, 26 Jul 2005 09:56:13 +0100</span><br />
</address>

It's not listed because neither of the two versions known to exist has 
<br />
been deposited with the TEI website, despite repeated requests to their 
<br />
translators!
<br />

I  can try again...
<br />

<p><p>Edward Vanhoutte wrote:
<br />

<em class="quotelev1">> Curiously, no German version of the TEI documentation is listed. Does 
</em><br />
<em class="quotelev1">> it not exist? (which I doubt).
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Edward
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Lou Burnard wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Lou Burnard wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> Edward Vanhoutte wrote:
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev3">>>> The Russian and Korean version of TEI Lite cannot be accessed from 
</em><br />
<em class="quotelev3">>>> <http://www.tei-c.org/Lite/>. Who will fix it?
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev3">>>> Edward
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev2">>> Whoever gets there first!
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> The ideal fix should be to process the SGML and RTF formats to 
</em><br />
<em class="quotelev2">>> something the webserver can do something sensible with; the quick fix 
</em><br />
<em class="quotelev2">>> would be to wrap them up in a zip so that cocoon doesnt have kittens 
</em><br />
<em class="quotelev2">>> when trying to serve them forth.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>
</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> Tue Jul 26 2005 - 05:01:48 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jul 26 05:03:27 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 26 Jul 2005 10:03:27 +0100
Subject: [tei-council] multilingualism
In-Reply-To: <42E5F933.1020801@kantl.be>
Message-ID: <42E5FC5F.3050907@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 26 Jul 2005 10:03:27 +0100</span><br />
</address>

Edward Vanhoutte wrote:
<br />

<em class="quotelev1">> Curiously, no German version of the TEI documentation is listed. Does
</em><br />
<em class="quotelev1">> it not exist? (which I doubt).
</em><br />
<em class="quotelev1">>
</em><br />
Arno Mittelbach made a start last year, but didnt complete it. FWIW.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Jul 26 2005 - 05:05:46 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jul 26 05:04:44 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 26 Jul 2005 10:04:44 +0100
Subject: [tei-council] multilingualism
In-Reply-To: <42E5F576.2070406@computing-services.oxford.ac.uk>
Message-ID: <42E5FCAC.10901@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 26 Jul 2005 10:04:44 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">> Edward Vanhoutte wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> The Russian and Korean version of TEI Lite cannot be accessed from
</em><br />
<em class="quotelev2">>> <http://www.tei-c.org/Lite/>. Who will fix it?
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> Edward
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> Whoever gets there first!
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> The ideal fix should be to process the SGML and RTF formats to
</em><br />
<em class="quotelev1">> something the webserver can do something sensible with; the quick fix
</em><br />
<em class="quotelev1">> would be to wrap them up in a zip so that cocoon doesnt have kittens
</em><br />
<em class="quotelev1">> when trying to serve them forth.
</em><br />
<em class="quotelev1">>
</em><br />
no need. Cocoon duly fixed. much less work than zipping.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Jul 26 2005 - 05:06:24 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Jul 26 05:17:27 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 26 Jul 2005 10:17:27 +0100
Subject: [tei-council] multilingualism
In-Reply-To: <42E5FC5F.3050907@computing-services.oxford.ac.uk>
Message-ID: <42E5FFA7.1070800@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, 26 Jul 2005 10:17:27 +0100</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev1">> Edward Vanhoutte wrote:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>Curiously, no German version of the TEI documentation is listed. Does
</em><br />
<em class="quotelev2">>>it not exist? (which I doubt).
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Arno Mittelbach made a start last year, but didnt complete it. FWIW.
</em><br />
<em class="quotelev1">> 
</em><br />

which makes three....
<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 Jul 26 2005 - 05:13:12 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Wed Jul 27 06:54:10 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 27 Jul 2005 11:54:10 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <17116.595.844748.107987@emt.wwp.brown.edu>
Message-ID: <42E767D2.2080407@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, 27 Jul 2005 11:54:10 +0100</span><br />
</address>

Syd Bauman wrote:
<br />
<em class="quotelev1">> SR> But still worth experimenting with having an IRC channel ready on
</em><br />
<em class="quotelev1">> SR> the side.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> IRC, ICQ/AIM, Gadu-Gadu, Groupwise, Jabber, Yahoo ... whatever. Yes,
</em><br />
<em class="quotelev1">> I think trying this is a very good idea.
</em><br />

I've been sat in #tei-c on irc.freenode.net during work hours (UK) since 
<br />
returning from these conferences on Monday, and although people seem to think it 
<br />
is a good idea and I mentioned it in a previous email, nary a soul has visited 
<br />
me. :-(
<br />

(really just a reminder)
<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 Jul 27 2005 - 06:56:56 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jul 27 07:14:43 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 27 Jul 2005 12:14:43 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <42E767D2.2080407@computing-services.oxford.ac.uk>
Message-ID: <42E76CA3.1020802@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 27 Jul 2005 12:14:43 +0100</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">> I've been sat in #tei-c on irc.freenode.net during work hours (UK) 
</em><br />
<em class="quotelev1">> since returning from these conferences on Monday, and although people 
</em><br />
<em class="quotelev1">> seem to think it is a good idea and I mentioned it in a previous 
</em><br />
<em class="quotelev1">> email, nary a soul has visited me. :-(
</em><br />

I've just lost my Gaim virginity and am frolicking with James, FWIW
<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 Jul 27 2005 - 07:19:06 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Wed Jul 27 07:19:32 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 27 Jul 2005 12:19:32 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <42E76CA3.1020802@computing-services.oxford.ac.uk>
Message-ID: <42E76DC4.2010801@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, 27 Jul 2005 12:19:32 +0100</span><br />
</address>

Sebastian Rahtz wrote:
<br />

<em class="quotelev1">> I've just lost my Gaim virginity and am frolicking with James, FWIW
</em><br />

You do make it sound all sordid...
<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 Jul 27 2005 - 07:22:18 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jul 27 07:53:31 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 27 Jul 2005 12:53:31 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <42E76DC4.2010801@computing-services.oxford.ac.uk>
Message-ID: <42E775BB.4080603@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 27 Jul 2005 12:53:31 +0100</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">> Sebastian Rahtz wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> I've just lost my Gaim virginity and am frolicking with James, FWIW
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> You do make it sound all sordid...
</em><br />

<p>I can't stop washing my hands now
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Jul 27 2005 - 07:55:58 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Wed Jul 27 14:29:20 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 27 Jul 2005 14:29:20 -0400
Subject: [tei-council] meeting technologies
In-Reply-To: <42E767D2.2080407@computing-services.oxford.ac.uk>
Message-ID: <17127.53888.306765.835911@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, 27 Jul 2005 14:29:20 -0400</span><br />
</address>

I was in favor of having in IRC channel open on the side during
<br />
conference calls, not for daily discussions.
<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 Jul 27 2005 - 14:29:25 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jul 27 16:16:33 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 27 Jul 2005 21:16:33 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <17127.53888.306765.835911@emt.wwp.brown.edu>
Message-ID: <42E7EBA1.5000806@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 27 Jul 2005 21:16:33 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>I was in favor of having in IRC channel open on the side during
</em><br />
<em class="quotelev1">>conference calls, not for daily discussions.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

but this was to experiment with now, to decide if its
<br />
a good idea for a real meeting.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Jul 27 2005 - 16:18:23 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jul 27 22:40:29 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 28 Jul 2005 11:40:29 +0900
Subject: [tei-council] meeting technologies
In-Reply-To: <42E7EBA1.5000806@computing-services.oxford.ac.uk>
Message-ID: <ygfu0if3b6q.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 28 Jul 2005 11:40:29 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Syd Bauman wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>I was in favor of having in IRC channel open on the side during
</em><br />
<em class="quotelev2">>>conference calls, not for daily discussions.
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> but this was to experiment with now, to decide if its
</em><br />
<em class="quotelev1">> a good idea for a real meeting.
</em><br />
<em class="quotelev1">>
</em><br />

To make this experimenting more efficient, I would like to suggest to
<br />
make an appointment (is this what you call it?) on such a channel and
<br />
then go.  As I mentioned before, I have never used IRC before, the
<br />
closest I came to Instqnt Messaging is a bit of chatting with my son
<br />
using Skype.  So to kick this off, I would need an instruction of how
<br />
to do this on a Mac OS X system.  (e.g what software to use, where to
<br />
connect etc.)   
<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> Wed Jul 27 2005 - 22:40:33 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Thu Jul 28 03:58:11 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 28 Jul 2005 08:58:11 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <ygfu0if3b6q.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <42E89013.7040305@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, 28 Jul 2005 08:58:11 +0100</span><br />
</address>

1. Install Firefox (you probably want to do this anyway)
<br />

2. Install the chatzilla plugin (you will need to tell Firefox you trust 
<br />
hacksrus before it lets you do this, but otherwise this is just a matter 
<br />
of finding the right link and clicking on it)
<br />

3. Select chatzilla from the Tools menu and fire her up
<br />

4. connect to the right channel (to be determined)
<br />

I did it yesterday, on this mac ,  in 5 minutes
<br />

<p> Christian Wittern wrote:
<br />

<em class="quotelev1">>Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk> writes:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>Syd Bauman wrote:
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev3">>>>I was in favor of having in IRC channel open on the side during
</em><br />
<em class="quotelev3">>>>conference calls, not for daily discussions.
</em><br />
<em class="quotelev3">>>> 
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev3">>>>      
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev2">>>but this was to experiment with now, to decide if its
</em><br />
<em class="quotelev2">>>a good idea for a real meeting.
</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">>To make this experimenting more efficient, I would like to suggest to
</em><br />
<em class="quotelev1">>make an appointment (is this what you call it?) on such a channel and
</em><br />
<em class="quotelev1">>then go.  As I mentioned before, I have never used IRC before, the
</em><br />
<em class="quotelev1">>closest I came to Instqnt Messaging is a bit of chatting with my son
</em><br />
<em class="quotelev1">>using Skype.  So to kick this off, I would need an instruction of how
</em><br />
<em class="quotelev1">>to do this on a Mac OS X system.  (e.g what software to use, where to
</em><br />
<em class="quotelev1">>connect etc.)   
</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="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 Jul 28 2005 - 04:03:52 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Jul 28 19:36:58 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 29 Jul 2005 08:36:58 +0900
Subject: [tei-council] meeting technologies
In-Reply-To: <42E89013.7040305@computing-services.oxford.ac.uk>
Message-ID: <ygfslxycxk5.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 29 Jul 2005 08:36:58 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> 1. Install Firefox (you probably want to do this anyway)
</em><br />
In place
<br />
<em class="quotelev1">> 2. Install the chatzilla plugin (you will need to tell Firefox you
</em><br />
<em class="quotelev1">>    trust hacksrus before it lets you do this, but otherwise this is
</em><br />
<em class="quotelev1">>    just a matter of finding the right link and clicking on it)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 3. Select chatzilla from the Tools menu and fire her up
</em><br />
<em class="quotelev1">>
</em><br />
So far so good.
<br />

<em class="quotelev1">> 4. connect to the right channel (to be determined)
</em><br />
<em class="quotelev1">>
</em><br />
Waiting for further instructions on this.
<br />

<em class="quotelev1">> I did it yesterday, on this mac ,  in 5 minutes
</em><br />

Thanks and welcome to the club:-)
<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> Thu Jul 28 2005 - 19:37:10 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Jul 28 19:39:48 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 29 Jul 2005 08:39:48 +0900
Subject: [tei-council] Next conference call
Message-ID: <ygfoe8mcxff.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 29 Jul 2005 08:39:48 +0900</span><br />
</address>

Sebastian, council members,
<br />

As you know, Sebastian volunteered to use some webmagic to determine
<br />
the date of our next on-wire meeting.  Since some time has elapsed
<br />
since then, I wonder if we can hear the results so that preparations
<br />
can start.
<br />

BTW, I now got a brand new handsfree set and hope that will improve
<br />
audability on my side.
<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 Jul 28 2005 - 19:39:55 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Fri Jul 29 04:57:11 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 29 Jul 2005 09:57:11 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <ygfslxycxk5.fsf@chwpb.local>
Message-ID: <42E9EF67.8030506@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, 29 Jul 2005 09:57:11 +0100</span><br />
</address>

Christian Wittern wrote:
<br />
<em class="quotelev1">> Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>4. connect to the right channel (to be determined)
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Waiting for further instructions on this.
</em><br />
<em class="quotelev1">> 
</em><br />

After having set various preferences in Chatzilla (like your 'Nickname')
<br />
Then you can either manually connect by using
<br />
/attach irc.freenode.net
<br />
/join #tei-c
<br />

or you can connect more automatically by using the url
<br />
irc://irc.freenode.net/tei-c
<br />
as you would a normal url in firefox.
<br />
(Which means it can be bookmarked etc. as well.)
<br />

I still prefer gaim, but that is because it is multiprotocol.
<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 Jul 29 2005 - 05:00:13 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sat Jul 30 11:51:09 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 30 Jul 2005 16:51:09 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
Message-ID: <42EBA1ED.7070603@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, 30 Jul 2005 16:51:09 +0100</span><br />
</address>

I'm rather slowly working my way through the proposals in Syd's table of 
<br />
attributes in  a more or less random order, picking off the simple cases 
<br />
first. I am simply applying the changes proposed where they seem 
<br />
non-controversial and/or already agreed to, but this is not always the case!
<br />

As the whole document is a bit long to digest, I am going to post a few 
<br />
specific queries as they come up, to sound out Council's views:
<br />

1. Drop the following attributes on teiHeader:
<br />

creator  (Syd proposes using resp instead)
<br />
status (this can take values "new" and "updated")
<br />

It seems useful to me to distinguish the agency responsible for creation 
<br />
of a header from the person who last changed it (which is identifiable 
<br />
from the <revisionDesc>)  but maybe not?  I'm less sure about the 
<br />
usefulness of STATUS. Anyone use these attributes?
<br />

2. Drop the wscale attribute on <alt> and <altGrp> (presumably because 
<br />
the  weight attribute  should contain a quantity and a scale as a single 
<br />
value -- but this is not explicit in Syd's table)
<br />

This seems reasonable in itself. On the other hand <alt> is a pretty 
<br />
recondite element which probably needs a lot more thought
<br />

<p>3. Drop <xxxSpan> elements in favour of HORSE-style attributes (i.e. 
<br />
something like the spanTo attribute added to <index>)
<br />

I am basically in favour of this proposal, but it needs more careful and 
<br />
detailed articulation
<br />

4. drop SIGIL on <witness> in favour of xml:id
<br />

This would be consistent with what we have already done for <hand> and 
<br />
<handShift>.  But will the users of <witness> be happy having to say 
<br />
<witness xml:id="foo"> instead of <witness sigil="foo">?
<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 Jul 30 2005 - 11:51:22 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jul 30 16:57:12 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 30 Jul 2005 21:57:12 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42EBA1ED.7070603@computing-services.oxford.ac.uk>
Message-ID: <42EBE9A8.8080606@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 30 Jul 2005 21:57:12 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">> 1. Drop the following attributes on teiHeader:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> creator  (Syd proposes using resp instead)
</em><br />
<em class="quotelev1">> status (this can take values "new" and "updated")
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> It seems useful to me to distinguish the agency responsible for
</em><br />
<em class="quotelev1">> creation of a header from the person who last changed it (which is
</em><br />
<em class="quotelev1">> identifiable from the <revisionDesc>)  but maybe not?  I'm less sure
</em><br />
<em class="quotelev1">> about the usefulness of STATUS. Anyone use these attributes?
</em><br />

<revisionDesc> applies to the document, not the header, surely? @creator
<br />
is the metadata stiuff only.
<br />
you might argue that <teiHeader> should be allowed
<br />
a child <respStmt> of its own.
<br />

any act of creation should generate a <change> in <revisionDesc> anyway,
<br />
by the way (and IMHO)
<br />

@status seems too limited to be of serious use.<!--nospam-->
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 3. Drop <xxxSpan> elements in favour of HORSE-style attributes (i.e.
</em><br />
<em class="quotelev1">> something like the spanTo attribute added to <index>)
</em><br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I am basically in favour of this proposal, but it needs more careful
</em><br />
<em class="quotelev1">> and detailed articulation
</em><br />

if I recall discussions with Lou correctly, my sticking point was that
<br />
idea that <del> would sometimes be empty
<br />
and sometimes not, which seems bothersome
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 4. drop SIGIL on <witness> in favour of xml:id
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> This would be consistent with what we have already done for <hand> and
</em><br />
<em class="quotelev1">> <handShift>.  But will the users of <witness> be happy having to say
</em><br />
<em class="quotelev1">> <witness xml:id="foo"> instead of <witness sigil="foo">?
</em><br />

<p>why on earth would they care either way? if you let them have a private
<br />
recondite name for an ID attribute, everyone
<br />
else will want one too.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sat Jul 30 2005 - 16:59:34 EDT</span>
</div>

From Laurent.Romary at loria.fr  Sun Jul 31 04:41:19 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Sun, 31 Jul 2005 10:41:19 +0200
Subject: [tei-council] meeting technologies
In-Reply-To: <42E9EF67.8030506@computing-services.oxford.ac.uk>
Message-ID: <51160d00da7c5e1b59d0f6b35d5e1fe9@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>: Sun, 31 Jul 2005 10:41:19 +0200</span><br />
</address>

The thing is intalled on my Mac as well!
<br />
Laurent
<br />

Le 29 juil. 05, ? 10:57, James Cummings a ?crit :
<br />

<em class="quotelev1">> Christian Wittern wrote:
</em><br />
<em class="quotelev2">>> Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> writes:
</em><br />
<em class="quotelev3">>>> 4. connect to the right channel (to be determined)
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev2">>> Waiting for further instructions on this.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> After having set various preferences in Chatzilla (like your 
</em><br />
<em class="quotelev1">> 'Nickname')
</em><br />
<em class="quotelev1">> Then you can either manually connect by using
</em><br />
<em class="quotelev1">> /attach irc.freenode.net
</em><br />
<em class="quotelev1">> /join #tei-c
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> or you can connect more automatically by using the url
</em><br />
<em class="quotelev1">> irc://irc.freenode.net/tei-c
</em><br />
<em class="quotelev1">> as you would a normal url in firefox.
</em><br />
<em class="quotelev1">> (Which means it can be bookmarked etc. as well.)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I still prefer gaim, but that is because it is multiprotocol.
</em><br />
<em class="quotelev1">> -- 
</em><br />
<em class="quotelev1">> Dr James Cummings, Oxford Text Archive, University of Oxford
</em><br />
<em class="quotelev1">> James dot Cummings at oucs dot ox dot ac dot uk
</em><br />
<em class="quotelev1">> _______________________________________________
</em><br />
<em class="quotelev1">> tei-council mailing list
</em><br />
<em class="quotelev1">> tei-council_at_lists.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>_______________________________________________
<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 Jul 31 2005 - 04:41:18 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 31 05:19:17 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 31 Jul 2005 10:19:17 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <51160d00da7c5e1b59d0f6b35d5e1fe9@loria.fr>
Message-ID: <42EC9795.1090409@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 31 Jul 2005 10:19:17 +0100</span><br />
</address>

Laurent Romary wrote:
<br />

<em class="quotelev1">> The thing is intalled on my Mac as well!
</em><br />

o, Christian, where are you?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Jul 31 2005 - 05:21:42 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Jul 31 10:16:47 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 31 Jul 2005 10:16:47 -0400
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42EBE9A8.8080606@computing-services.oxford.ac.uk>
Message-ID: <17132.56655.667577.878408@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, 31 Jul 2005 10:16:47 -0400</span><br />
</address>

<em class="quotelev1">> <revisionDesc> applies to the document, not the header, surely?
</em><br />

I have often entered <change> elements in a <revisionDesc> that
<br />
describe a change to the <teiHeader>. I think of <revisionDesc> as a
<br />
revision description of the entire file (<TEI.2>, <teiCorpus2>,
<br />
whatever). 
<br />

<p><em class="quotelev1">> @creator is the metadata stiuff only. you might argue that
</em><br />
<em class="quotelev1">> <teiHeader> should be allowed a child <respStmt> of its own.
</em><br />

Might, but I wouldn't.
<br />

<p><em class="quotelev1">> @status seems too limited to be of serious use.<!--nospam-->
</em><br />

Remember that it (currently) has dateCreated= and dateUpdated= to go
<br />
with it. But nonetheless, I agree completely. Even all combined, they
<br />
are not really useful, and probably should be dropped.
<br />

We might create a mechanism for stating that a particular <change> in
<br />
the <revisionDesc> applies to only the <teiHeader>, not the <text>.
<br />
(E.g., attribute scope { ( "header" | "text" | "both" ) } or
<br />
something like that), but since we're not planning on using
<br />
independent headers anymore, I'm not sure there's a significant
<br />
advantage to such a scheme.
<br />

<p>LB> 3. Drop <xxxSpan> elements in favour of HORSE-style attributes (i.e.
<br />
LB> something like the spanTo attribute added to <index>)
<br />

LB> I am basically in favour of this proposal, but it needs more careful
<br />
LB> and detailed articulation
<br />

I agree. If members of Council are interested, you can glean a little
<br />
bit more information about HORSE from the slides to my talk at ACH,
<br />
which are at
<br />
  http://www.tei-c.org/Talks/2005/ACH-ALLC/Bauman.tgz
<br />
particularly slides 6, 7, and 8. (There is currently no pointer from
<br />
any index page to those slides, as the other talks from that session
<br />
are not available yet due to licensing issues I just haven't gotten
<br />
around to dealing with.)
<br />

<p><em class="quotelev1">> why on earth would they care either way? if you let them have a
</em><br />
<em class="quotelev1">> private recondite name for an ID attribute, everyone else will want
</em><br />
<em class="quotelev1">> one too.
</em><br />

Really good point. The problem is that "they", the folks who use
<br />
<witness>, already have sigil= in P4. So it's not a question of
<br />
letting "them" have a special name, it will be viewed more as taking
<br />
away the special name currently available.
<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 Jul 31 2005 - 10:16:51 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Sun Jul 31 11:02:26 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 31 Jul 2005 16:02:26 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42EBA1ED.7070603@computing-services.oxford.ac.uk>
Message-ID: <42ECE802.3040006@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>: Sun, 31 Jul 2005 16:02:26 +0100</span><br />
</address>

Lou Burnard wrote:
<br />
<em class="quotelev1">> I'm rather slowly working my way through the proposals in Syd's table of 
</em><br />
<em class="quotelev1">> attributes in  a more or less random order, picking off the simple cases 
</em><br />
<em class="quotelev1">> first. I am simply applying the changes proposed where they seem 
</em><br />
<em class="quotelev1">> non-controversial and/or already agreed to, but this is not always the 
</em><br />
<em class="quotelev1">> case!
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> As the whole document is a bit long to digest, I am going to post a few 
</em><br />
<em class="quotelev1">> specific queries as they come up, to sound out Council's views:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 1. Drop the following attributes on teiHeader:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> creator  (Syd proposes using resp instead)
</em><br />
<em class="quotelev1">> status (this can take values "new" and "updated")
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> It seems useful to me to distinguish the agency responsible for creation 
</em><br />
<em class="quotelev1">> of a header from the person who last changed it (which is identifiable 
</em><br />
<em class="quotelev1">> from the <revisionDesc>)  but maybe not?  I'm less sure about the 
</em><br />
<em class="quotelev1">> usefulness of STATUS. Anyone use these attributes?
</em><br />

<p>For the record, the OTA uses @type and @date.created but none of the 
<br />
others.  I've never noticed anyone using them in other files I've 
<br />
looked at....
<br />

<p><em class="quotelev1">> 3. Drop <xxxSpan> elements in favour of HORSE-style attributes (i.e. 
</em><br />
<em class="quotelev1">> something like the spanTo attribute added to <index>)
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I am basically in favour of this proposal, but it needs more careful and 
</em><br />
<em class="quotelev1">> detailed articulation
</em><br />

I'd agree with this (with a more detailed proposal).
<br />

<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 4. drop SIGIL on <witness> in favour of xml:id
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> This would be consistent with what we have already done for <hand> and 
</em><br />
<em class="quotelev1">> <handShift>.  But will the users of <witness> be happy having to say 
</em><br />
<em class="quotelev1">> <witness xml:id="foo"> instead of <witness sigil="foo">?
</em><br />

My instant reaction to this was that I disagreed.  However, I'm 
<br />
willing to be convinced.
<br />

My reason for that was I have a vague memory of using
<br />
<witness id="OneThing" sigil="AnotherThing"> previously.
<br />
My understanding was that the sigil was a nice ID which then I'd
<br />
use in my <rdg>'s etc. elsewhere.  So the <rdg> refers
<br />
back to the content of the <witness> in a semantic way as expressed by 
<br />
the guidelines, but that an id or now xml:id simply locates the 
<br />
element.  So a sigil is an xml:id with meaning.  I realise that is 
<br />
fairly tenuous.
<br />

I think I had previously mis-used them where an id was used for a 
<br />
long-form of a sigil and sigil was used for the publicly-viewable 
<br />
version.
<br />

If we follow this further, does that mean <rdg> becomes
<br />
<rdg wit="#MsA #MsB #MsC"> instead of
<br />
<rdg wit="MsA MsB MsC"> ?
<br />

If that is happening across the board with other attributes which 
<br />
function as an ID then I guess it is a good thing.  But I thought I 
<br />
should attempt to express my instant (and irrational) first impression.
<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 Jul 31 2005 - 11:02:28 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 31 16:27:52 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 31 Jul 2005 21:27:52 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42ECE802.3040006@computing-services.oxford.ac.uk>
Message-ID: <42ED3448.8090106@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 31 Jul 2005 21:27:52 +0100</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> If we follow this further, does that mean <rdg> becomes
</em><br />
<em class="quotelev1">> <rdg wit="#MsA #MsB #MsC"> instead of
</em><br />
<em class="quotelev1">> <rdg wit="MsA MsB MsC"> ?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> If that is happening across the board with other attributes which
</em><br />
<em class="quotelev1">> function as an ID then I guess it is a good thing.  But I thought I
</em><br />
<em class="quotelev1">> should attempt to express my instant (and irrational) first impression.
</em><br />
<em class="quotelev1">>
</em><br />
thats the way the cookie crumbles, I am afraid. those # signs are going
<br />
to be with
<br />
you for ever now.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Jul 31 2005 - 16:30:12 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 31 16:34:08 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 31 Jul 2005 21:34:08 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <17132.56655.667577.878408@emt.wwp.brown.edu>
Message-ID: <42ED35C0.6090304@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 31 Jul 2005 21:34:08 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev2">>><revisionDesc> applies to the document, not the header, surely?
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I have often entered <change> elements in a <revisionDesc> that
</em><br />
<em class="quotelev1">>describe a change to the <teiHeader>. I think of <revisionDesc> as a
</em><br />
<em class="quotelev1">>revision description of the entire file (<TEI.2>, <teiCorpus2>,
</em><br />
<em class="quotelev1">>whatever). 
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
Yes, so do I.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>We might create a mechanism for stating that a particular <change> in
</em><br />
<em class="quotelev1">>the <revisionDesc> applies to only the <teiHeader>, not the <text>.
</em><br />
<em class="quotelev1">>(E.g., attribute scope { ( "header" | "text" | "both" ) } or
</em><br />
<em class="quotelev1">>something like that)
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
yrugh. If you must. I find it hard to imagine when one would
<br />
make use of it in Real Life (tm).
<br />

<em class="quotelev1">>Really good point. The problem is that "they", the folks who use
</em><br />
<em class="quotelev1">><witness>, already have sigil= in P4. So it's not a question of
</em><br />
<em class="quotelev1">>letting "them" have a special name, it will be viewed more as taking
</em><br />
<em class="quotelev1">>away the special name currently available.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
Well, P5 never promised to be backward compatible. Lots of people
<br />
are going to have to get used to small (but significant to them) changes.
<br />

If @sigil *is* a normal ID, there is no argument, it must be @xml:id.
<br />
Unless James can argue his case in full court.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Jul 31 2005 - 16:36:28 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Sun Jul 31 18:09:30 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 31 Jul 2005 23:09:30 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42ED35C0.6090304@computing-services.oxford.ac.uk>
Message-ID: <42ED4C1A.70503@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>: Sun, 31 Jul 2005 23:09:30 +0100</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev2">>>Really good point. The problem is that "they", the folks who use
</em><br />
<em class="quotelev2">>><witness>, already have sigil= in P4. So it's not a question of
</em><br />
<em class="quotelev2">>>letting "them" have a special name, it will be viewed more as taking
</em><br />
<em class="quotelev2">>>away the special name currently available.
</em><br />
<em class="quotelev1">> If @sigil *is* a normal ID, there is no argument, it must be @xml:id.
</em><br />
<em class="quotelev1">> Unless James can argue his case in full court.
</em><br />

Under P4 @sigil is datatype CDATA.  And "indicates the sigil for one 
<br />
witness or for one group of witnesses to which readings are assigned 
<br />
in a critical apparatus".  Indicating the sigil, to me, doesn't mean 
<br />
the same thing as providing an element ID.  Is it possible, for 
<br />
example, for a well-known standard sigil to comprise of something 
<br />
which doesn't form a proper @xml:id?
<br />

The notes to <witness> instead point to one of the uses of @id on this 
<br />
as the sigil: "In local encoding schemes, the value of the id 
<br />
attribute can be used as the sigil, and the declared value of the wit 
<br />
attribute may be changed to IDREF, so as to ensure that only witnesses 
<br />
referred to in a <witness> element contained within a <witList> may 
<br />
occur in the value of any wit attribute on a reading element within an 
<br />
apparatus."  This implies to me that there are also instances where 
<br />
one wouldn't want @id to be used as the sigil.<!--nospam--> Although this 
<br />
validation is useful (and what @id is meant for) providing this 
<br />
validation is not the point of the @sigil attribute.<!--nospam-->  It just strikes 
<br />
me that the sigil attribute is used to record a sigil, which may, or 
<br />
may not, be the same as an @id.<!--nospam-->
<br />

In addition, as Syd says, it seems like P5 (which provides such 
<br />
benefits for manuscript encoding) then would be removing the ability 
<br />
to record a sigil.  <witness xml:id="MS123"> doesn't mean the
<br />
same thing as <witness sigil="123"> or <witness xml:id="MS123" 
<br />
sigil="123">.
<br />

But I've not really given it any serious thought yet, and as I said, 
<br />
I'm willing to be convinced.
<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 Jul 31 2005 - 18:09:33 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sun Jul 31 18:40:00 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 31 Jul 2005 23:40:00 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42ED4C1A.70503@computing-services.oxford.ac.uk>
Message-ID: <42ED5340.9020905@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, 31 Jul 2005 23:40:00 +0100</span><br />
</address>

I agree with Jas that there might be cases where you'd want to use 
<br />
something different for a sigil and for an ID. However, (a) it's pretty 
<br />
hard to understand what function a "sigil" attribute on <witness> might 
<br />
perform which wouldn't be covered by *either* the xml:id attribute *or* 
<br />
the n attribute (b) an attribute that then cites the sigil has to be 
<br />
*either* a URL *or* NOT.  P4 shilly-shallies on this basic distinction 
<br />
all over the place and It Has To Stop.
<br />

<p>James Cummings wrote:
<br />

<em class="quotelev1">> Sebastian Rahtz wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev3">>>> Really good point. The problem is that "they", the folks who use
</em><br />
<em class="quotelev3">>>> <witness>, already have sigil= in P4. So it's not a question of
</em><br />
<em class="quotelev3">>>> letting "them" have a special name, it will be viewed more as taking
</em><br />
<em class="quotelev3">>>> away the special name currently available.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> If @sigil *is* a normal ID, there is no argument, it must be @xml:id.
</em><br />
<em class="quotelev2">>> Unless James can argue his case in full court.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Under P4 @sigil is datatype CDATA.  And "indicates the sigil for one 
</em><br />
<em class="quotelev1">> witness or for one group of witnesses to which readings are assigned 
</em><br />
<em class="quotelev1">> in a critical apparatus".  Indicating the sigil, to me, doesn't mean 
</em><br />
<em class="quotelev1">> the same thing as providing an element ID.  Is it possible, for 
</em><br />
<em class="quotelev1">> example, for a well-known standard sigil to comprise of something 
</em><br />
<em class="quotelev1">> which doesn't form a proper @xml:id?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> The notes to <witness> instead point to one of the uses of @id on this 
</em><br />
<em class="quotelev1">> as the sigil: "In local encoding schemes, the value of the id 
</em><br />
<em class="quotelev1">> attribute can be used as the sigil, and the declared value of the wit 
</em><br />
<em class="quotelev1">> attribute may be changed to IDREF, so as to ensure that only witnesses 
</em><br />
<em class="quotelev1">> referred to in a <witness> element contained within a <witList> may 
</em><br />
<em class="quotelev1">> occur in the value of any wit attribute on a reading element within an 
</em><br />
<em class="quotelev1">> apparatus."  This implies to me that there are also instances where 
</em><br />
<em class="quotelev1">> one wouldn't want @id to be used as the sigil. Although this 
</em><br />
<em class="quotelev1">> validation is useful (and what @id is meant for) providing this 
</em><br />
<em class="quotelev1">> validation is not the point of the @sigil attribute.  It just strikes 
</em><br />
<em class="quotelev1">> me that the sigil attribute is used to record a sigil, which may, or 
</em><br />
<em class="quotelev1">> may not, be the same as an @id.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> In addition, as Syd says, it seems like P5 (which provides such 
</em><br />
<em class="quotelev1">> benefits for manuscript encoding) then would be removing the ability 
</em><br />
<em class="quotelev1">> to record a sigil.  <witness xml:id="MS123"> doesn't mean the
</em><br />
<em class="quotelev1">> same thing as <witness sigil="123"> or <witness xml:id="MS123" 
</em><br />
<em class="quotelev1">> sigil="123">.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> But I've not really given it any serious thought yet, and as I said, 
</em><br />
<em class="quotelev1">> I'm willing to be convinced.
</em><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.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 />

_______________________________________________
<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 Jul 31 2005 - 18:40:13 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Aug  1 00:31:07 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 01 Aug 2005 13:31:07 +0900
Subject: [tei-council] meeting technologies
In-Reply-To: <42EC9795.1090409@computing-services.oxford.ac.uk>
Message-ID: <ygffytu2s8k.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 01 Aug 2005 13:31:07 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Laurent Romary wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> The thing is intalled on my Mac as well!
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> so, Christian, where are you?
</em><br />
<em class="quotelev1">>
</em><br />

I am still here.  Do you think I have to sit there and watch that space,
<br />
day and night?
<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 Aug 01 2005 - 00:31:17 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Aug  1 17:53:21 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 01 Aug 2005 22:53:21 +0100
Subject: [tei-council] Next conference call
In-Reply-To: <ygfoe8mcxff.fsf@chwpb.local>
Message-ID: <42EE99D1.6020407@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 01 Aug 2005 22:53:21 +0100</span><br />
</address>

Friday 9th September is what the Meetomatic oracle declares. of the 7
<br />
people who filled in the form,
<br />
we'd get 6 on that date. Lets do it then.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Mon Aug 01 2005 - 17:56:03 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Aug  2 18:47:26 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 02 Aug 2005 23:47:26 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42ED35C0.6090304@computing-services.oxford.ac.uk>
Message-ID: <42EFF7FE.6030201@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, 02 Aug 2005 23:47:26 +0100</span><br />
</address>

Sebastian Rahtz wrote:
<br />

<em class="quotelev1">>Syd Bauman wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev3">>>><revisionDesc> applies to the document, not the header, surely?
</em><br />
<em class="quotelev3">>>>   
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev3">>>>      
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev2">>>I have often entered <change> elements in a <revisionDesc> that
</em><br />
<em class="quotelev2">>>describe a change to the <teiHeader>. I think of <revisionDesc> as a
</em><br />
<em class="quotelev2">>>revision description of the entire file (<TEI.2>, <teiCorpus2>,
</em><br />
<em class="quotelev2">>>whatever). 
</em><br />
<em class="quotelev2">>> 
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>Yes, so do I.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

I have followed this advice, and now removed all attributes from the TEI 
<br />
Header (other than type). I have also added the following text to 
<br />
chapter HD:
<br />

<p>The main purpose of the revision description is to record changes
<br />
in the text to which a header is prefixed. However, it is recommended
<br />
TEI practice to include entries also for significant changes in the
<br />
header itself (other than the revision description itself, of
<br />
course). At the very least, an entry should be supplied indicating the
<br />
date of creation of the header.</p>
<br />

Any objections?
<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> Tue Aug 02 2005 - 18:46:21 EDT</span>
</div>

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Aug  2 18:47:49 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 02 Aug 2005 23:47:49 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42EFF7FE.6030201@computing-services.oxford.ac.uk>
Message-ID: <42EFF815.8030005@computing-services.oxford.ac.uk>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 02 Aug 2005 23:47:49 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> <p>The main purpose of the revision description is to record changes
</em><br />
<em class="quotelev1">> in the text to which a header is prefixed. However, it is recommended
</em><br />
<em class="quotelev1">> TEI practice to include entries also for significant changes in the
</em><br />
<em class="quotelev1">> header itself (other than the revision description itself, of
</em><br />
<em class="quotelev1">> course). At the very least, an entry should be supplied indicating the
</em><br />
<em class="quotelev1">> date of creation of the header.</p>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Any objections?
</em><br />

well, I think the first sentence is sort of asking for trouble. the main
<br />
purpose
<br />
of the revision description is to record changes to the "document"
<br />
(or whatever word you want to use for it) as a whole.
<br />

but yes it seems fine.
<br />

we just made this fairly formal within OSS Watch, with
<br />
a more structured <change> and a controlled vocabulary
<br />
for types of change. we'd certainly a <change> if what
<br />
we did was record a change in the licence (which is in
<br />
<availability>)
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Aug 02 2005 - 18:50:30 EDT</span>
</div>

From mjd at hum.ku.dk  Wed Aug  3 07:04:04 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Wed, 03 Aug 2005 13:04:04 +0200
Subject: [tei-council] Report on review of msDesciption chapter
In-Reply-To: <17116.595.844748.107987@emt.wwp.brown.edu>
Message-ID: <42F0C0C4.11824.EAC3F9@localhost>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: M. J. Driscoll <mjd_at_hum.ku.dk>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 03 Aug 2005 13:04:04 +0200</span><br />
</address>

My fellow astronauts,
<br />

I should like to draw your collective attention to the fact 
<br />
that I have now posted my report on the comments submitted 
<br />
to me on the new chapter on manuscript description. It is 
<br />
available for your perusal at:
<br />
http://www.tei-c.org/Activities/MS/msw04.xml
<br />

I should be very grateful to receive comments, especially 
<br />
pertaining to the points I list as those on which action 
<br />
might be taken (I stress the "might"; if I receive no 
<br />
feedback it is unlikely that any action will be taken).
<br />

all the best,
<br />
Matthew
<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 Aug 03 2005 - 07:04:18 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Mon Aug  8 08:16:13 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 08 Aug 2005 13:16:13 +0100
Subject: [tei-council] Re: [Fwd: odd class meeting]
In-Reply-To: <42F74ADE.2080609@oucs.ox.ac.uk>
Message-ID: <42F74D0D.10507@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, 08 Aug 2005 13:16:13 +0100</span><br />
</address>

Forwarded on behalf of SPQR:
<br />

Sebastian Rahtz wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Those of you coming to Oxford on September 26 and 27 might like to think
</em><br />
<em class="quotelev1">>of booking travel etc. If I am to book hotel rooms for you, please let
</em><br />
<em class="quotelev1">>me know dates. I am assuming I am to book a nice (inasmuch as it can be nice in
</em><br />
<em class="quotelev1">>England) dinner on 26th....
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I will bring the now-traditional slugs.
<br />
_______________________________________________
<br />
tei-council mailing list
<br />
tei-council_at_lists.village.Virginia.EDU
<br />
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
<br />
<span id="received"><dfn>Received on</dfn> Mon Aug 08 2005 - 08:22:11 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Mon Aug  8 11:16:05 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 08 Aug 2005 16:16:05 +0100
Subject: [tei-council] comments on edw90
Message-ID: <42F77735.1000204@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, 08 Aug 2005 16:16:05 +0100</span><br />
</address>

Here are some (rather belated) comments on some substantive issues 
<br />
raised by Syd's paper EDW90.
<br />

1. Syd's "Challenges"
<br />

1.1 The TYPE attribute.
<br />

Sebastian and I have done some testing of the feasibility of doing local 
<br />
over-rides as described here. Our conclusions are that this is not 
<br />
possible on technical grounds, and probably less good an idea than we 
<br />
initially thought in any case. What after all does it mean to say that 
<br />
"being typed" is a class? Is there any semantic one can associate with 
<br />
that which is *not* immediately over-ridden by the specific typology 
<br />
defined locally? (If there is, then maybe that would indicate that some 
<br />
class other than "typed" is appropriate).
<br />

Our recommendation is that
<br />
- the tei.typed class should be removed
<br />
- elements bearing a type attribute (and former members of the typed 
<br />
class) should be checked to see whether their valLists constitute an 
<br />
open or closed list
<br />
- for closed list, the datatype will be an alternation of the possible 
<br />
values
<br />
- for open (or semi) lists, the datatype will be tei.enumerated, i.e. a 
<br />
single token not containing whitespace
<br />

1.2 Over-riding of attributes
<br />

I think we can actually make explicit some of what Syd is describing 
<br />
here by using the RelaxNG method of defining facets. So we could for 
<br />
example say that a datatype was basically a positive integer, but with 
<br />
the added constraint that it has a value less than 43 by a construct such as
<br />

      <datatype>
<br />
          <rng:data type="nonNegativeInteger">
<br />
            <rng:param name="maxInclusive">42</rng:param>
<br />
          </rng:data>
<br />
        </datatype>
<br />

If (and only if) there is a 1:1 mapping between a TEI datatype and an 
<br />
RNHG datatype we could presumably also do
<br />

  <datatype>
<br />
          <rng:data>
<br />
           <rng:ref name="tei.nonNegativeInteger">
<br />
            <rng:param name="maxInclusive">42</rng:param>
<br />
          </rng:data>
<br />
   </datatype>
<br />

but it's not clear what this would mean for TEI datatypes which mapped 
<br />
to more than one RNG datatype or an expression
<br />

In the general case, however, we think that all datatype definitions 
<br />
should be complete and appropriate. In practice, we think the vast 
<br />
majority of TEI attributes are already catered for by a very small 
<br />
number of datatypes. (of the 500+ attributes listed by Syd, about 400 
<br />
are covered by derivations of tei.data.token, tei.data.pointer and 
<br />
tei.data.uboolean)
<br />

<p>We conclude that
<br />

- datatypes should be expressed as <rng:data> expressions
<br />
- for commonly occurring cases (see below) we should define a small 
<br />
number of macros, which will be named in the way Syd proposes for datatypes
<br />
- it should be possible to map all datatypes to W3C basic datatypes, 
<br />
possibly with additional constraints
<br />

<p>1.3 constraints
<br />

The TEI has always proposed additional constraints in remarks, valDesc, 
<br />
and descriptive prose. We think we should use the Schematron language to 
<br />
express some of these: the primary use case being constraints on 
<br />
acceptable GIs as targets for various pointing attributes.
<br />

We are not sure where these constraints go in ODD-world, but probably 
<br />
not in the <datatype>. We recommend using Schematron for them because 
<br />
(a) we know it does the job (b) it is a candidate ISO recommendation.
<br />

<p>2. Syd's comments on tokenization
<br />

I think anything we can do to reduce the complications consequent on the 
<br />
whitespace rules of XML is an unalloyed Good Thing, and propose to be 
<br />
even more draconian than Syd suggests. My suggestion is that we allow 
<br />
only token, nmtoken, and tei.data.token. While sympathising with the 
<br />
motivation for it, I feel that the distinction Syd proposes between 
<br />
"tei.data.string" and "tei.data.tokens" will only confuse people. If the 
<br />
value of a sequence of tokens is to be interpreted as a single string, 
<br />
then it probably shouldn't be an attribute at all. (That said, there's a 
<br />
strong case to be made for using "tei.data.tokens" as its name!)
<br />

<p>3. Proposed datatypes
<br />

These I like:
<br />
tei.data.token, tei.data.tokens, tei.data.pointer, tei.data.pointers
<br />

Constraining tei.data.token/s further as NMTOKEN/S/NCName/QNAME etc. is 
<br />
possible, but I am not sure how many elements would benefit from it
<br />

<p>Names I would prefer:
<br />
for tei.data.uboolean -> tei.data.truthValue
<br />

Names I'm not sure about
<br />
tei.data.temporalExpression: how does this map to ISO 8601?
<br />
(I assume it doesn't include dateRanges, for example)
<br />

tei.data.duration
<br />
  We should adopt a consistent policy as to whether quantities like this 
<br />
include their units, or whether the units are supplied as a separate 
<br />
attribute. I think I prefer the second option, as being more flexible.
<br />

tei.data.probability
<br />
  Not convinced we need this. There are very few candidates in the EDW90 
<br />
table (I find 1, to be exact!)
<br />

tei.data.numeric
<br />
  I'm now coming round to the view that we also need a tei.data.integer
<br />

tei.data.language
<br />
  I agree that we need to document exactly what this means somewhere and 
<br />
providing a TEI name for it is a good way of doing so.
<br />

tei.data.code and tei.data.key
<br />

   I have a different understanding of these.
<br />

Syd defines tei.data.code as a version of tei.data.pointer, with the 
<br />
extra constraint that the target must be in the present document. I am 
<br />
not sure what benefit there might be to adding this constraint.
<br />

More seriously, however, tei.data.key is defined as its complement, i.e. 
<br />
a tei.data.pointer with the constraint that its target must *not* be in 
<br />
the current document. I am even less clear what benefit there is in 
<br />
that, and find the naming rather confusing, since we are currently using 
<br />
"key=" attributes for things which are explicitly not pointers and which 
<br />
might even be in the same document (e.g. in TD)
<br />

I think we should stick to tei.data.pointer (by all means add 
<br />
tei.data.pointer.local, if need be) for the URI case, and keep 
<br />
tei.data.code (or key) for use when all we can say of the attribute is 
<br />
that its value is a magic token which might get you somewhere in some 
<br />
external system, e.g. a database key, but which cannot be validated. It 
<br />
might also be useful for cases where an association is made by 
<br />
co-reference, as with the ident/key pair in TD, or in whatever variety 
<br />
of HORSE we finally decide to back.
<br />

<p>That's probably enough to be going on with for the moment...
<br />

<p>Lou
<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> Mon Aug 08 2005 - 11:12:53 EDT</span>
</div>

From jawalsh at indiana.edu  Tue Aug  9 11:39:12 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Tue, 9 Aug 2005 10:39:12 -0500
Subject: [tei-council] Re: [Fwd: odd class meeting]
In-Reply-To: <42F74D0D.10507@computing-services.oxford.ac.uk>
Message-ID: <A4742D50-DBBD-4B21-B951-65A1A72A5F3A@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, 9 Aug 2005 10:39:12 -0500</span><br />
</address>

Have we decided on the final group for this meeting?
<br />

John
<br />
| John A. Walsh, Associate Director for Projects and Services
<br />
| Digital Library Program / Indiana University Libraries
<br />
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
<br />
| Voice:812-855-8758 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu>
<br />

On Aug 8, 2005, at 7:16 AM, Lou Burnard wrote:
<br />

<em class="quotelev1">> Forwarded on behalf of SPQR:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Sebastian Rahtz wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> Those of you coming to Oxford on September 26 and 27 might like to  
</em><br />
<em class="quotelev2">>> think
</em><br />
<em class="quotelev2">>> of booking travel etc. If I am to book hotel rooms for you, please  
</em><br />
<em class="quotelev2">>> let
</em><br />
<em class="quotelev2">>> me know dates. I am assuming I am to book a nice (inasmuch as it  
</em><br />
<em class="quotelev2">>> can be nice in
</em><br />
<em class="quotelev2">>> England) dinner on 26th....
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> I will bring the now-traditional slugs.
</em><br />
<em class="quotelev1">> _______________________________________________
</em><br />
<em class="quotelev1">> tei-council mailing list
</em><br />
<em class="quotelev1">> tei-council_at_lists.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> Tue Aug 09 2005 - 11:39:16 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Aug 10 21:36:46 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 11 Aug 2005 10:36:46 +0900
Subject: [tei-council] Next conference call
In-Reply-To: <42EE99D1.6020407@computing-services.oxford.ac.uk>
Message-ID: <ygfiryd1cgh.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 11 Aug 2005 10:36:46 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Friday 9th September is what the Meetomatic oracle declares. of the 7
</em><br />
<em class="quotelev1">> people who filled in the form,
</em><br />
<em class="quotelev1">> we'd get 6 on that date. Lets do it then.
</em><br />
<em class="quotelev1">>
</em><br />

Then it looks like I was the one who could not make it :-(.  
<br />

I will try to make it possible to catch a phone that night, but I will
<br />
be very busy the whole week with little time for the preparations of
<br />
the meeting.
<br />

The next conference call of the TEI council will then be on 2005-09-09
<br />
at 1300 UTC.  I hope we can have a dual-media (multimedia?) call,
<br />
using the voice phone and IRC chat in parallel.  For those who need
<br />
instructions to do IRC, please post your questions here well before
<br />
the call.  There is also always the opportunity to meet some of the
<br />
Oxford folks at the freenode hangout.
<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> Wed Aug 10 2005 - 21:36:51 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Aug 10 21:43:52 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 11 Aug 2005 10:43:52 +0900
Subject: [tei-council] Re: [Fwd: odd class meeting]
In-Reply-To: <42F74D0D.10507@computing-services.oxford.ac.uk>
Message-ID: <ygfek911c4n.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 11 Aug 2005 10:43:52 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Forwarded on behalf of SPQR:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Sebastian Rahtz wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>Those of you coming to Oxford on September 26 and 27 might like to think
</em><br />
<em class="quotelev2">>>of booking travel etc. If I am to book hotel rooms for you, please let
</em><br />
<em class="quotelev2">>>me know dates. I am assuming I am to book a nice (inasmuch as it can be nice in
</em><br />
<em class="quotelev2">>>England) dinner on 26th....
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> I will bring the now-traditional slugs.
</em><br />

As far as I remember you do not usually have to bring them, they
<br />
should be provided for free.
<br />

And yes, I would appreciate if Sebastian could book a room for me when
<br />
he reemerges online.  I plan to arrive on the 25th and will leave on
<br />
the 29th, so that would be 4 nights.
<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> Wed Aug 10 2005 - 21:43:57 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Aug 10 21:57:10 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 11 Aug 2005 10:57:10 +0900
Subject: [tei-council] comments on edw90
In-Reply-To: <42F77735.1000204@oucs.ox.ac.uk>
Message-ID: <ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 11 Aug 2005 10:57:10 +0900</span><br />
</address>

Thanks for your comments Lou.  It looks like we are actually moving
<br />
forward a lot:-)
<br />

I can't claim to understand everything, but it looks good as you
<br />
present it.  Just some very small quibbles:
<br />

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Our recommendation is that
</em><br />
<em class="quotelev1">> - the tei.typed class should be removed
</em><br />
<em class="quotelev1">> - elements bearing a type attribute (and former members of the typed
</em><br />
<em class="quotelev1">>   class) should be checked to see whether their valLists constitute an
</em><br />
<em class="quotelev1">>   open or closed list
</em><br />
<em class="quotelev1">> - for closed list, the datatype will be an alternation of the possible
</em><br />
<em class="quotelev1">>   values
</em><br />
<em class="quotelev1">> - for open (or semi) lists, the datatype will be tei.enumerated,
</em><br />
<em class="quotelev1">>   i.e. a single token not containing whitespace
</em><br />

I assume what this comes down to is that every element in need of it
<br />
will get a @type directly without the indirection through the class system.<!--nospam-->
<br />

<em class="quotelev1">> We conclude that
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> - datatypes should be expressed as <rng:data> expressions
</em><br />
<em class="quotelev1">> - for commonly occurring cases (see below) we should define a small
</em><br />
<em class="quotelev1">>   number of macros, which will be named in the way Syd proposes for
</em><br />
<em class="quotelev1">>   datatypes
</em><br />
<em class="quotelev1">> - it should be possible to map all datatypes to W3C basic datatypes,
</em><br />
<em class="quotelev1">>   possibly with additional constraints
</em><br />

Does this mean that we deviate from the principle to base our stuff on
<br />
W3C datatypes?  Or does this mean that we get at them through rng:data?
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> We are not sure where these constraints go in ODD-world, but probably
</em><br />
<em class="quotelev1">> not in the <datatype>. We recommend using Schematron for them because
</em><br />
<em class="quotelev1">> (a) we know it does the job (b) it is a candidate ISO recommendation.
</em><br />
<em class="quotelev1">>
</em><br />

That is very nice, but do you actually plan to provide the necessary
<br />
schematrons to do the validation?
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> tei.data.language
</em><br />
<em class="quotelev1">>   I agree that we need to document exactly what this means somewhere
</em><br />
<em class="quotelev1">>   and providing a TEI name for it is a good way of doing so.
</em><br />

Is this something different from xml:lang?  If yes, why do we need it?
<br />

<p>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> Wed Aug 10 2005 - 21:57:15 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Thu Aug 11 05:38:07 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 11 Aug 2005 10:38:07 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <42FB1C7F.2050400@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, 11 Aug 2005 10:38:07 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>Thanks for your comments Lou.  It looks like we are actually moving
</em><br />
<em class="quotelev1">>forward a lot:-)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I can't claim to understand everything, but it looks good as you
</em><br />
<em class="quotelev1">>present it.  Just some very small quibbles:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk> writes:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>Our recommendation is that
</em><br />
<em class="quotelev2">>>- the tei.typed class should be removed
</em><br />
<em class="quotelev2">>>- elements bearing a type attribute (and former members of the typed
</em><br />
<em class="quotelev2">>>  class) should be checked to see whether their valLists constitute an
</em><br />
<em class="quotelev2">>>  open or closed list
</em><br />
<em class="quotelev2">>>- for closed list, the datatype will be an alternation of the possible
</em><br />
<em class="quotelev2">>>  values
</em><br />
<em class="quotelev2">>>- for open (or semi) lists, the datatype will be tei.enumerated,
</em><br />
<em class="quotelev2">>>  i.e. a single token not containing whitespace
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I assume what this comes down to is that every element in need of it
</em><br />
<em class="quotelev1">>will get a @type directly without the indirection through the class system.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

<p>That's the proposal in essence.
<br />

<em class="quotelev2">>>We conclude that
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>- datatypes should be expressed as <rng:data> expressions
</em><br />
<em class="quotelev2">>>- for commonly occurring cases (see below) we should define a small
</em><br />
<em class="quotelev2">>>  number of macros, which will be named in the way Syd proposes for
</em><br />
<em class="quotelev2">>>  datatypes
</em><br />
<em class="quotelev2">>>- it should be possible to map all datatypes to W3C basic datatypes,
</em><br />
<em class="quotelev2">>>  possibly with additional constraints
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Does this mean that we deviate from the principle to base our stuff on
</em><br />
<em class="quotelev1">>W3C datatypes?  Or does this mean that we get at them through rng:data?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
The latter.
<br />

<p><p><em class="quotelev2">>>We are not sure where these constraints go in ODD-world, but probably
</em><br />
<em class="quotelev2">>>not in the <datatype>. We recommend using Schematron for them because
</em><br />
<em class="quotelev2">>>(a) we know it does the job (b) it is a candidate ISO recommendation.
</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">>That is very nice, but do you actually plan to provide the necessary
</em><br />
<em class="quotelev1">>schematrons to do the validation?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

We havent yet decided whether to include  schematron assertions (or 
<br />
whatever they are called) in all such cases, but there should be some if 
<br />
only to demonstrate the concept.
<br />

<p><em class="quotelev2">>>tei.data.language
</em><br />
<em class="quotelev2">>>  I agree that we need to document exactly what this means somewhere
</em><br />
<em class="quotelev2">>>  and providing a TEI name for it is a good way of doing so.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Is this something different from xml:lang?  If yes, why do we need it?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

Good question. I think the general feeling was that it would be helpful 
<br />
to document the use of xml:lang by referring to this datatype, but that 
<br />
may be a mistake.
<br />

<p><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 Aug 11 2005 - 05:44:16 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Thu Aug 11 05:56:22 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 11 Aug 2005 10:56:22 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <42FB1C7F.2050400@computing-services.oxford.ac.uk>
Message-ID: <42FB20C6.3040306@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, 11 Aug 2005 10:56:22 +0100</span><br />
</address>

Lou Burnard wrote:
<br />
<em class="quotelev2">>> Is this something different from xml:lang?  If yes, why do we need it?
</em><br />
<em class="quotelev1">> Good question. I think the general feeling was that it would be helpful 
</em><br />
<em class="quotelev1">> to document the use of xml:lang by referring to this datatype, but that 
</em><br />
<em class="quotelev1">> may be a mistake.
</em><br />

Just to make sure I'm understanding this...would that datatype then be used for 
<br />
validation of @xml:lang's format?  It seems strange to me to be using a 
<br />
tei.datatype to validate and/or document use of a non-TEI element/attribute. 
<br />
Will we be doing the same for xml:id? (or html:object or something?)  I guess I 
<br />
want to know why xml:lang is in need of the documentation when it's format is an 
<br />
external standard?  I think that is at the root of my unease with this (but, as 
<br />
always, I'm willing to be convinced).
<br />

In addition, on reflection, I am not as bothered as I would have thought in 
<br />
regards to the removal of a tei.typed class.
<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 Aug 11 2005 - 05:56:39 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Aug 11 23:06:24 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 12 Aug 2005 12:06:24 +0900
Subject: [tei-council] comments on edw90
In-Reply-To: <42FB20C6.3040306@computing-services.oxford.ac.uk>
Message-ID: <ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 12 Aug 2005 12:06:24 +0900</span><br />
</address>

James Cummings <James.Cummings_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Lou Burnard wrote:
</em><br />
<em class="quotelev3">>>> Is this something different from xml:lang?  If yes, why do we need it?
</em><br />
<em class="quotelev2">>> Good question. I think the general feeling was that it would be
</em><br />
<em class="quotelev2">>> helpful to document the use of xml:lang by referring to this
</em><br />
<em class="quotelev2">>> datatype, but that may be a mistake.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Just to make sure I'm understanding this...would that datatype then be
</em><br />
<em class="quotelev1">> used for validation of @xml:lang's format?  It seems strange to me to
</em><br />
<em class="quotelev1">> be using a tei.datatype to validate and/or document use of a non-TEI
</em><br />
<em class="quotelev1">> element/attribute. 
</em><br />

In fact, the whole point of using xml:lang and xml:id is to get the
<br />
run-of-the-mill validation from generic xml parsers.  And they do make
<br />
sure that the xml:lang is formated according to the spec, which I know
<br />
since I have been bitten by Saxon hundreds of times.  
<br />

As to the documentation aspect, I think we agreed that that is what
<br />
<language> is for and the magic relationship between its @xml:id value
<br />
and the value of @xml:lang on other elements is used to bring them
<br />
together (the socalled Nancy-Hack).
<br />

<p>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 Aug 11 2005 - 23:06:30 EDT</span>
</div>

From sschreib at umd.edu  Fri Aug 12 07:31:57 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Fri, 12 Aug 2005 07:31:57 -0400
Subject: [tei-council] Next conference call
In-Reply-To: <ygfiryd1cgh.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <42FC88AD.3050406@umd.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Susan Schreibman <sschreib_at_umd.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 12 Aug 2005 07:31:57 -0400</span><br />
</address>

Would it make sense then to find another time for the meeting?
<br />

usan
<br />

<p>Christian Wittern wrote:
<br />

<em class="quotelev1">>Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk> writes:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>Friday 9th September is what the Meetomatic oracle declares. of the 7
</em><br />
<em class="quotelev2">>>people who filled in the form,
</em><br />
<em class="quotelev2">>>we'd get 6 on that date. Lets do it then.
</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">>Then it looks like I was the one who could not make it :-(.  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I will try to make it possible to catch a phone that night, but I will
</em><br />
<em class="quotelev1">>be very busy the whole week with little time for the preparations of
</em><br />
<em class="quotelev1">>the meeting.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>The next conference call of the TEI council will then be on 2005-09-09
</em><br />
<em class="quotelev1">>at 1300 UTC.  I hope we can have a dual-media (multimedia?) call,
</em><br />
<em class="quotelev1">>using the voice phone and IRC chat in parallel.  For those who need
</em><br />
<em class="quotelev1">>instructions to do IRC, please post your questions here well before
</em><br />
<em class="quotelev1">>the call.  There is also always the opportunity to meet some of the
</em><br />
<em class="quotelev1">>Oxford folks at the freenode hangout.
</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="quotelev1">>
</em><br />

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742
Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib_at_umd.<!--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 Aug 12 2005 - 07:32:00 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Fri Aug 12 07:38:01 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 12 Aug 2005 12:38:01 +0100
Subject: [tei-council] Next conference call
In-Reply-To: <42FC88AD.3050406@umd.edu>
Message-ID: <42FC8A19.7000605@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, 12 Aug 2005 12:38:01 +0100</span><br />
</address>

Either we do that, or we nominate a deputy chair. A conference call 
<br />
without a chair/ringmaster is not a very enticing prospect
<br />

<p>L
<br />

Susan Schreibman wrote:
<br />
<em class="quotelev1">> Would it make sense then to find another time for the meeting?
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> susan
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Christian Wittern wrote:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>> Sebastian Rahtz <sebastian.rahtz_at_computing-services.oxford.ac.uk> writes:
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev3">>>> Friday 9th September is what the Meetomatic oracle declares. of the 7
</em><br />
<em class="quotelev3">>>> people who filled in the form,
</em><br />
<em class="quotelev3">>>> we'd get 6 on that date. Lets do it then.
</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">>> Then it looks like I was the one who could not make it :-(. 
</em><br />
<em class="quotelev2">>> I will try to make it possible to catch a phone that night, but I will
</em><br />
<em class="quotelev2">>> be very busy the whole week with little time for the preparations of
</em><br />
<em class="quotelev2">>> the meeting.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> The next conference call of the TEI council will then be on 2005-09-09
</em><br />
<em class="quotelev2">>> at 1300 UTC.  I hope we can have a dual-media (multimedia?) call,
</em><br />
<em class="quotelev2">>> using the voice phone and IRC chat in parallel.  For those who need
</em><br />
<em class="quotelev2">>> instructions to do IRC, please post your questions here well before
</em><br />
<em class="quotelev2">>> the call.  There is also always the opportunity to meet some of the
</em><br />
<em class="quotelev2">>> Oxford folks at the freenode hangout.
</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="quotelev2">>>  
</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> Fri Aug 12 2005 - 07:35:08 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Aug 14 19:43:57 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 15 Aug 2005 08:43:57 +0900
Subject: [tei-council] Next conference call
In-Reply-To: <42FC8A19.7000605@oucs.ox.ac.uk>
Message-ID: <ygf1x4wccea.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 15 Aug 2005 08:43:57 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Either we do that, or we nominate a deputy chair. A conference call
</em><br />
<em class="quotelev1">> without a chair/ringmaster is not a very enticing prospect
</em><br />

Well, rather then rescheduling the meeting, I reshuffled some of the
<br />
stuff on my agenda for Friday the 9th and am reasonably confident now
<br />
that I will be able to attend to the call.  After all, its at 10 pm
<br />
local time. 
<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> Sun Aug 14 2005 - 19:44:03 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Aug 23 08:47:44 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 23 Aug 2005 13:47:44 +0100
Subject: [tei-council] agenda for class meeting
Message-ID: <430B1AF0.2060204@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, 23 Aug 2005 13:47:44 +0100</span><br />
</address>

I'd like to hear suggestions, both from attendees and from others, about
<br />

 * agenda items for the TEI Class Meeting
<br />
 * deliverables you expect from the meeting
<br />
 * offers of availability to do work items
<br />
 * lists of prerequisite material you want distributed
<br />
    in advance.
<br />

I am away most of the week before the meeting, so no
<br />
last-minute requests, please!
<br />

I am also away now for 10 days on holiday again (Lake District, thank 
<br />
you for asking, boats and jolly daffodils and things, lots of rain, too 
<br />
many tourists, shall I take Proust to read?),
<br />
so I'd expect to take action on this again on 4th September.
<br />

Sebastian
<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 Aug 23 2005 - 08:48:09 EDT</span>
</div>

From Julia_Flanders at brown.edu  Sun Aug 28 15:49:52 2005
From: Julia_Flanders at brown.edu (Julia Flanders)
Date: Sun, 28 Aug 2005 15:49:52 -0400
Subject: [tei-council] from OASIS
Message-ID: <43121560.7080701@brown.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 28 Aug 2005 15:49:52 -0400</span><br />
</address>

This just came to info_at_tei-c.org; it seems to be something the Council 
<br />
might respond to.
<br />

-------- Original Message --------
<br />
Subject: 	(tr259)
<br />
Date: 	Sun, 28 Aug 2005 12:36:20 -0500 (CDT)
<br />
From: 	Dr. Laurence Leff <D-Leff_at_wiu.<!--nospam-->edu>
<br />
To: 	info_at_tei-c.<!--nospam-->org
<br />

<p><p>THIS IS AN ELECTRONIC COPY OF AN ITEM BEING TO SENT TO
<br />
YOU IN HARDCOPY FORMAT VIA U. S. MAIL AT THE INSIDE ADDRESS BELOW.
<br />
This will insure that you get at least one copy.  More importantly, 
<br />
sending electronic copies of conventional communications should
<br />
eliminate flaming and other problems that have been documented in regards
<br />
to electronic mail.
<br />

<br />
Stipes 447
<br />
Department of Computer Science
<br />
Western Illinois University
<br />
Macomb, IL 61455
<br />

** PAGER: ** 309 367 0787
<br />
** Fax: ** 309 298 2302
<br />

.AM
<br />
Text Encoding Initiative Consortium
<br />
Institute for Advanced Technology in the Humanities
<br />
319 Alderman Library
<br />
P. O. Box 400115
<br />
University of Virginia
<br />
Charlottesville, Virginia 22904-4115
<br />

Dear Sir or Madam:
<br />

The OASIS Legal XML Member Section e-Contracts Technical Committee
<br />
is choosing
<br />
a "host schema" to serve as the basis of the "narrative" part of
<br />
contracts.
<br />

We are, of course, considering Text Encoding Initiative 
<br />
The TC has developed evaluation criteria and evaluated TEI against
<br />
these criteria at:
<br />
http://www.oasis-open.org/committees/download.php/13508/tei.xml.pdf
<br />
http://www.oasis-open.org/committees/download.php/13449/R2.pdf
<br />

We would like the TEI Consortium to add to our information
<br />
for consideration.  We would extend any host schema to include
<br />
markup specific to contracts such as lists of the parties, recitals
<br />
and provision for written signatures.  As you
<br />
may
<br />
know, there was an article in XML Europe 2004 on merging TEI and
<br />
Docbook.  On this basis, I conclude that we could extend TEI for
<br />
the needs of the legal community dealing with contracts.
<br />

Thanks for your interest in our possible extension of your work.
<br />

Sincerely yours,
<br />

<p><p>Laurence L. Leff, Ph.D.
<br />
Associate Professor of Computer Science
<br />
Secretary,
<br />
The OASIS Legal XML Member Section e-Contracts Technical Committee
<br />

cc: info_at_tei-c.<!--nospam-->org
<br />

** P. S. ** Earlier, I sent a similar letter to Dr. Sperberg-McQueen.
<br />
I did not receive a response.  Perhaps, our letter
<br />
or the response was lost in the mail or Dr. Sperberg-McQueen was not the person
<br />
to whom to write.
<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 Aug 28 2005 - 15:49:48 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Aug 28 16:27:53 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 28 Aug 2005 16:27:53 -0400
Subject: [tei-council] from OASIS
In-Reply-To: <43121560.7080701@brown.edu>
Message-ID: <17170.7753.59514.27256@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, 28 Aug 2005 16:27:53 -0400</span><br />
</address>

<em class="quotelev1">> ** P. S. ** Earlier, I sent a similar letter to Dr.
</em><br />
<em class="quotelev1">> Sperberg-McQueen. I did not receive a response. Perhaps, our letter
</em><br />
<em class="quotelev1">> or the response was lost in the mail or Dr. Sperberg-McQueen was
</em><br />
<em class="quotelev1">> not the person to whom to write.
</em><br />

FYI, Michael forwarded the letter to me, and I did respond.
<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 Aug 28 2005 - 16:27:57 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Aug 28 22:30:02 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 28 Aug 2005 22:30:02 -0400
Subject: [tei-council] from OASIS
In-Reply-To: <17170.7753.59514.27256@emt.wwp.brown.edu>
Message-ID: <17170.29482.680194.485047@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, 28 Aug 2005 22:30:02 -0400</span><br />
</address>

<em class="quotelev1">> FYI, Michael forwarded the letter to me, and I did respond.
</em><br />

Well, I seem to be mis-remembering something here. I can find no
<br />
record whatsoever of my having received the forward from MSMcQ nor of
<br />
sending a reply to this gentleman. On the other hand, I remember the
<br />
question, and I remember starting to write a reply.
<br />

As best I can piece together from my uselessly hot brain right now
<br />
(while it's only 25 degees C here, the humidity is 90%), Michael told
<br />
me about the e-mail he received during a phone conversation earlier
<br />
this month. He said he'd forward it to me. I started to write a
<br />
reply, but apparently never finished it nor sent it for lack of
<br />
details and the e-mail address to which to send it, then failed to
<br />
follow up with Michael to actually get it from him.
<br />

Since I dropped the ball on this one I will volunteer to take it upon
<br />
myself to read and respond to their evaluation documents. This is a
<br />
significant task, though, so if anyone wants to take it on or
<br />
volunteer to help, speak up.
<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 Aug 28 2005 - 22:30:08 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Mon Aug 29 08:53:40 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 29 Aug 2005 13:53:40 +0100
Subject: [tei-council] from OASIS
In-Reply-To: <17170.29482.680194.485047@emt.wwp.brown.edu>
Message-ID: <43130554.7000400@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, 29 Aug 2005 13:53:40 +0100</span><br />
</address>

I think the appropriate person to respond to this enquiry would be 
<br />
Christian, as head of the Council. I am very happy to answer any queries 
<br />
they may have about interoperating with TEI. Since they are looking at 
<br />
legal materials, it's possible that Nick Finke might also be a good 
<br />
person to involve.
<br />

I don't think "reading and evaluating" their documents should be given a 
<br />
higher priority than editorial work on P5 which continues to be 
<br />
distressingly late.
<br />

<p>Syd Bauman wrote:
<br />

<em class="quotelev2">>>FYI, Michael forwarded the letter to me, and I did respond.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Well, I seem to be mis-remembering something here. I can find no
</em><br />
<em class="quotelev1">>record whatsoever of my having received the forward from MSMcQ nor of
</em><br />
<em class="quotelev1">>sending a reply to this gentleman. On the other hand, I remember the
</em><br />
<em class="quotelev1">>question, and I remember starting to write a reply.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>As best I can piece together from my uselessly hot brain right now
</em><br />
<em class="quotelev1">>(while it's only 25 degees C here, the humidity is 90%), Michael told
</em><br />
<em class="quotelev1">>me about the e-mail he received during a phone conversation earlier
</em><br />
<em class="quotelev1">>this month. He said he'd forward it to me. I started to write a
</em><br />
<em class="quotelev1">>reply, but apparently never finished it nor sent it for lack of
</em><br />
<em class="quotelev1">>details and the e-mail address to which to send it, then failed to
</em><br />
<em class="quotelev1">>follow up with Michael to actually get it from him.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Since I dropped the ball on this one I will volunteer to take it upon
</em><br />
<em class="quotelev1">>myself to read and respond to their evaluation documents. This is a
</em><br />
<em class="quotelev1">>significant task, though, so if anyone wants to take it on or
</em><br />
<em class="quotelev1">>volunteer to help, speak up.
</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.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">>  
</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 Aug 29 2005 - 08:50:46 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Mon Aug 29 09:43:45 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 29 Aug 2005 09:43:45 -0400
Subject: [tei-council] from OASIS
In-Reply-To: <43130554.7000400@computing-services.oxford.ac.uk>
Message-ID: <17171.4369.669728.249280@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, 29 Aug 2005 09:43:45 -0400</span><br />
</address>

<em class="quotelev1">> I think the appropriate person to respond to this enquiry would be
</em><br />
<em class="quotelev1">> Christian, as head of the Council. I am very happy to answer any
</em><br />
<em class="quotelev1">> queries they may have about interoperating with TEI. Since they are
</em><br />
<em class="quotelev1">> looking at legal materials, it's possible that Nick Finke might
</em><br />
<em class="quotelev1">> also be a good person to involve.
</em><br />

Yes, I also had thought about consulting Nick. If Christian is
<br />
willing, I think that would be great.
<br />

<p><em class="quotelev1">> I don't think "reading and evaluating" their documents should be
</em><br />
<em class="quotelev1">> given a higher priority than editorial work on P5 which continues
</em><br />
<em class="quotelev1">> to be distressingly late.
</em><br />

Have you taken a look at their document? I may be mis-remembering,
<br />
but it seemed there were several misconceptions which we would do
<br />
well to address.
<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 Aug 29 2005 - 09:43:53 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Aug 29 21:42:35 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 30 Aug 2005 10:42:35 +0900
Subject: [tei-council] from OASIS
In-Reply-To: <43130554.7000400@computing-services.oxford.ac.uk>
Message-ID: <ygffyss19pw.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 30 Aug 2005 10:42:35 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> I think the appropriate person to respond to this enquiry would be
</em><br />
<em class="quotelev1">> Christian, as head of the Council. I am very happy to answer any
</em><br />
<em class="quotelev1">> queries they may have about interoperating with TEI. Since they are
</em><br />
<em class="quotelev1">> looking at legal materials, it's possible that Nick Finke might also
</em><br />
<em class="quotelev1">> be a good person to involve.
</em><br />

Their documents provides an interesting case study of how the TEI is
<br />
perceived from the outside and is as such quite interesting.  At this
<br />
moment, I lack the time for working on a detailed reply.  I would
<br />
suggest that we (Lou?) contact Nick Finke and see if he is willing to
<br />
draft a reply, which we then could discuss and use as a base to send
<br />
out as "The Councils Reply", which I am willing to prepair.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I don't think "reading and evaluating" their documents should be given
</em><br />
<em class="quotelev1">> a higher priority than editorial work on P5 which continues to be
</em><br />
<em class="quotelev1">> distressingly late.
</em><br />
<em class="quotelev1">>
</em><br />

Hear, hear.  We are making good process however and will hopefully
<br />
continue during the crucial period of the next month.
<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 Aug 29 2005 - 21:42:40 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Aug 30 12:21:43 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 30 Aug 2005 12:21:43 -0400
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42EFF815.8030005@computing-services.oxford.ac.uk>
Message-ID: <17172.34711.545137.680567@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, 30 Aug 2005 12:21:43 -0400</span><br />
</address>

<em class="quotelev1">> 1. Drop the following attributes on teiHeader: ... I have followed
</em><br />
<em class="quotelev1">> this advice, and now removed all attributes from the TEI Header
</em><br />
<em class="quotelev1">> (other than type). [i.e., creator=, status=, date.created=,
</em><br />
<em class="quotelev1">> date.updated= have been removed]
</em><br />

As no one screamed for a resp= on <teiHeader>, I think this is fine.
<br />

<p><em class="quotelev1">> I have also added the following text to chapter HD:
</em><br />

As modified (what's in P5 has been updated per Sebastian's
<br />
suggestion), this looks fine to me, too. 
<br />

<p><em class="quotelev1">> 2. Drop the wscale attribute on <alt> and <altGrp> (presumably
</em><br />
<em class="quotelev1">> because the weight attribute should contain a quantity and a scale
</em><br />
<em class="quotelev1">> as a single value -- but this is not explicit in Syd's table)
</em><br />

How embarrassing. The note says "see weight= of <alt>", but there is
<br />
no entry for weight= of <alt>, as it's the "weights=" attribute of
<br />
<alt>. Besides, there's not much really helpful there, so I'll
<br />
explain here, then make a quick update to the database.
<br />

wScale= serves no purpose in P4 but to differentiate whether the
<br />
values in the weights= attribute range from 0 to 1 or 0 to 100. Even
<br />
though a value of "75" is unambiguously 75%, a value between 0 and 1
<br />
(inclusive) is ambiguous unless wScale= is specified. Thus,
<br />
   <alt wScale="real" weights="0 0.5 1"/>
<br />
represents odds of 0 (0%), 0.5 (50%), and 1 (100%), whereas
<br />
   <alt wScale="perc" weights="0 0.5 1"/>
<br />
represents odds of 0 (0%), 0.005 (0.5%), and 0.01 (1%).
<br />

However, the suggested datatype for P5 (tei.datatype.probability)
<br />
deliberately permits a percent sign in the value itself to perform
<br />
this disambiguation. Thus the first example above would be expressed
<br />
as either
<br />
   <alt weights="0 0.5 1"/>   or      <alt weights="0% 50% 100%"/>
<br />

<p><em class="quotelev1">> This seems reasonable in itself. On the other hand <alt> is a
</em><br />
<em class="quotelev1">> pretty recondite element which probably needs a lot more thought
</em><br />

Indeed.
<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 Aug 30 2005 - 12:21:48 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Tue Aug 30 12:22:20 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 30 Aug 2005 17:22:20 +0100
Subject: [tei-council] Dates, Ranges, Periods and Durations
Message-ID: <431487BC.3020105@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, 30 Aug 2005 17:22:20 +0100</span><br />
</address>

I've been wondering about the tei.temporalExpr class.
<br />
Currently (on the website at least) it provides a @value of "xsd:date | 
<br />
xsd:gYear | xsd:gMonth | xsd:gDay | xsd:gYearMonth | xsd:gMonthDay | xsd:time | 
<br />
xsd:dateTime" and in prose is decribed as "Any string representing a date in any 
<br />
of the standard formats recommended as W3C schema datatypes."
<br />

This doesn't seem to include xsd:duraton, and duration is catered for in the XML 
<br />
Schema spec. http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#duration
<br />

What I'm wondering about is whether we should be including the full scope of ISO 
<br />
8601 including especially the use of ranges (or 'Time Intervals') and Durations.
<br />

A more readable explanation may be available at 
<br />
http://en.wikipedia.org/wiki/ISO_8601#Time_intervals
<br />

I don't think we cater fully for the ISO spec at the moment.  If we did this 
<br />
would mean that any date @value would be able to express dates, times, intervals 
<br />
or ranges of time, durations or periods, etc.  This isn't to say that we 
<br />
wouldn't need dateRange as a method of indicating certainty/precision with 
<br />
regards to one of the ends of the range.
<br />

Maybe some of this is differences between ISO 8601:2004 and ISO 8601:2001?
<br />

I guess I was just wondering why we weren't seeming to support Durations, 
<br />
Periods, Ranges, in the datatype?  But, knowing me, I've probably just 
<br />
misunderstood something.
<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 Aug 30 2005 - 12:23:02 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Aug 30 15:56:50 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 30 Aug 2005 15:56:50 -0400
Subject: [tei-council] Dates, Ranges, Periods and Durations
In-Reply-To: <431487BC.3020105@computing-services.oxford.ac.uk>
Message-ID: <17172.47618.160836.369233@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, 30 Aug 2005 15:56:50 -0400</span><br />
</address>

I have argued that (ISO 8601) durations should be permitted as the
<br />
value of value= of both <date> and <time> for a long time now, but up
<br />
until now I thought I was alone in this desire. This is why the
<br />
recommendatino in EDW90 for value= of <date> is
<br />
tei.data.temporalExpression, as opposed to 
<br />
    tei.data.temporalExpression | tei.data.duration
<br />
which might make more sense. However, as currently imagined,
<br />
tei.data.duration represents a W3C Schema duration, not an ISO 8601
<br />
duration. There are differences other than simple profiling.
<br />

<p><em class="quotelev1">> What I'm wondering about is whether we should be including the full
</em><br />
<em class="quotelev1">> scope of ISO 8601 including especially the use of ranges (or 'Time
</em><br />
<em class="quotelev1">> Intervals') and Durations.
</em><br />

My inclination is that yes, we should. But of course W3C only
<br />
supports a subset via their XML Schema (part II) datatypes (not to be
<br />
confused with the profile described for discussion puproses in the
<br />
W3C Note on the subject). This shouldn't stop us from supporting
<br />
other expressions, but should give us mild pause -- software that
<br />
supports XSD datatypes will be readily available; software that
<br />
supports other valid 8601 expressions may not be as easy to come by. 
<br />

<p><em class="quotelev1">> Maybe some of this is differences between ISO 8601:2004 and ISO
</em><br />
<em class="quotelev1">> 8601:2001?
</em><br />

I didn't know there was a 2004 version. Thanks for the info.
<br />

<p><em class="quotelev1">> I guess I was just wondering why we weren't seeming to support
</em><br />
<em class="quotelev1">> Durations, Periods, Ranges, in the datatype? But, knowing me, I've
</em><br />
<em class="quotelev1">> probably just misunderstood something.
</em><br />

I think it would be a fine idea. We would need to think pretty
<br />
seriously about where to follow 8601 and where to follow W3C. (E.g.,
<br />
IIRC, W3C does not permit a range indicated by a solidus between two
<br />
expressions, which 8601 does; W3C permits a + or - sign before a
<br />
duration, which 8601 does not.)
<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 Aug 30 2005 - 15:56:54 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Aug 30 21:00:22 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 31 Aug 2005 10:00:22 +0900
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <17172.34711.545137.680567@emt.wwp.brown.edu>
Message-ID: <ygfslwqzzrt.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 31 Aug 2005 10:00:22 +0900</span><br />
</address>

Syd Bauman <Syd_Bauman_at_Brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev2">>> 1. Drop the following attributes on teiHeader: ... I have followed
</em><br />
<em class="quotelev2">>> this advice, and now removed all attributes from the TEI Header
</em><br />
<em class="quotelev2">>> (other than type). [i.e., creator=, status=, date.created=,
</em><br />
<em class="quotelev2">>> date.updated= have been removed]
</em><br />

Now thinking of this again, for what purpose would you need @type on
<br />
teiHeader?
<br />

<em class="quotelev1">> As no one screamed for a resp= on <teiHeader>, I think this is fine.
</em><br />

With me too.
<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> Tue Aug 30 2005 - 21:00:26 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Aug 31 04:14:17 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 31 Aug 2005 17:14:17 +0900
Subject: [tei-council] Upcoming teleconference Friday 2005-09-09 at 1300 UTC
Message-ID: <ygf1x4azfom.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 31 Aug 2005 17:14:17 +0900</span><br />
</address>

Dear Council members,
<br />

As you will remember, our next conference call is scheduled for Friday
<br />
of this coming week, a mere 9 days away.  Please catch up with what
<br />
you planned to do by that time, have a look at EDW 90, and in general
<br />
do the usual preparations that are necessary before such an event.  
<br />

If there is something you would like to see on the agenda, please do
<br />
write to this list (preferably) or to me privately.   As I mentioned,
<br />
I will be very busy all the way up to the conference, but I hope to be
<br />
able to process requests as necessary. 
<br />

As Sebastian suggested, we would like to have a second communication
<br />
channel open via IRC Chat at the time of the conference.  James, are
<br />
you taking care of this?  Could you please post instructions on how to
<br />
get connected etc. 
<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> Wed Aug 31 2005 - 04:14:22 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Wed Aug 31 04:49:35 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 31 Aug 2005 09:49:35 +0100
Subject: [tei-council] Upcoming teleconference Friday 2005-09-09 at 1300 UTC
In-Reply-To: <ygf1x4azfom.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43156F1F.3050203@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, 31 Aug 2005 09:49:35 +0100</span><br />
</address>

Christian Wittern wrote:
<br />
<em class="quotelev1">> As Sebastian suggested, we would like to have a second communication
</em><br />
<em class="quotelev1">> channel open via IRC Chat at the time of the conference.  James, are
</em><br />
<em class="quotelev1">> you taking care of this?  Could you please post instructions on how to
</em><br />
<em class="quotelev1">> get connected etc. 
</em><br />

Since there is only one non-council member hanging around occasionally in the 
<br />
public TEI Consortium IRC channel, does anyone have any objections to using 
<br />
that?  (If so, we can create a #tei-council private channel.)
<br />

If there are no objections, you may also be interested in the wiki page I have 
<br />
created which contains the information necessary to connect.
<br />

http://www.tei-c.org.uk/wiki/index.php/IRC
<br />

However, the information on specific clients is limited, so do feel free to add 
<br />
more detail!
<br />

Basically, in almost any IRC client, set the server to be irc.freenode.net
<br />
and the channel to be #tei-c and you should be fine.  In some clients this is 
<br />
done through setting up an account in various graphical manners, in others you 
<br />
might use /connect serverName or /server serverName and then /join #tei-c 
<br />
Alternatively, if you have the Chatzilla extension installed, in the address bar 
<br />
of firefox you can use this url: irc://irc.freenode.net/tei-c to connect.  My 
<br />
preferred client is gaim because it is multi-protocol (does yahoo, aim/aol, msn, 
<br />
jabber, gmail, chat protocols amongst others).
<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 Aug 31 2005 - 04:50:21 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Wed Aug 31 16:49:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 31 Aug 2005 16:49:11 -0400 (EDT)
Subject: [tei-council] comments on edw90
In-Reply-To: <ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <200508312049.j7VKnBia028939@cepheus.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, 31 Aug 2005 16:49:11 -0400 (EDT)</span><br />
</address>

<em class="quotelev1">> Sebastian and I have done some testing of the feasibility of doing
</em><br />
<em class="quotelev1">> local over-rides as described here. Our conclusions are that this
</em><br />
<em class="quotelev1">> is not possible on technical grounds,
</em><br />

This is quite a shame, as such a capability could provide the means
<br />
for significant simplification of the TEI scheme, and much of the work
<br />
put into ED W 90 was predicated on this possibility. Such is life.
<br />

<p><em class="quotelev1">> Our recommendation is that
</em><br />
<em class="quotelev1">> - the tei.typed class should be removed
</em><br />
<em class="quotelev1">> - elements bearing a type attribute (and former members of the
</em><br />
<em class="quotelev1">>   typed class) should be checked to see whether their valLists
</em><br />
<em class="quotelev1">>   constitute an open or closed list
</em><br />
<em class="quotelev1">> - for closed list, the datatype will be an alternation of the
</em><br />
<em class="quotelev1">>   possible values
</em><br />

I presume you mean "set of permissible values" or some such, not
<br />
"datatype". (Up until now we've been using the term "datatype" to
<br />
express an abstract grouping of values with similar syntactic
<br />
constraints and similar semantics, presumably implemented by some form
<br />
of indirection. However, there is the potential for lots of confusion,
<br />
because the child of <attDef> which is used to abstractly declare the
<br />
attribute type is called <datatype>. This is quite unfortunate a
<br />
situation, for which I must take the blame -- Sebastian specifically
<br />
asked me if any of the names he chose for these elements were
<br />
problematic before he cemented them into our processing chain, and I
<br />
missed this obvious thorn.)
<br />

<em class="quotelev1">> - for open (or semi) lists, the datatype will be tei.enumerated,
</em><br />
<em class="quotelev1">>   i.e. a single token not containing whitespace
</em><br />

I'm confused. What then is the difference between tei.data.enumerated
<br />
and tei.data.token?
<br />

In some ways this may feel like a big step backwards, as it is
<br />
essentially the system we were using before Paris. But I think this
<br />
works almost as well as the system Council sketched out in Paris. If
<br />
a TEI-schema-designer wants to restrict users to the values provided
<br />
in an open (or semi) list, all she needs to do is change the type of
<br />
<valList> from "open" to "closed". (Hmmm... I just realized that this
<br />
is actually currently not true. I think she'd have to copy-and-paste
<br />
the entire <valList> from the tagdoc into her ODD, which isn't nearly
<br />
as nice. Sebastian, could we arrange the process so that just
<br />
specifying, e.g.
<br />
          <elementSpec module="core" ident="note" mode="change">
<br />
            <attList>
<br />
              <attDef ident="place">
<br />
                <valList type="closed"/>
<br />
              </attDef>
<br />
            </attList>
<br />
          </elementSpec>
<br />
would work? It's not ambiguous that the user is trying to remove all
<br />
the possible values, because it makes no sense to have an empty
<br />
<valList>, especially if the type is "closed"; of course it also
<br />
isn't valid ala the current TD.)
<br />

<p><em class="quotelev1">> 1.2 Over-riding of attributes
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I think we can actually make explicit some of what Syd is
</em><br />
<em class="quotelev1">> describing here by using the RelaxNG method of defining facets. So
</em><br />
<em class="quotelev1">> we could for example say that a datatype was basically a positive
</em><br />
<em class="quotelev1">> integer, but with the added constraint that it has a value less
</em><br />
<em class="quotelev1">> than 43 by a construct such as
</em><br />
<em class="quotelev1">>     <datatype>
</em><br />
<em class="quotelev1">>       <rng:data type="nonNegativeInteger">
</em><br />
<em class="quotelev1">>         <rng:param name="maxInclusive">42</rng:param>
</em><br />
<em class="quotelev1">>       </rng:data>
</em><br />
<em class="quotelev1">>     </datatype>
</em><br />

Yes, I think this is doable, but it really only addresses a small
<br />
subset of what I think we set forth in Paris to do. (And note that
<br />
quite a few of the proposed datatypes make use of this.) In
<br />
particular, since the restriction is a facet, we can't use this
<br />
feature to have one TEI datatype for numeric representations
<br />
(tei.data.numeric), and say "this attribute is one of
<br />
tei.data.numeric, but must be a non-negative integer".
<br />

<p><em class="quotelev1">> If (and only if) there is a 1:1 mapping between a TEI datatype and
</em><br />
<em class="quotelev1">> [a W3C Schema] datatype we could presumably also do
</em><br />
<em class="quotelev1">>    <datatype>
</em><br />
<em class="quotelev1">>      <rng:data>
</em><br />
<em class="quotelev1">>        <rng:ref name="tei.nonNegativeInteger">
</em><br />
<em class="quotelev1">>        <rng:param name="maxInclusive">42</rng:param>
</em><br />
<em class="quotelev1">>      </rng:data>
</em><br />
<em class="quotelev1">>    </datatype>
</em><br />

I tried a quick test, and both nxml-mode and trang objected to such a
<br />
schema.
<br />

<p><em class="quotelev1">> In the general case, however, we think that all datatype definitions
</em><br />
<em class="quotelev1">> should be complete and appropriate. In practice, we think the vast
</em><br />
<em class="quotelev1">> majority of TEI attributes are already catered for by a very small
</em><br />
<em class="quotelev1">> number of datatypes. (of the 500+ attributes listed by Syd, about
</em><br />
<em class="quotelev1">> 400 are covered by derivations of tei.data.token, tei.data.pointer
</em><br />
<em class="quotelev1">> and tei.data.uboolean)
</em><br />

I'm not exactly sure what you mean by "derivations" here, but if it's
<br />
the adding restrictions to a generic datatype that we can't do, it
<br />
means we have a problem for lots of those attributes, no?
<br />

<p><em class="quotelev1">> We conclude that
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> - datatypes should be expressed as <rng:data> expressions
</em><br />

I'm not sure I see why we want to impose such a restriction. E.g., for
<br />
the TEI sex datatype, why would we prefer
<br />

     <rng:data>
<br />
       <rng:param name="pattern">^\s*(f|m|u|x)\s*$</rng:param>
<br />
     </rng:data>
<br />

to either
<br />

    <rng:choice>
<br />
      <rng:value>f</rng:value>
<br />
      <rng:value>m</rng:value>
<br />
      <rng:value>u</rng:value>
<br />
      <rng:value>x</rng:value>
<br />
    </rng:choice>
<br />

or far better
<br />

    <valList type="closed">
<br />
      <val>f</val> <desc>female</desc>
<br />
      <val>m</val> <desc>male</desc>
<br />
      <val>u</val> <desc>unknown or undetermined</desc>
<br />
      <val>x</val> <desc>not applicable or indeterminable</desc>
<br />
    </valList>
<br />

<p><em class="quotelev1">> - for commonly occurring cases (see below) we should define a small 
</em><br />
<em class="quotelev1">>   number of macros, which will be named in the way Syd proposes for
</em><br />
<em class="quotelev1">>   datatypes
</em><br />

I think I may be confused: for commonly occurring cases of what? In the
<br />
previous bullet point did "datatype" mean "the declaration of the
<br />
allowed values of a particular attribute" or "an abstract constraint
<br />
which can be applied to the allowed values of any given attribute"?
<br />

<p><em class="quotelev1">> - it should be possible to map all datatypes to W3C basic datatypes, 
</em><br />
<em class="quotelev1">>   possibly with additional constraints
</em><br />

If I understand this correctly, I don't think there's any immediate
<br />
problem with it. (I'm presuming that anything that is expressed as a
<br />
list of values is something that can be mapped ) I think it is
<br />
probably fine as a goal for the current short-term project.
<br />

However, as a long-term principle I think it is a very bad idea to tie
<br />
TEI to W3C datatypes. While I am far from a computer scientist who has
<br />
studied these issues, it's clear that W3C datatypes leave a lot to be
<br />
desired. It is quite reasonable to expect that other datatype
<br />
libraries will be published (e.g., OASIS DSDL part 5), or that we
<br />
would want to create a datatype library ourselves, perhaps using DTLL
<br />
if & when it becomes fully worked out.
<br />

<p><em class="quotelev1">> The TEI has always proposed additional constraints in remarks,
</em><br />
<em class="quotelev1">> valDesc, and descriptive prose. We think we should use the
</em><br />
<em class="quotelev1">> Schematron language to express some of these: the primary use case
</em><br />
<em class="quotelev1">> being constraints on acceptable GIs as targets for various pointing
</em><br />
<em class="quotelev1">> attributes.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> We are not sure where these constraints go in ODD-world, but
</em><br />
<em class="quotelev1">> probably not in the <datatype>. We recommend using Schematron for
</em><br />
<em class="quotelev1">> them because (a) we know it does the job (b) it is a candidate ISO
</em><br />
<em class="quotelev1">> recommendation.
</em><br />

I agree with all of the above. Although I think perhaps we should
<br />
avoid features of ISO Schematron that are not available in Schematron
<br />
1.x, as processors for the former are hard to come by. (That may
<br />
change by the time this becomes an issue, of course.)
<br />

<p><em class="quotelev1">> I think anything we can do to reduce the complications consequent on
</em><br />
<em class="quotelev1">> the whitespace rules of XML is an unalloyed Good Thing, and propose
</em><br />
<em class="quotelev1">> to be even more draconian than Syd suggests.
</em><br />

Hear hear!
<br />

<p><em class="quotelev1">> My suggestion is that we allow only token, nmtoken, and
</em><br />
<em class="quotelev1">> tei.data.token.
</em><br />

I'm not sure *where* this restriction occurs, since in the next
<br />
paragraph you propose we keep "tei.data.tokens".
<br />

- token: do you mean "rng:token" or "xsd:token"?
<br />

- xsd:NMTOKEN: interesting; where would you want to use it? I have
<br />
               found no good use for this datatype for any of the 541
<br />
               attributes I looked at. In every case that NMTOKEN is
<br />
               currently used, I think we should be using xsd:Name (or
<br />
               perhaps xsd:NCName), except for the 1 oddball case of
<br />
               unit= on <timeline>, which should be an enumerated list
<br />
               or folded into interval=.
<br />

<p><em class="quotelev1">> While sympathising with the motivation for it, I feel that the
</em><br />
<em class="quotelev1">> distinction Syd proposes between "tei.data.string" and
</em><br />
<em class="quotelev1">> "tei.data.tokens" will only confuse people. If the value of a
</em><br />
<em class="quotelev1">> sequence of tokens is to be interpreted as a single string, then it
</em><br />
<em class="quotelev1">> probably shouldn't be an attribute at all.
</em><br />

Really good point. As I said, I'm very back-and-forth on this issue,
<br />
and Lou's argument tips me back. The only attribute that I can think
<br />
of that does not fit the "tei.data.tokens" semantic and should remain
<br />
an attribute is the value= of <metSym>. And since it's a single
<br />
attribute, IMHO it doesn't have to be declared as a "datatype" (i.e.,
<br />
with indirection), and even if Council thinks it does, we could just
<br />
use tei.data.tokens and live with it. (Remember, the validation would
<br />
be exactly the same, it's only that the prose explanation might not
<br />
fit perfectly well. Does anyone use this attribute, anyway?)
<br />

<p><em class="quotelev1">> These I like:
</em><br />
<em class="quotelev1">> tei.data.token, tei.data.tokens, tei.data.pointer, tei.data.pointers
</em><br />

Me too.
<br />

<p><em class="quotelev1">> Constraining tei.data.token/s further as NMTOKEN/S/NCName/QNAME etc. is 
</em><br />
<em class="quotelev1">> possible, but I am not sure how many elements would benefit from it
</em><br />

Between half a dozen and a dozen attributes, I suspect. Most, if not
<br />
all, of which should be xsd:Name. 
<br />

<p><em class="quotelev1">> Names I would prefer:
</em><br />
<em class="quotelev1">> for tei.data.uboolean -> tei.data.truthValue
</em><br />

I *like* it. Unless there are rousing objections, I'll plan to change
<br />
this in EDW90 and the corresponding database later this week.
<br />

<p><em class="quotelev1">> Names I'm not sure about
</em><br />
<em class="quotelev1">> tei.data.temporalExpression: how does this map to ISO 8601?
</em><br />
<em class="quotelev1">> (I assume it doesn't include dateRanges, for example)
</em><br />

Hey, you thought of this name! See separate thread James started for
<br />
ISO 8601 alignment discussion.
<br />

<p><em class="quotelev1">> tei.data.duration
</em><br />
<em class="quotelev1">>   We should adopt a consistent policy as to whether quantities like this 
</em><br />
<em class="quotelev1">> include their units, or whether the units are supplied as a separate 
</em><br />
<em class="quotelev1">> attribute. I think I prefer the second option, as being more
</em><br />
<em class="quotelev1">> flexible.
</em><br />

If we're going to use W3C datatypes, then at least in those cases
<br />
where W3C puts the unit in with the quantity (xsd:duration explicitly,
<br />
and the various date and time formats implicitly) we'd have to do the
<br />
same. 
<br />

<p><em class="quotelev1">> tei.data.probability
</em><br />
<em class="quotelev1">>   Not convinced we need this. There are very few candidates in the
</em><br />
<em class="quotelev1">> EDW90 table (I find 1, to be exact!)
</em><br />

My fault, table had typos. This one is for expressing a range from 0
<br />
to 1 (or 0% to 100% or none to all). Currently only 3 attributes make
<br />
use of it (scope= of <handNote>, usage= of <language>, weights= of
<br />
<alt>). Since (IIRC) Council agreed in Paris that whenever 2 or more
<br />
attributes share the same constraint, a datatype should be abstracted
<br />
out, I did so. (There was even some discussion that there should be a
<br />
datatype even if only 1 attribute has a particular constraint, IIRC.)
<br />

<p><em class="quotelev1">> tei.data.numeric
</em><br />
<em class="quotelev1">>   I'm now coming round to the view that we also need a
</em><br />
<em class="quotelev1">>   tei.data.integer
</em><br />

I'm wondering if the concept of "positive integer or 0" is simple
<br />
enough that we don't need to bother creating a TEI datatype for it,
<br />
and could just use xsd:nonNegativeInteger directly when needed.
<br />

<p><em class="quotelev1">> tei.data.language
</em><br />
<em class="quotelev1">>   I agree that we need to document exactly what this means somewhere and 
</em><br />
<em class="quotelev1">> providing a TEI name for it is a good way of doing so.
</em><br />

JC> Just to make sure I'm understanding this...would that datatype
<br />
JC> then be used for validation of @xml:lang's format? It seems
<br />
JC> strange to me to be using a tei.datatype to validate and/or
<br />
JC> document use of a non-TEI element/attribute.
<br />

I agree with Lou. There are 3 reasons to make a datatype
<br />
(tei.data.language) that maps directly to xsd:language.
<br />

* It occurs more than twice (I'm not sure this is a compelling
<br />
  argument on its own): langKey= & otherLangs= of <textLang>, ident=
<br />
  of <language>, mainLang= of <hand>, and xml:lang= of everything.
<br />

* Although it maps directly to xsd:language, the explanation of
<br />
  xsd:language is both hard to find and hard to read & understand.
<br />
  (Quite unlike the explanation of xsd:nonNegativeInteger, which is
<br />
  easy to find, and not all that hard to read & understand -- besides,
<br />
  it's obvious enough that almost no one bothers.)
<br />

* As Christian pointed out, it would be nice to have someplace in the
<br />
  reference documentation to plunk the explanation of how xml:lang= is
<br />
  related to ident= of <language>.
<br />

<p>I will post a reply on tei.data.code and tei.data.key issue separately.
<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 Aug 31 2005 - 16:49:15 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Wed Aug 31 17:56:40 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 31 Aug 2005 22:56:40 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <ygfslwqzzrt.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43162798.3020708@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, 31 Aug 2005 22:56:40 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Now thinking of this again, for what purpose would you need @type on
</em><br />
<em class="quotelev1">>teiHeader?
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

It is used (by many) to distinguish a header attached to a teiCorpus 
<br />
from one attached to a text. And you might also need to use it to 
<br />
distinguish an "independent" header, now that we have removed the 
<br />
concept of auxiliary  tagset.  I agree both of these distinctions could 
<br />
be made by other means, but still...
<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 Aug 31 2005 - 17:44:52 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Aug 31 20:45:22 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 01 Sep 2005 09:45:22 +0900
Subject: [tei-council] Upcoming teleconference Friday 2005-09-09 at 1300 UTC
In-Reply-To: <43156F1F.3050203@computing-services.oxford.ac.uk>
Message-ID: <ygfpsrtwr8d.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 01 Sep 2005 09:45:22 +0900</span><br />
</address>

James Cummings <James.Cummings_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Christian Wittern wrote:
</em><br />
<em class="quotelev2">>> As Sebastian suggested, we would like to have a second communication
</em><br />
<em class="quotelev2">>> channel open via IRC Chat at the time of the conference.  James, are
</em><br />
<em class="quotelev2">>> you taking care of this?  Could you please post instructions on how to
</em><br />
<em class="quotelev2">>> get connected etc. 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Since there is only one non-council member hanging around occasionally
</em><br />
<em class="quotelev1">> in the public TEI Consortium IRC channel, does anyone have any
</em><br />
<em class="quotelev1">> objections to using that?  (If so, we can create a #tei-council
</em><br />
<em class="quotelev1">> private channel.)
</em><br />

I'd prefer to have a dedicated channel for the council.  BTW (showing
<br />
my ignorance) is it possible to have a log of the conversation and
<br />
post it for example on the Council pages?
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Basically, in almost any IRC client, set the server to be irc.freenode.net
</em><br />
<em class="quotelev1">> and the channel to be #tei-c and you should be fine.  In some clients
</em><br />
<em class="quotelev1">> this is done through setting up an account in various graphical
</em><br />
<em class="quotelev1">> manners, in others you might use /connect serverName or /server
</em><br />
<em class="quotelev1">> serverName and then /join #tei-c 
</em><br />
<em class="quotelev1">> Alternatively, if you have the Chatzilla extension installed, in the
</em><br />
<em class="quotelev1">> address bar of firefox you can use this url:
</em><br />
<em class="quotelev1">> irc://irc.freenode.net/tei-c to connect.  
</em><br />

Last time I tried this, I realized that I forgot to ask how do
<br />
disconnect, so my alter ego was hanging around there until the whole
<br />
firefox went belly up...
<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> Wed Aug 31 2005 - 20:45:27 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Thu Sep  1 09:32:10 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 1 Sep 2005 09:32:10 -0400 (EDT)
Subject: [tei-council] comments on edw90
In-Reply-To: <ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <200509011332.j81DWAtv024950@ursa.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>: Thu, 1 Sep 2005 09:32:10 -0400 (EDT)</span><br />
</address>

<em class="quotelev1">> tei.data.code and tei.data.key
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">>    I have a different understanding of these.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Syd defines tei.data.code as a version of tei.data.pointer, with the
</em><br />
<em class="quotelev1">> extra constraint that the target must be in the present document. I
</em><br />
<em class="quotelev1">> am not sure what benefit there might be to adding this constraint.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> More seriously, however, tei.data.key is defined as its complement,
</em><br />
<em class="quotelev1">> i.e. a tei.data.pointer with the constraint that its target must
</em><br />
<em class="quotelev1">> *not* be in the current document. I am even less clear what benefit
</em><br />
<em class="quotelev1">> there is in that, and find the naming rather confusing, since we are
</em><br />
<em class="quotelev1">> currently using "key=" attributes for things which are explicitly
</em><br />
<em class="quotelev1">> not pointers and which might even be in the same document (e.g. in
</em><br />
<em class="quotelev1">> TD)
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I think we should stick to tei.data.pointer (by all means add
</em><br />
<em class="quotelev1">> tei.data.pointer.local, if need be) for the URI case, and keep
</em><br />
<em class="quotelev1">> tei.data.code (or key) for use when all we can say of the attribute
</em><br />
<em class="quotelev1">> is that its value is a magic token which might get you somewhere in
</em><br />
<em class="quotelev1">> some external system, e.g. a database key, but which cannot be
</em><br />
<em class="quotelev1">> validated. It might also be useful for cases where an association is
</em><br />
<em class="quotelev1">> made by co-reference, as with the ident/key pair in TD, or in
</em><br />
<em class="quotelev1">> whatever variety of HORSE we finally decide to back.
</em><br />

P4 provided (at least) 3 ways for an attribute to refer to a
<br />
controlled vocabulary:
<br />

* the value is from a list specified in the DTD (e.g., status= of
<br />
  <availability>)
<br />

* the value is an IDREF to something (which has an id=) specified in
<br />
  the document instance (e.g., who= of <sp> or resp= of <add>)
<br />

* the value is a key into some (ostensibly external, but Lou correctly
<br />
  points out that, especially in the P5 world, it may well be in the
<br />
  document instance) resource (e.g., key= of <name>)
<br />

I am not claiming that this is the only or best way to think of these;
<br />
but I do think these are useful distinctions. It is my (very
<br />
unscientific) observation that users crave the use of IDREF (or its
<br />
modern equivalent) as a mechanism for controlling vocabularies. Even
<br />
those I would think of as "power users" of TEI are sometimes very
<br />
hesitant to change the DTD, and very few want to go to the trouble of
<br />
building a database and creating software that actually uses a TEI key
<br />
to look things up in it. However, users often really want the
<br />
capability to control the values of a particular attribute, and
<br />
occasionally even want to say something about what the values mean.
<br />

There are problems porting this analysis to the P5 world, though. In
<br />
P5, the pointers that replace IDREFs can point anywhere. Even into the
<br />
schema, e.g. Furthermore, in P4 the value of key= was just a key. But
<br />
in the P5 world, it might make sense for the key= to indicate the
<br />
resource as well as the key. E.g., in P4 <name key="929041"> perhaps
<br />
could be <name key="http://my.server.org/name-database?929041"> or
<br />
some such.
<br />

Thus, in EDW90 I suggested three mechanisms for controlling vocabulary.
<br />
* tei.data.enumerated, the control is via a closed <valList> in the
<br />
  ODD which boils down to a token list in the schema
<br />
* tei.data.code (perhaps a bad name), a local pointer (although an
<br />
  argument could be made for making this a generic pointer or for
<br />
  making it an xsd:Name and using co-reference)
<br />
* tei.data.key, for database keys, could be declared as a URI or as an
<br />
  xsd:Name, and I don't claim to know which is better
<br />

Note that, if I understand correctly, the key= of <attRef>,
<br />
<moduleRef>, <specDesc>, and <memberOf> is currently defined as being
<br />
a name, and is tied to being one processing chain. I.e., using a URI
<br />
here would break things.
<br />

As I sit here and think about it, in my pre-breakfast hypoglycemic
<br />
state, I am beginning to lean towards leaving tei.data.key an
<br />
xsd:Name, and telling users who really want to specify the resource as
<br />
well as the key to use xml:base=. E.g. <name key="929041"
<br />
xml:base="http:/my.server.org/name-database">. Is that feasible? I
<br />
don't claim to have thought this through at all.
<br />

<p>One final thought. As mentioned before, in the P5 world as currently
<br />
instantiated, a document can't say to which schema it is supposed to
<br />
conform. So suppose a project has 2 somewhat similar schemas that
<br />
serve different purposes lying around, each of which imposes a closed
<br />
value list on the bar= of <foo>, as follows:
<br />
   A        B
<br />
   ---      -------
<br />
   fee      fee
<br />
   fi       fi
<br />
   fo       fiddlie
<br />
   fum      aye
<br />
            oh
<br />
Now suppose you, the encoder, start working on an instance. Unless
<br />
said instance is already valid against A and invalid against B, you
<br />
have no way of knowing that "fum" is a legal value but "aye" is not.
<br />
Thus I think (or am I worried?) that a validatable method of
<br />
constraining values from within the instance will be even more popular
<br />
in P5 than in P4. I.e., it would be useful to have
<br />
  <definition-of-foo-values>
<br />
    <valList>
<br />
      <valItem ident="fee">
<br />
        <gloss>The file entropy evaluation as reported by blort</gloss>
<br />
      </valItem>
<br />
      <valItem ident="fi">
<br />
        <gloss>The file input, should contain only ASCII characters</gloss>
<br />
      </valItem>
<br />
      </valItem ident="fo">
<br />
   ...
<br />
or some such somewhere in the TEI Header.
<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 Sep 01 2005 - 09:32:16 EDT</span>
</div>

From jawalsh at indiana.edu  Thu Sep  1 09:49:23 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Thu, 1 Sep 2005 08:49:23 -0500
Subject: [tei-council] Conference Call Details
Message-ID: <D0C17509-A7CB-43F1-B88A-D3FD16329396@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, 1 Sep 2005 08:49:23 -0500</span><br />
</address>

Hi all,
<br />

Please see below for conference call details.  I will be traveling  
<br />
during the call and may not be able to call in, though I will do my  
<br />
best to attend.  I have been assured by the telecomm folks here at  
<br />
Indiana that the call will proceed fine whether or not I, as the  
<br />
conference organizer, dial in.
<br />

John
<br />

<p>You have been invited to participate in a Conference Call on 9/9/2005  
<br />
from 7:45:00 AM to 10:15:00 AM Indiana EST. (jawalsh: The actual  
<br />
conference time is 1300 - 1500 UTC, but I've reserved the line for 15  
<br />
extra minutes before and after).
<br />

The Conference Access Information is listed below:
<br />

Conf Id:        2174
<br />
Date:        9/9/2005
<br />
Begin Time:    7:45:00 AM Indiana EST
<br />
End Time:    10:15:00 AM Indiana EST
<br />

Phone Number:    (812) 856-3600
<br />
PIN:        000920#
<br />

This email was automatically generated by the  IU UITS Conference  
<br />
system. Please do not reply to this message.
<br />

For conferencing assistance please call 812-855-4848.
<br />

| John A. Walsh, Associate Director for Projects and Services
<br />
| Digital Library Program / Indiana University Libraries
<br />
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
<br />
| Voice:812-855-8758 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu>
<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 Sep 01 2005 - 09:49:50 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Thu Sep  1 15:35:22 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 01 Sep 2005 20:35:22 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <200509011332.j81DWAtv024950@ursa.services.brown.edu>
Message-ID: <431757FA.3010605@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, 01 Sep 2005 20:35:22 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev2">>>tei.data.code and tei.data.key
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>   I have a different understanding of these.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>Syd defines tei.data.code as a version of tei.data.pointer, with the
</em><br />
<em class="quotelev2">>>extra constraint that the target must be in the present document. I
</em><br />
<em class="quotelev2">>>am not sure what benefit there might be to adding this constraint.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>More seriously, however, tei.data.key is defined as its complement,
</em><br />
<em class="quotelev2">>>i.e. a tei.data.pointer with the constraint that its target must
</em><br />
<em class="quotelev2">>>*not* be in the current document. I am even less clear what benefit
</em><br />
<em class="quotelev2">>>there is in that, and find the naming rather confusing, since we are
</em><br />
<em class="quotelev2">>>currently using "key=" attributes for things which are explicitly
</em><br />
<em class="quotelev2">>>not pointers and which might even be in the same document (e.g. in
</em><br />
<em class="quotelev2">>>TD)
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>I think we should stick to tei.data.pointer (by all means add
</em><br />
<em class="quotelev2">>>tei.data.pointer.local, if need be) for the URI case, and keep
</em><br />
<em class="quotelev2">>>tei.data.code (or key) for use when all we can say of the attribute
</em><br />
<em class="quotelev2">>>is that its value is a magic token which might get you somewhere in
</em><br />
<em class="quotelev2">>>some external system, e.g. a database key, but which cannot be
</em><br />
<em class="quotelev2">>>validated. It might also be useful for cases where an association is
</em><br />
<em class="quotelev2">>>made by co-reference, as with the ident/key pair in TD, or in
</em><br />
<em class="quotelev2">>>whatever variety of HORSE we finally decide to back.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>P4 provided (at least) 3 ways for an attribute to refer to a
</em><br />
<em class="quotelev1">>controlled vocabulary:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>* the value is from a list specified in the DTD (e.g., status= of
</em><br />
<em class="quotelev1">>  <availability>)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>* the value is an IDREF to something (which has an id=) specified in
</em><br />
<em class="quotelev1">>  the document instance (e.g., who= of <sp> or resp= of <add>)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>* the value is a key into some (ostensibly external, but Lou correctly
</em><br />
<em class="quotelev1">>  points out that, especially in the P5 world, it may well be in the
</em><br />
<em class="quotelev1">>  document instance) resource (e.g., key= of <name>)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I am not claiming that this is the only or best way to think of these;
</em><br />
<em class="quotelev1">>but I do think these are useful distinctions. 
</em><br />
<em class="quotelev1">>
</em><br />

I agree.  What are the datatypes which, in P5, should correspond with 
<br />
each of these three cases?
<br />

<p><em class="quotelev1">>It is my (very
</em><br />
<em class="quotelev1">>unscientific) observation that users crave the use of IDREF (or its
</em><br />
<em class="quotelev1">>modern equivalent) as a mechanism for controlling vocabularies. Even
</em><br />
<em class="quotelev1">>those I would think of as "power users" of TEI are sometimes very
</em><br />
<em class="quotelev1">>hesitant to change the DTD, and very few want to go to the trouble of
</em><br />
<em class="quotelev1">>building a database and creating software that actually uses a TEI key
</em><br />
<em class="quotelev1">>to look things up in it. However, users often really want the
</em><br />
<em class="quotelev1">>capability to control the values of a particular attribute, and
</em><br />
<em class="quotelev1">>occasionally even want to say something about what the values mean.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>There are problems porting this analysis to the P5 world, though. In
</em><br />
<em class="quotelev1">>P5, the pointers that replace IDREFs can point anywhere. Even into the
</em><br />
<em class="quotelev1">>schema, e.g. Furthermore, in P4 the value of key= was just a key. But
</em><br />
<em class="quotelev1">>in the P5 world, it might make sense for the key= to indicate the
</em><br />
<em class="quotelev1">>resource as well as the key. E.g., in P4 <name key="929041"> perhaps
</em><br />
<em class="quotelev1">>could be <name key="http://my.server.org/name-database?929041"> or
</em><br />
<em class="quotelev1">>some such.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

That depends on what the datatype for "key" is. If it is a URIref, yes. 
<br />
If it is just a  xsd:name, then you can't do that without modifying the 
<br />
ODD (which of course is no big deal)
<br />

<em class="quotelev1">>Thus, in EDW90 I suggested three mechanisms for controlling vocabulary.
</em><br />
<em class="quotelev1">>* tei.data.enumerated, the control is via a closed <valList> in the
</em><br />
<em class="quotelev1">>  ODD which boils down to a token list in the schema
</em><br />
<em class="quotelev1">>* tei.data.code (perhaps a bad name), a local pointer (although an
</em><br />
<em class="quotelev1">>  argument could be made for making this a generic pointer or for
</em><br />
<em class="quotelev1">>  making it an xsd:Name and using co-reference)
</em><br />
<em class="quotelev1">>* tei.data.key, for database keys, could be declared as a URI or as an
</em><br />
<em class="quotelev1">>  xsd:Name, and I don't claim to know which is better
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

I think we should use a pointer for the second class (URIref) and 
<br />
xsd:name for the last.
<br />

<em class="quotelev1">>Note that, if I understand correctly, the key= of <attRef>,
</em><br />
<em class="quotelev1">><moduleRef>, <specDesc>, and <memberOf> is currently defined as being
</em><br />
<em class="quotelev1">>a name, and is tied to being one processing chain. I.e., using a URI
</em><br />
<em class="quotelev1">>here would break things.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

Also elsewhere, probably.
<br />

<em class="quotelev1">>As I sit here and think about it, in my pre-breakfast hypoglycemic
</em><br />
<em class="quotelev1">>state, I am beginning to lean towards leaving tei.data.key an
</em><br />
<em class="quotelev1">>xsd:Name, and telling users who really want to specify the resource as
</em><br />
<em class="quotelev1">>well as the key to use xml:base=. E.g. <name key="929041"
</em><br />
<em class="quotelev1">>xml:base="http:/my.server.org/name-database">. Is that feasible? I
</em><br />
<em class="quotelev1">>don't claim to have thought this through at all.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
See comment above. I dont think we should add special purpose rules of 
<br />
this kind.
<br />

<em class="quotelev1">>One final thought. As mentioned before, in the P5 world as currently
</em><br />
<em class="quotelev1">>instantiated, a document can't say to which schema it is supposed to
</em><br />
<em class="quotelev1">>conform. So suppose a project has 2 somewhat similar schemas that
</em><br />
<em class="quotelev1">>serve different purposes lying around, each of which imposes a closed
</em><br />
<em class="quotelev1">>value list on the bar= of <foo>, as follows:
</em><br />
<em class="quotelev1">>   A        B
</em><br />
<em class="quotelev1">>   ---      -------
</em><br />
<em class="quotelev1">>   fee      fee
</em><br />
<em class="quotelev1">>   fi       fi
</em><br />
<em class="quotelev1">>   fo       fiddlie
</em><br />
<em class="quotelev1">>   fum      aye
</em><br />
<em class="quotelev1">>            oh
</em><br />
<em class="quotelev1">>Now suppose you, the encoder, start working on an instance. Unless
</em><br />
<em class="quotelev1">>said instance is already valid against A and invalid against B, you
</em><br />
<em class="quotelev1">>have no way of knowing that "fum" is a legal value but "aye" is not.
</em><br />
<em class="quotelev1">>Thus I think (or am I worried?) that a validatable method of
</em><br />
<em class="quotelev1">>constraining values from within the instance will be even more popular
</em><br />
<em class="quotelev1">>in P5 than in P4. I.e., it would be useful to have
</em><br />
<em class="quotelev1">>  <definition-of-foo-values>
</em><br />
<em class="quotelev1">>    <valList>
</em><br />
<em class="quotelev1">>      <valItem ident="fee">
</em><br />
<em class="quotelev1">>        <gloss>The file entropy evaluation as reported by blort</gloss>
</em><br />
<em class="quotelev1">>      </valItem>
</em><br />
<em class="quotelev1">>      <valItem ident="fi">
</em><br />
<em class="quotelev1">>        <gloss>The file input, should contain only ASCII characters</gloss>
</em><br />
<em class="quotelev1">>      </valItem>
</em><br />
<em class="quotelev1">>      </valItem ident="fo">
</em><br />
<em class="quotelev1">>   ...
</em><br />
<em class="quotelev1">>or some such somewhere in the TEI Header.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

I dont pretend to understand what you're getting at here,. but in any 
<br />
case it seems a bit beyond our current remit.
<br />

<p><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">>  
</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 Sep 01 2005 - 15:32:33 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Thu Sep  1 16:07:01 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 01 Sep 2005 21:07:01 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <200508312049.j7VKnBia028939@cepheus.services.brown.edu>
Message-ID: <43175F65.6010103@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, 01 Sep 2005 21:07:01 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev2">>>Sebastian and I have done some testing of the feasibility of doing
</em><br />
<em class="quotelev2">>>local over-rides as described here. Our conclusions are that this
</em><br />
<em class="quotelev2">>>is not possible on technical grounds,
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>This is quite a shame, as such a capability could provide the means
</em><br />
<em class="quotelev1">>for significant simplification of the TEI scheme, and much of the work
</em><br />
<em class="quotelev1">>put into ED W 90 was predicated on this possibility. Such is life.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

Yes, I agree it's a nuisance. The problem is in the way that ODDs are 
<br />
"flattened" during the schema generation phase. Sebastianb and I have 
<br />
discussed it at length several times, and I have understood it at least 
<br />
once. Dont forget of course that the inability to do a local override 
<br />
*only* applies to generation of P5 canonical sources -- a user of the 
<br />
system is still at liberty eg to replace an unconstrained list  with a 
<br />
constrained one in their application-specific odd.
<br />

<em class="quotelev2">>>Our recommendation is that
</em><br />
<em class="quotelev2">>>- the tei.typed class should be removed
</em><br />
<em class="quotelev2">>>- elements bearing a type attribute (and former members of the
</em><br />
<em class="quotelev2">>>  typed class) should be checked to see whether their valLists
</em><br />
<em class="quotelev2">>>  constitute an open or closed list
</em><br />
<em class="quotelev2">>>- for closed list, the datatype will be an alternation of the
</em><br />
<em class="quotelev2">>>  possible values
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I presume you mean "set of permissible values" or some such, not
</em><br />
<em class="quotelev1">>"datatype". (Up until now we've been using the term "datatype" to
</em><br />
<em class="quotelev1">>express an abstract grouping of values with similar syntactic
</em><br />
<em class="quotelev1">>constraints and similar semantics, presumably implemented by some form
</em><br />
<em class="quotelev1">>of indirection. However, there is the potential for lots of confusion,
</em><br />
<em class="quotelev1">>because the child of <attDef> which is used to abstractly declare the
</em><br />
<em class="quotelev1">>attribute type is called <datatype>. This is quite unfortunate a
</em><br />
<em class="quotelev1">>situation, for which I must take the blame -- Sebastian specifically
</em><br />
<em class="quotelev1">>asked me if any of the names he chose for these elements were
</em><br />
<em class="quotelev1">>problematic before he cemented them into our processing chain, and I
</em><br />
<em class="quotelev1">>missed this obvious thorn.)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
Yes, sorry, I was using the term loosely to mean "what it says is legal 
<br />
for this attribute in the DTD/schema"
<br />

<em class="quotelev2">>>- for open (or semi) lists, the datatype will be tei.enumerated,
</em><br />
<em class="quotelev2">>>  i.e. a single token not containing whitespace
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I'm confused. What then is the difference between tei.data.enumerated
</em><br />
<em class="quotelev1">>and tei.data.token?
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

No difference for one sense of "datatype", some difference for the 
<br />
other! The suggestion is to use tei.data.enumerated for cases where 
<br />
there is a <valList>, open or closed. But I am happy to go with 
<br />
tei.data.token for open/semi lists as well if this is felt to be clearer.
<br />

<em class="quotelev1">>In some ways this may feel like a big step backwards, as it is
</em><br />
<em class="quotelev1">>essentially the system we were using before Paris. But I think this
</em><br />
<em class="quotelev1">>works almost as well as the system Council sketched out in Paris. If
</em><br />
<em class="quotelev1">>a TEI-schema-designer wants to restrict users to the values provided
</em><br />
<em class="quotelev1">>in an open (or semi) list, all she needs to do is change the type of
</em><br />
<em class="quotelev1">><valList> from "open" to "closed". (Hmmm... I just realized that this
</em><br />
<em class="quotelev1">>is actually currently not true. I think she'd have to copy-and-paste
</em><br />
<em class="quotelev1">>the entire <valList> from the tagdoc into her ODD, which isn't nearly
</em><br />
<em class="quotelev1">>as nice. Sebastian, could we arrange the process so that just
</em><br />
<em class="quotelev1">>specifying, e.g.
</em><br />
<em class="quotelev1">>          <elementSpec module="core" ident="note" mode="change">
</em><br />
<em class="quotelev1">>            <attList>
</em><br />
<em class="quotelev1">>              <attDef ident="place">
</em><br />
<em class="quotelev1">>                <valList type="closed"/>
</em><br />
<em class="quotelev1">>              </attDef>
</em><br />
<em class="quotelev1">>            </attList>
</em><br />
<em class="quotelev1">>          </elementSpec>
</em><br />
<em class="quotelev1">>would work? It's not ambiguous that the user is trying to remove all
</em><br />
<em class="quotelev1">>the possible values, because it makes no sense to have an empty
</em><br />
<em class="quotelev1">><valList>, especially if the type is "closed"; of course it also
</em><br />
<em class="quotelev1">>isn't valid ala the current TD.)
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

I would like to hear Sebastian's view on this -- he's back at work next 
<br />
week -- but I suspect he will say that this looks like rather recondite 
<br />
special-casing. After all, chances are that if you want to close the set 
<br />
of values you'll probably want to modify the TEI suggestions anyway.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>1.2 Over-riding of attributes
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>I think we can actually make explicit some of what Syd is
</em><br />
<em class="quotelev2">>>describing here by using the RelaxNG method of defining facets. So
</em><br />
<em class="quotelev2">>>we could for example say that a datatype was basically a positive
</em><br />
<em class="quotelev2">>>integer, but with the added constraint that it has a value less
</em><br />
<em class="quotelev2">>>than 43 by a construct such as
</em><br />
<em class="quotelev2">>>    <datatype>
</em><br />
<em class="quotelev2">>>      <rng:data type="nonNegativeInteger">
</em><br />
<em class="quotelev2">>>        <rng:param name="maxInclusive">42</rng:param>
</em><br />
<em class="quotelev2">>>      </rng:data>
</em><br />
<em class="quotelev2">>>    </datatype>
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Yes, I think this is doable, but it really only addresses a small
</em><br />
<em class="quotelev1">>subset of what I think we set forth in Paris to do. (And note that
</em><br />
<em class="quotelev1">>quite a few of the proposed datatypes make use of this.)
</em><br />
<em class="quotelev1">>
</em><br />

Could we see a list of these?
<br />

<em class="quotelev1">> In
</em><br />
<em class="quotelev1">>particular, since the restriction is a facet, we can't use this
</em><br />
<em class="quotelev1">>feature to have one TEI datatype for numeric representations
</em><br />
<em class="quotelev1">>(tei.data.numeric), and say "this attribute is one of
</em><br />
<em class="quotelev1">>tei.data.numeric, but must be a non-negative integer".
</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">>>If (and only if) there is a 1:1 mapping between a TEI datatype and
</em><br />
<em class="quotelev2">>>[a W3C Schema] datatype we could presumably also do
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>   <datatype>
</em><br />
<em class="quotelev2">>>     <rng:data>
</em><br />
<em class="quotelev2">>>       <rng:ref name="tei.nonNegativeInteger">
</em><br />
<em class="quotelev2">>>       <rng:param name="maxInclusive">42</rng:param>
</em><br />
<em class="quotelev2">>>     </rng:data>
</em><br />
<em class="quotelev2">>>   </datatype>
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I tried a quick test, and both nxml-mode and trang objected to such a
</em><br />
<em class="quotelev1">>schema.
</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">>>In the general case, however, we think that all datatype definitions
</em><br />
<em class="quotelev2">>>should be complete and appropriate. In practice, we think the vast
</em><br />
<em class="quotelev2">>>majority of TEI attributes are already catered for by a very small
</em><br />
<em class="quotelev2">>>number of datatypes. (of the 500+ attributes listed by Syd, about
</em><br />
<em class="quotelev2">>>400 are covered by derivations of tei.data.token, tei.data.pointer
</em><br />
<em class="quotelev2">>>and tei.data.uboolean)
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I'm not exactly sure what you mean by "derivations" here, but if it's
</em><br />
<em class="quotelev1">>the adding restrictions to a generic datatype that we can't do, it
</em><br />
<em class="quotelev1">>means we have a problem for lots of those attributes, no?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

Again, I think we need to look at cases here. Suppose we started by just 
<br />
using the simplest (most generic) datatypes wherever possible, how many 
<br />
attributes would be seriously discommoded?
<br />

<em class="quotelev2">>>We conclude that
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>- datatypes should be expressed as <rng:data> expressions
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I'm not sure I see why we want to impose such a restriction. E.g., for
</em><br />
<em class="quotelev1">>the TEI sex datatype, why would we prefer
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>     <rng:data>
</em><br />
<em class="quotelev1">>       <rng:param name="pattern">^\s*(f|m|u|x)\s*$</rng:param>
</em><br />
<em class="quotelev1">>     </rng:data>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>to either
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>    <rng:choice>
</em><br />
<em class="quotelev1">>      <rng:value>f</rng:value>
</em><br />
<em class="quotelev1">>      <rng:value>m</rng:value>
</em><br />
<em class="quotelev1">>      <rng:value>u</rng:value>
</em><br />
<em class="quotelev1">>      <rng:value>x</rng:value>
</em><br />
<em class="quotelev1">>    </rng:choice>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>or far better
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>    <valList type="closed">
</em><br />
<em class="quotelev1">>      <val>f</val> <desc>female</desc>
</em><br />
<em class="quotelev1">>      <val>m</val> <desc>male</desc>
</em><br />
<em class="quotelev1">>      <val>u</val> <desc>unknown or undetermined</desc>
</em><br />
<em class="quotelev1">>      <val>x</val> <desc>not applicable or indeterminable</desc>
</em><br />
<em class="quotelev1">>    </valList>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

I dont quite see what you're getting at here. We need to decide whether 
<br />
sex is an enumeration of possible values (possibly allowing people to 
<br />
use their own values), or a hardwired datatype like date values. My 
<br />
vote, fwiw, is for the former, but I'm open to discussion.
<br />

<em class="quotelev2">>>- for commonly occurring cases (see below) we should define a small 
</em><br />
<em class="quotelev2">>>  number of macros, which will be named in the way Syd proposes for
</em><br />
<em class="quotelev2">>>  datatypes
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I think I may be confused: for commonly occurring cases of what? In the
</em><br />
<em class="quotelev1">>previous bullet point did "datatype" mean "the declaration of the
</em><br />
<em class="quotelev1">>allowed values of a particular attribute" or "an abstract constraint
</em><br />
<em class="quotelev1">>which can be applied to the allowed values of any given attribute"?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

That's OK, I am not sure that I remember which I meant myself. I was 
<br />
probably hankering after comprehensible names for certain frequently 
<br />
ocuring ranges of v alues.
<br />

<em class="quotelev2">>>- it should be possible to map all datatypes to W3C basic datatypes, 
</em><br />
<em class="quotelev2">>>  possibly with additional constraints
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>If I understand this correctly, I don't think there's any immediate
</em><br />
<em class="quotelev1">>problem with it. (I'm presuming that anything that is expressed as a
</em><br />
<em class="quotelev1">>list of values is something that can be mapped ) I think it is
</em><br />
<em class="quotelev1">>probably fine as a goal for the current short-term project.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>However, as a long-term principle I think it is a very bad idea to tie
</em><br />
<em class="quotelev1">>TEI to W3C datatypes. While I am far from a computer scientist who has
</em><br />
<em class="quotelev1">>studied these issues, it's clear that W3C datatypes leave a lot to be
</em><br />
<em class="quotelev1">>desired. It is quite reasonable to expect that other datatype
</em><br />
<em class="quotelev1">>libraries will be published (e.g., OASIS DSDL part 5), or that we
</em><br />
<em class="quotelev1">>would want to create a datatype library ourselves, perhaps using DTLL
</em><br />
<em class="quotelev1">>if & when it becomes fully worked out.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

This is simply reiterating a decision we took at the Council meeting in 
<br />
Oxford, if I remember aright.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>The TEI has always proposed additional constraints in remarks,
</em><br />
<em class="quotelev2">>>valDesc, and descriptive prose. We think we should use the
</em><br />
<em class="quotelev2">>>Schematron language to express some of these: the primary use case
</em><br />
<em class="quotelev2">>>being constraints on acceptable GIs as targets for various pointing
</em><br />
<em class="quotelev2">>>attributes.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>We are not sure where these constraints go in ODD-world, but
</em><br />
<em class="quotelev2">>>probably not in the <datatype>. We recommend using Schematron for
</em><br />
<em class="quotelev2">>>them because (a) we know it does the job (b) it is a candidate ISO
</em><br />
<em class="quotelev2">>>recommendation.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I agree with all of the above. Although I think perhaps we should
</em><br />
<em class="quotelev1">>avoid features of ISO Schematron that are not available in Schematron
</em><br />
<em class="quotelev1">>1.x, as processors for the former are hard to come by. (That may
</em><br />
<em class="quotelev1">>change by the time this becomes an issue, of course.)
</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">>>I think anything we can do to reduce the complications consequent on
</em><br />
<em class="quotelev2">>>the whitespace rules of XML is an unalloyed Good Thing, and propose
</em><br />
<em class="quotelev2">>>to be even more draconian than Syd suggests.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Hear hear!
</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">>>My suggestion is that we allow only token, nmtoken, and
</em><br />
<em class="quotelev2">>>tei.data.token.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I'm not sure *where* this restriction occurs, since in the next
</em><br />
<em class="quotelev1">>paragraph you propose we keep "tei.data.tokens".
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I mean to include the plural forms, sorry for the carelessness.
<br />

<em class="quotelev1">>- token: do you mean "rng:token" or "xsd:token"?
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

No idea. Please spell out the difference, and express your preference if 
<br />
any.
<br />

<em class="quotelev1">>- xsd:NMTOKEN: interesting; where would you want to use it? I have
</em><br />
<em class="quotelev1">>               found no good use for this datatype for any of the 541
</em><br />
<em class="quotelev1">>               attributes I looked at. In every case that NMTOKEN is
</em><br />
<em class="quotelev1">>               currently used, I think we should be using xsd:Name (or
</em><br />
<em class="quotelev1">>               perhaps xsd:NCName), except for the 1 oddball case of
</em><br />
<em class="quotelev1">>               unit= on <timeline>, which should be an enumerated list
</em><br />
<em class="quotelev1">>               or folded into interval=.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

I'm happy to stick with NCName
<br />

<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>While sympathising with the motivation for it, I feel that the
</em><br />
<em class="quotelev2">>>distinction Syd proposes between "tei.data.string" and
</em><br />
<em class="quotelev2">>>"tei.data.tokens" will only confuse people. If the value of a
</em><br />
<em class="quotelev2">>>sequence of tokens is to be interpreted as a single string, then it
</em><br />
<em class="quotelev2">>>probably shouldn't be an attribute at all.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Really good point. As I said, I'm very back-and-forth on this issue,
</em><br />
<em class="quotelev1">>and Lou's argument tips me back. The only attribute that I can think
</em><br />
<em class="quotelev1">>of that does not fit the "tei.data.tokens" semantic and should remain
</em><br />
<em class="quotelev1">>an attribute is the value= of <metSym>. And since it's a single
</em><br />
<em class="quotelev1">>attribute, IMHO it doesn't have to be declared as a "datatype" (i.e.,
</em><br />
<em class="quotelev1">>with indirection), and even if Council thinks it does, we could just
</em><br />
<em class="quotelev1">>use tei.data.tokens and live with it. (Remember, the validation would
</em><br />
<em class="quotelev1">>be exactly the same, it's only that the prose explanation might not
</em><br />
<em class="quotelev1">>fit perfectly well. Does anyone use this attribute, anyway?)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I think it should be tei.data.token -- it can't have white space. It 
<br />
should be a single character in fact for any sensible kind of notation.
<br />

<em class="quotelev2">>>These I like:
</em><br />
<em class="quotelev2">>>tei.data.token, tei.data.tokens, tei.data.pointer, tei.data.pointers
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Me too.
</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">>>Constraining tei.data.token/s further as NMTOKEN/S/NCName/QNAME etc. is 
</em><br />
<em class="quotelev2">>>possible, but I am not sure how many elements would benefit from it
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Between half a dozen and a dozen attributes, I suspect. Most, if not
</em><br />
<em class="quotelev1">>all, of which should be xsd:Name. 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
Then let's go with that.
<br />

<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>Names I would prefer:
</em><br />
<em class="quotelev2">>>for tei.data.uboolean -> tei.data.truthValue
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I *like* it. Unless there are rousing objections, I'll plan to change
</em><br />
<em class="quotelev1">>this in EDW90 and the corresponding database later this week.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
Done?
<br />

<em class="quotelev2">>>Names I'm not sure about
</em><br />
<em class="quotelev2">>>tei.data.temporalExpression: how does this map to ISO 8601?
</em><br />
<em class="quotelev2">>>(I assume it doesn't include dateRanges, for example)
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Hey, you thought of this name! See separate thread James started for
</em><br />
<em class="quotelev1">>ISO 8601 alignment discussion.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

It's not so much the name that worries me as the significance! We need 
<br />
some straw person proposals in view of the points James raises.
<br />

<em class="quotelev2">>>tei.data.duration
</em><br />
<em class="quotelev2">>>  We should adopt a consistent policy as to whether quantities like this 
</em><br />
<em class="quotelev2">>>include their units, or whether the units are supplied as a separate 
</em><br />
<em class="quotelev2">>>attribute. I think I prefer the second option, as being more
</em><br />
<em class="quotelev2">>>flexible.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>If we're going to use W3C datatypes, then at least in those cases
</em><br />
<em class="quotelev1">>where W3C puts the unit in with the quantity (xsd:duration explicitly,
</em><br />
<em class="quotelev1">>and the various date and time formats implicitly) we'd have to do the
</em><br />
<em class="quotelev1">>same. 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

Yes., but only if we chose to. We could say we will NEVER have 
<br />
attributes which combine in their value quantity+unit, or we could say 
<br />
we have some which do and some which dont, or we could say all 
<br />
quantities have the potential to include units. Again, a list of 
<br />
specific cases might help sharpen discussion and reach a decision.
<br />

<em class="quotelev2">>>tei.data.probability
</em><br />
<em class="quotelev2">>>  Not convinced we need this. There are very few candidates in the
</em><br />
<em class="quotelev2">>>EDW90 table (I find 1, to be exact!)
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>My fault, table had typos. This one is for expressing a range from 0
</em><br />
<em class="quotelev1">>to 1 (or 0% to 100% or none to all). Currently only 3 attributes make
</em><br />
<em class="quotelev1">>use of it (scope= of <handNote>, usage= of <language>, weights= of
</em><br />
<em class="quotelev1">><alt>). Since (IIRC) Council agreed in Paris that whenever 2 or more
</em><br />
<em class="quotelev1">>attributes share the same constraint, a datatype should be abstracted
</em><br />
<em class="quotelev1">>out, I did so. (There was even some discussion that there should be a
</em><br />
<em class="quotelev1">>datatype even if only 1 attribute has a particular constraint, IIRC.)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
Well 3 is almost enough to warrant having it.  Presumably if we define 
<br />
it as a macro, the user who only wants ever to express probability by 
<br />
means of a percentage can say so by redefining the macro.
<br />

<em class="quotelev2">>>tei.data.numeric
</em><br />
<em class="quotelev2">>>  I'm now coming round to the view that we also need a
</em><br />
<em class="quotelev2">>>  tei.data.integer
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I'm wondering if the concept of "positive integer or 0" is simple
</em><br />
<em class="quotelev1">>enough that we don't need to bother creating a TEI datatype for it,
</em><br />
<em class="quotelev1">>and could just use xsd:nonNegativeInteger directly when needed.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

Fine by me.
<br />

<em class="quotelev2">>>tei.data.language
</em><br />
<em class="quotelev2">>>  I agree that we need to document exactly what this means somewhere and 
</em><br />
<em class="quotelev2">>>providing a TEI name for it is a good way of doing so.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>JC> Just to make sure I'm understanding this...would that datatype
</em><br />
<em class="quotelev1">>JC> then be used for validation of @xml:lang's format? It seems
</em><br />
<em class="quotelev1">>JC> strange to me to be using a tei.datatype to validate and/or
</em><br />
<em class="quotelev1">>JC> document use of a non-TEI element/attribute.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I agree with Lou. There are 3 reasons to make a datatype
</em><br />
<em class="quotelev1">>(tei.data.language) that maps directly to xsd:language.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>* It occurs more than twice (I'm not sure this is a compelling
</em><br />
<em class="quotelev1">>  argument on its own): langKey= & otherLangs= of <textLang>, ident=
</em><br />
<em class="quotelev1">>  of <language>, mainLang= of <hand>, and xml:lang= of everything.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>* Although it maps directly to xsd:language, the explanation of
</em><br />
<em class="quotelev1">>  xsd:language is both hard to find and hard to read & understand.
</em><br />
<em class="quotelev1">>  (Quite unlike the explanation of xsd:nonNegativeInteger, which is
</em><br />
<em class="quotelev1">>  easy to find, and not all that hard to read & understand -- besides,
</em><br />
<em class="quotelev1">>  it's obvious enough that almost no one bothers.)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>* As Christian pointed out, it would be nice to have someplace in the
</em><br />
<em class="quotelev1">>  reference documentation to plunk the explanation of how xml:lang= is
</em><br />
<em class="quotelev1">>  related to ident= of <language>.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I will post a reply on tei.data.code and tei.data.key issue separately.
</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.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">>  
</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 Sep 01 2005 - 16:04:12 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Thu Sep  1 20:30:33 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 1 Sep 2005 20:30:33 -0400
Subject: [tei-council] comments on edw90
In-Reply-To: <431757FA.3010605@computing-services.oxford.ac.uk>
Message-ID: <17175.40233.135852.836925@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, 1 Sep 2005 20:30:33 -0400</span><br />
</address>

<em class="quotelev2">> >* the value is from a list specified in the DTD (e.g., status= of
</em><br />
<em class="quotelev2">> >  <availability>)
</em><br />
<em class="quotelev2">> >
</em><br />
<em class="quotelev2">> >* the value is an IDREF to something (which has an id=) specified in
</em><br />
<em class="quotelev2">> >  the document instance (e.g., who= of <sp> or resp= of <add>)
</em><br />
<em class="quotelev2">> >
</em><br />
<em class="quotelev2">> >* the value is a key into some (ostensibly external, but Lou correctly
</em><br />
<em class="quotelev2">> >  points out that, especially in the P5 world, it may well be in the
</em><br />
<em class="quotelev2">> >  document instance) resource (e.g., key= of <name>)
</em><br />
<em class="quotelev2">> > ...
</em><br />
<em class="quotelev1">> I agree. What are the datatypes which, in P5, should correspond
</em><br />
<em class="quotelev1">> with each of these three cases?
</em><br />

* tei.data.enumerated
<br />
* tei.data.code
<br />
* tei.data.key
<br />

<p><em class="quotelev1">> That depends on what the datatype for "key" is. If it is a URIref,
</em><br />
<em class="quotelev1">> yes. If it is just a xsd:name, then you can't do that without
</em><br />
<em class="quotelev1">> modifying the ODD (which of course is no big deal)
</em><br />

Yes, that is the question we are currently discussing ... what should
<br />
the datatype of tei.data.key be, a URI or a name? Personally, I'm
<br />
inclined to stick with name. (I.e., that tei.data.key boil down to
<br />
xsd:Name.)
<br />

<p><em class="quotelev1">> I think we should use a pointer for the second class
</em><br />
<em class="quotelev1">> [tei.data.code] and xsd:name for the last [tei.data.key].
</em><br />

OK. On the proposal to constrain the pointer in tei.data.code to be a
<br />
local pointer, do you think it is
<br />
a. a bad idea
<br />
b. a good idea
<br />
c. you're indifferent
<br />
d. a bad idea for TEI to enforce it, but the Guidelines should mention
<br />
   that a project may wish to add this restriction locally, and
<br />
   perhaps even describe how
<br />
e. the TEI should enforce it, and the Guidelines should mention that
<br />
   a project may which to remove this constraint, and perhaps even
<br />
   describe how
<br />
f. the Princeton Band
<br />

Personally, I am leaning towards (b) or (d). The problem with
<br />
permitting a tei.data.code attribute to point outside the current
<br />
document is that it opens a bit of a can of worms as to what it
<br />
points at. E.g., if new= of <handShift> is supposed to point to a
<br />
<hand> inside a //TEI/teiHeader/profileDesc/handList, great. But if
<br />
you're putting that <hand> in an external document, what goes inside
<br />
the <text> of that external document?
<br />

<p><em class="quotelev2">> >Note that, if I understand correctly, the key= of <attRef>,
</em><br />
<em class="quotelev2">> ><moduleRef>, <specDesc>, and <memberOf> is currently defined as
</em><br />
<em class="quotelev2">> >being a name, and is tied to being one processing chain. I.e.,
</em><br />
<em class="quotelev2">> >using a URI here would break things.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Also elsewhere, probably.
</em><br />

I didn't notice any others, but I didn't look that carefully. Either
<br />
way, the point is that if we change tei.data.key into a URI, we need
<br />
to separate these attributes out into yet a different datatype.
<br />

<p><em class="quotelev1">> See comment above. I dont think we should add special purpose rules
</em><br />
<em class="quotelev1">> of this kind.
</em><br />

Which comment above? Doesn't matter. I think I was on drugs when I
<br />
suggested it. It's a hack, and as such the TEI should not be
<br />
recommending it. Suggestion withdrawn.
<br />

<p><em class="quotelev1">> I dont pretend to understand what you're getting at here,. but in
</em><br />
<em class="quotelev1">> any case it seems a bit beyond our current remit.
</em><br />

Just that we should not kiss off the concept of tei.data.code, i.e.
<br />
of allowing a user to constrain an attribute's value[1], and perhaps
<br />
provide some semantics, by making it refer to something in the
<br />
current instance (or potentially elsewhere). It's an important idea.
<br />

Note
<br />

----
[1] And yes, the constraint is *not* enforced by your schema
    validation process, but rather some separate link-checking
    process.
_______________________________________________
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 Sep 01 2005 - 20:30:38 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Thu Sep  1 23:57:46 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 1 Sep 2005 23:57:46 -0400 (EDT)
Subject: [tei-council] comments on edw90
In-Reply-To: <43175F65.6010103@computing-services.oxford.ac.uk>
Message-ID: <200509020357.j823vkia003843@cepheus.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>: Thu, 1 Sep 2005 23:57:46 -0400 (EDT)</span><br />
</address>

<em class="quotelev2">> >I'm confused. What then is the difference between tei.data.enumerated
</em><br />
<em class="quotelev2">> >and tei.data.token?
</em><br />
<em class="quotelev1">> No difference for one sense of "datatype", some difference for the
</em><br />
<em class="quotelev1">> other! The suggestion is to use tei.data.enumerated for cases where
</em><br />
<em class="quotelev1">> there is a <valList>, open or closed. But I am happy to go with
</em><br />
<em class="quotelev1">> tei.data.token for open/semi lists as well if this is felt to be
</em><br />
<em class="quotelev1">> clearer.
</em><br />

The idea from Paris was that a <valList>, whether closed, open, or
<br />
semi, is required for an attribute of type tei.data.token. I still
<br />
think that's fine.
<br />

<p><em class="quotelev1">> I would like to hear Sebastian's view on this -- he's back at work
</em><br />
<em class="quotelev1">> next week -- but I suspect he will say that this looks like rather
</em><br />
<em class="quotelev1">> recondite special-casing. After all, chances are that if you want to
</em><br />
<em class="quotelev1">> close the set of values you'll probably want to modify the TEI
</em><br />
<em class="quotelev1">> suggestions anyway.
</em><br />

While the former may be the case, I really hope we do a good enough
<br />
job of choosing values that at least for some attributes users would
<br />
be very happy just closing the list.
<br />

<p><em class="quotelev1">> Could we see a list of these?
</em><br />

Yes, in EDW90. The following all take advantage of W3C Schema facets
<br />
via RelaxNG parameters.
<br />
  tei.data.token
<br />
  tei.data.temporalExpression
<br />
  tei.data.duration
<br />
  tei.data.probability
<br />
  tei.data.numeric
<br />

<p><em class="quotelev1">> Again, I think we need to look at cases here. Suppose we started by
</em><br />
<em class="quotelev1">> just using the simplest (most generic) datatypes wherever possible,
</em><br />
<em class="quotelev1">> how many attributes would be seriously discommoded?
</em><br />

I've already looked at the cases. All of them. I've made suggestions
<br />
based on looking at them. Given that those suggestions were based on
<br />
the erroneous presumption that we could have code that would tighten
<br />
or loosen constraints of a datatype for a given attribute, quite a few
<br />
of them will need to be re-worked.
<br />

<p><em class="quotelev1">> I dont quite see what you're getting at here. We need to decide
</em><br />
<em class="quotelev1">> whether sex is an enumeration of possible values (possibly allowing
</em><br />
<em class="quotelev1">> people to use their own values), or a hardwired datatype like date
</em><br />
<em class="quotelev1">> values. My vote, fwiw, is for the former, but I'm open to
</em><br />
<em class="quotelev1">> discussion.
</em><br />

Now you've *really* lost me.
<br />

* Can people not change a datatype? (After all, it's just implemented
<br />
  as a macro.) If not, why not?
<br />

* If they can't change a datatype, what difference does it make
<br />
  whether the datatype is declared in terms of an <rng:data> or an
<br />
  <rng:choice> or a <tei:valList>?
<br />

* Why couldn't a hardwired datatype be an enumeration of possible
<br />
  values?
<br />

I think these two issues (whether an attribute type is abstracted to a
<br />
datatype or not, and whether it is expressed as an enumeration type,
<br />
some constraint on a string type, some W3C type, or some constrained
<br />
W3C type, etc.) are orthogonal.
<br />

<p><em class="quotelev1">> This is simply reiterating a decision we took at the Council meeting
</em><br />
<em class="quotelev1">> in Oxford, if I remember aright.
</em><br />

If you say so ... but which was the antecedent of "This"?
<br />

<p><em class="quotelev2">> >- token: do you mean "rng:token" or "xsd:token"?
</em><br />

<em class="quotelev1">> No idea. Please spell out the difference, and express your
</em><br />
<em class="quotelev1">> preference if any.
</em><br />

Difference is spelled out in EDW90. Basically xsd:token has one
<br />
additional (powerful) feature and one (minor) drawback over rng:token.
<br />
The additional feature is that further constraints can be applied via
<br />
facets. The drawback is that you must use a RelaxNG processor that
<br />
knows about W3C Schema datatypes. But since to process most the rest
<br />
of a TEI document, your RelaxNG processor is going to have to know
<br />
about W3C Schema datatypes anyway, I have a strong preference for
<br />
xsd:token. 
<br />

<p><em class="quotelev1">> I'm happy to stick with NCName
</em><br />

OK. If anyone has reason to prefer xsd:Name or xsd:NMTOKEN over
<br />
xsd:NCName for those attributes that used to be NMTOKEN (except for
<br />
unit= of <timeline>), speak now or forever hold your peace. (Well, at
<br />
least keep quiet about it for a few months.)
<br />

<p><em class="quotelev1">> I think it should be tei.data.token -- it can't have white space. It
</em><br />
<em class="quotelev1">> should be a single character in fact for any sensible kind of
</em><br />
<em class="quotelev1">> notation.
</em><br />

My first reaction was that this was unduly harsh, after all, it could
<br />
contain white-space in P4. But then I thought about it for a few
<br />
moments, and decided that any metrical notation that included
<br />
white-space could easily be re-worked without it. As above, if anyone
<br />
objects to tei.data.token (i.e., no white-space) for value= of
<br />
<metSym> (which was called <symbol> in P4), speak now.
<br />

<p><em class="quotelev2">> >Between half a dozen and a dozen attributes, I suspect. Most, if
</em><br />
<em class="quotelev2">> >not all, of which should be xsd:Name.
</em><br />
<em class="quotelev1">> Then let's go with that.
</em><br />

Errr ... didn't we just decide on xsd:NCName a few paragraphs above?
<br />

<p><em class="quotelev2">> >If we're going to use W3C datatypes, then at least in those cases
</em><br />
<em class="quotelev2">> >where W3C puts the unit in with the quantity (xsd:duration
</em><br />
<em class="quotelev2">> >explicitly, and the various date and time formats implicitly) we'd
</em><br />
<em class="quotelev2">> >have to do the same.
</em><br />

<em class="quotelev1">> Yes., but only if we chose to. We could say we will NEVER have
</em><br />
<em class="quotelev1">> attributes which combine in their value quantity+unit, or we could
</em><br />
<em class="quotelev1">> say we have some which do and some which dont, or we could say all
</em><br />
<em class="quotelev1">> quantities have the potential to include units. Again, a list of
</em><br />
<em class="quotelev1">> specific cases might help sharpen discussion and reach a decision.
</em><br />

Right, but my point was that the choice is inextricably linked to the
<br />
use of xsd:duration and xsd:[time-and-date-types]. If we make use of
<br />
those (and I can't really see not doing so at this point ... maybe
<br />
someday we could write a better datatype library, but it would be an
<br />
effort) then we can't choose "NEVER".
<br />

<p><em class="quotelev1">> ... Presumably if we define it as a macro, the user who only wants
</em><br />
<em class="quotelev1">> ever to express probability by means of a percentage can say so by
</em><br />
<em class="quotelev1">> redefining the macro.
</em><br />

My thoughts exactly.
<br />

<p><em class="quotelev2">> >I'm wondering if the concept of "positive integer or 0" is simple
</em><br />
<em class="quotelev2">> >enough that we don't need to bother creating a TEI datatype for it,
</em><br />
<em class="quotelev2">> >and could just use xsd:nonNegativeInteger directly when needed.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Fine by me.
</em><br />

Sounds good. Once again, if anyone objects ...
<br />

<p>FYI, it will probably take me several days to completely update the
<br />
table to reflect these various changes (presuming no one objects), as
<br />
my wife will be away and I'll be playing Mr. Mom for a while.
<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 Sep 01 2005 - 23:57:50 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Sat Sep  3 12:25:33 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sat, 03 Sep 2005 17:25:33 +0100
Subject: [tei-council] Upcoming teleconference Friday 2005-09-09 at 1300 UTC
In-Reply-To: <ygfpsrtwr8d.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <4319CE7D.6040200@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, 03 Sep 2005 17:25:33 +0100</span><br />
</address>

Christian Wittern wrote:
<br />
<em class="quotelev1">> James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> writes:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I'd prefer to have a dedicated channel for the council.
</em><br />

Ok, on the day of the council call I'll set up a password (or 'key') 
<br />
protected channel called #tei-council the joining instructions are the 
<br />
same and I'd still suggest joining the #tei-c one.  Once there type:
<br />
/join #tei-council 2expensive
<br />
and in most IRC clients that will get you there.
<br />

<em class="quotelev1">> BTW (showing
</em><br />
<em class="quotelev1">> my ignorance) is it possible to have a log of the conversation and
</em><br />
<em class="quotelev1">> post it for example on the Council pages?
</em><br />

Currently the robot I have sat in the public channel logs everything 
<br />
for the previous two days (it has a 'today' log and a 'yesterday' log) 
<br />
but these are overwritten each day.  However, it won't be on the 
<br />
council channel anyways.
<br />

But yes, most clients give a method of logging the traffic in a 
<br />
channel.  In fact, gaim gives the option of logging in plain text or 
<br />
HTML.  (Although it uses XML for most of its files, it doesn't seem to 
<br />
log in it unfortunately.)  I will make sure to enable logging on that 
<br />
day, and I hope others will as well to make doubly sure.
<br />

<em class="quotelev1">> Last time I tried this, I realized that I forgot to ask how do
</em><br />
<em class="quotelev1">> disconnect, so my alter ego was hanging around there until the whole
</em><br />
<em class="quotelev1">> firefox went belly up...
</em><br />

Most clients will respond to:
<br />
/quit
<br />
and some will pass on a quit message as well:
<br />
/quit I'm off to the pub.
<br />

I'm not sure the best way to do this in the Chatzilla extension, since 
<br />
I don't use it, but it will probably work with that.
<br />

In addition, if this happens often through disconenctions etc. another 
<br />
method is to register your nickname with NickServ, then if you come 
<br />
back and another virtual you is still there you can:
<br />
/ghost nickname password
<br />
and it will get rid of the other you.
<br />

<p>-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 Sep 03 2005 - 12:25:36 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sat Sep  3 16:48:55 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 03 Sep 2005 21:48:55 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <17175.40233.135852.836925@emt.wwp.brown.edu>
Message-ID: <431A0C37.6010402@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, 03 Sep 2005 21:48:55 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev3">>>>* the value is from a list specified in the DTD (e.g., status= of
</em><br />
<em class="quotelev3">>>> <availability>)
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev3">>>>* the value is an IDREF to something (which has an id=) specified in
</em><br />
<em class="quotelev3">>>> the document instance (e.g., who= of <sp> or resp= of <add>)
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev3">>>>* the value is a key into some (ostensibly external, but Lou correctly
</em><br />
<em class="quotelev3">>>> points out that, especially in the P5 world, it may well be in the
</em><br />
<em class="quotelev3">>>> document instance) resource (e.g., key= of <name>)
</em><br />
<em class="quotelev3">>>>...
</em><br />
<em class="quotelev3">>>>      
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev2">>>I agree. What are the datatypes which, in P5, should correspond
</em><br />
<em class="quotelev2">>>with each of these three cases?
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>* tei.data.enumerated
</em><br />
<em class="quotelev1">>* tei.data.code
</em><br />
<em class="quotelev1">>* tei.data.key
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
why is the second case not tei.data.pointer ?
<br />

<p><em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>That depends on what the datatype for "key" is. If it is a URIref,
</em><br />
<em class="quotelev2">>>yes. If it is just a xsd:name, then you can't do that without
</em><br />
<em class="quotelev2">>>modifying the ODD (which of course is no big deal)
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Yes, that is the question we are currently discussing ... what should
</em><br />
<em class="quotelev1">>the datatype of tei.data.key be, a URI or a name? Personally, I'm
</em><br />
<em class="quotelev1">>inclined to stick with name. (I.e., that tei.data.key boil down to
</em><br />
<em class="quotelev1">>xsd:Name.)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I agree.
<br />

<em class="quotelev2">>>I think we should use a pointer for the second class
</em><br />
<em class="quotelev2">>>[tei.data.code] and xsd:name for the last [tei.data.key].
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>OK. On the proposal to constrain the pointer in tei.data.code to be a
</em><br />
<em class="quotelev1">>local pointer, do you think it is
</em><br />
<em class="quotelev1">>a. a bad idea
</em><br />
<em class="quotelev1">>b. a good idea
</em><br />
<em class="quotelev1">>c. you're indifferent
</em><br />
<em class="quotelev1">>d. a bad idea for TEI to enforce it, but the Guidelines should mention
</em><br />
<em class="quotelev1">>   that a project may wish to add this restriction locally, and
</em><br />
<em class="quotelev1">>   perhaps even describe how
</em><br />
<em class="quotelev1">>e. the TEI should enforce it, and the Guidelines should mention that
</em><br />
<em class="quotelev1">>   a project may which to remove this constraint, and perhaps even
</em><br />
<em class="quotelev1">>   describe how
</em><br />
<em class="quotelev1">>f. the Princeton Band
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

I think it is a bad idea.
<br />

<em class="quotelev1">>Personally, I am leaning towards (b) or (d). The problem with
</em><br />
<em class="quotelev1">>permitting a tei.data.code attribute to point outside the current
</em><br />
<em class="quotelev1">>document is that it opens a bit of a can of worms as to what it
</em><br />
<em class="quotelev1">>points at. E.g., if new= of <handShift> is supposed to point to a
</em><br />
<em class="quotelev1">><hand> inside a //TEI/teiHeader/profileDesc/handList, great. But if
</em><br />
<em class="quotelev1">>you're putting that <hand> in an external document, what goes inside
</em><br />
<em class="quotelev1">>the <text> of that external document?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev3">>>>Note that, if I understand correctly, the key= of <attRef>,
</em><br />
<em class="quotelev3">>>><moduleRef>, <specDesc>, and <memberOf> is currently defined as
</em><br />
<em class="quotelev3">>>>being a name, and is tied to being one processing chain. I.e.,
</em><br />
<em class="quotelev3">>>>using a URI here would break things.
</em><br />
<em class="quotelev3">>>>      
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev2">>>Also elsewhere, probably.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I didn't notice any others, but I didn't look that carefully. Either
</em><br />
<em class="quotelev1">>way, the point is that if we change tei.data.key into a URI, we need
</em><br />
<em class="quotelev1">>to separate these attributes out into yet a different datatype.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I disagree. It is a name, not a pointer.
<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 Sep 03 2005 - 16:37:02 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sat Sep  3 17:04:13 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 03 Sep 2005 22:04:13 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <200509020357.j823vkia003843@cepheus.services.brown.edu>
Message-ID: <431A0FCD.4010702@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, 03 Sep 2005 22:04:13 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>The idea from Paris was that a <valList>, whether closed, open, or
</em><br />
<em class="quotelev1">>semi, is required for an attribute of type tei.data.token. I still
</em><br />
<em class="quotelev1">>think that's fine.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
No, I think the presence of a valList implies that the datatype should 
<br />
be tei.data.enumerated, which maps onto either an explicit list of 
<br />
alternatives (if the valList is closed) or onto tei.data.token otherwise.
<br />

<p><em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>I dont quite see what you're getting at here. We need to decide
</em><br />
<em class="quotelev2">>>whether sex is an enumeration of possible values (possibly allowing
</em><br />
<em class="quotelev2">>>people to use their own values), or a hardwired datatype like date
</em><br />
<em class="quotelev2">>>values. My vote, fwiw, is for the former, but I'm open to
</em><br />
<em class="quotelev2">>>discussion.
</em><br />
<em class="quotelev2">>>
</em><br />

...
<br />

<em class="quotelev2">>>This is simply reiterating a decision we took at the Council meeting
</em><br />
<em class="quotelev2">>>in Oxford, if I remember aright.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>If you say so ... but which was the antecedent of "This"?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

That datatypes should all be mapped to xsd: datatypes
<br />

<em class="quotelev3">>>>If we're going to use W3C datatypes, then at least in those cases
</em><br />
<em class="quotelev3">>>>where W3C puts the unit in with the quantity (xsd:duration
</em><br />
<em class="quotelev3">>>>explicitly, and the various date and time formats implicitly) we'd
</em><br />
<em class="quotelev3">>>>have to do the same.
</em><br />
<em class="quotelev3">>>>      
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>Yes., but only if we chose to. We could say we will NEVER have
</em><br />
<em class="quotelev2">>>attributes which combine in their value quantity+unit, or we could
</em><br />
<em class="quotelev2">>>say we have some which do and some which dont, or we could say all
</em><br />
<em class="quotelev2">>>quantities have the potential to include units. Again, a list of
</em><br />
<em class="quotelev2">>>specific cases might help sharpen discussion and reach a decision.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Right, but my point was that the choice is inextricably linked to the
</em><br />
<em class="quotelev1">>use of xsd:duration and xsd:[time-and-date-types]. If we make use of
</em><br />
<em class="quotelev1">>those (and I can't really see not doing so at this point ... maybe
</em><br />
<em class="quotelev1">>someday we could write a better datatype library, but it would be an
</em><br />
<em class="quotelev1">>effort) then we can't choose "NEVER".
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

So the choice is really
<br />

(1)  use xsd:duration (which includes units) , and thus remove all the 
<br />
additional attributes that specify units
<br />

(2) use plain old numeric dataype of some sort, and retain the unit 
<br />
attribute
<br />

Choice (1) is only going to work for durations where we can be confident 
<br />
that the xsd units are going to meet TEI needs, obviously. I fear there 
<br />
may be fewer of these than anticipated -- probably people will be 
<br />
content to use SI units for times, but you can bet someone will always 
<br />
want to measure (e.g.) distance in rods poles and perches.
<br />

At present the only attributes assigned tei.data.duration are age= and 
<br />
dur=  Choice 1 fits fine with the latter, and reasonably well with the 
<br />
former, imho. Any others?
<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 Sep 03 2005 - 16:52:29 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sat Sep  3 16:57:39 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 03 Sep 2005 21:57:39 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <431A0FCD.4010702@computing-services.oxford.ac.uk>
Message-ID: <431A0E43.6080507@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, 03 Sep 2005 21:57:39 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> So the choice is really
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> (1)  use xsd:duration (which includes units) , and thus remove all the
</em><br />
<em class="quotelev1">> additional attributes that specify units
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> (2) use plain old numeric dataype of some sort, and retain the unit
</em><br />
<em class="quotelev1">> attribute
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Choice (1) is only going to work for durations where we can be
</em><br />
<em class="quotelev1">> confident that the xsd units are going to meet TEI needs, obviously. I
</em><br />
<em class="quotelev1">> fear there may be fewer of these than anticipated -- probably people
</em><br />
<em class="quotelev1">> will be content to use SI units for times, but you can bet someone
</em><br />
<em class="quotelev1">> will always want to measure (e.g.) distance in rods poles and perches.
</em><br />
<em class="quotelev1">>
</em><br />
surely the point of these attributes is exactly to standardize described
<br />
text? so when I see "67 rods", I want to,
<br />
and should, encode it as <foo distance="32.3m">67 rods</foo>?
<br />

choice (1) seems obvious to me, and always has done. I don't think SI
<br />
units do the job,
<br />
I'll lobby ISO....
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sat Sep 03 2005 - 16:57:49 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep  4 10:41:48 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 04 Sep 2005 15:41:48 +0100
Subject: [tei-council] state of classes etc
Message-ID: <431B07AC.60509@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, 04 Sep 2005 15:41:48 +0100</span><br />
</address>

Lou asked me to regenerate EDW84, which lists
<br />
the elements and the classes they belong to, and vice versa.
<br />
I took the chance to clean it up a bit and deliver it as
<br />
XML, so its now at http://www.tei-c.org.uk/Drafts/edw84.xml
<br />
for you to goggle at.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Sep 04 2005 - 10:42:05 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Sep  4 14:59:26 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 4 Sep 2005 14:59:26 -0400
Subject: [tei-council] comments on edw90
In-Reply-To: <431A0C37.6010402@computing-services.oxford.ac.uk>
Message-ID: <17179.17422.849196.713371@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, 4 Sep 2005 14:59:26 -0400</span><br />
</address>

<em class="quotelev2">> >* tei.data.enumerated
</em><br />
<em class="quotelev2">> >* tei.data.code
</em><br />
<em class="quotelev2">> >* tei.data.key
</em><br />
<em class="quotelev2">> >
</em><br />
<em class="quotelev1">> why is the second case not tei.data.pointer ?
</em><br />

Good question. In part because I was copying this datatype that we
<br />
already had. :-) But more to the point, as currently conceived,
<br />
tei.data.pointer is a generic URI. tei.data.code, on the other hand,
<br />
is a datatype for local constraint of tokens, that happens to use a
<br />
pointer to perform that task. That is, it permits the user to
<br />
constrain the set of values of an attribute from within the document
<br />
instance. So if a user wants to establish a set of roles for the
<br />
various participants in a language interaction, she can do this by
<br />
encoding the following <roleDef>s (yeah, I know, there's no such
<br />
thing) in the <teiHeader>:
<br />

  <roleDef xml:id="session-chair"/>
<br />
  <roleDef xml:id="speaker"/>
<br />
  <roleDef xml:id="questioner"/>
<br />

or, better still
<br />

  <roleDef xml:id="session-chair">The session chair, repsonsible ...
<br />
  <roleDef xml:id="speaker">Paper presenter, not necessarily the
<br />
                            author ...
<br />
  <roleDef xml:id="questioner">A member of the auidience who asked
<br />

Then in the paticipant group, a
<br />
  <person role="#speaker">...
<br />
can occur, and Schematron can easily check that the value of role= is
<br />
one of "#session-chair", "#speaker", or "#questioner". In some other
<br />
instance, even in the same project, we might find
<br />

  <roleDef xml:id="conference-chair">One of the program committee
<br />
                                     co-chairs ... 
<br />
  <roleDef xml:id="server">A server who works for the conference 
<br />
                            hotel or the catering service they ...
<br />
  <roleDef xml:id="diner">Hotel resteraunt patron ...
<br />

So just as something like
<br />

  <valList type="closed">
<br />
    <valItem ident="session-chair">
<br />
      <gloss>The session chair, responsible for ... </gloss>
<br />
    </valItem>
<br />
    <valItem ident="speaker">
<br />
      <gloss>Paper presenter, not necessarily the author ...</gloss>
<br />
    </valItem>
<br />
    <valItem ident="questioner">
<br />
      <gloss>A member of the auidience who asked ...</gloss>
<br />
    </valItem>
<br />
  </valList>
<br />

can be used from within the ODD to constrain the values, something
<br />
like the fictional <roleDef>s above can be used from within the
<br />
instance to constrain the values. The only reason for using a local
<br />
URI and xml:id= over an NCName and ident= is that it's more likely
<br />
generic software will be helpful in the former case. The only reason
<br />
for not using a local URI, IMHO, is to avoid that ugly "#".
<br />

If the datatype were a generic URI, Schematron could still validate
<br />
that an attribute pointed to a <roleDef>. It might even be able to
<br />
still validate that a bare name fragment identifier was used, and
<br />
that it matches the xml:id= of a <roleDef>.
<br />

<p><em class="quotelev2">> >Yes, that is the question we are currently discussing ... what
</em><br />
<em class="quotelev2">> >should the datatype of tei.data.key be, a URI or a name?
</em><br />
<em class="quotelev2">> >Personally, I'm inclined to stick with name. (I.e., that
</em><br />
<em class="quotelev2">> >tei.data.key boil down to xsd:Name.)
</em><br />
<em class="quotelev2">> >
</em><br />
<em class="quotelev1">> I agree.
</em><br />

I'm just double-checking that I've understood you correctly. You are
<br />
in agreement that tei.data.key should boil down to an xsd:Name (as
<br />
opposed to merely agreeing that this is the question we are
<br />
discussing). 
<br />

<p><em class="quotelev2">> >OK. On the proposal to constrain the pointer in tei.data.code to be a
</em><br />
<em class="quotelev2">> >local pointer, ...
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I think it is a bad idea.
</em><br />

I suppose the reason I am shying away from full-blown URIs (i.e.,
<br />
prefer local URIs only, or co-reference with ident=) is that doing so
<br />
breaks away from the idea that the value of the attribute conveys
<br />
meaning itself, and that the pointing or co-referencing may be used
<br />
to provide constraint or to provide further information about the
<br />
semantics of the value.
<br />

Also, permitting any URI opens the can of worms I mentioned last
<br />
time.
<br />

<p><em class="quotelev2">> >I didn't notice any other [places than <attRef>, <moduleRef>,
</em><br />
<em class="quotelev2">> ><specDesc>, and <memberOf> where key= is defined as a name], but I
</em><br />
<em class="quotelev2">> >didn't look that carefully. Either way, the point is that if we
</em><br />
<em class="quotelev2">> >change tei.data.key into a URI, we need to separate these
</em><br />
<em class="quotelev2">> >attributes out into yet a different datatype.
</em><br />
<em class="quotelev2">> >
</em><br />
<em class="quotelev1">> I disagree. It is a name, not a pointer.
</em><br />

I don't understand with what you are disagreeing. In case there is
<br />
some confusion, let me reiterate the point. If we decide that the
<br />
datatype tei.data.key is a URI (which Lou is against, Syd is waffling
<br />
back & forth about, and about which no one else has issued an
<br />
opinion), then the key= attribute of
<br />
  <attRef>
<br />
  <moduleRef>
<br />
  <specDesc>
<br />
  <memberOf>
<br />
should not be declared using this datatype. (Which would be a bit
<br />
weird, as they're named "key".)
<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 Sep 04 2005 - 14:59:30 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Mon Sep  5 16:39:57 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 5 Sep 2005 16:39:57 -0400
Subject: [tei-council] EDW90 and data updated
Message-ID: <17180.44317.441377.692208@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, 5 Sep 2005 16:39:57 -0400</span><br />
</address>

I've made some minor updates to ED W 90 itself (removed
<br />
tei.data.string, as Lou's talked me out of it; where I said "I think
<br />
X ..." about whitespace, it now just says "X", as I've checked, and I
<br />
was right), and significant updates to the database of attributes and
<br />
datatypes. Changes include:
<br />

* Updated to reflect the changes Lou made to the CVS source based on
<br />
  the database (e.g., deleting most attributes of <teiHeader>)
<br />

* Changed various xsd:NMTOKEN attrs to be xsd:Name.
<br />

* Changed various things that were tei.data.numeric restricted to
<br />
  xsd:nonNegativeInteger to just xsd:nonNegativeInteger.
<br />

* Fixed a bunch of typos.
<br />

* Removed references to tei.data.string.
<br />

I have *not* changed tei.data.uboolean to tei.data.truthValue in the
<br />
database yet, but hope to get that done in < 24 hrs. Note that the
<br />
new version of ED W 90 itself may not be available on the web for a
<br />
few hours.
<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 Sep 05 2005 - 16:40:01 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Sep  6 07:45:25 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 06 Sep 2005 20:45:25 +0900
Subject: [tei-council] Draft agenda for Council teleconference on 2005-09-09 / 1300 UTC
Message-ID: <ygfoe76pgh6.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 06 Sep 2005 20:45:25 +0900</span><br />
</address>

TEI Council Members and Editors:
<br />

This is the agenda for the conference call the TEI Council will
<br />
hold Friday, September 9th, 2005 at 1300 UTC.
<br />

Please read through the following, in advance of the call.  
<br />

<p>INSTRUCTIONS for conference call:
<br />

Participants will dial in to +1-812-856-3600
<br />

The Conference Access Information is listed below:
<br />

Conf Id:        2174
<br />
Date:        9/9/2005
<br />

PIN:        000920#
<br />

Expected members to participate:
<br />

Syd Bauman, Alejandro Bia, Lou Burnard, James Cummings, Julia
<br />
Flanders, Susan Schreibman, Sebastian Rahtz, Laurent Romary, Natasha
<br />
Smith, John Walsh, Perry Willett, Christian Wittern.
<br />

Edward Vanhoutte excused himself and is busy working on his thesis while we talk.
<br />

Matthew Driscoll will be in Bulgaria, or actually on a bus somewhere
<br />
between Sofia and Ohrid, Macedonia.  
<br />

In addition to the voice connection, we also expect to communicate via
<br />
IRC. Instructions to connect are as follows (quoted from James
<br />
Cumming's message):
<br />

Basically, in almost any IRC client, set the server to be irc.freenode.net
<br />
and the channel to be #tei-c and you should be fine.  In some clients
<br />
this is done through setting up an account in various graphical
<br />
manners, in others you might use /connect serverName or /server
<br />
serverName and then /join #tei-c     [for #tei-council see below] 
<br />
Alternatively, if you have the Chatzilla extension installed, in the
<br />
address bar of firefox you can use this url:
<br />
irc://irc.freenode.net/tei-c to connect.  My preferred client is gaim
<br />
because it is multi-protocol (does yahoo, aim/aol, msn, jabber, gmail,
<br />
chat protocols amongst others).
<br />
...
<br />
Ok, on the day of the council call I'll set up a password (or 'key')
<br />
protected channel called #tei-council the joining instructions are the
<br />
same and I'd still suggest joining the #tei-c one.  Once there type:
<br />
/join #tei-council 2expensive
<br />
and in most IRC clients that will get you there.
<br />

(instructions also at:
<br />

http://www.tei-c.org.uk/wiki/index.php/IRC
<br />

However, the information on specific clients is limited, so do feel
<br />
free to add more detail! )
<br />

<br />

Agenda:
<br />

7 items, ca 5-20 minutes apiece.
<br />

-----------------------------------------------------
<br />

<p>1) Review of the minutes and action items (10 min)
<br />

   Minutes of the meeting are at
<br />
         http://www.tei-c.org/Council/tcm18.html.
<br />

         To speed up the review of action items, *please report to the
<br />
         council list* before the call as far as possible! 
<br />

<br />
         We will discuss the reports during the call as necessary.
<br />

<p>------------------------------------------------------------
<br />

2) Review of WG etc. progress (10 min) : 
<br />

<p>-----------------------------------------------------
<br />

<p>3) Report about TEI Council/ W3C I18N collaboration (5 Minutes)
<br />

         Sebastian Rahtz
<br />

<p>------------------------------------------------------------
<br />

<p>4) Report about TEI I18N activity  (5 Minutes)
<br />

        Sebastian Rahtz,
<br />

  please see also 
<br />
        http://users.ox.ac.uk/~rahtz/i18n/demo.html
<br />

------------------------------------------------------------
<br />

<p>5) P5 progress:  (20 min)
<br />

- on Attributes and Datatypes (EDW90)
<br />
        http://www.tei-c.org.uk/Drafts/edw90.xml?style=printable
<br />
        and various comments on tei-council
<br />
- on classes (?)
<br />
  http://www.tei-c.org.uk/Drafts/edw84.xml
<br />

-----------------------------------------------------
<br />

6) Other business  (5 minutes)
<br />

<p>   TBA
<br />

<p>-----------------------------------------------------
<br />

7) Meetings: (5 minutes)
<br />

   Next call, members meeting preparations.
<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 Sep 06 2005 - 07:45:43 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Sep  6 07:52:25 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 06 Sep 2005 12:52:25 +0100
Subject: [tei-council] Draft agenda for Council teleconference on 2005-09-09 / 1300 UTC
In-Reply-To: <ygfoe76pgh6.fsf@chwpb.local>
Message-ID: <431D82F9.2020207@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, 06 Sep 2005 12:52:25 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>4) Report about TEI I18N activity  (5 Minutes)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>	Sebastian Rahtz,
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  please see also 
</em><br />
<em class="quotelev1">>	http://users.ox.ac.uk/~rahtz/i18n/demo.html
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
actually, better now is http://www.tei-c.org/I18N/demo.xml
<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 Sep 06 2005 - 07:54:04 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Sep  6 08:07:17 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 06 Sep 2005 13:07:17 +0100
Subject: [tei-council] Draft agenda for Council teleconference on 2005-09-09 / 1300 UTC
In-Reply-To: <ygfoe76pgh6.fsf@chwpb.local>
Message-ID: <431D8675.6020702@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, 06 Sep 2005 13:07:17 +0100</span><br />
</address>

Report on Actions from last telco for SR
<br />

a) "create new release": duly done (and revised a day or two later) and 
<br />
all components updated in Sourceforge, on web site, etc. All being well, 
<br />
another release will be made to coincide with the Members Meeting, with 
<br />
the expectation that it will include new datatypes.
<br />

b) "details of directory layout": it was created, used, shipped etc. 
<br />
Syncrosoft duly used it in the oXygen public release, and it appears to 
<br />
be stable
<br />

memo to Lou and Syd:  read the second para of section 4 of the minutes.
<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 Sep 06 2005 - 08:08:55 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Tue Sep  6 10:25:06 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 06 Sep 2005 15:25:06 +0100
Subject: [tei-council] Draft agenda for Council teleconference on 2005-09-09 / 1300 UTC
In-Reply-To: <ygfoe76pgh6.fsf@chwpb.local>
Message-ID: <431DA6C2.7080306@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, 06 Sep 2005 15:25:06 +0100</span><br />
</address>

Christian Wittern wrote:
<br />
<em class="quotelev1">> 	 To speed up the review of action items, *please report to the
</em><br />
<em class="quotelev1">> 	 council list* before the call as far as possible! 
</em><br />

One of the action items for me to do was a HOWTO for the Stylesheets CVS module. 
<br />
  This has changed into a larger document detailing all the CVS modules and is 
<br />
available at:
<br />

http://www.tei-c.org/Council/tcw06.xml
<br />

Today Syd has suggested some changes which I should have finished by the time of 
<br />
the conference call.  However, more suggestions and corrections are desired.  It 
<br />
should give you enough information to have you be able to use TEI's CVS.  If it 
<br />
doesn't, tell me where.  (Though we don't want to just duplicate information 
<br />
available on the sourceforge site or elsewhere on the TEI site.)
<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> Tue Sep 06 2005 - 10:26:15 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Thu Sep  8 00:40:16 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 8 Sep 2005 00:40:16 -0400
Subject: [tei-council] Draft agenda for Council teleconference on 2005-09-09 / 1300 UTC
In-Reply-To: <ygfoe76pgh6.fsf@chwpb.local>
Message-ID: <17183.49328.443517.263433@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, 8 Sep 2005 00:40:16 -0400</span><br />
</address>

<em class="quotelev1">>        To speed up the review of action items, *please report to
</em><br />
<em class="quotelev1">>        the council list* before the call as far as possible!
</em><br />

<p>| * SR & SB:  Hammer out details of directory layout 
<br />

Done.
<br />

<p>| * SB: make all resp attributes into pointers. Scheduled for end of
<br />
|       August, still planning to do so then.
<br />

Done.
<br />

<p>| * SB & DD: finish SA discussions of XPointer ... 
<br />

<em class="quotelev1">>From DD "most of the scheme stuff rewritten", but still have to do
</em><br />
the prose describing XPointer. I'm hoping we can check in at least
<br />
the XPointer scheme discussions before the conference call.
<br />

<p>| * SB: with DD produce brief report on process for getting XPointer
<br />
|       schemes registered
<br />

No need. According to Henry Thompson there still is no process for
<br />
getting XPointer schemes registered at W3C. We should declare our
<br />
intention to register our schemes when the registry becomes "live" by
<br />
sending mail to ... Henry, I think, but will have to check on that.
<br />

<p>Since some of the underlying presumptions of the setup of datatypes
<br />
in EDW90's table have proven to be incorrect, I am planning to spend
<br />
time in the immediate future revamping the suggested declarations of
<br />
attribute values in the immediate future, rather than switch gears to
<br />
the bibliography.
<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 Sep 08 2005 - 00:40:21 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Thu Sep  8 06:03:31 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 08 Sep 2005 11:03:31 +0100
Subject: [tei-council] Draft agenda for Council teleconference on	2005-09-09 / 1300 UTC
In-Reply-To: <431D82F9.2020207@oucs.ox.ac.uk>
Message-ID: <43200C73.9030201@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, 08 Sep 2005 11:03:31 +0100</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev1">> actually, better now is http://www.tei-c.org/I18N/demo.xml
</em><br />

Am I missing something or isn't there a hu/hu or in fact any ??/hu ?
<br />

Not that I have any need of it personally.
<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> Thu Sep 08 2005 - 06:04:55 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep  8 06:08:03 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 08 Sep 2005 11:08:03 +0100
Subject: [tei-council] Draft agenda for Council teleconference on	2005-09-09 / 1300 UTC
In-Reply-To: <43200C73.9030201@computing-services.oxford.ac.uk>
Message-ID: <43200D83.9080409@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, 08 Sep 2005 11:08:03 +0100</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Am I missing something or isn't there a hu/hu or in fact any ??/hu ?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Not that I have any need of it personally.
</em><br />
<em class="quotelev1">>
</em><br />
I can only do hu/hu or ??/hu when a person of hu persuasion translates the
<br />
sample file for me...
<br />

ditto a large number of other [a-z][a-z]/[a-z][a-z] combinations...
<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> Thu Sep 08 2005 - 06:10:02 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Thu Sep  8 06:14:35 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 08 Sep 2005 11:14:35 +0100
Subject: [tei-council] Draft agenda for Council teleconference	on	2005-09-09 / 1300 UTC
In-Reply-To: <43200D83.9080409@oucs.ox.ac.uk>
Message-ID: <43200F0B.5090803@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, 08 Sep 2005 11:14:35 +0100</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev1">> I can only do hu/hu or ??/hu when a person of hu persuasion translates the
</em><br />
<em class="quotelev1">> sample file for me...
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> ditto a large number of other [a-z][a-z]/[a-z][a-z] combinations...
</em><br />

I'm confused then, how do you get the en/hu/ es/hu fr/hu without having had a 
<br />
person of hu persuasion do some translating?
<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> Thu Sep 08 2005 - 06:15:50 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep  8 07:01:44 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 08 Sep 2005 12:01:44 +0100
Subject: [tei-council] Draft agenda for Council teleconference	on	2005-09-09 / 1300 UTC
In-Reply-To: <43200F0B.5090803@computing-services.oxford.ac.uk>
Message-ID: <43201A18.6020207@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, 08 Sep 2005 12:01:44 +0100</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I'm confused then, how do you get the en/hu/ es/hu fr/hu without 
</em><br />
<em class="quotelev1">> having had a person of hu persuasion do some translating?
</em><br />

you have to distinguish between "hu" and "hu". the former is the translation
<br />
of a sample .odd file, the later is the translation of the string 
<br />
constants in the XSLT
<br />
stylesheets. I have the latter for hu, not the former.
<br />

is there a language code "wu", so that we could have "wu hu"?
<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> Thu Sep 08 2005 - 07:03:42 EDT</span>
</div>

From Julia_Flanders at Brown.edu  Thu Sep  8 16:38:56 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 8 Sep 2005 16:38:56 -0400
Subject: [tei-council] report on certainty
In-Reply-To: <ygfoe76pgh6.fsf@chwpb.local>
Message-ID: <a0620072bbf4648aff2a9@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 8 Sep 2005 16:38:56 -0400</span><br />
</address>

I have to apologize for the lateness and sketchiness of this report.
<br />

I had originally thought that in reviewing <certainty> and cert= I 
<br />
would find a great deal to change. However, after reviewing the 
<br />
discussion on TEI-L concerning certainty mechanisms, it seems as 
<br />
though people are generally content with the existing mechanisms. The 
<br />
areas of debate seem chiefly to concern how precise to be in 
<br />
assigning uncertainty. The approach Lou has been presenting (default 
<br />
three-value approach built in, extensible by the user) seems 
<br />
sensible; I believe that for most purposes it will not be possible to 
<br />
say more than "high|medium|low" and encouraging people to use those 
<br />
values is useful.
<br />

One interesting distinction was raised by Tim Finney, concerning a 
<br />
possible distinction, within the concept of "certainty", between:
<br />
--identifying how close one thinks one's encoding/transcription/etc 
<br />
is to the actual
<br />
--identifying how repeatable or "popular" an encoding is: how likely 
<br />
it is to be agreed with (this is what Finney called "precision"  but 
<br />
I don't think this is a good term in this context)
<br />

This is ingenious, but I don't think it's essential. In practice, 
<br />
it's difficult to assess how close an encoding is to being correct, 
<br />
except by saying something like "I'm [not | sort of | very] sure...", 
<br />
and assessing how repeatable an encoding is would be equally 
<br />
difficult.
<br />

Concerning the existing <certainty> element:
<br />
--the current attributes are reasonable, provide a way to point to 
<br />
the range of things one needs to comment on; most people don't 
<br />
need/won't be bothered to use these, but for the enthusiast they seem 
<br />
adequate based on the feedback we've had
<br />
--desc= will need to be a child element (but this is already 
<br />
contemplated, right?)
<br />
--degree= should use same values as cert= (?) since whatever insight 
<br />
we have about appropriate levels of precision will apply equally to 
<br />
both.
<br />

It would be helpful to add a recommendation of where in the document 
<br />
the <certainty> elements should live, and perhaps also to restrict 
<br />
where they go. At the moment, they could go anywhere, and I'm not 
<br />
sure this is useful. Would it make sense to create a place in the 
<br />
header for this kind of metacommentary? This would make it easier to 
<br />
contemplate processing the information systematically.
<br />

Best wishes, Julia
<br />

<em class="quotelev1">>1) Review of the minutes and action items (10 min)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>    Minutes of the meeting are at
</em><br />
<em class="quotelev1">>	 http://www.tei-c.org/Council/tcm18.html.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>	 To speed up the review of action items, *please report to the
</em><br />
<em class="quotelev1">>	 council list* before the call as far as possible!
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>	 We will discuss the reports during the call as necessary.
</em><br />
_______________________________________________
<br />
tei-council mailing list
<br />
tei-council_at_lists.village.Virginia.EDU
<br />
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
<br />
<span id="received"><dfn>Received on</dfn> Thu Sep 08 2005 - 16:39:02 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Thu Sep  8 16:50:56 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 08 Sep 2005 21:50:56 +0100
Subject: [tei-council] Changes to P5
Message-ID: <4320A430.2070107@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, 08 Sep 2005 21:50:56 +0100</span><br />
</address>

Here is the rather overdue report on changes to TEI P5 carried out since 
<br />
the start of July. Many apologies for the delay. I forgot to do it 
<br />
before setting off for DRH last week.
<br />

The P5 Changelog shows the following significant changes to P5 since
<br />
my last report (7 Jul 05)
<br />

* Renamed <bob> as <binaryObject> and added some discussion of its
<br />
  usage in CO
<br />

* Following much debate, a new directory structure was implemented,
<br />
  and a complete release (0.1.9) made using it. This was followed
<br />
  within a week by another (0.1.10) including Exemplars
<br />

* Changed desc attribute (e.g. on gap, join, joingrp) into
<br />
  child element; removed hand attribute on hand; change  value
<br />
  attribute on span  into content;
<br />

* New class "intervention" introduced to regularize use of resp and
<br />
  cert attributes
<br />

* Removed most attributes from <teiHeader> element
<br />

* Added valList elements to several tagdocs
<br />

* New class "ascribed" introduced to regularise use of who attribute
<br />

* Update MS draft and associated tagdocs following chapter review
<br />

* Rename hand_at_character as writing; rename date_at_certainty as
<br />
  precision; renamed code_at_type as lang; rename witness_at_sigil as xml:id
<br />

* Tidied up inconsistent use of <code> and <val> across the text of 5
<br />

* Changed @resp datatype into a pointer
<br />

* Several typos and inconsistencies were identified and 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> Thu Sep 08 2005 - 16:39:38 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Sep  8 21:17:59 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 09 Sep 2005 10:17:59 +0900
Subject: [tei-council] Draft agenda for Council teleconference on 2005-09-09 / 1300 UTC
In-Reply-To: <431DA6C2.7080306@computing-services.oxford.ac.uk>
Message-ID: <ygfu0gvdooo.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 09 Sep 2005 10:17:59 +0900</span><br />
</address>

James Cummings <James.Cummings_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Christian Wittern wrote:
</em><br />
<em class="quotelev2">>> 	 To speed up the review of action items, *please report to the
</em><br />
<em class="quotelev2">>> 	 council list* before the call as far as possible! 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> One of the action items for me to do was a HOWTO for the Stylesheets
</em><br />
<em class="quotelev1">> CVS module. This has changed into a larger document detailing all the
</em><br />
<em class="quotelev1">> CVS modules and is available at:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> http://www.tei-c.org/Council/tcw06.xml
</em><br />

Thanks.  I just read through the document, where presumably now
<br />
changes requested by Syd are integrated.  I had hoped that it would
<br />
describe not just what is there, but also gives the reader advise on
<br />
how to arrive at a usable local installation (which seems to be the
<br />
purpose of using CVS to me).  This probably means that you would first
<br />
have to install the Stylesheets, then P5 and then Roma (?).  I think
<br />
it would be nice if you could add a section that walks the reader
<br />
through a sample session that installs a usable local P5
<br />
environment. (Of course it would be even nicer if this would not be
<br />
necessary and you could just say "make install" and the whole shebang
<br />
would end up where it wants to be.
<br />

<br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Today Syd has suggested some changes which I should have finished by
</em><br />
<em class="quotelev1">> the time of the conference call.  However, more suggestions and
</em><br />
<em class="quotelev1">> corrections are desired.  It should give you enough information to
</em><br />
<em class="quotelev1">> have you be able to use TEI's CVS.  If it doesn't, tell me where.
</em><br />
<em class="quotelev1">> (Though we don't want to just duplicate information available on the
</em><br />
<em class="quotelev1">> sourceforge site or elsewhere on the TEI site.)
</em><br />

<p>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 Sep 08 2005 - 21:18:08 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Sep  8 22:08:20 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 09 Sep 2005 11:08:20 +0900
Subject: P5 CVS woes (was Re: [tei-council] Draft agenda for Council teleconference on 2005-09-09 / 1300 UTC)
In-Reply-To: <431DA6C2.7080306@computing-services.oxford.ac.uk>
Message-ID: <ygfy867at7v.fsf_-_@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 09 Sep 2005 11:08:20 +0900</span><br />
</address>

James Cummings <James.Cummings_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> http://www.tei-c.org/Council/tcw06.xml
</em><br />
<em class="quotelev1">>
</em><br />

For the record, I just tried to proceed to get a running P5 on my Mac
<br />
OS 10.3 machine, starting with the Stylesheet module, saying 
<br />

make install
<br />

This fails since the xsltdoc stuff is not there (Sebastian, remember
<br />
that I mentioned that before?) Anyhow, I proceeded to download xsltdoc
<br />
from http://prdownloads.sourceforge.net/xsltdoc/XSLTdoc_1.1.zip
<br />
and installed it locally, adding a symlink to the directory where my
<br />
Stylesheets live.  Now I do  "make install" again, this time I get:
<br />

chris_at_chwpb:~/src/tei/Stylesheets % sudo make install
<br />
Error on line 101 of file:/Users/chris/src/tei/Stylesheets/xsltdoc/xsl/core.xsl:
<br />
  XPTY0004: Required item type of value of variable $sourceRootUriAbs is xs:string; supplied
<br />
  value has item type xs:anyURI
<br />
Failed to compile stylesheet. 1 error detected.
<br />

<br />
having seen that it calls saxon, I assume that this might be a problem
<br />
with the stylesheets expecting a XSLT 1.0 processor, while my default
<br />
saxon is for XSLT 2.0.  I then switch the local saxon to 6.5.4 (or
<br />
whatever) and re-run the "make install" command.  This time I get 111
<br />
errors, go back to the XSLTDoc page and see that it requires XSLT
<br />
2.0. At this time I could go hunting for bugs in XSLTdoc, but since my
<br />
purpose is installing P5 I am ready to give up on this...
<br />

What it comes down to is that at the moment there seems to be no
<br />
(easy?) way to install the CVS Stylesheets (and the other P5 modules)
<br />
locally.  We need to solve this and update the document accordingly.
<br />

I know, I could just point to the stylesheets on the TEI website, as
<br />
James mentions in the document, so I do:
<br />

  chris at chwpb:~/src/tei/P5 % XSL=http://www.tei-c.org/stylesheet make -e
<br />
Checking you have a running XML tools and Perl before trying to run transform...
<br />
xsltproc:/sw/bin/xsltproc
<br />
Perl:/usr/bin/perl
<br />
xmllint:/sw/bin/xmllint
<br />
trang:/Users/chris/bin/trang
<br />
jing:/Users/chris/bin/jing
<br />
mkdir DTD
<br />
rm DTD/*
<br />
rm: DTD/*: No such file or directory
<br />
make: [dtds] Error 1 (ignored)
<br />
# generate the DTDs
<br />
xmllint --noent   Source-driver.xml | \
<br />
xsltproc --stringparam outputDir DTD --stringparam verbose true http://www.tei-c.org/stylesheet/odds/odd2dtd.xsl -
<br />
warning: failed to load external entity "http://www.tei-c.org/stylesheet/odds/odd2dtd.xsl"
<br />
cannot parse http://www.tei-c.org/stylesheet/odds/odd2dtd.xsl
<br />
make: *** [dtds] Error 4
<br />

At which point I am at the end of my wits.
<br />

The modules do not seem to be usable without a Debian system at the
<br />
moment (of the four I had running here, the last one went out of
<br />
service a few weeks ago).
<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 Sep 08 2005 - 22:08:26 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Thu Sep  8 23:09:15 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 8 Sep 2005 23:09:15 -0400
Subject: [tei-council] comments on edw90
In-Reply-To: <431A0FCD.4010702@computing-services.oxford.ac.uk>
Message-ID: <17184.64731.463270.588807@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, 8 Sep 2005 23:09:15 -0400</span><br />
</address>

My apologies for the delay. Several pieces of e-mail seem to have
<br />
gotten swallowed in my Inbox. I'm only going to get to this one
<br />
tonight, I'm afraid.
<br />

<p>SB>The idea from Paris was that a <valList>, whether closed, open, or
<br />
SB>semi, is required for an attribute of type tei.data.token. I still
<br />
SB>think that's fine.
<br />

LB> No, I think the presence of a valList implies that the datatype
<br />
LB> should be tei.data.enumerated, which maps onto either an explicit
<br />
LB> list of alternatives (if the valList is closed) or onto
<br />
LB> tei.data.token otherwise.
<br />

Sorry -- You are right, I had meant "tei.data.enumerated" in that
<br />
sentence.
<br />

<p>LB> [That datatypes should all be mapped to xsd: datatypes] is simply
<br />
LB> reiterating a decision we took at the Council meeting in Oxford,
<br />
LB> if I remember aright.
<br />

The minutes say only "it was proposed [within META] ... to define
<br />
datatypes for attribute values more abstractly, mapping them to W3C
<br />
schema datatypes where possible".
<br />

<p>LB> So the choice is really
<br />
LB> 
<br />
LB> (1) use xsd:duration (which includes units) , and thus remove all
<br />
LB> the additional attributes that specify units
<br />
LB> 
<br />
LB> (2) use plain old numeric dataype of some sort, and retain the
<br />
LB> unit attribute
<br />
LB> 
<br />
LB> Choice (1) is only going to work for durations where we can be
<br />
LB> confident that the xsd units are going to meet TEI needs,
<br />
LB> obviously. I fear there may be fewer of these than anticipated --
<br />
LB> probably people will be content to use SI units for times, but
<br />
LB> you can bet someone will always want to measure (e.g.) distance
<br />
LB> in rods poles and perches.
<br />
LB> 
<br />
LB> At present the only attributes assigned tei.data.duration are
<br />
LB> age= and dur= Choice 1 fits fine with the latter, and reasonably
<br />
LB> well with the former, imho. Any others?
<br />

SR> surely the point of these attributes is exactly to standardize
<br />
SR> described text? so when I see "67 rods", I want to, and should,
<br />
SR> encode it as <foo distance="32.3m">67 rods</foo>?
<br />

SR> choice (1) seems obvious to me, and always has done. I don't
<br />
SR> think SI units do the job, I'll lobby ISO....
<br />

I'm not entirely sure I fully understand what Lou's getting at, but I
<br />
think I agree with Sebastian. Are we talking just about durations,
<br />
here, or about any and all things that have units?
<br />

I haven't done an exhaustive search, but the attributes that are
<br />
concerned with duration include
<br />
* dur= of %tei.timed; & <recording>
<br />
* age= of <person>
<br />
* interval= & unit= of <timeline> & <when>
<br />
and could include 
<br />
* value= of the various date & time elements
<br />

While I think sticking with a number-and-unit-in-one approach of
<br />
xsd:duration probably makes sense for all of these, there are some
<br />
problems with using just xsd:duration alone for them.
<br />

First, xsd:duration permits negative values, which don't make sense
<br />
for age= or interval=/unit=. Second, it is my bet that TEI users in
<br />
general are not going to want to express someone's age as, e.g.
<br />
"P36Y", but would much rather "36 yr" (and we can argue over details
<br />
like "year" vs "yr" vs "years" vs "yrs", white-space or not).
<br />

IMHO we are *not* talking about <measure>, where the unit should
<br />
almost assuredly be kept separate from the numeric component.
<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 Sep 08 2005 - 23:09:34 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Fri Sep  9 03:53:51 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 09 Sep 2005 08:53:51 +0100
Subject: P5 CVS woes (was Re: [tei-council] Draft agenda for Council	teleconference on 2005-09-09 / 1300 UTC)
In-Reply-To: <ygfy867at7v.fsf_-_@chwpb.local>
Message-ID: <43213F8F.2050608@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, 09 Sep 2005 08:53:51 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>What it comes down to is that at the moment there seems to be no
</em><br />
<em class="quotelev1">>(easy?) way to install the CVS Stylesheets (and the other P5 modules)
</em><br />
<em class="quotelev1">>locally.  We need to solve this and update the document accordingly.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

the correct way to get yourself a P5 local install
<br />
is to use the Debian or RPM packages...
<br />

but I'll look at this again.
<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> Fri Sep 09 2005 - 03:55:55 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Fri Sep  9 03:57:04 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 09 Sep 2005 08:57:04 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <17184.64731.463270.588807@emt.wwp.brown.edu>
Message-ID: <43214050.8060906@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, 09 Sep 2005 08:57:04 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">> Second, it is my bet that TEI users in
</em><br />
<em class="quotelev1">>general are not going to want to express someone's age as, e.g.
</em><br />
<em class="quotelev1">>"P36Y", but would much rather "36 yr" (and we can argue over details
</em><br />
<em class="quotelev1">>like "year" vs "yr" vs "years" vs "yrs", white-space or not).
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I still say that if you use this attribute, you are committing yourself
<br />
to formal standardized notation. If the appropriate body has agreed
<br />
on "P36Y", it seems madness to me for text encoding folks to say they
<br />
want to withdraw from standardisation efforts, and insist on Western-centric
<br />
adhoc uncodified notation.
<br />

Sebastian
<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 Sep 09 2005 - 03:58:58 EDT</span>
</div>

From jawalsh at indiana.edu  Fri Sep  9 04:20:45 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Fri, 9 Sep 2005 03:20:45 -0500
Subject: P5 CVS woes (was Re: [tei-council] Draft agenda for Council	teleconference on 2005-09-09 / 1300 UTC)
In-Reply-To: <43213F8F.2050608@oucs.ox.ac.uk>
Message-ID: <FD89CB52-FE66-44A1-B127-A6742358CC3A@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, 9 Sep 2005 03:20:45 -0500</span><br />
</address>

| John A. Walsh, Associate Director for Projects and Services
<br />
| Digital Library Program / Indiana University Libraries
<br />
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
<br />
| Voice:812-855-8758 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu>
<br />

On Sep 9, 2005, at 2:53 AM, Sebastian Rahtz wrote:
<br />

<em class="quotelev1">> Christian Wittern wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> What it comes down to is that at the moment there seems to be no
</em><br />
<em class="quotelev2">>> (easy?) way to install the CVS Stylesheets (and the other P5 modules)
</em><br />
<em class="quotelev2">>> locally.  We need to solve this and update the document accordingly.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> the correct way to get yourself a P5 local install
</em><br />
<em class="quotelev1">> is to use the Debian or RPM packages...
</em><br />

Certainly installing from source (or CVS) without having to use a  
<br />
package should also be a "correct" way to install P5,  no?  Not every  
<br />
system supports Debian or RPM packages.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> but I'll look at this again.
</em><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 />
<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 Sep 09 2005 - 04:20:56 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Fri Sep  9 04:30:13 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 09 Sep 2005 09:30:13 +0100
Subject: P5 CVS woes (was Re: [tei-council] Draft agenda for	Council	teleconference on 2005-09-09 / 1300 UTC)
In-Reply-To: <FD89CB52-FE66-44A1-B127-A6742358CC3A@indiana.edu>
Message-ID: <43214815.7010306@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, 09 Sep 2005 09:30:13 +0100</span><br />
</address>

John A. Walsh wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Certainly installing from source (or CVS) without having to use a  
</em><br />
<em class="quotelev1">> package should also be a "correct" way to install P5,  no?  Not every  
</em><br />
<em class="quotelev1">> system supports Debian or RPM packages.
</em><br />
<em class="quotelev1">>
</em><br />
only evil ones don't :-}
<br />

but you're right, of course; I'll make sure the "install" targets work 
<br />
for Stylesheets and P5
<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> Fri Sep 09 2005 - 04:32:09 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Fri Sep  9 04:43:09 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 09 Sep 2005 09:43:09 +0100
Subject: P5 CVS woes (was Re: [tei-council] Draft agenda for Council	teleconference on 2005-09-09 / 1300 UTC)
In-Reply-To: <ygfy867at7v.fsf_-_@chwpb.local>
Message-ID: <43214B1D.9040801@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, 09 Sep 2005 09:43:09 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> starting with the Stylesheet module, saying 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>make install
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>This fails since the xsltdoc stuff is not there 
</em><br />
<em class="quotelev1">>
</em><br />
try now. it bypasses that bit if you don't have xsltdoc.
<br />

<em class="quotelev1">>I know, I could just point to the stylesheets on the TEI website, as
</em><br />
<em class="quotelev1">>James mentions in the document, so I do:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  chris at chwpb:~/src/tei/P5 % XSL=http://www.tei-c.org/stylesheet make -e
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
this should be
<br />

make XSL=http://www.tei-c.org/release/xml/tei/stylesheet
<br />

James, can you check your doc and make sure it uses that example?
<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> Fri Sep 09 2005 - 04:45:05 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Fri Sep  9 04:55:55 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 09 Sep 2005 09:55:55 +0100
Subject: [tei-council] Draft agenda for Council teleconference on	2005-09-09 / 1300 UTC
In-Reply-To: <ygfu0gvdooo.fsf@chwpb.local>
Message-ID: <43214E1B.3030904@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, 09 Sep 2005 09:55:55 +0100</span><br />
</address>

If you update from CVS, I claim that
<br />

 (cd Stylesheets; make PREFIX=/tmp/foo install)
<br />
 (cd Roma; make PREFIX=/tmp/foo install)
<br />
 (cd P5; make PREFIX=/tmp/foo XSL=/tmp/foo2/share/xml/tei/stylesheet 
<br />
install)
<br />

<br />
will behave as expected
<br />

Sebastian
<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 Sep 09 2005 - 04:57:58 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Fri Sep  9 05:06:27 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 09 Sep 2005 10:06:27 +0100
Subject: [tei-council] Draft agenda for Council teleconference on	2005-09-09 / 1300 UTC
In-Reply-To: <ygfu0gvdooo.fsf@chwpb.local>
Message-ID: <43215093.3000802@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, 09 Sep 2005 10:06:27 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>(Of course it would be even nicer if this would not be
</em><br />
<em class="quotelev1">>necessary and you could just say "make install" and the whole shebang
</em><br />
<em class="quotelev1">>would end up where it wants to be.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I think there is a stage beyond this which is even more
<br />
important, and which isn't complete yet; and that is the
<br />
answer to "so I've run 'make install' and the files are all in place;
<br />
now how do I make oXygen/xMeTaL/jEdit/Emacs find the
<br />
stuff"
<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> Fri Sep 09 2005 - 05:08:32 EDT</span>
</div>

From abia at umh.es  Fri Sep  9 08:19:16 2005
From: abia at umh.es (Alejandro Bia)
Date: Fri, 09 Sep 2005 14:19:16 +0200
Subject: [tei-council] Unable to attend conference-call
Message-ID: <5.2.0.9.0.20050909141512.03d82658@mussol.umh.es>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Alejandro Bia <abia_at_umh.es>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 09 Sep 2005 14:19:16 +0200</span><br />
</address>

Dear all,
<br />

Today I have to put an exam at the university at the same time of the call, 
<br />
so I will not be able to participate. I'm sorry.
<br />

Later, I will send another message with some other matters I need to 
<br />
communicate to the Council.
<br />

Best wishes,
<br />
Alex.-
<br />

<p>---------------------------------------------------------
<br />
ALEJANDRO BIA-PLATAS
<br />
e-mail: abia_at_umh.<!--nospam-->es
<br />

   Departamento de Estad?stica, Matem?tica e Inform?tica
<br />
   Universidad Miguel Hern?ndez
<br />
   Edificio Torretamarit
<br />
   Avenida de la Universidad s/n, E-03202, Elche, ESPA?A
<br />
   http://www.umh.es/
<br />
   Tel: +34 966658542
<br />
   Fax: +34 966658715
<br />
   Tel?fono m?vil: +34 610806427
<br />

--------------------------------------------------------- 
<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 Sep 09 2005 - 08:19:31 EDT</span>
</div>

From Julia_Flanders at Brown.edu  Fri Sep  9 11:30:07 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Fri, 9 Sep 2005 11:30:07 -0400
Subject: [tei-council] more on certainty
Message-ID: <a06200733bf473d9f5b53@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 9 Sep 2005 11:30:07 -0400</span><br />
</address>

Here are some more specific assessments of the certainty= and exact= 
<br />
attributes on <date> and <dateStruct>, in the context of the cert= 
<br />
attribute. It didn't take 3 hours, so I'm still good to go on the 
<br />
verse chapter :-)
<br />

1. The state of play
<br />
In P4 we have the following provisions:
<br />
<date certainty=""> with suggested values "approx | before | after"; 
<br />
intended to capture "degree of precision"
<br />
<dateStruct exact=""> with suggested values "approx | before | 
<br />
after"; intended to capture "degree of precision"
<br />
For P5 so far Lou has changed the certainty= attribute on <date> to precision=.
<br />

Here are the things I think one can say in general about dates:
<br />
precision: how many decimal places
<br />
accuracy: how "true" or "correct"
<br />
certainty: our state of mind about truth or correctness
<br />
and also more specific date-like things, such as Gabriel Bodard's 
<br />
suggested "notBefore", "notAfter", which seem to me to be potentially 
<br />
useful specifications under the general heading of precision. (That 
<br />
is, they are a way of adding, slightly, to the precision of a date.)
<br />

2. Is precision useful on dates? yes, I think it is.
<br />
If so, how to encode it?
<br />
--both certainty= on <date> and exact= on <dateStruct> could be 
<br />
changed to precision= (already begun)
<br />
--but if the values for these attributes are intended to indicate 
<br />
"degree of precision", the suggested values from P4 are not good for 
<br />
this. It also seems to me that one can determine how precise a date 
<br />
is by looking at the value= attribute, which clearly shows whether a 
<br />
date is stated to the century, year, month, day, etc. So I would 
<br />
propose that the precision= attribute may be redundant; if someone 
<br />
wants to indicate how precise a date is, they should do so by using 
<br />
the value= attribute with a properly ISO formatted date.
<br />
--the impulse behind the P4 suggested values is reflected more 
<br />
successfully in Gabriel Bodard's suggestion that we add the 
<br />
attributes notBefore= and notAfter=. His additional proposal that the 
<br />
exact= attribute be used to indicate whether either or both of these 
<br />
is exact seems unnecessary: this kind of "exactness" seems to me to 
<br />
be more a statement about our level of knowledge than about the date 
<br />
itself; see below on certainty.
<br />

2. Is accuracy useful on dates? I think this is more difficult to say.
<br />
--dates that are transcribed may be transcribed accurately or 
<br />
inaccurately, but if the latter surely the encoder would not know (or 
<br />
else they'd fix it)
<br />
--dates that are supplied, i.e. those that originate with the 
<br />
encoder/project, may (in theory) be known to be accurate or 
<br />
inaccurate, but the latter case is a little bizarre to imagine.
<br />
--need to distinguish between inaccuracies (a person--e.g. an 
<br />
author--has a wrong idea) and errors (the text has a wrong value), 
<br />
but it's hard to know which is which. For instance, if you see the 
<br />
sentence
<br />

        The American Civil War ended in 1850
<br />

is it useful to say that the date is inaccurate? or would you be more 
<br />
likely to use <sic>?
<br />

3. Is certainty useful on dates? I think probably so, but there are 
<br />
several things about which one might be certain:
<br />
--in data which is being generated rather than transcribed, one may 
<br />
not be certain about whether a date is correct or not, and one might 
<br />
wish to indicate this fact. For instance, in transcribing interview 
<br />
data, one might have reason to doubt the correctness of all the dates 
<br />
of interviews conducted by Person X, who is known to have been 
<br />
suffering mental problems at the time and wasn't keeping good notes. 
<br />
The dates as recorded might be very precise, but also very uncertain.
<br />
--one might also wish to express uncertainty about the level of 
<br />
precision recorded.
<br />
--I don't see that it is useful to express certainty (i.e. a state of 
<br />
mind) concerning the exactness (i.e. the precision) of a date. One 
<br />
expresses the precision using the mechanism given above; one can say 
<br />
a date is notBefore a certain date (which itself can be expressed 
<br />
with whatever level of precision is appropriate). But expressing, 
<br />
additionally, ideas about whether the precision of that notBefore 
<br />
value is correct is just way too meta for me.
<br />

I'm leaving out here forms of uncertainty which affect the *reading* 
<br />
or *transcription* of the date, which would fall under <unclear>, etc.
<br />

If so, how to encode it?
<br />
--for the first case above, I'd say that a cert= attribute on <date> 
<br />
and <dateStruct> might be useful.
<br />
--for the second case, <certainty> seems to be the more appropriate element.
<br />

4. Summary
<br />
--consider whether precision= is really necessary: does it add to the 
<br />
information available in value=, or does it make that information 
<br />
available in a more tractable form?
<br />
--add notBefore= and notAfter= to <date> and <dateStruct>
<br />
--consider adding cert= to <date> and <dateStruct>
<br />
--don't try to capture level of accuracy in dates?
<br />

I hope this is useful.
<br />

best wishes, Julia
<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 Sep 09 2005 - 11:30:14 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Fri Sep  9 12:55:00 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 09 Sep 2005 17:55:00 +0100
Subject: [tei-council] Re: tcw06.xml
In-Reply-To: <ygfu0gvdooo.fsf@chwpb.local>
Message-ID: <4321BE64.3060000@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, 09 Sep 2005 17:55:00 +0100</span><br />
</address>

Christian Wittern wrote:
<br />
<em class="quotelev1">>I think
</em><br />
<em class="quotelev1">> it would be nice if you could add a section that walks the reader
</em><br />
<em class="quotelev1">> through a sample session that installs a usable local P5
</em><br />
<em class="quotelev1">> environment. (Of course it would be even nicer if this would not be
</em><br />
<em class="quotelev1">> necessary and you could just say "make install" and the whole shebang
</em><br />
<em class="quotelev1">> would end up where it wants to be.
</em><br />

<p>I have added an example installation from scratch of Stylesheets, P5 and Roma 
<br />
modules.  I tested the steps on my own machine (but doing it to /tmp/tei )
<br />

See http://www.tei-c.org/Council/tcw06.xml
<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> Fri Sep 09 2005 - 12:56:22 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Fri Sep  9 16:43:12 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 9 Sep 2005 16:43:12 -0400
Subject: [tei-council] first crack at notes from this morning's call
Message-ID: <17185.62432.449625.228190@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, 9 Sep 2005 16:43:12 -0400</span><br />
</address>

Notes are at
<br />
  http://www.tei-c.org/Council/tcm19.xml?style=printable
<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 Sep 09 2005 - 16:43:17 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Sep  9 19:18:47 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 10 Sep 2005 08:18:47 +0900
Subject: [tei-council] Re: tcw06.xml
In-Reply-To: <4321BE64.3060000@computing-services.oxford.ac.uk>
Message-ID: <ygfll25j0dk.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 10 Sep 2005 08:18:47 +0900</span><br />
</address>

James Cummings <James.Cummings_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> I have added an example installation from scratch of Stylesheets, P5
</em><br />
<em class="quotelev1">> and Roma modules.  I tested the steps on my own machine (but doing it
</em><br />
<em class="quotelev1">> to /tmp/tei )
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> See http://www.tei-c.org/Council/tcw06.xml
</em><br />

Thanks. Following your exact instructions, on the last leg I get this:
<br />
<code>
<br />

perl -p -i -e 's/\(\%schemapattern;\)\?/%schemapattern;/' DTD/tagdocs.dtd
<br />
perl -p -i -e 's/\)\*\(/\)\*,\(/' DTD/textstructure.dtd
<br />
(cd DTD; ln -s tei.dtd tei2.dtd)
<br />
roma "--localsource=Source-driver.xml" --nodtd --noxsd --xsl=/tmp/tei/share/xml/tei/stylesheet/ --teiserver=http://tei.oucs.ox.ac.uk/Query/ p5odds.odd .
<br />
WARNING: Unrecognized option '--localsource=Source-driver.xml' ignored
<br />
For usage syntax issue /Users/chris/bin/roma --help
<br />
========= 2005-09-10 08:06:26 Roma starts, info:
<br />
Test for software: xmllint, xsltproc, trang, and perl
<br />
/sw/bin/xmllint
<br />
/sw/bin/xsltproc
<br />
/Users/chris/bin/trang
<br />
/usr/bin/perl
<br />
TEI database server: http://tei.oucs.ox.ac.uk/Query/
<br />
TEI stylesheet tree: /tmp/tei/share/xml/tei/stylesheet/
<br />

<p>ERROR: stylesheet location /tmp/tei/share/xml/tei/stylesheet/ is not accessible.
<br />
This was a fatal error. 2005-09-10 08:06:27.N
<br />
make: *** [oddschema] Error 1
<br />

</code>
<br />

This is a bit odd (pardon the pun), since the stuff sits there under
<br />
/tmp/tei and just waits to be used:
<br />

  /tmp/tei/share/xml/tei/stylesheet:
<br />
  total used in directory 60 available 2647112
<br />
  drwxr-xr-x   12 root     staff         408 Sep 10 08:02 .
<br />
  drwxr-xr-x    3 root     wheel         102 Sep 10 08:02 ..
<br />
  drwxr-xr-x    9 root     staff         306 Sep 10 08:02 common
<br />
  drwxr-xr-x   15 root     staff         510 Sep 10 08:02 fo
<br />
  drwxr-xr-x   14 root     staff         476 Sep 10 08:02 html
<br />
  -rw-r--r--    1 root     staff       29941 Sep 10 08:02 i18n.xml
<br />
  drwxr-xr-x   14 root     staff         476 Sep 10 08:02 latex
<br />
  drwxr-xr-x   17 root     staff         578 Sep 10 08:02 odds
<br />
  drwxr-xr-x    4 root     staff         136 Sep 10 08:02 slides
<br />
  -rw-r--r--    1 root     staff        8306 Sep 10 08:02 tei.css
<br />
  -rw-r--r--    1 root     staff       10167 Sep 10 08:02 teic.css
<br />
  -rw-r--r--    1 root     staff        3370 Sep 10 08:02 teislides.css
<br />

<p>Well, I think Sebastian will need to look on this once more.  
<br />

But anyhow, except for this little glitch, I am now able to get a
<br />
working P5 on my Mac OS powerbook following these instructions. Heureka!
<br />

However, the non-obvious pre-requisites (Saxon, perl, trang, jing,
<br />
xmllint) are not mentioned in the doc -- it would be convenient to
<br />
point people to the relevant locations.  
<br />

And before we announce this to TEI-L, it would be good if some brave
<br />
soul could try this out on a Windows machine...
<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> Fri Sep 09 2005 - 19:18:53 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Sep  9 19:28:26 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 10 Sep 2005 08:28:26 +0900
Subject: [tei-council] first crack at notes from this morning's call
In-Reply-To: <17185.62432.449625.228190@emt.wwp.brown.edu>
Message-ID: <ygfhdctizxh.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 10 Sep 2005 08:28:26 +0900</span><br />
</address>

Syd Bauman <Syd_Bauman_at_Brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev1">> Notes are at
</em><br />
<em class="quotelev1">>   http://www.tei-c.org/Council/tcm19.xml?style=printable
</em><br />

Thanks, that was quick.  
<br />

I forgot what I pointed out in the first section, so you might just
<br />
delete that part.  The deadline for that item seems a bit pessimistic
<br />
-- I would say at least those attending the class meeting should be
<br />
able to have a spinning P5 on their harddrive -- how about 2005-09-18?
<br />

The call yesterday came after a unusually long and busy week here, and
<br />
I appreciate your patience with my slightly unfocussed chairing.
<br />
Thank you all for your contributions and efforts.
<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> Fri Sep 09 2005 - 19:28:35 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Sep  9 19:57:44 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 10 Sep 2005 08:57:44 +0900
Subject: [tei-council] Re: tcw06.xml
In-Reply-To: <ygfll25j0dk.fsf@chwpb.local>
Message-ID: <ygfd5nhiykn.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Sat, 10 Sep 2005 08:57:44 +0900</span><br />
</address>

Christian Wittern <wittern_at_kanji.<!--nospam-->zinbun.kyoto-u.ac.jp> writes:
<br />

<em class="quotelev1">> roma "--localsource=Source-driver.xml" --nodtd --noxsd --xsl=/tmp/tei/share/xml/tei/stylesheet/ --teiserver=http://tei.oucs.ox.ac.uk/Query/ p5odds.odd .
</em><br />
<em class="quotelev1">> WARNING: Unrecognized option '--localsource=Source-driver.xml' ignored
</em><br />
<em class="quotelev1">> For usage syntax issue /Users/chris/bin/roma --help
</em><br />

(Slowly waking up) Looking at this more carefully, I see that it is
<br />
calling an old version of roma which happens to be on the path.  It
<br />
will probably be a good idea to explicitly use the roma that had been
<br />
installed in the previous step in $PREFIX/bin.  Again, this is an
<br />
issue with the software, not the documentation.  
<br />

This time it seems to run through without glitch. 
<br />

All the best and a nice weekend to everybody,
<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 Sep 09 2005 - 19:57:52 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sat Sep 10 06:03:16 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 10 Sep 2005 11:03:16 +0100
Subject: [tei-council] Re: tcw06.xml
In-Reply-To: <ygfd5nhiykn.fsf@chwpb.local>
Message-ID: <4322AF64.3000209@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, 10 Sep 2005 11:03:16 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>calling an old version of roma which happens to be on the path.  It
</em><br />
<em class="quotelev1">>will probably be a good idea to explicitly use the roma that had been
</em><br />
<em class="quotelev1">>installed in the previous step in $PREFIX/bin.  Again, this is an
</em><br />
<em class="quotelev1">>issue with the software, not the documentation.  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I'll change the P5/Exemplars/Makefile to call $PREFIX/bin/roma
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sat Sep 10 2005 - 06:03:35 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sat Sep 10 06:08:50 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 10 Sep 2005 11:08:50 +0100
Subject: [tei-council] Re: tcw06.xml
In-Reply-To: <ygfll25j0dk.fsf@chwpb.local>
Message-ID: <4322B0B2.6030708@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, 10 Sep 2005 11:08:50 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>However, the non-obvious pre-requisites (Saxon, perl, trang, jing,
</em><br />
<em class="quotelev1">>xmllint) are not mentioned in the doc -- it would be convenient to
</em><br />
<em class="quotelev1">>point people to the relevant locations.  
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
James, I guess this in your ball court.
<br />

Note that  saxon is not a prerequisite for most people,
<br />
since they won't have xsltdoc
<br />

<em class="quotelev1">>And before we announce this to TEI-L, it would be good if some brave
</em><br />
<em class="quotelev1">>soul could try this out on a Windows machine...
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I don't think its conceivable it will work. It is designed
<br />
to work in a Unix environment, and I don't have any idea
<br />
at all what may be needed to make the scripts work under Windows.
<br />

The schemas, xsl, etc would normally be installed from "compiled" form
<br />
anyway, and have no OS-dependencies. The "roma" script is written
<br />
in the shell language; it _could_be rewritten in Perl or Ruby or something
<br />
which might run under Windoze, but how many Windows people know
<br />
the existence of a command-line? Ideally, someone would rewrite it as pretty
<br />
GUI thang in Java, which would be quite easy. I don't have the skills
<br />
myself,
<br />
sadly.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sat Sep 10 2005 - 06:09:09 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sat Sep 10 14:12:04 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 10 Sep 2005 19:12:04 +0100
Subject: [tei-council] datatype issues (part 1)
Message-ID: <432321F4.2070405@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, 10 Sep 2005 19:12:04 +0100</span><br />
</address>

Working through the datatype definitions, I have so far identified the 
<br />
following issues. Comments and corrections on these would be much 
<br />
appreciated, especially if it comes in the next few days.
<br />

1. <specDesc ident="tei.data.xxxx"/> will extract the <desc> from the 
<br />
referenced macroSpec. It would be nice also to be able to extract the 
<br />
<content> or <stringVal> part for display.
<br />

2. The definition of <macroSpec> allows it to contain multiple <content> 
<br />
or <stringVal> children. Why?
<br />

3. tei.data.certainty is defined as either an enumeration ("high", 
<br />
"low", "medium", "unknown")  or a reference to tei.data.probability, 
<br />
which is a real value between 0,1 or an integer between 0,100. I wonder 
<br />
if it wouldn't be less confusing to restrict the values for 
<br />
tei.data.certainty to the literal only, since any attribute for which we 
<br />
to allow either kind of value can do so by giving an alternation of 
<br />
datatypes (I think)
<br />

 4. tei.datatype.language is isomorphic with xsd:language: do we need it?
<br />

5. tei.data.regexp is used only  in two rather obscure places: do we 
<br />
need it? If we do, is the reference to appx. F of the xsd spec really 
<br />
the canonical place to define what sort of regexp we mean ?
<br />

6. tei.data.sex defines four alphabetic values (m f x u) which 
<br />
correspond to ISO 5218 numeric codes 1 2 0 and 9. Should we not rather 
<br />
use the ISO codes?
<br />

7. Furthermore, where (as with sex) the datatype is a closed 
<br />
enumeration, it makes sense to represent this in the macrospec as a 
<br />
<rng:choice> containing several <rng:value>s. But there is currently no 
<br />
scope to  provide a gloss for what each value means, since <valList> is 
<br />
not allowed within <macrospec>.
<br />

8. In earlier discussion I had proposed that tei.data.token should 
<br />
differ from rng:token in that the former should not permit included 
<br />
whitespace.  Thinking about this again, I think I might have been wrong: 
<br />
it might be less confusing to use <rng:token> directly wherever we want 
<br />
a "tei.data.token", thus allowing people to use XML whitespace 
<br />
normalization in attribute values in the same way as they can in 
<br />
content. If we do define tei.data.token as proposed (i.e. as an 
<br />
xsd:token with a facet saying that whitespace is not allowed), we should 
<br />
really give it a different name, or expect to spend the rest of eternity 
<br />
explaining why our usage differs from W3C and RNG's (ok, we were there 
<br />
first, but still). Same applies, mutatis mutandis, to tei.data.tokens: 
<br />
it might indeed be simpler to define that as xsd:token rather than as a 
<br />
list of our weird tei.data.tokens. On the other hand....
<br />

That's something to be going on with. I'm going to have a cup of tea AND 
<br />
A BISCUIT now.
<br />

Lou
<br />

<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> Sat Sep 10 2005 - 14:01:07 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sat Sep 10 14:11:38 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 10 Sep 2005 19:11:38 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432321F4.2070405@computing-services.oxford.ac.uk>
Message-ID: <432321DA.3060703@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, 10 Sep 2005 19:11:38 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">> 1. <specDesc ident="tei.data.xxxx"/> will extract the <desc> from the
</em><br />
<em class="quotelev1">> referenced macroSpec. It would be nice also to be able to extract the
</em><br />
<em class="quotelev1">> <content> or <stringVal> part for display.
</em><br />

a detail.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 2. The definition of <macroSpec> allows it to contain multiple
</em><br />
<em class="quotelev1">> <content> or <stringVal> children. Why?
</em><br />
<em class="quotelev1">>
</em><br />
an oversight? hard to conceive of a reason...
<br />

<em class="quotelev1">> 3. tei.data.certainty is defined as either an enumeration ("high",
</em><br />
<em class="quotelev1">> "low", "medium", "unknown")  or a reference to tei.data.probability,
</em><br />
<em class="quotelev1">> which is a real value between 0,1 or an integer between 0,100. I
</em><br />
<em class="quotelev1">> wonder if it wouldn't be less confusing to restrict the values for
</em><br />
<em class="quotelev1">> tei.data.certainty to the literal only, since any attribute for which
</em><br />
<em class="quotelev1">> we to allow either kind of value can do so by giving an alternation of
</em><br />
<em class="quotelev1">> datatypes (I think)
</em><br />

absolutely.  much clearer
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 4. tei.datatype.language is isomorphic with xsd:language: do we need it?
</em><br />

that applies to other cases, surely? for elegance, yes.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 5. tei.data.regexp is used only  in two rather obscure places: do we
</em><br />
<em class="quotelev1">> need it? If we do, is the reference to appx. F of the xsd spec really
</em><br />
<em class="quotelev1">> the canonical place to define what sort of regexp we mean ?
</em><br />

pass. but sounds dumpable.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 6. tei.data.sex defines four alphabetic values (m f x u) which
</em><br />
<em class="quotelev1">> correspond to ISO 5218 numeric codes 1 2 0 and 9. Should we not rather
</em><br />
<em class="quotelev1">> use the ISO codes?
</em><br />

it would be consistent of me to say "yes", so I will say "yes".  tho
<br />
pragmatically its a pain
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 7. Furthermore, where (as with sex) the datatype is a closed
</em><br />
<em class="quotelev1">> enumeration, it makes sense to represent this in the macrospec as a
</em><br />
<em class="quotelev1">> <rng:choice> containing several <rng:value>s. But there is currently
</em><br />
<em class="quotelev1">> no scope to  provide a gloss for what each value means, since
</em><br />
<em class="quotelev1">> <valList> is not allowed within <macrospec>.
</em><br />

allow valList within <macroSpec>, then.  important that it be glossable
<br />
- especially for that sex example!
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> That's something to be going on with. I'm going to have a cup of tea
</em><br />
<em class="quotelev1">> AND A BISCUIT now.
</em><br />
<em class="quotelev1">>
</em><br />
i can smell the baked potatoes.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sat Sep 10 2005 - 14:11:49 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sat Sep 10 22:29:27 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 11 Sep 2005 11:29:27 +0900
Subject: [tei-council] Re: tcw06.xml
In-Reply-To: <4322B0B2.6030708@oucs.ox.ac.uk>
Message-ID: <ygf3bocgwvs.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 11 Sep 2005 11:29:27 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk> writes:
<br />

<em class="quotelev1">> Christian Wittern wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>However, the non-obvious pre-requisites (Saxon, perl, trang, jing,
</em><br />
<em class="quotelev2">>>xmllint) are not mentioned in the doc -- it would be convenient to
</em><br />
<em class="quotelev2">>>point people to the relevant locations.  
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> James, I guess this in your ball court.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Note that  saxon is not a prerequisite for most people,
</em><br />
<em class="quotelev1">> since they won't have xsltdoc
</em><br />

Right, but then you need xsltproc, which is in the same package as
<br />
xmllint I guess.
<br />

<p><em class="quotelev2">>>And before we announce this to TEI-L, it would be good if some brave
</em><br />
<em class="quotelev2">>>soul could try this out on a Windows machine...
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> I don't think its conceivable it will work. It is designed
</em><br />
<em class="quotelev1">> to work in a Unix environment, and I don't have any idea
</em><br />
<em class="quotelev1">> at all what may be needed to make the scripts work under Windows.
</em><br />

Fine, so the way for Windows users to follow the TEI development would
<br />
be to stick to SF releases and submit the ODD files they produce to
<br />
the Roma webservice.  That sounds fair enough, but maybe we should
<br />
mention that in the CVS howto as well. 
<br />

<p>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> Sat Sep 10 2005 - 22:29:45 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sat Sep 10 22:41:15 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 11 Sep 2005 11:41:15 +0900
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432321F4.2070405@computing-services.oxford.ac.uk>
Message-ID: <ygfy864fhro.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 11 Sep 2005 11:41:15 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Working through the datatype definitions, I have so far identified the
</em><br />
<em class="quotelev1">> following issues. Comments and corrections on these would be much
</em><br />
<em class="quotelev1">> appreciated, especially if it comes in the next few days.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 1. <specDesc ident="tei.data.xxxx"/> will extract the <desc> from the
</em><br />
<em class="quotelev1">>    referenced macroSpec. It would be nice also to be able to extract
</em><br />
<em class="quotelev1">>    the <content> or <stringVal> part for display.
</em><br />

In that case maybe <getTarget type="content|stringVal|desc" ident=""/>
<br />
would do the trick.
<br />

<em class="quotelev1">> 2. The definition of <macroSpec> allows it to contain multiple
</em><br />
<em class="quotelev1">>    <content> or <stringVal> children. Why?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 3. tei.data.certainty is defined as either an enumeration ("high",
</em><br />
<em class="quotelev1">>    "low", "medium", "unknown")  or a reference to
</em><br />
<em class="quotelev1">>    tei.data.probability, which is a real value between 0,1 or an
</em><br />
<em class="quotelev1">>    integer between 0,100. I wonder if it wouldn't be less confusing to
</em><br />
<em class="quotelev1">>    restrict the values for tei.data.certainty to the literal only,
</em><br />
<em class="quotelev1">>    since any attribute for which we to allow either kind of value can
</em><br />
<em class="quotelev1">>    do so by giving an alternation of datatypes (I think)
</em><br />

This sounds reasonable to me.
<br />

<em class="quotelev1">>  4. tei.datatype.language is isomorphic with xsd:language: do we
</em><br />
<em class="quotelev1">>  need it?
</em><br />

I have asked this before.  We have to think how this fits in with
<br />
@xml:lang and <language>. 
<br />

<em class="quotelev1">> 5. tei.data.regexp is used only  in two rather obscure places: do we
</em><br />
<em class="quotelev1">>    need it? If we do, is the reference to appx. F of the xsd spec
</em><br />
<em class="quotelev1">>    really the canonical place to define what sort of regexp we mean
</em><br />
<em class="quotelev1">>    ?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 6. tei.data.sex defines four alphabetic values (m f x u) which
</em><br />
<em class="quotelev1">>    correspond to ISO 5218 numeric codes 1 2 0 and 9. Should we not
</em><br />
<em class="quotelev1">>    rather use the ISO codes?
</em><br />

Hmm.  This raises the general question of how far we want to go in
<br />
pulling in the relevant standards and keeping our descriptions in
<br />
synch. Also, I would rather have some layer of human-readability here,
<br />
which could then under the hood be mapped to the relevant codes. mfxu
<br />
is just so much more intuitive than 1209.  The same issue came also up
<br />
with durations, P35Y vs. 35yrs.  At some point, we planned to have the
<br />
tei.* stuff provide this layer -- is this what Syd is the underlying
<br />
assumption that turned out to be not workable?  In that case, we have
<br />
to rethink the whole strategy, I am afraid. 
<br />

<em class="quotelev1">> 7. Furthermore, where (as with sex) the datatype is a closed
</em><br />
<em class="quotelev1">>    enumeration, it makes sense to represent this in the macrospec as a
</em><br />
<em class="quotelev1">>    <rng:choice> containing several <rng:value>s. But there is
</em><br />
<em class="quotelev1">>    currently no scope to  provide a gloss for what each value means,
</em><br />
<em class="quotelev1">>    since <valList> is not allowed within <macrospec>.
</em><br />

Maybe that should be changed then?  
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 8. In earlier discussion I had proposed that tei.data.token should
</em><br />
<em class="quotelev1">>    differ from rng:token in that the former should not permit included
</em><br />
<em class="quotelev1">>    whitespace.  Thinking about this again, I think I might have been
</em><br />
<em class="quotelev1">>    wrong: it might be less confusing to use <rng:token> directly
</em><br />
<em class="quotelev1">>    wherever we want a "tei.data.token", thus allowing people to use
</em><br />
<em class="quotelev1">>    XML whitespace normalization in attribute values in the same way as
</em><br />
<em class="quotelev1">>    they can in content. If we do define tei.data.token as proposed
</em><br />
<em class="quotelev1">>    (i.e. as an xsd:token with a facet saying that whitespace is not
</em><br />
<em class="quotelev1">>    allowed), we should really give it a different name, or expect to
</em><br />
<em class="quotelev1">>    spend the rest of eternity explaining why our usage differs from
</em><br />
<em class="quotelev1">>    W3C and RNG's (ok, we were there first, but still). Same applies,
</em><br />
<em class="quotelev1">>    mutatis mutandis, to tei.data.tokens: it might indeed be simpler to
</em><br />
<em class="quotelev1">>    define that as xsd:token rather than as a list of our weird
</em><br />
<em class="quotelev1">>    tei.data.tokens. On the other hand....
</em><br />

Yeah.  a token is a token is a token.  We won't be able to change
<br />
that.
<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> Sat Sep 10 2005 - 22:41:20 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Sun Sep 11 06:28:28 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 11 Sep 2005 11:28:28 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <ygfy864fhro.fsf@chwpb.local>
Message-ID: <432406CC.8030106@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>: Sun, 11 Sep 2005 11:28:28 +0100</span><br />
</address>

Christian Wittern wrote:
<br />
<em class="quotelev2">>>6. tei.data.sex defines four alphabetic values (m f x u) which
</em><br />
<em class="quotelev2">>>   correspond to ISO 5218 numeric codes 1 2 0 and 9. Should we not
</em><br />
<em class="quotelev2">>>   rather use the ISO codes?
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Hmm.  This raises the general question of how far we want to go in
</em><br />
<em class="quotelev1">> pulling in the relevant standards and keeping our descriptions in
</em><br />
<em class="quotelev1">> synch. Also, I would rather have some layer of human-readability here,
</em><br />
<em class="quotelev1">> which could then under the hood be mapped to the relevant codes. mfxu
</em><br />
<em class="quotelev1">> is just so much more intuitive than 1209.  The same issue came also up
</em><br />
<em class="quotelev1">> with durations, P35Y vs. 35yrs.  At some point, we planned to have the
</em><br />
<em class="quotelev1">> tei.* stuff provide this layer -- is this what Syd is the underlying
</em><br />
<em class="quotelev1">> assumption that turned out to be not workable?  In that case, we have
</em><br />
<em class="quotelev1">> to rethink the whole strategy, I am afraid. 
</em><br />

I was worried about this as well.  I like the idea of following the 
<br />
ISO standard, but 0 1 2 or 9 isn't very human readable to me.  (I'm 
<br />
assuming by the way that we are talking about ISO5218:2004 not 
<br />
5218:1977, does anyone know what the differences might be?)  Is there 
<br />
any benefit in allowing both or having one mapped to the other? Or, as 
<br />
Christian asks, is this what proved unworkable?
<br />

Trying to find out more about hte 2004 version, I discovered the UK 
<br />
government's recommended use of ISO 5218:2004 in their data standards 
<br />
catalogue.  I see that this version hasn't added values for 
<br />
transgendered individuals etc. as I thought it might have.  (They 
<br />
simply seem to suggest recording sex at registration and current sex.) 
<br />
http://www.govtalk.gov.uk/gdsc/html/frames/PersonGenderCurrent-2-0-Release.htm 
<br />

<p>Is there a way to have someone put 'm' and it be understood in the 
<br />
schema as iso 5218's '1'?  (Or put 35yrs and it be understood as P35Y 
<br />
?)  Or does this just defeat the point of standards...
<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 Sep 11 2005 - 06:28:29 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sun Sep 11 07:58:50 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 11 Sep 2005 12:58:50 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432406CC.8030106@computing-services.oxford.ac.uk>
Message-ID: <43241BFA.9010703@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, 11 Sep 2005 12:58:50 +0100</span><br />
</address>

Warning: this post contains unintended innuendos. Oooo mrs.
<br />

James Cummings wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Is there a way to have someone put 'm' and it be understood in the 
</em><br />
<em class="quotelev1">> schema as iso 5218's '1'?  (Or put 35yrs and it be understood as P35Y 
</em><br />
<em class="quotelev1">> ?)  Or does this just defeat the point of standards...
</em><br />
<em class="quotelev1">>
</em><br />
Yes, it defeats the point of the exercise. Think dates. You can say 
<br />
<date>wibble</date> if you like, but  once you say <date 
<br />
value="xxxx">wibble</date> your value MUST conform to what the relevant 
<br />
standard says it should be.
<br />

Similarly, with the (one or two) places where sex rears its head **as a 
<br />
coded attribute value**.  It's supposed to be a normalised value: ISO 
<br />
has normalized in this particular way. If you really want to retain the 
<br />
ability to say sex="some-arbitrary-code-i-just-invented" that's a 
<br />
different attribute. We could have both sex and ISOsex I suppose, but 
<br />
maybe that's going too far.
<br />

Look at it another way. I have a very fine tool which knows how to 
<br />
process ISO sex values when it sees them, iff they are expressed in a 
<br />
conformant way. I will not be best pleased if it now has to recognise 
<br />
some arbitrary other set of values as well: in fact, I probably won't 
<br />
bother at all. It's worth my while as a developer to fit in with ISO's 
<br />
whims: I don't know whether or not the TEI is that important yet. 
<br />

My argument is that iff we are going to go to the trouble of normalising 
<br />
attribute values, and there is a pre-existing international norm, then 
<br />
we really have to have much better reasons not to follow it than to say 
<br />
"it's not intuitive". Says who? If you're arabic or chinese, why is "m" 
<br />
more intuitive than "1"? (or "u" than "0")?
<br />

We could have much the same argument about whether we should replace the 
<br />
required values of the xsd "boolean" datatype ((which are "true" and 
<br />
"false") with "0" and "1" or "yes" and "no" ...
<br />

Lou
<br />

p.s. you could in your ODD application redefine tei.data.sex as a 
<br />
different set of values, of course, tho I think you're making life 
<br />
difficult for others if you do
<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> Sun Sep 11 2005 - 07:56:19 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Sep 11 10:06:56 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 11 Sep 2005 10:06:56 -0400
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432321F4.2070405@computing-services.oxford.ac.uk>
Message-ID: <17188.14848.10373.576601@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, 11 Sep 2005 10:06:56 -0400</span><br />
</address>

<em class="quotelev1">> 1. <specDesc ident="tei.data.xxxx"/> will extract the <desc> from
</em><br />
<em class="quotelev1">> the referenced macroSpec. It would be nice also to be able to
</em><br />
<em class="quotelev1">> extract the <content> or <stringVal> part for display.
</em><br />

Yes, it would.
<br />

<p><em class="quotelev1">> 2. The definition of <macroSpec> allows it to contain multiple
</em><br />
<em class="quotelev1">> <content> or <stringVal> children. Why?
</em><br />

I can't come up with a good reason off the top of my head.
<br />

<p><em class="quotelev1">> 3. tei.data.certainty is defined as either an enumeration ("high",
</em><br />
<em class="quotelev1">> "low", "medium", "unknown") or a reference to tei.data.probability,
</em><br />
<em class="quotelev1">> which is a real value between 0,1 or an integer between 0,100. I
</em><br />
<em class="quotelev1">> wonder if it wouldn't be less confusing to restrict the values for
</em><br />
<em class="quotelev1">> tei.data.certainty to the literal only, since any attribute for
</em><br />
<em class="quotelev1">> which we to allow either kind of value can do so by giving an
</em><br />
<em class="quotelev1">> alternation of datatypes (I think)
</em><br />

I don't see that it is less confusing, but it may have the advantage
<br />
of making it easier on the user who wants to modify his ODDs so that
<br />
certainty is expressed only as one or the other. It makes no
<br />
difference to the constraint expressed in the end, so seems like a
<br />
fine idea to me.
<br />

<p><em class="quotelev1">>  4. tei.datatype.language is isomorphic with xsd:language: do we
</em><br />
<em class="quotelev1">>  need it?
</em><br />

We've discussed this at least twice in the past, and have concluded
<br />
that while tei.data.language is not entirely necessary, it would be a
<br />
good place to put information about how one uses xsd:language in TEI
<br />
-- that it is co-referenced with ident= of <language> (optionally if
<br />
it starts with "i-", 2 letters, or 3 letters, required if it starts
<br />
with "x-"). Otherwise this information won't show up in the reference
<br />
documentation at all except perhaps in the tagdoc for <language>
<br />
itself. 
<br />

<p><em class="quotelev1">> 5. tei.data.regexp is used only in two rather obscure places: do we
</em><br />
<em class="quotelev1">> need it? 
</em><br />

I don't think we need it, although again, it may be a useful place to
<br />
put an explanation. 
<br />

<em class="quotelev1">> If we do, is the reference to appx. F of the xsd spec really the
</em><br />
<em class="quotelev1">> canonical place to define what sort of regexp we mean ?
</em><br />

Are you asking
<br />
* whether we want to use W3C XSD regular expressions or would we do
<br />
  better to use some other regular expression language, or
<br />
* whether appendix F is the canonical place to refer to W3C XSD
<br />
  regular expressions?
<br />

I think the answer is "yes" to the former, but could be convinced
<br />
otherwise. The answer is a definitive "I don't know" to the latter.
<br />
(Especially since in the draft of XSD 1.1 it is in appendix H, not
<br />
F.) If we agree that this is the regexp language we want to use, I
<br />
will chase down the proper canonical reference to it (I'm presuming
<br />
there is one ... oh dear).
<br />

<p><em class="quotelev1">> 6. tei.data.sex defines four alphabetic values (m f x u) which
</em><br />
<em class="quotelev1">> correspond to ISO 5218 numeric codes 1 2 0 and 9. Should we not
</em><br />
<em class="quotelev1">> rather use the ISO codes?
</em><br />

Ooohhh ... really good question. Better conformance to external
<br />
standards, or more human-readable values? Tough choice in this case.
<br />
Part of me really wants to just use
<br />
  "not known" | "male" | "female" | "not specified"
<br />
and avoid the question.
<br />

<p><em class="quotelev1">> 7. Furthermore, where (as with sex) the datatype is a closed
</em><br />
<em class="quotelev1">> enumeration, it makes sense to represent this in the macrospec as a
</em><br />
<em class="quotelev1">> <rng:choice> containing several <rng:value>s. But there is
</em><br />
<em class="quotelev1">> currently no scope to provide a gloss for what each value means,
</em><br />
<em class="quotelev1">> since <valList> is not allowed within <macrospec>.
</em><br />

Errr... I'm not sure I internalized that bit of information (that
<br />
<valList> is not permitted within <macroSpec>) when I thought about
<br />
these. I know META has been disbanded, but this really seems like an
<br />
issue that should be looked at and quite possibly changed. <valList>s
<br />
are really the right thing for the job, here.
<br />

<p><em class="quotelev1">> 8. In earlier discussion I had proposed that tei.data.token should
</em><br />
<em class="quotelev1">> differ from rng:token in that the former should not permit included
</em><br />
<em class="quotelev1">> whitespace. Thinking about this again, I think I might have been
</em><br />
<em class="quotelev1">> wrong: it might be less confusing to use <rng:token> directly
</em><br />
<em class="quotelev1">> wherever we want a "tei.data.token", thus allowing people to use
</em><br />
<em class="quotelev1">> XML whitespace normalization in attribute values in the same way as
</em><br />
<em class="quotelev1">> they can in content.
</em><br />

There is no XML whitespace normalization of any content in TEI, yet,
<br />
is there? When we're done straightening out the classes and stuff,
<br />
there may be one or two obscure places where it is useful.
<br />

<em class="quotelev1">> If we do define tei.data.token as proposed (i.e. as an xsd:token
</em><br />
<em class="quotelev1">> with a facet saying that whitespace is not allowed), we should
</em><br />
<em class="quotelev1">> really give it a different name, or expect to spend the rest of
</em><br />
<em class="quotelev1">> eternity explaining why our usage differs from W3C and RNG's (ok,
</em><br />
<em class="quotelev1">> we were there first, but still).
</em><br />

I think a "no internal whitespace" restriction is a really good thing
<br />
to have[1]. But I think you are absolutely right, we should change
<br />
the name. It's not our fault that W3C and RelaxNG deliberately use
<br />
the term "token" in a manner that is counter-intuitive to end users
<br />
(although perhaps makes sense to those writing validators).
<br />
Nonetheless, if we use the same term in the more normal way, we are
<br />
dooming users to even more confusion. Problem is, it's hard to come
<br />
up with an alternative. How about tei.data.term?
<br />

<p><em class="quotelev1">> Same applies, mutatis mutandis, to tei.data.tokens: it might indeed
</em><br />
<em class="quotelev1">> be simpler to define that as xsd:token rather than as a list of our
</em><br />
<em class="quotelev1">> weird tei.data.tokens. On the other hand....
</em><br />

I don't think it matters much. I think it is useful to have the
<br />
parallelism between tei.data.pointer(s) and tei.data.token(s), and
<br />
whatever others may come up. But since they'll provide the same
<br />
constraint, it's not very important.
<br />

<p>Note
<br />

----
[1] Note that I said "internal". Important detail: because W3C Schema
    regular expressions are implicitly anchored,
       <foo type="
       bar"/>
    is not permitted using current definition of tei.data.token.
    Since
      <foo type=
       "bar"/>
    is, of course, permitted, I don't see this as a problem at all,
    and even think it makes thinking about the attribute easier. ("No
    whitespace" vs "no whitespace, except leading and trailing which
    will get trimmed off before comparison for validation") I think
    the restriction on no internal whitespace is important; I think
    the restriction on leading & trailing is a nicety worth having.
_______________________________________________
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 Sep 11 2005 - 10:07:00 EDT</span>
</div>

From Laurent.Romary at loria.fr  Sun Sep 11 11:36:30 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Sun, 11 Sep 2005 17:36:30 +0200
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <17188.14848.10373.576601@emt.wwp.brown.edu>
Message-ID: <432c6d11beae57e26e676af90eb58055@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>: Sun, 11 Sep 2005 17:36:30 +0200</span><br />
</address>

Le 11 sept. 05, ? 16:06, Syd Bauman a ?crit :
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> 6. tei.data.sex defines four alphabetic values (m f x u) which
</em><br />
<em class="quotelev2">>> correspond to ISO 5218 numeric codes 1 2 0 and 9. Should we not
</em><br />
<em class="quotelev2">>> rather use the ISO codes?
</em><br />
<em class="quotelev2">>>
</em><br />

There is also the possibility that we keep the TEI values for our users 
<br />
and use <equiv> to mark the link with ISO values.
<br />
Laurent
<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 Sep 11 2005 - 11:35:27 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep 11 15:27:12 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 11 Sep 2005 20:27:12 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432c6d11beae57e26e676af90eb58055@loria.fr>
Message-ID: <43248510.70009@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, 11 Sep 2005 20:27:12 +0100</span><br />
</address>

Laurent Romary wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> There is also the possibility that we keep the TEI values for our
</em><br />
<em class="quotelev1">> users and use <equiv> to mark the link with ISO values.
</em><br />
<em class="quotelev1">> Laurent
</em><br />
<em class="quotelev1">>
</em><br />
Why set the TEI up as a standards-making body in areas
<br />
for which standards already exist? As Lou said, the point
<br />
of @sex is to produce a standardized form, not something
<br />
that is readable for humans.
<br />

<p><p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Sep 11 2005 - 15:27:29 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep 11 16:19:59 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 11 Sep 2005 21:19:59 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432406CC.8030106@computing-services.oxford.ac.uk>
Message-ID: <4324916F.1070001@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, 11 Sep 2005 21:19:59 +0100</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Is there a way to have someone put 'm' and it be understood in the
</em><br />
<em class="quotelev1">> schema as iso 5218's '1'?  (Or put 35yrs and it be understood as P35Y
</em><br />
<em class="quotelev1">> ?)  Or does this just defeat the point of standards...
</em><br />

if you want to make an editing schema which accepts "m" and "f", and
<br />
then run a transformation to
<br />
canonical form, feel free....
<br />

you can't have your cake and eat it
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Sep 11 2005 - 16:20:09 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep 11 16:21:18 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 11 Sep 2005 21:21:18 +0100
Subject: [tei-council] Re: tcw06.xml
In-Reply-To: <ygf3bocgwvs.fsf@chwpb.local>
Message-ID: <432491BE.3060906@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, 11 Sep 2005 21:21:18 +0100</span><br />
</address>

<em class="quotelev1">>Fine, so the way for Windows users to follow the TEI development would
</em><br />
<em class="quotelev1">>be to stick to SF releases and submit the ODD files they produce to
</em><br />
<em class="quotelev1">>the Roma webservice. 
</em><br />
<em class="quotelev1">>
</em><br />
I don't have a better answer, I am afraid
<br />

<p><p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Sep 11 2005 - 16:21:25 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep 11 16:25:02 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 11 Sep 2005 21:25:02 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <ygfy864fhro.fsf@chwpb.local>
Message-ID: <4324929E.9000501@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, 11 Sep 2005 21:25:02 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Also, I would rather have some layer of human-readability here,
</em><br />
<em class="quotelev1">>which could then under the hood be mapped to the relevant codes. mfxu
</em><br />
<em class="quotelev1">>is just so much more intuitive than 1209.  The same issue came also up
</em><br />
<em class="quotelev1">>with durations, P35Y vs. 35yrs.  At some point, we planned to have the
</em><br />
<em class="quotelev1">>tei.* stuff provide this layer -- is this what Syd is the underlying
</em><br />
<em class="quotelev1">>assumption that turned out to be not workable?  In that case, we have
</em><br />
<em class="quotelev1">>to rethink the whole strategy, I am afraid. 
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
The thing that Syd wanted, which Lou and I claim is unworkable,
<br />
is to have separate enumerated lists for each element which
<br />
shares a global attribute. So no, this isn't it.
<br />

You phrase "under the hood be mapped to the relevant codes"
<br />
sounds nice, but there is no hood under which this can happen!
<br />
If you want your archival XML to have ISO values for sex, but your
<br />
editors seem "mfu", then you have to use an alternate authoring DTD,
<br />
and impose a transformation in your workflow.
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Sep 11 2005 - 16:25:09 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep 11 16:26:33 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 11 Sep 2005 21:26:33 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43241BFA.9010703@computing-services.oxford.ac.uk>
Message-ID: <432492F9.8020801@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, 11 Sep 2005 21:26:33 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> My argument is that iff we are going to go to the trouble of
</em><br />
<em class="quotelev1">> normalising attribute values, and there is a pre-existing
</em><br />
<em class="quotelev1">> international norm, then we really have to have much better reasons
</em><br />
<em class="quotelev1">> not to follow it than to say "it's not intuitive".
</em><br />

<p>my sentiments exactly.....
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Sep 11 2005 - 16:26:40 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Sun Sep 11 16:33:48 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 11 Sep 2005 21:33:48 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432492F9.8020801@oucs.ox.ac.uk>
Message-ID: <432494AC.2090605@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>: Sun, 11 Sep 2005 21:33:48 +0100</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev1">> Lou Burnard wrote:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>My argument is that iff we are going to go to the trouble of
</em><br />
<em class="quotelev2">>>normalising attribute values, and there is a pre-existing
</em><br />
<em class="quotelev2">>>international norm, then we really have to have much better reasons
</em><br />
<em class="quotelev2">>>not to follow it than to say "it's not intuitive".
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> my sentiments exactly.....
</em><br />

Yup.  I'm convinced.  Ok, so we have sex="1" and value="P36Y"?  I 
<br />
don't mind having a local modification have male/female/unknown and 
<br />
transform it to 1/2/0 if I ever encounter it as a problem.  The 
<br />
benefit of having attribute values being international standards does 
<br />
seem to outweigh any other benefit of knowing at a glance what that 
<br />
value means.  I'm assuming that when slightly cryptic ISO standards 
<br />
like this are use for attribute values that there will be a 
<br />
(simplified) discussion of it in the guidelines and perhaps a pointer 
<br />
to further information on 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> Sun Sep 11 2005 - 16:33:40 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sun Sep 11 19:22:26 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 12 Sep 2005 00:22:26 +0100
Subject: [tei-council] datatypes
Message-ID: <4324BC32.2070906@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, 12 Sep 2005 00:22:26 +0100</span><br />
</address>

A *very preliminary* list of datatypes and their declarations, bearing 
<br />
at least some resemblance to the way they will eventually appear in the 
<br />
revised chapter ST is now available at http://www.tei-c.org/Drafts/DTYPES/
<br />

Please note that I am still fiddling with the ODDs from which this HTML 
<br />
is generated and don't intend to check them into source forge until 
<br />
we're able to generate plausible DTD and RNG declarations from them. 
<br />
Also please note that I haven't yet acted on the suggestions made in 
<br />
response to yesterday's discussion on the list -- so keep those comments 
<br />
coming in...
<br />

Lou
<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 Sep 11 2005 - 19:20:06 EDT</span>
</div>

From pwillett at umich.edu  Sun Sep 11 21:15:18 2005
From: pwillett at umich.edu (Perry Willett)
Date: Sun, 11 Sep 2005 21:15:18 -0400 (EDT)
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432494AC.2090605@computing-services.oxford.ac.uk>
Message-ID: <Pine.LNX.4.63.0509112113350.24140@arkanoid.gpcc.itd.umich.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Perry Willett <pwillett_at_umich.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 11 Sep 2005 21:15:18 -0400 (EDT)</span><br />
</address>

I'm all for following the ISO standards on this too. People
<br />
will get used to the values fairly quickly as they use them.
<br />

Perry Willett
<br />
University of Michigan
<br />
pwillett_at_umich.<!--nospam-->edu
<br />

<p>On Sun, 11 Sep 2005, James Cummings wrote:
<br />

<em class="quotelev1">> Sebastian Rahtz wrote:
</em><br />
<em class="quotelev2">>> Lou Burnard wrote:
</em><br />
<em class="quotelev2">>> 
</em><br />
<em class="quotelev2">>> 
</em><br />
<em class="quotelev3">>>> My argument is that iff we are going to go to the trouble of
</em><br />
<em class="quotelev3">>>> normalising attribute values, and there is a pre-existing
</em><br />
<em class="quotelev3">>>> international norm, then we really have to have much better reasons
</em><br />
<em class="quotelev3">>>> not to follow it than to say "it's not intuitive".
</em><br />
<em class="quotelev2">>> 
</em><br />
<em class="quotelev2">>> my sentiments exactly.....
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Yup.  I'm convinced.  Ok, so we have sex="1" and value="P36Y"?  I don't mind 
</em><br />
<em class="quotelev1">> having a local modification have male/female/unknown and transform it to 
</em><br />
<em class="quotelev1">> 1/2/0 if I ever encounter it as a problem.  The benefit of having attribute 
</em><br />
<em class="quotelev1">> values being international standards does seem to outweigh any other benefit 
</em><br />
<em class="quotelev1">> of knowing at a glance what that value means.  I'm assuming that when 
</em><br />
<em class="quotelev1">> slightly cryptic ISO standards like this are use for attribute values that 
</em><br />
<em class="quotelev1">> there will be a (simplified) discussion of it in the guidelines and perhaps a 
</em><br />
<em class="quotelev1">> pointer to further information on it?
</em><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.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">>
</em><br />
_______________________________________________
<br />
tei-council mailing list
<br />
tei-council_at_lists.village.Virginia.EDU
<br />
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
<br />
<span id="received"><dfn>Received on</dfn> Sun Sep 11 2005 - 21:15:21 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Sep 11 22:55:59 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 11 Sep 2005 22:55:59 -0400
Subject: [tei-council] first crack at notes from this morning's call
In-Reply-To: <ygfhdctizxh.fsf@chwpb.local>
Message-ID: <17188.60991.259112.162452@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, 11 Sep 2005 22:55:59 -0400</span><br />
</address>

<em class="quotelev1">> I forgot what I pointed out in the first section, so you might just
</em><br />
<em class="quotelev1">> delete that part. The deadline for that item seems a bit
</em><br />
<em class="quotelev1">> pessimistic -- I would say at least those attending the class
</em><br />
<em class="quotelev1">> meeting should be able to have a spinning P5 on their harddrive --
</em><br />
<em class="quotelev1">> how about 2005-09-18?
</em><br />

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> Sun Sep 11 2005 - 22:56:03 EDT</span>
</div>

From Laurent.Romary at loria.fr  Mon Sep 12 01:09:31 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Mon, 12 Sep 2005 07:09:31 +0200
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43248510.70009@oucs.ox.ac.uk>
Message-ID: <6c37a181af58aacf8ef886c861d7c02a@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, 12 Sep 2005 07:09:31 +0200</span><br />
</address>

There are cases where we act as an interface towards communities which 
<br />
may not like to manipulate formats like numbers for sex. If our users 
<br />
are not deeply used tu m, f etc. then of course we can just move to ISO 
<br />
codes.
<br />

Le 11 sept. 05, ? 21:27, Sebastian Rahtz a ?crit :
<br />

<em class="quotelev1">> Laurent Romary wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> There is also the possibility that we keep the TEI values for our
</em><br />
<em class="quotelev2">>> users and use <equiv> to mark the link with ISO values.
</em><br />
<em class="quotelev2">>> Laurent
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> Why set the TEI up as a standards-making body in areas
</em><br />
<em class="quotelev1">> for which standards already exist? As Lou said, the point
</em><br />
<em class="quotelev1">> of @sex is to produce a standardized form, not something
</em><br />
<em class="quotelev1">> that is readable for humans.
</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">> 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 />
<em class="quotelev1">> OSS Watch: JISC Open Source Advisory Service
</em><br />
<em class="quotelev1">> http://www.oss-watch.ac.uk
</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> Mon Sep 12 2005 - 01:08:27 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Mon Sep 12 14:28:51 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 12 Sep 2005 14:28:51 -0400
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <6c37a181af58aacf8ef886c861d7c02a@loria.fr>
Message-ID: <17189.51427.518938.47525@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, 12 Sep 2005 14:28:51 -0400</span><br />
</address>

For the record, I'm leaning towards ISO numeric codes for sex=.
<br />

However, the argument in favor of more memorable codes is quite a
<br />
strong one.
<br />

<p>LB> Yes, it defeats the point of the exercise. Think dates. You can
<br />
LB> say <date>wibble</date> if you like, but once you say <date
<br />
LB> value="xxxx">wibble</date> your value MUST conform to what the
<br />
LB> relevant standard says it should be.
<br />

Yes indeed, which is possibly a bit of a problem for some TEI
<br />
users, as they may well be interested in calendars other than the
<br />
Gregorian, which is all that ISO 8601 purports to represent.
<br />
(However, lots of people think it's OK to use it for proleptic
<br />
Gregorian, too.)
<br />

<p>LB> Similarly, with the (one or two) places where sex rears its head
<br />
LB> **as a coded attribute value**. It's supposed to be a normalised
<br />
LB> value: ISO has normalized in this particular way. If you really
<br />
LB> want to retain the ability to say sex="some-arbitrary-code-i-
<br />
LB> just-invented" that's a different attribute. We could have both
<br />
LB> sex and ISOsex I suppose, but maybe that's going too far.
<br />

This seems like circular reasoning. The reason sex= is supposed to be
<br />
a normalized value is because the TEI has decided it would be a
<br />
useful thing. If TEI (i.e., us, right here, right now) decide that it
<br />
is not so useful to normalize against ISO 5218, that's fine. We can
<br />
normalize against our own definitions of "m", "f", "u", and "x"
<br />
(although some might call that 'regularization', since the
<br />
definition, although external to the instance, is not external to the
<br />
TEI).
<br />

I'm not aware that anybody has recommended arbitrary codes get made
<br />
up by the user.
<br />

<p>LB> My argument is that iff we are going to go to the trouble of
<br />
LB> normalising attribute values, and there is a pre-existing
<br />
LB> international norm, then we really have to have much better
<br />
LB> reasons not to follow it than to say "it's not intuitive".
<br />

I'm inclined to agree. "It's not intuitive" is probably not a
<br />
sufficient argument on its own.
<br />

<p>LB> Says who? If you're arabic or chinese, why is "m" more intuitive
<br />
LB> than "1"? (or "u" than "0")?
<br />

That's not really fair, in that if you're Arabic or Chinese you'll
<br />
either be dealing with an equally non-intuitive element name (e.g.
<br />
"person") and attribute name (i.e. "sex"), or you will have
<br />
internationalized your schema, including these values.
<br />

<p>LB> We could have much the same argument about whether we should
<br />
LB> replace the required values of the xsd "boolean" datatype ((which
<br />
LB> are "true" and "false") with "0" and "1" or "yes" and "no" ...
<br />

Well, yes, but there the XSD values are just as intuitive, so there's
<br />
really no argument at all. (And actually, since xsd:boolean takes the
<br />
lexical values "true", "false", "1", and "0", if I were to do
<br />
anything to change it I'd probably want to restrict it so only one
<br />
pair of opposites was permitted.)
<br />

<p>LB> p.s. you could in your ODD application redefine tei.data.sex as a
<br />
LB> different set of values, of course, ...
<br />

Absolutely. Which makes me think this isn't really all that
<br />
important.
<br />

<p>JC> I'm assuming that when slightly cryptic ISO standards like this
<br />
JC> are use for attribute values that there will be a (simplified)
<br />
JC> discussion of it in the guidelines and perhaps a pointer to
<br />
JC> further information on it?
<br />

I think that's a requirement.
<br />

<p>SR> If you want your archival XML to have ISO values for sex, but
<br />
SR> your editors seem "mfu", then you have to use an alternate
<br />
SR> authoring DTD, and impose a transformation in your workflow.
<br />

In many many cases this is going to be a really good idea, for lots
<br />
of less sexy reasons than this one.
<br />

<p>SB> Part of me really wants to just use
<br />
SB>   "not known" | "male" | "female" | "not specified"
<br />
SB> and avoid the question.
<br />

BTW, those are the values that 0, 1, 2, and 9 map to in 5218. I.e.,
<br />
use the entire normalized value, not the look-up code to it.
<br />

<p>LR> There is also the possibility that we keep the TEI values for our
<br />
LR> users and use <equiv> to mark the link with ISO values.
<br />

SR> Why set the TEI up as a standards-making body in areas for which
<br />
SR> standards already exist? As Lou said, the point of @sex is to
<br />
SR> produce a standardized form, not something that is readable for
<br />
SR> humans.
<br />

That seems like it might be a bit of a slippery slope. I mean, one
<br />
of the main selling points of XML is that it is human readable. If a
<br />
user wanted to store this information in a manner she could never
<br />
directly read, she could use a proprietary database instead.
<br />
(Although I readily admit that in this particular case the values
<br />
aren't really not human readable, rather they just require the user
<br />
to take an extra step to ascertain meaning; a step they might have to
<br />
take in cases of "u" and "x", anyway.)
<br />

<p>LR> There are cases where we act as an interface towards communities
<br />
LR> which may not like to manipulate formats like numbers for sex.
<br />

Right.
<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 Sep 12 2005 - 14:28:56 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Mon Sep 12 14:43:52 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Mon, 12 Sep 2005 19:43:52 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <17189.51427.518938.47525@emt.wwp.brown.edu>
Message-ID: <4325CC68.1050400@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>: Mon, 12 Sep 2005 19:43:52 +0100</span><br />
</address>

Syd Bauman wrote:
<br />
<em class="quotelev1">> LB> Yes, it defeats the point of the exercise. Think dates. You can
</em><br />
<em class="quotelev1">> LB> say <date>wibble</date> if you like, but once you say <date
</em><br />
<em class="quotelev1">> LB> value="xxxx">wibble</date> your value MUST conform to what the
</em><br />
<em class="quotelev1">> LB> relevant standard says it should be.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Yes indeed, which is possibly a bit of a problem for some TEI
</em><br />
<em class="quotelev1">> users, as they may well be interested in calendars other than the
</em><br />
<em class="quotelev1">> Gregorian, which is all that ISO 8601 purports to represent.
</em><br />
<em class="quotelev1">> (However, lots of people think it's OK to use it for proleptic
</em><br />
<em class="quotelev1">> Gregorian, too.)
</em><br />

Has anyone come up with a standard which represents any possible time, 
<br />
duration, periods, in all known calendars? Or is there a time/date 
<br />
standard that is in any way better ISO 8601?
<br />

One of the other differences I notice with ISO8601 and your patterns 
<br />
is that tei.duration current copes with things at a smaller 
<br />
granularity than 1 second and ISO 8601 doesn't.
<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> Mon Sep 12 2005 - 14:43:40 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Mon Sep 12 14:55:50 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 12 Sep 2005 14:55:50 -0400
Subject: [tei-council] datatypes
In-Reply-To: <4324BC32.2070906@computing-services.oxford.ac.uk>
Message-ID: <17189.53046.97139.966870@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, 12 Sep 2005 14:55:50 -0400</span><br />
</address>

<em class="quotelev1">> A *very preliminary* list of datatypes and their declarations,
</em><br />
<em class="quotelev1">> bearing at least some resemblance to the way they will eventually
</em><br />
<em class="quotelev1">> appear in the revised chapter ST is now available at
</em><br />
<em class="quotelev1">> http://www.tei-c.org/Drafts/DTYPES/
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Please note that I am still fiddling with the ODDs from which this
</em><br />
<em class="quotelev1">> HTML is generated and don't intend to check them into source forge
</em><br />
<em class="quotelev1">> until we're able to generate plausible DTD and RNG declarations
</em><br />
<em class="quotelev1">> from them. Also please note that I haven't yet acted on the
</em><br />
<em class="quotelev1">> suggestions made in response to yesterday's discussion on the list
</em><br />
<em class="quotelev1">> -- so keep those comments coming in...
</em><br />

I don't suppose you want to put these ODDs somewhere I can edit them?
<br />
The workflow of my changing EDW 90, and your copying stuff from there
<br />
to these ODDs seems a bit silly.
<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 Sep 12 2005 - 14:55:52 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Sep 12 15:21:21 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 12 Sep 2005 20:21:21 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <17189.51427.518938.47525@emt.wwp.brown.edu>
Message-ID: <4325D531.6070308@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, 12 Sep 2005 20:21:21 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>LB> Says who? If you're arabic or chinese, why is "m" more intuitive
</em><br />
<em class="quotelev1">>LB> than "1"? (or "u" than "0")?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>That's not really fair, in that if you're Arabic or Chinese you'll
</em><br />
<em class="quotelev1">>either be dealing with an equally non-intuitive element name (e.g.
</em><br />
<em class="quotelev1">>"person") and attribute name (i.e. "sex"), or you will have
</em><br />
<em class="quotelev1">>internationalized your schema, including these values.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
you can internationalize the attribute name and description
<br />
to help the Arabic encoder, and easily get back to canonical TEI,
<br />
with no lossiness. If you start monkeying with allowed values,
<br />
your task immediately becomes noticeably harder (in this case,
<br />
not _that_ hard, but no longer commodity).
<br />

<em class="quotelev1">>SR> If you want your archival XML to have ISO values for sex, but
</em><br />
<em class="quotelev1">>SR> your editors seem "mfu", then you have to use an alternate
</em><br />
<em class="quotelev1">>SR> authoring DTD, and impose a transformation in your workflow.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>In many many cases this is going to be a really good idea, for lots
</em><br />
<em class="quotelev1">>of less sexy reasons than this one.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
hopefully, the talk by self and G Bina in Sofia will discuss
<br />
this sort of thing
<br />

<em class="quotelev1">>That seems like it might be a bit of a slippery slope. I mean, one
</em><br />
<em class="quotelev1">>of the main selling points of XML is that it is human readable.
</em><br />
<em class="quotelev1">>
</em><br />
hmm. the thing about XML is that its text, and so
<br />
easily read by any application, including "cat".
<br />
That's as far as I would go. Can anyone claim <respStmt>
<br />
is "human-readable", in that sense that "sex='m'" is "readable"?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Mon Sep 12 2005 - 15:21:32 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Mon Sep 12 17:55:52 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 12 Sep 2005 22:55:52 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <17189.51427.518938.47525@emt.wwp.brown.edu>
Message-ID: <4325F968.6090002@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, 12 Sep 2005 22:55:52 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>For the record, I'm leaning towards ISO numeric codes for sex=.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
OK, so far the consensus appears to be to grin and bear it and go with 
<br />
ISO codes. I will give it another 24 hours, and then change the tagdoc 
<br />
accordingly.
<br />

At the same time and for much the same reasons, I'm proposing to change 
<br />
the definition for tei.data.duration to be equivalent to xsd:duration 
<br />
only. I can't see any reason not to go with the ISO defined way of 
<br />
indicating duration. The only reason not to would be if you wanted to 
<br />
use an attribute defined as tei.data.duration to record durations in 
<br />
other units (e.g. microseconds, or centuries). Even assuming  anyone 
<br />
came up with a convincing use case the way to do that would be to define 
<br />
a different attribute, I think.
<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 Sep 12 2005 - 17:45:09 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Sep 13 05:49:19 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 13 Sep 2005 10:49:19 +0100
Subject: [tei-council] datatype issues (part 1) continued,,,
In-Reply-To: <17188.14848.10373.576601@emt.wwp.brown.edu>
Message-ID: <4326A09F.1000808@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, 13 Sep 2005 10:49:19 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev2">>>5. tei.data.regexp is used only in two rather obscure places: do we
</em><br />
<em class="quotelev2">>>need it? 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I don't think we need it, although again, it may be a useful place to
</em><br />
<em class="quotelev1">> put an explanation. 
</em><br />
<em class="quotelev1">> 
</em><br />

I propose to change this to tei.data.formula which maps to xsd:token
<br />

The only places it is used at present is for attributes like metDecl 
<br />
which have as their value a string of gobbledegook in some special 
<br />
syntax defined by the TEI. This seems a useful category of information. 
<br />
Calling it regexp suggests to me that it is a (Unix style) regular 
<br />
expression, which it isn't necessarily -- though obviously one could 
<br />
define a reg exp that matched any such formula!
<br />

Whether or not an attribute the value of which *was* a Unix regular 
<br />
expression should use this datatype is a bridge I would prefer to cross 
<br />
when we actually have such an attribute. I would have thought it would 
<br />
be much better as content anyway.
<br />

<p><em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>8. In earlier discussion I had proposed that tei.data.token should
</em><br />
<em class="quotelev2">>>differ from rng:token in that the former should not permit included
</em><br />
<em class="quotelev2">>>whitespace. Thinking about this again, I think I might have been
</em><br />
<em class="quotelev2">>>wrong: it might be less confusing to use <rng:token> directly
</em><br />
<em class="quotelev2">>>wherever we want a "tei.data.token", thus allowing people to use
</em><br />
<em class="quotelev2">>>XML whitespace normalization in attribute values in the same way as
</em><br />
<em class="quotelev2">>>they can in content.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> There is no XML whitespace normalization of any content in TEI, yet,
</em><br />
<em class="quotelev1">> is there? When we're done straightening out the classes and stuff,
</em><br />
<em class="quotelev1">> there may be one or two obscure places where it is useful.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>If we do define tei.data.token as proposed (i.e. as an xsd:token
</em><br />
<em class="quotelev2">>>with a facet saying that whitespace is not allowed), we should
</em><br />
<em class="quotelev2">>>really give it a different name, or expect to spend the rest of
</em><br />
<em class="quotelev2">>>eternity explaining why our usage differs from W3C and RNG's (ok,
</em><br />
<em class="quotelev2">>>we were there first, but still).
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I think a "no internal whitespace" restriction is a really good thing
</em><br />
<em class="quotelev1">> to have[1]. But I think you are absolutely right, we should change
</em><br />
<em class="quotelev1">> the name. It's not our fault that W3C and RelaxNG deliberately use
</em><br />
<em class="quotelev1">> the term "token" in a manner that is counter-intuitive to end users
</em><br />
<em class="quotelev1">> (although perhaps makes sense to those writing validators).
</em><br />
<em class="quotelev1">> Nonetheless, if we use the same term in the more normal way, we are
</em><br />
<em class="quotelev1">> dooming users to even more confusion. Problem is, it's hard to come
</em><br />
<em class="quotelev1">> up with an alternative. How about tei.data.term?
</em><br />
<em class="quotelev1">> 
</em><br />

Not bad, but we do use "term" rather a lot in slightly different ways 
<br />
elsewhere in the Guidelines, and, crucially, in my book a "term" is 
<br />
taken from a human language not an artificial one. So my proposal is now
<br />

1. rename tei.data.token as tei.data.ident, mapping it to NMTOKEN.
<br />
2. tei.data.tokens is a list of tei.data.ident
<br />
3. tei.data.enumerated is a ref to a tei.data.ident
<br />
4. tei.data.key is mapped to NCName
<br />

I hesitated a long time over NMTOKEN and NCName. The former allows 
<br />
hyphens but not underscore; the latter allows underscore but not hyphen. 
<br />
Syd's proposed pattern allows either and also comma. I am open to 
<br />
persuasion that both tei.data.key and tei.data.ident should have the 
<br />
same mapping; less to defining something which is not either NMTOKEN or 
<br />
NCName.
<br />

The distinction between tei.data.key and tei.data.ident is that the 
<br />
latter need not actually map onto anything anywhere, it's just a name.
<br />
So in order of ascending tightness of constraint, we have
<br />

tei.data.enumerated : the value is defined by a valList (type=closed)
<br />
tei.data.code : the value is defined by a pointer to something which 
<br />
must exist
<br />
tei.data.key : the value is defined by an enumeration elsewhere e.g. a 
<br />
database key
<br />
tei.data.ident : the value is a name or identifier of some kind but not 
<br />
necessarily enumerated or enumeratable
<br />

<p>Does that make sense?
<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 Sep 13 2005 - 05:49:23 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Sep 13 07:02:15 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 13 Sep 2005 12:02:15 +0100
Subject: [tei-council] datatype issues (part 1) continued,,,
In-Reply-To: <4326A09F.1000808@oucs.ox.ac.uk>
Message-ID: <4326B1B7.7030008@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, 13 Sep 2005 12:02:15 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I propose to change this to tei.data.formula which maps to xsd:token
</em><br />

not sure I like the word "formula". that seems too precise to me.
<br />
tei.data. notation?
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Not bad, but we do use "term" rather a lot in slightly different ways 
</em><br />
<em class="quotelev1">> elsewhere in the Guidelines, and, crucially, in my book a "term" is 
</em><br />
<em class="quotelev1">> taken from a human language not an artificial one. So my proposal is now
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 1. rename tei.data.token as tei.data.ident, mapping it to NMTOKEN.
</em><br />
<em class="quotelev1">> 2. tei.data.tokens is a list of tei.data.ident
</em><br />
<em class="quotelev1">> 3. tei.data.enumerated is a ref to a tei.data.ident
</em><br />
<em class="quotelev1">> 4. tei.data.key is mapped to NCName
</em><br />

"ident" or "name"? and tei.data.enumerated is probably a ref to xsd:token
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> tei.data.enumerated : the value is defined by a valList (type=closed)
</em><br />

only sometimes. this is still messy
<br />

<em class="quotelev1">> tei.data.code : the value is defined by a pointer to something which 
</em><br />
<em class="quotelev1">> must exist
</em><br />

ok
<br />

<em class="quotelev1">> tei.data.key : the value is defined by an enumeration elsewhere e.g. a 
</em><br />
<em class="quotelev1">> database key
</em><br />

ok
<br />

<em class="quotelev1">> tei.data.ident : the value is a name or identifier of some kind but 
</em><br />
<em class="quotelev1">> not necessarily enumerated or enumeratable
</em><br />

<p>ok
<br />

but tei.data.key is not an NMtoken but a simple string
<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 Sep 13 2005 - 07:04:38 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Sep 13 10:10:35 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 13 Sep 2005 15:10:35 +0100
Subject: [tei-council] And now for something completely different
Message-ID: <4326DDDB.4050805@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, 13 Sep 2005 15:10:35 +0100</span><br />
</address>

This note is NOT about datatypes.
<br />

A colleague is developing a RNG specification for a linguistic 
<br />
application, and wants to embed within it the TEI-ISO module. From his 
<br />
point of view, the best way to do this is to write his own schema and to 
<br />
reference the module in which <fvLib>, <fs> etc. are defined.
<br />

His question is: what URL should he use to reference the current draft 
<br />
for the RNG or RNC schema generated forthis module?
<br />

I told him to download the whole of the latest release from SF and link 
<br />
to a local copy, while we sort this question out....
<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 Sep 13 2005 - 10:10:35 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Sep 14 07:35:37 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 14 Sep 2005 12:35:37 +0100
Subject: [tei-council] And now for something completely different
In-Reply-To: <4326DDDB.4050805@oucs.ox.ac.uk>
Message-ID: <43280B09.5040506@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, 14 Sep 2005 12:35:37 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> His question is: what URL should he use to reference the current draft 
</em><br />
<em class="quotelev1">> for the RNG or RNC schema generated forthis module?
</em><br />

http://www.tei-c.org/release/xml/tei/schema/relaxng/iso-fs.rng
<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 Sep 14 2005 - 07:35:49 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Wed Sep 14 17:40:33 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 14 Sep 2005 22:40:33 +0100
Subject: [tei-council] Datatypes, part 2
Message-ID: <432898D1.7000602@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, 14 Sep 2005 22:40:33 +0100</span><br />
</address>

I have now updated the draft ODDs defining datatypes and regenerated the 
<br />
HTML draft describing them. This draft, which will eventually appear as 
<br />
a subsection of the new ST, still has a lot of holes (in particular 
<br />
there are no examples) but it is intended to be a fairly quick and 
<br />
complete overview of the new datatype system to which we hope to move 
<br />
shortly.  I've made several changes on the basis of comments made so far 
<br />
on this list: please respond quickly if you think it is still seriously 
<br />
wrong, as the next step will be to start allocating existing attributes 
<br />
to the new datatypes, a lengthy and pernickety task which we don't want 
<br />
to do more than once! While waiting for your comments, I will be 
<br />
drafting a little test file to check that validators do actually 
<br />
validate these datatypes in the way the books say they should...
<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> Wed Sep 14 2005 - 17:29:55 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Wed Sep 14 17:44:27 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 14 Sep 2005 22:44:27 +0100
Subject: [tei-council] datatypes part 2 contd
Message-ID: <432899BB.1090900@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, 14 Sep 2005 22:44:27 +0100</span><br />
</address>

p.s.
<br />

For those with short memories or full mailboxes, that HTML draft is at 
<br />
http://www.tei-c.org/Drafts/DTYPES/
<br />

The tagdocs have been checked into  cvs under the P5/Source/ST tree -- 
<br />
but not yet the prose.
<br />
_______________________________________________
<br />
tei-council mailing list
<br />
tei-council_at_lists.village.Virginia.EDU
<br />
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
<br />
<span id="received"><dfn>Received on</dfn> Wed Sep 14 2005 - 17:33:48 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Thu Sep 15 16:50:41 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 15 Sep 2005 21:50:41 +0100
Subject: [tei-council] tei.data.blah
Message-ID: <4329DEA1.2050903@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, 15 Sep 2005 21:50:41 +0100</span><br />
</address>

I have just noticed that using tei.data.blah as the name for the 
<br />
datatype "blah", as recommended in edw90,  gives a tiny opporunity for 
<br />
confusion if we keep the convention that "tei.blah" is the name for the 
<br />
*class* "blah".... especially as we have a class called "data"!
<br />

Just thought I'd mention it....
<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 Sep 15 2005 - 16:40:17 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep 15 17:02:38 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 15 Sep 2005 22:02:38 +0100
Subject: [tei-council] tei.data.blah
In-Reply-To: <4329DEA1.2050903@computing-services.oxford.ac.uk>
Message-ID: <4329E16E.4060106@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, 15 Sep 2005 22:02:38 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">> I have just noticed that using tei.data.blah as the name for the
</em><br />
<em class="quotelev1">> datatype "blah", as recommended in edw90,  gives a tiny opporunity for
</em><br />
<em class="quotelev1">> confusion if we keep the convention that "tei.blah" is the name for
</em><br />
<em class="quotelev1">> the *class* "blah".... especially as we have a class called "data"!
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Just thought I'd mention it....
</em><br />
<em class="quotelev1">>
</em><br />
so call them macro.data.blah
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Thu Sep 15 2005 - 17:02:52 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Thu Sep 15 19:36:49 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 15 Sep 2005 19:36:49 -0400
Subject: [tei-council] back; update
Message-ID: <17194.1425.544565.770039@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, 15 Sep 2005 19:36:49 -0400</span><br />
</address>

Whoooeee! Been out of touch for a bit there, sorry. I had to perform
<br />
a complete system change of my desktop system at work since I last
<br />
posted.[1] In the interim I have been slowly but steadily re-working
<br />
the attributes. I expect to be finished sometime over the weekend,
<br />
and will post then.
<br />

Notes
<br />
-----
<br />
[1] Sebastian might be pleased to hear the new one is an Intel-based
<br />
    Debian system, as opposed to a PPC based Debian system.[2]
<br />
    However, we had worked out all the differences -- I had been
<br />
    building P5 on that system with no trouble for some time.
<br />
[2] But don't worry, James, my laptop still has a PPC based Debian
<br />
    system on which to test your HOWTOs. :-)
<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 Sep 15 2005 - 19:36:58 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sat Sep 17 19:14:27 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 18 Sep 2005 00:14:27 +0100
Subject: [tei-council] Datatypes.... continued
Message-ID: <432CA353.9000105@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, 18 Sep 2005 00:14:27 +0100</span><br />
</address>

I haven't heard any squawks of protest, so assuming people are 
<br />
reasonably happy with the datatypes so far proposed, I've now checked  
<br />
through the list in Syd's table for discrepancies, or things I've 
<br />
overlooked. The executive summary is that I think we need just one new 
<br />
datatype "tei.data.count", which I will add to the list. Otherwise, 
<br />
we're ready to move to implementation, assuming none of the following 
<br />
tidyup is controversial.
<br />

1. add_at_place 
<br />
   addSpan_at_place
<br />
   metDecl_at_type    
<br />
           -->  tei.data.enumerated
<br />

2. tei.pointerGroup_at_domains  
<br />
          -->  tei.data.pointers
<br />

3. schemaSpec_at_start
<br />
    specDesc_at_atts   
<br />
         --> tei.data.names
<br />

4. date_at_precision
<br />
       --> tei.data.certainty
<br />

5. tei.datable_at_dateAttrib
<br />
       --> tei.data.enumerated
<br />

6. locus_at_scheme
<br />
       --> tei.data.name
<br />

7. fragmentPattern_at_pat
<br />
      --> tei.data.notation
<br />

8. schemaSpec_at_namespace
<br />
    elementSpec_at_ns (why isnt it "namespace" btw?)
<br />
       --> these could be xsd:uri as proposed, or tei.data.pointer, but 
<br />
maybe since they have to be
<br />
             real namespace names (i.e. "#foo" won't do) maybe shd be 
<br />
their own datatype?
<br />

9.   tei.declarable_at_default
<br />
     tei.identifiable_at_predeclare
<br />
     metSym_at_terminal
<br />
     numeric_at_trunc
<br />
     binary_at_value                  
<br />
        --> are all xsd:boolean (so "unknown" not allowed) ; could just 
<br />
be tei.data.truthValue with extra rule
<br />

10.  timeline_at_interval
<br />
       when_at_interval   
<br />
       --> tei.data.numeric | -1  (or think of a better way of doing the -1)
<br />

11. several attributes with proposed  datypes of "xsd:NCName" -> 
<br />
tei.data.name
<br />

12. several attributes with proposed datatypes of "xsd:nonNegativeInteger"
<br />
   --> there are enough of these that I propose a new datatype 
<br />
"tei.data.count"
<br />

13. sense_at_level -> tei.<!--nospam-->data.count
<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 Sep 17 2005 - 19:04:13 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Sep 18 00:03:38 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 18 Sep 2005 00:03:38 -0400
Subject: [tei-council] attribute table for ED W 90 updated
Message-ID: <17196.59162.642012.88366@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, 18 Sep 2005 00:03:38 -0400</span><br />
</address>

I've now finished the second pass through the table of attributes
<br />
that goes with ED W 90. The direct link to the PHP interface to it is
<br />
http://dev.stg.brown.edu/staff/Syd_Bauman/edw90.php. 
<br />

At some point Council needs to go through this list and suggest
<br />
changes, fill gaps, say "go ahead", etc. I'm not sure exactly when
<br />
this should be done, since it's obvious from Lou's DTYPES list that
<br />
we need to do quite a bit more work on datatypes first. I'll try to
<br />
get to those tonight, but more likely tomorrow.
<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 Sep 18 2005 - 00:03:50 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Sep 18 01:16:51 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 18 Sep 2005 01:16:51 -0400
Subject: [tei-council] datatypes
In-Reply-To: <4324BC32.2070906@computing-services.oxford.ac.uk>
Message-ID: <17196.63555.177746.535394@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, 18 Sep 2005 01:16:51 -0400</span><br />
</address>

Not surprisingly, my disagreements with this proposed list of
<br />
datatypes fall mostly in the places where it differs from those
<br />
recommended in EDW90 (as I said I was going to modify it on the
<br />
conference call, but haven't bothered since Lou in essence moved the
<br />
declarations to DTYPES).
<br />

* tei.data.probability: Hmmm... this might work. It is a bit
<br />
  confusing. The problem is that, because the recommendation in
<br />
  DTYPES has removed the percent sign, there is no way to distinguish
<br />
  "1" meaning 100% from "1" meaning 1%. However, we could write a
<br />
  prose rule that required users who want to use "1" to mean 100%
<br />
  write it as "1.0" (which, because the percentages are declared as
<br />
  integers, and the check is done on the lexical space, not the value
<br />
  space, could not be a percentage). This seems somewhat fragile to
<br />
  me, so I still think the original idea (requiring a percent sign
<br />
  for percentages) is better, but this one is not implausible.
<br />
  Note also that the EDW90 pattern permits fractions of a percentage,
<br />
  whereas the DTYPES pattern does not. I'm perfectly happy either
<br />
  way. (There is no current application of this datatype where
<br />
  fractional percentages would make any sense at all; one can imagine
<br />
  that it might be used for something else for which more precision
<br />
  would be appropriate, though.) In either case, having now done the
<br />
  calculation to figure out how tiny a number can fit into an
<br />
  xsd:float (~1.4e-45), I am convinced we should change xsd:double
<br />
  to xsd:float.
<br />

* tei.data.numeric: the change removes support for a constituency
<br />
  that we already now about: those who need to enter floating point
<br />
  numbers. Furthermore, I still claim it makes sense to permit
<br />
  percentages. (One could argue, though, that the percentages should
<br />
  be limited to 8 characters maximum (effectively limiting them to 3
<br />
  or 4 decimal places of precision), so that any tei.data.numeric
<br />
  value could fit into 64 bits.)
<br />

Well, I've gotten through group 1, numeric. I hope to tackle the
<br />
others tomorrow.
<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 Sep 18 2005 - 01:17:08 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep 18 02:16:11 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 18 Sep 2005 07:16:11 +0100
Subject: [tei-council] datatypes
In-Reply-To: <17196.63555.177746.535394@emt.wwp.brown.edu>
Message-ID: <432D062B.1020908@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, 18 Sep 2005 07:16:11 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>* tei.data.numeric: the change removes support for a constituency
</em><br />
<em class="quotelev1">>  that we already now about: those who need to enter floating point
</em><br />
<em class="quotelev1">>  numbers.
</em><br />
<em class="quotelev1">>
</em><br />
I thought we went through this on TEI-L, and someone like
<br />
M Beddows showed that the W3C datatypes did do everything
<br />
needed?
<br />

<em class="quotelev1">> Furthermore, I still claim it makes sense to permit
</em><br />
<em class="quotelev1">>  percentages
</em><br />
<em class="quotelev1">>
</em><br />
at first blush, I think a percentage is like a dimension,
<br />
not a numeric (width=23cm, width=88%). mixing
<br />
it in with numeric seems pretty weird. I may well be wrong.
<br />

<em class="quotelev1">> (One could argue, though, that the percentages should
</em><br />
<em class="quotelev1">>  be limited to 8 characters maximum (effectively limiting them to 3
</em><br />
<em class="quotelev1">>  or 4 decimal places of precision), so that any tei.data.numeric
</em><br />
<em class="quotelev1">>  value could fit into 64 bits.)
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
haven't we gone beyond worrying about number of bits
<br />
we use up?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Sep 18 2005 - 02:16:31 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sun Sep 18 07:24:27 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 18 Sep 2005 12:24:27 +0100
Subject: [tei-council] attribute table for ED W 90 updated
In-Reply-To: <17196.59162.642012.88366@emt.wwp.brown.edu>
Message-ID: <432D4E6B.3040905@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, 18 Sep 2005 12:24:27 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>I've now finished the second pass through the table of attributes
</em><br />
<em class="quotelev1">>that goes with ED W 90. The direct link to the PHP interface to it is
</em><br />
<em class="quotelev1">>http://dev.stg.brown.edu/staff/Syd_Bauman/edw90.php. 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>At some point Council needs to go through this list and suggest
</em><br />
<em class="quotelev1">>changes, fill gaps, say "go ahead", etc. 
</em><br />
<em class="quotelev1">>
</em><br />

Indeed yes. The message I posted last night summarized the outstanding 
<br />
issues, as I see them at least.
<br />

<p><em class="quotelev1">>I'm not sure exactly when
</em><br />
<em class="quotelev1">>this should be done, since it's obvious from Lou's DTYPES list that
</em><br />
<em class="quotelev1">>we need to do quite a bit more work on datatypes first. I'll try to
</em><br />
<em class="quotelev1">>get to those tonight, but more likely tomorrow,
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

I am not quite sure what Syd means by "Lou's DTYPES list" and I am 
<br />
completely in the dark as to why he thinks there is "quite a bit more 
<br />
work" to be done! The list of datatypes I circulated last weekend, with 
<br />
the one (or possibly two) extensions I suggested yesterday, seems to me 
<br />
a workable basis for progress, and is almost entirely compatible with 
<br />
the proposals in Syd's edw90 table -- indeed, it is based on same.
<br />

We really have to get this long overdue and not very difficult exercise 
<br />
out of the way before moving on to the class system, which is a much 
<br />
more challenging prospect....
<br />

<p><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">>  
</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> Sun Sep 18 2005 - 07:30:58 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sun Sep 18 07:55:07 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 18 Sep 2005 12:55:07 +0100
Subject: [tei–council] datatypes –– syd's comments
In-Reply-To: <17196.63555.177746.535394@emt.wwp.brown.edu>
Message-ID: <432D559B.9040205@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, 18 Sep 2005 12:55:07 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>* tei.data.probability: Hmmm... this might work. It is a bit
</em><br />
<em class="quotelev1">>  confusing. The problem is that, because the recommendation in
</em><br />
<em class="quotelev1">>  DTYPES has removed the percent sign, there is no way to distinguish
</em><br />
<em class="quotelev1">>  "1" meaning 100% from "1" meaning 1%. 
</em><br />
<em class="quotelev1">>
</em><br />
Ah! good point. But what is your recommendation?
<br />
(a) decide whether probability shd be expressed as a number between 0 
<br />
and 1 or as a number between 0 and 100 and then enforce one of them (if 
<br />
so, which?)
<br />
(b) allow both as alternatives, but require that the latter (1 to 100) 
<br />
is always followed by a percent sign
<br />
(c) leave things as proposed but note the constraint that numbers 
<br />
between 0 and 1 must be expressed including a decimal point.
<br />

Being a lazy person, I have a slight preference for (c) though it's hard 
<br />
to care very much about this:  the total number of attributes affected 
<br />
in the current version of edw90 table is one (1)
<br />

<em class="quotelev1">>* tei.data.numeric: the change removes support for a constituency
</em><br />
<em class="quotelev1">>  that we already now about: those who need to enter floating point
</em><br />
<em class="quotelev1">>  numbers. Furthermore, I still claim it makes sense to permit
</em><br />
<em class="quotelev1">>  percentages. (One could argue, though, that the percentages should
</em><br />
<em class="quotelev1">>  be limited to 8 characters maximum (effectively limiting them to 3
</em><br />
<em class="quotelev1">>  or 4 decimal places of precision), so that any tei.data.numeric
</em><br />
<em class="quotelev1">>  value could fit into 64 bits.)
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I don't completely understand this comment since tei.data.numeric maps 
<br />
to xsd:decimal which does support floating point numbers.  I assume what 
<br />
you mean is that such numbers can't be represented using the 
<br />
mantis+exponent (aka "scientific") notation. So it will permit 
<br />
"1.23456789" but not  "2e0.134"
<br />

Again, I find very few real use cases in the edw90 table -- in fact the 
<br />
only case where I suppose it might be plausible to permit the scientific 
<br />
notation is the value attribute on <numeric> and <num>
<br />

I can't see any use case where you might want to supply a percentage so 
<br />
I am not very enthusiastic about that either. Would tei.data.probability 
<br />
suit them?
<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 Sep 18 2005 - 08:01:33 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Sep 18 11:15:56 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 18 Sep 2005 11:15:56 -0400
Subject: on spec grp 2, datatypes normalized (was "Re: [tei-council] datatypes")
In-Reply-To: <4324BC32.2070906@computing-services.oxford.ac.uk>
Message-ID: <17197.33964.284995.434431@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, 18 Sep 2005 11:15:56 -0400</span><br />
</address>

It seems to make sense to divide these comments up along with the
<br />
clever groupings Lou has used. Thus this one is
<br />

On Specification group 2: Datatypes: normalised
<br />
-- ------------- ----- -- ---------- ----------
<br />

* tei.data.temporal (I like the name better than the previous clumsy
<br />
  "temporalExpression"): the change removes the capability to express
<br />
  a time without seconds. The change also brings the datatype closer
<br />
  in line with being "normalized" to W3C Schema part 2, in the sense
<br />
  that the only component whose value space is not a date or time has
<br />
  been removed.
<br />

  However, as is often the case, I don't think the datatypes
<br />
  described in W3C Schema part 2 would do a particularly good job of
<br />
  modeling or representing humanities data. (Remember, they were
<br />
  written by corporations for corporations.) One might even go so far
<br />
  as to say W3C is a bit dyslexic in the area of dates and times. I
<br />
  concede that I may have missed or be misunderstanding some
<br />
  pertinent detail thereof; and I am going to resist the urge to bash
<br />
  W3C date & time datatypes in general, and will try to stick to the
<br />
  detailed issue at hand. However, so that no one gets the wrong
<br />
  idea, I will note that as much as I can pick holes in W3C
<br />
  representations, they've done a better job than I would have done
<br />
  at first crack, and have what I think is a very good examination of
<br />
  how dates, times, and durations are compared and thus sorted.
<br />

  The problem at hand boils down to the W3C conception of a time:
<br />
  "time represents an instant of time ..." (3.2.8). Thus, to the W3C,
<br />
  "09:07:51" is just a less precise description of some instant,
<br />
  which would be more precisely described as "09:07:51.209831". But
<br />
  in the humanities, I submit, we often need to encode times less
<br />
  precisely than to the instant, or even the second. Requiring
<br />
  seconds (or even thousands thereof) when you're logging incoming
<br />
  support phone calls or web hits makes sense. But requiring them for
<br />
  "They had all frozen at the same time, on a snowy night, seven
<br />
  years before, and after that it was always ten minutes to five in
<br />
  the castle" or "Six in the evening" is problematic. "16:50" says
<br />
  something different than "16:50:00" just as "that building is 14.2
<br />
  meters high" is different than "that building is 14200 millimeters
<br />
  high". The former time denotes a minute (the 1,011th minute of the
<br />
  day), the latter time denotes a second (the 60,601st second of the
<br />
  day). The latter height implies one used a ruler with millimeter
<br />
  markings; the former does not.
<br />

  Rather than suggest TEI should require precision to the second, I'm
<br />
  actually surprised that someone hasn't suggested, for consistency
<br />
  at least, that TEI should permit precision only to the hour. (After
<br />
  all, pending this discussion we permit precision to the year,
<br />
  month, day, minute, and second.)
<br />

  All that said, if we do go with the EDW90 recommendation of
<br />
  permitting times to the minute, the prose should note that it is
<br />
  possible that some processors might not be able to properly compare
<br />
  or sort them. (Unlikely, though, as the W3C algorithm for doing so
<br />
  applies to times without seconds as well as with; see 3.2.7.4.)
<br />

* tei.data.duration: The change removes the capability to express a
<br />
  duration in a more common syntax, sticking only with the W3C syntax
<br />
  that uses the 8601 "format with time-unit designators". Here the
<br />
  difference, as far as I know, is only syntax. My reasoning for
<br />
  recommending we allow more readable syntax is that I think many, if
<br />
  not most, applications within the TEI world would be using these
<br />
  sorts of values more for regularization than for normalization.
<br />
  Admittedly, the W3C datatype performs both functions, if almost
<br />
  unreadably. (Why couldn't they have recommended 8601 alternate
<br />
  syntax?)
<br />

  So I still prefer
<br />
     xsd:duration | xsd:token { pattern =
<br />
     "[0-9]+(\.[0-9]+)? (year|month|week|d|h|min|s|ms|μs" }
<br />
  (Note that is *not* the same as the one in EDW90; this one is,
<br />
  IMHO, much better, and conforms to NIST recommendations (which use
<br />
  SI wherever possible); however, it does not permit expression of a
<br />
  negative duration.) But again, unlike xsd:duration where the
<br />
  semantics are actually different, in this case it is only syntax,
<br />
  so I don't care very much. I just think TEI users are going to be
<br />
  much happier encoding <person age="3 month"> than <person
<br />
  age="P3M"> and <event dur="13 ms"> than <event dur="PT0.013S">.
<br />

* tei.data.sex: We've already hashed this through, and it's only
<br />
  syntax, so again, I don't care much. But I am not sure this one
<br />
  meets "Syd's rule". I think for many TEI applications "u", "m",
<br />
  "f", and "x" (or "not known", "male", "female", "not specified")
<br />
  will be demonstrably significantly better -- the humans will be
<br />
  able to proofread the texts.
<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 Sep 18 2005 - 11:16:09 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sun Sep 18 13:42:49 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 18 Sep 2005 18:42:49 +0100
Subject: on spec grp 2, datatypes normalized (was "Re: [tei-council] datatypes")
In-Reply-To: <17197.33964.284995.434431@emt.wwp.brown.edu>
Message-ID: <432DA719.1010607@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, 18 Sep 2005 18:42:49 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>It seems to make sense to divide these comments up along with the
</em><br />
<em class="quotelev1">>clever groupings Lou has used. Thus this one is
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>On Specification group 2: Datatypes: normalised
</em><br />
<em class="quotelev1">>-- ------------- ----- -- ---------- ----------
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>* tei.data.temporal (I like the name better than the previous clumsy
</em><br />
<em class="quotelev1">>  "temporalExpression"): the change removes the capability to express
</em><br />
<em class="quotelev1">>  a time without seconds. The change also brings the datatype closer
</em><br />
<em class="quotelev1">>  in line with being "normalized" to W3C Schema part 2, in the sense
</em><br />
<em class="quotelev1">>  that the only component whose value space is not a date or time has
</em><br />
<em class="quotelev1">>  been removed.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

This is indeed the case, and reflects a conscious decision to use 
<br />
attribute values here as elsewhere to represent a normalized value, 
<br />
which might indeed be represented in a more nuanced way within the 
<br />
content of the element or by linking elsewhere.
<br />
....
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  Rather than suggest TEI should require precision to the second, I'm
</em><br />
<em class="quotelev1">>  actually surprised that someone hasn't suggested, for consistency
</em><br />
<em class="quotelev1">>  at least, that TEI should permit precision only to the hour. (After
</em><br />
<em class="quotelev1">>  all, pending this discussion we permit precision to the year,
</em><br />
<em class="quotelev1">>  month, day, minute, and second.)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I don't get it. If you want to give a value precise to only a year, 
<br />
month etc. you  can do so using the approved designation, surely? "1900" 
<br />
doesnt mean any particular time in 1900, it just means 1900. Similarly, 
<br />
1900-12 means some time in December 1900. And so on.
<br />

<em class="quotelev1">>  All that said, if we do go with the EDW90 recommendation of
</em><br />
<em class="quotelev1">>  permitting times to the minute, the prose should note that it is
</em><br />
<em class="quotelev1">>  possible that some processors might not be able to properly compare
</em><br />
<em class="quotelev1">>  or sort them. (Unlikely, though, as the W3C algorithm for doing so
</em><br />
<em class="quotelev1">>  applies to times without seconds as well as with; see 3.2.7.4.)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
Surely, the point of using this format is precisely that as many 
<br />
processors as possible will do the right thing with them. Can you give 
<br />
some examples of processors which do not behave correctly when handling 
<br />
ISO 8601 format values? And is there any reason to believe they would 
<br />
make a better fist of handling an arbitrary TEI-invented format instead?
<br />

Similar considerations apply to the other two cases you mention. In the 
<br />
case of duration and sex, we are talking about an encoded value for an 
<br />
attribute, and it makes much better sense to use an ISO- or W3C- 
<br />
recommended encoded value than to make one up.  "Readability" of syntax 
<br />
is a very subjective question which in my view should be given 
<br />
correspondingly less weight. Obviously in any real application the 
<br />
actual values stored in the attribute won't be visible to the end-user 
<br />
anyway: they will be translated into something more friendly.
<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 Sep 18 2005 - 12:39:40 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Sep 18 13:26:13 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 18 Sep 2005 13:26:13 -0400
Subject: on spec grp 3, notations & ptrs (was "Re: [tei-council] datatypes")
In-Reply-To: <4324BC32.2070906@computing-services.oxford.ac.uk>
Message-ID: <17197.41781.746732.957067@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, 18 Sep 2005 13:26:13 -0400</span><br />
</address>

Specification group 3: Datatypes: notations and pointers
<br />
------------- ----- -- ---------- --------- --- --------
<br />

* tei.data.notation: I don't know what this datatype is for or what
<br />
  semantics it carries at all. I'm suspicious that I'd like it if I
<br />
  did know what you had in mind -- but rather than have us guess,
<br />
  perhaps you'd tell us what it's for, and what attributes should be
<br />
  assigned this datatype?
<br />

  On the other hand, no matter what it's for, why use rng:token
<br />
  instead of xsd:token? For that matter, why use either of those
<br />
  instead of tei.data.tokens? (Answer: because in this list, there is
<br />
  no tei.data.token(s) -- what happened to them?)
<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 Sep 18 2005 - 13:26:32 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sun Sep 18 14:50:23 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 18 Sep 2005 19:50:23 +0100
Subject: on spec grp 3, notations & ptrs (was "Re: [tei-council] datatypes")
In-Reply-To: <17197.41781.746732.957067@emt.wwp.brown.edu>
Message-ID: <432DB6EF.2020302@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, 18 Sep 2005 19:50:23 +0100</span><br />
</address>

Mea culpa -- I forgot to update the website at 
<br />
http://www.tei-c.org/Drafts/DTYPES/ as well as checking the changes into 
<br />
CVS.
<br />

Have now done so. Mind you, the Virginia site seems to be down again...
<br />

Syd Bauman wrote:
<br />

<em class="quotelev1">>Specification group 3: Datatypes: notations and pointers
</em><br />
<em class="quotelev1">>------------- ----- -- ---------- --------- --- --------
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>* tei.data.notation: I don't know what this datatype is for or what
</em><br />
<em class="quotelev1">>  semantics it carries at all. I'm suspicious that I'd like it if I
</em><br />
<em class="quotelev1">>  did know what you had in mind -- but rather than have us guess,
</em><br />
<em class="quotelev1">>  perhaps you'd tell us what it's for, and what attributes should be
</em><br />
<em class="quotelev1">>  assigned this datatype?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  On the other hand, no matter what it's for, why use rng:token
</em><br />
<em class="quotelev1">>  instead of xsd:token? For that matter, why use either of those
</em><br />
<em class="quotelev1">>  instead of tei.data.tokens? (Answer: because in this list, there is
</em><br />
<em class="quotelev1">>  no tei.data.token(s) -- what happened to them?)
</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.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">>  
</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> Sun Sep 18 2005 - 13:47:38 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Sep 18 23:30:50 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 18 Sep 2005 23:30:50 -0400
Subject: on spec grp 4, coded values (was "Re: [tei-council] datatypes")
In-Reply-To: <4324BC32.2070906@computing-services.oxford.ac.uk>
Message-ID: <17198.12522.68260.573944@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, 18 Sep 2005 23:30:50 -0400</span><br />
</address>

[Note: despite the In-Reply-To field, this commentary is based on the
<br />
 new version Lou just put out at
<br />
 http://www.tei-c.org.uk/Drafts/DTYPES/ (the main site is down).]
<br />

On Specification group 4: Datatypes: coded values
<br />
-- ------------- ----- -- ---------- ----- ------
<br />

* tei.data.code: the change permits any pointer; the recommendation
<br />
  in ED W 90 is for local pointers only. We've talked about this
<br />
  somewhat over the past few weeks or so, but IIRC, no one has said
<br />
  anything on this issue except Lou and Syd. Lou has said (at least
<br />
  twice) that he thinks it should be a generic pointer, but has not
<br />
  expressed why.
<br />

  I think there are several good reasons to restrict these kinds of
<br />
  references to local pointers.
<br />

  - It mimics what P4 had.
<br />

  - It provides a system (as did ID/IDREF) where the attribute value
<br />
    itself may be used as a code for a useful semantic distinction
<br />
    (thus the name). E.g., new= and old= of <handShift> -- the real
<br />
    details are provided by the <hand> to which they point, but
<br />
    mnemonic values like "#Scribe1brown" and "#Scribe2red" can convey
<br />
    a lot of meaning by themselves, or at least be easy for humans to
<br />
    associate with the appropriate <hand>.
<br />

  - By changing the values of the xml:id= attributes of the elements
<br />
    pointed at (e.g., <hand>), the encoder gets to create the
<br />
    vocabulary used.
<br />

  - People want to know where things point. (Or go -- some of the
<br />
    bigger complaints about P4 are about places where it says that
<br />
    something should be documented "in the TEI header" without saying
<br />
    where in the TEI header.)
<br />

    If we stick to local pointers, we can define the place or places
<br />
    (likely in the TEI header) to where each tei.data.code attribute
<br />
    is supposed to point, document it accordingly, and perhaps write
<br />
    a Schematron rule to verify that it does so.
<br />

    If we permit any pointer, documentation where these things point
<br />
    becomes somewhat harder. E.g., if the new= of <handShift> points
<br />
    to an external file, does it still need to point at a <tei:hand>?
<br />
    Presumably so. But unless the external file is another encoded
<br />
    document that happened to be written by the same scribes, it is
<br />
    likely to be just a project repository for <hand> elements. What
<br />
    goes in the <text> element of that document? We also need to
<br />
    rewrite the prose so that it is clear that the <hand> in one TEI
<br />
    document may well be documenting the handwriting in another.
<br />

  In either case (whether tei.data.code is declared as a pointer or a
<br />
  local pointer), a user could easily switch to the other by
<br />
  modifying her customization ODD file. I think it will provide a
<br />
  more coherent system (and be easier for us to boot) if we provide a
<br />
  local pointer mechanism; users who change it to general pointers
<br />
  will know up front they are making an extension that may change
<br />
  some of the semantics of some bits of the Guidelines.
<br />

* tei.data.enumerated: the change permits whitespace in the values.
<br />
  I'm not sure about this. For consistency with tei.data.name and
<br />
  tei.data.code (as proposed in ED W 90), I think whitespace should
<br />
  not be permitted. Especially in cases of "open" valLists,
<br />
  disallowing whitespace would help users understand that the value
<br />
  should be a code, not a paragraph. On the other hand, is there any
<br />
  really strong reason to insist on things like 
<br />
    <lg type="couplet-alexandrine"> 
<br />
  instead of
<br />
    <lg type="Alexandrine couplet">?
<br />
  Even if we use token w/o the restriction, for consistency it should
<br />
  probably be xsd:token.
<br />

* tei.data.key: the change is from 'xsd:token' to 'rng:string'. I
<br />
  think it should be left as 'xsd:token' just for consistency. There
<br />
  is no difference in validation at all (since there are no
<br />
  enumerated values).
<br />

* tei.data.name: the change is from any string that does not contain
<br />
  whitespace (but may include, e.g., punctuation marks, currency
<br />
  symbols, math symbols, etc.) to an XML NMTOKEN. I am not sure why
<br />
  we'd want to exclude the non-letter, non-digit characters (other
<br />
  than .-_:, which are permitted in NMTOKEN). Why shouldn't the
<br />
  Tibetan Paluta character be allowed?
<br />

* tei.data.names: the change is from multiple occurrences of
<br />
  whitespace-delimited tokens to only one. Despite your claim, Lou,
<br />
  this really must be an error. I bet you meant 
<br />
     tei.data.names = list { tei.data.name+ }
<br />

* tei.data.name(s): the change is from the name "token(s)" to
<br />
  "name(s)". I dunno. Feels very much like out of the frying pan into
<br />
  the fire. While "token" is confusing because W3C mis-named their
<br />
  datatype, "name" is confusing because in fact these values are most
<br />
  likely not proper nouns at all, and have nothing to do with the
<br />
  <name> element, the 'names' class, or the 'naming' class.
<br />
  How about
<br />
  - term
<br />
  - sign
<br />
  - TOKEN
<br />
  - character-sequence
<br />
  - character-sequence-sans-whitespace
<br />
  - charSeq
<br />
  - noWScharSeq
<br />
  - datum ('data' for plural)
<br />
  - the Latin or French word for "token"
<br />
  Oh dear. I'm almost ready to live with the confusion over "token".
<br />

<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 Sep 18 2005 - 23:31:04 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Sep 19 07:12:01 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 19 Sep 2005 20:12:01 +0900
Subject: [tei-council] Re: on spec grp 4, coded values
In-Reply-To: <17198.12522.68260.573944@emt.wwp.brown.edu>
Message-ID: <ygfek7lfh1a.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 19 Sep 2005 20:12:01 +0900</span><br />
</address>

Syd Bauman <Syd_Bauman_at_Brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev1">> [Note: despite the In-Reply-To field, this commentary is based on the
</em><br />
<em class="quotelev1">>  new version Lou just put out at
</em><br />
<em class="quotelev1">>  http://www.tei-c.org.uk/Drafts/DTYPES/ (the main site is down).]
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> On Specification group 4: Datatypes: coded values
</em><br />
<em class="quotelev1">> -- ------------- ----- -- ---------- ----- ------
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> * tei.data.code: the change permits any pointer; the recommendation
</em><br />
<em class="quotelev1">>   in ED W 90 is for local pointers only. We've talked about this
</em><br />
<em class="quotelev1">>   somewhat over the past few weeks or so, but IIRC, no one has said
</em><br />
<em class="quotelev1">>   anything on this issue except Lou and Syd. Lou has said (at least
</em><br />
<em class="quotelev1">>   twice) that he thinks it should be a generic pointer, but has not
</em><br />
<em class="quotelev1">>   expressed why.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>   I think there are several good reasons to restrict these kinds of
</em><br />
<em class="quotelev1">>   references to local pointers.
</em><br />

I assume you are talking about pointers to the current document in the
<br />
ID/IDREF tradition.
<br />

I think I understand your argument, but I have to warn you that I
<br />
think the notion of local gets somehow blurred when you start to have
<br />
things like xinclude and even more if you put your stuff into XML
<br />
databases -- the latter introduce even more complications with the
<br />
notion of collections, which are not the current docuemnt, but also
<br />
not really not local.
<br />

So I am not really convinced the argument local vs remote gets you
<br />
anywhere in the real world, except maybe that it makes the validation
<br />
a lot easier if you want to enforce only #pointers.
<br />

As you see, I am back in circulation and hope to take up some other
<br />
issues as well.
<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 Sep 19 2005 - 07:12:08 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Sep 19 07:14:21 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 19 Sep 2005 20:14:21 +0900
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <432CA353.9000105@computing-services.oxford.ac.uk>
Message-ID: <ygfaci9fgxe.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 19 Sep 2005 20:14:21 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> I haven't heard any squawks of protest, so assuming people are
</em><br />
<em class="quotelev1">> reasonably happy with the datatypes so far proposed, I've now checked
</em><br />
<em class="quotelev1">> through the list in Syd's table for discrepancies, or things I've
</em><br />
<em class="quotelev1">> overlooked. The executive summary is that I think we need just one new
</em><br />
<em class="quotelev1">> datatype "tei.data.count", which I will add to the list. Otherwise,
</em><br />
<em class="quotelev1">> we're ready to move to implementation, assuming none of the following
</em><br />
<em class="quotelev1">> tidyup is controversial.
</em><br />

<p>I have been terribly busy the last two weeks and did not find the time
<br />
necessary to dig into the datatypes arcanea, but I see you sorted it
<br />
out more or less now and it looks pretty fine to me at the moment.
<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> Mon Sep 19 2005 - 07:14:27 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Sep 19 07:23:18 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 19 Sep 2005 20:23:18 +0900
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <432DA719.1010607@computing-services.oxford.ac.uk>
Message-ID: <ygfek7lcndl.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 19 Sep 2005 20:23:18 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev2">>>On Specification group 2: Datatypes: normalised
</em><br />
<em class="quotelev2">>>-- ------------- ----- -- ---------- ----------
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>* tei.data.temporal (I like the name better than the previous clumsy
</em><br />
<em class="quotelev2">>>  "temporalExpression"): the change removes the capability to express
</em><br />
<em class="quotelev2">>>  a time without seconds. The change also brings the datatype closer
</em><br />
<em class="quotelev2">>>  in line with being "normalized" to W3C Schema part 2, in the sense
</em><br />
<em class="quotelev2">>>  that the only component whose value space is not a date or time has
</em><br />
<em class="quotelev2">>>  been removed.
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> This is indeed the case, and reflects a conscious decision to use
</em><br />
<em class="quotelev1">> attribute values here as elsewhere to represent a normalized value,
</em><br />
<em class="quotelev1">> which might indeed be represented in a more nuanced way within the
</em><br />
<em class="quotelev1">> content of the element or by linking elsewhere.
</em><br />
<em class="quotelev1">> ....
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  Rather than suggest TEI should require precision to the second, I'm
</em><br />
<em class="quotelev2">>>  actually surprised that someone hasn't suggested, for consistency
</em><br />
<em class="quotelev2">>>  at least, that TEI should permit precision only to the hour. (After
</em><br />
<em class="quotelev2">>>  all, pending this discussion we permit precision to the year,
</em><br />
<em class="quotelev2">>>  month, day, minute, and second.)
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> I don't get it. If you want to give a value precise to only a year,
</em><br />
<em class="quotelev1">> month etc. you  can do so using the approved designation, surely?
</em><br />
<em class="quotelev1">> "1900" doesnt mean any particular time in 1900, it just means
</em><br />
<em class="quotelev1">> 1900. Similarly, 1900-12 means some time in December 1900. And so
</em><br />
<em class="quotelev1">> on.
</em><br />

It is a timespan, put not a point in time.  This problem raises its
<br />
head regularily when trying to express a Chinese year in ISO, which
<br />
should then be rendered as 1900-02-17 to 1901-01-29.  Any idea how
<br />
this could be expressed on @value for date?
<br />

<em class="quotelev1">> Similar considerations apply to the other two cases you mention. In
</em><br />
<em class="quotelev1">> the case of duration and sex, we are talking about an encoded value
</em><br />
<em class="quotelev1">> for an attribute, and it makes much better sense to use an ISO- or
</em><br />
<em class="quotelev1">> W3C- 
</em><br />
<em class="quotelev1">> recommended encoded value than to make one up.  "Readability" of
</em><br />
<em class="quotelev1">> syntax is a very subjective question which in my view should be given
</em><br />
<em class="quotelev1">> correspondingly less weight. Obviously in any real application the
</em><br />
<em class="quotelev1">> actual values stored in the attribute won't be visible to the end-user
</em><br />
<em class="quotelev1">> anyway: they will be translated into something more friendly.
</em><br />

Well, I grudgingly agree to this now, we probably do the best to
<br />
long-term maintability if we stick with these unwieldy ISO things --
<br />
they will hopefully stay around for a while.
<br />

Alll 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 Sep 19 2005 - 07:23:24 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Sep 19 07:26:31 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 19 Sep 2005 20:26:31 +0900
Subject: [tei-council] Problem with Roma or ODD
Message-ID: <ygfaci9cn88.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 19 Sep 2005 20:26:31 +0900</span><br />
</address>

Given the following ODD fragment,
<br />

                        <elementSpec ident="app" mode="change" module="textcrit">
<br />
                         <attList>
<br />
                                 <attDef ident="resp" usage="opt">
<br />
                                         <desc>Agency responsible for this apparatus entry (usually as given in the text)</desc>
<br />
                                         <datatype><rng:text/></datatype>
<br />
                                 </attDef>
<br />
                         </attList>
<br />
                        </elementSpec>
<br />

<p>I do not see the change materialize in the generated validators.  Is
<br />
this a problem with Roma, or with my understanding of the ODDs? What I
<br />
want to achieve is adding a @resp to <app>.
<br />

BTW, the CVS Howto seems now workable to me, thanks James.  I wonder
<br />
if anybody else tried to use it in Schema production recently?
<br />

All the best,
<br />

Christian
<br />

<p><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 Sep 19 2005 - 07:26:37 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Sep 19 07:31:33 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 19 Sep 2005 12:31:33 +0100
Subject: [tei-council] Problem with Roma or ODD
In-Reply-To: <ygfaci9cn88.fsf@chwpb.local>
Message-ID: <432EA195.8070109@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, 19 Sep 2005 12:31:33 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>Given the following ODD fragment,
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>			<elementSpec ident="app" mode="change" module="textcrit">
</em><br />
<em class="quotelev1">>			 <attList>
</em><br />
<em class="quotelev1">>				 <attDef ident="resp" usage="opt">
</em><br />
<em class="quotelev1">>					 <desc>Agency responsible for this apparatus entry (usually as given in the text)</desc>
</em><br />
<em class="quotelev1">>					 <datatype><rng:text/></datatype>
</em><br />
<em class="quotelev1">>				 </attDef>
</em><br />
<em class="quotelev1">>			 </attList>
</em><br />
<em class="quotelev1">>			</elementSpec>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I do not see the change materialize in the generated validators.  Is
</em><br />
<em class="quotelev1">>this a problem with Roma, or with my understanding of the ODDs? What I
</em><br />
<em class="quotelev1">>want to achieve is adding a @resp to <app>.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
you need "mode='add'" on the <attDef>
<br />

you might argue about defaults of @mode, but in the
<br />
implementation now, you need to be specific.
<br />

greetings from Sophia Antipolis.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Mon Sep 19 2005 - 07:31:50 EDT</span>
</div>

From Laurent.Romary at loria.fr  Mon Sep 19 07:47:22 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Mon, 19 Sep 2005 13:47:22 +0200
Subject: [tei-council] Problem with Roma or ODD
In-Reply-To: <ygfaci9cn88.fsf@chwpb.local>
Message-ID: <744a9e6bd9b7cd326ea4105f79dee3e5@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, 19 Sep 2005 13:47:22 +0200</span><br />
</address>

Dear Christian,
<br />
I guess you put the answer in your own message: you want to add @resp 
<br />
to add. You need to add a mode="add"  to attDef. (Seb, Lou, etc.: am I 
<br />
right?)
<br />
Best,
<br />
Laurent
<br />
Le 19 sept. 05, ? 13:26, Christian Wittern a ?crit :
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Given the following ODD fragment,
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 			<elementSpec ident="app" mode="change" module="textcrit">
</em><br />
<em class="quotelev1">> 			 <attList>
</em><br />
<em class="quotelev1">> 				 <attDef ident="resp" usage="opt">
</em><br />
<em class="quotelev1">> 					 <desc>Agency responsible for this apparatus entry (usually as 
</em><br />
<em class="quotelev1">> given in the text)</desc>
</em><br />
<em class="quotelev1">> 					 <datatype><rng:text/></datatype>
</em><br />
<em class="quotelev1">> 				 </attDef>
</em><br />
<em class="quotelev1">> 			 </attList>
</em><br />
<em class="quotelev1">> 			</elementSpec>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I do not see the change materialize in the generated validators.  Is
</em><br />
<em class="quotelev1">> this a problem with Roma, or with my understanding of the ODDs? What I
</em><br />
<em class="quotelev1">> want to achieve is adding a @resp to <app>.<!--nospam-->
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> BTW, the CVS Howto seems now workable to me, thanks James.  I wonder
</em><br />
<em class="quotelev1">> if anybody else tried to use it in Schema production recently?
</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="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> -- 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  Christian Wittern
</em><br />
<em class="quotelev1">>  Institute for Research in Humanities, Kyoto University
</em><br />
<em class="quotelev1">>  47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
</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 Sep 19 2005 - 07:46:16 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Sep 19 07:54:30 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 19 Sep 2005 12:54:30 +0100
Subject: [tei–council] datatypes –– syd's comments
In-Reply-To: <432D559B.9040205@computing-services.oxford.ac.uk>
Message-ID: <432EA6F6.5060806@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, 19 Sep 2005 12:54:30 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>  DTYPES has removed the percent sign, there is no way to distinguish
</em><br />
<em class="quotelev2">>>  "1" meaning 100% from "1" meaning 1%.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Ah! good point. But what is your recommendation?
</em><br />
<em class="quotelev1">> (a) decide whether probability shd be expressed as a number between 0
</em><br />
<em class="quotelev1">> and 1 or as a number between 0 and 100 and then enforce one of them
</em><br />
<em class="quotelev1">> (if so, which?)
</em><br />
<em class="quotelev1">> (b) allow both as alternatives, but require that the latter (1 to 100)
</em><br />
<em class="quotelev1">> is always followed by a percent sign
</em><br />
<em class="quotelev1">> (c) leave things as proposed but note the constraint that numbers
</em><br />
<em class="quotelev1">> between 0 and 1 must be expressed including a decimal point.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Being a lazy person, I have a slight preference for (c) though it's
</em><br />
<em class="quotelev1">> hard to care very much about this:  the total number of attributes
</em><br />
<em class="quotelev1">> affected in the current version of edw90 table is one (1)
</em><br />

why dont we just zap that one :-}
<br />

<em class="quotelev1">> I don't completely understand this comment since tei.data.numeric maps
</em><br />
<em class="quotelev1">> to xsd:decimal which does support floating point numbers.  I assume
</em><br />
<em class="quotelev1">> what you mean is that such numbers can't be represented using the
</em><br />
<em class="quotelev1">> mantis+exponent (aka "scientific") notation. So it will permit
</em><br />
<em class="quotelev1">> "1.23456789" but not  "2e0.134"
</em><br />
<em class="quotelev1">>
</em><br />
|if you use xsd:float then
<br />
"-1E4, 1267.43233E12, 12.78e-2, 12| |, -0, 0| and |INF| are all legal
<br />
literals for *float*"
<br />
(http://www.w3.org/TR/xmlschema-2/#float), so
<br />
why is decimal preferred to float?
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Mon Sep 19 2005 - 07:54:52 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Sep 19 08:32:59 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 19 Sep 2005 13:32:59 +0100
Subject: [tei-council] naming languages
Message-ID: <432EAFFB.4080602@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, 19 Sep 2005 13:32:59 +0100</span><br />
</address>

oh look, this fun
<br />

http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Mon Sep 19 2005 - 08:33:18 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Mon Sep 19 10:43:46 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 19 Sep 2005 16:43:46 +0200
Subject: on spec grp 4, coded values (was "Re: [tei-council] datatypes")
In-Reply-To: <17198.12522.68260.573944@emt.wwp.brown.edu>
Message-ID: <432ECEA2.30508@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, 19 Sep 2005 16:43:46 +0200</span><br />
</address>

Syd Bauman wrote:
<br />
<em class="quotelev1">> [Note: despite the In-Reply-To field, this commentary is based on the
</em><br />
<em class="quotelev1">>  new version Lou just put out at
</em><br />
<em class="quotelev1">>  http://www.tei-c.org.uk/Drafts/DTYPES/ (the main site is down).]
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> On Specification group 4: Datatypes: coded values
</em><br />
<em class="quotelev1">> -- ------------- ----- -- ---------- ----- ------
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> * tei.data.code: the change permits any pointer; the recommendation
</em><br />
<em class="quotelev1">>   in ED W 90 is for local pointers only. We've talked about this
</em><br />
<em class="quotelev1">>   somewhat over the past few weeks or so, but IIRC, no one has said
</em><br />
<em class="quotelev1">>   anything on this issue except Lou and Syd. Lou has said (at least
</em><br />
<em class="quotelev1">>   twice) that he thinks it should be a generic pointer, but has not
</em><br />
<em class="quotelev1">>   expressed why.
</em><br />

It seems to me self-evident that once we changed from using IDREF to 
<br />
URIref, which we did long ago, the distinction between "local" and 
<br />
"generic" pointer became meaningless.
<br />

<em class="quotelev1">> 
</em><br />
<em class="quotelev1">>   I think there are several good reasons to restrict these kinds of
</em><br />
<em class="quotelev1">>   references to local pointers.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">>   - It mimics what P4 had.
</em><br />
<em class="quotelev1">> 
</em><br />

Not a good reason.
<br />

<em class="quotelev1">>   - It provides a system (as did ID/IDREF) where the attribute value
</em><br />
<em class="quotelev1">>     itself may be used as a code for a useful semantic distinction
</em><br />
<em class="quotelev1">>     (thus the name). E.g., new= and old= of <handShift> -- the real
</em><br />
<em class="quotelev1">>     details are provided by the <hand> to which they point, but
</em><br />
<em class="quotelev1">>     mnemonic values like "#Scribe1brown" and "#Scribe2red" can convey
</em><br />
<em class="quotelev1">>     a lot of meaning by themselves, or at least be easy for humans to
</em><br />
<em class="quotelev1">>     associate with the appropriate <hand>.
</em><br />
<em class="quotelev1">> 
</em><br />

You can still do that if you choose to.
<br />

<p><em class="quotelev1">>   - By changing the values of the xml:id= attributes of the elements
</em><br />
<em class="quotelev1">>     pointed at (e.g., <hand>), the encoder gets to create the
</em><br />
<em class="quotelev1">>     vocabulary used.
</em><br />

You can still do that too.
<br />

<em class="quotelev1">> 
</em><br />
<em class="quotelev1">>   - People want to know where things point. (Or go -- some of the
</em><br />
<em class="quotelev1">>     bigger complaints about P4 are about places where it says that
</em><br />
<em class="quotelev1">>     something should be documented "in the TEI header" without saying
</em><br />
<em class="quotelev1">>     where in the TEI header.)
</em><br />
<em class="quotelev1">> 
</em><br />

True, but irrelevant.
<br />

<em class="quotelev1">>     If we stick to local pointers, we can define the place or places
</em><br />
<em class="quotelev1">>     (likely in the TEI header) to where each tei.data.code attribute
</em><br />
<em class="quotelev1">>     is supposed to point, document it accordingly, and perhaps write
</em><br />
<em class="quotelev1">>     a Schematron rule to verify that it does so.
</em><br />
<em class="quotelev1">> 
</em><br />

We can specify the target element type, and maybe we should do so in 
<br />
some cases, but I don't see any advantage at all to trying to specify 
<br />
"where" the element instance is. It's all out there in cyberspace, man!
<br />

<p><em class="quotelev1">>     If we permit any pointer, documentation where these things point
</em><br />
<em class="quotelev1">>     becomes somewhat harder. E.g., if the new= of <handShift> points
</em><br />
<em class="quotelev1">>     to an external file, does it still need to point at a <tei:hand>?
</em><br />

Yes, obviously.
<br />

<em class="quotelev1">>     Presumably so. But unless the external file is another encoded
</em><br />
<em class="quotelev1">>     document that happened to be written by the same scribes, it is
</em><br />
<em class="quotelev1">>     likely to be just a project repository for <hand> elements. What
</em><br />
<em class="quotelev1">>     goes in the <text> element of that document? We also need to
</em><br />
<em class="quotelev1">>     rewrite the prose so that it is clear that the <hand> in one TEI
</em><br />
<em class="quotelev1">>     document may well be documenting the handwriting in another.
</em><br />
<em class="quotelev1">> 
</em><br />

The thing that handshift points to must be a <hand> element. It doesn't 
<br />
matter where that <hand> element is located, or what else is in the 
<br />
document containing it.
<br />

<p><em class="quotelev1">>   In either case (whether tei.data.code is declared as a pointer or a
</em><br />
<em class="quotelev1">>   local pointer), a user could easily switch to the other by
</em><br />
<em class="quotelev1">>   modifying her customization ODD file. I think it will provide a
</em><br />
<em class="quotelev1">>   more coherent system (and be easier for us to boot) if we provide a
</em><br />
<em class="quotelev1">>   local pointer mechanism; users who change it to general pointers
</em><br />
<em class="quotelev1">>   will know up front they are making an extension that may change
</em><br />
<em class="quotelev1">>   some of the semantics of some bits of the Guidelines.
</em><br />
<em class="quotelev1">> 
</em><br />

I don't know of any way of defining a local pointer, other than to say 
<br />
that the URL reference must begin with a # -- in which case you break 
<br />
things for the obsessive person who includes the full URL even when the 
<br />
pointer is to somewhere in the current document.
<br />

<p><p><em class="quotelev1">> * tei.data.enumerated: the change permits whitespace in the values.
</em><br />
<em class="quotelev1">>   I'm not sure about this. For consistency with tei.data.name and
</em><br />
<em class="quotelev1">>   tei.data.code (as proposed in ED W 90), I think whitespace should
</em><br />
<em class="quotelev1">>   not be permitted. Especially in cases of "open" valLists,
</em><br />
<em class="quotelev1">>   disallowing whitespace would help users understand that the value
</em><br />
<em class="quotelev1">>   should be a code, not a paragraph. On the other hand, is there any
</em><br />
<em class="quotelev1">>   really strong reason to insist on things like 
</em><br />
<em class="quotelev1">>     <lg type="couplet-alexandrine"> 
</em><br />
<em class="quotelev1">>   instead of
</em><br />
<em class="quotelev1">>     <lg type="Alexandrine couplet">?
</em><br />
<em class="quotelev1">>   Even if we use token w/o the restriction, for consistency it should
</em><br />
<em class="quotelev1">>   probably be xsd:token.
</em><br />

I am open minded (or open-minded) on this question. I finally came down 
<br />
on the side of allowing *normalised* whitespace within the value because 
<br />
(a) there are quite a few real life examples in P4
<br />
(b) i assumed that whoever defined xsd:token that way was probably not a 
<br />
complete idiot.
<br />

There are quite a few things which are linguistically single tokens but 
<br />
which include a space, all right?
<br />

<p><em class="quotelev1">> * tei.data.key: the change is from 'xsd:token' to 'rng:string'. I
</em><br />
<em class="quotelev1">>   think it should be left as 'xsd:token' just for consistency. There
</em><br />
<em class="quotelev1">>   is no difference in validation at all (since there are no
</em><br />
<em class="quotelev1">>   enumerated values).
</em><br />

There is all the difference in the world. key is *explicitly* defined as 
<br />
something that is to be validated externally and over which the TEI 
<br />
should therefore place no (additional) syntactic constraints. We cannot 
<br />
possibly second guess what syntactic constraints every database system 
<br />
in the world might impose, ergo our only choice is to not impose any at all.
<br />

<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> * tei.data.name: the change is from any string that does not contain
</em><br />
<em class="quotelev1">>   whitespace (but may include, e.g., punctuation marks, currency
</em><br />
<em class="quotelev1">>   symbols, math symbols, etc.) to an XML NMTOKEN. I am not sure why
</em><br />
<em class="quotelev1">>   we'd want to exclude the non-letter, non-digit characters (other
</em><br />
<em class="quotelev1">>   than .-_:, which are permitted in NMTOKEN). Why shouldn't the
</em><br />
<em class="quotelev1">>   Tibetan Paluta character be allowed?
</em><br />

I assume the latter is not a serious suggestion. I thought the reason 
<br />
was fairly obviously to do with ease of (XML) processing.
<br />

<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> * tei.data.names: the change is from multiple occurrences of
</em><br />
<em class="quotelev1">>   whitespace-delimited tokens to only one. Despite your claim, Lou,
</em><br />
<em class="quotelev1">>   this really must be an error. I bet you meant 
</em><br />
<em class="quotelev1">>      tei.data.names = list { tei.data.name+ }
</em><br />
<em class="quotelev1">> 
</em><br />

Yes, sorry. It is right in CVS...
<br />

<em class="quotelev1">> * tei.data.name(s): the change is from the name "token(s)" to
</em><br />
<em class="quotelev1">>   "name(s)". I dunno. Feels very much like out of the frying pan into
</em><br />
<em class="quotelev1">>   the fire. While "token" is confusing because W3C mis-named their
</em><br />
<em class="quotelev1">>   datatype, "name" is confusing because in fact these values are most
</em><br />
<em class="quotelev1">>   likely not proper nouns at all, and have nothing to do with the
</em><br />
<em class="quotelev1">>   <name> element, the 'names' class, or the 'naming' class.
</em><br />
<em class="quotelev1">>   How about
</em><br />
<em class="quotelev1">>   - term
</em><br />
<em class="quotelev1">>   - sign
</em><br />
<em class="quotelev1">>   - TOKEN
</em><br />
<em class="quotelev1">>   - character-sequence
</em><br />
<em class="quotelev1">>   - character-sequence-sans-whitespace
</em><br />
<em class="quotelev1">>   - charSeq
</em><br />
<em class="quotelev1">>   - noWScharSeq
</em><br />
<em class="quotelev1">>   - datum ('data' for plural)
</em><br />
<em class="quotelev1">>   - the Latin or French word for "token"
</em><br />
<em class="quotelev1">>   Oh dear. I'm almost ready to live with the confusion over "token".
</em><br />
<em class="quotelev1">> 
</em><br />

<p>We did discuss this a a bit on the list and nobody came up with a better 
<br />
suggestion. I think using "token" would really be asking for confusion 
<br />
-- precisely because we do mean something different from a datatype 
<br />
which the W3C calls "token" -- whether it's in caps or not. I also 
<br />
considered "ident" and "label". The key thing about it, surely though, 
<br />
is that it is a way of naming something, even if it's not a proper name?
<br />

We can iron this one out maybe later. At least we agree on what it is, 
<br />
and until someone comes up with a better token, let's call it a name!
<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 Sep 19 2005 - 10:36:44 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Mon Sep 19 14:22:08 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 19 Sep 2005 14:22:08 -0400
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <4325CC68.1050400@computing-services.oxford.ac.uk>
Message-ID: <17199.464.243621.414963@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, 19 Sep 2005 14:22:08 -0400</span><br />
</address>

<em class="quotelev1">> Has anyone come up with a standard which represents any possible
</em><br />
<em class="quotelev1">> time, duration, periods, in all known calendars? Or is there a
</em><br />
<em class="quotelev1">> time/date standard that is in any way better ISO 8601?
</em><br />

There are several profiles (i.e., subsets) of 8601 which are arguably
<br />
superior. (They have rules like don't permit basic, only extended,
<br />
formats where both are available; don't permit "24" in the hour
<br />
field, etc.)
<br />

<p><em class="quotelev1">> One of the other differences I notice with ISO8601 and your
</em><br />
<em class="quotelev1">> patterns is that tei.duration current copes with things at a
</em><br />
<em class="quotelev1">> smaller granularity than 1 second and ISO 8601 doesn't.
</em><br />

What makes you think one can't express fractions of a second in ISO
<br />
8601 durations? I am quite positive you can in the alternate format
<br />
(e.g., PT00:00:00,110 for 110 ms), and thus presumed you could in the
<br />
format with time-unit designators.
<br />

(BTW, 8601 permits fractions of other units, as well; so "half an
<br />
hour" could be PT00,5.)
<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 Sep 19 2005 - 14:22:27 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Sep 19 18:45:16 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 20 Sep 2005 07:45:16 +0900
Subject: [tei-council] Problem with Roma or ODD
In-Reply-To: <432EA195.8070109@oucs.ox.ac.uk>
Message-ID: <ygfzmq8brsz.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 20 Sep 2005 07:45:16 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk> writes:
<br />

<em class="quotelev1">> Christian Wittern wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>Given the following ODD fragment,
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>			<elementSpec ident="app" mode="change" module="textcrit">
</em><br />
<em class="quotelev2">>>			 <attList>
</em><br />
<em class="quotelev2">>>				 <attDef ident="resp" usage="opt">
</em><br />
<em class="quotelev2">>>					 <desc>Agency responsible for this apparatus entry (usually as given in the text)</desc>
</em><br />
<em class="quotelev2">>>					 <datatype><rng:text/></datatype>
</em><br />
<em class="quotelev2">>>				 </attDef>
</em><br />
<em class="quotelev2">>>			 </attList>
</em><br />
<em class="quotelev2">>>			</elementSpec>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>I do not see the change materialize in the generated validators.  Is
</em><br />
<em class="quotelev2">>>this a problem with Roma, or with my understanding of the ODDs? What I
</em><br />
<em class="quotelev2">>>want to achieve is adding a @resp to <app>.
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> you need "mode='add'" on the <attDef>
</em><br />
<em class="quotelev1">>
</em><br />

Thanks. Arrrgh.  If you say so.  How about putting an example of this in the
<br />
ODD Manual?  
<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 Sep 19 2005 - 18:45:24 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Sep 20 00:20:20 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 00:20:20 -0400
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <432DA719.1010607@computing-services.oxford.ac.uk>
Message-ID: <17199.36356.769861.682886@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, 20 Sep 2005 00:20:20 -0400</span><br />
</address>

<em class="quotelev1">> This is indeed the case, and reflects a conscious decision to use
</em><br />
<em class="quotelev1">> attribute values here as elsewhere to represent a normalized value,
</em><br />
<em class="quotelev1">> which might indeed be represented in a more nuanced way within the
</em><br />
<em class="quotelev1">> content of the element or by linking elsewhere.
</em><br />

While I agree with the general principle, "13:30" is not more nuanced
<br />
than "13:30:00"; but it is different, and needs to be representable.
<br />

<p><em class="quotelev1">> I don't get it. If you want to give a value precise to only a year,
</em><br />
<em class="quotelev1">> month etc. you can do so using the approved designation, surely?
</em><br />
<em class="quotelev1">> "1900" doesnt mean any particular time in 1900, it just means 1900.
</em><br />
<em class="quotelev1">> Similarly, 1900-12 means some time in December 1900. And so on.
</em><br />

Exactly! Using W3C datatypes you can give a date/time value precise
<br />
to the
<br />
* year
<br />
* month
<br />
* day
<br />
* second
<br />
but *not* to the hour or minute. This is what requires repair.
<br />

<p><em class="quotelev1">> Surely, the point of using this format is precisely that as many
</em><br />
<em class="quotelev1">> processors as possible will do the right thing with them.
</em><br />

Yes, but not at the expense of not being able to represent humanities
<br />
data. Besides, keep in mind that (at least for RelaxNG) all a datatype
<br />
does is, given a certain string, say "yes, this is" or "no, this is
<br />
not" a valid instance of me. It doesn't return a normalized or
<br />
regularized or canonical value or anything like that.
<br />

<p><em class="quotelev1">> Can you give some examples of processors which do not behave
</em><br />
<em class="quotelev1">> correctly when handling ISO 8601 format values? And is there any
</em><br />
<em class="quotelev1">> reason to believe they would make a better fist of handling an
</em><br />
<em class="quotelev1">> arbitrary TEI-invented format instead?
</em><br />

The format I'm recommending is *not* arbitrary and is *not*
<br />
TEI-invented; it *is* ISO 8601.
<br />

<p><em class="quotelev1">> Similar considerations apply to the other two cases you mention. In
</em><br />
<em class="quotelev1">> the case of duration and sex, we are talking about an encoded value
</em><br />
<em class="quotelev1">> for an attribute, and it makes much better sense to use an ISO- or
</em><br />
<em class="quotelev1">> W3C- recommended encoded value than to make one up.
</em><br />

[On duration; ignoring sex, where it seems we're agreed on ISO's 0, 1,
<br />
2, 9:]
<br />
Again, it's only syntax, so I'm not claiming it is very important, but
<br />
I'd like to set the record straight. I did not make up the syntax I am
<br />
suggesting. It comes from NIST which takes most of it from SI. I
<br />
daresay the Bureau International des Poids et Mesures and even the
<br />
(US) National Institute of Standards and Technology has been doing
<br />
this standardization of units stuff for a lot longer than either ISO
<br />
or W3C, and they do a significantly better job.
<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 Sep 20 2005 - 00:20:36 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Sep 20 05:32:06 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 20 Sep 2005 10:32:06 +0100
Subject: [tei-council] Problem with Roma or ODD
In-Reply-To: <ygfzmq8brsz.fsf@chwpb.local>
Message-ID: <432FD716.30702@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, 20 Sep 2005 10:32:06 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>Thanks. Arrrgh.  If you say so.
</em><br />
<em class="quotelev1">>
</em><br />
you have to distinguish between authoring a module and
<br />
authoring an extension schema.
<br />

<em class="quotelev1">>  How about putting an example of this in the
</em><br />
<em class="quotelev1">>ODD Manual?  
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
surely there is one???
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Sep 20 2005 - 05:32:24 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Sep 20 10:23:43 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 10:23:43 -0400
Subject: [tei-council] datatype issues (part 1) continued,,,
In-Reply-To: <4326A09F.1000808@oucs.ox.ac.uk>
Message-ID: <17200.7023.583257.963017@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, 20 Sep 2005 10:23:43 -0400</span><br />
</address>

<em class="quotelev1">> The only places [tei.data.regexp] is used at present is for
</em><br />
<em class="quotelev1">> attributes like metDecl which have as their value a string of
</em><br />
<em class="quotelev1">> gobbledegook in some special syntax defined by the TEI.
</em><br />

Huh?? Even in P3 the pattern= attribute of <metDecl> was defined as a
<br />
regular expression. In P3 and P4 the regular expression language used
<br />
was that created by the TEI for its extended pointer syntax. In P5 we
<br />
have made the move to using the W3C regular expression language
<br />
instead. I think using a regexp here is and was a good idea,
<br />
switching to W3C regexps is a good move, and this attribute should
<br />
most certainly remain as is.
<br />

<p><em class="quotelev1">> This [string of gobbledegook in some special syntax defined by the
</em><br />
<em class="quotelev1">> TEI] seems a useful category of information.
</em><br />

If there are any such attributes, then yes, I agree, it's a useful
<br />
category. But don't put pattern= of <metDecl> in it, it doesn't
<br />
belong there.
<br />

Since we use regexps as an attributes' type very rarely (only 2 or 3
<br />
occurrences, I think), I don't really care whether we abstract them
<br />
into a datatype or not, although it may be a useful place to explain
<br />
it.
<br />

<p><em class="quotelev1">> I hesitated a long time over NMTOKEN and NCName. The former allows
</em><br />
<em class="quotelev1">> hyphens but not underscore; the latter allows underscore but not
</em><br />
<em class="quotelev1">> hyphen.
</em><br />

This is simply untrue. xsd:NMTOKEN maps to an XML NMTOKEN; xsd:NCName
<br />
maps to an XML Namespaces NCName, which maps to an XML name except
<br />
that colon is not allowed. Both allow hyphen, both allow underscore.
<br />
xsd:NCName does not permit the string to *start* with a digit or
<br />
punctuation character other than underscore.
<br />

<p><em class="quotelev1">> Syd's proposed pattern
</em><br />

Credit where credit is due: it was your proposal, Lou.
<br />

<em class="quotelev1">> allows [hyphen or underscore] and also comma.
</em><br />

And also semicolon, circled plus sign, curly braces, the Euro
<br />
symbol, the copyright symbol, etc.
<br />

<p><em class="quotelev1">> I am open to persuasion that both tei.data.key and tei.data.ident
</em><br />
<em class="quotelev1">> should have the same mapping; less to defining something which is
</em><br />
<em class="quotelev1">> not either NMTOKEN or NCName.
</em><br />

In P4 most of these things were CDATA. I think making them a single
<br />
token (normal sense of the word) is a really good idea -- if we could
<br />
do so in P4 we should (we can't). I even think forbidding some kinds
<br />
of non-whitespace characters would be a really good idea (e.g.,
<br />
control characters, PUA characters, etc. See [1] for list). However,
<br />
I'm not really sure of the advantage of telling people who would like
<br />
to have things like "damaged/deliberate" and "damaged/accidental" as
<br />
their values for reason= of <gap> that they cannot, just because W3C
<br />
says that names of elements etc. can't have a slash. 
<br />

<p><em class="quotelev1">> So in order of ascending tightness of constraint, we have
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> tei.data.enumerated : the value is defined by a valList (type=closed)
</em><br />
<em class="quotelev1">> tei.data.code : the value is defined by a pointer to something which 
</em><br />
<em class="quotelev1">>                 must exist
</em><br />
<em class="quotelev1">> tei.data.key : the value is defined by an enumeration elsewhere e.g. a 
</em><br />
<em class="quotelev1">>                database key
</em><br />
<em class="quotelev1">> tei.data.ident : the value is a name or identifier of some kind but not 
</em><br />
<em class="quotelev1">>                  necessarily enumerated or enumeratable
</em><br />

Where in your scheme to <valList>s of type= "open" and "semi" fit?
<br />
I.e., are they still assigned the datatype tei.data.enumerated?
<br />

Note
<br />

----
[1] A first cut at Unicode categories that should and should not be
    permitted in tei.data.[token,ident,name,term]. I am not a Unicode
    expert, nor have I taken the time to examine each category
    carefully, nor to see into what categories the characters
    permitted in xsd:NMTOKEN fall.
    Abbr.  Description                    Should be OK?
    -----  -----------                    ------ -- ---
    Lu     Letter, Uppercase              yes
    Ll     Letter, Lowercase              yes
    Lt     Letter, Titlecase              yes
    Lm     Letter, Modifier               yes?
    Lo     Letter, Other                  yes
    Mn     Mark, Nonspacing               ?
    Mc     Mark, Spacing Combining        ?
    Me     Mark, Enclosing                ?
    Nd     Number, Decimal Digit          yes
    Nl     Number, Letter                 yes
    No     Number, Other                  yes
    Pc     Punctuation, Connector         yes
    Pd     Punctuation, Dash              yes
    Ps     Punctuation, Open              yes
    Pe     Punctuation, Close             yes
    Pi     Punctuation, Initial quote     yes
    Pf     Punctuation, Final quote       yes
    Po     Punctuation, Other             yes
    Sm     Symbol, Math                   yes
    Sc     Symbol, Currency               yes
    Sk     Symbol, Modifier               yes
    So     Symbol, Other                  yes
    Zs     Separator, Space               NO
    Zl     Separator, Line                NO
    Zp     Separator, Paragraph           NO
    Cc     Other, Control                 NO
    Cf     Other, Format                  NO
    Cs     Other, Surrogate               NO
    Co     Other, Private Use             NO
    Cn     Other, Not Assigned            NO
_______________________________________________
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 Sep 20 2005 - 10:23:59 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Sep 20 12:20:28 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 12:20:28 -0400
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <432CA353.9000105@computing-services.oxford.ac.uk>
Message-ID: <17200.14028.790906.531915@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, 20 Sep 2005 12:20:28 -0400</span><br />
</address>

<em class="quotelev1">> 1. add_at_place 
</em><br />
<em class="quotelev1">>    addSpan_at_place
</em><br />
<em class="quotelev1">>            -->  tei.data.enumerated
</em><br />

What do you propose the value list be? The list{} method proposed
<br />
permits things like "opposite top left" (which is also permitted in
<br />
P4). 
<br />

<em class="quotelev1">>    metDecl_at_type    
</em><br />
<em class="quotelev1">>            -->  tei.data.enumerated
</em><br />

Again, we need to account for the fact that more than 1 "value" is
<br />
permitted. Thus the value list would have to account for the various
<br />
combinations. Luckily, since there are only 3 of 'em, in this case
<br />
it's not hard:
<br />
  met
<br />
  real
<br />
  rhyme
<br />
  met;real
<br />
  met;rhyme
<br />
  real;rhyme
<br />
  met;real;rhyme
<br />
(In EDW90 I just copied what P4 says to do: "One or more of the three
<br />
attribute names met, real, or rhyme, separated by whitespace", thus
<br />
   list { ("met" | "real" | "rhyme")+ }
<br />
Both P4 and EDW90 permit silly combinations like "met real met
<br />
real".)
<br />

<p><em class="quotelev1">> 2. tei.pointerGroup_at_domains  
</em><br />
<em class="quotelev1">>           -->  tei.data.pointers
</em><br />

I don't really see it as a plus to permit values that the prose says
<br />
are invalid just to say we used a datatype directly. The EDW90
<br />
recommendation matches the prose perfectly. (It is
<br />
  list { tei.data.pointer, tei.data.pointers }
<br />
.)
<br />

On the other hand, if everyone really thinks it is extremely
<br />
important to use an abstract TEI datatype instead of a perfectly
<br />
reasonable combination of 'em like the above, I suppose we could move
<br />
the "must be 2 or more" check into a Schematron rule. Seems like the
<br />
lesser of two evils, at least.
<br />

<br />
<em class="quotelev1">> 3. schemaSpec_at_start
</em><br />
<em class="quotelev1">>     specDesc_at_atts   
</em><br />
<em class="quotelev1">>          --> tei.data.names
</em><br />

Again, why use a lax constraint when the proper one is readily
<br />
available just to say you used a datatype? There are three possible
<br />
declarations for tei.data.names on the table, and only one of them
<br />
actually constrain this attribute properly:
<br />
* list { xsd:NCName+ }  ->  does not permit "musicML:note", but since 
<br />
                            there is an ns= attribute, I'm betting
<br />
                            that's considered a good thing, right
<br />
                            Sebastian?
<br />
* list { xsd:NMTOKEN+ }  ->  permits "--notAllowed"
<br />
* list { xsd:token { pattern="\S+" } }  ->  permits "${notAllowed}"
<br />

If we decide tei.data.names should boil down to something other than
<br />
the first, then I think we should just use the proper constraint
<br />
without a TEI datatype and not fret it.
<br />

<p><em class="quotelev1">> 4. date_at_precision
</em><br />
<em class="quotelev1">>        --> tei.data.certainty
</em><br />

I think this is a really bad idea. First off, <date> should probably
<br />
not have a precision= attribute. The precision should be expressed in
<br />
the value=. Furthermore, while I suppose vague terms like "high",
<br />
"medium", and "low" are occasionally applied to the precision, it is
<br />
much more common, and far more useful, to express the unit to which a
<br />
measurement is precise. So if we really wanted to separate precision
<br />
from the value=, we would want precision= of date to have values like
<br />
"century", "decade", "year", "month", "week", and "day".
<br />

<p><em class="quotelev1">> 5. tei.datable_at_dateAttrib
</em><br />
<em class="quotelev1">>        --> tei.data.enumerated
</em><br />

Yes, that's what is recommended: tei.enumerated with a value list of
<br />
"datable" | "dated" | "unknown".
<br />

<p><em class="quotelev1">> 6. locus_at_scheme
</em><br />
<em class="quotelev1">>        --> tei.data.name
</em><br />

I presume that's because you don't want to argue with Matthew and
<br />
David over the possible values? :-) Seriously, I don't currently
<br />
really understood the purpose of this attribute. <locus> describes a
<br />
location in the current manuscript, which (supposedly) has only one
<br />
foliation scheme which should be described in //supportDesc/foliation
<br />
(of which only 0 or 1 are permitted, right?). So what does scheme=
<br />
buy us?
<br />

<p><em class="quotelev1">> 7. fragmentPattern_at_pat
</em><br />
<em class="quotelev1">>       --> tei.data.notation
</em><br />

As above, if "tei.data.notation" is for "notations TEI made up", this
<br />
doesn't belong.
<br />

<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 8. schemaSpec_at_namespace
</em><br />
<em class="quotelev1">>     elementSpec_at_ns (why isnt it "namespace" btw?)
</em><br />
<em class="quotelev1">>        --> these could be xsd:uri as proposed, or tei.data.pointer, but 
</em><br />
<em class="quotelev1">> maybe since they have to be
</em><br />
<em class="quotelev1">>              real namespace names (i.e. "#foo" won't do) maybe shd be 
</em><br />
<em class="quotelev1">> their own datatype?
</em><br />

Yes, all our ns= and namespace= attributes need to be brought into
<br />
alignment. I don't care which.
<br />

However, as I read the spec, "#foo" is a perfectly valid namespace.
<br />
Stupid perhaps, but valid.
<br />

<p><em class="quotelev1">> 9.   tei.declarable_at_default
</em><br />
<em class="quotelev1">>      tei.identifiable_at_predeclare
</em><br />
<em class="quotelev1">>      metSym_at_terminal
</em><br />
<em class="quotelev1">>      numeric_at_trunc
</em><br />
<em class="quotelev1">>      binary_at_value                  
</em><br />
<em class="quotelev1">>         --> are all xsd:boolean (so "unknown" not allowed) ; could just 
</em><br />
<em class="quotelev1">> be tei.data.truthValue with extra rule
</em><br />

Could be. And at one point in the history of that EDW90 table, they
<br />
were. But a week or two ago we agreed to go directly with
<br />
xsd:boolean. 
<br />

<p><em class="quotelev1">> 10.  timeline_at_interval
</em><br />
<em class="quotelev1">>        when_at_interval   
</em><br />
<em class="quotelev1">>        --> tei.data.numeric | -1  (or think of a better way of
</em><br />
<em class="quotelev1">>            doing the -1)
</em><br />

a) We'd go back to needing unit= (I'm not saying this is so horrible,
<br />
   just want to make sure everyone understands the implications) and
<br />
   violate the policy of using W3C Schema datatypes where applicable.
<br />

b) All of the proposed declarations of tei.data.numeric already
<br />
   permit -1.
<br />

c) This permits all other negative numbers, which P4 explicitly
<br />
   disallows. 
<br />

d) If you meant 'tei.data.count', it won't do as fractions may be
<br />
   needed. 
<br />

e) Now that I think about it, the pattern EDW90 recommends has a
<br />
   problem, too: it permits "-0.5".
<br />

Thus, I am now leaning towards
<br />
   xsd:long { minInclusive = "0" }  |  xsd:token "unknown"
<br />

<p><em class="quotelev1">> 11. several attributes with proposed  datypes of "xsd:NCName" -> 
</em><br />
<em class="quotelev1">>     tei.data.name
</em><br />

Again, only if we agree tei.data.name -> xsd:NCName, of which I've
<br />
yet to be convinced.
<br />

<p><em class="quotelev1">> 12. several attributes with proposed datatypes of
</em><br />
<em class="quotelev1">>     "xsd:nonNegativeInteger" --> there are enough of these that I
</em><br />
<em class="quotelev1">>     propose a new datatype "tei.data.count"
</em><br />

Fine with me, although I'm not sure what it gains for us.
<br />

<p><em class="quotelev1">> 13. sense_at_level -> tei.<!--nospam-->data.count
</em><br />

Fine.
<br />
(Just so everyone understands, the only real difference between
<br />
  xsd:unsignedShort
<br />
and
<br />
  tei.data.count -> xsd:nonNegativeIngeger
<br />
is that the software engineer designing an application that reads a
<br />
TEI-encoded dictionary knows that in the former case whenever she
<br />
comes across a level= of <sense> she need only set aside 16 bits to
<br />
hold the value; with the latter she gets no such assurances. The
<br />
other difference, that xsd:unsignedShort has a maximum value of
<br />
65,535, isn't a practical problem.)
<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 Sep 20 2005 - 12:20:46 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Sep 20 13:16:53 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 13:16:53 -0400
Subject: [tei-council] naming languages
In-Reply-To: <432EAFFB.4080602@oucs.ox.ac.uk>
Message-ID: <17200.17413.755118.837616@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, 20 Sep 2005 13:16:53 -0400</span><br />
</address>

<em class="quotelev1">> oh look, this fun
</em><br />
<em class="quotelev1">> http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt
</em><br />

This, I believe, is a draft of the (much anticipated?) successor to
<br />
RFC 3066. xml:lang= is already defined as "3066 or its successor",
<br />
but IIRC there are sections of CH that will need to be updated when
<br />
this becomes a real RFC.
<br />

Alejandro mentioned in Paris that 2-letter initial subcodes are
<br />
preferred to 3-letter. I don't know if CH has been updated to reflect
<br />
that yet. However, I just quickly checked this new draft, and it
<br />
seems that when a 2-letter code is availalbe, it *must* be used, as
<br />
the 3-letter version will not be in the IANA registry.
<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 Sep 20 2005 - 13:17:15 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Sep 20 13:19:25 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 20 Sep 2005 18:19:25 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <17199.464.243621.414963@emt.wwp.brown.edu>
Message-ID: <4330449D.1070605@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, 20 Sep 2005 18:19:25 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev2">>>Has anyone come up with a standard which represents any possible
</em><br />
<em class="quotelev2">>>time, duration, periods, in all known calendars? Or is there a
</em><br />
<em class="quotelev2">>>time/date standard that is in any way better ISO 8601?
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>There are several profiles (i.e., subsets) of 8601 which are arguably
</em><br />
<em class="quotelev1">>superior. (They have rules like don't permit basic, only extended,
</em><br />
<em class="quotelev1">>formats where both are available; don't permit "24" in the hour
</em><br />
<em class="quotelev1">>field, etc.)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

Thanks for the clarification, and apologies for my careless usage. Let's 
<br />
see if I;ve understood the position correctly.
<br />
(1) ISO 8601 defines a large  number of different formats for 
<br />
representing temporal expressions
<br />
(2) W3C has defined a subset of these for which named w3c datatypes exist
<br />
(3) the edw90 proposal for tei.data.temporal is to allow a combination 
<br />
of (some of or all?) the w3c datatypes plus a couple of others which Syd 
<br />
proposes we should allow for as well by means of a pattern
<br />

If that's correct, the only issue we have to argue about is whether or 
<br />
not the 'extras' are desirable enough to outweigh the possible 
<br />
inconvenience of supporting formats which off-the-shelf w3c-focussed 
<br />
implementations may not recognise.
<br />

I don't have a strong view on this: we could maybe distinguish 
<br />
tei.data.temporal and tei.data.temporal.extended if others do -- the 
<br />
distinction being that the former keeps to our original goal of mapping 
<br />
cleanly to w3c datatypes.
<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 Sep 20 2005 - 13:26:31 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Sep 20 13:26:04 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 20 Sep 2005 18:26:04 +0100
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <17199.36356.769861.682886@emt.wwp.brown.edu>
Message-ID: <4330462C.5050607@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, 20 Sep 2005 18:26:04 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>Again, it's only syntax, so I'm not claiming it is very important, but
</em><br />
<em class="quotelev1">>I'd like to set the record straight. I did not make up the syntax I am
</em><br />
<em class="quotelev1">>suggesting. It comes from NIST which takes most of it from SI. I
</em><br />
<em class="quotelev1">>daresay the Bureau International des Poids et Mesures and even the
</em><br />
<em class="quotelev1">>(US) National Institute of Standards and Technology has been doing
</em><br />
<em class="quotelev1">>this standardization of units stuff for a lot longer than either ISO
</em><br />
<em class="quotelev1">>or W3C, and they do a significantly better job.
</em><br />
<em class="quotelev1">>
</em><br />
Well, I may be wrong on this as much else, but I wasn't aware that 
<br />
either of the venerable bodies you mention had much of a say in the 
<br />
world of computer representations of datatypes.
<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 Sep 20 2005 - 13:33:05 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Sep 20 13:52:33 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 20 Sep 2005 18:52:33 +0100
Subject: [tei-council] datatype issues (part 1) continued,,,
In-Reply-To: <17200.7023.583257.963017@emt.wwp.brown.edu>
Message-ID: <43304C61.4010808@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, 20 Sep 2005 18:52:33 +0100</span><br />
</address>

  Syd Bauman wrote:
<br />

<em class="quotelev2">>>The only places [tei.data.regexp] is used at present is for
</em><br />
<em class="quotelev2">>>attributes like metDecl which have as their value a string of
</em><br />
<em class="quotelev2">>>gobbledegook in some special syntax defined by the TEI.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Huh?? Even in P3 the pattern= attribute of <metDecl> was defined as a
</em><br />
<em class="quotelev1">>regular expression. In P3 and P4 the regular expression language used
</em><br />
<em class="quotelev1">>was that created by the TEI for its extended pointer syntax. In P5 we
</em><br />
<em class="quotelev1">>have made the move to using the W3C regular expression language
</em><br />
<em class="quotelev1">>instead. I think using a regexp here is and was a good idea,
</em><br />
<em class="quotelev1">>switching to W3C regexps is a good move, and this attribute should
</em><br />
<em class="quotelev1">>most certainly remain as is.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
OK, I am perfectly happy to restrict the kind of gobbledegook permitted 
<br />
for this datatype to a W3C-defined regular expression. That ought to fit 
<br />
with most kinds of gobbledegook we can come up with!
<br />

Is everyone happy with "regexp" as the name for it? how about 
<br />
"tei.data.pattern" ?
<br />

<p>....
<br />

<p><em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>I hesitated a long time over NMTOKEN and NCName. The former allows
</em><br />
<em class="quotelev2">>>hyphens but not underscore; the latter allows underscore but not
</em><br />
<em class="quotelev2">>>hyphen.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>This is simply untrue. xsd:NMTOKEN maps to an XML NMTOKEN; xsd:NCName
</em><br />
<em class="quotelev1">>maps to an XML Namespaces NCName, which maps to an XML name except
</em><br />
<em class="quotelev1">>that colon is not allowed. Both allow hyphen, both allow underscore.
</em><br />
<em class="quotelev1">>xsd:NCName does not permit the string to *start* with a digit or
</em><br />
<em class="quotelev1">>punctuation character other than underscore.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
....
<br />

<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>I am open to persuasion that both tei.data.key and tei.data.ident
</em><br />
<em class="quotelev2">>>should have the same mapping; less to defining something which is
</em><br />
<em class="quotelev2">>>not either NMTOKEN or NCName.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>In P4 most of these things were CDATA. I think making them a single
</em><br />
<em class="quotelev1">>token (normal sense of the word) is a really good idea -- if we could
</em><br />
<em class="quotelev1">>do so in P4 we should (we can't). I even think forbidding some kinds
</em><br />
<em class="quotelev1">>of non-whitespace characters would be a really good idea (e.g.,
</em><br />
<em class="quotelev1">>control characters, PUA characters, etc. See [1] for list). However,
</em><br />
<em class="quotelev1">>I'm not really sure of the advantage of telling people who would like
</em><br />
<em class="quotelev1">>to have things like "damaged/deliberate" and "damaged/accidental" as
</em><br />
<em class="quotelev1">>their values for reason= of <gap> that they cannot, just because W3C
</em><br />
<em class="quotelev1">>says that names of elements etc. can't have a slash. 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

This is really a tricky problem. It's kind of like the discussion about 
<br />
temporal expressions -- because the W3C datatypes don't exactly fit in 
<br />
with feelings about what a "name/ident/term" ought to be, it's tempting 
<br />
to invent our own definition as an alternative.
<br />

We can probably distinguish cases where the name *must* conform to W3C 
<br />
rules about identifiers -- if it's the name of an element it obviously 
<br />
has to follow constraint on what an XML name can be. If however it's a 
<br />
name we've made up this is less obviously the case, and the only 
<br />
constraint we'd probably want to put on it is that it shouldnt contain 
<br />
white space (else we can't have tei.data.names). But do we really want 
<br />
two kinds of tei.data.name?
<br />

<p><em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>So in order of ascending tightness of constraint, we have
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>tei.data.enumerated : the value is defined by a valList (type=closed)
</em><br />
<em class="quotelev2">>>tei.data.code : the value is defined by a pointer to something which 
</em><br />
<em class="quotelev2">>>                must exist
</em><br />
<em class="quotelev2">>>tei.data.key : the value is defined by an enumeration elsewhere e.g. a 
</em><br />
<em class="quotelev2">>>               database key
</em><br />
<em class="quotelev2">>>tei.data.ident : the value is a name or identifier of some kind but not 
</em><br />
<em class="quotelev2">>>                 necessarily enumerated or enumeratable
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Where in your scheme to <valList>s of type= "open" and "semi" fit?
</em><br />
<em class="quotelev1">>I.e., are they still assigned the datatype tei.data.enumerated?
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

My proposal is yes, they still have tei.data.enumerated.
<br />

<em class="quotelev1">>[1] A first cut at Unicode categories that should and should not be
</em><br />
<em class="quotelev1">>    permitted in tei.data.[token,ident,name,term]. 
</em><br />
<em class="quotelev1">>
</em><br />

Useful table. If we decide to invent our own kind of name, then it will 
<br />
be eminently sensible to base it on Unicode character categories.
<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 Sep 20 2005 - 13:59:18 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Sep 20 14:10:31 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 14:10:31 -0400
Subject: [tei–council] datatypes –– syd's comments
In-Reply-To: <432D559B.9040205@computing-services.oxford.ac.uk>
Message-ID: <17200.20631.233369.37067@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, 20 Sep 2005 14:10:31 -0400</span><br />
</address>

<em class="quotelev1">> Ah! good point. But what is your recommendation?
</em><br />
<em class="quotelev1">> (a) decide whether probability shd be expressed as a number between 0 
</em><br />
<em class="quotelev1">> and 1 or as a number between 0 and 100 and then enforce one of them (if 
</em><br />
<em class="quotelev1">> so, which?)
</em><br />
<em class="quotelev1">> (b) allow both as alternatives, but require that the latter (1 to 100) 
</em><br />
<em class="quotelev1">> is always followed by a percent sign
</em><br />
<em class="quotelev1">> (c) leave things as proposed but note the constraint that numbers 
</em><br />
<em class="quotelev1">> between 0 and 1 must be expressed including a decimal point.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Being a lazy person, I have a slight preference for (c) though it's hard 
</em><br />
<em class="quotelev1">> to care very much about this:  the total number of attributes affected 
</em><br />
<em class="quotelev1">> in the current version of edw90 table is one (1)
</em><br />

Which one do you have in mind? I count six (6). In any case, I agree
<br />
it's not all that important, but have a strong preference for (b).
<br />

<p><em class="quotelev1">> I don't completely understand this comment since tei.data.numeric
</em><br />
<em class="quotelev1">> maps to xsd:decimal which does support floating point numbers. I
</em><br />
<em class="quotelev1">> assume what you mean is that such numbers can't be represented
</em><br />
<em class="quotelev1">> using the mantis+exponent (aka "scientific") notation. So it will
</em><br />
<em class="quotelev1">> permit "1.23456789" but not "2e0.134"
</em><br />

You are absolutely correct, I meant scientific notation.
<br />

<p><em class="quotelev1">> Again, I find very few real use cases in the edw90 table -- in fact
</em><br />
<em class="quotelev1">> the only case where I suppose it might be plausible to permit the
</em><br />
<em class="quotelev1">> scientific notation is the value attribute on <numeric> and <num>
</em><br />

But we know that there are users who need, or at least want, to be
<br />
able to use scientific notation. Especially since there is a W3C
<br />
datatype ready-made that supports it, I can see no reason to tell
<br />
them they can't use scientific notation.
<br />

<p><em class="quotelev1">> I can't see any use case where you might want to supply a
</em><br />
<em class="quotelev1">> percentage so I am not very enthusiastic about that either.
</em><br />

To me a percentage is just another way of representing a floating
<br />
point number. 145% is the same as 1.45, but some users will be
<br />
happier with the former. Not a bid deal in either case, I don't
<br />
think. 
<br />

<em class="quotelev1">> Would tei.data.probability suit them?
</em><br />

I don't understand the quetsion.
<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 Sep 20 2005 - 14:10:47 EDT</span>
</div>

From Julia_Flanders at Brown.edu  Tue Sep 20 14:15:23 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Tue, 20 Sep 2005 14:15:23 -0400
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <4330449D.1070605@computing-services.oxford.ac.uk>
Message-ID: <a0620070abf55fdfc4623@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 20 Sep 2005 14:15:23 -0400</span><br />
</address>

It certainly seems to me that the TEI community is likely to need a 
<br />
representation of time that doesn't require misleading levels of 
<br />
precision. If I'm transcribing a journal whose entries include the 
<br />
time of day, I don't want to be forced to represent those times as 
<br />
accurate to the second. Am I right in guessing that this is an 
<br />
"extra"?
<br />

The option of an extended tei.data.temporal might be a good way to do this.
<br />

<em class="quotelev1">>Thanks for the clarification, and apologies for my careless usage. 
</em><br />
<em class="quotelev1">>Let's see if I;ve understood the position correctly.
</em><br />
<em class="quotelev1">>(1) ISO 8601 defines a large  number of different formats for 
</em><br />
<em class="quotelev1">>representing temporal expressions
</em><br />
<em class="quotelev1">>(2) W3C has defined a subset of these for which named w3c datatypes exist
</em><br />
<em class="quotelev1">>(3) the edw90 proposal for tei.data.temporal is to allow a 
</em><br />
<em class="quotelev1">>combination of (some of or all?) the w3c datatypes plus a couple of 
</em><br />
<em class="quotelev1">>others which Syd proposes we should allow for as well by means of a 
</em><br />
<em class="quotelev1">>pattern
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>If that's correct, the only issue we have to argue about is whether 
</em><br />
<em class="quotelev1">>or not the 'extras' are desirable enough to outweigh the possible 
</em><br />
<em class="quotelev1">>inconvenience of supporting formats which off-the-shelf w3c-focussed 
</em><br />
<em class="quotelev1">>implementations may not recognise.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I don't have a strong view on this: we could maybe distinguish 
</em><br />
<em class="quotelev1">>tei.data.temporal and tei.data.temporal.extended if others do -- the 
</em><br />
<em class="quotelev1">>distinction being that the former keeps to our original goal of 
</em><br />
<em class="quotelev1">>mapping cleanly to w3c datatypes.
</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.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 Sep 20 2005 - 14:15:29 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Sep 20 14:13:41 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 20 Sep 2005 19:13:41 +0100
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <17200.14028.790906.531915@emt.wwp.brown.edu>
Message-ID: <43305155.6090705@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, 20 Sep 2005 19:13:41 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev2">>>1. add_at_place 
</em><br />
<em class="quotelev2">>>   addSpan_at_place
</em><br />
<em class="quotelev2">>>           -->  tei.data.enumerated
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>What do you propose the value list be? The list{} method proposed
</em><br />
<em class="quotelev1">>permits things like "opposite top left" (which is also permitted in
</em><br />
<em class="quotelev1">>P4). 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I have no particular proposal. Any list I came up with only be advisory 
<br />
anyway.
<br />

<p><em class="quotelev2">>>   metDecl_at_type    
</em><br />
<em class="quotelev2">>>           -->  tei.data.enumerated
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Again, we need to account for the fact that more than 1 "value" is
</em><br />
<em class="quotelev1">>permitted. Thus the value list would have to account for the various
</em><br />
<em class="quotelev1">>combinations. Luckily, since there are only 3 of 'em, in this case
</em><br />
<em class="quotelev1">>it's not hard:
</em><br />
<em class="quotelev1">>  met
</em><br />
<em class="quotelev1">>  real
</em><br />
<em class="quotelev1">>  rhyme
</em><br />
<em class="quotelev1">>  met;real
</em><br />
<em class="quotelev1">>  met;rhyme
</em><br />
<em class="quotelev1">>  real;rhyme
</em><br />
<em class="quotelev1">>  met;real;rhyme
</em><br />
<em class="quotelev1">>(In EDW90 I just copied what P4 says to do: "One or more of the three
</em><br />
<em class="quotelev1">>attribute names met, real, or rhyme, separated by whitespace", thus
</em><br />
<em class="quotelev1">>   list { ("met" | "real" | "rhyme")+ }
</em><br />
<em class="quotelev1">>Both P4 and EDW90 permit silly combinations like "met real met
</em><br />
<em class="quotelev1">>real".)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

o here;s a case where an enumeration is both possible and desirable. good!
<br />

<p><p><em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>2. tei.pointerGroup_at_domains  
</em><br />
<em class="quotelev2">>>          -->  tei.data.pointers
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I don't really see it as a plus to permit values that the prose says
</em><br />
<em class="quotelev1">>are invalid just to say we used a datatype directly. The EDW90
</em><br />
<em class="quotelev1">>recommendation matches the prose perfectly. (It is
</em><br />
<em class="quotelev1">>  list { tei.data.pointer, tei.data.pointers }
</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">>On the other hand, if everyone really thinks it is extremely
</em><br />
<em class="quotelev1">>important to use an abstract TEI datatype instead of a perfectly
</em><br />
<em class="quotelev1">>reasonable combination of 'em like the above, I suppose we could move
</em><br />
<em class="quotelev1">>the "must be 2 or more" check into a Schematron rule. Seems like the
</em><br />
<em class="quotelev1">>lesser of two evils, at least.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
Actually, I wonder if it might not be better to rethink this attribute 
<br />
into two?
<br />

<p><p><em class="quotelev1">> 
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>3. schemaSpec_at_start
</em><br />
<em class="quotelev2">>>    specDesc_at_atts   
</em><br />
<em class="quotelev2">>>         --> tei.data.names
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Again, why use a lax constraint when the proper one is readily
</em><br />
<em class="quotelev1">>available just to say you used a datatype? There are three possible
</em><br />
<em class="quotelev1">>declarations for tei.data.names on the table, and only one of them
</em><br />
<em class="quotelev1">>actually constrain this attribute properly:
</em><br />
<em class="quotelev1">>* list { xsd:NCName+ }  ->  does not permit "musicML:note", but since 
</em><br />
<em class="quotelev1">>                            there is an ns= attribute, I'm betting
</em><br />
<em class="quotelev1">>                            that's considered a good thing, right
</em><br />
<em class="quotelev1">>                            Sebastian?
</em><br />
<em class="quotelev1">>* list { xsd:NMTOKEN+ }  ->  permits "--notAllowed"
</em><br />
<em class="quotelev1">>* list { xsd:token { pattern="\S+" } }  ->  permits "${notAllowed}"
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>If we decide tei.data.names should boil down to something other than
</em><br />
<em class="quotelev1">>the first, then I think we should just use the proper constraint
</em><br />
<em class="quotelev1">>without a TEI datatype and not fret it.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
Is this another instance of the particular problem that we;re using 
<br />
"name" sometimes to mean a NMTOKEN and sometimes not?
<br />

<em class="quotelev2">>>4. date_at_precision
</em><br />
<em class="quotelev2">>>       --> tei.data.certainty
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I think this is a really bad idea. First off, <date> should probably
</em><br />
<em class="quotelev1">>not have a precision= attribute. The precision should be expressed in
</em><br />
<em class="quotelev1">>the value=. Furthermore, while I suppose vague terms like "high",
</em><br />
<em class="quotelev1">>"medium", and "low" are occasionally applied to the precision, it is
</em><br />
<em class="quotelev1">>much more common, and far more useful, to express the unit to which a
</em><br />
<em class="quotelev1">>measurement is precise. So if we really wanted to separate precision
</em><br />
<em class="quotelev1">>from the value=, we would want precision= of date to have values like
</em><br />
<em class="quotelev1">>"century", "decade", "year", "month", "week", and "day".
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

I can't remember who suggested having "precision" as an explicit 
<br />
attribute on date. It does seem to overlap with the value attribute.  
<br />
Unless anyone wants to fight to the death for it, I propose we remove it.
<br />

<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>5. tei.datable_at_dateAttrib
</em><br />
<em class="quotelev2">>>       --> tei.data.enumerated
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Yes, that's what is recommended: tei.enumerated with a value list of
</em><br />
<em class="quotelev1">>"datable" | "dated" | "unknown".
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

OK
<br />

<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>6. locus_at_scheme
</em><br />
<em class="quotelev2">>>       --> tei.data.name
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I presume that's because you don't want to argue with Matthew and
</em><br />
<em class="quotelev1">>David over the possible values? :-) Seriously, I don't currently
</em><br />
<em class="quotelev1">>really understood the purpose of this attribute. <locus> describes a
</em><br />
<em class="quotelev1">>location in the current manuscript, which (supposedly) has only one
</em><br />
<em class="quotelev1">>foliation scheme which should be described in //supportDesc/foliation
</em><br />
<em class="quotelev1">>(of which only 0 or 1 are permitted, right?). So what does scheme=
</em><br />
<em class="quotelev1">>buy us?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

Matthew? what is this attribute for? I'm too tired to remember...
<br />

<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>7. fragmentPattern_at_pat
</em><br />
<em class="quotelev2">>>      --> tei.data.notation
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>As above, if "tei.data.notation" is for "notations TEI made up", this
</em><br />
<em class="quotelev1">>doesn't belong.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

See other note.
<br />

<em class="quotelev2">>>8. schemaSpec_at_namespace
</em><br />
<em class="quotelev2">>>    elementSpec_at_ns (why isnt it "namespace" btw?)
</em><br />
<em class="quotelev2">>>       --> these could be xsd:uri as proposed, or tei.data.pointer, but 
</em><br />
<em class="quotelev2">>>maybe since they have to be
</em><br />
<em class="quotelev2">>>             real namespace names (i.e. "#foo" won't do) maybe shd be 
</em><br />
<em class="quotelev2">>>their own datatype?
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Yes, all our ns= and namespace= attributes need to be brought into
</em><br />
<em class="quotelev1">>alignment. I don't care which.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>However, as I read the spec, "#foo" is a perfectly valid namespace.
</em><br />
<em class="quotelev1">>Stupid perhaps, but valid.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

OK, that solves that one.
<br />

<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>9.   tei.declarable_at_default
</em><br />
<em class="quotelev2">>>     tei.identifiable_at_predeclare
</em><br />
<em class="quotelev2">>>     metSym_at_terminal
</em><br />
<em class="quotelev2">>>     numeric_at_trunc
</em><br />
<em class="quotelev2">>>     binary_at_value                  
</em><br />
<em class="quotelev2">>>        --> are all xsd:boolean (so "unknown" not allowed) ; could just 
</em><br />
<em class="quotelev2">>>be tei.data.truthValue with extra rule
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Could be. And at one point in the history of that EDW90 table, they
</em><br />
<em class="quotelev1">>were. But a week or two ago we agreed to go directly with
</em><br />
<em class="quotelev1">>xsd:boolean. 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

So we either have to have a pair of datatypes, one permitting "unknown" 
<br />
and one not, or we have to have an additional rule to exclude "unknown" 
<br />
in cases where it makes no sense, like these.
<br />

<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>10.  timeline_at_interval
</em><br />
<em class="quotelev2">>>       when_at_interval   
</em><br />
<em class="quotelev2">>>       --> tei.data.numeric | -1  (or think of a better way of
</em><br />
<em class="quotelev2">>>           doing the -1)
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>a) We'd go back to needing unit= (I'm not saying this is so horrible,
</em><br />
<em class="quotelev1">>   just want to make sure everyone understands the implications) and
</em><br />
<em class="quotelev1">>   violate the policy of using W3C Schema datatypes where applicable.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>b) All of the proposed declarations of tei.data.numeric already
</em><br />
<em class="quotelev1">>   permit -1.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>c) This permits all other negative numbers, which P4 explicitly
</em><br />
<em class="quotelev1">>   disallows. 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>d) If you meant 'tei.data.count', it won't do as fractions may be
</em><br />
<em class="quotelev1">>   needed. 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>e) Now that I think about it, the pattern EDW90 recommends has a
</em><br />
<em class="quotelev1">>   problem, too: it permits "-0.5".
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Thus, I am now leaning towards
</em><br />
<em class="quotelev1">>   xsd:long { minInclusive = "0" }  |  xsd:token "unknown"
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

where did the "unknown" come from?  I think it shd remain 
<br />
tei.data.numeric, but with the constraint that it can't be smaller than -1
<br />

<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>11. several attributes with proposed  datypes of "xsd:NCName" -> 
</em><br />
<em class="quotelev2">>>    tei.data.name
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Again, only if we agree tei.data.name -> xsd:NCName, of which I've
</em><br />
<em class="quotelev1">>yet to be convinced.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

ee discussion elsewhere
<br />

<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>12. several attributes with proposed datatypes of
</em><br />
<em class="quotelev2">>>    "xsd:nonNegativeInteger" --> there are enough of these that I
</em><br />
<em class="quotelev2">>>    propose a new datatype "tei.data.count"
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Fine with me, although I'm not sure what it gains for us.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

It gives us a meaningful TEI datatype.
<br />

<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>13. sense_at_level -> tei.<!--nospam-->data.count
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Fine.
</em><br />
<em class="quotelev1">>(Just so everyone understands, the only real difference between
</em><br />
<em class="quotelev1">>  xsd:unsignedShort
</em><br />
<em class="quotelev1">>and
</em><br />
<em class="quotelev1">>  tei.data.count -> xsd:nonNegativeIngeger
</em><br />
<em class="quotelev1">>is that the software engineer designing an application that reads a
</em><br />
<em class="quotelev1">>TEI-encoded dictionary knows that in the former case whenever she
</em><br />
<em class="quotelev1">>comes across a level= of <sense> she need only set aside 16 bits to
</em><br />
<em class="quotelev1">>hold the value; with the latter she gets no such assurances. The
</em><br />
<em class="quotelev1">>other difference, that xsd:unsignedShort has a maximum value of
</em><br />
<em class="quotelev1">>65,535, isn't a practical problem.)
</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="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> Tue Sep 20 2005 - 14:20:42 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Sep 20 17:41:39 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 21 Sep 2005 06:41:39 +0900
Subject: [tei-council] naming languages
In-Reply-To: <17200.17413.755118.837616@emt.wwp.brown.edu>
Message-ID: <ygfvf0v1koc.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 21 Sep 2005 06:41:39 +0900</span><br />
</address>

Syd Bauman <Syd_Bauman_at_Brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev2">>> oh look, this fun
</em><br />
<em class="quotelev2">>> http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> This, I believe, is a draft of the (much anticipated?) successor to
</em><br />
<em class="quotelev1">> RFC 3066. xml:lang= is already defined as "3066 or its successor",
</em><br />
<em class="quotelev1">> but IIRC there are sections of CH that will need to be updated when
</em><br />
<em class="quotelev1">> this becomes a real RFC.
</em><br />

Actually, this is the 12th version of a document that has been
<br />
discussed for years now.  We will have to see if they finish before P5
<br />
goes to press.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Alejandro mentioned in Paris that 2-letter initial subcodes are
</em><br />
<em class="quotelev1">> preferred to 3-letter. I don't know if CH has been updated to reflect
</em><br />
<em class="quotelev1">> that yet. However, I just quickly checked this new draft, and it
</em><br />
<em class="quotelev1">> seems that when a 2-letter code is availalbe, it *must* be used, as
</em><br />
<em class="quotelev1">> the 3-letter version will not be in the IANA registry.
</em><br />

The draft of Chapter 4 is based on an earlier version, but so far I
<br />
have not seen anything that contradicts what we say.
<br />

<p>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> Tue Sep 20 2005 - 17:41:50 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Sep 20 18:32:25 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 18:32:25 -0400
Subject: [tei–council] datatypes –– syd's comments
In-Reply-To: <432D559B.9040205@computing-services.oxford.ac.uk>
Message-ID: <17200.36345.425511.930904@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, 20 Sep 2005 18:32:25 -0400</span><br />
</address>

Lou wrote:
<br />
<em class="quotelev1">> ... tei.data.numeric maps to xsd:decimal which does support
</em><br />
<em class="quotelev1">> floating point numbers.
</em><br />

Right, you have instantiated tei.data.numeric as xsd:decimal, quite
<br />
in opposition to the recommendation, which was to use xsd:long |
<br />
xsd:double. I don't recall anyone presenting any argument as to why
<br />
xsd:decimal should be preferred. Not only does it not support
<br />
scientific notation, I believe it is harder for vendors to implement.
<br />
Did I miss something? (Always a possibility :-)
<br />

Arguments favoring xsd:decimal over xsd:double could be made (e.g.,
<br />
based on the approximation required of xsd:double), and I'd be happy
<br />
to entertain them. But as of now, I don't see why you made this
<br />
change.
<br />

---------
<br />

For those still wrapping their minds around these datatypes, I've
<br />
copied the following explanations from Eric van der Vlists book[1].
<br />

xsd:decimal --
<br />
    This datatype represents decimal numbers. The number of digits
<br />
    can be arbitrarily long (the datatype doesn't impose any
<br />
    restrictions), ... Leading and
<br />
    trailing zeros aren't considered significant and may be trimmed.
<br />
    The decimal separator is always a dot (.), and a leading sign (+
<br />
    or -) may be used, but any characters other than the 10 digits
<br />
    zero through nine are forbidden, including whitespace inside the
<br />
    value. ...
<br />

xsd:long --
<br />
    Contains an integer between -9223372036854775808 and
<br />
    9223372036854775807; i.e., the values that can be stored in a
<br />
    64-bit word.
<br />

xsd:double --
<br />
    ... represents IEEE ... double (64 bits) precision
<br />
    floating-point types. These store the values in the form of a
<br />
    mantissa and an exponent of a power of 2 (m x 2^e), allowing a large
<br />
    scale of numbers in a storage that has a fixed length.
<br />
    Fortunately, the lexical space doesn't require powers of 2 (in
<br />
    fact, it doesn't accept powers of 2), but instead uses a
<br />
    traditional scientific notation based on integer powers of 10.
<br />
    Because the value spaces (powers of 2) don't exactly match the
<br />
    values from the lexical space (powers of 10), the recommendation
<br />
    specifies that the closest value is taken. The consequence of
<br />
    this approximate matching is that float datatypes are the domain
<br />
    of approximation; most of the float values can't be considered
<br />
    exact and are approximate.
<br />
    These datatypes accept several special values: positive zero (0),
<br />
    negative zero (-0) (which is less than positive 0 but greater
<br />
    than any negative value); infinity (INF), which is greater than
<br />
    any value; negative infinity (-INF), which is less than any
<br />
    value; and "not a number" (NaN).
<br />

Note
<br />

----
[1] http://books.xmlschemata.org/relaxng/relax-CHP-8-SECT-1.html
_______________________________________________
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 Sep 20 2005 - 18:32:43 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Sep 20 18:38:53 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 18:38:53 -0400
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <4330449D.1070605@computing-services.oxford.ac.uk>
Message-ID: <17200.36733.850364.960368@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, 20 Sep 2005 18:38:53 -0400</span><br />
</address>

Lou Burnard writes:
<br />
<em class="quotelev1">> Thanks for the clarification, and apologies for my careless usage. Let's 
</em><br />
<em class="quotelev1">> see if I;ve understood the position correctly.
</em><br />
<em class="quotelev1">> (1) ISO 8601 defines a large  number of different formats for 
</em><br />
<em class="quotelev1">> representing temporal expressions
</em><br />
<em class="quotelev1">> (2) W3C has defined a subset of these for which named w3c datatypes exist
</em><br />
<em class="quotelev1">> (3) the edw90 proposal for tei.data.temporal is to allow a combination 
</em><br />
<em class="quotelev1">> of (some of or all?) the w3c datatypes plus a couple of others which Syd 
</em><br />
<em class="quotelev1">> proposes we should allow for as well by means of a pattern
</em><br />

Yes! That's it in a nutshell. (EDW90 does propose all the W3C
<br />
temporal types save duration be included; it only proposes the
<br />
addition of "time precise to the minute", but we may wish to add
<br />
"time precise to the hour" as well; I have not (yet) thought about
<br />
adding dateTime values (as opposed to time values) that are precise
<br />
to the hour or minute.)
<br />

One clarification, one caveat:
<br />

* Reminder to others that Lou's use of "pattern" in (3) is that of
<br />
  'W3C pattern facet', not a RelaxNG pattern. (The whole thing is a
<br />
  RelaxNG pattern.)
<br />

* In truth, there are quite a few other differences between W3C dates
<br />
  & times and ISO 8601 representations, which I didn't think we
<br />
  should concern ourselves with. Others may disagree, though. The
<br />
  list is at http://www.w3.org/TR/xmlschema-2/#deviantformats.
<br />

<p><em class="quotelev1">> If that's correct, the only issue we have to argue about is whether
</em><br />
<em class="quotelev1">> or not the 'extras' are desirable enough to outweigh the possible
</em><br />
<em class="quotelev1">> inconvenience of supporting formats which off-the-shelf
</em><br />
<em class="quotelev1">> w3c-focussed implementations may not recognise.
</em><br />

Since
<br />

a) I've yet to see any example of software that does something
<br />
   useful with "13:14:54" but barfs on "13:15", and
<br />
b) users aren't *required* to be imprecise
<br />

I think the extras are well worth it.
<br />

<p><em class="quotelev1">> I don't have a strong view on this: we could maybe distinguish
</em><br />
<em class="quotelev1">> tei.data.temporal and tei.data.temporal.extended if others do --
</em><br />
<em class="quotelev1">> the distinction being that the former keeps to our original goal of
</em><br />
<em class="quotelev1">> mapping cleanly to w3c datatypes.
</em><br />

A bit of a side-note: to me the proposed
<br />
   xsd:date | xsd:time | ... | xsd:token { pattern = "[whatever]" }
<br />
*is* mapping directly to W3C datatypes. (I had not contemplated this
<br />
"cleanly" business before :-) That is, nothing more than an average
<br />
RelaxNG validator that knows the W3C datatype library (e.g., jing,
<br />
xmllint) is needed to validate 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> Tue Sep 20 2005 - 18:39:10 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Sep 20 20:47:25 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 21 Sep 2005 09:47:25 +0900
Subject: [tei-council] Problem with Roma or ODD
In-Reply-To: <432FD716.30702@oucs.ox.ac.uk>
Message-ID: <ygfr7bj1c2q.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 21 Sep 2005 09:47:25 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk> writes:
<br />

<em class="quotelev1">> Christian Wittern wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>Thanks. Arrrgh.  If you say so.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> you have to distinguish between authoring a module and
</em><br />
<em class="quotelev1">> authoring an extension schema.
</em><br />

Well, I thought it was obvious from the context.  I say, I want to
<br />
change <app>.  I then throw in a new @resp.  Since there is no existing
<br />
@resp, it seemed obvious to me that the change consists of adding this
<br />
new attribute.  Maybe I got too used to languages that attempt to
<br />
magically "do the right thing"...
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>  How about putting an example of this in the
</em><br />
<em class="quotelev2">>>ODD Manual?  
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> surely there is one???
</em><br />
<em class="quotelev1">>
</em><br />
There is an example that changes <div> to use a closed valList for
<br />
@type and one that removes attributes from the linking module.  Both
<br />
do make extensive use of the @mode attribute, so maybe that should be
<br />
enough to alert the reader to the fact that this might be necessary in
<br />
the case I was attempting.  However, I wonder that if it is really
<br />
necessary, would'nt it be helpful if the Schema would say so and allow
<br />
a parser to indicate the problem?
<br />

All the best,
<br />

Christian
<br />

<p><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 />
<em class="quotelev1">> OSS Watch: JISC Open Source Advisory Service
</em><br />
<em class="quotelev1">> http://www.oss-watch.ac.uk
</em><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 Sep 20 2005 - 20:47:30 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Sep 20 22:42:36 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 22:42:36 -0400
Subject: [tei-council] datatype issues (part 1) continued,,,
In-Reply-To: <43304C61.4010808@computing-services.oxford.ac.uk>
Message-ID: <17200.51356.633809.345060@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, 20 Sep 2005 22:42:36 -0400</span><br />
</address>

<em class="quotelev1">> OK, I am perfectly happy to restrict the kind of gobbledegook permitted 
</em><br />
<em class="quotelev1">> for this datatype to a W3C-defined regular expression. That ought to fit 
</em><br />
<em class="quotelev1">> with most kinds of gobbledegook we can come up with!
</em><br />

Indeed, we can enjoy years of spewing gobbledegook (and validating
<br />
it) to our hearts' content.
<br />

<p><em class="quotelev1">> Is everyone happy with "regexp" as the name for it? how about
</em><br />
<em class="quotelev1">> "tei.data.pattern" ?
</em><br />

I don't think I care. On the one hand, I think tei.data.pattern is
<br />
less annoying as a name, but on the other the word "pattern" is
<br />
getting quite overloaded these days.
<br />

<p><em class="quotelev1">> We can probably distinguish cases where the name *must* conform to
</em><br />
<em class="quotelev1">> W3C rules about identifiers -- if it's the name of an element it
</em><br />
<em class="quotelev1">> obviously has to follow constraint on what an XML name can be. If
</em><br />
<em class="quotelev1">> however it's a name we've made up this is less obviously the case,
</em><br />
<em class="quotelev1">> and the only constraint we'd probably want to put on it is that it
</em><br />
<em class="quotelev1">> shouldnt contain white space (else we can't have tei.data.names).
</em><br />
<em class="quotelev1">> But do we really want two kinds of tei.data.name?
</em><br />

We've already done this. Those that *must* confrom to W3C rules about
<br />
identifiers are listed in the table as having xsd:Name as their
<br />
proposed type; those that don't are listed as having tei.data.token
<br />
as their proposed type.
<br />

<p><em class="quotelev1">> My proposal is yes, they [open & semi valLists] still have
</em><br />
<em class="quotelev1">> tei.data.enumerated.
</em><br />

Check. Seems to make sense. Note, though, that my earlier proposal to
<br />
use e.g. "met;real" as type= of <metDecl> won't work, as ";" is not a
<br />
permissible character in an xsd:Name, and all of the values in a
<br />
<valList> must be xsd:Names, as they are expressed in the ODD as the
<br />
ident= of <valItem>. (I'm concerned that if we changed ident= of
<br />
<valList> to be tei.data.[token,term,name] and thus allow bizarre
<br />
characters, Sebastian might go postal and spray the entire Council
<br />
with blue paint.)
<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 Sep 20 2005 - 22:42:53 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Sep 21 01:32:34 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 21 Sep 2005 14:32:34 +0900
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <17200.36733.850364.960368@emt.wwp.brown.edu>
Message-ID: <ygfll1r0yvh.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 21 Sep 2005 14:32:34 +0900</span><br />
</address>

Syd Bauman <Syd_Bauman_at_Brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> If that's correct, the only issue we have to argue about is whether
</em><br />
<em class="quotelev2">>> or not the 'extras' are desirable enough to outweigh the possible
</em><br />
<em class="quotelev2">>> inconvenience of supporting formats which off-the-shelf
</em><br />
<em class="quotelev2">>> w3c-focussed implementations may not recognise.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Since
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> a) I've yet to see any example of software that does something
</em><br />
<em class="quotelev1">>    useful with "13:14:54" but barfs on "13:15", and
</em><br />
<em class="quotelev1">> b) users aren't *required* to be imprecise
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I think the extras are well worth it.
</em><br />

I second that.  The requirement to give the @CREATEDATE up to the
<br />
seconds in METS regularily drives me crazy (I wonder who manages to
<br />
create such a record in just one second anyway).  It would be good to
<br />
save TEI users that headache.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> A bit of a side-note: to me the proposed
</em><br />
<em class="quotelev1">>    xsd:date | xsd:time | ... | xsd:token { pattern = "[whatever]" }
</em><br />
<em class="quotelev1">> *is* mapping directly to W3C datatypes. (I had not contemplated this
</em><br />
<em class="quotelev1">> "cleanly" business before :-) That is, nothing more than an average
</em><br />
<em class="quotelev1">> RelaxNG validator that knows the W3C datatype library (e.g., jing,
</em><br />
<em class="quotelev1">> xmllint) is needed to validate it.
</em><br />

This looks useful:-)
<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> Wed Sep 21 2005 - 01:32:42 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Wed Sep 21 04:23:51 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 21 Sep 2005 09:23:51 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <17200.36733.850364.960368@emt.wwp.brown.edu>
Message-ID: <43311897.3020303@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, 21 Sep 2005 09:23:51 +0100</span><br />
</address>

Syd Bauman wrote:
<br />
<em class="quotelev1">> Yes! That's it in a nutshell. (EDW90 does propose all the W3C
</em><br />
<em class="quotelev1">> temporal types save duration be included; 
</em><br />

What was the reasoning for not including duration again?
<br />
<em class="quotelev1">> Since
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> a) I've yet to see any example of software that does something
</em><br />
<em class="quotelev1">>    useful with "13:14:54" but barfs on "13:15", and
</em><br />
<em class="quotelev1">> b) users aren't *required* to be imprecise
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I think the extras are well worth it.
</em><br />

Let me just confirm this because my head must be off in the clouds, does ISO 
<br />
8601:2004 say that in order to have a valid time it has to be complete to the 
<br />
second?  I've not read the full ISO text (because like other ISO things it seems 
<br />
to cost money) so I've been relying on other people's explanations of it. 
<br />
However, the wikipedia article (which as we know might be completely wrong) says:
<br />

"It is also acceptable to omit elements to reduce precision. hh:mm, hhmm, and hh 
<br />
are all used."
<br />

This seems to indicate that you can say 13:15 or 13, etc.
<br />

Further, it even allows fractional notation:
<br />

"Fractions may also be used with all three of the time elements. These are 
<br />
indicated by using the decimal point (either a comma or dot). A fraction may 
<br />
only refer to the most precise component of a time representation -- that is, if 
<br />
you are indicated 14 hours, 30 and one half minutes, you do not include a 
<br />
seconds figure. You represent it as 14:30.5 or 1430.5. (You may replace the "." 
<br />
with a "," depending on the local custom.)"
<br />

<p>Now, is the problem with the W3C Schema datatypes and the way they implement the 
<br />
ISO standard? I know there are some variations, but it seems like a pretty major 
<br />
one to insist on 13:14:54 instead of just 13:15.
<br />

Just want to make sure I'm understanding where the problem lies.
<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> Wed Sep 21 2005 - 04:23:55 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Sep 21 04:50:47 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 21 Sep 2005 09:50:47 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43311897.3020303@computing-services.oxford.ac.uk>
Message-ID: <43311EE7.8050100@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, 21 Sep 2005 09:50:47 +0100</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> "It is also acceptable to omit elements to reduce precision. hh:mm,
</em><br />
<em class="quotelev1">> hhmm, and hh are all used."
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> This seems to indicate that you can say 13:15 or 13, etc.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
unfortunately, the W3C removed that flexibility
<br />

"The ?lexical space?
<br />
<http://www.w3.org/TR/xmlschema-2/#dt-lexical-space> of *dateTime*
<br />
consists of finite-length sequences of characters of the form: |'-'?
<br />
yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?|"
<br />

ISO 8601 has what we want, but it isn't implemented in the
<br />
schema-processing tools.
<br />

Pragmatically, whats the point of setting up datatypes and then immediately
<br />
have them knocked back down to unimplemented?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Sep 21 2005 - 04:51:09 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Sep 21 04:53:47 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 21 Sep 2005 09:53:47 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43311897.3020303@computing-services.oxford.ac.uk>
Message-ID: <43311F9B.8050407@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, 21 Sep 2005 09:53:47 +0100</span><br />
</address>

<q>
<br />
[ISO 8601] <http://www.w3.org/TR/xmlschema-2/#ISO8601> supports a
<br />
variety of "truncated" formats in which some of the characters on the
<br />
left of specific formats, for example, the century, can be omitted.
<br />
Truncated formats are, in general, not permitted for the datatypes
<br />
defined in this specification </q>
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Sep 21 2005 - 04:54:04 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Wed Sep 21 05:02:54 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 21 Sep 2005 10:02:54 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43311EE7.8050100@oucs.ox.ac.uk>
Message-ID: <433121BE.7050302@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, 21 Sep 2005 10:02:54 +0100</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev2">>>This seems to indicate that you can say 13:15 or 13, etc.
</em><br />
<em class="quotelev1">> unfortunately, the W3C removed that flexibility
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> "The ?lexical space?
</em><br />
<em class="quotelev1">> <http://www.w3.org/TR/xmlschema-2/#dt-lexical-space> of *dateTime*
</em><br />
<em class="quotelev1">> consists of finite-length sequences of characters of the form: |'-'?
</em><br />
<em class="quotelev1">> yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?|"
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> ISO 8601 has what we want, but it isn't implemented in the
</em><br />
<em class="quotelev1">> schema-processing tools.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Pragmatically, whats the point of setting up datatypes and then immediately
</em><br />
<em class="quotelev1">> have them knocked back down to unimplemented?
</em><br />

I see, I thought it might be the W3C who had removed the flexibility.
<br />
Is what we are suggesting then adding the ability to use 13:15?  Is there a way 
<br />
to still make this compatible with the W3 datatype?  (i.e. saying that if it 
<br />
only has one colon then it is really got :00 on the end.)  Or is this something 
<br />
that should be done in a processing stage?
<br />

Sorry for the naive questions, just trying to make sure I understand.
<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> Wed Sep 21 2005 - 05:02:58 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Wed Sep 21 05:08:51 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 21 Sep 2005 10:08:51 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43311F9B.8050407@oucs.ox.ac.uk>
Message-ID: <43312323.7070107@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, 21 Sep 2005 10:08:51 +0100</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev1">> <q>
</em><br />
<em class="quotelev1">> [ISO 8601] <http://www.w3.org/TR/xmlschema-2/#ISO8601> supports a
</em><br />
<em class="quotelev1">> variety of "truncated" formats in which some of the characters on the
</em><br />
<em class="quotelev1">> left of specific formats, for example, the century, can be omitted.
</em><br />
<em class="quotelev1">> Truncated formats are, in general, not permitted for the datatypes
</em><br />
<em class="quotelev1">> defined in this specification </q>
</em><br />

Yes the bit that confused me was:
<br />

<q> Right truncated formats are also, in general, not permitted for the 
<br />
datatypes defined in this specification with the following exceptions: 
<br />
right-truncated representations of dateTime are used as lexical representations 
<br />
for date, gMonth, gYear.</q>
<br />

It seems silly to allow it for date, gMonth, and gYear, but not for time.  I 
<br />
understand there is a minor benefit in implementations, but the same type of 
<br />
logic has to exist for processing right-truncated date as time, so don't see 
<br />
that it is much of a saving.  *shrug* Oh well, I'm sure more able brains than 
<br />
mine have thought this through...
<br />

I'm still not convinced that xsd:duration should be excluded.
<br />

Apologies,
<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> Wed Sep 21 2005 - 05:09:04 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Sep 21 05:25:05 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 21 Sep 2005 10:25:05 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43312323.7070107@computing-services.oxford.ac.uk>
Message-ID: <433126F1.4060102@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, 21 Sep 2005 10:25:05 +0100</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> <q> Right truncated formats are also, in general, not permitted for
</em><br />
<em class="quotelev1">> the datatypes defined in this specification with the following
</em><br />
<em class="quotelev1">> exceptions: right-truncated representations of dateTime are used as
</em><br />
<em class="quotelev1">> lexical representations for date, gMonth, gYear.</q>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> It seems silly to allow it for date, gMonth, and gYear, but not for
</em><br />
<em class="quotelev1">> time.  I understand there is a minor benefit in implementations, but
</em><br />
<em class="quotelev1">> the same type of logic has to exist for processing right-truncated
</em><br />
<em class="quotelev1">> date as time, so don't see that it is much of a saving.  *shrug* Oh
</em><br />
<em class="quotelev1">> well, I'm sure more able brains than mine have thought this through...
</em><br />

I just shouted at two W3C folks about this and they shrugged their
<br />
shoulders and said "well you should see the problems timezones cause" :-}
<br />

<p><p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Sep 21 2005 - 05:25:24 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Sep 21 06:36:26 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 21 Sep 2005 11:36:26 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <433121BE.7050302@computing-services.oxford.ac.uk>
Message-ID: <433137AA.6000600@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, 21 Sep 2005 11:36:26 +0100</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Is what we are suggesting then adding the ability to use 13:15?  Is
</em><br />
<em class="quotelev1">> there a way to still make this compatible with the W3 datatype?
</em><br />

you can say "xsd:dateTime | AComplexRegexp" if you want.
<br />

me, I would just swallow my objections and say "lets use XSD datatypes
<br />
and lobby them to improve it".
<br />
I see little point in saying "we want full ISO 8601 but we'll just
<br />
reduce it to CDATA for validation purposes".
<br />
babies, bathwater, etc.
<br />

<em class="quotelev1">> (i.e. saying that if it only has one colon then it is really got :00
</em><br />
<em class="quotelev1">> on the end.)
</em><br />

cant be done in a schema
<br />

<em class="quotelev1">>   Or is this something that should be done in a processing stage?
</em><br />

processing is another matter, this is about validation only
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Sep 21 2005 - 06:36:55 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Wed Sep 21 07:50:51 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 21 Sep 2005 13:50:51 +0200
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <433126F1.4060102@oucs.ox.ac.uk>
Message-ID: <4331491B.7090106@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, 21 Sep 2005 13:50:51 +0200</span><br />
</address>

The trouble with right truncation, then, is that you have to know the 
<br />
time zone before you know how to interpret the time? and the timezone 
<br />
indicator is the rightmost part being truncated?
<br />

Duh! they should have put the time zone indicator FIRST!
<br />

<p>Sebastian Rahtz wrote:
<br />
<em class="quotelev1">> James Cummings wrote:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>><q> Right truncated formats are also, in general, not permitted for
</em><br />
<em class="quotelev2">>>the datatypes defined in this specification with the following
</em><br />
<em class="quotelev2">>>exceptions: right-truncated representations of dateTime are used as
</em><br />
<em class="quotelev2">>>lexical representations for date, gMonth, gYear.</q>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>It seems silly to allow it for date, gMonth, and gYear, but not for
</em><br />
<em class="quotelev2">>>time.  I understand there is a minor benefit in implementations, but
</em><br />
<em class="quotelev2">>>the same type of logic has to exist for processing right-truncated
</em><br />
<em class="quotelev2">>>date as time, so don't see that it is much of a saving.  *shrug* Oh
</em><br />
<em class="quotelev2">>>well, I'm sure more able brains than mine have thought this through...
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I just shouted at two W3C folks about this and they shrugged their
</em><br />
<em class="quotelev1">> shoulders and said "well you should see the problems timezones cause" :-}
</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> Wed Sep 21 2005 - 07:43:53 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Sep 21 08:02:22 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 21 Sep 2005 13:02:22 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <4331491B.7090106@oucs.ox.ac.uk>
Message-ID: <43314BCE.2070308@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, 21 Sep 2005 13:02:22 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">> The trouble with right truncation, then, is that you have to know the
</em><br />
<em class="quotelev1">> time zone before you know how to interpret the time? and the timezone
</em><br />
<em class="quotelev1">> indicator is the rightmost part being truncated?
</em><br />

not sure about that. I was not implying TZ was the *reason* for
<br />
disallowing truncation.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Duh! they should have put the time zone indicator FIRST!
</em><br />

TZ was probably an afterthought and the implementation followed that :-}
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Sep 21 2005 - 08:02:40 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Wed Sep 21 11:15:59 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 21 Sep 2005 11:15:59 -0400
Subject: [tei-council] tei.data.blah
In-Reply-To: <4329E16E.4060106@oucs.ox.ac.uk>
Message-ID: <17201.31023.728951.417524@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, 21 Sep 2005 11:15:59 -0400</span><br />
</address>

<em class="quotelev1">> so call them macro.data.blah
</em><br />

Either is fine with me.
<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 Sep 21 2005 - 11:16:18 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Sep 21 11:41:04 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 21 Sep 2005 16:41:04 +0100
Subject: [tei-council] tei.data.blah
In-Reply-To: <17201.31023.728951.417524@emt.wwp.brown.edu>
Message-ID: <43317F10.90700@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, 21 Sep 2005 16:41:04 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev2">>>so call them macro.data.blah
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Either is fine with me.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
we could resolve this next week in the class meeting. I'd quite
<br />
like to spend 30 minutes then writing down the final naming rules
<br />
once and for all. Including names of modules, about which I am
<br />
not very happy :-}
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Sep 21 2005 - 11:41:22 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Wed Sep 21 14:37:16 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 21 Sep 2005 14:37:16 -0400
Subject: [tei-council] datatypes
In-Reply-To: <432D062B.1020908@oucs.ox.ac.uk>
Message-ID: <17201.43100.255234.25151@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, 21 Sep 2005 14:37:16 -0400</span><br />
</address>

<em class="quotelev2">> >* tei.data.numeric: the change removes support for a constituency
</em><br />
<em class="quotelev2">> >  that we already now about: those who need to enter floating point
</em><br />
<em class="quotelev2">> >  numbers.
</em><br />
<em class="quotelev2">> >
</em><br />
<em class="quotelev1">> I thought we went through this on TEI-L, and someone like
</em><br />
<em class="quotelev1">> M Beddows showed that the W3C datatypes did do everything
</em><br />
<em class="quotelev1">> needed?
</em><br />

Well, yes, there are W3C datatypes for everything we need (or close
<br />
enough): xsd:long will handle any integer up to an enormous size, and
<br />
xsd:double will handle most any fraction and supports scientific
<br />
notation (thus supporting numbers that are larger than can be
<br />
represented with xsd:long). But these aren't what's in the tagdoc.
<br />
xsd:decimal is. 
<br />

<p><em class="quotelev2">> > Furthermore, I still claim it makes sense to permit
</em><br />
<em class="quotelev2">> >  percentages
</em><br />
<em class="quotelev2">> >
</em><br />
<em class="quotelev1">> at first blush, I think a percentage is like a dimension,
</em><br />
<em class="quotelev1">> not a numeric (width=23cm, width=88%). mixing
</em><br />
<em class="quotelev1">> it in with numeric seems pretty weird. I may well be wrong.
</em><br />

That is exactly the same as (width=23cm, width=0.88). In the first
<br />
case, you have a quantity ("23") and a unit ("cm"). In the second
<br />
case you have a quantity ("88%" or "0.88", same thing) and no unit.
<br />
88% of what? In the world of web widths, the implied unit is usually
<br />
"the width of the window".
<br />

<p><em class="quotelev2">> > (One could argue, though, that the percentages should be limited
</em><br />
<em class="quotelev2">> > to 8 characters maximum (effectively limiting them to 3 or 4
</em><br />
<em class="quotelev2">> > decimal places of precision), so that any tei.data.numeric value
</em><br />
<em class="quotelev2">> > could fit into 64 bits.)
</em><br />
<em class="quotelev2">> >
</em><br />
<em class="quotelev1">> haven't we gone beyond worrying about number of bits
</em><br />
<em class="quotelev1">> we use up?
</em><br />

I'm not sure it's worth the bother, but if I understand correctly
<br />
most common math subroutine libraries have trouble with > 64 bit
<br />
numbers (which is why xsd:long and xsd:double are 64 bit!). There
<br />
exist fancy math libraries for handling things like infinite
<br />
precision base-10 numbers (i.e., xsd:decimal or unlimited-digit
<br />
percentages). However, my understanding is that they are not as
<br />
readily available, not available in some languages, and not easy to
<br />
install & use on all systems. I don't know. The only one I've ever
<br />
tried to install & use took me about 4 minutes. (Can't remember its
<br />
name though ...)
<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 Sep 21 2005 - 14:37:34 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Wed Sep 21 18:50:52 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 21 Sep 2005 23:50:52 +0100
Subject: [tei-council] Datatype : roundup
Message-ID: <4331E3CC.6020908@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, 21 Sep 2005 23:50:52 +0100</span><br />
</address>

Rather than repeat with comment all the last few days messages, here is 
<br />
my take on where I think we now are.
<br />

1. No-one has dissented from the basic objective of providing tei 
<br />
datatypes which together cover the full range of current requirements as 
<br />
identified in Syd's edw90 table. There has been debate chiefly where the 
<br />
requirements identified there don't map tidily on to existing W3C 
<br />
datatypes.
<br />

2. Here are my proposals for resolving the currently debated issues:
<br />

a. tei.data.notation : renamed as tei.data.pattern and explicitly tied 
<br />
to regular  expression syntax [some debate is needed on how we define 
<br />
this: syd's original proposal suggested we should support only the W3C 
<br />
rather restricted version of regexps, i.e. the pattern has to be 
<br />
"anchored". Is that OK, or are we supporting apache-style 
<br />
perl-compatible regexps? or just the original syntax built into grep 
<br />
(but not egrep)?]
<br />

b. split the currently defined tei.data.name into two: tei.data.ident 
<br />
and tei.data.name  -- the former is used for those cases where the name 
<br />
concerned *must* be an XML-compatible name and maps to xsd:Name ; the 
<br />
latter for names of any kind excluding spaces (mapping to NMTOKEN?)
<br />

c. add a pattern to the list of alternatives proposed for 
<br />
tei.data.temporal which  supports  right-truncated times (just don't say 
<br />
i didnt tell you it'll all end in tears)
<br />

d. define  tei.data.probability as a value between 0 and 1 only
<br />

e. define tei.data. numeric as double, rather than decimal
<br />

I've now changed all the definitions accordingly, added a little bit 
<br />
more explication, and regenerated the HTML preview pages at 
<br />
http://www.tei-c.org/Drafts/DTYPES/
<br />

I am sure Council members are anxious to move on from this rather 
<br />
tedious subject to the exciting challenges of rethinking the class 
<br />
system, but it would be REALLY HELPFUL if they could give this latest 
<br />
iteration a quick read through and comment as to whether or not they think
<br />

-- the list of datatypes proposed is adequate to our needs (as 
<br />
summarized in edw90)
<br />
-- the definitions for them proposed are reasonably comprehensible and 
<br />
adequate
<br />

We could then move on...
<br />

<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> Wed Sep 21 2005 - 18:48:52 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Sep 21 21:00:50 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 22 Sep 2005 10:00:50 +0900
Subject: [tei-council] Datatype : roundup
In-Reply-To: <4331E3CC.6020908@computing-services.oxford.ac.uk>
Message-ID: <ygfpsr1ykzh.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 22 Sep 2005 10:00:50 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Rather than repeat with comment all the last few days messages, here
</em><br />
<em class="quotelev1">> is my take on where I think we now are.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 1. No-one has dissented from the basic objective of providing tei
</em><br />
<em class="quotelev1">>    datatypes which together cover the full range of current
</em><br />
<em class="quotelev1">>    requirements as identified in Syd's edw90 table. There has been
</em><br />
<em class="quotelev1">>    debate chiefly where the requirements identified there don't map
</em><br />
<em class="quotelev1">>    tidily on to existing W3C datatypes.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> 2. Here are my proposals for resolving the currently debated issues:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> a. tei.data.notation : renamed as tei.data.pattern and explicitly tied
</em><br />
<em class="quotelev1">> to regular  expression syntax [some debate is needed on how we define
</em><br />
<em class="quotelev1">> this: syd's original proposal suggested we should support only the W3C
</em><br />
<em class="quotelev1">> rather restricted version of regexps, i.e. the pattern has to be
</em><br />
<em class="quotelev1">> "anchored". Is that OK, or are we supporting apache-style
</em><br />
<em class="quotelev1">> perl-compatible regexps? or just the original syntax built into grep
</em><br />
<em class="quotelev1">> (but not egrep)?]
</em><br />

Why on earth has nobody yet tought of standardizing regexes?  You
<br />
surely to not have to worry about truncated timezones there...
<br />

However, thinking of implementation in validators, it probably it the
<br />
only viable option to go with the W3C.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> b. split the currently defined tei.data.name into two: tei.data.ident
</em><br />
<em class="quotelev1">> and tei.data.name  -- the former is used for those cases where the
</em><br />
<em class="quotelev1">> name concerned *must* be an XML-compatible name and maps to xsd:Name ;
</em><br />
<em class="quotelev1">> the latter for names of any kind excluding spaces (mapping to
</em><br />
<em class="quotelev1">> NMTOKEN?)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> c. add a pattern to the list of alternatives proposed for
</em><br />
<em class="quotelev1">> tei.data.temporal which  supports  right-truncated times (just don't
</em><br />
<em class="quotelev1">> say i didnt tell you it'll all end in tears)
</em><br />

Please, please do so!!
<br />

<em class="quotelev1">> d. define  tei.data.probability as a value between 0 and 1 only
</em><br />

+1
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> -- the list of datatypes proposed is adequate to our needs (as
</em><br />
<em class="quotelev1">>    summarized in edw90)
</em><br />
<em class="quotelev1">> -- the definitions for them proposed are reasonably comprehensible and
</em><br />
<em class="quotelev1">>    adequate
</em><br />
<em class="quotelev1">>
</em><br />

I see you folded this already into "The Guidelines", but probably
<br />
something went wrong during the conversion, there are things like
<br />
attributes on <> and some quotes also seem amiss.
<br />

Apart from that and apart from the fact that this is like looking at a
<br />
list of words and then asking "Is this all you will ever need to talk
<br />
to each other", it seems sufficient to this tired brain.
<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> Wed Sep 21 2005 - 21:00:56 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Thu Sep 22 01:58:21 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 22 Sep 2005 01:58:21 -0400
Subject: [tei-council] Datatype : roundup
In-Reply-To: <4331E3CC.6020908@computing-services.oxford.ac.uk>
Message-ID: <17202.18429.528819.465597@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, 22 Sep 2005 01:58:21 -0400</span><br />
</address>

Thank you for the succinct summary, Lou. I'm going to address it
<br />
quickly now, but can't really give it thorough treatment.
<br />

<p><em class="quotelev1">> 1. No-one has dissented from the basic objective of providing tei
</em><br />
<em class="quotelev1">> datatypes which together cover the full range of current
</em><br />
<em class="quotelev1">> requirements as identified in Syd's edw90 table.
</em><br />

I'm not 100% sure on what you mean by this. I thought we had agreed
<br />
*not* to have a TEI datatype for xsd:boolean. I also thought it might
<br />
be worth not bothering with the indirection for xsd:nonNegativeInteger
<br />
and xsd:Name. At the moment I don't care very much, but I think some
<br />
users really get fed up with indirection, and when it's almost
<br />
completely pointless ...
<br />

<p><em class="quotelev1">> a. tei.data.notation : renamed as tei.data.pattern and explicitly
</em><br />
<em class="quotelev1">> tied to regular expression syntax
</em><br />

Sounds good to me.
<br />

<p><em class="quotelev1">> [some debate is needed on how we define this: syd's original
</em><br />
<em class="quotelev1">> proposal suggested we should support only the W3C rather restricted
</em><br />
<em class="quotelev1">> version of regexps, i.e. the pattern has to be "anchored". Is that
</em><br />
<em class="quotelev1">> OK, or are we supporting apache-style perl-compatible regexps? or
</em><br />
<em class="quotelev1">> just the original syntax built into grep (but not egrep)?]
</em><br />

We initially went with W3C some 2 or 3 years ago using the (perhaps
<br />
flawed) logic that it was a regular expression language that any XML
<br />
software would have to know in order to support the W3C Schema
<br />
"pattern" facet anyway. And although they are anchored, I think the
<br />
characterization of them as "restricted" is very misleading. The W3C
<br />
regular expression language is basically the Perl language with quite
<br />
a few useful extensions like
<br />
  \i == matches any char that's legal as an initial char in an
<br />
        xsd:Name  
<br />
  \c == matches any char that's legal in an xsd:Name
<br />
  \p{Po} == matches any char from the PUA
<br />

<p><em class="quotelev1">> b. split the currently defined tei.data.name into two:
</em><br />
<em class="quotelev1">> tei.data.ident and tei.data.name -- the former is used for those
</em><br />
<em class="quotelev1">> cases where the name concerned *must* be an XML-compatible name and
</em><br />
<em class="quotelev1">> maps to xsd:Name ; the latter for names of any kind excluding
</em><br />
<em class="quotelev1">> spaces (mapping to NMTOKEN?)
</em><br />

I like tei.data.ident (although again, it's not clear to me that
<br />
abstracting to a TEI datatype gains us much -- I guess the schema
<br />
extender who knows ahead of time she will never want to use colonized
<br />
names or names > 31 chars long could re-declare it as
<br />
  xsd:NCName { maxLength = "31" }
<br />
so I'll take that back; I'm all in favor.)
<br />

As for tei.data.name:
<br />
* the name is really bad; I'd prefer to live with the confusion of
<br />
  tei.data.token. (Remember, the string "xsd:token" will only appear
<br />
  a few times in all of P5; in the declarations of at most half a
<br />
  dozen datatypes.)
<br />
* I think we should probably be more permissive than NMTOKEN.
<br />

<p><em class="quotelev1">> c. add a pattern to the list of alternatives proposed for
</em><br />
<em class="quotelev1">> tei.data.temporal which supports right-truncated times (just don't
</em><br />
<em class="quotelev1">> say i didnt tell you it'll all end in tears)
</em><br />

OK, I won't say that. But what do you think could happen to make it
<br />
end in tears?
<br />

<p><em class="quotelev1">> d. define  tei.data.probability as a value between 0 and 1 only
</em><br />

I really don't see why not permit percentages. Users had the choice
<br />
in P4, when we couldn't even validate it. Now we can.
<br />

<p><em class="quotelev1">> e. define tei.data. numeric as double, rather than decimal
</em><br />

Oh dear. This is the painful one. I was almost hoping to not have to
<br />
tackle this. "Tackle what?" you ask. If I understand correctly, Lou
<br />
is now proposing to declare that all TEI numbers be an xsd:double
<br />
rather than the proposed xsd:double | xsd:long.
<br />

What's the difference? Since xsd:double can represent a *much* larger
<br />
number range than xsd:long, why would anyone care? Because it doesn't
<br />
represent it exactly. In order to gain its incredible range, the trade
<br />
off is precision. When I wrote EDW90 I had no idea how precise an
<br />
xsd:double is (it's not easy to find out), but I knew it was less
<br />
than the 19 digits you can get for integers from xsd:long. I figured
<br />
it's not hard for an application to tell the difference (if it has a
<br />
dot or a letter e, it's an xsd:double, otherwise it's an xsd:long),
<br />
so why not just use 'em both?
<br />

But (Lou seems to be asking) do we really need the xsd:long? I've
<br />
just spent some time delving into this, and it seems that an
<br />
xsd:double can represent numbers with up to ~16 significant
<br />
digits.[1] So my addition of xsd:long to our datatype seems to only
<br />
support those users who wish to precisely indicate integers between
<br />
1e16 (10,000,000,000,000,000) and 1e19 (10,000,000,000,000,000,000).
<br />
That is to say, if you wanted to record the combined gross domestic
<br />
product of the EU and USA to the penny, you *might* need an xsd:long
<br />
to do so. If you don't mind representing it in euros or dollars, an
<br />
xsd:double will do. (I have never seen a representation of GDP that
<br />
could not be expressed in a 32-bit floating point number, e.g.
<br />
$5.625e13 is the CIA estimate for 2004.)
<br />

The executive summary is that 
<br />
* I now think xsd:double alone will do
<br />
* Someone should check my math on this, it is quite complicated stuff 
<br />
* If someone has a use-case where we'd want to represent a 16-digit
<br />
  or greater integer precisely (i.e., to the 1s place), we should
<br />
  reconsider xsd:long. (Yes, a credit card number along with the
<br />
  security code on the back is 19 digits long, but it's not really a
<br />
  number, it's a string that just happens to be composed of only
<br />
  digits.)
<br />

Note
<br />

----
[1]
http://cch.loria.fr/documentation/IEEE754/numerical_comp_guide/ncg_math.doc.html#555
_______________________________________________
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 Sep 22 2005 - 01:58:41 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Thu Sep 22 05:19:11 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 22 Sep 2005 10:19:11 +0100
Subject: [tei-council] Datatype : roundup
In-Reply-To: <17202.18429.528819.465597@emt.wwp.brown.edu>
Message-ID: <4332770F.9020209@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, 22 Sep 2005 10:19:11 +0100</span><br />
</address>

Syd Bauman wrote:
<br />
<em class="quotelev1">> Thank you for the succinct summary, Lou. I'm going to address it
</em><br />
<em class="quotelev1">> quickly now, but can't really give it thorough treatment.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>1. No-one has dissented from the basic objective of providing tei
</em><br />
<em class="quotelev2">>>datatypes which together cover the full range of current
</em><br />
<em class="quotelev2">>>requirements as identified in Syd's edw90 table.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I'm not 100% sure on what you mean by this. I thought we had agreed
</em><br />
<em class="quotelev1">> *not* to have a TEI datatype for xsd:boolean. I also thought it might
</em><br />
<em class="quotelev1">> be worth not bothering with the indirection for xsd:nonNegativeInteger
</em><br />
<em class="quotelev1">> and xsd:Name. At the moment I don't care very much, but I think some
</em><br />
<em class="quotelev1">> users really get fed up with indirection, and when it's almost
</em><br />
<em class="quotelev1">> completely pointless ...
</em><br />

It is not complettely pointless. It provide us with a space in which to 
<br />
define TEI-specific semantics in addition to the basic datatyping. So we 
<br />
can say not just this is a number, but this is a number which is used to 
<br />
count something.
<br />

<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>[some debate is needed on how we define this: syd's original
</em><br />
<em class="quotelev2">>>proposal suggested we should support only the W3C rather restricted
</em><br />
<em class="quotelev2">>>version of regexps, i.e. the pattern has to be "anchored". Is that
</em><br />
<em class="quotelev2">>>OK, or are we supporting apache-style perl-compatible regexps? or
</em><br />
<em class="quotelev2">>>just the original syntax built into grep (but not egrep)?]
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> We initially went with W3C some 2 or 3 years ago using the (perhaps
</em><br />
<em class="quotelev1">> flawed) logic that it was a regular expression language that any XML
</em><br />
<em class="quotelev1">> software would have to know in order to support the W3C Schema
</em><br />
<em class="quotelev1">> "pattern" facet anyway.
</em><br />

I am not sure who the "we" in that sentence is -- possibly the SO work 
<br />
group?
<br />

And although they are anchored, I think the
<br />
<em class="quotelev1">> characterization of them as "restricted" is very misleading.
</em><br />

Well, as one who has done a lot of programming in various 
<br />
pattern-matching languages, I think the characterization is not VERY 
<br />
misleading. But it hardly matters... I am quite happy for us to stick 
<br />
with the W3C regexp language if others agree, for the good pragmatic 
<br />
reason given above, provided that we make explicit what its shortcomings 
<br />
are.
<br />

<p>  The W3C
<br />
<em class="quotelev1">> regular expression language is basically the Perl language with quite
</em><br />
<em class="quotelev1">> a few useful extensions like
</em><br />
<em class="quotelev1">>   \i == matches any char that's legal as an initial char in an
</em><br />
<em class="quotelev1">>         xsd:Name  
</em><br />
<em class="quotelev1">>   \c == matches any char that's legal in an xsd:Name
</em><br />
<em class="quotelev1">>   \p{Po} == matches any char from the PUA
</em><br />

<p>Aaargh, so it's not even a clean subset!
<br />

<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> so I'll take that back; I'm all in favor.)
</em><br />
<em class="quotelev1">> 
</em><br />
Good
<br />

<em class="quotelev1">> As for tei.data.name:
</em><br />
<em class="quotelev1">> * the name is really bad; I'd prefer to live with the confusion of
</em><br />
<em class="quotelev1">>   tei.data.token. (Remember, the string "xsd:token" will only appear
</em><br />
<em class="quotelev1">>   a few times in all of P5; in the declarations of at most half a
</em><br />
<em class="quotelev1">>   dozen datatypes.)
</em><br />

That's irrelevant to the issue here: we want people to use the TEI name 
<br />
and not be confused when they talk to others about it. No-one has yet 
<br />
proposed a better name than name.
<br />

<em class="quotelev1">> * I think we should probably be more permissive than NMTOKEN.
</em><br />
<em class="quotelev1">> 
</em><br />

We can tweak the definition if you like, but I don't understand why you 
<br />
would want to.
<br />

<p><em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>c. add a pattern to the list of alternatives proposed for
</em><br />
<em class="quotelev2">>>tei.data.temporal which supports right-truncated times (just don't
</em><br />
<em class="quotelev2">>>say i didnt tell you it'll all end in tears)
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> OK, I won't say that. But what do you think could happen to make it
</em><br />
<em class="quotelev1">> end in tears?
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
(a) difficulties in implementation
<br />
(b) confusion caused by lack of timezone information
<br />

<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>d. define  tei.data.probability as a value between 0 and 1 only
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I really don't see why not permit percentages. Users had the choice
</em><br />
<em class="quotelev1">> in P4, when we couldn't even validate it. Now we can.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />

implicity, clarity, precision...
<br />

<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>e. define tei.data. numeric as double, rather than decimal
</em><br />
<em class="quotelev1">>
</em><br />

<p>I think this is a mistake, actually. Decimal was a better choice, since 
<br />
it can represent any number, real or integer, no matter how big. It 
<br />
means you can;t use scientific notation, which someone folks on TEI-L 
<br />
suddenly woke up and asked for. I now think maybe we should have a 
<br />
different datatype for that.
<br />

Credit card numbers, by the way, are tei.data.ident, clearly.
<br />

<p><em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Oh dear. This is the painful one. I was almost hoping to not have to
</em><br />
<em class="quotelev1">> tackle this. "Tackle what?" you ask. If I understand correctly, Lou
</em><br />
<em class="quotelev1">> is now proposing to declare that all TEI numbers be an xsd:double
</em><br />
<em class="quotelev1">> rather than the proposed xsd:double | xsd:long.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> What's the difference? Since xsd:double can represent a *much* larger
</em><br />
<em class="quotelev1">> number range than xsd:long, why would anyone care? Because it doesn't
</em><br />
<em class="quotelev1">> represent it exactly. In order to gain its incredible range, the trade
</em><br />
<em class="quotelev1">> off is precision. When I wrote EDW90 I had no idea how precise an
</em><br />
<em class="quotelev1">> xsd:double is (it's not easy to find out), but I knew it was less
</em><br />
<em class="quotelev1">> than the 19 digits you can get for integers from xsd:long. I figured
</em><br />
<em class="quotelev1">> it's not hard for an application to tell the difference (if it has a
</em><br />
<em class="quotelev1">> dot or a letter e, it's an xsd:double, otherwise it's an xsd:long),
</em><br />
<em class="quotelev1">> so why not just use 'em both?
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> But (Lou seems to be asking) do we really need the xsd:long? I've
</em><br />
<em class="quotelev1">> just spent some time delving into this, and it seems that an
</em><br />
<em class="quotelev1">> xsd:double can represent numbers with up to ~16 significant
</em><br />
<em class="quotelev1">> digits.[1] So my addition of xsd:long to our datatype seems to only
</em><br />
<em class="quotelev1">> support those users who wish to precisely indicate integers between
</em><br />
<em class="quotelev1">> 1e16 (10,000,000,000,000,000) and 1e19 (10,000,000,000,000,000,000).
</em><br />
<em class="quotelev1">> That is to say, if you wanted to record the combined gross domestic
</em><br />
<em class="quotelev1">> product of the EU and USA to the penny, you *might* need an xsd:long
</em><br />
<em class="quotelev1">> to do so. If you don't mind representing it in euros or dollars, an
</em><br />
<em class="quotelev1">> xsd:double will do. (I have never seen a representation of GDP that
</em><br />
<em class="quotelev1">> could not be expressed in a 32-bit floating point number, e.g.
</em><br />
<em class="quotelev1">> $5.625e13 is the CIA estimate for 2004.)
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> The executive summary is that 
</em><br />
<em class="quotelev1">> * I now think xsd:double alone will do
</em><br />
<em class="quotelev1">> * Someone should check my math on this, it is quite complicated stuff 
</em><br />
<em class="quotelev1">> * If someone has a use-case where we'd want to represent a 16-digit
</em><br />
<em class="quotelev1">>   or greater integer precisely (i.e., to the 1s place), we should
</em><br />
<em class="quotelev1">>   reconsider xsd:long. (Yes, a credit card number along with the
</em><br />
<em class="quotelev1">>   security code on the back is 19 digits long, but it's not really a
</em><br />
<em class="quotelev1">>   number, it's a string that just happens to be composed of only
</em><br />
<em class="quotelev1">>   digits.)
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Note
</em><br />
<em class="quotelev1">> ----
</em><br />
<em class="quotelev1">> [1]
</em><br />
<em class="quotelev1">> http://cch.loria.fr/documentation/IEEE754/numerical_comp_guide/ncg_math.doc.html#555
</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.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 Sep 22 2005 - 05:19:16 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Thu Sep 22 06:16:49 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 22 Sep 2005 11:16:49 +0100
Subject: [tei-council] Datatype : roundup
In-Reply-To: <4332770F.9020209@computing-services.oxford.ac.uk>
Message-ID: <43328491.2030105@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, 22 Sep 2005 11:16:49 +0100</span><br />
</address>

Lou Burnard wrote:
<br />
<em class="quotelev3">>>> [some debate is needed on how we define this: syd's original
</em><br />
<em class="quotelev3">>>> proposal suggested we should support only the W3C rather restricted
</em><br />
<em class="quotelev3">>>> version of regexps, i.e. the pattern has to be "anchored". Is that
</em><br />
<em class="quotelev3">>>> OK, or are we supporting apache-style perl-compatible regexps? or
</em><br />
<em class="quotelev3">>>> just the original syntax built into grep (but not egrep)?]
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> We initially went with W3C some 2 or 3 years ago using the (perhaps
</em><br />
<em class="quotelev2">>> flawed) logic that it was a regular expression language that any XML
</em><br />
<em class="quotelev2">>> software would have to know in order to support the W3C Schema
</em><br />
<em class="quotelev2">>> "pattern" facet anyway.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Well, as one who has done a lot of programming in various 
</em><br />
<em class="quotelev1">> pattern-matching languages, I think the characterization is not VERY 
</em><br />
<em class="quotelev1">> misleading. But it hardly matters... I am quite happy for us to stick 
</em><br />
<em class="quotelev1">> with the W3C regexp language if others agree, for the good pragmatic 
</em><br />
<em class="quotelev1">> reason given above, provided that we make explicit what its shortcomings 
</em><br />
<em class="quotelev1">> are.
</em><br />

I don't know the differences between the various regexp standards out there, but 
<br />
on the face of it sounds like a good idea to stick to W3C in this regard.  A 
<br />
quick trawl round the  XSLT2 spec shows that its regex's seem to be (as one 
<br />
would expect) based on the XPath2, which bases them on those in W3C Schema.  So 
<br />
that at least looks like some consistency, and I didn't notice any big warning 
<br />
signs, but someone correct me if I'm wrong.
<br />

<em class="quotelev3">>>> c. add a pattern to the list of alternatives proposed for
</em><br />
<em class="quotelev3">>>> tei.data.temporal which supports right-truncated times (just don't
</em><br />
<em class="quotelev3">>>> say i didnt tell you it'll all end in tears)
</em><br />
<em class="quotelev2">>> OK, I won't say that. But what do you think could happen to make it
</em><br />
<em class="quotelev2">>> end in tears?
</em><br />
<em class="quotelev1">> (a) difficulties in implementation
</em><br />
<em class="quotelev1">> (b) confusion caused by lack of timezone information
</em><br />

Is there any sensible way to add timezone information to right-truncated times?
<br />

Although it bothers me, I think in the end I'd be willing to add :00 for seconds 
<br />
to any time recorded, if I were indeed recording times.
<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> Thu Sep 22 2005 - 06:17:05 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Thu Sep 22 06:35:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 22 Sep 2005 06:35:11 -0400
Subject: [tei-council] Datatype : roundup
In-Reply-To: <4332770F.9020209@computing-services.oxford.ac.uk>
Message-ID: <17202.35039.694032.99577@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, 22 Sep 2005 06:35:11 -0400</span><br />
</address>

<em class="quotelev1">> I am not sure who the "we" in that sentence is -- possibly the SO
</em><br />
<em class="quotelev1">> work group?
</em><br />

Yup, sorry; I should have been more explicit. SO decided on the W3C
<br />
regular expression language, and Council approved.
<br />

<p><em class="quotelev1">> Well, as one who has done a lot of programming in various
</em><br />
<em class="quotelev1">> pattern-matching languages, I think the characterization is not
</em><br />
<em class="quotelev1">> VERY misleading. But it hardly matters... I am quite happy for us
</em><br />
<em class="quotelev1">> to stick with the W3C regexp language if others agree, for the good
</em><br />
<em class="quotelev1">> pragmatic reason given above, provided that we make explicit what
</em><br />
<em class="quotelev1">> its shortcomings are.
</em><br />

What shortcomings do you have in mind? (Implicit anchoring, while a
<br />
difference, can hardly be called a shortcoming.)
<br />

<p><em class="quotelev1">> Aaargh, so it's not even a clean subset!
</em><br />

It is not a subset at all (at least, not of any language I'm aware
<br />
of).
<br />

<p><em class="quotelev2">> > As for tei.data.name:
</em><br />
<em class="quotelev2">> > * the name is really bad; I'd prefer to live with the confusion of
</em><br />
<em class="quotelev2">> >   tei.data.token. (Remember, the string "xsd:token" will only appear
</em><br />
<em class="quotelev2">> >   a few times in all of P5; in the declarations of at most half a
</em><br />
<em class="quotelev2">> >   dozen datatypes.)
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> That's irrelevant to the issue here: we want people to use the TEI
</em><br />
<em class="quotelev1">> name and not be confused when they talk to others about it. No-one
</em><br />
<em class="quotelev1">> has yet proposed a better name than name.
</em><br />

I disagree; I think *you* proposed a better name than 'name', when
<br />
you proposed 'token'. The latter is mildly confusing due to W3C's
<br />
misuse; the former is outright misleading. The attributes of this
<br />
type (type=, subtype=; to= & from= of <locus>; scope= of <handNote>,
<br />
etc.) don't really have names as their values in any sense of the
<br />
word.
<br />

<p><em class="quotelev2">> > * I think we should probably be more permissive than NMTOKEN.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> We can tweak the definition if you like, but I don't understand why
</em><br />
<em class="quotelev1">> you would want to.
</em><br />

Because I don't think we should be limiting users to letters, digits,
<br />
dot, hyphen, underscore, and colon for the values of these
<br />
attributes, e.g. cref=, extent=, reason=, where= of <move>, real=,
<br />
met=, rhyme=. Although for some it does make sense (name= of <equiv>,
<br />
included= of <witness>); perhaps these should be moved to
<br />
tei.data.ident?
<br />

<p><em class="quotelev1">> (a) difficulties in implementation
</em><br />

Why is it so much harder to implement? I haven't completely worked
<br />
through the algorithms for comparison of dateTimes and addition of
<br />
duration to dateTime, but neither seems to depend on precision to the
<br />
second. Did I miss something?
<br />

<p><em class="quotelev1">> (b) confusion caused by lack of timezone information
</em><br />

Good point. We should make timezone information possible on
<br />
right-truncated times, of course.
<br />

<p><em class="quotelev2">> > I really don't see why not permit percentages. Users had the
</em><br />
<em class="quotelev2">> > choice in P4, when we couldn't even validate it. Now we can.
</em><br />
<em class="quotelev2">> > 
</em><br />
<em class="quotelev1">> simplicity, clarity, precision...
</em><br />

While I suppose it is simpler for software writers to have 1 system
<br />
rather than 2, there is nothing more clear nor more precise about
<br />
"0.824" than "82.4%". While I have some sympathy with the idea of
<br />
reducing choices for users, this is one place where I think users
<br />
like the choice.
<br />

<p><em class="quotelev1">> I think this is a mistake, actually. Decimal was a better choice,
</em><br />
<em class="quotelev1">> since it can represent any number, real or integer, no matter how
</em><br />
<em class="quotelev1">> big. It means you can;t use scientific notation, which someone
</em><br />
<em class="quotelev1">> folks on TEI-L suddenly woke up and asked for. 
</em><br />

So you think we have more users who really want to represent numbers
<br />
with greater than 16 (decimal) digits of precision than users who
<br />
want to represent numbers in scientific notation? As I had hoped my
<br />
example would demonstrate, that much precision is not something we
<br />
humans generally deal with.
<br />

<em class="quotelev1">> I now think maybe we should have a different datatype for
</em><br />
<em class="quotelev1">> [scientific notation].
</em><br />

If we split scientific notation out to a different datatype, won't we
<br />
need a disjunction of the two datatypes in most if not all instances
<br />
anyway? And the disjunction (whether of two separate TEI datatypes or
<br />
of two xsd: datatypes inside a TEI datatype) might be a bit confusing
<br />
for implementers. But it shouldn't be impossible to deal with (could
<br />
always just assume that if it's not in scientific notation, it is an
<br />
xsd:decimal).
<br />

<p><em class="quotelev1">> Credit card numbers, by the way, are tei.data.ident, clearly.
</em><br />

I thought you wanted tei.data.ident to be xsd:Name -- credit card
<br />
numbers start with a digit, and thus are invalid xsd:Names. They'd be
<br />
fine as tei.data.[name|token], but once again the name "name" doesn't
<br />
make sense. (Alternative one could insist that they start with a "V"
<br />
or "M" or whatever :-)
<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 Sep 22 2005 - 06:35:31 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Thu Sep 22 07:08:21 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 22 Sep 2005 07:08:21 -0400
Subject: [tei-council] Datatype : roundup
In-Reply-To: <43328491.2030105@computing-services.oxford.ac.uk>
Message-ID: <17202.37029.381447.317880@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, 22 Sep 2005 07:08:21 -0400</span><br />
</address>

<em class="quotelev1">> Is there any sensible way to add timezone information to
</em><br />
<em class="quotelev1">> right-truncated times?
</em><br />

Yes, although it's no longer trivial. The regexp in the following
<br />
schema 
<br />
* does not permit the "military" timezone designators except for "Z",
<br />
  because that's what W3C does
<br />
* requires minutes in the non-"Z" time zone designators, because W3C
<br />
  does
<br />
* does permit minutes other than "00" and "30" in the minutes field
<br />
  of time zone designators, even though none exist, because that's what
<br />
  W3C does (I'm of half a mind to fix this oversight of theirs)
<br />
* does permit time zones greater than 14, because it's a royal pain
<br />
  to limit 'em, and W3C's own syntax doesn't (although semantically
<br />
  it's still an error, I think) -- I mostly copied the regexp from
<br />
  the W3C spec
<br />
* does not permit the hour to be "24", because that's a really
<br />
  really bad idea (one of 8601:2000's greatest failings, and the
<br />
  proof that it was written by committee)
<br />

--------- begin tim.rnc ---------
<br />
# test 'tim', a right-truncated 'time' :-)
<br />
start = element tests { test+ }
<br />
test = element test {
<br />
   attribute tim { xsd:token { pattern =
<br />
      "([01][0-9]|2[0-3])(:[0-5][0-9])?(((\+|-)[01][0-9]:[0-5][0-9])|Z)?"
<br />
   }
<br />
   }
<br />
}
<br />
--------- end tim.rnc ---------
<br />

--------- begin tim.xml ---------
<br />
<?xml version="1.0" encoding="UTF-8" ?>
<br />
<!-- should be valid -->
<br />
<tests>
<br />
  <test tim="10:32-04:00"/>
<br />
  <test tim="11+05:00"/>
<br />
  <test tim="12:34Z"/>
<br />
  <test tim="13Z"/>
<br />
</tests>
<br />
--------- end tim.xml ---------
<br />

--------- begin TIM.xml ---------
<br />
<?xml version="1.0" encoding="UTF-8" ?>
<br />
<!-- each attribute value should be invalid -->
<br />
<tests>
<br />
  <test tim="10:32-04"/>
<br />
  <test tim="11+98:00"/>
<br />
  <test tim="12:34J"/>
<br />
  <test tim="13K"/>
<br />
  <test tim="145"/>
<br />
  <test tim="15:16:17"/> <!-- valid against xsd:time -->
<br />
  <test tim="16:61+00:00"/>    <!-- no leap minutes! -->
<br />
  <test tim="17:98"/>
<br />
  <test tim="24:00"/>
<br />
  <test tim="32:00Z"/>
<br />
</tests>
<br />
--------- end TIM.xml ---------
<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 Sep 22 2005 - 07:08:40 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Thu Sep 22 09:35:06 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 22 Sep 2005 14:35:06 +0100
Subject: [tei-council] Datatype : roundup
In-Reply-To: <17202.35039.694032.99577@emt.wwp.brown.edu>
Message-ID: <4332B30A.4060700@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, 22 Sep 2005 14:35:06 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev3">>>>As for tei.data.name:
</em><br />
<em class="quotelev3">>>>* the name is really bad; I'd prefer to live with the confusion of
</em><br />
<em class="quotelev3">>>>  tei.data.token. (Remember, the string "xsd:token" will only appear
</em><br />
<em class="quotelev3">>>>  a few times in all of P5; in the declarations of at most half a
</em><br />
<em class="quotelev3">>>>  dozen datatypes.)
</em><br />
<em class="quotelev3">>>>      
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev2">>>That's irrelevant to the issue here: we want people to use the TEI
</em><br />
<em class="quotelev2">>>name and not be confused when they talk to others about it. No-one
</em><br />
<em class="quotelev2">>>has yet proposed a better name than name.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I disagree; I think *you* proposed a better name than 'name', when
</em><br />
<em class="quotelev1">>you proposed 'token'. The latter is mildly confusing due to W3C's
</em><br />
<em class="quotelev1">>misuse; the former is outright misleading. The attributes of this
</em><br />
<em class="quotelev1">>type (type=, subtype=; to= & from= of <locus>; scope= of <handNote>,
</em><br />
<em class="quotelev1">>etc.) don't really have names as their values in any sense of the
</em><br />
<em class="quotelev1">>word.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

Which attributes get which datatype is a moveable feast, of course. But 
<br />
I stand by the assertion that no-one has yet proposed a better name for 
<br />
this one. Token is not acceptable because of the confusion already noted.
<br />

<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev3">>>>* I think we should probably be more permissive than NMTOKEN.
</em><br />
<em class="quotelev3">>>>      
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev2">>>We can tweak the definition if you like, but I don't understand why
</em><br />
<em class="quotelev2">>>you would want to.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Because I don't think we should be limiting users to letters, digits,
</em><br />
<em class="quotelev1">>dot, hyphen, underscore, and colon for the values of these
</em><br />
<em class="quotelev1">>attributes, e.g. cref=, extent=, reason=, where= of <move>, real=,
</em><br />
<em class="quotelev1">>met=, rhyme=. Although for some it does make sense (name= of <equiv>,
</em><br />
<em class="quotelev1">>included= of <witness>); perhaps these should be moved to
</em><br />
<em class="quotelev1">>tei.data.ident?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

My proposal is to offer a range of choices: name, ident, enumerated. I 
<br />
have yet to see any argument for a fourth category, so that's progress. 
<br />
I still think that NMTOKEN is a good choice as representation for the 
<br />
first of these: yes, we are constraining people not to include weird 
<br />
punctuation characters in  their names. Why is that a bad idea? We are 
<br />
also getting some sensible validation for free!
<br />

<p><em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev3">>>>I really don't see why not permit percentages. Users had the
</em><br />
<em class="quotelev3">>>>choice in P4, when we couldn't even validate it. Now we can.
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev3">>>>      
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev2">>>simplicity, clarity, precision...
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>While I suppose it is simpler for software writers to have 1 system
</em><br />
<em class="quotelev1">>rather than 2, there is nothing more clear nor more precise about
</em><br />
<em class="quotelev1">>"0.824" than "82.4%". While I have some sympathy with the idea of
</em><br />
<em class="quotelev1">>reducing choices for users, this is one place where I think users
</em><br />
<em class="quotelev1">>like the choice.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

I see no evidence for this asserttion at all. Since both representations 
<br />
mean exactly the same thing, and are exactly inter-convertible, I think 
<br />
it just looks silly not to come down on one side of the fence or the 
<br />
other. 
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>I think this is a mistake, actually. Decimal was a better choice,
</em><br />
<em class="quotelev2">>>since it can represent any number, real or integer, no matter how
</em><br />
<em class="quotelev2">>>big. It means you can;t use scientific notation, which someone
</em><br />
<em class="quotelev2">>>folks on TEI-L suddenly woke up and asked for. 
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>So you think we have more users who really want to represent numbers
</em><br />
<em class="quotelev1">>with greater than 16 (decimal) digits of precision than users who
</em><br />
<em class="quotelev1">>want to represent numbers in scientific notation? As I had hoped my
</em><br />
<em class="quotelev1">>example would demonstrate, that much precision is not something we
</em><br />
<em class="quotelev1">>humans generally deal with.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

No, I think that if there are 10 people in the world who want to use a 
<br />
numeric datatype, 8 of them might  want to use what one might call 
<br />
unscientific notation, and 9.9 of them will want to represent values 
<br />
representable to an accuracy less than 8 decimal digits!
<br />

<p><p><em class="quotelev2">>>I now think maybe we should have a different datatype for
</em><br />
<em class="quotelev2">>>[scientific notation].
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>If we split scientific notation out to a different datatype, won't we
</em><br />
<em class="quotelev1">>need a disjunction of the two datatypes in most if not all instances
</em><br />
<em class="quotelev1">>anyway? And the disjunction (whether of two separate TEI datatypes or
</em><br />
<em class="quotelev1">>of two xsd: datatypes inside a TEI datatype) might be a bit confusing
</em><br />
<em class="quotelev1">>for implementers. But it shouldn't be impossible to deal with (could
</em><br />
<em class="quotelev1">>always just assume that if it's not in scientific notation, it is an
</em><br />
<em class="quotelev1">>xsd:decimal).
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

I dont think that sort of "assumption" is something an XML validator can 
<br />
do, is it?  But we could certainly say the numeric datatype maps onto 
<br />
xsd:decimal|xsd:float if that would make you happy. 
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>Credit card numbers, by the way, are tei.data.ident, clearly.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I thought you wanted tei.data.ident to be xsd:Name -- credit card
</em><br />
<em class="quotelev1">>numbers start with a digit, and thus are invalid xsd:Names. They'd be
</em><br />
<em class="quotelev1">>fine as tei.data.[name|token], but once again the name "name" doesn't
</em><br />
<em class="quotelev1">>make sense. (Alternative one could insist that they start with a "V"
</em><br />
<em class="quotelev1">>or "M" or whatever :-)
</em><br />
<em class="quotelev1">>
</em><br />

Ah yes, good point.
<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 Sep 22 2005 - 09:32:59 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep 22 06:27:00 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 11:27:00 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <a0620070abf55fdfc4623@[128.148.157.102]>
Message-ID: <433286F4.4050107@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, 22 Sep 2005 11:27:00 +0100</span><br />
</address>

On dates/times again, one should bear in mind that XML processors
<br />
may start using datatype information. At the moment, the
<br />
only thing where it matters is in validation; but in the world
<br />
of W3C Schema and XSLT2, the processing application can say
<br />
"what basic datatype did you work out for this attribute".  So if
<br />
our schema said "xsd:dateTime | long-regexp-allowing:13:15as-a-time",
<br />
then the processor might take different actions depending
<br />
on whether you did 13:15 or 13:15:00.
<br />

It is not easy to think through whether this matters or not.
<br />

As ever, I vote to keep the default to be compliant with XSD, and to
<br />
simply document how people who need full ISO 8601 can
<br />
extend their local schema.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Thu Sep 22 2005 - 16:30:49 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep 22 11:31:49 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 16:31:49 +0100
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <17199.36356.769861.682886@emt.wwp.brown.edu>
Message-ID: <4332CE65.4090403@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, 22 Sep 2005 16:31:49 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>Yes, but not at the expense of not being able to represent humanities
</em><br />
<em class="quotelev1">>data.
</em><br />
<em class="quotelev1">>
</em><br />
i know its just political correctness, but can we remember
<br />
_not_ to shepherd the TEI into a "humanities" ghetto?
<br />
The TEI is about _text_, which is of interest in many disciplines.
<br />

<em class="quotelev1">> Besides, keep in mind that (at least for RelaxNG) all a datatype
</em><br />
<em class="quotelev1">>does is, given a certain string, say "yes, this is" or "no, this is
</em><br />
<em class="quotelev1">>not" a valid instance of me. It doesn't return a normalized or
</em><br />
<em class="quotelev1">>regularized or canonical value or anything like that.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
but do bear in mind that this _isn't_ true for W3C Schema
<br />
and the PSVI.
<br />

you may one day wish to do a proper sort of TEI-encoded
<br />
elements according to their date. If they emerge into the PSVI
<br />
as having matched a regexp, you'll be at a disadvantage.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Thu Sep 22 2005 - 16:31:00 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep 22 14:57:33 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 19:57:33 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <431757FA.3010605@computing-services.oxford.ac.uk>
Message-ID: <4332FE9D.9030704@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, 22 Sep 2005 19:57:33 +0100</span><br />
</address>

<em class="quotelev2">>> state, I am beginning to lean towards leaving tei.data.key an
</em><br />
<em class="quotelev2">>> xsd:Name, and telling users who really want to specify the resource as
</em><br />
<em class="quotelev2">>> well as the key to use xml:base=. E.g. <name key="929041"
</em><br />
<em class="quotelev2">>> xml:base="http:/my.server.org/name-database">. Is that feasible? I
</em><br />
<em class="quotelev1">>
</em><br />
how is that different from key="http://www.foo.com#92041" ?
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> One final thought. As mentioned before, in the P5 world as currently
</em><br />
<em class="quotelev2">>> instantiated, a document can't say to which schema it is supposed to
</em><br />
<em class="quotelev2">>> conform. 
</em><br />
<em class="quotelev1">>
</em><br />
This is not some sort of P5 restriction. We don't dictate what
<br />
mechanisms people may use to do this, of which there are at least
<br />
4 (DOCTYPE, the XSD mechanism, the software-speficic Oxygen PI,
<br />
and the external mapping implemented in emacs).
<br />

that's an aside tho...
<br />

<em class="quotelev2">>> So suppose a project has 2 somewhat similar schemas that
</em><br />
<em class="quotelev2">>> serve different purposes lying around, each of which imposes a closed
</em><br />
<em class="quotelev2">>> value list on the bar= of <foo>, as follows:
</em><br />
<em class="quotelev2">>>   A        B
</em><br />
<em class="quotelev2">>>   ---      -------
</em><br />
<em class="quotelev2">>>   fee      fee
</em><br />
<em class="quotelev2">>>   fi       fi
</em><br />
<em class="quotelev2">>>   fo       fiddlie
</em><br />
<em class="quotelev2">>>   fum      aye
</em><br />
<em class="quotelev2">>>            oh
</em><br />
<em class="quotelev2">>> Now suppose you, the encoder, start working on an instance. Unless
</em><br />
<em class="quotelev2">>> said instance is already valid against A and invalid against B, you
</em><br />
<em class="quotelev2">>> have no way of knowing that "fum" is a legal value but "aye" is not.
</em><br />
<em class="quotelev2">>> Thus I think (or am I worried?) that a validatable method of
</em><br />
<em class="quotelev2">>> constraining values from within the instance will be even more popular
</em><br />
<em class="quotelev2">>> in P5 than in P4. I.e., it would be useful to have
</em><br />
<em class="quotelev2">>>  <definition-of-foo-values>
</em><br />
<em class="quotelev2">>>    <valList>
</em><br />
<em class="quotelev2">>>      <valItem ident="fee">
</em><br />
<em class="quotelev2">>>        <gloss>The file entropy evaluation as reported by blort</gloss>
</em><br />
<em class="quotelev2">>>      </valItem>
</em><br />
<em class="quotelev2">>>      <valItem ident="fi">
</em><br />
<em class="quotelev2">>>        <gloss>The file input, should contain only ASCII
</em><br />
<em class="quotelev2">>> characters</gloss>
</em><br />
<em class="quotelev2">>>      </valItem>
</em><br />
<em class="quotelev2">>>      </valItem ident="fo">
</em><br />
<em class="quotelev2">>>   ...
</em><br />
<em class="quotelev2">>> or some such somewhere in the TEI Header.
</em><br />
<em class="quotelev1">>
</em><br />
you want to put an ODD schema fragment in the TEI header????
<br />
well, its an interesting idea. it is pre-supposed in one of the
<br />
datatypes that values will be defined in the header, so conceivably
<br />
a general-purpose container could be useful.
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Thu Sep 22 2005 - 16:31:04 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep 22 11:50:01 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 16:50:01 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <ygfll1r0yvh.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <4332D2A9.1060600@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, 22 Sep 2005 16:50:01 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>I second that.  The requirement to give the @CREATEDATE up to the
</em><br />
<em class="quotelev1">>seconds in METS regularily drives me crazy (I wonder who manages to
</em><br />
<em class="quotelev1">>create such a record in just one second anyway)
</em><br />
<em class="quotelev1">>
</em><br />
computers. who else writes a "createdate" attribute
<br />
but a bit of software?
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Thu Sep 22 2005 - 16:31:07 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep 22 15:08:27 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 20:08:27 +0100
Subject: on spec grp 2, datatypes normalized (was "Re: [tei-council] datatypes")
In-Reply-To: <17197.33964.284995.434431@emt.wwp.brown.edu>
Message-ID: <4333012B.3090003@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, 22 Sep 2005 20:08:27 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>  So I still prefer
</em><br />
<em class="quotelev1">>     xsd:duration | xsd:token { pattern =
</em><br />
<em class="quotelev1">>     "[0-9]+(\.[0-9]+)? (year|month|week|d|h|min|s|ms|μs" }
</em><br />
<em class="quotelev1">>  (Note that is *not* the same as the one in EDW90; this one is,
</em><br />
<em class="quotelev1">>  IMHO, much better, and conforms to NIST recommendations (which use
</em><br />
<em class="quotelev1">>  SI wherever possible); however, it does not permit expression of a
</em><br />
<em class="quotelev1">>  negative duration.) But again, unlike xsd:duration where the
</em><br />
<em class="quotelev1">>  semantics are actually different, in this case it is only syntax,
</em><br />
<em class="quotelev1">>  so I don't care very much. I just think TEI users are going to be
</em><br />
<em class="quotelev1">>  much happier encoding <person age="3 month"> than <person
</em><br />
<em class="quotelev1">>  age="P3M"> and <event dur="13 ms"> than <event dur="PT0.013S">.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
Although you can guess which side of the fence I am on
<br />
personally, the reference to "TEI users" does remind us
<br />
that "P" in "P5" stands for "proposal".  This stuff
<br />
will be reviewed by the user community, won't it?
<br />

wearing my newly acquired i18n hat, i note that
<br />
"year", "month" and "week" are another example
<br />
of language specificity. Feel feel to reply that "M"
<br />
is the worst of both worlds :-}
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Thu Sep 22 2005 - 16:31:10 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep 22 15:15:56 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 20:15:56 +0100
Subject: on spec grp 4, coded values (was "Re: [tei-council] datatypes")
In-Reply-To: <17198.12522.68260.573944@emt.wwp.brown.edu>
Message-ID: <433302EC.1030300@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, 22 Sep 2005 20:15:56 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>  I think there are several good reasons to restrict these kinds of
</em><br />
<em class="quotelev1">>  references to local pointers.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  - It mimics what P4 had.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
that's not one of our design goals, though
<br />

<em class="quotelev1">>  - It provides a system (as did ID/IDREF) where the attribute value
</em><br />
<em class="quotelev1">>    itself may be used as a code for a useful semantic distinction
</em><br />
<em class="quotelev1">>    (thus the name). E.g., new= and old= of <handShift> -- the real
</em><br />
<em class="quotelev1">>    details are provided by the <hand> to which they point, but
</em><br />
<em class="quotelev1">>    mnemonic values like "#Scribe1brown" and "#Scribe2red" can convey
</em><br />
<em class="quotelev1">>    a lot of meaning by themselves, or at least be easy for humans to
</em><br />
<em class="quotelev1">>    associate with the appropriate <hand>.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I dont get this. why are local pointers more readable
<br />
than remote ones?
<br />

<em class="quotelev1">>  - By changing the values of the xml:id= attributes of the elements
</em><br />
<em class="quotelev1">>    pointed at (e.g., <hand>), the encoder gets to create the
</em><br />
<em class="quotelev1">>    vocabulary used.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
well, if they want to work that way, they can, no?
<br />

<em class="quotelev1">>    If we stick to local pointers, we can define the place or places
</em><br />
<em class="quotelev1">>    (likely in the TEI header) to where each tei.data.code attribute
</em><br />
<em class="quotelev1">>    is supposed to point, document it accordingly, and perhaps write
</em><br />
<em class="quotelev1">>    a Schematron rule to verify that it does so.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
there is some strength in this, I agree.  but as Christian says,
<br />
its not always so obvious what "local" means
<br />

<em class="quotelev1">>    If we permit any pointer, documentation where these things point
</em><br />
<em class="quotelev1">>    becomes somewhat harder. E.g., if the new= of <handShift> points
</em><br />
<em class="quotelev1">>    to an external file, does it still need to point at a <tei:hand>?
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
fair point. usage will dictate the pattern
<br />

<em class="quotelev1">>    rewrite the prose so that it is clear that the <hand> in one TEI
</em><br />
<em class="quotelev1">>    document may well be documenting the handwriting in another.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
sadly true :-}
<br />

<em class="quotelev1">>* tei.data.key: the change is from 'xsd:token' to 'rng:string'. I
</em><br />
<em class="quotelev1">>  think it should be left as 'xsd:token' just for consistency. There
</em><br />
<em class="quotelev1">>  is no difference in validation at all (since there are no
</em><br />
<em class="quotelev1">>  enumerated values).
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
you cannot predict what a database key looks like.
<br />
It is not acceptable to say you can only interact with
<br />
external systems which key things use a "xsd:token" datatype
<br />

<p><p><p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Thu Sep 22 2005 - 16:31:13 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep 22 15:17:45 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 20:17:45 +0100
Subject: [tei-council] datatype issues (part 1) continued,,,
In-Reply-To: <17200.7023.583257.963017@emt.wwp.brown.edu>
Message-ID: <43330359.7050300@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, 22 Sep 2005 20:17:45 +0100</span><br />
</address>

Syd said
<br />

<em class="quotelev1">>Where in your scheme to <valList>s of type= "open" and "semi" fit?
</em><br />
<em class="quotelev1">>I.e., are they still assigned the datatype tei.data.enumerated?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
just as an aside "open" and "semi" lists can
<br />
have no impact on the schema at all. they
<br />
are just documentation. personally,
<br />
I find it a bit odd that they are the same name
<br />
as "closed", which _does_ affect the schema....
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Thu Sep 22 2005 - 16:31:17 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep 22 11:47:48 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 16:47:48 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <200508312049.j7VKnBia028939@cepheus.services.brown.edu>
Message-ID: <4332D224.1040409@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, 22 Sep 2005 16:47:48 +0100</span><br />
</address>

Syd Bauman wrote some time back (sorry, catching up on email on the train):
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Sebastian, could we arrange the process so that just
</em><br />
<em class="quotelev1">>specifying, e.g.
</em><br />
<em class="quotelev1">>          <elementSpec module="core" ident="note" mode="change">
</em><br />
<em class="quotelev1">>            <attList>
</em><br />
<em class="quotelev1">>              <attDef ident="place">
</em><br />
<em class="quotelev1">>                <valList type="closed"/>
</em><br />
<em class="quotelev1">>              </attDef>
</em><br />
<em class="quotelev1">>            </attList>
</em><br />
<em class="quotelev1">>          </elementSpec>
</em><br />
<em class="quotelev1">>would work? 
</em><br />
<em class="quotelev1">>
</em><br />
you mean <attDef ident="place" mode="change">
<br />
    <valList type="closed" mode="change"/>
<br />

quite incrediblly, this works!
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> In
</em><br />
<em class="quotelev1">>particular, since the restriction is a facet, we can't use this
</em><br />
<em class="quotelev1">>feature to have one TEI datatype for numeric representations
</em><br />
<em class="quotelev1">>(tei.data.numeric), and say "this attribute is one of
</em><br />
<em class="quotelev1">>tei.data.numeric, but must be a non-negative integer".
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
sadly, I suspect this _would_ be possibly in W3C Schema.
<br />
MScQ will say "told you so".
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Thu Sep 22 2005 - 16:31:01 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Thu Sep 22 23:09:31 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 22 Sep 2005 23:09:31 -0400
Subject: [tei-council] comments on edw90
In-Reply-To: <4332FE9D.9030704@oucs.ox.ac.uk>
Message-ID: <17203.29163.377001.717208@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, 22 Sep 2005 23:09:31 -0400</span><br />
</address>

<em class="quotelev1">> you want to put an ODD schema fragment in the TEI header???? well,
</em><br />
<em class="quotelev1">> its an interesting idea. it is pre-supposed in one of the datatypes
</em><br />
<em class="quotelev1">> that values will be defined in the header, so conceivably a
</em><br />
<em class="quotelev1">> general-purpose container could be useful.
</em><br />

Not necessarily a <valList>.
<br />

I just suggested the following to Lou for age= of <person> (which
<br />
represents a demographic age range, not a time duration someone has
<br />
been alive):
<br />

<person age="#middle-aged">
<br />
<!-- elsewhere, very likely in <teiHeader> of same doc ... -->
<br />
<codeGrp gis="person personGrp" attr="age">
<br />
  <codeDef xml:id="infant">birth to 1 year</codeDef>
<br />
  <codeDef xml:id="child">1 to 8 years</codeDef>
<br />
  <codeDef xml:id="teen">9 to 19 years</codeDef>
<br />
  <codeDef xml:id="young-adult">20 to 30 years</codeDef>
<br />
  <codeDef xml:id="yuppie">30-39 years</codeDef>
<br />
  <codeDef xml:id="middle-aged">Generally 40-65, but post-menopausal
<br />
                                women are in a separate
<br />
                                category</codeDef>
<br />
  <!-- ... -->
<br />
</codeGrp>
<br />

This generic mechanism would allow the Schematron rule to be the same
<br />
for all tei.data.code elements: "I must point to something whose
<br />
parent <codeGrp> has my element name in its gis= list and my attr
<br />
name in its attr= list." The 'something' allows us to put
<br />
special-purpose elements (like <hand>) in there when needed.
<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 Sep 22 2005 - 23:09:43 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Fri Sep 23 04:23:37 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 23 Sep 2005 09:23:37 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <17203.29163.377001.717208@emt.wwp.brown.edu>
Message-ID: <4333BB89.4040804@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, 23 Sep 2005 09:23:37 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">><person age="#middle-aged">
</em><br />
<em class="quotelev1">><!-- elsewhere, very likely in <teiHeader> of same doc ... -->
</em><br />
<em class="quotelev1">><codeGrp gis="person personGrp" attr="age">
</em><br />
<em class="quotelev1">>  <codeDef xml:id="infant">birth to 1 year</codeDef>
</em><br />
<em class="quotelev1">>  <codeDef xml:id="child">1 to 8 years</codeDef>
</em><br />
<em class="quotelev1">>  <codeDef xml:id="teen">9 to 19 years</codeDef>
</em><br />
<em class="quotelev1">>  <codeDef xml:id="young-adult">20 to 30 years</codeDef>
</em><br />
<em class="quotelev1">>  <codeDef xml:id="yuppie">30-39 years</codeDef>
</em><br />
<em class="quotelev1">>  <codeDef xml:id="middle-aged">Generally 40-65, but post-menopausal
</em><br />
<em class="quotelev1">>                                women are in a separate
</em><br />
<em class="quotelev1">>                                category</codeDef>
</em><br />
<em class="quotelev1">>  <!-- ... -->
</em><br />
<em class="quotelev1">></codeGrp>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
haven't you just reinvented <classDecl>? in one of my files I
<br />
see
<br />

<taxonomy xml:id="Zone">
<br />
<category xml:id="z_A"><catDesc>Parte Antica</catDesc></category>
<br />
<category xml:id="z_V"><catDesc>Zona Vecchia</catDesc></category>
<br />
<category xml:id="z_P"><catDesc>Zona Prima</catDesc></category>
<br />
<category xml:id="z_S"><catDesc>Zona Seconda</catDesc></category>
<br />
<category xml:id="z_T"><catDesc>Zona Terza</catDesc></category>
<br />
    </taxonomy>
<br />

which surely has the same effect? tying the code table to the
<br />
element name and attribute seems a mildly clumsy way of doing it.
<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> Fri Sep 23 2005 - 04:23:40 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Fri Sep 23 04:46:31 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 23 Sep 2005 10:46:31 +0200
Subject: [tei-council] comments on edw90
In-Reply-To: <4333BB89.4040804@oucs.ox.ac.uk>
Message-ID: <4333C0E7.3040508@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, 23 Sep 2005 10:46:31 +0200</span><br />
</address>

Yes, there are several re-inventions of this kind throughout the header, 
<br />
which would benefit from integration.
<br />

Sebastian Rahtz wrote:
<br />
<em class="quotelev1">> Syd Bauman wrote:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>> <person age="#middle-aged">
</em><br />
<em class="quotelev2">>> <!-- elsewhere, very likely in <teiHeader> of same doc ... -->
</em><br />
<em class="quotelev2">>> <codeGrp gis="person personGrp" attr="age">
</em><br />
<em class="quotelev2">>>  <codeDef xml:id="infant">birth to 1 year</codeDef>
</em><br />
<em class="quotelev2">>>  <codeDef xml:id="child">1 to 8 years</codeDef>
</em><br />
<em class="quotelev2">>>  <codeDef xml:id="teen">9 to 19 years</codeDef>
</em><br />
<em class="quotelev2">>>  <codeDef xml:id="young-adult">20 to 30 years</codeDef>
</em><br />
<em class="quotelev2">>>  <codeDef xml:id="yuppie">30-39 years</codeDef>
</em><br />
<em class="quotelev2">>>  <codeDef xml:id="middle-aged">Generally 40-65, but post-menopausal
</em><br />
<em class="quotelev2">>>                                women are in a separate
</em><br />
<em class="quotelev2">>>                                category</codeDef>
</em><br />
<em class="quotelev2">>>  <!-- ... -->
</em><br />
<em class="quotelev2">>> </codeGrp>
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> haven't you just reinvented <classDecl>? in one of my files I
</em><br />
<em class="quotelev1">> see
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> <taxonomy xml:id="Zone">
</em><br />
<em class="quotelev1">> <category xml:id="z_A"><catDesc>Parte Antica</catDesc></category>
</em><br />
<em class="quotelev1">> <category xml:id="z_V"><catDesc>Zona Vecchia</catDesc></category>
</em><br />
<em class="quotelev1">> <category xml:id="z_P"><catDesc>Zona Prima</catDesc></category>
</em><br />
<em class="quotelev1">> <category xml:id="z_S"><catDesc>Zona Seconda</catDesc></category>
</em><br />
<em class="quotelev1">> <category xml:id="z_T"><catDesc>Zona Terza</catDesc></category>
</em><br />
<em class="quotelev1">>    </taxonomy>
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> which surely has the same effect? tying the code table to the
</em><br />
<em class="quotelev1">> element name and attribute seems a mildly clumsy way of doing it.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> sebastian
</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="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 Sep 23 2005 - 04:39:42 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Fri Sep 23 09:22:11 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 23 Sep 2005 15:22:11 +0200
Subject: [tei-council] progress on datatypes
Message-ID: <43340183.9010604@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, 23 Sep 2005 15:22:11 +0200</span><br />
</address>

I append two reports from the script I wrote to perform datatype 
<br />
conversion of existing TEI element specs using as input the table which 
<br />
Syd maintains as an adjunct to edw90. Syd did a mass updating of this 
<br />
last night, at my request so that we could make some progress on this front.
<br />

My script assumes that only tei.data.xxx style datatypes will be used, 
<br />
since these are the ones that we have been discussing. It therefore 
<br />
flags as "not a TEI datatype" anything else when processing the table 
<br />
and produces the message "fix element_at_attribute by hand" -- in many 
<br />
cases no fix is needed, of course.
<br />

The script then romps along copying all existing ODD sources into a new 
<br />
directory, reporting each case where it doesn't know what the new 
<br />
datatype should be (this is the second set of error messages); when this 
<br />
happens, it simply copies across the existing datatype.
<br />

The only exception to this procedure is that I hand edited the data 
<br />
extracted from Syd's table to replace "tei.data.word" with 
<br />
"tei.data.name". We don't have a tagdoc for tei.data.word  so leaving 
<br />
this unchanged (even assuming I thought this late suggestion was a 
<br />
better name, which I don't) would have meant the ODDs generated were 
<br />
invalid.
<br />

---------------------
<br />

@| is syntactically invalid: ignored
<br />
@| is syntactically invalid: ignored
<br />
  is not even close to a tei datatype: fix w_at_lemma by hand
<br />
list { tei.data.language+ } is not even close to a tei datatype: fix 
<br />
textLang_at_otherLangs by hand
<br />
list { tei.data.probability+ } is not even close to a tei datatype: fix 
<br />
alt_at_weights by hand
<br />
list { xsd:NCName* } is not even close to a tei datatype: fix 
<br />
specDesc_at_atts by hand
<br />
NaAA is not even close to a tei datatype: fix gap_at_desc by hand
<br />
NaAA is not even close to a tei datatype: fix join_at_desc by hand
<br />
NaAA is not even close to a tei datatype: fix joinGrp_at_desc by hand
<br />
NaAA is not even close to a tei datatype: fix arc_at_label2 by hand
<br />
NaAA is not even close to a tei datatype: fix node_at_label2 by hand
<br />
NaAA is not even close to a tei datatype: fix arc_at_label by hand
<br />
NaAA is not even close to a tei datatype: fix eLeaf_at_label by hand
<br />
NaAA is not even close to a tei datatype: fix eTree_at_label by hand
<br />
NaAA is not even close to a tei datatype: fix graph_at_label by hand
<br />
NaAA is not even close to a tei datatype: fix iNode_at_label by hand
<br />
NaAA is not even close to a tei datatype: fix leaf_at_label by hand
<br />
NaAA is not even close to a tei datatype: fix node_at_label by hand
<br />
NaAA is not even close to a tei datatype: fix root_at_label by hand
<br />
NaAA is not even close to a tei datatype: fix tree_at_label by hand
<br />
NaAA is not even close to a tei datatype: fix triangle_at_label by hand
<br />
NaAA is not even close to a tei datatype: fix orgDivn_at_reg by hand
<br />
NaAA is not even close to a tei datatype: fix orgName_at_reg by hand
<br />
NaAA is not even close to a tei datatype: fix orgTitle_at_reg by hand
<br />
NaAA is not even close to a tei datatype: fix orgType_at_reg by hand
<br />
pending <index> revision is not even close to a tei datatype: fix 
<br />
index_at_index by hand
<br />
pending DI revision is not even close to a tei datatype: fix m_at_baseForm 
<br />
by hand
<br />
tei.data.idents is not a tei datatype: fix schemaSpec_at_start by hand
<br />
tei.data.truthValue | "partial" is not even close to a tei datatype: fix 
<br />
tree_at_ord by hand
<br />
xsd:anyURI is not even close to a tei datatype: fix schemaSpec_at_namespace 
<br />
by hand
<br />
xsd:anyURI is not even close to a tei datatype: fix elementSpec_at_ns by hand
<br />
xsd:boolean is not even close to a tei datatype: fix metSym_at_terminal by hand
<br />
xsd:boolean is not even close to a tei datatype: fix numeric_at_trunc by hand
<br />
xsd:boolean is not even close to a tei datatype: fix binary_at_value by hand
<br />
xsd:float { minInclusive = "0" } | xsd:token is not even close to a tei 
<br />
datatype: fix timeline_at_interval by hand
<br />
"unknown" is syntactically invalid: ignored
<br />
xsd:float { minInclusive = "0" } | xsd:token is not even close to a tei 
<br />
datatype: fix when_at_interval by hand
<br />
"unknown" is syntactically invalid: ignored
<br />
xsd:nonNegativeInteger | "many" is not even close to a tei datatype: fix 
<br />
handDesc_at_hands by hand
<br />
xsd:token { pattern="[0-9]+(\.[0-9]+){0,2}[abdp]?" is not even close to 
<br />
a tei datatype: fix TEI_at_version by hand
<br />
} is syntactically invalid: ignored
<br />
xsd:unsignedShort is not even close to a tei datatype: fix sense_at_level 
<br />
by hand
<br />
[should be dropped completely] is not even close to a tei datatype: fix 
<br />
alt_at_wScale by hand
<br />
[should be dropped completely] is not even close to a tei datatype: fix 
<br />
altGrp_at_wScale by hand
<br />
@| is syntactically invalid: ignored
<br />
  is not even close to a tei datatype: fix %tei.dictionaries_at_expand by hand
<br />
  is not even close to a tei datatype: fix %tei.dictionaries_at_split by hand
<br />
  is not even close to a tei datatype: fix %tei.dictionaries_at_value by hand
<br />
list { tei.data.ident, tei.data.idents } is not even close to a tei 
<br />
datatype: fix %tei.pointerGroup_at_targFunc by hand
<br />
list { tei.data.pointer, tei.data.pointers } is not even close to a tei 
<br />
datatype: fix %tei.pointerGroup_at_domains by hand
<br />
NaAA is not even close to a tei datatype: fix %tei.dictionaries_at_orig by hand
<br />
NaAA is not even close to a tei datatype: fix %tei.names_at_reg by hand
<br />
NaAA is not even close to a tei datatype: fix %tei.personPart_at_reg by hand
<br />
NaAA is not even close to a tei datatype: fix %tei.temporalExpr_at_reg by hand
<br />
xsd:boolean is not even close to a tei datatype: fix 
<br />
%tei.declarable_at_default by hand
<br />
xsd:boolean is not even close to a tei datatype: fix 
<br />
%tei.identifiable_at_predeclare by hand
<br />
-------------
<br />
No datatype proposed for accMat_at_type: leaving well alone
<br />
No datatype proposed for add_at_resp: leaving well alone
<br />
No datatype proposed for add_at_cert: leaving well alone
<br />
No datatype proposed for addSpan_at_type: leaving well alone
<br />
No datatype proposed for alt_at_weights: leaving well alone
<br />
No datatype proposed for alt_at_wScale: leaving well alone
<br />
No datatype proposed for altGrp_at_wScale: leaving well alone
<br />
No datatype proposed for altName_at_type: leaving well alone
<br />
No datatype proposed for arc_at_label: leaving well alone
<br />
No datatype proposed for arc_at_label2: leaving well alone
<br />
No datatype proposed for tei.ascribed_at_who: leaving well alone
<br />
No datatype proposed for attDef_at_ns: leaving well alone
<br />
No datatype proposed for attList_at_type: leaving well alone
<br />
No datatype proposed for binary_at_value: leaving well alone
<br />
No datatype proposed for binaryObject_at_width: leaving well alone
<br />
No datatype proposed for binaryObject_at_height: leaving well alone
<br />
No datatype proposed for binaryObject_at_scale: leaving well alone
<br />
No datatype proposed for binaryObject_at_mimeType: leaving well alone
<br />
No datatype proposed for binaryObject_at_encoding: leaving well alone
<br />
No datatype proposed for camera_at_type: leaving well alone
<br />
No datatype proposed for tei.analysis_at_ana: leaving well alone
<br />
No datatype proposed for tei.interpret_at_resp: leaving well alone
<br />
No datatype proposed for tei.interpret_at_type: leaving well alone
<br />
No datatype proposed for tei.interpret_at_inst: leaving well alone
<br />
No datatype proposed for tei.linking_at_corresp: leaving well alone
<br />
No datatype proposed for tei.linking_at_synch: leaving well alone
<br />
No datatype proposed for tei.linking_at_sameAs: leaving well alone
<br />
No datatype proposed for tei.linking_at_copyOf: leaving well alone
<br />
No datatype proposed for tei.linking_at_next: leaving well alone
<br />
No datatype proposed for tei.linking_at_prev: leaving well alone
<br />
No datatype proposed for tei.linking_at_exclude: leaving well alone
<br />
No datatype proposed for tei.linking_at_select: leaving well alone
<br />
No datatype proposed for tei.seg_at_type: leaving well alone
<br />
No datatype proposed for tei.seg_at_function: leaving well alone
<br />
No datatype proposed for tei.seg_at_part: leaving well alone
<br />
No datatype proposed for ab_at_rend: leaving well alone
<br />
No datatype proposed for coll_at_fVal: leaving well alone
<br />
No datatype proposed for corr_at_resp: leaving well alone
<br />
No datatype proposed for corr_at_cert: leaving well alone
<br />
No datatype proposed for custEvent_at_type: leaving well alone
<br />
No datatype proposed for damage_at_resp: leaving well alone
<br />
No datatype proposed for tei.datable_at_notBefore: leaving well alone
<br />
No datatype proposed for tei.datable_at_notAfter: leaving well alone
<br />
No datatype proposed for tei.datable_at_certainty: leaving well alone
<br />
No datatype proposed for tei.datable_at_dateAttrib: leaving well alone
<br />
No datatype proposed for tei.datable_at_evidence: leaving well alone
<br />
No datatype proposed for tei.declarable_at_default: leaving well alone
<br />
No datatype proposed for tei.declaring_at_decls: leaving well alone
<br />
No datatype proposed for decoNote_at_type: leaving well alone
<br />
No datatype proposed for decoNote_at_subtype: leaving well alone
<br />
No datatype proposed for del_at_resp: leaving well alone
<br />
No datatype proposed for del_at_cert: leaving well alone
<br />
No datatype proposed for tei.dictionaries_at_expand: leaving well alone
<br />
No datatype proposed for tei.dictionaries_at_norm: leaving well alone
<br />
No datatype proposed for tei.dictionaries_at_split: leaving well alone
<br />
No datatype proposed for tei.dictionaries_at_value: leaving well alone
<br />
No datatype proposed for tei.dictionaries_at_orig: leaving well alone
<br />
No datatype proposed for tei.dictionaries_at_location: leaving well alone
<br />
No datatype proposed for tei.dictionaries_at_mergedin: leaving well alone
<br />
No datatype proposed for tei.dictionaries_at_opt: leaving well alone
<br />
No datatype proposed for tei.divn_at_type: leaving well alone
<br />
No datatype proposed for tei.divn_at_org: leaving well alone
<br />
No datatype proposed for tei.divn_at_sample: leaving well alone
<br />
No datatype proposed for tei.divn_at_part: leaving well alone
<br />
No datatype proposed for tei.divn_at_part: leaving well alone
<br />
No datatype proposed for eLeaf_at_label: leaving well alone
<br />
No datatype proposed for elementSpec_at_ns: leaving well alone
<br />
No datatype proposed for elementSpec_at_type: leaving well alone
<br />
No datatype proposed for tei.enjamb_at_enjamb: leaving well alone
<br />
No datatype proposed for tei.entries_at_type: leaving well alone
<br />
No datatype proposed for tei.entries_at_key: leaving well alone
<br />
No datatype proposed for equiv_at_filter: leaving well alone
<br />
No datatype proposed for equiv_at_mimetype: leaving well alone
<br />
No datatype proposed for equiv_at_rend: leaving well alone
<br />
No datatype proposed for eTree_at_label: leaving well alone
<br />
No datatype proposed for event_at_who: leaving well alone
<br />
No datatype proposed for expan_at_resp: leaving well alone
<br />
No datatype proposed for expan_at_cert: leaving well alone
<br />
No datatype proposed for explicit_at_type: leaving well alone
<br />
No datatype proposed for finalRubric_at_type: leaving well alone
<br />
No datatype proposed for fLib_at_type: leaving well alone
<br />
No datatype proposed for tei.formPointers_at_target: leaving well alone
<br />
No datatype proposed for tei.fragmentary_at_wit: leaving well alone
<br />
No datatype proposed for fsdDecl_at_fsd: leaving well alone
<br />
No datatype proposed for fvLib_at_type: leaving well alone
<br />
No datatype proposed for gap_at_desc: leaving well alone
<br />
No datatype proposed for gap_at_resp: leaving well alone
<br />
No datatype proposed for tei.global_at_xml:id: leaving well alone
<br />
No datatype proposed for tei.global_at_n: leaving well alone
<br />
No datatype proposed for tei.global_at_xml:lang: leaving well alone
<br />
No datatype proposed for tei.global_at_rend: leaving well alone
<br />
No datatype proposed for tei.global_at_xml:base: leaving well alone
<br />
No datatype proposed for glyph_at_ucs: leaving well alone
<br />
No datatype proposed for graph_at_label: leaving well alone
<br />
No datatype proposed for graphic_at_mimeType: leaving well alone
<br />
No datatype proposed for hand_at_hand: leaving well alone
<br />
No datatype proposed for handDesc_at_hands: leaving well alone
<br />
No datatype proposed for tei.identifiable_at_ident: leaving well alone
<br />
No datatype proposed for tei.identifiable_at_depend: leaving well alone
<br />
No datatype proposed for tei.identifiable_at_predeclare: leaving well alone
<br />
No datatype proposed for tei.identifiable_at_module: leaving well alone
<br />
No datatype proposed for tei.identifiable_at_mode: leaving well alone
<br />
No datatype proposed for incipit_at_type: leaving well alone
<br />
No datatype proposed for index_at_indexName: leaving well alone
<br />
No datatype proposed for indexTerm_at_sortKey: leaving well alone
<br />
No datatype proposed for iNode_at_label: leaving well alone
<br />
No datatype proposed for tei.intervention_at_cert: leaving well alone
<br />
No datatype proposed for tei.intervention_at_resp: leaving well alone
<br />
No datatype proposed for interp_at_value: leaving well alone
<br />
No datatype proposed for join_at_desc: leaving well alone
<br />
No datatype proposed for joinGrp_at_desc: leaving well alone
<br />
No datatype proposed for kinesic_at_who: leaving well alone
<br />
No datatype proposed for leaf_at_label: leaving well alone
<br />
No datatype proposed for m_at_baseForm: leaving well alone
<br />
No datatype proposed for tei.measured_at_unit: leaving well alone
<br />
No datatype proposed for tei.measured_at_scope: leaving well alone
<br />
No datatype proposed for tei.metrical_at_met: leaving well alone
<br />
No datatype proposed for tei.metrical_at_real: leaving well alone
<br />
No datatype proposed for tei.metrical_at_rhyme: leaving well alone
<br />
No datatype proposed for metSym_at_terminal: leaving well alone
<br />
No datatype proposed for move_at_who: leaving well alone
<br />
No datatype proposed for tei.names_at_key: leaving well alone
<br />
No datatype proposed for tei.names_at_reg: leaving well alone
<br />
No datatype proposed for node_at_label: leaving well alone
<br />
No datatype proposed for node_at_label2: leaving well alone
<br />
No datatype proposed for numeric_at_trunc: leaving well alone
<br />
No datatype proposed for orgDivn_at_reg: leaving well alone
<br />
No datatype proposed for orgName_at_reg: leaving well alone
<br />
No datatype proposed for orgTitle_at_reg: leaving well alone
<br />
No datatype proposed for orgType_at_reg: leaving well alone
<br />
No datatype proposed for origPlace_at_placeAttrib: leaving well alone
<br />
No datatype proposed for origPlace_at_evidence: leaving well alone
<br />
No datatype proposed for pause_at_who: leaving well alone
<br />
No datatype proposed for tei.personPart_at_key: leaving well alone
<br />
No datatype proposed for tei.personPart_at_reg: leaving well alone
<br />
No datatype proposed for tei.personPart_at_type: leaving well alone
<br />
No datatype proposed for tei.personPart_at_full: leaving well alone
<br />
No datatype proposed for tei.personPart_at_sort: leaving well alone
<br />
No datatype proposed for tei.pointer_at_type: leaving well alone
<br />
No datatype proposed for tei.pointer_at_evaluate: leaving well alone
<br />
No datatype proposed for tei.pointerGroup_at_domains: leaving well alone
<br />
No datatype proposed for tei.pointerGroup_at_targFunc: leaving well alone
<br />
No datatype proposed for q_at_who: leaving well alone
<br />
No datatype proposed for tei.readings_at_wit: leaving well alone
<br />
No datatype proposed for tei.readings_at_type: leaving well alone
<br />
No datatype proposed for tei.readings_at_cause: leaving well alone
<br />
No datatype proposed for tei.readings_at_varSeq: leaving well alone
<br />
No datatype proposed for tei.readings_at_resp: leaving well alone
<br />
No datatype proposed for tei.readings_at_hand: leaving well alone
<br />
No datatype proposed for restore_at_cert: leaving well alone
<br />
No datatype proposed for root_at_label: leaving well alone
<br />
No datatype proposed for rubric_at_type: leaving well alone
<br />
No datatype proposed for schemaSpec_at_start: leaving well alone
<br />
No datatype proposed for schemaSpec_at_ns: leaving well alone
<br />
No datatype proposed for sense_at_level: leaving well alone
<br />
No datatype proposed for setting_at_who: leaving well alone
<br />
No datatype proposed for shift_at_who: leaving well alone
<br />
No datatype proposed for sp_at_who: leaving well alone
<br />
No datatype proposed for span_at_value: leaving well alone
<br />
No datatype proposed for tei.spanning_at_spanTo: leaving well alone
<br />
No datatype proposed for specDesc_at_atts: leaving well alone
<br />
No datatype proposed for step_at_refunit: leaving well alone
<br />
No datatype proposed for step_at_length: leaving well alone
<br />
No datatype proposed for step_at_delim: leaving well alone
<br />
No datatype proposed for step_at_from: leaving well alone
<br />
No datatype proposed for step_at_to: leaving well alone
<br />
No datatype proposed for beetroot_at_type: leaving well alone
<br />
No datatype proposed for beetroot_at_bax: leaving well alone
<br />
No datatype proposed for beetroot_at_bar: leaving well alone
<br />
No datatype proposed for beetroot_at_baz: leaving well alone
<br />
No datatype proposed for TEI_at_xmlns: leaving well alone
<br />
No datatype proposed for TEI_at_version: leaving well alone
<br />
No datatype proposed for teiCorpus_at_xmlns: leaving well alone
<br />
No datatype proposed for tei.TEIform_at_TEIform: leaving well alone
<br />
No datatype proposed for teiHeader_at_creator: leaving well alone
<br />
No datatype proposed for teiHeader_at_status: leaving well alone
<br />
No datatype proposed for teiHeader_at_dateCreated: leaving well alone
<br />
No datatype proposed for teiHeader_at_dateUpdated: leaving well alone
<br />
No datatype proposed for tei.temporalExpr_at_value: leaving well alone
<br />
No datatype proposed for tei.temporalExpr_at_key: leaving well alone
<br />
No datatype proposed for tei.temporalExpr_at_reg: leaving well alone
<br />
No datatype proposed for tei.temporalExpr_at_type: leaving well alone
<br />
No datatype proposed for tei.temporalExpr_at_full: leaving well alone
<br />
No datatype proposed for term_at_type: leaving well alone
<br />
No datatype proposed for textLang_at_otherLangs: leaving well alone
<br />
No datatype proposed for tei.timed_at_start: leaving well alone
<br />
No datatype proposed for tei.timed_at_end: leaving well alone
<br />
No datatype proposed for tei.timed_at_dur: leaving well alone
<br />
No datatype proposed for timeline_at_interval: leaving well alone
<br />
No datatype proposed for tree_at_label: leaving well alone
<br />
No datatype proposed for tree_at_ord: leaving well alone
<br />
No datatype proposed for triangle_at_label: leaving well alone
<br />
No datatype proposed for tei.typed_at_type: leaving well alone
<br />
No datatype proposed for tei.typed_at_subtype: leaving well alone
<br />
No datatype proposed for u_at_who: leaving well alone
<br />
No datatype proposed for unclear_at_cert: leaving well alone
<br />
No datatype proposed for valDesc_at_mode: leaving well alone
<br />
No datatype proposed for valList_at_mode: leaving well alone
<br />
No datatype proposed for vocal_at_who: leaving well alone
<br />
No datatype proposed for w_at_lemma: leaving well alone
<br />
No datatype proposed for when_at_interval: leaving well alone
<br />
No datatype proposed for witness_at_sigil: leaving well alone
<br />
No datatype proposed for writing_at_who: leaving well alone
<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 Sep 23 2005 - 09:15:31 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Fri Sep 23 09:38:51 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 23 Sep 2005 09:38:51 -0400
Subject: [tei-council] comments on edw90
In-Reply-To: <4333BB89.4040804@oucs.ox.ac.uk>
Message-ID: <17204.1387.201575.44425@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, 23 Sep 2005 09:38:51 -0400</span><br />
</address>

Sebastian Rahtz writes:
<br />
<em class="quotelev1">> haven't you just reinvented <classDecl>? 
</em><br />

That's funny, I thought I'd reinvented <handList>, <witList>, and
<br />
<castList> for roles that are not listed in the document being
<br />
transcribed. (And perhaps <interGrp> and <spanGrp>?)
<br />
 :-)
<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 Sep 23 2005 - 09:39:01 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Fri Sep 23 09:59:04 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 23 Sep 2005 09:59:04 -0400
Subject: [tei-council] progress on datatypes
In-Reply-To: <43340183.9010604@oucs.ox.ac.uk>
Message-ID: <17204.2600.896868.537062@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, 23 Sep 2005 09:59:04 -0400</span><br />
</address>

Wow. It worked? Cool. Congrats, Lou.
<br />

Any chance that it's easy for you to re-post the first report such
<br />
that line-wrapping doesn't make it even harder to read & process?
<br />

Of course, there's still a lot of work to be done on individual
<br />
attributes and hammering out the declarations of types, but we've
<br />
just accomplished a big step in the right direction.
<br />

<p>The "current" column of the table is now mostly incorrect. Do people
<br />
want me to rename it to "used to be" or just drop it altogether?
<br />

Whichever, at the same time I'll make the output sortable by comment.
<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 Sep 23 2005 - 09:59:14 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Fri Sep 23 19:54:18 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 24 Sep 2005 00:54:18 +0100
Subject: [tei-council] datatypes: outstanding questions
Message-ID: <433495AA.50805@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, 24 Sep 2005 00:54:18 +0100</span><br />
</address>

I now have another, and MUCH SHORTER list of outstanding issues for 
<br />
Council's consideration. There follows a list of all attributes whose 
<br />
datatype remains a matter of uncertainty. In some cases Syd has made a 
<br />
suggestion which I disagree with; in others there is no suggestion; in 
<br />
two or three others, I agree with the suggestion, but havent yet 
<br />
implemented it. Fortunately, there are only a few!
<br />

w_at_lemma:
<br />
  Syd suggests this should be a child element which is not unreasonable: 
<br />
if it remains an
<br />
  attribute, I think it should be tei.data.name
<br />

<br />
textLang_at_otherLangs:
<br />
  Syd proposes list { tei.data.language+ } : fine
<br />

alt_at_weights:
<br />
   list { tei.data.probability+ } : fine
<br />

pecDesc_at_atts:
<br />
   list { xsd:NCName* } : I think list {tei.data.ident+}  wd be more 
<br />
consistent
<br />

arc_at_label2:
<br />
node_at_label2:
<br />
arc_at_label:
<br />
eLeaf_at_label:
<br />
eTree_at_label:
<br />
graph_at_label:
<br />
iNode_at_label:
<br />
leaf_at_label:
<br />
node_at_label:
<br />
root_at_label:
<br />
tree_at_label:
<br />
triangle_at_label:
<br />
   Syd marks all these as "NaAA" : but they are still all there and
<br />
   need to be fixed if we want to retain this module
<br />

orgDivn_at_reg:
<br />
orgName_at_reg:
<br />
orgTitle_at_reg:
<br />
orgType_at_reg:
<br />
   Likewise, marked as NaAA : need to be fixed
<br />

m_at_baseForm:
<br />
   pending DI revision : shd be treated as w_at_lemma above
<br />

chemaSpec_at_start:
<br />
   Syd proposes tei.data.idents: should be list {tei.data.ident+} for
<br />
   consistency
<br />

tree_at_ord:
<br />
   tei.data.truthValue | "partial" : shd be closed vallist, 
<br />
tei.data.enumerated
<br />

chemaSpec_at_namespace:
<br />
elementSpec_at_ns:
<br />
   Syd proposes xsd:anyURI : but is a namespace
<br />
   necessarily a URI (and if it is, why not use
<br />
   tei.data.pointer). suggest (new) tei.data.namespace mapping to ?
<br />

metSym_at_terminal:
<br />
numeric_at_trunc:
<br />
binary_at_value:
<br />
   Syd suggests  xsd:boolean for these: I think they should all be
<br />
   tei.data.truthValue (which should map to xsd:boolean; cases where 
<br />
truthValue permits "unknown" shd be given     different datatype)
<br />

timeline_at_interval:
<br />
when_at_interval:
<br />
   xsd:float { minInclusive = "0" } | xsd:token : rationalise to
<br />
   tei.data.count and revise text (use null value for uncertain
<br />
   interval size)
<br />

handDesc_at_hands:
<br />
   xsd:nonNegativeInteger | "many" : rationalise to tei.data.count and
<br />
   remove "many" option.
<br />

<p>TEI_at_version:
<br />
   Syd proposes  xsd:token { pattern="[0-9]+(\.[0-9]+){0,2}[abdp]?" :
<br />
   which seems entirely unnecessary effort to me, but it doesnt matter
<br />
   to anyone except us, so ...
<br />

ense_at_level:
<br />
   xsd:unsignedShort : shd be tei.data.count
<br />

alt_at_wScale:
<br />
altGrp_at_wScale:
<br />
   Syd says [should be dropped completely] : i agree, assuming that we
<br />
   agree on using either 0..1 or 0..100 (but not either) to express
<br />
   probabilities. These elements need a lot of tidying up.
<br />

<p>%tei.dictionaries_at_expand:
<br />
%tei.dictionaries_at_split:
<br />
%tei.dictionaries_at_value:
<br />
    : no proposals are made for these three, presumably "pending DI
<br />
    revision"
<br />

%tei.pointerGroup_at_targFunc:
<br />
   list { tei.data.ident, tei.data.idents } : I agree that this should
<br />
   be handled in the same way as targets attribute, but its components
<br />
   are tei.data.name not tei.data.ident -- they are arbitrary names,
<br />
   not XML identifiers
<br />

<p>%tei.pointerGroup_at_domains:
<br />
   list { tei.data.pointer, tei.data.pointers } : yes, tho I think it
<br />
   might be better to rethink this lot as child elements
<br />

%tei.dictionaries_at_orig:
<br />
   NaAA : is still there, but in need of serious revision
<br />

%tei.names_at_reg:
<br />
   NaAA :  is still there, but in need of serious revision
<br />
%tei.personPart_at_reg:
<br />
   NaAA :  is still there, but in need of serious revision
<br />

%tei.temporalExpr_at_reg:
<br />
   NaAA : is still there, but should be removed
<br />

%tei.declarable_at_default:
<br />
%tei.identifiable_at_predeclare:
<br />
   xsd:boolean : should both be tei.data.truthValue, cf above
<br />

%tei.global_at_xmlid:
<br />
   xsd:ID : er, yes.
<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> Fri Sep 23 2005 - 20:01:57 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sat Sep 24 07:08:27 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 24 Sep 2005 12:08:27 +0100
Subject: [tei-council] datatypes: outstanding questions
In-Reply-To: <433495AA.50805@computing-services.oxford.ac.uk>
Message-ID: <433533AB.7020201@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, 24 Sep 2005 12:08:27 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> w_at_lemma:
</em><br />
<em class="quotelev1">>  Syd suggests this should be a child element which is not
</em><br />
<em class="quotelev1">> unreasonable: if it remains an
</em><br />
<em class="quotelev1">>  attribute, I think it should be tei.data.name
</em><br />

I'm with Syd on that, at first sight
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> arc_at_label2:
</em><br />
<em class="quotelev1">> .....
</em><br />
<em class="quotelev1">>   Syd marks all these as "NaAA" : but they are still all there and
</em><br />
<em class="quotelev1">>   need to be fixed if we want to retain this module
</em><br />

why would these stop being attributes? they look like simple tokens mostly
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> orgDivn_at_reg:
</em><br />
<em class="quotelev1">> orgName_at_reg:
</em><br />
<em class="quotelev1">> orgTitle_at_reg:
</em><br />
<em class="quotelev1">> orgType_at_reg:
</em><br />
<em class="quotelev1">>   Likewise, marked as NaAA : need to be fixed
</em><br />

to non-attributes, yes
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> schemaSpec_at_namespace:
</em><br />
<em class="quotelev1">> elementSpec_at_ns:
</em><br />
<em class="quotelev1">>   Syd proposes xsd:anyURI : but is a namespace
</em><br />
<em class="quotelev1">>   necessarily a URI (and if it is, why not use
</em><br />
<em class="quotelev1">>   tei.data.pointer). suggest (new) tei.data.namespace mapping to ?
</em><br />

I now believe namespaces are URI, so believe in pointer
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> metSym_at_terminal:
</em><br />
<em class="quotelev1">> numeric_at_trunc:
</em><br />
<em class="quotelev1">> binary_at_value:
</em><br />
<em class="quotelev1">>   Syd suggests  xsd:boolean for these: I think they should all be
</em><br />
<em class="quotelev1">>   tei.data.truthValue (which should map to xsd:boolean; cases where
</em><br />
<em class="quotelev1">> truthValue permits "unknown" shd be given     different datatype)
</em><br />

yes, agreed. call the extended one "tei.data.Philosophical"
<br />

<em class="quotelev1">> handDesc_at_hands:
</em><br />
<em class="quotelev1">>   xsd:nonNegativeInteger | "many" : rationalise to tei.data.count and
</em><br />
<em class="quotelev1">>   remove "many" option.
</em><br />

nah, extend it to also allow "not many", "quite a few", "a reasonable
<br />
amount", "not many at all", "god knows", "really quite a decent number". etc
<br />

in other cases I either agree with Lou or concur that I dont know what to do
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sat Sep 24 2005 - 07:08:56 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sat Sep 24 11:38:23 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 24 Sep 2005 11:38:23 -0400
Subject: [tei-council] datatypes: outstanding questions
In-Reply-To: <433495AA.50805@computing-services.oxford.ac.uk>
Message-ID: <17205.29423.518168.418211@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, 24 Sep 2005 11:38:23 -0400</span><br />
</address>

Very quick reply, as I have to leave in a few mins for flight to
<br />
Oxford.
<br />

<p><em class="quotelev1">> specDesc_at_atts:
</em><br />
<em class="quotelev1">>    list { xsd:NCName* } : I think list {tei.data.ident+}  wd be more 
</em><br />
<em class="quotelev1">>    consistent
</em><br />

Would be fine with me, but that "+" has to be a "*", as atts="" has
<br />
meaning. 
<br />

<p><em class="quotelev1">>    Syd marks all these as "NaAA" : but they are still all there and
</em><br />
<em class="quotelev1">>    need to be fixed if we want to retain this module
</em><br />

Right. "NaAA" really should be "NS2baAA" (not supposed to be an
<br />
attribute anymore :-)
<br />

<p><em class="quotelev1">> schemaSpec_at_start:
</em><br />
<em class="quotelev1">>    Syd proposes tei.data.idents: should be list {tei.data.ident+} for
</em><br />
<em class="quotelev1">>    consistency
</em><br />

In which case do we need tei.data.idents, or should we always just
<br />
use the RNG 'list' notation directly?
<br />

<p><em class="quotelev1">> tree_at_ord:
</em><br />
<em class="quotelev1">>    tei.data.truthValue | "partial" : shd be closed vallist, 
</em><br />
<em class="quotelev1">> tei.data.enumerated
</em><br />

It's fine with me, but I'm shocked that you'd suggest it. doesn't
<br />
putting "0", "1", "true" and "false" into an enumeration lose the
<br />
same information you lose by using "10:35" in a time?
<br />

<p><em class="quotelev1">> schemaSpec_at_namespace:
</em><br />
<em class="quotelev1">> elementSpec_at_ns:
</em><br />
<em class="quotelev1">>    Syd proposes xsd:anyURI : but is a namespace
</em><br />
<em class="quotelev1">>    necessarily a URI (and if it is, why not use
</em><br />
<em class="quotelev1">>    tei.data.pointer). suggest (new) tei.data.namespace mapping to ?
</em><br />

Yes, a namespace is necessarily an IRI (internationalized URI). From
<br />
the Namespaces in XML 1.1 spec:
<br />

  [Definition: An XML namespace is identified by an IRI reference;
<br />
   element and attribute names may be placed in an XML namespace
<br />
   using the mechanisms described in this specification. ]
<br />

<p><em class="quotelev1">> metSym_at_terminal:
</em><br />
<em class="quotelev1">> numeric_at_trunc:
</em><br />
<em class="quotelev1">> binary_at_value:
</em><br />
<em class="quotelev1">>    Syd suggests  xsd:boolean for these: I think they should all be
</em><br />
<em class="quotelev1">>    tei.data.truthValue (which should map to xsd:boolean; cases where 
</em><br />
<em class="quotelev1">> truthValue permits "unknown" shd be given different datatype)
</em><br />

Again, I don't see that the indirection gains us anything, but I
<br />
certainly don't object.
<br />

<p><em class="quotelev1">> timeline_at_interval:
</em><br />
<em class="quotelev1">> when_at_interval:
</em><br />
<em class="quotelev1">>    xsd:float { minInclusive = "0" } | xsd:token : rationalise to
</em><br />
<em class="quotelev1">>    tei.data.count and revise text (use null value for uncertain
</em><br />
<em class="quotelev1">>    interval size)
</em><br />

Can't: intervals don't have to be integers. (And remember, the only
<br />
token permitted was "unknown" or some such.) Could use
<br />
tei.data.numeric, but that permits all sorts of values (negative
<br />
numbers, scientific notation) that make no sense. (I suppose we could
<br />
use tei.data.numeric, and say in the prose that *any* negative value
<br />
indicates uncertainty.)
<br />

<p><em class="quotelev1">> handDesc_at_hands:
</em><br />
<em class="quotelev1">>    xsd:nonNegativeInteger | "many" : rationalise to tei.data.count and
</em><br />
<em class="quotelev1">>    remove "many" option.
</em><br />

I like the idea, but I'm worried that the reason P4 permitted the
<br />
vague term(s?) is because manuscript describes do not want to or
<br />
cannot accurately count the number of hands. Matthew?
<br />

<p><em class="quotelev1">> sense_at_level:
</em><br />
<em class="quotelev1">>    xsd:unsignedShort : shd be tei.data.count
</em><br />

Yup.
<br />

<p><em class="quotelev1">> alt_at_wScale:
</em><br />
<em class="quotelev1">> altGrp_at_wScale:
</em><br />
<em class="quotelev1">>    Syd says [should be dropped completely] : i agree, assuming that we
</em><br />
<em class="quotelev1">>    agree on using either 0..1 or 0..100 (but not either) to express
</em><br />
<em class="quotelev1">>    probabilities. These elements need a lot of tidying up.
</em><br />

It can (and should) be dropped completely if we allow either, is long
<br />
as they can be differentiated by syntax, e.g., appending "%" to the
<br />
0..100 case.
<br />

<p><em class="quotelev1">> %tei.pointerGroup_at_targFunc:
</em><br />
<em class="quotelev1">>    list { tei.data.ident, tei.data.idents } : I agree that this should
</em><br />
<em class="quotelev1">>    be handled in the same way as targets attribute, but its components
</em><br />
<em class="quotelev1">>    are tei.data.name not tei.data.ident -- they are arbitrary names,
</em><br />
<em class="quotelev1">>    not XML identifiers
</em><br />

OK w/ me. I think I was just copying the description.
<br />

<p>Gotta go ...
<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 Sep 24 2005 - 11:38:35 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sat Sep 24 11:41:47 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 24 Sep 2005 11:41:47 -0400
Subject: [tei-council] datatypes: outstanding questions
In-Reply-To: <433533AB.7020201@oucs.ox.ac.uk>
Message-ID: <17205.29627.392312.296241@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, 24 Sep 2005 11:41:47 -0400</span><br />
</address>

<em class="quotelev1">> why would these stop being attributes? they look like simple tokens
</em><br />
<em class="quotelev1">> mostly
</em><br />

Because they might have characters outside of Unicode or be in a
<br />
language other than the element on which they are specified (or would
<br />
be a child).
<br />

<p><em class="quotelev1">> nah, extend it to also allow "not many", "quite a few", "a
</em><br />
<em class="quotelev1">> reasonable amount", "not many at all", "god knows", "really quite a
</em><br />
<em class="quotelev1">> decent number". etc
</em><br />

Hmmm... I don't know enough about encoding of different hands in
<br />
manuscripts to say whether the precise (tei.data.count) or vague
<br />
(above) suggestion is better, but if we go with the vague, we can't
<br />
have spaces in the values. (Enumerations are the ident= of <valItem>,
<br />
and ident= is a tei.data.ident, which can't have a space.)
<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 Sep 24 2005 - 11:41:59 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sat Sep 24 12:59:38 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 24 Sep 2005 17:59:38 +0100
Subject: [tei-council] datatypes: outstanding questions
In-Reply-To: <17205.29627.392312.296241@emt.wwp.brown.edu>
Message-ID: <433585FA.7040907@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, 24 Sep 2005 17:59:38 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev2">>>why would these stop being attributes? they look like simple tokens
</em><br />
<em class="quotelev2">>>mostly
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Because they might have characters outside of Unicode or be in a
</em><br />
<em class="quotelev1">>language other than the element on which they are specified (or would
</em><br />
<em class="quotelev1">>be a child).
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I think I must be misunderstanding those elements....
<br />

<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>nah, extend it to also allow "not many", "quite a few", "a
</em><br />
<em class="quotelev2">>>reasonable amount", "not many at all", "god knows", "really quite a
</em><br />
<em class="quotelev2">>>decent number". etc
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Hmmm...
</em><br />
<em class="quotelev1">>
</em><br />
I was joking, by the way :-}
<br />

I dont know wjat, but I cannot believe it is sensible to
<br />
have an apparent numeric attribute with an alternative of
<br />
"well, some, dont know how many"
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sat Sep 24 2005 - 12:59:58 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sat Sep 24 19:38:07 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 25 Sep 2005 08:38:07 +0900
Subject: [tei-council] datatypes: outstanding questions
In-Reply-To: <433495AA.50805@computing-services.oxford.ac.uk>
Message-ID: <ygf7jd6ghpc.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 25 Sep 2005 08:38:07 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> I now have another, and MUCH SHORTER list of outstanding issues for
</em><br />
<em class="quotelev1">> Council's consideration. 
</em><br />

Great.  We are indeed making rapid progress!
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> w_at_lemma:
</em><br />
<em class="quotelev1">>   Syd suggests this should be a child element which is not
</em><br />
<em class="quotelev1">>   unreasonable: if it remains an
</em><br />
<em class="quotelev1">>   attribute, I think it should be tei.data.name
</em><br />

I would also advocate a child element here, but I am a bit afraid that
<br />
if <w> is used, it is usually quite extensively, which would make it
<br />
quite unwieldy to handle this with a child element, rather than an
<br />
attribute.  But I guess this is what we will have to get used to.
<br />
Encoders can always change this back to @lemma with their ODDs.
<br />

<em class="quotelev1">> arc_at_label2:
</em><br />
<em class="quotelev1">> triangle_at_label:
</em><br />
<em class="quotelev1">>    Syd marks all these as "NaAA" : but they are still all there and
</em><br />
<em class="quotelev1">>    need to be fixed if we want to retain this module
</em><br />

All these labels need to be changed to child elements here, no sweat.
<br />

<em class="quotelev1">> orgDivn_at_reg:
</em><br />
<em class="quotelev1">> orgName_at_reg:
</em><br />
<em class="quotelev1">> orgTitle_at_reg:
</em><br />
<em class="quotelev1">> orgType_at_reg:
</em><br />
<em class="quotelev1">>    Likewise, marked as NaAA : need to be fixed
</em><br />

ame here.
<br />

<em class="quotelev1">> schemaSpec_at_start:
</em><br />
<em class="quotelev1">>    Syd proposes tei.data.idents: should be list {tei.data.ident+} for
</em><br />
<em class="quotelev1">>    consistency
</em><br />

Wow, you can have more than one ident here?  Good news.
<br />

<em class="quotelev1">> schemaSpec_at_namespace:
</em><br />
<em class="quotelev1">> elementSpec_at_ns:
</em><br />
<em class="quotelev1">>    Syd proposes xsd:anyURI : but is a namespace
</em><br />
<em class="quotelev1">>    necessarily a URI (and if it is, why not use
</em><br />
<em class="quotelev1">>    tei.data.pointer). suggest (new) tei.data.namespace mapping to ?
</em><br />

and of course, both will have the same names, surely?
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> TEI_at_version:
</em><br />
<em class="quotelev1">>    Syd proposes  xsd:token { pattern="[0-9]+(\.[0-9]+){0,2}[abdp]?" :
</em><br />
<em class="quotelev1">>    which seems entirely unnecessary effort to me, but it doesnt matter
</em><br />
<em class="quotelev1">>    to anyone except us, so ...
</em><br />

Shouldn't this be a fixed value? 5.0 for P5?  Everything else seems to
<br />
be asking for trouble to me.
<br />

<em class="quotelev1">> alt_at_wScale:
</em><br />
<em class="quotelev1">> altGrp_at_wScale:
</em><br />
<em class="quotelev1">>    Syd says [should be dropped completely] : i agree, assuming that we
</em><br />
<em class="quotelev1">>    agree on using either 0..1 or 0..100 (but not either) to express
</em><br />
<em class="quotelev1">>    probabilities. These elements need a lot of tidying up.
</em><br />

Who will be doing this tidying up? 
<br />

<em class="quotelev1">> %tei.dictionaries_at_expand:
</em><br />
<em class="quotelev1">> %tei.dictionaries_at_split:
</em><br />
<em class="quotelev1">> %tei.dictionaries_at_value:
</em><br />
<em class="quotelev1">>     : no proposals are made for these three, presumably "pending DI
</em><br />
<em class="quotelev1">>     revision"
</em><br />

They all look like elements to me, mostly.  We need to have a formal
<br />
process to get the "DI revision" into shape.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> %tei.dictionaries_at_orig:
</em><br />
<em class="quotelev1">>    NaAA : is still there, but in need of serious revision
</em><br />

as above.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> %tei.names_at_reg:
</em><br />
<em class="quotelev1">>    NaAA :  is still there, but in need of serious revision
</em><br />
<em class="quotelev1">> %tei.personPart_at_reg:
</em><br />
<em class="quotelev1">>    NaAA :  is still there, but in need of serious revision
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> %tei.temporalExpr_at_reg:
</em><br />
<em class="quotelev1">>    NaAA : is still there, but should be removed
</em><br />
<em class="quotelev1">>
</em><br />

For all these regs, didn't we have a proposal to handle them?
<br />

<p>Time for boarding,
<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> Sat Sep 24 2005 - 19:38:31 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Sep 25 09:38:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 25 Sep 2005 09:38:11 -0400
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <ygfek7lcndl.fsf@chwpb.local>
Message-ID: <17206.43075.888747.279444@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, 25 Sep 2005 09:38:11 -0400</span><br />
</address>

<em class="quotelev1">> It is a timespan, put not a point in time. This problem raises its
</em><br />
<em class="quotelev1">> head regularily when trying to express a Chinese year in ISO, which
</em><br />
<em class="quotelev1">> should then be rendered as 1900-02-17 to 1901-01-29. Any idea how
</em><br />
<em class="quotelev1">> this could be expressed on @value for date?
</em><br />

This is easily represented in ISO 8601 with one of 
<br />
   1900-02-17/1901-01-29
<br />
   1900-02-17/P0Y11M12D
<br />
   P0Y11M12D/1901-01-29
<br />
   or, if parties have agreed to use the alternative format
<br />
   1900-02-17/P0000-11-12
<br />
or any one of lots of variations if you drop the "0Y", use
<br />
week-numbers instead of dates, or express the period in days instead
<br />
of months & days, etc.
<br />

However, I do not think W3C permits any of these representation of
<br />
ranges in their datatypes. (They use notBefore= and notAfter=, I
<br />
think.) I don't know, but I would not be surprised if they're lack of
<br />
support is because implementing this is a pain.
<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 Sep 25 2005 - 09:38:22 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Sep 25 11:02:57 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 25 Sep 2005 11:02:57 -0400
Subject: [tei-council] datatypes: outstanding questions
In-Reply-To: <ygf7jd6ghpc.fsf@chwpb.local>
Message-ID: <17206.48161.806355.779231@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, 25 Sep 2005 11:02:57 -0400</span><br />
</address>

CW> Shouldn't [version= of TEI] be a fixed value? 5.0 for P5?
<br />
CW> Everything else seems to be asking for trouble to me.
<br />

Brings up a good question about what purpose that version number
<br />
serves, not just its format. In theory, the format has already been
<br />
decided (on 20004-01-27), and my suggested regexp violates it :-)
<br />
However, I note that we agreed on that format before we instituted
<br />
Sourceforge, and we may want to rethink this again.
<br />

The problem is we agreed on "5.minor.bugfix", but on Sourceforge we
<br />
are using, e.g., "0.1.10". Does that correspond to "5.1.10" (I'd
<br />
prefer not, as "0.1.10" implies it is still pre-release, but "5.1.10"
<br />
does not.)
<br />

Whatever the format for the version number (I sometimes lean towards
<br />
just using the release date, period), we need to consider whether it
<br />
represents only the version of P5 upon which the document is based,
<br />
or also the version of the local customization files. And perhaps the
<br />
language, too.
<br />

Of course it could be argued that whatever it is, it should be #FIXED.
<br />
I.e., the schema declares the only possible value for the (required)
<br />
attribute. 
<br />

<p>CW> For all these regs, didn't we have a proposal to handle them?
<br />

There are several, IIRC, but the one that Council is currently
<br />
supposed to be considering was posted to the list 2005-07-08 with the
<br />
subject "regularizing names". Mailman doesn't seem to let you pull up
<br />
a single set of postings by thread/subject/date, but I think
<br />
searching for "regu" at
<br />
http://lists.village.virginia.edu/mailman/private/tei-council/2005/subject.html
<br />
will get you this thread.
<br />

<p>CW> Time for boarding,
<br />

Hope your flight has gone well. I just checked with the front desk,
<br />
and you're not here yet.
<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 Sep 25 2005 - 11:03:07 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Sun Sep 25 12:06:03 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 25 Sep 2005 17:06:03 +0100
Subject: [tei-council] datatypes: outstanding questions
In-Reply-To: <17205.29627.392312.296241@emt.wwp.brown.edu>
Message-ID: <4336CAEB.9000400@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>: Sun, 25 Sep 2005 17:06:03 +0100</span><br />
</address>

Syd Bauman wrote:
<br />
<em class="quotelev1">> Hmmm... I don't know enough about encoding of different hands in
</em><br />
<em class="quotelev1">> manuscripts to say whether the precise (tei.data.count) or vague
</em><br />
<em class="quotelev1">> (above) suggestion is better, but if we go with the vague, we can't
</em><br />
<em class="quotelev1">> have spaces in the values. (Enumerations are the ident= of <valItem>,
</em><br />
<em class="quotelev1">> and ident= is a tei.data.ident, which can't have a space.)
</em><br />

It seems obvious that it is possible for the number of hands in a 
<br />
manuscript to either a) but uncountable in any reliable sense or b) 
<br />
debateable.  I would be nervous of having to say how many hands a 
<br />
particular manuscript contains.  However, if instead this attribute 
<br />
really means how many hands the electronic version of the document has 
<br />
  recorded/identify, then that is perfectly fine and I have no problem 
<br />
with it being a fixed value.
<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 Sep 25 2005 - 12:06:02 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep 25 12:34:36 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 25 Sep 2005 17:34:36 +0100
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <17206.43075.888747.279444@emt.wwp.brown.edu>
Message-ID: <4336D19C.7040202@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, 25 Sep 2005 17:34:36 +0100</span><br />
</address>

Does it strike anyone that instead of
<br />
  foo="true|false|unknown"
<br />
we could just say that the absence of the foo attribute
<br />
means "unknown"? then all the boolean
<br />
attributes stay as true|false, but some are required
<br />
and some are optional.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Sep 25 2005 - 12:35:00 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Sep 25 13:05:25 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 25 Sep 2005 13:05:25 -0400
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <4336D19C.7040202@oucs.ox.ac.uk>
Message-ID: <17206.55509.686733.707626@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, 25 Sep 2005 13:05:25 -0400</span><br />
</address>

<em class="quotelev1">> Does it strike anyone that instead of
</em><br />
<em class="quotelev1">>   foo="true|false|unknown"
</em><br />
<em class="quotelev1">> we could just say that the absence of the foo attribute
</em><br />
<em class="quotelev1">> means "unknown"? then all the boolean
</em><br />
<em class="quotelev1">> attributes stay as true|false, but some are required
</em><br />
<em class="quotelev1">> and some are optional.
</em><br />

But then we'd lose the lovely, if opaque to many, distinction
<br />
between "unknown" and "unspecified". 
<br />

Seriously, I've oft thought about recommending a different set of
<br />
"not-true, not-false" values, but never got around to it. If we can
<br />
agree that distinctions between things like
<br />
 * unknown (I didn't try to find out)
<br />
 * undetermined (I tried, but failed)
<br />
 * unknowable (not only did I fail, but you will too)
<br />
 * unspecified (answer was not in the source I'm transcribing)
<br />
 * indeterminate (I'm sure I could find out, if I had more
<br />
                  information)
<br />
 * unwilling (I know, but I'm not telling)
<br />
can all be collapsed into one non-value, then it may make a lot of
<br />
sense.
<br />

Alright, it wasn't entirely seriously.
<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 Sep 25 2005 - 13:05:35 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sun Sep 25 13:03:22 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 25 Sep 2005 18:03:22 +0100
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <4336D19C.7040202@oucs.ox.ac.uk>
Message-ID: <4336D85A.5060708@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, 25 Sep 2005 18:03:22 +0100</span><br />
</address>

Sebastian Rahtz wrote:
<br />

<em class="quotelev1">>Does it strike anyone that instead of
</em><br />
<em class="quotelev1">>  foo="true|false|unknown"
</em><br />
<em class="quotelev1">>we could just say that the absence of the foo attribute
</em><br />
<em class="quotelev1">>means "unknown"? then all the boolean
</em><br />
<em class="quotelev1">>attributes stay as true|false, but some are required
</em><br />
<em class="quotelev1">>and some are optional.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
Not a bad idea, but we actually have four values for the extended 
<br />
boolean -- true, false, unknown, and inapplicable
<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 Sep 25 2005 - 13:10:11 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep 25 13:11:10 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 25 Sep 2005 18:11:10 +0100
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <17206.55509.686733.707626@emt.wwp.brown.edu>
Message-ID: <4336DA2E.5050102@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, 25 Sep 2005 18:11:10 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>But then we'd lose the lovely, if opaque to many, distinction
</em><br />
<em class="quotelev1">>between "unknown" and "unspecified". 
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
so opaque I can barely see through it...
<br />

<em class="quotelev1">> * unknown (I didn't try to find out)
</em><br />
<em class="quotelev1">> * undetermined (I tried, but failed)
</em><br />
<em class="quotelev1">> * unknowable (not only did I fail, but you will too)
</em><br />
<em class="quotelev1">> * unspecified (answer was not in the source I'm transcribing)
</em><br />
<em class="quotelev1">> * indeterminate (I'm sure I could find out, if I had more
</em><br />
<em class="quotelev1">>                  information)
</em><br />
<em class="quotelev1">> * unwilling (I know, but I'm not telling)
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I think that's splendid!
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Sep 25 2005 - 13:11:26 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sun Sep 25 15:24:02 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 25 Sep 2005 20:24:02 +0100
Subject: [tei-council] datatypes updated
Message-ID: <4336F952.5030502@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, 25 Sep 2005 20:24:02 +0100</span><br />
</address>

I have now checked  new versions of all tagdocs, classdocs, and chapter 
<br />
files
<br />
into CVS. These versions now use the new datatypes only (more or less!)
<br />

There follow some random notes on what I needed to change (or not 
<br />
change) to get this revised version to validate both P5 itself and our 
<br />
current test suite.
<br />

<p>1.  textLang used to use langKey and otherLang to reference a <language>
<br />
 - I have changed them to tei.data.language to do this which means they 
<br />
dont need to be pointers any more, but they must use valid language 
<br />
codes. I also changed "langKey" to "mainLang". 
<br />

2. I have left most things defined as tei.data.names unchanged. But they 
<br />
need to be reviewed, and changed to either list{tei.data.name*} or 
<br />
tei.data.token (or some other name to map on to xsd:token), depending on 
<br />
whether they are actually distinct items like "up down" or single items 
<br />
which just happen to have a space in them like "fat possum"
<br />

3.  tei.data.probability : I have made this consistently a number 
<br />
between 0 and 1, and I have decided on using it for certainty_at_degree, 
<br />
and as an alternation with tei.data.certainty for  damage_at_degree -- 
<br />
sorry, no percentages.
<br />

4. tei.data.certainty : this needs a better name to indicate that it 
<br />
means "approximate designation of quantity" : i used it for purpose_at_degree
<br />

4. schemaSpec_at_start is oneOrMore tei.idents, rather than zeroOrMore as 
<br />
proposed by Syd
<br />

5. scheme attribute on att, tag, gi : as these have a vallist, i have 
<br />
made them tei.data.enumerated and also made the list open to cater for 
<br />
the various names used in SA
<br />

6. In abolishing the reg= attribute i had to revise the text of CO a bit 
<br />
and ND quite a lot. The latter in particular contains several examples 
<br />
best characterized as a little eccentric... and two problems remain: how 
<br />
to represent a glossed geographic feature like <geogName>Mont (Mountain) 
<br />
St Michel</geogName>
<br />

7. somehow note_at_target came out as truthValue instead of pointers: fixed
<br />

8. metsym_at_value changed back to text, since examples use / and @
<br />

9. ruledLines changed to choice of single or list of two tei.data.count 
<br />
to allow for range (this meant also changing several egs in MS
<br />

10. removed several cases where reg= was being used to mean equiv= for 
<br />
quantities etc. this needs thought
<br />

11.  xsd:regexp doesnt allow use of +- as in example for metdecl: 
<br />
changed example
<br />

12.  attributes width, height, scale on (at least) graphic need some 
<br />
more thought; height and width should include units ("10in" etc) ; scale 
<br />
should be tei.data.probability (which maybe needs a better name?)
<br />

13. fragmentPattern_at_pat changed to text pro tem (shd be child element?)
<br />

14. state_at_delim -> reverted to text (names doesnt allow space)
<br />

15. handNote_at_script should be tei.data.names, not pointer
<br />

<p>L
<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> Sun Sep 25 2005 - 15:30:49 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Sep 25 17:05:10 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 25 Sep 2005 17:05:10 -0400
Subject: [tei-council] datatypes updated
In-Reply-To: <4336F952.5030502@computing-services.oxford.ac.uk>
Message-ID: <17207.4358.200293.269412@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, 25 Sep 2005 17:05:10 -0400</span><br />
</address>

<em class="quotelev1">> I have now checked new versions of all tagdocs, classdocs, and
</em><br />
<em class="quotelev1">> chapter files into CVS. These versions now use the new datatypes
</em><br />
<em class="quotelev1">> only (more or less!)
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> There follow some random notes on what I needed to change (or not
</em><br />
<em class="quotelev1">> change) to get this revised version to validate both P5 itself and
</em><br />
<em class="quotelev1">> our current test suite.
</em><br />

I am getting two massive sets of errors. 
<br />

* It seems that at least fileents.dtd still points to a directory
<br />
  called "newSource/". I've changed 'em to "Source/", will check in
<br />
  shortly, presuming it works.
<br />

* For reasons I can't explain, jing is calling the wrong java. I
<br />
  have to manually reset JAVA_HOME to get it to work.
<br />

Oh. I see someone's already checked in a fixed fileents.dtd now.
<br />
Good. However, now that I've fixed these two, I'm still getting quite
<br />
a few validation problems, but am probably too tired to do much about
<br />
it tonight.
<br />

<p><em class="quotelev1">> 1. textLang used to use langKey and otherLang to reference a
</em><br />
<em class="quotelev1">> <language> - I have changed them to tei.data.language to do this
</em><br />
<em class="quotelev1">> which means they dont need to be pointers any more, but they must
</em><br />
<em class="quotelev1">> use valid language codes. I also changed "langKey" to "mainLang".
</em><br />

I don't understand. They are listed as tei.data.language in the EDW90
<br />
table, and always have been (well, otherLangs= was list {
<br />
xsd:language } at one point).
<br />

Ah well, as long as they've been fixed.
<br />

<p><em class="quotelev1">> 2. I have left most things defined as tei.data.names unchanged. But
</em><br />
<em class="quotelev1">> they need to be reviewed, and changed to either
</em><br />
<em class="quotelev1">> list{tei.data.name*} or tei.data.token (or some other name to map
</em><br />
<em class="quotelev1">> on to xsd:token), depending on whether they are actually distinct
</em><br />
<em class="quotelev1">> items like "up down" or single items which just happen to have a
</em><br />
<em class="quotelev1">> space in them like "fat possum"
</em><br />

This review had already been done -- in the EDW90 table, as of last
<br />
week at least, those that had actual distinct items were either
<br />
tei.data.tokens or list { something }.
<br />

<p><em class="quotelev1">> 3.  tei.data.probability : I have made this consistently a number 
</em><br />
<em class="quotelev1">> between 0 and 1, and I have decided on using it for certainty_at_degree, 
</em><br />
<em class="quotelev1">> and as an alternation with tei.data.certainty for  damage_at_degree -- 
</em><br />
<em class="quotelev1">> sorry, no percentages.
</em><br />

So the net effect is 
<br />
1) removed alternation of tei.data.certainty from recommendation for
<br />
   degree= of <certainty>
<br />
2) no percentages in tei.data.probability
<br />

<p><em class="quotelev1">> 4. tei.data.certainty : this needs a better name to indicate that
</em><br />
<em class="quotelev1">> it means "approximate designation of quantity" : i used it for
</em><br />
<em class="quotelev1">> purpose_at_degree
</em><br />

I.e., you've removed alternation of tei.data.probability from
<br />
recommendation for degree= of <purpose>. How come? (Having never seen
<br />
a <purpose> element used in real life, I don't think, I'm not sure I
<br />
understand how one is intended to combine either probabilities or
<br />
"high", "medium", et al., let alone intertwine them.)
<br />

<p><em class="quotelev1">> 4. schemaSpec_at_start is oneOrMore tei.idents, rather than zeroOrMore as 
</em><br />
<em class="quotelev1">> proposed by Syd
</em><br />

I proposed the plural class "tei.data.idents", at your suggestion,
<br />
which should boil down to 
<br />
   list { tei.data.ident+ }
<br />
Perhaps you are confusing this with the requirement that the atts=
<br />
attribute be allowed to be empty.
<br />

<p><em class="quotelev1">> 5. scheme attribute on att, tag, gi : as these have a vallist, i
</em><br />
<em class="quotelev1">> have made them tei.data.enumerated and also made the list open to
</em><br />
<em class="quotelev1">> cater for the various names used in SA
</em><br />

I'm not convinced an enumeration is the best way to go. What are
<br />
namespaces for if not to indicate the scheme an attribute or element
<br />
belongs to? While I agree the EDW90 recommendation (pointer|ident)
<br />
may be a bit dorky, I think associating an <att> or <gi> with a
<br />
namespace is a better idea.
<br />

<p><em class="quotelev1">> 6. In abolishing the reg= attribute i had to revise the text of CO
</em><br />
<em class="quotelev1">> a bit and ND quite a lot. The latter in particular contains several
</em><br />
<em class="quotelev1">> examples best characterized as a little eccentric... 
</em><br />

So what did you put into the Guidelines about how regularizations
<br />
should be encoded?
<br />

<em class="quotelev1">> ... and two problems remain: how to represent a glossed geographic
</em><br />
<em class="quotelev1">> feature like <geogName>Mont (Mountain) St Michel</geogName>
</em><br />

The other?
<br />

<p><em class="quotelev1">> 8. metsym_at_value changed back to text, since examples use / and @
</em><br />

But text allows whitespace, which you said it can't have.
<br />

I think it should be tei.data.token -- it can't have white space. It 
<br />
should be a single character in fact for any sensible kind of notation.
<br />

<p><em class="quotelev1">> 9. ruledLines changed to choice of single or list of two tei.data.count 
</em><br />
<em class="quotelev1">> to allow for range (this meant also changing several egs in MS
</em><br />

Why not just "list { tei.data.count, tei.data.count? }" ?
<br />

<p><em class="quotelev1">> 10. removed several cases where reg= was being used to mean equiv=
</em><br />
<em class="quotelev1">> for quantities etc. this needs thought
</em><br />

Indeed.
<br />

<p><em class="quotelev1">> 11.  xsd:regexp doesnt allow use of +- as in example for metdecl: 
</em><br />
<em class="quotelev1">> changed example
</em><br />

I could swear I had fixed that. Sorry.
<br />

<p><em class="quotelev1">> 12. attributes width, height, scale on (at least) graphic need some
</em><br />
<em class="quotelev1">> more thought; height and width should include units ("10in" etc) ;
</em><br />
<em class="quotelev1">> scale should be tei.data.probability (which maybe needs a better
</em><br />
<em class="quotelev1">> name?)
</em><br />

So you can't scale a graphic larger than 100%?
<br />

<p><em class="quotelev1">> 13. fragmentPattern_at_pat changed to text pro tem (shd be child
</em><br />
<em class="quotelev1">>     element?)
</em><br />

Why would this be a child element? Characters outside of Unicode or
<br />
not permitted, big time; and It cannot be said to be in any natural
<br />
language, so you can't want to indicate which one. (Note: I recently
<br />
discovered that the XPath 2.0 regular expression language includes
<br />
back references, which would allow it to be the language for this.)
<br />

<p><em class="quotelev1">> 14. state_at_delim -> reverted to text (names doesnt allow space)
</em><br />

?? tei.data.names (plural) should allow space.
<br />

<p><em class="quotelev1">> 15. handNote_at_script should be tei.<!--nospam-->data.names, not pointer
</em><br />

I had thought the control offered by tei.data.code would be
<br />
beneficial. Having never seen this attribute used, let alone used it
<br />
myself, I'll be happy to bow to your wisdom.
<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 Sep 25 2005 - 17:05:20 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep 25 17:39:34 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 25 Sep 2005 22:39:34 +0100
Subject: [tei-council] datatypes updated
In-Reply-To: <17207.4358.200293.269412@emt.wwp.brown.edu>
Message-ID: <43371916.5010007@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, 25 Sep 2005 22:39:34 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Good. However, now that I've fixed these two, I'm still getting quite
</em><br />
<em class="quotelev1">>a few validation problems, 
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I've been cycling round this, and I reckon its now stable. there are
<br />
some more errors,
<br />
but they seem to be deliberate.
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Sep 25 2005 - 17:40:02 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Sep 28 16:26:24 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 28 Sep 2005 21:26:24 +0100
Subject: [tei-council] Re: naming names
In-Reply-To: <433A9013.7020004@computing-services.oxford.ac.uk>
Message-ID: <ygfk6h17xcf.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 28 Sep 2005 21:26:24 +0100</span><br />
</address>

Thanks Sebastian, that was quick!
<br />

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Sebastian Rahtz wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>http://www.tei-c.org/Drafts/edw87.xml is updated  to reflect the
</em><br />
<em class="quotelev2">>>new thinking on The Naming of the TEI Classes. The table of classes
</em><br />
<em class="quotelev2">>>has been partly updated following these rules; the ones marked ??
</em><br />
<em class="quotelev2">>>have not been looked at yet.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>This comes from the discussion of SB, JC, CW and SR today.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>Shall I pass this by the rest of the council yet?
</em><br />

I would think the other council members should be included in the
<br />
discussion and thus added them to the recipients. 
<br />

<p><em class="quotelev1">> I can't see much use for the distinction between "part" and
</em><br />
<em class="quotelev1">> "component". Why not call them both "part".
</em><br />

We have been going back and forth on this and ended up feeling that
<br />
it is a somehow useful distinction. The purpose of the names is to
<br />
indicate something about how classes are used and/or why they have
<br />
been formed.  We probably will see whether this is useful once all new
<br />
names have been assigned.
<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> Wed Sep 28 2005 - 16:26:32 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sat Oct  1 01:29:12 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 1 Oct 2005 01:29:12 -0400 (EDT)
Subject: on spec grp 4, coded values (was "Re: [tei-council] datatypes")
In-Reply-To: <432ECEA2.30508@oucs.ox.ac.uk>
Message-ID: <200510010529.j915TCbA009042@pyxis.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>: Sat, 1 Oct 2005 01:29:12 -0400 (EDT)</span><br />
</address>

Lou Burnard wrote:
<br />

<p><em class="quotelev2">> >   - People want to know where things point. ...
</em><br />
<em class="quotelev1">> True, but irrelevant.
</em><br />

I think considering what users want "irrelevant" is a bit rough.
<br />

<p><em class="quotelev1">> We can specify the target element type, and maybe we should do so
</em><br />
<em class="quotelev1">> in some cases, but I don't see any advantage at all to trying to
</em><br />
<em class="quotelev1">> specify "where" the element instance is. It's all out there in
</em><br />
<em class="quotelev1">> cyberspace, man!
</em><br />

The advantage, again, is just to make life easier on users. They
<br />
don't want to figure out where is a good place to put something, they
<br />
just want to know where it goes. (Although it's nicer if it's not
<br />
*required* to be there.)
<br />

<p><em class="quotelev2">> > * tei.data.enumerated: the change permits whitespace in the values.
</em><br />
<em class="quotelev1">> I am open minded (or open-minded) on this question. I finally came
</em><br />
<em class="quotelev1">> down on the side of allowing *normalised* whitespace within the
</em><br />
<em class="quotelev1">> value because ...
</em><br />

This has a *major* consistency problem, though. If you have a closed
<br />
value list, the values cannot have spaces (because they must match
<br />
ident= of <valItem>). If you have an open list, they can (because the
<br />
only constraint is they must match the pattern "token").
<br />

For consistency, this *must* be declared to match the declaration of
<br />
ident= of <valItem>, which is tei.data.ident.
<br />

<p><em class="quotelev2">> > * tei.data.key: the change is from 'xsd:token' to 'rng:string'. I
</em><br />
<em class="quotelev2">> >   think it should be left as 'xsd:token' just for consistency.
</em><br />
<em class="quotelev2">> >   There is no difference in validation at all (since there are no
</em><br />
<em class="quotelev2">> >   enumerated values).
</em><br />
<em class="quotelev1">> There is all the difference in the world. key is *explicitly*
</em><br />
<em class="quotelev1">> defined as something that is to be validated externally and over
</em><br />
<em class="quotelev1">> which the TEI should therefore place no (additional) syntactic
</em><br />
<em class="quotelev1">> constraints. We cannot possibly second guess what syntactic
</em><br />
<em class="quotelev1">> constraints every database system in the world might impose, ergo
</em><br />
<em class="quotelev1">> our only choice is to not impose any at all.
</em><br />

And what syntactic constraints do you believe xsd:token would impose?
<br />
In RelaxNG, AFAIK, the only constraints are that all characters be
<br />
from Unicode. PUA, combining, whatever. (XML itself additionally
<br />
imposes constraints, e.g. that unescaped "<" and "&" are not
<br />
permitted, but even that's not imposed by the datatype.) If you're
<br />
worried about the constraints in W3C Schema land, who knows what
<br />
rng:string will do? Probably the right thing, I suppose, but still,
<br />
if what you really want is preserved whitespace, why not be explicit
<br />
and use xsd:string?
<br />

<p><em class="quotelev2">> > * tei.data.name: the change is from any string that does not
</em><br />
<em class="quotelev2">> >   contain whitespace (but may include, e.g., punctuation marks,
</em><br />
<em class="quotelev2">> >   currency symbols, math symbols, etc.) to an XML NMTOKEN. I am
</em><br />
<em class="quotelev2">> >   not sure why we'd want to exclude the non-letter, non-digit
</em><br />
<em class="quotelev2">> >   characters (other than .-_:, which are permitted in NMTOKEN).
</em><br />
<em class="quotelev2">> >   Why shouldn't the Tibetan Paluta character be allowed?
</em><br />
<em class="quotelev1">> I assume the latter is not a serious suggestion. I thought the
</em><br />
<em class="quotelev1">> reason was fairly obviously to do with ease of (XML) processing.
</em><br />

It was a 100% completely serious suggestion, and if I may remind you
<br />
Lou, it was *your* suggestion. I'm just sticking with it after you
<br />
have abandoned it.
<br />

What part of XML processing do you think is so much easier to do with
<br />
an attribute that matches xsd:NMTOKEN versus one that permits other
<br />
punctuation characters, etc.?
<br />

<p><em class="quotelev1">> We did discuss this a a bit on the list and nobody came up with a
</em><br />
<em class="quotelev1">> better suggestion. I think using "token" would really be asking for
</em><br />
<em class="quotelev1">> confusion -- precisely because we do mean something different from
</em><br />
<em class="quotelev1">> a datatype which the W3C calls "token" -- whether it's in caps or
</em><br />
<em class="quotelev1">> not. I also considered "ident" and "label". The key thing about it,
</em><br />
<em class="quotelev1">> surely though, is that it is a way of naming something, even if
</em><br />
<em class="quotelev1">> it's not a proper name?
</em><br />

You lost me at the bakery. How are the values of
<br />
  age= of <person> 
<br />
  from= and to= of <locus>
<br />
  value= of <metSym>
<br />
  where= of <move>
<br />
  scope= of <handNote>
<br />
  extent= and reason= of <gap>, <supplied>, and <unclear>
<br />
  loc= of <app>
<br />
naming something? (It does apply in some circumstances, of course,
<br />
e.g. name= of <equiv> or lang= of <code>.) While I agree with you that
<br />
neither "ident" nor "label" will do, I would much prefer to live with
<br />
the mild confusion of "token" than the misleading lie of "name". But
<br />
the suggestion "word" has been put forth, and I think that would be
<br />
fine.
<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 Oct 01 2005 - 01:29:16 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sat Oct  1 12:39:58 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 01 Oct 2005 17:39:58 +0100
Subject: [tei-council] tei.bibl.phrase
Message-ID: <433EBBDE.3000909@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, 01 Oct 2005 17:39:58 +0100</span><br />
</address>

 Syd writes:
<br />

[quote]
<br />
* new class,  tei.biblPhrases containing <title>,  <date>, <dateRange>, 
<br />
and <author>, i.e. things that are members  of both tei.phrase and 
<br />
tei.biblPart,            such that the new class will be a subclass of each.
<br />

Can someone  explain this? Both my notes and JC's notes say this, but it 
<br />
doesn't make sense to me.<title>, <date>, <dateRange>, and <author> are 
<br />
not part of tei.phrase at least not directly (and <author> not at all). 
<br />
Nor are they part of  tei.biblPart.
<br />
 [/Quote]           
<br />

<title> etc. are all members of phrase indirectly -- <title> via 
<br />
hqhrase, <date> and <dateRange> via tei.data. <author> is a member of 
<br />
tei.biblPart.
<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 Oct 01 2005 - 12:40:04 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sat Oct  1 12:53:13 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 1 Oct 2005 12:53:13 -0400
Subject: [tei-council] tei.bibl.phrase
In-Reply-To: <433EBBDE.3000909@computing-services.oxford.ac.uk>
Message-ID: <17214.48889.284076.140683@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, 1 Oct 2005 12:53:13 -0400</span><br />
</address>

| * new class, tei.biblPhrases containing <title>, <date>,
<br />
|   <dateRange>, and <author>, i.e. things that are members of both
<br />
|   tei.phrase and tei.biblPart, such that the new class will be a
<br />
|   subclass of each.
<br />
| 
<br />
| Can someone explain this? Both my notes and JC's notes say this,
<br />
| but it doesn't make sense to me.<title>, <date>, <dateRange>, and
<br />
| <author> are not part of tei.phrase at least not directly (and
<br />
| <author> not at all). Nor are they part of tei.biblPart.
<br />

<em class="quotelev1">> <title> etc. are all members of phrase indirectly -- <title> via 
</em><br />
<em class="quotelev1">> hqhrase, <date> and <dateRange> via tei.data. <author> is a member of 
</em><br />
<em class="quotelev1">> tei.biblPart.
</em><br />

Right, so none of the elements mentioned are in fact in both classes.
<br />
Are there any elements that are a member of both? I don't think we
<br />
have the right criteria for the members of this new class, here.
<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 Oct 01 2005 - 12:53:22 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sat Oct  1 13:06:40 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 01 Oct 2005 18:06:40 +0100
Subject: [tei-council] tei.bibl.phrase
In-Reply-To: <17214.48889.284076.140683@emt.wwp.brown.edu>
Message-ID: <433EC220.2020108@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, 01 Oct 2005 18:06:40 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>| * new class, tei.biblPhrases containing <title>, <date>,
</em><br />
<em class="quotelev1">>|   <dateRange>, and <author>, i.e. things that are members of both
</em><br />
<em class="quotelev1">>|   tei.phrase and tei.biblPart, such that the new class will be a
</em><br />
<em class="quotelev1">>|   subclass of each.
</em><br />
<em class="quotelev1">>| 
</em><br />
<em class="quotelev1">>| Can someone explain this? Both my notes and JC's notes say this,
</em><br />
<em class="quotelev1">>| but it doesn't make sense to me.<title>, <date>, <dateRange>, and
</em><br />
<em class="quotelev1">>| <author> are not part of tei.phrase at least not directly (and
</em><br />
<em class="quotelev1">>| <author> not at all). Nor are they part of tei.biblPart.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>><title> etc. are all members of phrase indirectly -- <title> via 
</em><br />
<em class="quotelev2">>>hqhrase, <date> and <dateRange> via tei.data. <author> is a member of 
</em><br />
<em class="quotelev2">>>tei.biblPart.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Right, so none of the elements mentioned are in fact in both classes.
</em><br />
<em class="quotelev1">>Are there any elements that are a member of both? I don't think we
</em><br />
<em class="quotelev1">>have the right criteria for the members of this new class, here.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

I agree. I think what we wanted to do was identify a new sub-class of 
<br />
phrase containing the components of <bibl> which were not already 
<br />
members of tei.biblPart, factoring them out of the definition of phrase 
<br />
in the process.  <author> doesnt belong in the list at all, since it's a 
<br />
member of tei.biblPart.
<br />

The issue now becomes whether a reference to tei.phrase.bibl  would make 
<br />
sense wherever we currently have a reference to either tei.hqphrase or 
<br />
tei.data
<br />

If it wouldnt, and if we want to retain those class memberships for 
<br />
<title>, <date>, <dateRange> then there is no point in defining this new 
<br />
class.
<br />

<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> Sat Oct 01 2005 - 13:06:43 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sat Oct  1 13:24:52 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 01 Oct 2005 18:24:52 +0100
Subject: [tei-council] tei.bibl.phrase
In-Reply-To: <433EC220.2020108@computing-services.oxford.ac.uk>
Message-ID: <433EC664.2000809@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, 01 Oct 2005 18:24:52 +0100</span><br />
</address>

No, I've got it now!
<br />

tei.phrase.bibl is needed: it should be a subclass of  tei.biblPart. It 
<br />
contains those elements which are members of tei.phrase (indirectly) and 
<br />
not currently members of tei.biblPart.  Once it exists we can rewrite 
<br />
the content of bibl as tei.biblPart*, thus removing all sorts of silly 
<br />
phrase elements from bibl.
<br />

james's notes make this a lot clearer than either mine or syd's...
<br />

<p><p>Lou Burnard wrote:
<br />

<em class="quotelev1">> Syd Bauman wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> | * new class, tei.biblPhrases containing <title>, <date>,
</em><br />
<em class="quotelev2">>> |   <dateRange>, and <author>, i.e. things that are members of both
</em><br />
<em class="quotelev2">>> |   tei.phrase and tei.biblPart, such that the new class will be a
</em><br />
<em class="quotelev2">>> |   subclass of each.
</em><br />
<em class="quotelev2">>> | | Can someone explain this? Both my notes and JC's notes say this,
</em><br />
<em class="quotelev2">>> | but it doesn't make sense to me.<title>, <date>, <dateRange>, and
</em><br />
<em class="quotelev2">>> | <author> are not part of tei.phrase at least not directly (and
</em><br />
<em class="quotelev2">>> | <author> not at all). Nor are they part of tei.biblPart.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev3">>>> <title> etc. are all members of phrase indirectly -- <title> via 
</em><br />
<em class="quotelev3">>>> hqhrase, <date> and <dateRange> via tei.data. <author> is a member 
</em><br />
<em class="quotelev3">>>> of tei.biblPart.
</em><br />
<em class="quotelev3">>>>   
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> Right, so none of the elements mentioned are in fact in both classes.
</em><br />
<em class="quotelev2">>> Are there any elements that are a member of both? I don't think we
</em><br />
<em class="quotelev2">>> have the right criteria for the members of this new class, here.
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I agree. I think what we wanted to do was identify a new sub-class of 
</em><br />
<em class="quotelev1">> phrase containing the components of <bibl> which were not already 
</em><br />
<em class="quotelev1">> members of tei.biblPart, factoring them out of the definition of 
</em><br />
<em class="quotelev1">> phrase in the process.  <author> doesnt belong in the list at all, 
</em><br />
<em class="quotelev1">> since it's a member of tei.biblPart.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> The issue now becomes whether a reference to tei.phrase.bibl  would 
</em><br />
<em class="quotelev1">> make sense wherever we currently have a reference to either 
</em><br />
<em class="quotelev1">> tei.hqphrase or tei.data
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> If it wouldnt, and if we want to retain those class memberships for 
</em><br />
<em class="quotelev1">> <title>, <date>, <dateRange> then there is no point in defining this 
</em><br />
<em class="quotelev1">> new class.
</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.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 />

_______________________________________________
<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 Oct 01 2005 - 13:25:04 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sat Oct  1 13:37:56 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 1 Oct 2005 13:37:56 -0400
Subject: [tei-council] tei.bibl.phrase
In-Reply-To: <433EC220.2020108@computing-services.oxford.ac.uk>
Message-ID: <17214.51572.625770.634726@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, 1 Oct 2005 13:37:56 -0400</span><br />
</address>

<em class="quotelev1">> I think what we wanted to do was identify a new sub-class of phrase
</em><br />
<em class="quotelev1">> containing the components of <bibl> which were not already members
</em><br />
<em class="quotelev1">> of tei.biblPart, factoring them out of the definition of phrase in
</em><br />
<em class="quotelev1">> the process. <author> doesnt belong in the list at all, since it's
</em><br />
<em class="quotelev1">> a member of tei.biblPart.
</em><br />

That makes more sense!
<br />

<p><em class="quotelev1">> The issue now becomes whether a reference to tei.phrase.bibl would
</em><br />
<em class="quotelev1">> make sense wherever we currently have a reference to either
</em><br />
<em class="quotelev1">> tei.hqphrase or tei.data
</em><br />

A quick 'grep' says that tei.hqphrase and tei.data are each only
<br />
referenced once, by tei.phrase. A reference to tei.phrase.bibl would
<br />
obviously be part of tei.phrase.
<br />

Semantically, tei.bibl.phrase makes a lot of sense. I'm not sure
<br />
there would be any practical difference at all.
<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 Oct 01 2005 - 13:38:06 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sat Oct  1 14:05:24 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 01 Oct 2005 19:05:24 +0100
Subject: [tei-council] tei.metrical.components
Message-ID: <433ECFE4.6060506@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, 01 Oct 2005 19:05:24 +0100</span><br />
</address>

"We  never decided whether [tei.model.metrical] class contains only <l> 
<br />
or both <l> and <lg>. JC's notes say <l>, mine say undecided ... and 
<br />
LB's say <q>contains <l> or <lg>, except that Laurent  doesnt like the 
<br />
recursion</q>"
<br />

Can we have a decision please?
<br />

If Laurent's arguments are persuasive, may I suggest that we should 
<br />
define three classes:
<br />

tei.model.metrical.terminal (member <l>)
<br />
tei.model.metrical.nonterminal (member <lg>)
<br />
tei.model.metrical (members 
<br />
tei.model.metrical.terminal|tei.model.nonterminal)
<br />

{Probably not those names tho...}
<br />

p.s. I see Syd is using <q> where he should be using <quote>  -- or 
<br />
should he? :-)
<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> Sat Oct 01 2005 - 14:05:28 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sat Oct  1 14:13:31 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 01 Oct 2005 19:13:31 +0100
Subject: [tei-council] winkling out the incls
Message-ID: <433ED1CB.5050505@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, 01 Oct 2005 19:13:31 +0100</span><br />
</address>

We decided to winkle all reference to tei.incl out of the header 
<br />
elements, and (I think) also out of tei.bibl class elements. so that 
<br />
means it shouldn't appear inside <respStmt> right?
<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 Oct 01 2005 - 14:13:42 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sat Oct  1 14:41:48 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 01 Oct 2005 19:41:48 +0100
Subject: [tei-council] tei.metrical.components
In-Reply-To: <433ECFE4.6060506@computing-services.oxford.ac.uk>
Message-ID: <433ED86C.2080303@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, 01 Oct 2005 19:41:48 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">> "We  never decided whether [tei.model.metrical] class contains only
</em><br />
<em class="quotelev1">> <l> or both <l> and <lg>. JC's notes say <l>, mine say undecided ...
</em><br />
<em class="quotelev1">> and LB's say <q>contains <l> or <lg>, except that Laurent  doesnt like
</em><br />
<em class="quotelev1">> the recursion</q>"
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Can we have a decision please?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> If Laurent's arguments are persuasive
</em><br />

DO we know how many recursive classes we have already? If none, then
<br />
dont start now. If many,
<br />
then proceed on this one. If one or two, can they be zapped too?
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sat Oct 01 2005 - 14:41:57 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sat Oct  1 15:12:50 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 1 Oct 2005 15:12:50 -0400
Subject: [tei-council] winkling out the incls
In-Reply-To: <433ED1CB.5050505@computing-services.oxford.ac.uk>
Message-ID: <17214.57266.821652.825343@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, 1 Oct 2005 15:12:50 -0400</span><br />
</address>

<em class="quotelev1">> We decided to winkle all reference to tei.incl out of the header
</em><br />
<em class="quotelev1">> elements, and (I think) also out of tei.bibl class elements. so
</em><br />
<em class="quotelev1">> that means it shouldn't appear inside <respStmt> right?
</em><br />

Yes. Although <respStmt> occurs outside of <teiHeader> (and thus
<br />
would make you think it needs tei.incl), it only occurs in other
<br />
things that are structured: <biblStruct> and <msItemStruct>.
<br />

So the end content model for <respStmt> should read 
<br />

  ( ( tei.agent, resp ) | ( resp, tei.agent ) ), ( tei.agent | resp )* 
<br />

which I agree just sucks, but if we want to continue to support DTDs
<br />
we can't use the far superior
<br />

<br />
  (
<br />
    ( tei.agent, resp+ ) | ( tei.agent+, resp ) |    
<br />
    ( resp, tei.agent+ ) | ( resp+, tei.agent )
<br />
  )
<br />

as it would be non-deterministic.
<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 Oct 01 2005 - 15:13:00 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sat Oct  1 16:01:16 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 1 Oct 2005 16:01:16 -0400
Subject: [tei-council] tei.metrical.components
In-Reply-To: <433ECFE4.6060506@computing-services.oxford.ac.uk>
Message-ID: <17214.60172.622894.702423@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, 1 Oct 2005 16:01:16 -0400</span><br />
</address>

<em class="quotelev1">> If Laurent's arguments are persuasive, may I suggest that we should
</em><br />
<em class="quotelev1">> define three classes:
</em><br />
<em class="quotelev1">>  tei.model.metrical.terminal (member <l>)
</em><br />
<em class="quotelev1">>  tei.model.metrical.nonterminal (member <lg>)
</em><br />
<em class="quotelev1">>  tei.model.metrical (members tei.model.metrical.terminal|tei.model.nonterminal)
</em><br />

I think this is fine, although I think Laurent may argue that <lg>
<br />
should not be in a class, but rather should appear directly in its
<br />
own content model.
<br />

<p><em class="quotelev1">> p.s. I see Syd is using <q> where he should be using <quote> -- or
</em><br />
<em class="quotelev1">> should he? :-)
</em><br />

Yes, because TEI Lite doesn't have <quote>!
<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 Oct 01 2005 - 16:01:26 EDT</span>
</div>

From Laurent.Romary at loria.fr  Sun Oct  2 09:46:25 2005
From: Laurent.Romary at loria.fr (Laurent.Romary_at_loria.fr)
Date: Sun,  2 Oct 2005 15:46:25 +0200
Subject: [tei-council] tei.metrical.components
In-Reply-To: <433ECFE4.6060506@computing-services.oxford.ac.uk>
Message-ID: <1128260785.433fe4b1e249c@www.loria.fr>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: <Laurent.Romary_at_loria.fr>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun,  2 Oct 2005 15:46:25 +0200</span><br />
</address>

I was close to be convinced that <l> and <lg> are very simetrical with regards
<br />
the kind of information that may be attached to them. I am thus ready to see
<br />
them in the same class (althought I keep my general feeling concerning
<br />
recursion).
<br />
Laurent
<br />

Selon Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk>:
<br />

<em class="quotelev1">> "We  never decided whether [tei.model.metrical] class contains only <l>
</em><br />
<em class="quotelev1">> or both <l> and <lg>. JC's notes say <l>, mine say undecided ... and
</em><br />
<em class="quotelev1">> LB's say <q>contains <l> or <lg>, except that Laurent  doesnt like the
</em><br />
<em class="quotelev1">> recursion</q>"
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Can we have a decision please?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> If Laurent's arguments are persuasive, may I suggest that we should
</em><br />
<em class="quotelev1">> define three classes:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> tei.model.metrical.terminal (member <l>)
</em><br />
<em class="quotelev1">> tei.model.metrical.nonterminal (member <lg>)
</em><br />
<em class="quotelev1">> tei.model.metrical (members
</em><br />
<em class="quotelev1">> tei.model.metrical.terminal|tei.model.nonterminal)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> {Probably not those names tho...}
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> p.s. I see Syd is using <q> where he should be using <quote>  -- or
</em><br />
<em class="quotelev1">> should he? :-)
</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><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 Oct 02 2005 - 09:46:42 EDT</span>
</div>

From Laurent.Romary at loria.fr  Sun Oct  2 09:47:16 2005
From: Laurent.Romary at loria.fr (Laurent.Romary_at_loria.fr)
Date: Sun,  2 Oct 2005 15:47:16 +0200
Subject: [tei-council] winkling out the incls
In-Reply-To: <433ED1CB.5050505@computing-services.oxford.ac.uk>
Message-ID: <1128260836.433fe4e4c10f0@www.loria.fr>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: <Laurent.Romary_at_loria.fr>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun,  2 Oct 2005 15:47:16 +0200</span><br />
</address>

I agree with this!
<br />
Laurent
<br />

Selon Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk>:
<br />

<em class="quotelev1">> We decided to winkle all reference to tei.incl out of the header
</em><br />
<em class="quotelev1">> elements, and (I think) also out of tei.bibl class elements. so that
</em><br />
<em class="quotelev1">> means it shouldn't appear inside <respStmt> right?
</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.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><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 Oct 02 2005 - 09:47:19 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Oct  2 16:56:58 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 2 Oct 2005 16:56:58 -0400 (EDT)
Subject: [tei-council] processing TEI times
Message-ID: <200510022056.j92KuweE024880@pyxis.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, 2 Oct 2005 16:56:58 -0400 (EDT)</span><br />
</address>

2005-09-22T11:27+01, Sebastian said:
<br />
<em class="quotelev1">> On dates/times again, one should bear in mind that XML processors
</em><br />
<em class="quotelev1">> may start using datatype information. At the moment, the only thing
</em><br />
<em class="quotelev1">> where it matters is in validation; but in the world of W3C Schema
</em><br />
<em class="quotelev1">> and XSLT2, the processing application can say "what basic datatype
</em><br />
<em class="quotelev1">> did you work out for this attribute". So if our schema said
</em><br />
<em class="quotelev1">> "xsd:dateTime | long-regexp-allowing:13:15as-a-time", then the
</em><br />
<em class="quotelev1">> processor might take different actions depending on whether you did
</em><br />
<em class="quotelev1">> 13:15 or 13:15:00.
</em><br />
<em class="quotelev1">> It is not easy to think through whether this matters or not.
</em><br />

2005-09-22T16:31+01, Sebastian said:
<br />
<em class="quotelev1">> you may one day wish to do a proper sort of TEI-encoded elements
</em><br />
<em class="quotelev1">> according to their date. If they emerge into the PSVI as having
</em><br />
<em class="quotelev1">> matched a regexp, you'll be at a disadvantage.
</em><br />

<p>I've decided that I (partially) agree with Sebastian. I still believe
<br />
whole heartedly that it is incredibly important to be able to record
<br />
times that are less precise than to the second, and I still believe
<br />
that permitting the value= attribute to directly reflect this reduced
<br />
precision is the right way to do this. However, after poking around a
<br />
bit I've concluded that it *is* quite possible, if not likely, that
<br />
users will run up against software that handles times precise to the
<br />
second just fine, but barfs on less precise times.
<br />

Thus, I've written a stylesheet for converting a TEI P5 document with
<br />
<time> and <date> elements that have reduced precision times on value=
<br />
to a similar document with (falsely) precise times. Actually, I've
<br />
written two: one for XSLT 1.0 and one for XSLT 2.0 processors. These
<br />
stylesheets can be found on the TEI wiki:
<br />
  http://www.tei-c.org/wiki/index.php/InsertFalsePrecision1.xsl
<br />
  http://www.tei-c.org/wiki/index.php/InsertFalsePrecision2.xsl
<br />

Lastly, I've updated the pattern in tei.data.temporal to accept times
<br />
precise to only the hour, and imprecise times that also have dates.
<br />
Furthermore I've updated the pattern to allow only W3C-legal timezone
<br />
designators.
<br />

Because the pattern has gotten quite unwieldy, I've also written a
<br />
tiny test schema and test file for it. The test schema includes
<br />
annotations to explain the sub-patterns. They can be found at
<br />
   http://www.tei-c.org/Council/test_time_pattern.rng
<br />
   http://www.tei-c.org/Council/test_time_pattern.rnc
<br />
   http://www.tei-c.org/Council/test_time_pattern.xml
<br />
In order to make it easier for a Council member to read the
<br />
annotations, I've put them up separately at 
<br />
   http://bauman.zapto.org/~syd/ttpe.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> Sun Oct 02 2005 - 16:57:02 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Oct  2 18:23:50 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 02 Oct 2005 23:23:50 +0100
Subject: [tei-council] processing TEI times
In-Reply-To: <200510022056.j92KuweE024880@pyxis.services.brown.edu>
Message-ID: <43405DF6.5020902@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, 02 Oct 2005 23:23:50 +0100</span><br />
</address>

good god!
<br />

     <rng:data type="token">
<br />
        <rng:param
<br />
name="pattern">(-?\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01
<br />
])T)?([01][0-9]|2[0-3])(:[0-5][0-9])?(Z|[+\-]((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?
<br />
</rng:param>
<br />
      </rng:data>
<br />

Really, I don't think this is wise. Define a separate datatype
<br />
for "isodateformat", and let people change to that if they want.
<br />
Add an extra attribute called "@isodate" or something.
<br />
But adding "oh and practically anything else" at the end of a list of
<br />
datatypes from an external source just does not seem right.
<br />

What do others think?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Oct 02 2005 - 18:23:58 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Oct  2 18:35:52 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 2 Oct 2005 18:35:52 -0400
Subject: [tei-council] processing TEI times
In-Reply-To: <43405DF6.5020902@oucs.ox.ac.uk>
Message-ID: <17216.24776.606950.737362@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, 2 Oct 2005 18:35:52 -0400</span><br />
</address>

<em class="quotelev1">> Really, I don't think this is wise. Define a separate datatype for
</em><br />
<em class="quotelev1">> "isodateformat", and let people change to that if they want. Add an
</em><br />
<em class="quotelev1">> extra attribute called "@isodate" or something. But adding "oh and
</em><br />
<em class="quotelev1">> practically anything else" at the end of a list of datatypes from
</em><br />
<em class="quotelev1">> an external source just does not seem right.
</em><br />

What do you mean "practically anything else"? It permits almost
<br />
nothing else, except the same things that xsd:dateTime and xsd:time
<br />
permit, with a precision truncated to hours or seconds.
<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 Oct 02 2005 - 18:36:01 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Oct  2 18:43:21 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 2 Oct 2005 18:43:21 -0400
Subject: [tei-council] processing TEI times
In-Reply-To: <17216.24776.606950.737362@emt.wwp.brown.edu>
Message-ID: <17216.25225.744175.738706@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, 2 Oct 2005 18:43:21 -0400</span><br />
</address>

[Sorry, hit "send" too soon :-]
<br />

In fact, the reason the pattern looks so complicated is precisely to
<br />
address what I thought was your previous concern of "practically
<br />
anything else". The pattern originally proposed was more permissive
<br />
than W3C in a variety of ways (e.g., permitting "+15:00" as a time
<br />
zone designator) that this pattern deliberately avoids.
<br />

In fact, this pattern is a teeny bit more restrictive than the W3C,
<br />
in that it forbids an hour of "24" (which W3C allows, but not in a
<br />
canonical representation).
<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 Oct 02 2005 - 18:43:31 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Oct  2 19:25:36 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 2 Oct 2005 19:25:36 -0400
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <43305155.6090705@computing-services.oxford.ac.uk>
Message-ID: <17216.27760.643405.50247@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, 2 Oct 2005 19:25:36 -0400</span><br />
</address>

Lou Burnard writes:
<br />

<em class="quotelev3">> >>1. add_at_place 
</em><br />
<em class="quotelev3">> >>   addSpan_at_place
</em><br />
<em class="quotelev3">> >>           -->  tei.data.enumerated
</em><br />
<em class="quotelev2">> >What do you propose the value list be? The list{} method proposed
</em><br />
<em class="quotelev2">> >permits things like "opposite top left" (which is also permitted in
</em><br />
<em class="quotelev2">> >P4). 
</em><br />
<em class="quotelev1">> I have no particular proposal. Any list I came up with only be
</em><br />
<em class="quotelev1">> advisory anyway.
</em><br />

The point I was trying to make is that if we want to mimic the P4
<br />
recommendations we will find it very hard to use tei.data.enumerated.
<br />
If we don't want to mimic the syntax P4 used, fine, but it will be
<br />
awfully hard to come up with a system that permits the various
<br />
combinations P4 allowed. I'll wonder aloud if it would be difficult
<br />
to add the capability to <valList> to permit one or more, rather than
<br />
just one, from the list.
<br />

<p><em class="quotelev2">> > [ met/real/rhyme list for type= of <metDecl> ]
</em><br />
<em class="quotelev1">> so here;s a case where an enumeration is both possible and
</em><br />
<em class="quotelev1">> desirable. good!
</em><br />

Yes, but it doesn't scale well at all.
<br />

<p><em class="quotelev3">> >>2. tei.pointerGroup_at_domains  
</em><br />
<em class="quotelev3">> >>          -->  tei.data.pointers
</em><br />
<em class="quotelev2">> >I don't really see it as a plus to permit values that the prose says
</em><br />
<em class="quotelev2">> >are invalid just to say we used a datatype directly. The EDW90
</em><br />
<em class="quotelev2">> >recommendation matches the prose perfectly. (It is
</em><br />
<em class="quotelev2">> >  list { tei.data.pointer, tei.data.pointers }
</em><br />
<em class="quotelev2">> >.)
</em><br />
<em class="quotelev2">> >On the other hand, ... [could use Schematron]
</em><br />
<em class="quotelev1">> Actually, I wonder if it might not be better to rethink this
</em><br />
<em class="quotelev1">> attribute into two?
</em><br />

I don't follow you. I really don't like how this attribute and its
<br />
cousins targType= and targets= work, so I'm all ears if you have a
<br />
different recommendation.
<br />

<p><em class="quotelev3">> >>3. schemaSpec_at_start
</em><br />
<em class="quotelev3">> >>    specDesc_at_atts   
</em><br />
<em class="quotelev3">> >>         --> tei.data.names
</em><br />
<em class="quotelev2">> >Again, why use a lax constraint when the proper one is readily
</em><br />
<em class="quotelev2">> >available just to say you used a datatype? ...
</em><br />
<em class="quotelev1">> Is this another instance of the particular problem that we;re using
</em><br />
<em class="quotelev1">> "name" sometimes to mean a NMTOKEN and sometimes not?
</em><br />

I don't see how. And I don't think I've ever used "name" to mean
<br />
NMTOKEN (or NCName or Name, for that matter).
<br />

<p><em class="quotelev3">> >>4. date_at_precision
</em><br />
<em class="quotelev3">> >>       --> tei.data.certainty
</em><br />
<em class="quotelev2">> > ...
</em><br />
<em class="quotelev1">> I can't remember who suggested having "precision" as an explicit
</em><br />
<em class="quotelev1">> attribute on date. It does seem to overlap with the value
</em><br />
<em class="quotelev1">> attribute. Unless anyone wants to fight to the death for it, I
</em><br />
<em class="quotelev1">> propose we remove it.
</em><br />

Fight to the death? I wouldn't even trade a stale slice of bread for
<br />
it. Until someone sits down and really thinks through representations
<br />
of precision, accuracy, and certainty, I think we should nuke it.
<br />

<p><em class="quotelev3">> >>9.   tei.declarable_at_default
</em><br />
<em class="quotelev3">> >>     tei.identifiable_at_predeclare
</em><br />
<em class="quotelev3">> >>     metSym_at_terminal
</em><br />
<em class="quotelev3">> >>     numeric_at_trunc
</em><br />
<em class="quotelev3">> >>     binary_at_value                  
</em><br />
<em class="quotelev3">> >>        --> are all xsd:boolean (so "unknown" not allowed) ;
</em><br />
<em class="quotelev3">> >>could just be tei.data.truthValue with extra rule
</em><br />
<em class="quotelev2">> >
</em><br />
<em class="quotelev2">> >Could be. And at one point in the history of that EDW90 table,
</em><br />
<em class="quotelev2">> >they were. But a week or two ago we agreed to go directly with
</em><br />
<em class="quotelev2">> >xsd:boolean.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> So we either have to have a pair of datatypes, one permitting
</em><br />
<em class="quotelev1">> "unknown" and one not, or we have to have an additional rule to
</em><br />
<em class="quotelev1">> exclude "unknown" in cases where it makes no sense, like these.
</em><br />

Or we could use "tei.data.truthValue" for attribute values for which
<br />
"true", "false", and "unknown" all make sense, and "xsd:boolean"
<br />
directly for the above, where only "true" and "false" make sense. As
<br />
was pointed out before, if you need TEI prose to explain what 'true'
<br />
and 'false' mean, you probably shouldn't be encoding texts anyway.
<br />

<p><em class="quotelev3">> >>10.  timeline_at_interval
</em><br />
<em class="quotelev3">> >>       when_at_interval   
</em><br />
<em class="quotelev3">> >>       --> tei.data.numeric | -1  (or think of a better way of
</em><br />
<em class="quotelev3">> >>           doing the -1)
</em><br />
<em class="quotelev2">> >
</em><br />
<em class="quotelev2">> >a) We'd go back to needing unit= (I'm not saying this is so horrible,
</em><br />
<em class="quotelev2">> >   just want to make sure everyone understands the implications) ...
</em><br />
<em class="quotelev2">> > ...
</em><br />
<em class="quotelev2">> >Thus, I am now leaning towards
</em><br />
<em class="quotelev2">> >   xsd:long { minInclusive = "0" }  |  xsd:token "unknown"
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> where did the "unknown" come from? I think it shd remain
</em><br />
<em class="quotelev1">> tei.data.numeric, but with the constraint that it can't be smaller
</em><br />
<em class="quotelev1">> than -1
</em><br />

My apologies, I thought it was clear. In P4 an interval is either
<br />
a) a positive number which, when combined with the value of units=,
<br />
   gives you the interval; or
<br />
b) the special value '0' meaning that all the intervals are evenly
<br />
   spaced, but the size of the intervals is not known; or
<br />
c) the special value -1 indicating uncertainty about all the
<br />
   intervals in the timeline
<br />
My proposal above was intended to use "unknown" instead of "-1"; why
<br />
use a funny coded numerical value? It might make perfect sense to use
<br />
another keyword for (b), and use "minExclusive" instead of
<br />
"minInclusive". Yes, that would be better, if we could just come up
<br />
with a good keyword.
<br />

I'm not sure we can actually constrain a TEI datatype as you
<br />
suggested, but if we can and do use 
<br />
   tei.data.numeric { minInclusive = "-1" }
<br />
we end up permitting all sorts of values *between* -1 and 0 for which
<br />
we have no definition. (Many a good elisp program would solve this by
<br />
just using tei.data.numeric, mapping "0" to (b), and any negative
<br />
value at all to (c).)
<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 Oct 02 2005 - 19:25:47 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Oct  3 04:17:06 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 03 Oct 2005 09:17:06 +0100
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <17216.27760.643405.50247@emt.wwp.brown.edu>
Message-ID: <4340E902.7030104@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, 03 Oct 2005 09:17:06 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>If we don't want to mimic the syntax P4 used, fine, but it will be
</em><br />
<em class="quotelev1">>awfully hard to come up with a system that permits the various
</em><br />
<em class="quotelev1">>combinations P4 allowed. I'll wonder aloud if it would be difficult
</em><br />
<em class="quotelev1">>to add the capability to <valList> to permit one or more, rather than
</em><br />
<em class="quotelev1">>just one, from the list.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
how could this work in DTD-land? does it even work in Relax? Obviously,
<br />
if you know the target notation, making valList do it is easy....
<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> Mon Oct 03 2005 - 04:17:20 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Mon Oct  3 09:36:10 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 3 Oct 2005 09:36:10 -0400
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <4340E902.7030104@oucs.ox.ac.uk>
Message-ID: <17217.13258.681138.587896@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, 3 Oct 2005 09:36:10 -0400</span><br />
</address>

<em class="quotelev2">> >If we don't want to mimic the syntax P4 used, fine, but it will be
</em><br />
<em class="quotelev2">> >awfully hard to come up with a system that permits the various
</em><br />
<em class="quotelev2">> >combinations P4 allowed. I'll wonder aloud if it would be
</em><br />
<em class="quotelev2">> >difficult to add the capability to <valList> to permit one or
</em><br />
<em class="quotelev2">> >more, rather than just one, from the list.
</em><br />
<em class="quotelev2">> >
</em><br />
<em class="quotelev1">> how could this work in DTD-land? does it even work in Relax?
</em><br />
<em class="quotelev1">> Obviously, if you know the target notation, making valList do it is
</em><br />
<em class="quotelev1">> easy....
</em><br />

It would not work in DTD-land; never has, never will. As for RelaxNG,
<br />
I don't quite understand the question. I know I can write RelaxNG
<br />
patterns that do this:
<br />

  attribute place { list { ( "inline" | "supralinear" | "infralinear" |
<br />
                           "left" | "right" | "top" | "bottom" |
<br />
                           "opposite" | "verso" | "middle" | "center"
<br />
                           | "margin" )+ }} # or whatever the list of
<br />
                                            # values is
<br />

but whether we can translate a <valList> into such a pattern or not
<br />
... well, I don't see why not, really, but I leave that to your
<br />
expertise.
<br />

<p>At one point in EDW90 I recommended a somewhat more complex pattern
<br />
(list of lists, essentially) that provides additional useful
<br />
constraint, but for which it would be even harder to build a
<br />
general-purpose mechanism, and is probably not worth 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> Mon Oct 03 2005 - 09:36:19 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Oct  3 10:51:44 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 03 Oct 2005 15:51:44 +0100
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <17217.13258.681138.587896@emt.wwp.brown.edu>
Message-ID: <43414580.2080008@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, 03 Oct 2005 15:51:44 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>It would not work in DTD-land; never has, never will. 
</em><br />
<em class="quotelev1">>
</em><br />
I thought one of our baselines was compatibility with DTD
<br />
so far as possible? what would your code degrade into?
<br />

<em class="quotelev1">>As for RelaxNG,
</em><br />
<em class="quotelev1">>I don't quite understand the question. I know I can write RelaxNG
</em><br />
<em class="quotelev1">>patterns that do this:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  attribute place { list { ( "inline" | "supralinear" | "infralinear" |
</em><br />
<em class="quotelev1">>                           "left" | "right" | "top" | "bottom" |
</em><br />
<em class="quotelev1">>                           "opposite" | "verso" | "middle" | "center"
</em><br />
<em class="quotelev1">>                           | "margin" )+ }} # or whatever the list of
</em><br />
<em class="quotelev1">>                                            # values is
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
really? I didn't realize. Fine, that's easy to create from a valList
<br />
if it is so instantiated. You'd have to change the syntax of valList,
<br />
obviously.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Mon Oct 03 2005 - 10:51:50 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Mon Oct  3 11:55:16 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 3 Oct 2005 11:55:16 -0400
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <43414580.2080008@oucs.ox.ac.uk>
Message-ID: <17217.21604.334994.269032@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, 3 Oct 2005 11:55:16 -0400</span><br />
</address>

<em class="quotelev1">> I thought one of our baselines was compatibility with DTD so far as
</em><br />
<em class="quotelev1">> possible? 
</em><br />

Compatibility, yes; equivalent level of constraint, no. We have
<br />
always understood that there are constraints modern schema languages
<br />
can provide that DTDs can't. E.g., DTDs cannot express dates, times,
<br />
numbers, etc., yet we use them to constrain our attribute values.
<br />

<p><em class="quotelev1">> what would your code degrade into?
</em><br />

CDATA, just as we had in P4.
<br />

<p>The much harder question is how will your odd2dtd process recognize
<br />
this as something it cannot translate to DTD-language, and thus needs
<br />
to spit out as CDATA? To that I have no good answer. (How does it do
<br />
this with, say, tei.data.temporal?)
<br />

<p><em class="quotelev1">> really? I didn't realize. Fine, that's easy to create from a
</em><br />
<em class="quotelev1">> valList if it is so instantiated. You'd have to change the syntax
</em><br />
<em class="quotelev1">> of valList, obviously.
</em><br />

So we'd need something like <valList quantity="oneOrMore"> or
<br />
<valList org="list"> 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> Mon Oct 03 2005 - 11:55:25 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Oct  3 12:34:12 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 03 Oct 2005 17:34:12 +0100
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <17217.21604.334994.269032@emt.wwp.brown.edu>
Message-ID: <43415D84.5090005@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, 03 Oct 2005 17:34:12 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>what would your code degrade into?
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>CDATA, just as we had in P4.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
ah yes, of course...
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>The much harder question is how will your odd2dtd process recognize
</em><br />
<em class="quotelev1">>this as something it cannot translate to DTD-language, and thus needs
</em><br />
<em class="quotelev1">>to spit out as CDATA? To that I have no good answer. (How does it do
</em><br />
<em class="quotelev1">>this with, say, tei.data.temporal?)
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
it just translates more or less everything to CDATA :-}
<br />

<em class="quotelev1">>So we'd need something like <valList quantity="oneOrMore"> or
</em><br />
<em class="quotelev1">><valList org="list"> or some such?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
indeed.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Mon Oct 03 2005 - 12:34:20 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Oct  3 16:21:24 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 03 Oct 2005 21:21:24 +0100
Subject: [tei-council] TEI relaxng schemas, pattern names
Message-ID: <434192C4.5040308@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, 03 Oct 2005 21:21:24 +0100</span><br />
</address>

Those of you who read our relaxng schemas for fun will know that
<br />
they are full of patterns like:
<br />

<br />
 div = element div {div.content,div.attributes}
<br />
 div.content =  p+
<br />

Although the _element_ <div> is in a namespace, and protected
<br />
from conflict, the _pattern_ "div" is global. If you merge the TEI
<br />
with another language, and that too defines a pattern "div", it's
<br />
an error.
<br />

To get around this, I have done some experimental
<br />
work on the processing
<br />
and found that I can insert eg "_TEI_" in front of each
<br />
pattern, so that the above would be:
<br />

 _TEI_div = element div {div.content,div.attributes}
<br />
 div.content =  _TEI_p+
<br />

Question: should I make this standard
<br />
for our output? It means the schemas are less legible,
<br />
but makes them more portable.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Mon Oct 03 2005 - 16:21:32 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Oct  3 20:44:03 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 04 Oct 2005 09:44:03 +0900
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <434192C4.5040308@oucs.ox.ac.uk>
Message-ID: <ygfu0fyaz70.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 04 Oct 2005 09:44:03 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk> writes:
<br />

<em class="quotelev1">>  _TEI_div = element div {div.content,div.attributes}
</em><br />
<em class="quotelev1">>  div.content =  _TEI_p+
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Question: should I make this standard
</em><br />
<em class="quotelev1">> for our output? It means the schemas are less legible,
</em><br />
<em class="quotelev1">> but makes them more portable.
</em><br />

I am strongly in favor of this, since, as I understand it will solve
<br />
the problem of intermixing with foreign schemas (e.g. MODS)!?
<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 Oct 03 2005 - 20:44:08 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Mon Oct  3 21:21:38 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 3 Oct 2005 21:21:38 -0400
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <434192C4.5040308@oucs.ox.ac.uk>
Message-ID: <17217.55586.238520.297390@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, 3 Oct 2005 21:21:38 -0400</span><br />
</address>

<em class="quotelev1">>  _TEI_div = element div {div.content,div.attributes}
</em><br />
<em class="quotelev1">>  div.content =  _TEI_p+
</em><br />

Wouldn't that really have to be
<br />

  _TEI_div = element div { _TEI_div.content, _TEI_div.attributes }
<br />
  _TEI_div.content =  _TEI_p+
<br />

(Actually, isn't "div" already a reserved pattern in RelaxNG, like
<br />
"start" or "element"?)
<br />

<p><em class="quotelev1">> Question: should I make this standard for our output? It means the
</em><br />
<em class="quotelev1">> schemas are less legible, but makes them more portable.
</em><br />

I think I'm mildly in favor. I'm not sure it's really all that
<br />
important, and (as someone who does read the schemas quite a bit) I
<br />
can see it being annoying, but other than that it can't hurt, and it
<br />
really might help someone at some point down the road quite a bit.
<br />

However, I think it a good idea that the "_TEI_" (or whatever)
<br />
prefixes *not* show up in the snippets in the Guidelines.
<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 Oct 03 2005 - 21:21:49 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Oct  4 04:13:46 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 04 Oct 2005 09:13:46 +0100
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <17217.55586.238520.297390@emt.wwp.brown.edu>
Message-ID: <434239BA.5070500@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, 04 Oct 2005 09:13:46 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev2">>> _TEI_div = element div {div.content,div.attributes}
</em><br />
<em class="quotelev2">>> div.content =  _TEI_p+
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Wouldn't that really have to be
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  _TEI_div = element div { _TEI_div.content, _TEI_div.attributes }
</em><br />
<em class="quotelev1">>  _TEI_div.content =  _TEI_p+
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>(Actually, isn't "div" already a reserved pattern in RelaxNG, like
</em><br />
<em class="quotelev1">>"start" or "element"?)
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I thought about that. Maybe I'll implement it too.
<br />

<em class="quotelev1">>However, I think it a good idea that the "_TEI_" (or whatever)
</em><br />
<em class="quotelev1">>prefixes *not* show up in the snippets in the Guidelines.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

absolutely!
<br />

I have it as an XSLT parameter, so documentation runs will
<br />
set it to blank.
<br />
sebastian
<br />
_______________________________________________
<br />
tei-council mailing list
<br />
tei-council_at_lists.village.Virginia.EDU
<br />
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
<br />
<span id="received"><dfn>Received on</dfn> Tue Oct 04 2005 - 04:13:59 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Oct  4 04:17:34 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 04 Oct 2005 09:17:34 +0100
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <ygfu0fyaz70.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43423A9E.9000109@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, 04 Oct 2005 09:17:34 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I am strongly in favor of this, since, as I understand it will solve
</em><br />
<em class="quotelev1">>the problem of intermixing with foreign schemas (e.g. MODS)!?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
can you remind me of the details of this, so that
<br />
I can test it?
<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 Oct 04 2005 - 04:17:38 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Oct  4 08:13:56 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 4 Oct 2005 08:13:56 -0400
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <434239BA.5070500@oucs.ox.ac.uk>
Message-ID: <17218.29188.119435.76587@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, 4 Oct 2005 08:13:56 -0400</span><br />
</address>

<em class="quotelev1">> I have it as an XSLT parameter, so documentation runs will set it
</em><br />
<em class="quotelev1">> to blank. 
</em><br />

Oooh ... I think I like that. It means that in my local system, I can
<br />
set it to blank too, and not have to see those ugly prefixes. On the
<br />
other hand, are there any downsides to encouraging inconsistency in
<br />
the pattern names between different users (or even between different
<br />
customizations for the same user)?
<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 Oct 04 2005 - 08:14:04 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Oct  4 08:23:55 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 04 Oct 2005 13:23:55 +0100
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <17218.29188.119435.76587@emt.wwp.brown.edu>
Message-ID: <4342745B.2060501@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, 04 Oct 2005 13:23:55 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev2">>>I have it as an XSLT parameter, so documentation runs will set it
</em><br />
<em class="quotelev2">>>to blank. 
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Oooh ... I think I like that. It means that in my local system, I can
</em><br />
<em class="quotelev1">>set it to blank too, and not have to see those ugly prefixes. On the
</em><br />
<em class="quotelev1">>other hand, are there any downsides to encouraging inconsistency in
</em><br />
<em class="quotelev1">>the pattern names between different users (or even between different
</em><br />
<em class="quotelev1">>customizations for the same user)?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I share the concern. But I don't have an answer...
<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 Oct 04 2005 - 08:24:08 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Oct  4 13:14:16 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 4 Oct 2005 13:14:16 -0400
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43311897.3020303@computing-services.oxford.ac.uk>
Message-ID: <17218.47208.150812.839364@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, 4 Oct 2005 13:14:16 -0400</span><br />
</address>

<em class="quotelev2">> > Yes! That's it in a nutshell. (EDW90 does propose all the W3C
</em><br />
<em class="quotelev2">> > temporal types save duration be included;
</em><br />
<em class="quotelev1">> What was the reasoning for not including duration again?
</em><br />

I don't know that there was any good reasoning. We need to think out 
<br />
  <date>, <time>
<br />
  <dateRange>, <timeRange>
<br />
  <dateStruct>, <timeStruct>
<br />
and the various other uses of tei.data.temporal. It certainly
<br />
wouldn't make sense to use a duration on, e.g., from= and to= of
<br />
<dateRange>. 
<br />

<p><em class="quotelev1">> Let me just confirm this because my head must be off in the clouds,
</em><br />
<em class="quotelev1">> does ISO 8601:2004 say that in order to have a valid time it has to
</em><br />
<em class="quotelev1">> be complete to the second? ... wikipedia ... says:
</em><br />
<em class="quotelev1">> "It is also acceptable to omit elements to reduce precision. hh:mm,
</em><br />
<em class="quotelev1">> hhmm, and hh are all used."
</em><br />
<em class="quotelev1">> ...
</em><br />
<em class="quotelev1">> Now, is the problem with the W3C Schema datatypes and the way they
</em><br />
<em class="quotelev1">> implement the ISO standard? I know there are some variations, but
</em><br />
<em class="quotelev1">> it seems like a pretty major one to insist on 13:14:54 instead of
</em><br />
<em class="quotelev1">> just 13:15.
</em><br />

Yes, you have it right, and I think this question has already been
<br />
answered, but thought it worth repeating: ISO 8601 permits both hh:mm
<br />
and hh, and also hh,hh (fractions of an hour) & hh:mm,mm (fractions
<br />
of a minute). W3C does not permit any of these. I don't think the
<br />
fractional hours or minutes are that important, but others may
<br />
disagree.
<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 Oct 04 2005 - 13:14:26 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Oct  4 15:08:31 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 4 Oct 2005 15:08:31 -0400
Subject: [tei-council] tei.data.blah
In-Reply-To: <43317F10.90700@oucs.ox.ac.uk>
Message-ID: <17218.54063.210430.625047@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, 4 Oct 2005 15:08:31 -0400</span><br />
</address>

LB> I have just noticed that using tei.data.blah as the name for the
<br />
LB> datatype "blah", as recommended in edw90, gives a tiny opporunity
<br />
LB> for confusion if we keep the convention that "tei.blah" is the
<br />
LB> name for the *class* "blah".... especially as we have a class
<br />
LB> called "data"!
<br />

SR> so call them macro.data.blah
<br />

SB> Either is fine with me.
<br />

SR> we could resolve this next week in the class meeting. ...
<br />

Errr... we didn't. Given the new naming conventions we did hammer out,
<br />
though, do we still need to worry about this? "tei.blah" is slated to
<br />
become "tei.model.blah" or perhaps "tei.att.blah", so we've no
<br />
worries, right?
<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 Oct 04 2005 - 15:08:40 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Oct  4 15:38:10 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 04 Oct 2005 20:38:10 +0100
Subject: [tei-council] tei.data.blah
In-Reply-To: <17218.54063.210430.625047@emt.wwp.brown.edu>
Message-ID: <4342DA22.7090302@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, 04 Oct 2005 20:38:10 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>SR> we could resolve this next week in the class meeting. ...
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Errr... we didn't. Given the new naming conventions we did hammer out,
</em><br />
<em class="quotelev1">>though, do we still need to worry about this? "tei.blah" is slated to
</em><br />
<em class="quotelev1">>become "tei.model.blah" or perhaps "tei.att.blah", so we've no
</em><br />
<em class="quotelev1">>worries, right?
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

the pattern tei.date.XXX seems to fit in with our changes,
<br />
so I think we leave well alone.
<br />

Although I think we should drop the "tei." prefix passim
<br />
now. The argument for introducing it (sharing with other
<br />
schemata) is proved not to work, and I have introduced
<br />
a new method which works better (the optional $patternPrefix)
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Oct 04 2005 - 15:38:21 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Oct  4 18:04:51 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 4 Oct 2005 18:04:51 -0400
Subject: [tei-council] tei.data.blah
In-Reply-To: <4342DA22.7090302@oucs.ox.ac.uk>
Message-ID: <17218.64643.109967.995797@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, 4 Oct 2005 18:04:51 -0400</span><br />
</address>

<em class="quotelev1">> Although I think we should drop the "tei." prefix passim now. The
</em><br />
<em class="quotelev1">> argument for introducing it (sharing with other schemata) is proved
</em><br />
<em class="quotelev1">> not to work, and I have introduced a new method which works better
</em><br />
<em class="quotelev1">> (the optional $patternPrefix)
</em><br />

I think I'm in favor.
<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 Oct 04 2005 - 18:05:00 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Oct  4 22:23:55 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 05 Oct 2005 11:23:55 +0900
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <43423A9E.9000109@oucs.ox.ac.uk>
Message-ID: <ygfachobt1g.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 05 Oct 2005 11:23:55 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk> writes:
<br />

<em class="quotelev1">> Christian Wittern wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>I am strongly in favor of this, since, as I understand it will solve
</em><br />
<em class="quotelev2">>>the problem of intermixing with foreign schemas (e.g. MODS)!?
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> can you remind me of the details of this, so that
</em><br />
<em class="quotelev1">> I can test it?
</em><br />

I had a customization which replaces (if I remember correctly) the
<br />
content of biblStruct with a MODS record.  The problem arises, because
<br />
some names defined in MODS (e.g. "name") clash with TEI names.  Do you
<br />
need the files again, or is this good enough?
<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 Oct 04 2005 - 22:24:10 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Oct  4 22:31:29 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 05 Oct 2005 11:31:29 +0900
Subject: [tei-council] Council class meeting notes
Message-ID: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 05 Oct 2005 11:31:29 +0900</span><br />
</address>

Dear Council members,
<br />

As you will be aware, some volunteers from among us (Syd, John, Laurent,
<br />
Lou, Sebastian, James and myself) met in Oxford at the end of
<br />
September to discuss a complete overhaul on classes.  We spent two
<br />
full days and then some of us another morning on this, discussing some
<br />
general principles and then trying to apply them to some modules. The
<br />
notes from this meeting are now at
<br />
http://www.tei-c.org/Council/tcm20.xml?style=printable . I would like
<br />
to encourage all Council members to look at this document and
<br />
familiarize themselve with the content of this document.  One open
<br />
question that needs addressing urgently is the issue of how classes
<br />
are to be named -- we discussed this and the discussion is reflected
<br />
in http://www.tei-c.org/Drafts/edw87.xml?style=printable, but no
<br />
decision, not even a coherent proposal has been reached.
<br />

All the best,
<br />

Christian Wittern
<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 Oct 04 2005 - 22:31:34 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Oct  5 04:17:57 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 05 Oct 2005 09:17:57 +0100
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <ygfachobt1g.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43438C35.1060401@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, 05 Oct 2005 09:17:57 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>I had a customization which replaces (if I remember correctly) the
</em><br />
<em class="quotelev1">>content of biblStruct with a MODS record.  The problem arises, because
</em><br />
<em class="quotelev1">>some names defined in MODS (e.g. "name") clash with TEI names.  Do you
</em><br />
<em class="quotelev1">>need the files again, or is this good enough?
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I have found the MODS schema you sent me. I'll see if I can make it fly
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Oct 05 2005 - 04:18:08 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Wed Oct  5 13:28:45 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 05 Oct 2005 18:28:45 +0100
Subject: The Naming of Classes [was Re: [tei-council] Council class meeting notes]
In-Reply-To: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43440D4D.9040207@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, 05 Oct 2005 18:28:45 +0100</span><br />
</address>

Christian Wittern wrote:
<br />
<em class="quotelev1">>  One open
</em><br />
<em class="quotelev1">> question that needs addressing urgently is the issue of how classes
</em><br />
<em class="quotelev1">> are to be named -- we discussed this and the discussion is reflected
</em><br />
<em class="quotelev1">> in http://www.tei-c.org/Drafts/edw87.xml?style=printable, but no
</em><br />
<em class="quotelev1">> decision, not even a coherent proposal has been reached.
</em><br />
<em class="quotelev1">>
</em><br />

As a step towards this, I have now written a substantial revision of the 
<br />
original edw87, after discussion with Sebastian and James (they however 
<br />
bear responsibility only for not having been able to persuade me not to)
<br />

To facilitate comparison, I have left the original version of edw87 
<br />
unchanged, though it does form the basis of my revision. The rewrite is 
<br />
available from http://www.tei-c.org/Drafts/edw87a.xml
<br />

Comments welcomed-- especially if you think the underlying principles 
<br />
listed at the start of the rewrite are seriously flawed or 
<br />
incomprehensible. The details of the names themselves are less serious 
<br />
-- but if you don't like them, proposals for a better alternative add 
<br />
great weight to your objection.
<br />

Note that the list doesn't yet include any of the new classes proposed 
<br />
in tcm20.
<br />

Lou
<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 Oct 05 2005 - 13:23:13 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Oct  5 15:43:16 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 05 Oct 2005 20:43:16 +0100
Subject: [tei-council] edw87a
Message-ID: <43442CD4.9040105@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, 05 Oct 2005 20:43:16 +0100</span><br />
</address>

As I have said to Lou many times over the past few days, my only
<br />
problem with this scheme is that one man's Like is another man's Part.
<br />
So if I had made that table, it is quite likely that I'd have made
<br />
different decisions on some of the cases.  But I think the advantages
<br />
outweigh the disadvantages, in making it clear to the reader what
<br />
thoughts went through the mind of the Namer.  So I'm happy to commend
<br />
the thing, and suggest that it be Made So.
<br />

I think it's worth stressing that Lou's edw87a is actually following
<br />
the same train of thought as SB/SR/CW/JC last week did when they
<br />
compiled edw87.  So its not a choice between them, really; a finished
<br />
table in edw87 would have had the same problems as edw87a
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Oct 05 2005 - 15:43:21 EDT</span>
</div>

From Julia_Flanders at Brown.edu  Wed Oct  5 17:25:29 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Wed, 5 Oct 2005 17:25:29 -0400
Subject: [tei-council] I18N proposal for review
Message-ID: <a06200727bf69f4a2ad4c@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 5 Oct 2005 17:25:29 -0400</span><br />
</address>

Sebastian, Veronika, and I have completed a pretty-much-final draft 
<br />
of the I18N proposal to ALLC, which is now up at the TEI web site and 
<br />
ready for review at http://www.tei-c.org/I18N/
<br />

Please take a look and let us know of any urgent suggested changes or 
<br />
additions. We'll submit it to ALLC within a week.
<br />

Best wishes, Julia
<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 Oct 05 2005 - 17:25:34 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Wed Oct  5 21:28:12 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 5 Oct 2005 21:28:12 -0400
Subject: The Naming of Classes [was Re: [tei-council] Council class meeting notes]
In-Reply-To: <43440D4D.9040207@oucs.ox.ac.uk>
Message-ID: <17220.32172.734583.802478@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, 5 Oct 2005 21:28:12 -0400</span><br />
</address>

I haven't yet read this carefully, but on quick glance EDW87a looks
<br />
OK to me. A few nit-picks jump to mind (I'd prefer "-like" or
<br />
"Siblings" to "Like"; the prose describing subclasses is twisted;
<br />
EDW79 and EDW86 are no longer good places to look for lists of
<br />
attribute names currently in use), but mostly we need to merge in the
<br />
new classes and address some details.
<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 Oct 05 2005 - 21:28:25 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Oct  5 23:40:16 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 06 Oct 2005 12:40:16 +0900
Subject: [tei-council] I18N proposal for review
In-Reply-To: <a06200727bf69f4a2ad4c@[128.148.157.102]>
Message-ID: <ygfirwbb9en.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 06 Oct 2005 12:40:16 +0900</span><br />
</address>

Julia Flanders <Julia_Flanders_at_Brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev1">> Sebastian, Veronika, and I have completed a pretty-much-final draft of
</em><br />
<em class="quotelev1">> the I18N proposal to ALLC, which is now up at the TEI web site and
</em><br />
<em class="quotelev1">> ready for review at http://www.tei-c.org/I18N/
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Please take a look and let us know of any urgent suggested changes or
</em><br />
<em class="quotelev1">> additions. We'll submit it to ALLC within a week.
</em><br />

I have read through this and can only say this is very good, solid work.
<br />
Needless to say that I am especially happy with the list of proposed
<br />
translations:-)  I really hope that the work can proceed as envisioned.
<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> Wed Oct 05 2005 - 23:40:23 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Oct  6 00:52:58 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 06 Oct 2005 13:52:58 +0900
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <43440D4D.9040207@oucs.ox.ac.uk>
Message-ID: <ygfmzln8cwl.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 06 Oct 2005 13:52:58 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> To facilitate comparison, I have left the original version of edw87
</em><br />
<em class="quotelev1">> unchanged, though it does form the basis of my revision. The rewrite
</em><br />
<em class="quotelev1">> is available from http://www.tei-c.org/Drafts/edw87a.xml
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Comments welcomed-- especially if you think the underlying principles
</em><br />
<em class="quotelev1">> listed at the start of the rewrite are seriously flawed or
</em><br />
<em class="quotelev1">> incomprehensible. The details of the names themselves are less serious
</em><br />
<em class="quotelev1">> -- but if you don't like them, proposals for a better alternative add
</em><br />
<em class="quotelev1">> great weight to your objection.
</em><br />
<em class="quotelev1">>
</em><br />

I don't have really serious objections anymore, although two points
<br />
strike me as unfortunate:  
<br />

For model classes that are populated from modules (like the
<br />
*dictionary* stuff), this can not anymore be guessed from the name.
<br />
Since in practice the knowledge were something comes from is needed to
<br />
write customizations, it would be useful to see this reflected
<br />
somewhat in the naming.
<br />

*Part and *Like are not really clearly distinguishable. And *Like
<br />
really sounds a bit silly.  In what way is chunk pLike? If siblings
<br />
are the criterium, pSiblings would maybe make more sense?
<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> Thu Oct 06 2005 - 00:53:04 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Oct  6 04:48:19 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 06 Oct 2005 09:48:19 +0100
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <ygfmzln8cwl.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <4344E4D3.1000504@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, 06 Oct 2005 09:48:19 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>*Part and *Like are not really clearly distinguishable. And *Like
</em><br />
<em class="quotelev1">>really sounds a bit silly.  In what way is chunk pLike? If siblings
</em><br />
<em class="quotelev1">>are the criterium, pSiblings would maybe make more sense?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
"Siblings" does not really seem right to be. That implies shared parentage.
<br />
a <list> is "Like" a <p> in sort of places it appears, ie at a block level.
<br />

I agree, the word "Like" may not be perfect. But I don't see an obvious 
<br />
alternative
<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> Thu Oct 06 2005 - 04:48:32 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Thu Oct  6 10:57:38 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 6 Oct 2005 10:57:38 -0400
Subject: [tei-council] Datatype : roundup
In-Reply-To: <4332B30A.4060700@computing-services.oxford.ac.uk>
Message-ID: <17221.15202.193503.39940@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, 6 Oct 2005 10:57:38 -0400</span><br />
</address>

SB> I really don't see why not permit percentages. Users had the
<br />
SB> choice in P4, when we couldn't even validate it. Now we can.
<br />

LB> simplicity, clarity, precision...
<br />

SB> While I suppose it is simpler for software writers to have 1
<br />
SB> system rather than 2, there is nothing more clear nor more
<br />
SB> precise about "0.824" than "82.4%". While I have some sympathy
<br />
SB> with the idea of reducing choices for users, this is one place
<br />
SB> where I think users like the choice.
<br />

LB> I see no evidence for this asserttion at all. Since both
<br />
LB> representations mean exactly the same thing, and are exactly
<br />
LB> inter-convertible, I think it just looks silly not to come down
<br />
LB> on one side of the fence or the other.
<br />

If we ask a random sampling of 50-200 TEI users whether they'd prefer
<br />
to always use decimal representation (whether xsd:decimal or
<br />
xsd:double) like "0.824" or always use percentages like "8.24%", I'll
<br />
buy you a beer if > 0.80 of them all agree on one or the other.
<br />

<p>LB> I think this is a mistake, actually. Decimal was a better choice,
<br />
LB> since it can represent any number, real or integer, no matter how
<br />
LB> big. It means you can;t use scientific notation, which someone
<br />
LB> folks on TEI-L suddenly woke up and asked for.
<br />

SB> So you think we have more users who really want to represent
<br />
SB> numbers with greater than 16 (decimal) digits of precision than
<br />
SB> users who want to represent numbers in scientific notation? As I
<br />
SB> had hoped my example would demonstrate, that much precision is
<br />
SB> not something we humans generally deal with.
<br />

LB> No, I think that if there are 10 people in the world who want to
<br />
LB> use a numeric datatype, 8 of them might want to use what one
<br />
LB> might call unscientific notation, and 9.9 of them will want to
<br />
LB> represent values representable to an accuracy less than 8 decimal
<br />
LB> digits!
<br />

That seems like a pretty strong argument in favor of using
<br />
xsd:double! If 20% of people in the world want to use scientific
<br />
notation, but only 1% want > 8 places of precision, let alone > 16
<br />
places of precision, we should most certainly use xsd:double, not
<br />
xsd:decimal. I'd much prefer to tell the far less than 1% that they
<br />
can't represent their *huge* numbers precisely than to tell the 20%
<br />
they can't represent their numbers with scientific notation.
<br />

My point is this: even in the hard sciences, representation of any
<br />
number to > 16 digits of precision is almost unheard of.
<br />
Representation of numbers that are extremely unwieldy using decimal
<br />
notation (which is, after all, why scientific notation was invented)
<br />
is quite common.
<br />

* the speed of light is defined by CGPM to only 9 digits of
<br />
  precision, according to Wikipedia. Most of us would probably prefer
<br />
    <measure quantity="3e8" unit="cm/s">C</measure>
<br />
  to
<br />
    <measure quantity="300000000" unit="m/s">C</measure>
<br />
  or the more precise
<br />
    <measure quantity="299792458" unit="m/s">C</measure>
<br />
  or
<br />
    <measure quantity="1.08e9" unit="km/h">C</measure>
<br />
  to
<br />
    <measure quantity="1080000000" unit="km/h">C</measure>
<br />
  or the more precise
<br />
    <measure quantity="1079252849" unit="kn/h">C</measure>
<br />
  but any of these is perfectly OK if quantity is an xsd:double.
<br />

* Avogadro's number is usually described as roughly 6.022e23. Can you
<br />
  imagine needing to express this as <num
<br />
  value="602214199000000000000000">? Kind of defeats the purpose,
<br />
  especially when there's really no solid agreement on what the
<br />
  number *is* past that first "1".
<br />

* If I understand correctly, the computers NASA used to send men to
<br />
  the moon had "double precision" capability, but these instructions
<br />
  used two 16-bit registers, i.e., roughly the same precision as
<br />
  today's xsd:int and xsd:float.
<br />

BTW, the one obvious reason to want to use xsd:decimal (whether we
<br />
use xsd:double alone as I'm now advocating, or xsd:double|xsd:long,
<br />
which I'd be perfectly happy with, too) are encoding books of
<br />
mathematical tables and tables of physical constants and the like.
<br />

I just skimmed through my copy of CRC Standard Mathematical Tables,
<br />
and found
<br />
 - tens, perhaps hundreds of pages of things to 5 & 6 places
<br />
 - a few pages of things to 8 places
<br />
 - one large multi-page table to 9 places (compound interest --
<br />
   I wonder what that tells us! :-)
<br />
 - one entry (the number of seconds per radian) to 11 places
<br />
 - only 3 tables that would require > 16 digits precision:
<br />
   sums of reciprocal powers, Bernoulli numbers, and Euler numbers.
<br />
   (Anyone remember what those things are? I sure don't :-)
<br />

<p>LB> I now think maybe we should have a different datatype for
<br />
LB> [scientific notation].
<br />

SB> If we split scientific notation out to a different datatype, won't we
<br />
SB> need a disjunction of the two datatypes in most if not all instances
<br />
SB> anyway? And the disjunction (whether of two separate TEI datatypes or
<br />
SB> of two xsd: datatypes inside a TEI datatype) might be a bit confusing
<br />
SB> for implementers. But it shouldn't be impossible to deal with (could
<br />
SB> always just assume that if it's not in scientific notation, it is an
<br />
SB> xsd:decimal).
<br />

LB> I dont think that sort of "assumption" is something an XML
<br />
LB> validator can do, is it? 
<br />

True, but the validator doesn't have to do any such thing. It just
<br />
has to say "yes, this thing is a valid xsd:decimal OR a valid
<br />
xsd:double". Other processes will have to actually figure out what
<br />
the value *means*, e.g. to sort by it, or generate a scaled value of
<br />
it for use in an SVG or whatever.
<br />

<p>LB> But we could certainly say the numeric datatype maps onto
<br />
LB> xsd:decimal|xsd:float if that would make you happy.
<br />

[I presume you mean "xsd:double" -- we haven't considered xsd:float,
<br />
and I see no reason why we should.]
<br />

I think the worst that could happen in this case is some developers
<br />
curse us for having been so cavalier with their time and effort.
<br />
Fine, let's go with 
<br />
   data.numeric = xsd:decimal | xsd:double
<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 Oct 06 2005 - 10:57:52 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Thu Oct  6 13:19:42 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 06 Oct 2005 18:19:42 +0100
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <ygfmzln8cwl.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43455CAE.9050706@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, 06 Oct 2005 18:19:42 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> For model classes that are populated from modules (like the
</em><br />
<em class="quotelev1">> *dictionary* stuff), this can not anymore be guessed from the name.
</em><br />
<em class="quotelev1">> Since in practice the knowledge were something comes from is needed to
</em><br />
<em class="quotelev1">> write customizations, it would be useful to see this reflected
</em><br />
<em class="quotelev1">> somewhat in the naming.
</em><br />

I agree with this objective: I tried to do this to some extent by using 
<br />
"entry" as the prototype name, since one always talks about dictionary 
<br />
entries. But I agree that more attention is needed here. The dictionary 
<br />
chapter is the one which uses classes most heavily at present, and I 
<br />
need to study the way it does so a bit more carefully.
<br />

<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> *Part and *Like are not really clearly distinguishable. And *Like
</em><br />
<em class="quotelev1">> really sounds a bit silly.  In what way is chunk pLike? If siblings
</em><br />
<em class="quotelev1">> are the criterium, pSiblings would maybe make more sense?
</em><br />
<em class="quotelev1">> 
</em><br />

<p>I am sorry if the two are not distinguishable, since the distinction is 
<br />
really rather critical! "chunk" is "pLike" in the sense that its members 
<br />
are "like" ps -- they occur at the same hierarchic level as p  and they 
<br />
are semantically associated. I agree that this is a bit of a stretch for 
<br />
  "chunk" though, since the members of that class really have nothing in 
<br />
common except for their hierarchic position. I hope you agree that the 
<br />
distinction works better with e.g. bibLike and bibPart.
<br />

I didn't choose "sibling" because it seemed to me that many xLike class 
<br />
members would have siblings which were *not* xLike. For example hiLike 
<br />
things are not really dateLike, but they are both siblings (and both 
<br />
"pPart"s!). But I've no quarrel with changing "like" to "sib". (It would 
<br />
get rid of my all time favourite which no-one has yet commented 
<br />
on/noticed i.e. "model.uLike" )
<br />

As Sebastian points out, deciding  whether something is "xLike" or 
<br />
"yPart" for a given x which is a member of y is likely often to be a 
<br />
rather subjective decision. The TEI is full of rather subjective 
<br />
decisions about how things should be named, and I'm very happy to review 
<br />
particular cases, or -- if the cases turn out to be rather numerous -- 
<br />
to rethink the whole exercise. But what alternative proposals do we have?
<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> Thu Oct 06 2005 - 13:14:13 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Thu Oct  6 13:22:51 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 06 Oct 2005 18:22:51 +0100
Subject: [tei-council] I18N proposal for review
In-Reply-To: <ygfirwbb9en.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43455D6B.70002@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, 06 Oct 2005 18:22:51 +0100</span><br />
</address>

Christian Wittern wrote:
<br />
<em class="quotelev1">> Julia Flanders <Julia_Flanders_at_Brown.edu> writes:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>Sebastian, Veronika, and I have completed a pretty-much-final draft of
</em><br />
<em class="quotelev2">>>the I18N proposal to ALLC, which is now up at the TEI web site and
</em><br />
<em class="quotelev2">>>ready for review at http://www.tei-c.org/I18N/
</em><br />
<em class="quotelev1">> I have read through this and can only say this is very good, solid work.
</em><br />
<em class="quotelev1">> Needless to say that I am especially happy with the list of proposed
</em><br />
<em class="quotelev1">> translations:-)  I really hope that the work can proceed as envisioned.
</em><br />

I too have only had a quick look at it so far, but would echo 
<br />
Christian's comments.  I'm quite happy with the proposed languages, 
<br />
and  congratulate Sebastian, Veronika and Julia on a job well done. 
<br />
(I'll read it through more carefully soon and see if I can come up 
<br />
with any pedantic nit-picks. ;-) )
<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> Thu Oct 06 2005 - 13:22:36 EDT</span>
</div>

From nsmith at email.unc.edu  Thu Oct  6 13:32:51 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Thu, 6 Oct 2005 13:32:51 -0400 (Eastern Daylight Time)
Subject: [tei-council] I18N proposal for review
In-Reply-To: <a06200727bf69f4a2ad4c@[128.148.157.102]>
Message-ID: <Pine.WNT.4.10.10510061326160.3848-100000@AALCD49.lib.unc.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Natasha Smith <nsmith_at_email.unc.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 6 Oct 2005 13:32:51 -0400 (Eastern Daylight Time)</span><br />
</address>

Julia, Sebastian, and Veronika:
<br />

You did a remarkable job with clearly describing quite a complex project.
<br />
Ambitious, but looks very doable. I have a slight concern about proposed
<br />
deadlines, but it might be fine if you already have people lined up and
<br />
planning to work within a tight schedule.
<br />

Again, great work and all the best, ns   
<br />

<p><p><p>all the best, ns
<br />

On Wed, 5 Oct 2005, Julia Flanders wrote:
<br />

<em class="quotelev1">> Sebastian, Veronika, and I have completed a pretty-much-final draft 
</em><br />
<em class="quotelev1">> of the I18N proposal to ALLC, which is now up at the TEI web site and 
</em><br />
<em class="quotelev1">> ready for review at http://www.tei-c.org/I18N/
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Please take a look and let us know of any urgent suggested changes or 
</em><br />
<em class="quotelev1">> additions. We'll submit it to ALLC within a week.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Best wishes, Julia
</em><br />
<em class="quotelev1">> _______________________________________________
</em><br />
<em class="quotelev1">> tei-council mailing list
</em><br />
<em class="quotelev1">> tei-council_at_lists.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>_______________________________________________
<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 Oct 06 2005 - 13:33:07 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sat Oct  8 07:01:26 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 08 Oct 2005 12:01:26 +0100
Subject: The Naming of Classes [was Re: [tei-council] Council class meeting notes]
In-Reply-To: <17220.32172.734583.802478@emt.wwp.brown.edu>
Message-ID: <4347A706.9010606@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, 08 Oct 2005 12:01:26 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>I haven't yet read this carefully, but on quick glance EDW87a looks
</em><br />
<em class="quotelev1">>OK to me.
</em><br />
<em class="quotelev1">>
</em><br />

Good!
<br />

<em class="quotelev1">> A few nit-picks jump to mind (I'd prefer "-like" or
</em><br />
<em class="quotelev1">>"Siblings" to "Like"
</em><br />
<em class="quotelev1">>
</em><br />
I think introducing a hyphen into the world of TEI naming 
<br />
meta-characters really would be inconsistent., and "Sibling" is both too 
<br />
long and (I think) misleading -- see my reply to Christian yesterday.
<br />

<em class="quotelev1">>; the prose describing subclasses is twisted;
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
Please make a suggestion for untwisting it.
<br />

<em class="quotelev1">>EDW79 and EDW86 are no longer good places to look for lists of
</em><br />
<em class="quotelev1">>attribute names currently in use),
</em><br />
<em class="quotelev1">>
</em><br />

Yes, I just took that text unchanged.
<br />

<em class="quotelev1">> but mostly we need to merge in the
</em><br />
<em class="quotelev1">>new classes and address some details.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

Also a check that all existing class names are actually covered (I found 
<br />
one or two missing).
<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 Oct 08 2005 - 06:59:33 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sat Oct  8 07:48:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 8 Oct 2005 07:48:11 -0400
Subject: The Naming of Classes [was Re: [tei-council] Council class meeting notes]
In-Reply-To: <4347A706.9010606@computing-services.oxford.ac.uk>
Message-ID: <17223.45563.392188.708157@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, 8 Oct 2005 07:48:11 -0400</span><br />
</address>

<em class="quotelev1">> I think introducing a hyphen into the world of TEI naming
</em><br />
<em class="quotelev1">> meta-characters really would be inconsistent., and "Sibling" is
</em><br />
<em class="quotelev1">> both too long and (I think) misleading -- see my reply to Christian
</em><br />
<em class="quotelev1">> yesterday.
</em><br />

I was figuring we'd introduce these hyphens in a consistent way. But
<br />
your reply to Christian yesterday convinced me that "Sibling" is even
<br />
less desirable than "Like" (or "-like").
<br />

<p><em class="quotelev1">> Please make a suggestion for untwisting it.
</em><br />

<item>If the class members are all children of the element after
<br />
which the class is named, then the first suffix should be
<br />
<code>Part</code>; if the class members are all siblings of the
<br />
element after which the class is named, then the first suffix should
<br />
be <code>Like</code>.</item>
<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 Oct 08 2005 - 07:48:20 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sat Oct  8 08:35:32 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 08 Oct 2005 13:35:32 +0100
Subject: The Naming of Classes [was Re: [tei-council] Council class meeting notes]
In-Reply-To: <17223.45563.392188.708157@emt.wwp.brown.edu>
Message-ID: <4347BD14.7050308@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, 08 Oct 2005 13:35:32 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev2">>>I think introducing a hyphen into the world of TEI naming
</em><br />
<em class="quotelev2">>>meta-characters really would be inconsistent., and "Sibling" is
</em><br />
<em class="quotelev2">>>both too long and (I think) misleading -- see my reply to Christian
</em><br />
<em class="quotelev2">>>yesterday.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I was figuring we'd introduce these hyphens in a consistent way. But
</em><br />
<em class="quotelev1">>your reply to Christian yesterday convinced me that "Sibling" is even
</em><br />
<em class="quotelev1">>less desirable than "Like" (or "-like").
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

I don't doubt that it would be consistent, but it seems mad to have 
<br />
camelCasing AND dots AND hyphens to do token separation in different 
<br />
circumstances
<br />

<p><em class="quotelev2">>>Please make a suggestion for untwisting it.
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">><item>If the class members are all children of the element after
</em><br />
<em class="quotelev1">>which the class is named, then the first suffix should be
</em><br />
<em class="quotelev1">><code>Part</code>; if the class members are all siblings of the
</em><br />
<em class="quotelev1">>element after which the class is named, then the first suffix should
</em><br />
<em class="quotelev1">>be <code>Like</code>.</item>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

This is OK, but misses the point that "like" things are not only 
<br />
siblings -- they are also semantically related. And there are siblings 
<br />
which are not like.
<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">>  
</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 Oct 08 2005 - 08:33:37 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sat Oct  8 22:23:31 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 8 Oct 2005 22:23:31 -0400
Subject: [tei-council] gaiji in PCDATA, or <g> in text
Message-ID: <17224.32547.11372.38752@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, 8 Oct 2005 22:23:31 -0400</span><br />
</address>

While we were in Oxford, Lou, Sebastian, and I finally hammered out a
<br />
plan for allowing <g> in places where text is allowed. Sebastian gets
<br />
the credit for the scheme, I think. 
<br />

* A new class, 'tei.gLike' which has only 1 member, <g>
<br />
* A new macro, 'macro.xtext' which is declared 
<br />
  macro.xtext = (text | tei.gLike)*
<br />
* Wherever <g> is desired, use reference macro.xtext instead of
<br />
  rng:text.
<br />

Sebastian recently implimented the system, and today I went through
<br />
various occurences and set them to either macro.xtext or rng:text.
<br />
Here is the list of the current settings, with some comments.
<br />

<altIdent>         allow <g>
<br />
<formulaNotations> doesn't matter, not used; should be nuked
<br />
<formula>          text only -- modern formulas don't contain gaijis
<br />
<charName>         text only -- must follow Unicode convention, which does not include gaijis
<br />
<glyphName>        text only -- must follow Unicode convention, which does not include gaijis
<br />
<localName>        allow <g>
<br />
<value>            allow <g>
<br />
<string>           allow <g>
<br />
<day>              allow <g>
<br />
<geog>             allow <g>
<br />
<hour>             allow <g>
<br />
<minute>           allow <g>
<br />
<month>            allow <g>
<br />
<second>           allow <g>
<br />
<week>             allow <g>
<br />
<year>             allow <g>
<br />
<schemapattern>    text only
<br />
<att>              CHANGED to tei.data.ident to match prose definition
<br />
<code>             text only
<br />
<defaultVal>       text only (should be tei.data.names?)
<br />
<eg>               text only
<br />
<egXML>            text only
<br />
<ident>            text only
<br />
<memberOf>         allow <g>
<br />
<stringVal>        text only, should be nuked
<br />
<val>              text only
<br />
<altName>          allow <g>
<br />
<collection>       allow <g> (should be macro.phraseSeq, no?)
<br />
<depth>            allow <g>
<br />
<height>           allow <g>
<br />
<institution>      allow <g> (should be macro.phraseSeq, no?)
<br />
<locus>            allow <g> (maybe should be text only?)
<br />
<origDate>         text only
<br />
<origPlace>        allow <g> (should be macro.phraseSeq, no?)
<br />
<repository>       allow <g> (should be macro.phraseSeq, no?)
<br />
<width>            allow <g>
<br />
<unicodeName>      text only -- must be a Unicode name, and they don't have gaijis
<br />

Speak up if you think any of these have been incorrectly instituted.
<br />
It would also be useful if people would express opinions on the
<br />
"should be" coments.
<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 Oct 08 2005 - 22:23:41 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Oct  9 07:38:48 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 09 Oct 2005 12:38:48 +0100
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <17224.32547.11372.38752@emt.wwp.brown.edu>
Message-ID: <43490148.30805@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, 09 Oct 2005 12:38:48 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>* A new class, 'tei.gLike' which has only 1 member, <g>
</em><br />
<em class="quotelev1">>* A new macro, 'macro.xtext' which is declared 
</em><br />
<em class="quotelev1">>  macro.xtext = (text | tei.gLike)*
</em><br />
<em class="quotelev1">>* Wherever <g> is desired, use reference macro.xtext instead of
</em><br />
<em class="quotelev1">>  rng:text.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
with the caveat that the macro does not work in all situations
<br />
(because of DTD weird things), so sometimes "text | tei.gLike" is needed
<br />
by hand
<br />

<em class="quotelev1">><institution>      allow <g> (should be macro.phraseSeq, no?)
</em><br />
<em class="quotelev1">><locus>            allow <g> (maybe should be text only?)
</em><br />
<em class="quotelev1">><origPlace>        allow <g> (should be macro.phraseSeq, no?)
</em><br />
<em class="quotelev1">><repository>       allow <g> (should be macro.phraseSeq, no?)
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
hard to disagree with your conclusion about these
<br />

<em class="quotelev1">><origDate>         text only
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
sure about that?
<br />

I am very glad you cleared up after my initial "bull in a china job"
<br />
canter through the "text", Syd.  This cheers me up.
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Oct 09 2005 - 07:38:56 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Oct  9 08:51:34 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 9 Oct 2005 08:51:34 -0400
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <43490148.30805@oucs.ox.ac.uk>
Message-ID: <17225.4694.495053.134292@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, 9 Oct 2005 08:51:34 -0400</span><br />
</address>

Sebastian says:
<br />

<em class="quotelev1">> with the caveat that the macro does not work in all situations
</em><br />
<em class="quotelev1">> (because of DTD weird things), so sometimes "text | tei.gLike" is
</em><br />
<em class="quotelev1">> needed by hand
</em><br />

Oh dear. I didn't look for "text | tei.gLike", only for
<br />
"macro.xtext". Will try to check that later today. (At some point you
<br />
should explain this DTD-generation problem to me.)
<br />

<p><em class="quotelev2">> ><origDate>         text only
</em><br />
<em class="quotelev1">> sure about that?
</em><br />

Pretty sure, although I'm happy to have the MS group over-rule me if
<br />
needed. <origDate>, if I understand correctly, is used as a place for
<br />
a modern philologist, librarian, or other manuscript describer to put
<br />
in the date he thinks is the date of the manuscript's origin, and
<br />
would never be used to transcribe a date written in a manuscript. I
<br />
could be wrong, though, and if someone wants to argue that such a
<br />
manuscript describer should have the capability to record the date in
<br />
Elvish (a language not covered by Unicode) ...
<br />

<p><em class="quotelev1">> I am very glad you cleared up after my initial "bull in a china
</em><br />
<em class="quotelev1">> job" canter through the "text", Syd. This cheers me up.
</em><br />

My pleasure, but don't break out the champagne until I'm done with
<br />
"text | tei.gLike". (Although first glance says there are very few
<br />
that should be reverted to "text" only.)
<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 Oct 09 2005 - 08:51:47 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Oct  9 09:57:22 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 9 Oct 2005 09:57:22 -0400
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <43490148.30805@oucs.ox.ac.uk>
Message-ID: <17225.8642.532044.78348@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, 9 Oct 2005 09:57:22 -0400</span><br />
</address>

<em class="quotelev1">> with the caveat that the macro does not work in all situations
</em><br />
<em class="quotelev1">> (because of DTD weird things), so sometimes "text | tei.gLike" is
</em><br />
<em class="quotelev1">> needed by hand
</em><br />

OK, I've taken a quick glance at all of these (list appended), and
<br />
none of them are obvious candidates for excluding <g>, so I've left
<br />
them all as permitting <g>. 
<br />

A few questions arise:
<br />

<gramGrp>: why does this element have text at all? The content should
<br />
           probably be something like
<br />
           tei.Incl*, tei.gramInfo, ( tei.gramInfo | tei.Incl )*
<br />
           no?
<br />

<re>: If character data is allowed, then <g> should be allowed. But
<br />
      why does this element permit PCDATA at all? I thought it was
<br />
      roughly analagous to <entry>, which does not.
<br />

<pVar>: the "Note:" information (<remarks>) does not match the
<br />
        content model; which is correct?
<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 Oct 09 2005 - 09:57:31 EDT</span>
</div>

From Laurent.Romary at loria.fr  Sun Oct  9 11:22:27 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Sun, 9 Oct 2005 17:22:27 +0200
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <17225.8642.532044.78348@emt.wwp.brown.edu>
Message-ID: <C85FA63F-2FFE-42CF-AE0F-7CB6852F28CD@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>: Sun, 9 Oct 2005 17:22:27 +0200</span><br />
</address>

Le 9 oct. 05 ? 15:57, Syd Bauman a ?crit :
<br />

<em class="quotelev2">>> with the caveat that the macro does not work in all situations
</em><br />
<em class="quotelev2">>> (because of DTD weird things), so sometimes "text | tei.gLike" is
</em><br />
<em class="quotelev2">>> needed by hand
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> OK, I've taken a quick glance at all of these (list appended), and
</em><br />
<em class="quotelev1">> none of them are obvious candidates for excluding <g>, so I've left
</em><br />
<em class="quotelev1">> them all as permitting <g>.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> A few questions arise:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> <gramGrp>: why does this element have text at all? The content should
</em><br />
<em class="quotelev1">>            probably be something like
</em><br />
<em class="quotelev1">>            tei.Incl*, tei.gramInfo, ( tei.gramInfo | tei.Incl )*
</em><br />
<em class="quotelev1">>            no?
</em><br />

This is because you may use this element to tag semi-structured  
<br />
grammatical information where you may have text ('labels' or other  
<br />
comments) interspersed with actual elements like <pos>, <gen>, <num>  
<br />
etc.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> <re>: If character data is allowed, then <g> should be allowed. But
</em><br />
<em class="quotelev1">>       why does this element permit PCDATA at all? I thought it was
</em><br />
<em class="quotelev1">>       roughly analagous to <entry>, which does not.
</em><br />

M?me cause, m?me effet. <re> is used to describe entry-like objects  
<br />
within a real entry (e.g. compounds). Such information is sometimes  
<br />
less structured then a real entry and may thus require that data be  
<br />
there in complement to the usual stuff (<gramGrp>, <form>, <sense>,  
<br />
etc.). Note also that we can have <dicScrap> (yark) and entryFree) as  
<br />
alternates to <entry> whereas there is only one <re>.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> <pVar>: the "Note:" information (<remarks>) does not match the
</em><br />
<em class="quotelev1">>         content model; which is correct?
</em><br />

It is even more weird that oVar is more consistent. My advice: change  
<br />
<remarks> to mirror oVar.
<br />
Best,
<br />
Laurent_______________________________________________
<br />
tei-council mailing list
<br />
tei-council_at_lists.village.Virginia.EDU
<br />
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
<br />
<span id="received"><dfn>Received on</dfn> Sun Oct 09 2005 - 11:22:36 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Oct  9 16:17:59 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 9 Oct 2005 16:17:59 -0400
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <C85FA63F-2FFE-42CF-AE0F-7CB6852F28CD@loria.fr>
Message-ID: <17225.31479.770205.474099@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, 9 Oct 2005 16:17:59 -0400</span><br />
</address>

Laurent --
<br />
  Thanks for the explanations.
<br />

<p><em class="quotelev1">> It is even more weird that oVar is more consistent. My advice:
</em><br />
<em class="quotelev1">> change <remarks> to mirror oVar.
</em><br />

Done; except, of course it says "<pRef>", not "<oRef>" :-)
<br />

<p>Thanks!
<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 Oct 09 2005 - 16:18:09 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Oct  9 18:53:08 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 10 Oct 2005 07:53:08 +0900
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <4347BD14.7050308@computing-services.oxford.ac.uk>
Message-ID: <ygfmzli2tgr.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 10 Oct 2005 07:53:08 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev2">>><item>If the class members are all children of the element after
</em><br />
<em class="quotelev2">>>which the class is named, then the first suffix should be
</em><br />
<em class="quotelev2">>><code>Part</code>; if the class members are all siblings of the
</em><br />
<em class="quotelev2">>>element after which the class is named, then the first suffix should
</em><br />
<em class="quotelev2">>>be <code>Like</code>.</item>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> This is OK, but misses the point that "like" things are not only
</em><br />
<em class="quotelev1">> siblings -- they are also semantically related. And there are siblings
</em><br />
<em class="quotelev1">> which are not like.
</em><br />

Which is exactly what caused my confusion. How about 
<br />

... if the class members all occur on the same hierarchical level as
<br />
the siblings of the element after which the class is named, then the
<br />
first suffix should be <code>Like</code>.
<br />

for the second half of the sentence?
<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> Sun Oct 09 2005 - 18:53:10 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Oct  9 19:00:47 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 10 Oct 2005 08:00:47 +0900
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <17224.32547.11372.38752@emt.wwp.brown.edu>
Message-ID: <ygfirw62t40.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 10 Oct 2005 08:00:47 +0900</span><br />
</address>

Syd Bauman <Syd_Bauman_at_Brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev1">> <localName>        allow <g>
</em><br />

As I said elsewhere, this is "text only" in my book.  Since it is a
<br />
modern, locally defined name made up by the project, there is no
<br />
reason to insist on using <g>, which would only complicate matters in
<br />
this "meta" situation.
<br />

<em class="quotelev1">> <eg>               text only
</em><br />
<em class="quotelev1">> <egXML>            text only
</em><br />

Why would these be text only?  I would "allow <g>" here
<br />

<em class="quotelev1">> <depth>            allow <g>
</em><br />
<em class="quotelev1">> <height>           allow <g>
</em><br />
<em class="quotelev1">> <width>            allow <g>
</em><br />

Hard to see why you would need a <g> here, but surely not impossible:-)
<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> Sun Oct 09 2005 - 19:00:47 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Mon Oct 10 07:30:58 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 10 Oct 2005 07:30:58 -0400
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <ygfirw62t40.fsf@chwpb.local>
Message-ID: <17226.20722.398892.214901@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, 10 Oct 2005 07:30:58 -0400</span><br />
</address>

Christian Wittern writes:
<br />

<em class="quotelev2">> > <localName>        allow <g>
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> As I said elsewhere, this is "text only" in my book. Since it is a
</em><br />
<em class="quotelev1">> modern, locally defined name made up by the project, there is no
</em><br />
<em class="quotelev1">> reason to insist on using <g>, which would only complicate matters
</em><br />
<em class="quotelev1">> in this "meta" situation.
</em><br />

OK. I've just reverted this from 'macro.xtext' to 'rng:text'.
<br />

<p><em class="quotelev2">> > <eg>               text only
</em><br />
<em class="quotelev2">> > <egXML>            text only
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Why would these be text only?  I would "allow <g>" here
</em><br />

Because these are examples of XML encoding or other computer
<br />
documents. At lest for <egXML>, where the contents are defined to be
<br />
well-formed XML, it definitionally cannot have a character outside of
<br />
Unicode in it, so cannot need to have such a character encoded with
<br />
<g>. (You may want to give an example of <g>, but this is handled,
<br />
like any other example element, by using an element from a different
<br />
namespace, e.g. "http://www.tei-c.org/ns/Examples")
<br />

I suppose if someone wants to use <eg> to show an example of RTF or
<br />
some even more bizarre language, there might be some character in use
<br />
that is not actually a Unicode character? 
<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 Oct 10 2005 - 07:31:07 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Mon Oct 10 07:36:41 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 10 Oct 2005 07:36:41 -0400
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <4347BD14.7050308@computing-services.oxford.ac.uk>
Message-ID: <17226.21065.536247.918252@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, 10 Oct 2005 07:36:41 -0400</span><br />
</address>

<em class="quotelev1">> I don't doubt that it would be consistent, but it seems mad to have
</em><br />
<em class="quotelev1">> camelCasing AND dots AND hyphens to do token separation in
</em><br />
<em class="quotelev1">> different circumstances
</em><br />

I see the point, but I'm thinking of "p-like" as a single hyphenated
<br />
word.
<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 Oct 10 2005 - 07:36:54 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Mon Oct 10 08:55:57 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 10 Oct 2005 13:55:57 +0100
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <17226.21065.536247.918252@emt.wwp.brown.edu>
Message-ID: <434A64DD.1010608@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, 10 Oct 2005 13:55:57 +0100</span><br />
</address>

There seems to have been little dissent from the proposals of edw87a, 
<br />
which Council was asked to comment on a week or so ago.
<br />

I've therefore now implemented the renamings for all existing classes as 
<br />
defined in edw87a (which maybe should replace the existing edw87 to 
<br />
avoid confusion). I have also tested that we can still generate valid 
<br />
schemas, and run the test suite. This is quite a big job and there may 
<br />
well be a bit of mopping up to do in the next day or two. But I think we 
<br />
now at least have a basically consistent and defensible naming system in 
<br />
place, on top of which we can start implementing (and extending) the 
<br />
ideas discussed at the classes meeting (see tcm20 and edw92)
<br />

Sebastian and I hope to use this is a basis for a new candidate release 
<br />
of P5 to be available in time for the members meeting. We'll announce 
<br />
that at the start of next week, all being well.
<br />

One major outstanding task is completion of the datatype changes, on 
<br />
which Syd has been beavering away over the last few days, so I am 
<br />
optimistic that this can be completed on the same timescale.
<br />

At the moment, the new version is in CVS, but to make everything work 
<br />
you also need to update your ODD stylesheet package to the latest 
<br />
version (using Debian it's easy!).
<br />

<p>Excelsior!
<br />

Lou
<br />

<p><p>Syd Bauman wrote:
<br />
<em class="quotelev2">>>I don't doubt that it would be consistent, but it seems mad to have
</em><br />
<em class="quotelev2">>>camelCasing AND dots AND hyphens to do token separation in
</em><br />
<em class="quotelev2">>>different circumstances
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I see the point, but I'm thinking of "p-like" as a single hyphenated
</em><br />
<em class="quotelev1">> word.
</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.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 />

<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 Oct 10 2005 - 08:50:45 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Oct 10 08:55:51 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 10 Oct 2005 13:55:51 +0100
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <434A64DD.1010608@oucs.ox.ac.uk>
Message-ID: <434A64D7.2060705@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, 10 Oct 2005 13:55:51 +0100</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Sebastian and I hope to use this is a basis for a new candidate
</em><br />
<em class="quotelev1">> release of P5 to be available in time for the members meeting. We'll
</em><br />
<em class="quotelev1">> announce that at the start of next week, all being well.
</em><br />
<em class="quotelev1">>
</em><br />
To clarify, a "release" means new releases on Sourceforge, new Debian
<br />
packages, updated Roma, and new
<br />
public Knoppix release. All being well, those can all happen more or
<br />
less simultaneously.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Mon Oct 10 2005 - 08:55:56 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Oct 10 18:33:28 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 11 Oct 2005 07:33:28 +0900
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <17226.20722.398892.214901@emt.wwp.brown.edu>
Message-ID: <ygfoe5x0zpj.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 11 Oct 2005 07:33:28 +0900</span><br />
</address>

Syd Bauman <Syd_Bauman_at_Brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev1">> Christian Wittern writes:
</em><br />
<em class="quotelev3">>> > <eg>               text only
</em><br />
<em class="quotelev3">>> > <egXML>            text only
</em><br />
<em class="quotelev2">>> 
</em><br />
<em class="quotelev2">>> Why would these be text only?  I would "allow <g>" here
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Because these are examples of XML encoding or other computer
</em><br />
<em class="quotelev1">> documents. At lest for <egXML>, where the contents are defined to be
</em><br />
<em class="quotelev1">> well-formed XML, it definitionally cannot have a character outside of
</em><br />
<em class="quotelev1">> Unicode in it, so cannot need to have such a character encoded with
</em><br />
<em class="quotelev1">> <g>. 
</em><br />

I am afraid you are confusing two levels of different encoding here.
<br />
<g> is a means to encode arbitrary characters in XML using XML
<br />
methods.  The characters are defined to be possibly outside of Unicode
<br />
by their semantics on the markup level -- the character encdoing of
<br />
course contains only legal Unicode characters in any case.
<br />

<em class="quotelev1">> (You may want to give an example of <g>, but this is handled,
</em><br />
<em class="quotelev1">> like any other example element, by using an element from a different
</em><br />
<em class="quotelev1">> namespace, e.g. "http://www.tei-c.org/ns/Examples")
</em><br />
<em class="quotelev1">>
</em><br />
I see.
<br />

<em class="quotelev1">> I suppose if someone wants to use <eg> to show an example of RTF or
</em><br />
<em class="quotelev1">> some even more bizarre language, there might be some character in use
</em><br />
<em class="quotelev1">> that is not actually a Unicode character? 
</em><br />
<em class="quotelev1">>
</em><br />

Most surely not, but that is a bit OT:-)
<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> Mon Oct 10 2005 - 18:33:29 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Oct 10 18:34:22 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 11 Oct 2005 07:34:22 +0900
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <434A64DD.1010608@oucs.ox.ac.uk>
Message-ID: <ygfk6gl0zo1.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 11 Oct 2005 07:34:22 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Sebastian and I hope to use this is a basis for a new candidate
</em><br />
<em class="quotelev1">> release of P5 to be available in time for the members meeting. We'll
</em><br />
<em class="quotelev1">> announce that at the start of next week, all being well.
</em><br />

Hurray, so good luck and I hope everything goes 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 Oct 10 2005 - 18:34:21 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Mon Oct 10 18:36:49 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 10 Oct 2005 18:36:49 -0400
Subject: [tei-council] for Council to consider: new datatype
Message-ID: <17226.60673.459030.600149@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, 10 Oct 2005 18:36:49 -0400</span><br />
</address>

After a huddle over the weekend among me, Sebastian, and Lou, we've
<br />
created yet another datatype. This one is specifically designed for
<br />
the height= and width= attributes of <graphic> and <binaryObject> The
<br />
declaration is 
<br />

data.htmlDimension =
<br />
  xsd:token {
<br />
    pattern =
<br />
      "[\-+]?\d+(\.\d+)?(cm|mm|in|pt|pc|px|em|ex|gd|rem|vw|vh|vm)"
<br />
  }
<br />

That pattern is specifically designed to allow values to map directly
<br />
to XSLFO or CSS3 values. It is a little more restrictive, in that it
<br />
requires that the numeric portion neither start nor end with a
<br />
decimal point (i.e., if there is a decimal point, there must be at
<br />
least one digit on either side). It is a little less restrictive than
<br />
XSLFO in that it permits some units that CSS3 uses but XSLFO does
<br />
not.
<br />

I think this is a fine and dandy datatype, but the more I think of
<br />
it, the more I think the name leaves a lot to be desired. Any
<br />
suggestions? Anyone object to it entirely or to its definition?
<br />

<p>P.S. I plan to post a similar missive about <respStmt> in a day or
<br />
     two. I *really* want Council members to think about this stuff
<br />
     and respond.
<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 Oct 10 2005 - 18:36:59 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Oct 10 18:38:49 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 10 Oct 2005 23:38:49 +0100
Subject: [tei-council] for Council to consider: new datatype
In-Reply-To: <17226.60673.459030.600149@emt.wwp.brown.edu>
Message-ID: <434AED79.902@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, 10 Oct 2005 23:38:49 +0100</span><br />
</address>

data.webMeasure?
<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> Mon Oct 10 2005 - 18:39:02 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Mon Oct 10 19:12:10 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 11 Oct 2005 00:12:10 +0100
Subject: [tei-council] for Council to consider: new datatype
In-Reply-To: <17226.60673.459030.600149@emt.wwp.brown.edu>
Message-ID: <434AF54A.5090209@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, 11 Oct 2005 00:12:10 +0100</span><br />
</address>

Fine by me, but
<br />
(a) why restrict it to web measurements? there might well be other 
<br />
attributes for which we'd want to specify number+units  in a single value.
<br />
(b) some of these units look a bit exotic to me : isn't a "rem" a unit 
<br />
of exposure to radiation? couldnt find it in css3 anyway
<br />

how about data.measure?
<br />

"dimension" suggests the axis along which the measurement is made to me, 
<br />
not the actual measurement.
<br />

<p>Syd Bauman wrote:
<br />

<em class="quotelev1">> After a huddle over the weekend among me, Sebastian, and Lou, we've
</em><br />
<em class="quotelev1">> created yet another datatype. This one is specifically designed for
</em><br />
<em class="quotelev1">> the height= and width= attributes of <graphic> and <binaryObject> The
</em><br />
<em class="quotelev1">> declaration is 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> data.htmlDimension =
</em><br />
<em class="quotelev1">>   xsd:token {
</em><br />
<em class="quotelev1">>     pattern =
</em><br />
<em class="quotelev1">>       "[\-+]?\d+(\.\d+)?(cm|mm|in|pt|pc|px|em|ex|gd|rem|vw|vh|vm)"
</em><br />
<em class="quotelev1">>   }
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> That pattern is specifically designed to allow values to map directly
</em><br />
<em class="quotelev1">> to XSLFO or CSS3 values. It is a little more restrictive, in that it
</em><br />
<em class="quotelev1">> requires that the numeric portion neither start nor end with a
</em><br />
<em class="quotelev1">> decimal point (i.e., if there is a decimal point, there must be at
</em><br />
<em class="quotelev1">> least one digit on either side). It is a little less restrictive than
</em><br />
<em class="quotelev1">> XSLFO in that it permits some units that CSS3 uses but XSLFO does
</em><br />
<em class="quotelev1">> not.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I think this is a fine and dandy datatype, but the more I think of
</em><br />
<em class="quotelev1">> it, the more I think the name leaves a lot to be desired. Any
</em><br />
<em class="quotelev1">> suggestions? Anyone object to it entirely or to its definition?
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> P.S. I plan to post a similar missive about <respStmt> in a day or
</em><br />
<em class="quotelev1">>      two. I *really* want Council members to think about this stuff
</em><br />
<em class="quotelev1">>      and respond.
</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.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>_______________________________________________
<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 Oct 10 2005 - 18:55:13 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Mon Oct 10 20:05:55 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 10 Oct 2005 20:05:55 -0400
Subject: [tei-council] for Council to consider: new datatype
In-Reply-To: <434AF54A.5090209@computing-services.oxford.ac.uk>
Message-ID: <17227.483.795229.606225@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, 10 Oct 2005 20:05:55 -0400</span><br />
</address>

SR> data.webMeasure?
<br />

I like that a lot better. Of course, XSLFO may well be used for
<br />
printed pages. But 'data.outputMeasurement' seems kinda clunky.
<br />

<p>LB> (a) why restrict it to web measurements? there might well be
<br />
LB>     other attributes for which we'd want to specify number+units 
<br />
LB>     in a single value.
<br />

Darn good question. The difficulty is that if we use it for other
<br />
things, we need to include all sorts of units, some that won't make
<br />
any sense for a given attribute. So either we make up a separate
<br />
datatype for each set of units a set of attributes wants, or we live
<br />
with a system that permits ridiculous values like
<br />
  <graphic height="1.1m" width="76kg"/>
<br />
  <person height="256px" weight="3em"/>
<br />
  <when interval="14.7mg"/>
<br />
Personally, I would much prefer a few extra datatypes. (There can't
<br />
be that many needed, can there?
<br />

<p><em class="quotelev1">> (b) some of these units look a bit exotic to me : isn't a "rem" a
</em><br />
<em class="quotelev1">>     unit of exposure to radiation? couldnt find it in css3 anyway
</em><br />

I think they're outright weird. Got 'em straight from 
<br />
http://www.w3.org/TR/2005/WD-css3-values-20050726/#numbers0, where
<br />
"rem" is listed as "the font size of the root element".
<br />

<p><em class="quotelev1">> "dimension" suggests the axis along which the measurement is made
</em><br />
<em class="quotelev1">> to me, not the actual measurement.
</em><br />

I think you're right, "measurement" is better. If we go with one
<br />
datatype fits all, then "data.measurement" makes sense. If we go with
<br />
different datatypes for different kinds of measurement, then things
<br />
like "data.lengthMeasurement" and "data.massMeasurement" or
<br />
"data.measurement.typesetting" and "data.measurement.length" and
<br />
"data.measurement.mass" might make sense. (We don't really have any
<br />
mass ones, I don't think; just using that as an example.)
<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 Oct 10 2005 - 20:06:05 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Mon Oct 10 21:46:42 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 10 Oct 2005 21:46:42 -0400
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <434A64DD.1010608@oucs.ox.ac.uk>
Message-ID: <17227.6530.638047.398404@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, 10 Oct 2005 21:46:42 -0400</span><br />
</address>

<em class="quotelev1">> One major outstanding task is completion of the datatype changes,
</em><br />
<em class="quotelev1">> on which Syd has been beavering away over the last few days, so I
</em><br />
<em class="quotelev1">> am optimistic that this can be completed on the same timescale.
</em><br />

~45 down, ~30 to go.
<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 Oct 10 2005 - 21:46:53 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Tue Oct 11 07:37:12 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 11 Oct 2005 12:37:12 +0100
Subject: [tei-council] for Council to consider: new datatype
In-Reply-To: <17227.483.795229.606225@emt.wwp.brown.edu>
Message-ID: <434BA3E8.1010903@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, 11 Oct 2005 12:37:12 +0100</span><br />
</address>

Syd Bauman wrote:
<br />
<em class="quotelev1">>   <graphic height="1.1m" width="76kg"/>
</em><br />
<em class="quotelev1">>   <person height="256px" weight="3em"/>
</em><br />

Doesn't CSS3 (and earlier) allow for percentage widths and heights as well?
<br />
Your datatype didn't seem to cope with this.  100%, 30%, etc.
<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> Tue Oct 11 2005 - 07:37:47 EDT</span>
</div>

From Julia_Flanders at Brown.edu  Tue Oct 11 17:48:42 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Tue, 11 Oct 2005 17:48:42 -0400
Subject: [tei-council] submitted I18N proposal
Message-ID: <a06200741bf71e3467645@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 11 Oct 2005 17:48:42 -0400</span><br />
</address>

I'm happy to report that the I18N proposal has been submitted to 
<br />
Harold Short of the ALLC. I'll keep you all informed on any 
<br />
information I receive. Thanks to all who helped with this, and in 
<br />
particular to Sebastian and Veronika who did the bulk of the hard 
<br />
work.
<br />

Best wishes, Julia
<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 Oct 11 2005 - 17:48:48 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Tue Oct 11 22:34:40 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 11 Oct 2005 22:34:40 -0400
Subject: [tei-council] quick note on some attr updates
Message-ID: <17228.30272.674133.223894@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, 11 Oct 2005 22:34:40 -0400</span><br />
</address>

While fixing rng:text attributes I have also
<br />
* deleted key= of att.personal
<br />
* deleted key= of att.datePart
<br />
* updated value= of att.datePart to refer to data.temporal; still
<br />
  also allows data.duration
<br />
* created special content models for interval= of <timeline> and
<br />
  <whem> 
<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> Tue Oct 11 2005 - 22:34:50 EDT</span>
</div>

From Julia_Flanders at Brown.edu  Wed Oct 12 10:45:37 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Wed, 12 Oct 2005 10:45:37 -0400
Subject: [tei-council] for Council to consider: new datatype
In-Reply-To: <17227.483.795229.606225@emt.wwp.brown.edu>
Message-ID: <a0620074dbf72d0e527d3@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 12 Oct 2005 10:45:37 -0400</span><br />
</address>

I think "output" or "display" is the right sort of term. And having a 
<br />
set of these (potentially to include other things like typesetting or 
<br />
gemstones) as subclasses of the general "measurement" category seems 
<br />
like an interesting idea.
<br />

--Julia
<br />

At 8:05 PM -0400 10/10/05, Syd Bauman wrote:
<br />
<em class="quotelev1">>SR> data.webMeasure?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I like that a lot better. Of course, XSLFO may well be used for
</em><br />
<em class="quotelev1">>printed pages. But 'data.outputMeasurement' seems kinda clunky.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>LB> (a) why restrict it to web measurements? there might well be
</em><br />
<em class="quotelev1">>LB>     other attributes for which we'd want to specify number+units
</em><br />
<em class="quotelev1">>LB>     in a single value.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Darn good question. The difficulty is that if we use it for other
</em><br />
<em class="quotelev1">>things, we need to include all sorts of units, some that won't make
</em><br />
<em class="quotelev1">>any sense for a given attribute. So either we make up a separate
</em><br />
<em class="quotelev1">>datatype for each set of units a set of attributes wants, or we live
</em><br />
<em class="quotelev1">>with a system that permits ridiculous values like
</em><br />
<em class="quotelev1">>   <graphic height="1.1m" width="76kg"/>
</em><br />
<em class="quotelev1">>   <person height="256px" weight="3em"/>
</em><br />
<em class="quotelev1">>   <when interval="14.7mg"/>
</em><br />
<em class="quotelev1">>Personally, I would much prefer a few extra datatypes. (There can't
</em><br />
<em class="quotelev1">>be that many needed, can there?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>  (b) some of these units look a bit exotic to me : isn't a "rem" a
</em><br />
<em class="quotelev2">>>      unit of exposure to radiation? couldnt find it in css3 anyway
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I think they're outright weird. Got 'em straight from
</em><br />
<em class="quotelev1">>http://www.w3.org/TR/2005/WD-css3-values-20050726/#numbers0, where
</em><br />
<em class="quotelev1">>"rem" is listed as "the font size of the root element".
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>  "dimension" suggests the axis along which the measurement is made
</em><br />
<em class="quotelev2">>>  to me, not the actual measurement.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I think you're right, "measurement" is better. If we go with one
</em><br />
<em class="quotelev1">>datatype fits all, then "data.measurement" makes sense. If we go with
</em><br />
<em class="quotelev1">>different datatypes for different kinds of measurement, then things
</em><br />
<em class="quotelev1">>like "data.lengthMeasurement" and "data.massMeasurement" or
</em><br />
<em class="quotelev1">>"data.measurement.typesetting" and "data.measurement.length" and
</em><br />
<em class="quotelev1">>"data.measurement.mass" might make sense. (We don't really have any
</em><br />
<em class="quotelev1">>mass ones, I don't think; just using that as an example.)
</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.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 Oct 12 2005 - 10:45:43 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Oct 16 07:33:16 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 16 Oct 2005 12:33:16 +0100
Subject: [tei-council] foreName
Message-ID: <43523A7C.50402@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, 16 Oct 2005 12:33:16 +0100</span><br />
</address>

can anyone think of a reason why we have <surname> and <foreName>?
<br />
that is, why is it not <forename>? If no-one can suggest a strong
<br />
argument, I propose to rename <foreName> to <forename>
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Oct 16 2005 - 07:33:37 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Oct 16 07:47:20 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 16 Oct 2005 12:47:20 +0100
Subject: [tei-council] dateable elements
Message-ID: <43523DC8.3020509@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, 16 Oct 2005 12:47:20 +0100</span><br />
</address>

The classes "att.datePart" (in the namesdates module) and dateable
<br />
and the (misname) "model.pPart.datable" (in the MS module) have two
<br />
much in common.
<br />

The pPart.datable class offers
<br />

   <attDef ident="notBefore" usage="opt">
<br />
    <attDef ident="notAfter" usage="opt">
<br />
    <attDef ident="certainty" usage="opt">
<br />
    <attDef ident="dateAttrib" usage="opt">
<br />
    <attDef ident="evidence" usage="opt">
<br />

whole the datePart class offers
<br />

   <attDef ident="value" usage="opt">
<br />
    <attDef ident="type" usage="opt">
<br />
    <attDef ident="full" usage="opt">
<br />

It looks to me as if we need a class in the core which has  all the
<br />
attributes
<br />
of the 2 classes.
<br />

Does anyone disagree?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Oct 16 2005 - 07:47:49 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Oct 16 11:45:34 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 16 Oct 2005 11:45:34 -0400
Subject: [tei-council] foreName
In-Reply-To: <43523A7C.50402@oucs.ox.ac.uk>
Message-ID: <17234.30110.781725.912679@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, 16 Oct 2005 11:45:34 -0400</span><br />
</address>

<em class="quotelev1">> can anyone think of a reason why we have <surname> and <foreName>?
</em><br />
<em class="quotelev1">> that is, why is it not <forename>? If no-one can suggest a strong
</em><br />
<em class="quotelev1">> argument, I propose to rename <foreName> to <forename>
</em><br />

I'm embarrassed to admit that for a while I thought there was no word
<br />
"forename" only because TEI used "foreName" not "forename". I would
<br />
guess it's a mistake, but would like to hear what the reasoning was
<br />
(if any) at the time. Anyone know who was on the Subcommittee on
<br />
Names, Dates,and Measures?
<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 Oct 16 2005 - 11:45:45 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sun Oct 16 12:19:27 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 16 Oct 2005 17:19:27 +0100
Subject: [tei-council] foreName
In-Reply-To: <17234.30110.781725.912679@emt.wwp.brown.edu>
Message-ID: <43527D8F.4070308@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, 16 Oct 2005 17:19:27 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev2">>>can anyone think of a reason why we have <surname> and <foreName>?
</em><br />
<em class="quotelev2">>>that is, why is it not <forename>? If no-one can suggest a strong
</em><br />
<em class="quotelev2">>>argument, I propose to rename <foreName> to <forename>
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I'm embarrassed to admit that for a while I thought there was no word
</em><br />
<em class="quotelev1">> "forename" only because TEI used "foreName" not "forename". I would
</em><br />
<em class="quotelev1">> guess it's a mistake, but would like to hear what the reasoning was
</em><br />
<em class="quotelev1">> (if any) at the time. 
</em><br />

It is a mistake. A corrigible error.
<br />

Anyone know who was on the Subcommittee on
<br />
<em class="quotelev1">> Names, Dates,and Measures?
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />

I know, but I aint telling.
<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 Oct 16 2005 - 12:01:28 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Oct 16 13:16:22 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 16 Oct 2005 13:16:22 -0400
Subject: [tei-council] foreName
In-Reply-To: <43527D8F.4070308@computing-services.oxford.ac.uk>
Message-ID: <17234.35558.2985.498836@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, 16 Oct 2005 13:16:22 -0400</span><br />
</address>

SR> I propose to rename <foreName> to <forename>
<br />

LB> It is a mistake. A corrigible error.
<br />

That means we should change it in P4 then, too, 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> Sun Oct 16 2005 - 13:16:30 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Oct 16 13:20:48 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 16 Oct 2005 18:20:48 +0100
Subject: [tei-council] foreName
In-Reply-To: <17234.35558.2985.498836@emt.wwp.brown.edu>
Message-ID: <43528BF0.9040303@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, 16 Oct 2005 18:20:48 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>SR> I propose to rename <foreName> to <forename>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>LB> It is a mistake. A corrigible error.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>That means we should change it in P4 then, too, eh?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

cary.....
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Oct 16 2005 - 13:21:09 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Oct 16 14:39:48 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 16 Oct 2005 14:39:48 -0400
Subject: [tei-council] for Council to consider: new datatype
In-Reply-To: <434BA3E8.1010903@computing-services.oxford.ac.uk>
Message-ID: <17234.40564.803622.707387@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, 16 Oct 2005 14:39:48 -0400</span><br />
</address>

James Cummings writes:
<br />
<em class="quotelev1">> Doesn't CSS3 (and earlier) allow for percentage widths and heights
</em><br />
<em class="quotelev1">> as well? Your datatype didn't seem to cope with this. 100%, 30%,
</em><br />
<em class="quotelev1">> etc.
</em><br />

Absolutely, they do. Does anyone think we should not add it, i.e. use 
<br />

data.outputMeasurement =
<br />
  xsd:token {
<br />
    pattern =
<br />
      "[\-+]?\d+(\.\d+)?(%|cm|mm|in|pt|pc|px|em|ex|gd|rem|vw|vh|vm)"
<br />
  }
<br />

?
<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 Oct 16 2005 - 14:39:59 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sun Oct 16 17:44:01 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 16 Oct 2005 17:44:01 -0400
Subject: [tei-council] report on rng:text attribute sweep
Message-ID: <17234.51617.851672.284870@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, 16 Oct 2005 17:44:01 -0400</span><br />
</address>

Here's the list of changes made in my recent sweep to root out the
<br />
remaining rng:text attributes. 
<br />
* Names of classes are delimited by "%" and ";" even though they are
<br />
  no longer expressed as parameter entities, just because I don't have
<br />
  a better way to make them stand out.
<br />
* Names of elements, attributes, and classes are as they were at the
<br />
  time; some of them have changed since.
<br />

--------- altered ---------
<br />
indexName=   of <index>               -> data.ident
<br />
width=       of <binaryObject>        -> data.htmlDimension /* also of <graphic> */
<br />
height=      of <binaryObject>        -> data.htmlDimension /* also of <graphic> */
<br />
scale=       of <binaryObject>        -> data.numeric
<br />
type=        of %att.entryLike;       -> data.enumerated
<br />
level=       of <sense>               -> data.numeric [1]
<br />
type=        of <form>                -> data.enumerated
<br />
extent=      of <orth>                -> data.enumerated
<br />
extent=      of <pron>                -> data.enumerated
<br />
type=        of <gram>                -> data.enumerated
<br />
type=        of <itype>               -> data.enumerated; also changed GI to <iType>
<br />
type=        of <colloc>              -> data.name /* EDW90 says enumerated [2] */
<br />
type=        of <usg>                 -> data.enumerated
<br />
type=        of <lbl>                 -> data.name /* EDW90 says enumerated [2] */
<br />
type=        of <re>                  -> data.name /* EDW90 says enumerated [2] */
<br />
type=        of <oRef>                -> data.enumerated
<br />
type=        of <oVar>                -> data.enumerated
<br />
placeAttrib= of <origPlace>           -> data.enumerated
<br />
evidence=    of <origPlace>           -> data.enumerated
<br />
unit=        of %att.measured;        -> data.enumerated
<br />
scope=       of %att.measured;        -> data.enumerated
<br />
certainty=   of %model.pPart.datable; -> data.enumerated
<br />
dateAttrib=  of %model.pPart.datable; -> data.enumerated
<br />
evidence=    of %model.pPart.datable; -> data.enumerated
<br />
notAfter=    of %model.pPart.datable; -> data.temporal
<br />
notBefore=   of %model.pPart.datable; -> data.temporal
<br />
interval=    of <when>                -> specialized; also interval= of <timeline> [3]
<br />
type=        of %att.pointing;        -> data.name  /* EDW90 says enumerated [2] */
<br />
lemma=       of <w>                   -> data.name  /* must become element, eh? */
<br />
baseForm=    of <m>                   -> data.name  /* must become element, eh? */
<br />
type=        of %att.textCritical;    -> data.enumerated
<br />
cause=       of %att.textCritical;    -> data.enumerated
<br />
key=         of %att.personal;        -> DELETED
<br />
key=         of %att.datePart;        -> DELETED [4]
<br />
type=        of %att.datePart;        -> data.name
<br />
mode=        of %att.identified;      -> data.enumerated
<br />
mode=        of <valDesc>             -> data.enumerated
<br />
mode=        of <valList>             -> data.enumerated
<br />
key=         of <attRef>              -> data.ident
<br />
type=        of <schemaSpec>          -> data.name /* EDW90 says enumerated [2] */
<br />
ns=          of <schemaSpec>          -> data.namespace /* also ns= of <attDef> & <elementSpec> */
<br />

--------- stet ---------
<br />
n=           of %att.global; /* data.names problematic */
<br />
rend=        of %att.global;
<br />
key=         of %att.naming;
<br />
pat=         of <fragmentPattern> /* now replacementPattern= of <cRefPattern> */
<br />
delim=       of <state>
<br />
value=       of <metSym>
<br />
mimetype=    of <equiv>
<br />
sortKey=     of <term>
<br />
mimeType=    of <graphic>
<br />
mimeType=    of <binaryObject>
<br />
encoding=    of <binaryObject>
<br />
key=         of %att.entryLike; -- changed to sortKey=
<br />
expand=      of %att.lexicographic;  /* must become element, eh? */
<br />
norm=        of %att.lexicographic;  /* must become element, eh? */
<br />
split=       of %att.lexicographic;  /* must become element, eh? */
<br />
value=       of %att.lexicographic;  /* must become element, eh? */
<br />
orig=        of %att.lexicographic;  /* must become element, eh? */
<br />
reg=         of <orgName> /* needs to be handled by different mechanism */
<br />
reg=         of <orgTitle>/* needs to be handled by different mechanism */
<br />
reg=         of <orgType> /* needs to be handled by different mechanism */
<br />
reg=         of <orgDivn> /* needs to be handled by different mechanism */
<br />
label=       of <graph>   /* slated to become child somehow; data.names problematic */
<br />
label=       of <node>    /* slated to become child somehow; data.names problematic */
<br />
label2=      of <node>    /* slated to become child somehow; data.names problematic */
<br />
label=       of <arc>     /* slated to become child somehow; data.names problematic */
<br />
label2=      of <arc>     /* slated to become child somehow; data.names problematic */
<br />
label=       of <tree>    /* slated to become child somehow; data.names problematic */
<br />
label=       of <root>    /* slated to become child somehow; data.names problematic */
<br />
label=       of <iNode>   /* slated to become child somehow; data.names problematic */
<br />
label=       of <leaf>    /* slated to become child somehow; data.names problematic */
<br />
label=       of <eTree>   /* slated to become child somehow; data.names problematic */
<br />
label=       of <triangle>/* slated to become child somehow; data.names problematic */
<br />
label=       of <eLeaf>   /* slated to become child somehow; data.names problematic */
<br />

Notes
<br />
-----
<br />
[1] I still think this is a bad idea. The data.numeric type permits
<br />
    negative values, fractions, and numbers way outside the bounds of
<br />
    possibility here. xsd:unsignedByte is much closer to what we want
<br />
    (and is a straight W3C type, to boot): an integer between 0 and
<br />
    255 (inclusive). Could also use xsd:nonNegativeInteger {
<br />
    maxInclusive="whatever-number-we-agree-on" }
<br />

[2] The problem here is that we have not yet really hammered down the
<br />
    relationship between the use of the data.enumerated type and the
<br />
    existence of a <valList>. It has been suggested (I think by
<br />
    several different people, myself & Lou included) that the
<br />
    relationship should be iff -- i.e., if there is a <valList>, then
<br />
    datatype must be data.enumerated; if the datatype is
<br />
    data.enumerated, then there must be a <valList>. This system has
<br />
    its appeal, but also has problems (which I hope to address
<br />
    later). For these attributes, I have recommended in EDW90 that
<br />
    the type be data.enumerated, but no one has come up with a
<br />
    suggested value list. Thus I have made the datatype data.name
<br />
    instead, at least for now. In retrospect, probably should have
<br />
    been data.ident, but I'm hoping we come up with value lists
<br />
    instead, anyway.
<br />

[3] The attribute type is essentially that which I suggested on this
<br />
    list almost a month ago (2005-09-20), and which I think Lou
<br />
    doesn't like. But no one has suggested anything better. It is
<br />
    currently 
<br />
       xsd:float { minExclusive = "0" } | "unknown"
<br />
    for <when>, and
<br />
       xsd:float { minExclusive = "0" } | "regular" | "irregular"
<br />
    for <timeline>. This mimics P4 pretty well. I, for one, would be
<br />
    happy if we came up with a better method altogether.
<br />

[4] Also fixed value= which had been a choice of lots of xsd, and is
<br />
    now data.temporal
<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 Oct 16 2005 - 17:44:10 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Oct 18 05:03:36 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 18 Oct 2005 10:03:36 +0100
Subject: [tei-council] dateable elements
In-Reply-To: <4354B6EB.8030900@oucs.ox.ac.uk>
Message-ID: <4354BA68.8070601@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, 18 Oct 2005 10:03:36 +0100</span><br />
</address>

James Cummings wrote (privately, but I am sure he wont mind me posting):
<br />

<em class="quotelev1">>Not as long as the attributes don't go missing. :-)  But really I think that the
</em><br />
<em class="quotelev1">>date/time stuff needs to be sat down and looked at again overall.  I don't mind
</em><br />
<em class="quotelev1">>us using the funny W3C implementation of iso8601, but think we should make sure
</em><br />
<em class="quotelev1">>we are now being consistent throughout all our date/time representations.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
It seems to me that the case for a genuine new work group to look
<br />
at times, dates, places, names, and people is now clear.
<br />

How can we acquire a work group leader, or should we just
<br />
ask for volunteers?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Oct 18 2005 - 05:04:01 EDT</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Tue Oct 18 05:06:57 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 18 Oct 2005 10:06:57 +0100
Subject: [tei-council] dateable elements
In-Reply-To: <4354BA68.8070601@oucs.ox.ac.uk>
Message-ID: <4354BB31.9050205@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, 18 Oct 2005 10:06:57 +0100</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev1">> James Cummings wrote (privately, but I am sure he wont mind me posting):
</em><br />

Indeed, posting it privately was in fact an error.
<br />

<em class="quotelev1">> It seems to me that the case for a genuine new work group to look
</em><br />
<em class="quotelev1">> at times, dates, places, names, and people is now clear.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> How can we acquire a work group leader, or should we just
</em><br />
<em class="quotelev1">> ask for volunteers?
</em><br />

I'm happy to volunteer to be part of such a group, but do not want to lead 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> Tue Oct 18 2005 - 05:07:30 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Oct 18 05:33:21 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 18 Oct 2005 10:33:21 +0100
Subject: [tei-council] Re: 'token' classes
In-Reply-To: <BF73B058-749A-48EF-8E23-942F054E2C85@loria.fr>
Message-ID: <4354C161.7030005@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, 18 Oct 2005 10:33:21 +0100</span><br />
</address>

Yes, precisely. I am hoping to draft a revision of the section of 
<br />
chapter ST concerned to address this point a little more firmly later on 
<br />
today.
<br />

  Laurent Romary wrote:
<br />

<em class="quotelev1">> I also agree with this option, but I would suggest to tackle it from  a 
</em><br />
<em class="quotelev1">> more semantic point of view (instead of pure syntactic constraint  of 
</em><br />
<em class="quotelev1">> having white spaces or not in the type attribute).
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> What we want (maybe...) is to consider that the type attribute  contains 
</em><br />
<em class="quotelev1">> a code or identifier (not necessarily in the sense of xml)  that is 
</em><br />
<em class="quotelev1">> related to a predefined classification of a given object. We  should 
</em><br />
<em class="quotelev1">> state that strongly somewhere so that it gives encoders the  instruction 
</em><br />
<em class="quotelev1">> to actually +think+ of the general picture in which a  given value for 
</em><br />
<em class="quotelev1">> type will be considered. Typically, the possible  types of division in a 
</em><br />
<em class="quotelev1">> corpus (<div>) the various grammatical  features he wants to use in a 
</em><br />
<em class="quotelev1">> dictionary (<gram>) etc.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Laurent
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Le 18 oct. 05 ? 10:41, James Cummings a ?crit :
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>> Syd Bauman wrote:
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev4">>>>> I think we can proceed with two datatypes (Syd's data.name(s) and
</em><br />
<em class="quotelev4">>>>> data.token(s), for the sake of argument) and add a third one later
</em><br />
<em class="quotelev4">>>>> after review?
</em><br />
<em class="quotelev4">>>>>
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev3">>>> I think that's a good idea. If users all over the world scream for
</em><br />
<em class="quotelev3">>>> the capability to put spaces into their type= attributes, we can
</em><br />
<em class="quotelev3">>>> rethink this. If you & Christian are the only two, you know how to
</em><br />
<em class="quotelev3">>>> customize TEI yourselves ... :-)
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev3">>>> I think Lou will be vindicated, and most no one will really think
</em><br />
<em class="quotelev3">>>> it's horrible to say "collar,dog" as opposed to "dog collar".
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> Just to say that I think having no spaces in type attributes (or  only 
</em><br />
<em class="quotelev2">>> having
</em><br />
<em class="quotelev2">>> spaces in similar attributes when they are real separate tokens (or  
</em><br />
<em class="quotelev2">>> whatever))
</em><br />
<em class="quotelev2">>> is a good idea.  I am happy to be convinced otherwise, but it seems  a 
</em><br />
<em class="quotelev2">>> perfectly
</em><br />
<em class="quotelev2">>> reasonable restriction which will stop people doing <div type="The  
</em><br />
<em class="quotelev2">>> chapter where
</em><br />
<em class="quotelev2">>> she gets killed"> or something silly.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> -J
</em><br />
<em class="quotelev2">>> -- 
</em><br />
<em class="quotelev2">>> Dr James Cummings, Oxford Text Archive, University of Oxford
</em><br />
<em class="quotelev2">>> James dot Cummings at oucs dot ox dot ac dot uk
</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 />

<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 Oct 18 2005 - 05:15:43 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Oct 18 05:39:59 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 18 Oct 2005 10:39:59 +0100
Subject: [tei-council] [Fwd: Re: 'token' classes]
Message-ID: <4354C2EF.6040301@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, 18 Oct 2005 10:39:59 +0100</span><br />
</address>

-------- Original Message --------
<br />
Subject: Re: 'token' classes
<br />
Date: Tue, 18 Oct 2005 10:38:09 +0100
<br />
From: Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk>
<br />
To: Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk>
<br />
References: <200510170247.j9H2lc20018933_at_pyxis.<!--nospam-->services.brown.edu> 
<br />
<4353C406.9040809_at_oucs.<!--nospam-->ox.ac.uk> 
<br />
<17235.55628.147721.610665_at_emt.<!--nospam-->wwp.brown.edu> 
<br />
<4353DA50.6060303_at_oucs.<!--nospam-->ox.ac.uk> 
<br />
<ygf4q7f6acj.fsf_at_kanji.<!--nospam-->zinbun.kyoto-u.ac.jp> 
<br />
<435427A8.9060603_at_oucs.<!--nospam-->ox.ac.uk> 
<br />
<17236.12940.860584.793970_at_emt.<!--nospam-->wwp.brown.edu> 
<br />
<4354B54C.1080404_at_oucs.<!--nospam-->ox.ac.uk> 
<br />
<BF73B058-749A-48EF-8E23-942F054E2C85_at_loria.<!--nospam-->fr> 
<br />
<4354BD4E.4030408_at_oucs.<!--nospam-->ox.ac.uk>
<br />

Sebastian Rahtz wrote:
<br />

<em class="quotelev1">> Laurent Romary wrote:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>What we want (maybe...) is to consider that the type attribute 
</em><br />
<em class="quotelev2">>>contains a code or identifier (not necessarily in the sense of xml) 
</em><br />
<em class="quotelev2">>>that is related to a predefined classification of a given object. We 
</em><br />
<em class="quotelev2">>>should state that strongly somewhere so that it gives encoders the 
</em><br />
<em class="quotelev2">>>instruction to actually +think+ of the general picture in which a 
</em><br />
<em class="quotelev2">>>given value for type will be considered. Typically, the possible 
</em><br />
<em class="quotelev2">>>types of division in a corpus (<div>) the various grammatical 
</em><br />
<em class="quotelev2">>>features he wants to use in a dictionary (<gram>) etc.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> This is fine, but why do you consider that a code or identier has no
</em><br />
<em class="quotelev1">> spaces? my identifer is "Sebastian Rahtz", not some
</em><br />
<em class="quotelev1">> artificial construction like "Sebastian_Rahtz".
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />

Au contraire, your name may well be "Sebastian Rahtz" (and tagged as
<br />
such by <name>) but your identification is precisely likely to be an
<br />
artificial construction of some kind. Suince it's artificial we can
<br />
plausibbly make up rules about whether or not it has spaces.
<br />

That said, I think this discussion gas led to me finally understanding
<br />
why W3C use the word "token" the way they do == and seeing it as not
<br />
implausible.
<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 Oct 18 2005 - 05:22:12 EDT</span>
</div>

From Laurent.Romary at loria.fr  Tue Oct 18 05:22:47 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Tue, 18 Oct 2005 11:22:47 +0200
Subject: [tei-council] dateable elements
In-Reply-To: <4354BB31.9050205@computing-services.oxford.ac.uk>
Message-ID: <4F7A2484-0252-48FC-9E45-1F326B711251@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, 18 Oct 2005 11:22:47 +0200</span><br />
</address>

I would also like to contribute, but would be an awful leader in the  
<br />
current context...
<br />
Laurent
<br />

Le 18 oct. 05 ? 11:06, James Cummings a ?crit :
<br />

<em class="quotelev1">> Sebastian Rahtz wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> James Cummings wrote (privately, but I am sure he wont mind me  
</em><br />
<em class="quotelev2">>> posting):
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Indeed, posting it privately was in fact an error.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> It seems to me that the case for a genuine new work group to look
</em><br />
<em class="quotelev2">>> at times, dates, places, names, and people is now clear.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> How can we acquire a work group leader, or should we just
</em><br />
<em class="quotelev2">>> ask for volunteers?
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I'm happy to volunteer to be part of such a group, but do not want  
</em><br />
<em class="quotelev1">> to lead it.
</em><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.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 />

_______________________________________________
<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 Oct 18 2005 - 05:22:51 EDT</span>
</div>

From Laurent.Romary at loria.fr  Tue Oct 18 05:30:34 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Tue, 18 Oct 2005 11:30:34 +0200
Subject: [tei-council] [Fwd: Re: 'token' classes]
In-Reply-To: <4354C2EF.6040301@computing-services.oxford.ac.uk>
Message-ID: <E82FF6A2-F71E-4075-85ED-BBFBD4BAD346@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, 18 Oct 2005 11:30:34 +0200</span><br />
</address>

As usual, Lou expresses my view better than I do myself...
<br />
I agree,
<br />
Laurent
<br />

Le 18 oct. 05 ? 11:39, Lou Burnard a ?crit :
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> -------- Original Message --------
</em><br />
<em class="quotelev1">> Subject: Re: 'token' classes
</em><br />
<em class="quotelev1">> Date: Tue, 18 Oct 2005 10:38:09 +0100
</em><br />
<em class="quotelev1">> From: Lou Burnard <lou.burnard_at_computing-services.oxford.ac.uk>
</em><br />
<em class="quotelev1">> To: Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk>
</em><br />
<em class="quotelev1">> References: <200510170247.j9H2lc20018933_at_pyxis.services.brown.edu>  
</em><br />
<em class="quotelev1">> <4353C406.9040809_at_oucs.ox.ac.uk>  
</em><br />
<em class="quotelev1">> <17235.55628.147721.610665_at_emt.wwp.brown.edu>  
</em><br />
<em class="quotelev1">> <4353DA50.6060303_at_oucs.ox.ac.uk>  
</em><br />
<em class="quotelev1">> <ygf4q7f6acj.fsf_at_kanji.zinbun.kyoto-u.ac.jp>  
</em><br />
<em class="quotelev1">> <435427A8.9060603_at_oucs.ox.ac.uk>  
</em><br />
<em class="quotelev1">> <17236.12940.860584.793970_at_emt.wwp.brown.edu> <4354B54C. 
</em><br />
<em class="quotelev1">> 1080404_at_oucs.ox.ac.uk>  
</em><br />
<em class="quotelev1">> <BF73B058-749A-48EF-8E23-942F054E2C85_at_loria.fr> <4354BD4E. 
</em><br />
<em class="quotelev1">> 4030408_at_oucs.ox.ac.uk>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Sebastian Rahtz wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> Laurent Romary wrote:
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev3">>>> What we want (maybe...) is to consider that the type attribute  
</em><br />
<em class="quotelev3">>>> contains a code or identifier (not necessarily in the sense of  
</em><br />
<em class="quotelev3">>>> xml) that is related to a predefined classification of a given  
</em><br />
<em class="quotelev3">>>> object. We should state that strongly somewhere so that it gives  
</em><br />
<em class="quotelev3">>>> encoders the instruction to actually +think+ of the general  
</em><br />
<em class="quotelev3">>>> picture in which a given value for type will be considered.  
</em><br />
<em class="quotelev3">>>> Typically, the possible types of division in a corpus (<div>) the  
</em><br />
<em class="quotelev3">>>> various grammatical features he wants to use in a dictionary  
</em><br />
<em class="quotelev3">>>> (<gram>) etc.
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev2">>> This is fine, but why do you consider that a code or identier has no
</em><br />
<em class="quotelev2">>> spaces? my identifer is "Sebastian Rahtz", not some
</em><br />
<em class="quotelev2">>> artificial construction like "Sebastian_Rahtz".
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Au contraire, your name may well be "Sebastian Rahtz" (and tagged as
</em><br />
<em class="quotelev1">> such by <name>) but your identification is precisely likely to be an
</em><br />
<em class="quotelev1">> artificial construction of some kind. Suince it's artificial we can
</em><br />
<em class="quotelev1">> plausibbly make up rules about whether or not it has spaces.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> That said, I think this discussion gas led to me finally understanding
</em><br />
<em class="quotelev1">> why W3C use the word "token" the way they do == and seeing it as not
</em><br />
<em class="quotelev1">> implausible.
</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.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 />

_______________________________________________
<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 Oct 18 2005 - 05:30:18 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Oct 18 20:00:23 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 19 Oct 2005 09:00:23 +0900
Subject: [tei-council] dateable elements
In-Reply-To: <4F7A2484-0252-48FC-9E45-1F326B711251@loria.fr>
Message-ID: <ygfmzl68jfs.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 19 Oct 2005 09:00:23 +0900</span><br />
</address>

<em class="quotelev3">>>> It seems to me that the case for a genuine new work group to look
</em><br />
<em class="quotelev3">>>> at times, dates, places, names, and people is now clear.
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev3">>>> How can we acquire a work group leader, or should we just
</em><br />
<em class="quotelev3">>>> ask for volunteers?
</em><br />

We will probably need to think whether this would be an ad-hoc task
<br />
force to look at these issues on a rather tight schedule, or whether
<br />
we want a full-blown WG that might look at the prosopography stuff as
<br />
well and takes its time (most likely 2-3 years?) to come up with
<br />
recommendations.
<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 Oct 18 2005 - 20:00:39 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Oct 19 03:06:06 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 19 Oct 2005 16:06:06 +0900
Subject: [tei-council] TEI Council report to MM 2005
Message-ID: <ygf7jcaq941.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 19 Oct 2005 16:06:06 +0900</span><br />
</address>

Dear Council members,
<br />

I have drafted a report to the members meeting.  It is now available
<br />
at
<br />
http://www.kanji.zinbun.kyoto-u.ac.jp/~wittern/tei/mm05councilreport.html
<br />
for your review.  Please look at this and report anything that you
<br />
feel is missing or weird here.  I would like to finalize this Friday
<br />
and hand it over to Lou for publication on the Website, so please give
<br />
me your comments now.
<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> Wed Oct 19 2005 - 03:06:16 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Oct 19 05:04:10 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Oct 2005 10:04:10 +0100
Subject: [tei-council] dateable elements
In-Reply-To: <ygfmzl68jfs.fsf@chwpb.local>
Message-ID: <43560C0A.5080509@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, 19 Oct 2005 10:04:10 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>We will probably need to think whether this would be an ad-hoc task
</em><br />
<em class="quotelev1">>force to look at these issues on a rather tight schedule
</em><br />
<em class="quotelev1">>
</em><br />
I am inclined to think we ought to do _something_ soon
<br />

<em class="quotelev1">> or whether
</em><br />
<em class="quotelev1">>we want a full-blown WG that might look at the prosopography stuff as
</em><br />
<em class="quotelev1">>well and takes its time (most likely 2-3 years?) to come up with
</em><br />
<em class="quotelev1">>recommendations.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
this is the internet age now, of course; so we can compress that
<br />
to one year.....
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Oct 19 2005 - 05:04:37 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Oct 19 06:26:13 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Oct 2005 11:26:13 +0100
Subject: [tei-council] TEI Council report to MM 2005
In-Reply-To: <ygf7jcaq941.fsf@chwpb.local>
Message-ID: <43561F45.2030706@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, 19 Oct 2005 11:26:13 +0100</span><br />
</address>

looks convincing enough
<br />

I am not sure we want people reading or commenting on EDW90 any more,
<br />
though?
<br />
thats now of historical interest, I'd say
<br />

and "Nice" is not spelt "Nizza" :-}
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Oct 19 2005 - 06:26:39 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Oct 19 18:30:05 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 20 Oct 2005 07:30:05 +0900
Subject: [tei-council] TEI Council report to MM 2005
In-Reply-To: <43561F45.2030706@oucs.ox.ac.uk>
Message-ID: <ygfwtk9jg2a.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 20 Oct 2005 07:30:05 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk> writes:
<br />

<em class="quotelev1">> looks convincing enough
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I am not sure we want people reading or commenting on EDW90 any more,
</em><br />
<em class="quotelev1">> though?
</em><br />
<em class="quotelev1">> thats now of historical interest, I'd say
</em><br />

Well, the report is supposed to reflect the history.  As to the
<br />
commenting, if somebody wants to look there and has something useful
<br />
to say, I would like to hear it.
<br />

<p><em class="quotelev1">>
</em><br />
<em class="quotelev1">> and "Nice" is not spelt "Nizza" :-}
</em><br />
<em class="quotelev1">>
</em><br />
Oops, thank you. 
<br />

I updated the document to reflect both comments.
<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> Wed Oct 19 2005 - 18:30:23 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Oct 19 18:33:49 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 20 Oct 2005 07:33:49 +0900
Subject: [tei-council] dateable elements
In-Reply-To: <43560C0A.5080509@oucs.ox.ac.uk>
Message-ID: <ygfsluxjfw2.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 20 Oct 2005 07:33:49 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk> writes:
<br />

<em class="quotelev1">> Christian Wittern wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>We will probably need to think whether this would be an ad-hoc task
</em><br />
<em class="quotelev2">>>force to look at these issues on a rather tight schedule
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> I am inclined to think we ought to do _something_ soon
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> or whether
</em><br />
<em class="quotelev2">>>we want a full-blown WG that might look at the prosopography stuff as
</em><br />
<em class="quotelev2">>>well and takes its time (most likely 2-3 years?) to come up with
</em><br />
<em class="quotelev2">>>recommendations.
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> this is the internet age now, of course; so we can compress that
</em><br />
<em class="quotelev1">> to one year.....
</em><br />

Hear, hear.  I wonder if one year is soon enough though?
<br />

For quick action, I would like to ask for somebody to volunteer to act
<br />
as chair for this from our midst with the mandate to collect further
<br />
input from where she thinks suitable.
<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> Wed Oct 19 2005 - 18:34:07 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Oct 19 18:33:36 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Oct 2005 23:33:36 +0100
Subject: [tei-council] TEI Council report to MM 2005
In-Reply-To: <ygfwtk9jg2a.fsf@chwpb.local>
Message-ID: <4356C9C0.4080704@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, 19 Oct 2005 23:33:36 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>Well, the report is supposed to reflect the history.  As to the
</em><br />
<em class="quotelev1">>commenting, if somebody wants to look there and has something useful
</em><br />
<em class="quotelev1">>to say, I would like to hear it.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
yes, of course. I just wondered about so actively referring them
<br />
to the report on which the work was based, rather than the
<br />
work itself.
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Oct 19 2005 - 18:34:17 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Oct 19 18:37:06 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Oct 2005 23:37:06 +0100
Subject: [tei-council] dateable elements
In-Reply-To: <ygfsluxjfw2.fsf@chwpb.local>
Message-ID: <4356CA92.6010809@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, 19 Oct 2005 23:37:06 +0100</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>For quick action, I would like to ask for somebody to volunteer to act
</em><br />
<em class="quotelev1">>as chair for this from our midst with the mandate to collect further
</em><br />
<em class="quotelev1">>input from where she thinks suitable.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
If somebody would give me a job where I was paid
<br />
to work on the TEI, I'd be delighted to do this.
<br />
Anyone here got a vacancy? (no, really, I need
<br />
a change).
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Oct 19 2005 - 18:37:44 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Oct 19 18:48:02 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Oct 2005 23:48:02 +0100
Subject: [tei-council] P5 version 0.2.1
Message-ID: <4356CD22.4090403@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, 19 Oct 2005 23:48:02 +0100</span><br />
</address>

I am unilaterally declaring 0.2.1 to be frozen.
<br />

I have to burn CDs for the members meeting tomorrow,
<br />
so this is as late as I can leave it. I propose to give all attendees
<br />
a TEI Knoppix with the current state of affairs.
<br />

I probably won't get the packages etc onto Sourceforge
<br />
until the weekend, so there is technically still time to find
<br />
disasters, for those who want to give me a hard time.
<br />

What, no testing phase, you say? No, no testing phase :-}
<br />
You'll have to trust that Syd and Lou have run "make test"
<br />
a few million times.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Oct 19 2005 - 18:48:31 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Thu Oct 20 09:57:12 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 20 Oct 2005 09:57:12 -0400
Subject: [tei-council] sex confession
Message-ID: <17239.41528.319553.941346@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, 20 Oct 2005 09:57:12 -0400</span><br />
</address>

Last night I got a few datatype fixes into P5 just before Sebastian
<br />
went off to make the released version and press CDs for the Members'
<br />
Meeting. Of those half a dozen or so fixes, I goofed one: sex= of
<br />
<personGrp>. I not only didn't I fix it, I made it worse.
<br />

It had a <valList> that didn't match the datatype. I have no idea
<br />
what kind of drugs I was on, but in my haste rather than do the right
<br />
thing (simply delete the <valList>), I changed the <valList> to more
<br />
closely match the datatype. So now, instead of matching sex= of
<br />
<person>, the sex= attribute of <personGrp> is idiotic. Ignore it.
<br />
It will be fixed in CVS by this time tomorrow.
<br />

However, it did raise an important issue about this particular
<br />
datatype.
<br />

Problem
<br />
-------
<br />
We agreed to use ISO 5218 codes for the value of sex= of <person> and
<br />
<personGrp>:
<br />
    * 0 = not known,
<br />
    * 1 = male,
<br />
    * 2 = female,
<br />
    * 9 = not specified.
<br />
However, <personGrp> (at least as P4 conceives it) requires an
<br />
additional value: "mixed" -- the group contains people of different
<br />
sexes.
<br />

Solutions
<br />
---------
<br />
Some possible solutions are:
<br />
1. Add a new numeric code, say "7", that means "mixed", to data.sex.
<br />
2. Use
<br />
     attribute sex { data.sex | "mixed" }
<br />
   for sex= of <personGrp>
<br />
3. Change the datatype so that the values are "not known", "male",
<br />
   "female", and "not specified", and then use #2.
<br />
4. Remove "mixed" from the possible values of sex= of <personGrp> and
<br />
   either
<br />
   a) say "you can't say that -- tough", or
<br />
   b) say "if sex= is *not* specified, it is presumed to be mixed"
<br />
5. Remove sex= from <personGrp> entirely -- if you want to know,
<br />
   check the children[1]
<br />

At the moment I am leaning towards #2, at least until those who work
<br />
on our "prosopography" work on the issue. With this solution the
<br />
datatype still maps cleanly to ISO, and it is very clear which values
<br />
of sex= of <personGrp> are from ISO (numeric codes) and which are
<br />
made up by TEI (contain letters).
<br />

<p>Note
<br />

----
[1] The following fragment of XSLT 1.1 does the job iff there are
    only male and female children. One could obviously extend this to
    cover the "not known" and "not specified" cases as well.
  <xsl:template match="personGrp">
    <xsl:variable name="sex">
      <xsl:choose>
        <xsl:when test="count(./person[@sex='1']) = 0 and count(.<!--nospam-->/person[@sex='2']) > 0">
          <xsl:text>all female</xsl:text>
        </xsl:when>
        <xsl:when test="count(./person[@sex='1']) > 0 and count(.<!--nospam-->/person[@sex='2']) = 0">
          <xsl:text>all male</xsl:text>
        </xsl:when>
        <xsl:when test="count(./person[@sex='1']) > 0 and count(.<!--nospam-->/person[@sex='2']) > 0">
          <xsl:text>mixed company</xsl:text>
        </xsl:when>
      </xsl:choose>
    </xsl:variable>
    <xsl:message>
      personGrp # <xsl:value-of select="@n"/> is <xsl:value-of select="$sex"/>.<!--nospam-->
    </xsl:message>
  </xsl:template>
   Of course, one could go a lot further:
        <xsl:when test="count(./person[@sex='1']) > 0.<!--nospam-->6 * count(./person)">
          <xsl:text>mostly male</xsl:text>
        </xsl:when>
        <xsl:when test="count(./person[@sex='2']) > 0.<!--nospam-->6 * count(./person)">
          <xsl:text>mostly female</xsl:text>
        </xsl:when>
   (BTW, I'm not claiming this is *good* XSLT code, just proof of
   concept.)
_______________________________________________
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 Oct 20 2005 - 09:57:22 EDT</span>
</div>

From Julia_Flanders at Brown.edu  Thu Oct 20 10:17:13 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 20 Oct 2005 10:17:13 -0400
Subject: [tei-council] TEI Council report to MM 2005
In-Reply-To: <ygf7jcaq941.fsf@chwpb.local>
Message-ID: <a06200741bf7d57113fa0@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 20 Oct 2005 10:17:13 -0400</span><br />
</address>

Christian, it looks good to me. I like your house renovation metaphor 
<br />
(though as anyone who has been through a house renovation knows, it's 
<br />
one that projects an unending future of renovations :-) or maybe they 
<br />
do these things better in Germany!
<br />

best wishes, Julia
<br />

<em class="quotelev1">>Dear Council members,
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I have drafted a report to the members meeting.  It is now available
</em><br />
<em class="quotelev1">>at
</em><br />
<em class="quotelev1">>http://www.kanji.zinbun.kyoto-u.ac.jp/~wittern/tei/mm05councilreport.html
</em><br />
<em class="quotelev1">>for your review.  Please look at this and report anything that you
</em><br />
<em class="quotelev1">>feel is missing or weird here.  I would like to finalize this Friday
</em><br />
<em class="quotelev1">>and hand it over to Lou for publication on the Website, so please give
</em><br />
<em class="quotelev1">>me your comments now.
</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="quotelev1">>
</em><br />
<em class="quotelev1">>  Christian Wittern
</em><br />
<em class="quotelev1">>  Institute for Research in Humanities, Kyoto University
</em><br />
<em class="quotelev1">>  47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
</em><br />
<em class="quotelev1">>_______________________________________________
</em><br />
<em class="quotelev1">>tei-council mailing list
</em><br />
<em class="quotelev1">>tei-council_at_lists.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 Oct 20 2005 - 10:17:19 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Oct 20 11:16:17 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 20 Oct 2005 16:16:17 +0100
Subject: [tei-council] sex confession
In-Reply-To: <17239.41528.319553.941346@emt.wwp.brown.edu>
Message-ID: <4357B4C1.4080208@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, 20 Oct 2005 16:16:17 +0100</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>Solutions
</em><br />
<em class="quotelev1">>---------
</em><br />
<em class="quotelev1">>Some possible solutions are:
</em><br />
<em class="quotelev1">>1. Add a new numeric code, say "7", that means "mixed", to data.sex.
</em><br />
<em class="quotelev1">>2. Use
</em><br />
<em class="quotelev1">>     attribute sex { data.sex | "mixed" }
</em><br />
<em class="quotelev1">>   for sex= of <personGrp>
</em><br />
<em class="quotelev1">>3. Change the datatype so that the values are "not known", "male",
</em><br />
<em class="quotelev1">>   "female", and "not specified", and then use #2.
</em><br />
<em class="quotelev1">>4. Remove "mixed" from the possible values of sex= of <personGrp> and
</em><br />
<em class="quotelev1">>   either
</em><br />
<em class="quotelev1">>   a) say "you can't say that -- tough", or
</em><br />
<em class="quotelev1">>   b) say "if sex= is *not* specified, it is presumed to be mixed"
</em><br />
<em class="quotelev1">>5. Remove sex= from <personGrp> entirely -- if you want to know,
</em><br />
<em class="quotelev1">>   check the children[1]
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
My preference is for 4, followed by 5,  followed by 2.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Thu Oct 20 2005 - 11:16:52 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Thu Oct 20 11:22:58 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 20 Oct 2005 16:22:58 +0100
Subject: [tei-council] sex confession
In-Reply-To: <4357B4C1.4080208@oucs.ox.ac.uk>
Message-ID: <4357B652.8010101@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, 20 Oct 2005 16:22:58 +0100</span><br />
</address>

On the positive side, it's a good test to see if you have a real 0.2.1
<br />
TEI installed - just look
<br />
at <personGrp> and check you see the anomaly. If you do, you have the
<br />
version
<br />
of P5 which was current from 2200 GMT yesterday to 0900 GMT today (when
<br />
I froze things).
<br />

Gosh, making a new release of the TEI files everywhere they ought to be
<br />
is an exhausting process.
<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> Thu Oct 20 2005 - 11:23:29 EDT</span>
</div>

From Julia_Flanders at Brown.edu  Thu Oct 20 11:24:24 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 20 Oct 2005 11:24:24 -0400
Subject: [tei-council] sex confession
In-Reply-To: <17239.41528.319553.941346@emt.wwp.brown.edu>
Message-ID: <a06200747bf7d655296f8@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 20 Oct 2005 11:24:24 -0400</span><br />
</address>

Solution 2 sounds reasonable to me. I like the fact that it makes a 
<br />
clear distinction between the ISO codes and the value which is not a 
<br />
member thereof.
<br />

Julia
<br />

<em class="quotelev1">>Problem
</em><br />
<em class="quotelev1">>-------
</em><br />
<em class="quotelev1">>We agreed to use ISO 5218 codes for the value of sex= of <person> and
</em><br />
<em class="quotelev1">><personGrp>:
</em><br />
<em class="quotelev1">>     * 0 = not known,
</em><br />
<em class="quotelev1">>     * 1 = male,
</em><br />
<em class="quotelev1">>     * 2 = female,
</em><br />
<em class="quotelev1">>     * 9 = not specified.
</em><br />
<em class="quotelev1">>However, <personGrp> (at least as P4 conceives it) requires an
</em><br />
<em class="quotelev1">>additional value: "mixed" -- the group contains people of different
</em><br />
<em class="quotelev1">>sexes.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Solutions
</em><br />
<em class="quotelev1">>---------
</em><br />
<em class="quotelev1">>Some possible solutions are:
</em><br />
<em class="quotelev1">>1. Add a new numeric code, say "7", that means "mixed", to data.sex.
</em><br />
<em class="quotelev1">>2. Use
</em><br />
<em class="quotelev1">>      attribute sex { data.sex | "mixed" }
</em><br />
<em class="quotelev1">>    for sex= of <personGrp>
</em><br />
<em class="quotelev1">>3. Change the datatype so that the values are "not known", "male",
</em><br />
<em class="quotelev1">>    "female", and "not specified", and then use #2.
</em><br />
<em class="quotelev1">>4. Remove "mixed" from the possible values of sex= of <personGrp> and
</em><br />
<em class="quotelev1">>    either
</em><br />
<em class="quotelev1">>    a) say "you can't say that -- tough", or
</em><br />
<em class="quotelev1">>    b) say "if sex= is *not* specified, it is presumed to be mixed"
</em><br />
<em class="quotelev1">>5. Remove sex= from <personGrp> entirely -- if you want to know,
</em><br />
<em class="quotelev1">>    check the children[1]
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>At the moment I am leaning towards #2, at least until those who work
</em><br />
<em class="quotelev1">>on our "prosopography" work on the issue. With this solution the
</em><br />
<em class="quotelev1">>datatype still maps cleanly to ISO, and it is very clear which values
</em><br />
<em class="quotelev1">>of sex= of <personGrp> are from ISO (numeric codes) and which are
</em><br />
<em class="quotelev1">>made up by TEI (contain letters).
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Note
</em><br />
<em class="quotelev1">>----
</em><br />
<em class="quotelev1">>[1] The following fragment of XSLT 1.1 does the job iff there are
</em><br />
<em class="quotelev1">>     only male and female children. One could obviously extend this to
</em><br />
<em class="quotelev1">>     cover the "not known" and "not specified" cases as well.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>   <xsl:template match="personGrp">
</em><br />
<em class="quotelev1">>     <xsl:variable name="sex">
</em><br />
<em class="quotelev1">>       <xsl:choose>
</em><br />
<em class="quotelev1">>         <xsl:when test="count(./person[@sex='1']) = 0 and 
</em><br />
<em class="quotelev1">>count(./person[@sex='2']) > 0">
</em><br />
<em class="quotelev1">>           <xsl:text>all female</xsl:text>
</em><br />
<em class="quotelev1">>         </xsl:when>
</em><br />
<em class="quotelev1">>         <xsl:when test="count(./person[@sex='1']) > 0 and 
</em><br />
<em class="quotelev1">>count(./person[@sex='2']) = 0">
</em><br />
<em class="quotelev1">>           <xsl:text>all male</xsl:text>
</em><br />
<em class="quotelev1">>         </xsl:when>
</em><br />
<em class="quotelev1">>         <xsl:when test="count(./person[@sex='1']) > 0 and 
</em><br />
<em class="quotelev1">>count(./person[@sex='2']) > 0">
</em><br />
<em class="quotelev1">>           <xsl:text>mixed company</xsl:text>
</em><br />
<em class="quotelev1">>         </xsl:when>
</em><br />
<em class="quotelev1">>       </xsl:choose>
</em><br />
<em class="quotelev1">>     </xsl:variable>
</em><br />
<em class="quotelev1">>     <xsl:message>
</em><br />
<em class="quotelev1">>       personGrp # <xsl:value-of select="@n"/> is <xsl:value-of 
</em><br />
<em class="quotelev1">>select="$sex"/>.
</em><br />
<em class="quotelev1">>     </xsl:message>
</em><br />
<em class="quotelev1">>   </xsl:template>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>    Of course, one could go a lot further:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>         <xsl:when test="count(./person[@sex='1']) > 0.<!--nospam-->6 * count(./person)">
</em><br />
<em class="quotelev1">>           <xsl:text>mostly male</xsl:text>
</em><br />
<em class="quotelev1">>         </xsl:when>
</em><br />
<em class="quotelev1">>         <xsl:when test="count(./person[@sex='2']) > 0.<!--nospam-->6 * count(./person)">
</em><br />
<em class="quotelev1">>           <xsl:text>mostly female</xsl:text>
</em><br />
<em class="quotelev1">>         </xsl:when>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>    (BTW, I'm not claiming this is *good* XSLT code, just proof of
</em><br />
<em class="quotelev1">>    concept.)
</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 Oct 20 2005 - 11:24:35 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Oct 20 18:38:36 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 21 Oct 2005 07:38:36 +0900
Subject: [tei-council] TEI Council report to MM 2005
In-Reply-To: <4357F422.6050204@umd.edu>
Message-ID: <ygf64rr24r7.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 21 Oct 2005 07:38:36 +0900</span><br />
</address>

Susan Schreibman <sschreib_at_umd.<!--nospam-->edu> writes:
<br />

<em class="quotelev1">> Hi Christian -- this report looks terrific. I wondered if it were
</em><br />
<em class="quotelev1">> possible to include a link to the mapping done by John and Natasha?
</em><br />

In fact I wondered about that as well.  In some minutes there is an
<br />
action item to put a link to this on the Activities page, but as far
<br />
as I can see this has never happened.  
<br />

John, Natasha -- can you give me a URL for this file? Preferrable on
<br />
the tei-c.org domain;-)
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I just wanted to tell you that I won't make the members meeting this
</em><br />
<em class="quotelev1">> year. I've just too many obligations with this new job. I hate to miss
</em><br />
<em class="quotelev1">> it, as it is the first one I'm not attending
</em><br />

Sorry to hear that.  I am sure it will be a memorable occasion.
<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> Thu Oct 20 2005 - 18:38:41 EDT</span>
</div>

From nsmith at email.unc.edu  Fri Oct 21 09:16:16 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Fri, 21 Oct 2005 09:16:16 -0400 (Eastern Daylight Time)
Subject: [tei-council] TEI Council report to MM 2005
In-Reply-To: <ygf64rr24r7.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <Pine.WNT.4.10.10510210913280.2912-100000@AALCD49.lib.unc.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Natasha Smith <nsmith_at_email.unc.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 21 Oct 2005 09:16:16 -0400 (Eastern Daylight Time)</span><br />
</address>

Christian:
<br />

It does look great. Your metaphor's so poetic and mentioning of Tubingen
<br />
brought wonderful memories - thank you!
<br />

I have rather nitpicking suggestions:
<br />

1.	"While in the past development took place mainly in workgroups
<br />
charged by the Council, this year the Council took on more and more tasks
<br />
by itself and did not charge any new workgroups this year." A bit
<br />
awkwardly stated and please delete one of two "this year"s mentioned in
<br />
the sentence.
<br />
2.	"one face to face meeting" - I think it should be  "face-to-face."
<br />
I leave it to native speakers...
<br />
3.	dubbed the "class meeting" - either needs a second comma after the
<br />
closing quotation or needs mdashes on both sides
<br />
4.	'the Council focussed" - should be "focused"; similarily - should
<br />
be similarly; fomat - change to format; metioned to mentioned; Liasion -
<br />
Liaison;  jon - join; 
<br />

As to the mapping, "an attempt to map metadata standards to the elements
<br />
in the TEIHeader" is still in the phase of "attempt". I hope that we can
<br />
finally move ahead with it once all of us(I mean catalogers and us) at the
<br />
same in the same place. John?
<br />

best, ns
<br />

<p><p>On Fri, 21 Oct 2005, Christian Wittern wrote:
<br />

<em class="quotelev1">> Susan Schreibman <sschreib_at_umd.edu> writes:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">> > Hi Christian -- this report looks terrific. I wondered if it were
</em><br />
<em class="quotelev2">> > possible to include a link to the mapping done by John and Natasha?
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> In fact I wondered about that as well.  In some minutes there is an
</em><br />
<em class="quotelev1">> action item to put a link to this on the Activities page, but as far
</em><br />
<em class="quotelev1">> as I can see this has never happened.  
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> John, Natasha -- can you give me a URL for this file? Preferrable on
</em><br />
<em class="quotelev1">> the tei-c.org domain;-)
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">> >
</em><br />
<em class="quotelev2">> > I just wanted to tell you that I won't make the members meeting this
</em><br />
<em class="quotelev2">> > year. I've just too many obligations with this new job. I hate to miss
</em><br />
<em class="quotelev2">> > it, as it is the first one I'm not attending
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Sorry to hear that.  I am sure it will be a memorable occasion.
</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">>  Christian Wittern 
</em><br />
<em class="quotelev1">>  Institute for Research in Humanities, Kyoto University
</em><br />
<em class="quotelev1">>  47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
</em><br />
<em class="quotelev1">> _______________________________________________
</em><br />
<em class="quotelev1">> tei-council mailing list
</em><br />
<em class="quotelev1">> tei-council_at_lists.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>_______________________________________________
<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 Oct 21 2005 - 09:17:06 EDT</span>
</div>

From Syd_Bauman at Brown.edu  Sat Oct 22 20:24:13 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 22 Oct 2005 20:24:13 -0400
Subject: [tei-council] sex confession
In-Reply-To: <a06200747bf7d655296f8@[128.148.157.102]>
Message-ID: <17242.55341.820563.529333@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, 22 Oct 2005 20:24:13 -0400</span><br />
</address>

<em class="quotelev2">> > 1. Add a new numeric code, say "7", that means "mixed", to data.sex.
</em><br />
<em class="quotelev2">> > 2. Use
</em><br />
<em class="quotelev2">> >      attribute sex { data.sex | "mixed" }
</em><br />
<em class="quotelev2">> >    for sex= of <personGrp>
</em><br />
<em class="quotelev2">> > 3. Change the datatype so that the values are "not known", "male",
</em><br />
<em class="quotelev2">> >    "female", and "not specified", and then use #2.
</em><br />
<em class="quotelev2">> > 4. Remove "mixed" from the possible values of sex= of <personGrp> and
</em><br />
<em class="quotelev2">> >    either
</em><br />
<em class="quotelev2">> >    a) say "you can't say that -- tough", or
</em><br />
<em class="quotelev2">> >    b) say "if sex= is *not* specified, it is presumed to be mixed"
</em><br />
<em class="quotelev2">> > 5. Remove sex= from <personGrp> entirely -- if you want to know,
</em><br />
<em class="quotelev2">> >    check the children[1]
</em><br />

JF> Solution 2 sounds reasonable to me. I like the fact that it makes
<br />
JF> a clear distinction between the ISO codes and the value which is
<br />
JF> not a member thereof.
<br />

SR> My preference is for 4, followed by 5,  followed by 2.
<br />

<p>I think 1 is a bad idea, as it's confusing, and what do we do when
<br />
ISO updates their standard and uses the number we picked?
<br />

I like 3, but have already been outvoted on that.
<br />

4a and 5 turn out to have a major problem -- a <personGrp> element
<br />
does not group a bunch of <person> elements, but rather just
<br />
describes the group. Thus it *needs* to be able to say "mixed", and I
<br />
can well imagine people wanting even more precision than that. (E.g.,
<br />
to be able to specify exact counts, or rough percentages, of each
<br />
sex.)
<br />

So I think we are down to 2 or 4b. For the moment I've checked in a
<br />
version that uses 2. Those who want to argue for 4b or a system that
<br />
allows more flexibility and precision should speak up now (and thus
<br />
be drafted for the <soCalled>prosopography</soCalled> WG! :-)
<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 Oct 22 2005 - 20:24:23 EDT</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Sun Oct 23 05:31:07 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 23 Oct 2005 10:31:07 +0100
Subject: [tei-council] sex confession
In-Reply-To: <17242.55341.820563.529333@emt.wwp.brown.edu>
Message-ID: <435B585B.4010404@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, 23 Oct 2005 10:31:07 +0100</span><br />
</address>

Sorry, I havent contributed to this discussion yet, being busy in Nancy 
<br />
(on which more anon), but just for the record my recommendation is for  4.b
<br />

Syd Bauman wrote:
<br />

<em class="quotelev3">>>>1. Add a new numeric code, say "7", that means "mixed", to data.sex.
</em><br />
<em class="quotelev3">>>>2. Use
</em><br />
<em class="quotelev3">>>>     attribute sex { data.sex | "mixed" }
</em><br />
<em class="quotelev3">>>>   for sex= of <personGrp>
</em><br />
<em class="quotelev3">>>>3. Change the datatype so that the values are "not known", "male",
</em><br />
<em class="quotelev3">>>>   "female", and "not specified", and then use #2.
</em><br />
<em class="quotelev3">>>>4. Remove "mixed" from the possible values of sex= of <personGrp> and
</em><br />
<em class="quotelev3">>>>   either
</em><br />
<em class="quotelev3">>>>   a) say "you can't say that -- tough", or
</em><br />
<em class="quotelev3">>>>   b) say "if sex= is *not* specified, it is presumed to be mixed"
</em><br />
<em class="quotelev3">>>>5. Remove sex= from <personGrp> entirely -- if you want to know,
</em><br />
<em class="quotelev3">>>>   check the children[1]
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> JF> Solution 2 sounds reasonable to me. I like the fact that it makes
</em><br />
<em class="quotelev1">> JF> a clear distinction between the ISO codes and the value which is
</em><br />
<em class="quotelev1">> JF> not a member thereof.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> SR> My preference is for 4, followed by 5,  followed by 2.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I think 1 is a bad idea, as it's confusing, and what do we do when
</em><br />
<em class="quotelev1">> ISO updates their standard and uses the number we picked?
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I like 3, but have already been outvoted on that.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 4a and 5 turn out to have a major problem -- a <personGrp> element
</em><br />
<em class="quotelev1">> does not group a bunch of <person> elements, but rather just
</em><br />
<em class="quotelev1">> describes the group. Thus it *needs* to be able to say "mixed", and I
</em><br />
<em class="quotelev1">> can well imagine people wanting even more precision than that. (E.g.,
</em><br />
<em class="quotelev1">> to be able to specify exact counts, or rough percentages, of each
</em><br />
<em class="quotelev1">> sex.)
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> So I think we are down to 2 or 4b. For the moment I've checked in a
</em><br />
<em class="quotelev1">> version that uses 2. Those who want to argue for 4b or a system that
</em><br />
<em class="quotelev1">> allows more flexibility and precision should speak up now (and thus
</em><br />
<em class="quotelev1">> be drafted for the <soCalled>prosopography</soCalled> WG! :-)
</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.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>_______________________________________________
<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 Oct 23 2005 - 05:13:19 EDT</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Oct 23 18:48:33 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 24 Oct 2005 07:48:33 +0900
Subject: [tei-council] sex confession
In-Reply-To: <435B585B.4010404@computing-services.oxford.ac.uk>
Message-ID: <ygfd5lvx326.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 24 Oct 2005 07:48:33 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> Sorry, I havent contributed to this discussion yet, being busy in
</em><br />
<em class="quotelev1">> Nancy (on which more anon), but just for the record my recommendation
</em><br />
<em class="quotelev1">> is for  4.b
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Syd Bauman wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev4">>>>>1. Add a new numeric code, say "7", that means "mixed", to data.sex.
</em><br />
<em class="quotelev4">>>>>2. Use
</em><br />
<em class="quotelev4">>>>>     attribute sex { data.sex | "mixed" }
</em><br />
<em class="quotelev4">>>>>   for sex= of <personGrp>
</em><br />
<em class="quotelev4">>>>>3. Change the datatype so that the values are "not known", "male",
</em><br />
<em class="quotelev4">>>>>   "female", and "not specified", and then use #2.
</em><br />
<em class="quotelev4">>>>>4. Remove "mixed" from the possible values of sex= of <personGrp> and
</em><br />
<em class="quotelev4">>>>>   either
</em><br />
<em class="quotelev4">>>>>   a) say "you can't say that -- tough", or
</em><br />
<em class="quotelev4">>>>>   b) say "if sex= is *not* specified, it is presumed to be mixed"
</em><br />
<em class="quotelev4">>>>>5. Remove sex= from <personGrp> entirely -- if you want to know,
</em><br />
<em class="quotelev4">>>>>   check the children[1]
</em><br />

I am with 2 here -- I think is is always a good idea to make things
<br />
explicit and not to rely on some implicit, tacit assumption.
<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> Sun Oct 23 2005 - 18:48:39 EDT</span>
</div>

From nsmith at email.unc.edu  Mon Oct 24 10:23:10 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Mon, 24 Oct 2005 10:23:10 -0400 (Eastern Daylight Time)
Subject: [tei-council] sex confession
In-Reply-To: <17242.55341.820563.529333@emt.wwp.brown.edu>
Message-ID: <Pine.WNT.4.10.10510241022390.2012-100000@AALCD49.lib.unc.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Natasha Smith <nsmith_at_email.unc.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 24 Oct 2005 10:23:10 -0400 (Eastern Daylight Time)</span><br />
</address>

Reread all the arguments - my vote goes to 2. n
<br />

<p>On Sat, 22 Oct 2005, Syd Bauman wrote:
<br />

<em class="quotelev3">> > > 1. Add a new numeric code, say "7", that means "mixed", to data.sex.
</em><br />
<em class="quotelev3">> > > 2. Use
</em><br />
<em class="quotelev3">> > >      attribute sex { data.sex | "mixed" }
</em><br />
<em class="quotelev3">> > >    for sex= of <personGrp>
</em><br />
<em class="quotelev3">> > > 3. Change the datatype so that the values are "not known", "male",
</em><br />
<em class="quotelev3">> > >    "female", and "not specified", and then use #2.
</em><br />
<em class="quotelev3">> > > 4. Remove "mixed" from the possible values of sex= of <personGrp> and
</em><br />
<em class="quotelev3">> > >    either
</em><br />
<em class="quotelev3">> > >    a) say "you can't say that -- tough", or
</em><br />
<em class="quotelev3">> > >    b) say "if sex= is *not* specified, it is presumed to be mixed"
</em><br />
<em class="quotelev3">> > > 5. Remove sex= from <personGrp> entirely -- if you want to know,
</em><br />
<em class="quotelev3">> > >    check the children[1]
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> JF> Solution 2 sounds reasonable to me. I like the fact that it makes
</em><br />
<em class="quotelev1">> JF> a clear distinction between the ISO codes and the value which is
</em><br />
<em class="quotelev1">> JF> not a member thereof.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> SR> My preference is for 4, followed by 5,  followed by 2.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I think 1 is a bad idea, as it's confusing, and what do we do when
</em><br />
<em class="quotelev1">> ISO updates their standard and uses the number we picked?
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I like 3, but have already been outvoted on that.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 4a and 5 turn out to have a major problem -- a <personGrp> element
</em><br />
<em class="quotelev1">> does not group a bunch of <person> elements, but rather just
</em><br />
<em class="quotelev1">> describes the group. Thus it *needs* to be able to say "mixed", and I
</em><br />
<em class="quotelev1">> can well imagine people wanting even more precision than that. (E.g.,
</em><br />
<em class="quotelev1">> to be able to specify exact counts, or rough percentages, of each
</em><br />
<em class="quotelev1">> sex.)
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> So I think we are down to 2 or 4b. For the moment I've checked in a
</em><br />
<em class="quotelev1">> version that uses 2. Those who want to argue for 4b or a system that
</em><br />
<em class="quotelev1">> allows more flexibility and precision should speak up now (and thus
</em><br />
<em class="quotelev1">> be drafted for the <soCalled>prosopography</soCalled> WG! :-)
</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.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>_______________________________________________
<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 Oct 24 2005 - 10:24:07 EDT</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Nov  1 09:24:10 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 01 Nov 2005 14:24:10 +0000
Subject: [tei-council] [Fwd: Meeting: TEI Council telcon]
Message-ID: <43677A8A.2020604@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, 01 Nov 2005 14:24:10 +0000</span><br />
</address>

I've proposed a meeting for the dates below. 
<br />

Please visit the following web page to fill in your own
<br />
constraints:
<br />

http://www.meetomatic.com/respond.asp?id=B64ABH
<br />

PROPOSED MEETING DATES:
<br />

Monday 28th November
<br />
Tuesday 29th November
<br />
Wednesday 30th November
<br />
Thursday 1st December
<br />
Friday 9th December
<br />
Monday 12th December
<br />
Tuesday 13th December
<br />
Wednesday 14th December
<br />
Thursday 15th December
<br />
Friday 16th December
<br />

<p><p><p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Nov 01 2005 - 09:25:23 EST</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Nov  1 12:43:49 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 01 Nov 2005 17:43:49 +0000
Subject: [tei-council] datatypes again: make data.key a URI
Message-ID: <4367A955.10605@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, 01 Nov 2005 17:43:49 +0000</span><br />
</address>

[Aaargh you cry, not again]
<br />

Proposal: make data.key map on to xsd:anyURI instead of xsd:string
<br />

Rationale:   At present data.key is for "things like database keys" 
<br />
i.e. arbitrary strings which are not XML names (like ident), and not 
<br />
necessarily pointers (like #ident). A key is a magic string of some sort 
<br />
which an external system uses to access some additional information 
<br />
associated with the magic string.
<br />

I put it to you, mlud, that this *is* effectively a URI. It is hard to 
<br />
imagine any likely scenario in which a database system wouldn't provide 
<br />
a URI-encoded way of accessing its contents in this day and age.
<br />

Use case:  all naming elements (<rs>, <name> etc.) have a key attribute 
<br />
defined as data.key. You *might* want to say <rs key="wibble">Mr 
<br />
Bennet</rs> and leave it at that, but it seems at least as likely that 
<br />
you will somewhere have a <person xml:id="wibble"> element (not 
<br />
necessarily in the same document, but that doesnt matter any more) and 
<br />
want to point to it.
<br />

Choices: we could allow for both key= and uri= and say you really ought 
<br />
to choose one or the other but not both. we could allow for them as 
<br />
alternatives. we could choose just one. My vote is for the last, and for 
<br />
URI.
<br />

We have made the transition from ID/IDREF to xml:id/anyURI more or less 
<br />
consistently throughout P5. I say now is the time to recognise that 
<br />
anyURI is a better way of meeting the ends for which "key" was 
<br />
originally conceived.
<br />

Any objections?
<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 Nov 01 2005 - 12:38:41 EST</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Tue Nov  1 12:51:35 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 01 Nov 2005 19:51:35 +0200
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367A955.10605@oucs.ox.ac.uk>
Message-ID: <4367AB27.5030107@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, 01 Nov 2005 19:51:35 +0200</span><br />
</address>

Lou Burnard wrote:
<br />
<em class="quotelev1">> Rationale:   At present data.key is for "things like database keys" i.e. 
</em><br />
<em class="quotelev1">> arbitrary strings which are not XML names (like ident), and not 
</em><br />
<em class="quotelev1">> necessarily pointers (like #ident). A key is a magic string of some sort 
</em><br />
<em class="quotelev1">> which an external system uses to access some additional information 
</em><br />
<em class="quotelev1">> associated with the magic string.
</em><br />
<em class="quotelev1">> I put it to you, mlud, that this *is* effectively a URI. It is hard to 
</em><br />
<em class="quotelev1">> imagine any likely scenario in which a database system wouldn't provide 
</em><br />
<em class="quotelev1">> a URI-encoded way of accessing its contents in this day and age.
</em><br />
<em class="quotelev1">> 
</em><br />

<p><p>What if my key has characters not allowed by URI's (I've not checked 
<br />
what the restrictions on that since I'm still in Sofia).
<br />

<p><em class="quotelev1">> Use case:  all naming elements (<rs>, <name> etc.) have a key attribute 
</em><br />
<em class="quotelev1">> defined as data.key. You *might* want to say <rs key="wibble">Mr 
</em><br />
<em class="quotelev1">> Bennet</rs> and leave it at that, but it seems at least as likely that 
</em><br />
<em class="quotelev1">> you will somewhere have a <person xml:id="wibble"> element (not 
</em><br />
<em class="quotelev1">> necessarily in the same document, but that doesnt matter any more) and 
</em><br />
<em class="quotelev1">> want to point to it.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Choices: we could allow for both key= and uri= and say you really ought 
</em><br />
<em class="quotelev1">> to choose one or the other but not both. we could allow for them as 
</em><br />
<em class="quotelev1">> alternatives. we could choose just one. My vote is for the last, and for 
</em><br />
<em class="quotelev1">> URI.
</em><br />

What if I want to give the <person> element a key to my database but I 
<br />
want to also give it an xml:id for other purposes?
<br />

<em class="quotelev1">> Any objections?
</em><br />

I'm not necessarily objecting, just want it explained to me more. 
<br />
What do we lose if we are only able to have key or xml:id on an element.
<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> Tue Nov 01 2005 - 12:51:23 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Nov  1 13:23:49 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 01 Nov 2005 18:23:49 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367AB27.5030107@computing-services.oxford.ac.uk>
Message-ID: <4367B2B5.7070105@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, 01 Nov 2005 18:23:49 +0000</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> What if my key has characters not allowed by URI's (I've not checked
</em><br />
<em class="quotelev1">> what the restrictions on that since I'm still in Sofia).
</em><br />
<em class="quotelev1">>
</em><br />
you can use encoding in URIs if needed, eg for spaces
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> What if I want to give the <person> element a key to my database but I
</em><br />
<em class="quotelev1">> want to also give it an xml:id for other purposes?
</em><br />

eh? thats not the same issue. Lou is talking about <rs>, not <person>
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Nov 01 2005 - 13:24:56 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Nov  1 13:28:12 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 01 Nov 2005 18:28:12 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367A955.10605@oucs.ox.ac.uk>
Message-ID: <4367B3BC.3010500@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, 01 Nov 2005 18:28:12 +0000</span><br />
</address>

So long as you keep the data.key clearly defined for this purpose,
<br />
people can
<br />
always change its datatype if their resource is not URI-addressable.
<br />

as a local example, Lou, "rahtz" is a key into our LDAP, but is that
<br />
addressable
<br />
as  a URI?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Nov 01 2005 - 13:29:20 EST</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Tue Nov  1 13:34:46 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 01 Nov 2005 20:34:46 +0200
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367B2B5.7070105@oucs.ox.ac.uk>
Message-ID: <4367B546.704@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, 01 Nov 2005 20:34:46 +0200</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev1">> James Cummings wrote:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>What if my key has characters not allowed by URI's (I've not checked
</em><br />
<em class="quotelev2">>>what the restrictions on that since I'm still in Sofia).
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> you can use encoding in URIs if needed, eg for spaces
</em><br />

ok.  I'm easily convinced by that.
<br />

<em class="quotelev2">>>What if I want to give the <person> element a key to my database but I
</em><br />
<em class="quotelev2">>>want to also give it an xml:id for other purposes?
</em><br />
<em class="quotelev1">> eh? thats not the same issue. Lou is talking about <rs>, not <person>
</em><br />

erm yeah. typo, blame it on being in a Sofia pub.  I meant <rs 
<br />
key="#databaseKey" xml:id="someDocumentIDScheme">foo</rs>
<br />

Isn't it at all likely that I'll want to apply both rather than have 
<br />
to choose between them?
<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> Tue Nov 01 2005 - 13:34:35 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Nov  1 13:42:50 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 01 Nov 2005 18:42:50 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367B546.704@computing-services.oxford.ac.uk>
Message-ID: <4367B72A.5020004@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, 01 Nov 2005 18:42:50 +0000</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> erm yeah. typo, blame it on being in a Sofia pub.  I meant <rs
</em><br />
<em class="quotelev1">> key="#databaseKey" xml:id="someDocumentIDScheme">foo</rs>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Isn't it at all likely that I'll want to apply both rather than have
</em><br />
<em class="quotelev1">> to choose between them?
</em><br />
<em class="quotelev1">>
</em><br />
what you're doing here is a grotesque abuse of xml:id! in your example
<br />
"someDocumentIDScheme" identifies this <rs>, not the "foo" thing.
<br />

the lamb and spinach patties with "potatoes on skin" were good for me,
<br />
if you have not ordered yet
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Nov 01 2005 - 13:43:58 EST</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Tue Nov  1 13:55:07 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 01 Nov 2005 20:55:07 +0200
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367B72A.5020004@oucs.ox.ac.uk>
Message-ID: <4367BA0B.9060700@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, 01 Nov 2005 20:55:07 +0200</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev2">>>Isn't it at all likely that I'll want to apply both rather than have
</em><br />
<em class="quotelev2">>>to choose between them?
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> what you're doing here is a grotesque abuse of xml:id! in your example
</em><br />
<em class="quotelev1">> "someDocumentIDScheme" identifies this <rs>, not the "foo" thing.
</em><br />

Ok... I must be being dense, I was assuming it was identifying the 
<br />
<rs> element, not the 'foo'.... can't I have a database key attached 
<br />
to something where I also want to have an ID of some sort on the 
<br />
element?  Aren't these two completely different things?
<br />

<em class="quotelev1">> the lamb and spinach patties with "potatoes on skin" were good for me,
</em><br />
<em class="quotelev1">> if you have not ordered yet
</em><br />

Already eaten.  Yesterday MattZ got a lovely StPatrick's Day style hat 
<br />
because we had two Murphys.
<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> Tue Nov 01 2005 - 13:55:13 EST</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Nov  1 14:42:55 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 01 Nov 2005 19:42:55 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367BA0B.9060700@computing-services.oxford.ac.uk>
Message-ID: <4367C53F.9020101@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, 01 Nov 2005 19:42:55 +0000</span><br />
</address>

James Cummings wrote:
<br />
<em class="quotelev1">> Sebastian Rahtz wrote:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev3">>>> Isn't it at all likely that I'll want to apply both rather than have
</em><br />
<em class="quotelev3">>>> to choose between them?
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> what you're doing here is a grotesque abuse of xml:id! in your example
</em><br />
<em class="quotelev2">>> "someDocumentIDScheme" identifies this <rs>, not the "foo" thing.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Ok... I must be being dense, I was assuming it was identifying the <rs> 
</em><br />
<em class="quotelev1">> element, not the 'foo'.... can't I have a database key attached to 
</em><br />
<em class="quotelev1">> something where I also want to have an ID of some sort on the element?  
</em><br />
<em class="quotelev1">> Aren't these two completely different things?
</em><br />
<em class="quotelev1">> 
</em><br />

This makes no sense. Have another murphys.
<br />

The <rs> can have an xml:id if you like. The <person> can too.
<br />
The purpose of the KEY attribute however is to say what <person> 
<br />
corresponds to this <rs>. It can do that by pointing to the <person>s 
<br />
ID, or by Some Other Means.
<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 Nov 01 2005 - 14:23:56 EST</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Tue Nov  1 14:32:24 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 01 Nov 2005 21:32:24 +0200
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367C53F.9020101@computing-services.oxford.ac.uk>
Message-ID: <4367C2C8.6090906@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, 01 Nov 2005 21:32:24 +0200</span><br />
</address>

Lou Burnard wrote:
<br />
<em class="quotelev2">>> Ok... I must be being dense, I was assuming it was identifying the 
</em><br />
<em class="quotelev2">>> <rs> element, not the 'foo'.... can't I have a database key attached 
</em><br />
<em class="quotelev2">>> to something where I also want to have an ID of some sort on the 
</em><br />
<em class="quotelev2">>> element?  Aren't these two completely different things?
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> This makes no sense. Have another murphys.
</em><br />

*James orders another Murphys
<br />

<em class="quotelev1">> The <rs> can have an xml:id if you like. The <person> can too.
</em><br />
<em class="quotelev1">> The purpose of the KEY attribute however is to say what <person> 
</em><br />
<em class="quotelev1">> corresponds to this <rs>. It can do that by pointing to the <person>s 
</em><br />
<em class="quotelev1">> ID, or by Some Other Means.
</em><br />

Ah I think I am understanding my misunderstanding now.  *sip Murphys*
<br />
You said:
<br />

<em class="quotelev1"> >Choices: we could allow for both key= and uri= and say you really
</em><br />
<em class="quotelev1"> >ought to choose one or the other but not both. we could allow for
</em><br />
<em class="quotelev1"> >them as alternatives. we could choose just one. My vote is for the
</em><br />
<em class="quotelev1"> >last, and for URI.
</em><br />

I misread uri= and xml:id because the preceding example involving the 
<br />
person.  I thought you were saying a choice of xml:id or key.... *doh* 
<br />
  I agree then: just make @key a URI and if someone wants to change it 
<br />
they can.
<br />

*sigh*
<br />

I really should have a thunderbird extension which asks 'are you in a 
<br />
pub?' if my IP address has changed from the last time I've answered 
<br />
and then if I say yes, just postpone the message instead of sending them.
<br />

*Sigh*
<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> Tue Nov 01 2005 - 14:32:30 EST</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Nov  1 14:54:23 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 01 Nov 2005 19:54:23 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367AB27.5030107@computing-services.oxford.ac.uk>
Message-ID: <4367C7EF.2000806@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, 01 Nov 2005 19:54:23 +0000</span><br />
</address>

James Cummings wrote:
<br />

<p><em class="quotelev1">> 
</em><br />
<em class="quotelev2">>> Use case:  all naming elements (<rs>, <name> etc.) have a key 
</em><br />
<em class="quotelev2">>> attribute defined as data.key. You *might* want to say <rs 
</em><br />
<em class="quotelev2">>> key="wibble">Mr Bennet</rs> and leave it at that, but it seems at 
</em><br />
<em class="quotelev2">>> least as likely that you will somewhere have a <person 
</em><br />
<em class="quotelev2">>> xml:id="wibble"> element (not necessarily in the same document, but 
</em><br />
<em class="quotelev2">>> that doesnt matter any more) and want to point to it.
</em><br />
<em class="quotelev2">>>
</em><br />
...
<br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> What if I want to give the <person> element a key to my database but I 
</em><br />
<em class="quotelev1">> want to also give it an xml:id for other purposes?
</em><br />
<em class="quotelev1">> 
</em><br />

Sorry, I think I now see what I have failed to explain. It's not that 
<br />
you have to choose between <rs key="xxx"> and <person xml:id="xxx">. The 
<br />
  assumption is that you might want to have both and to link them 
<br />
together. At present, if you say <rs key="xxx"> and you want to link 
<br />
that to your <person xml:id="yyy"> you either have to use a different 
<br />
attribute, since key= doesnt act as a uri, or redefine the datraype for 
<br />
key, which is what I am proposing.
<br />

<em class="quotelev1">> I'm not necessarily objecting, just want it explained to me more. What 
</em><br />
<em class="quotelev1">> do we lose if we are only able to have key or xml:id on an element.
</em><br />
<em class="quotelev1">> 
</em><br />

hope this is a bit clearer now, and apologies for excessive elision
<br />

<em class="quotelev1">> -James
</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 Nov 01 2005 - 14:35:16 EST</span>
</div>

From Julia_Flanders at Brown.edu  Thu Nov  3 11:55:20 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 3 Nov 2005 11:55:20 -0500
Subject: [tei-council] stepping down
Message-ID: <a06200715bf8ff0b51117@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 3 Nov 2005 11:55:20 -0500</span><br />
</address>

As some of you may already know, at the TEI board meeting a few days 
<br />
ago I stepped down as TEI chair and Matthew Zimmerman agreed to serve 
<br />
as the new chair. So I will henceforth no longer be a member of the 
<br />
TEI council. I've asked Daniel Pitti to remove me from the list and 
<br />
add Matt in my place.
<br />

I will be happy to follow up on any loose ends of tasks that I began 
<br />
(e.g. if there are further issues with name  regularization or 
<br />
certainty, etc.) and would also be happy to help with chapter 
<br />
reviewing and other work if needed; just let me know.
<br />

best wishes, Julia
<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 Nov 03 2005 - 11:55:30 EST</span>
</div>

From Julia_Flanders at Brown.edu  Thu Nov  3 11:57:28 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 3 Nov 2005 11:57:28 -0500
Subject: [tei-council] conference call
Message-ID: <a06200717bf8ff1e05742@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 3 Nov 2005 11:57:28 -0500</span><br />
</address>

I'm forwarding Matt  Z. the details Sebastian posted concerning the 
<br />
conference call.
<br />

best, Julia
<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 Nov 03 2005 - 11:57:34 EST</span>
</div>

From pwillett at umich.edu  Thu Nov  3 12:03:24 2005
From: pwillett at umich.edu (Perry Willett)
Date: Thu, 3 Nov 2005 12:03:24 -0500
Subject: [tei-council] members meeting report?
In-Reply-To: <a06200715bf8ff0b51117@[128.148.157.102]>
Message-ID: <002401c5e098$83909a70$922bd38d@CLUBSODA>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Perry Willett <pwillett_at_umich.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 3 Nov 2005 12:03:24 -0500</span><br />
</address>

For we unhappy few who didn't attend the members meeting, could we hear the
<br />
election results? Anything else to report? Thanks,
<br />

Perry
<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 Nov 03 2005 - 12:03:33 EST</span>
</div>

From Julia_Flanders at Brown.edu  Thu Nov  3 12:07:01 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 3 Nov 2005 12:07:01 -0500
Subject: [tei-council] members meeting report?
In-Reply-To: <002401c5e098$83909a70$922bd38d@CLUBSODA>
Message-ID: <a06200719bf8ff414db71@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 3 Nov 2005 12:07:01 -0500</span><br />
</address>

Yes, a report will be posted to TEI-L very soon. ...
<br />

<em class="quotelev1">>For we unhappy few who didn't attend the members meeting, could we hear the
</em><br />
<em class="quotelev1">>election results? Anything else to report? Thanks,
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Perry
</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 Nov 03 2005 - 12:07:07 EST</span>
</div>

From Julia_Flanders at Brown.edu  Thu Nov  3 14:41:24 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 3 Nov 2005 14:41:24 -0500
Subject: [tei-council] TEI election results
Message-ID: <a06200735bf90176f24ae@[128.148.157.102]>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Julia Flanders <Julia_Flanders_at_Brown.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Thu, 3 Nov 2005 14:41:24 -0500</span><br />
</address>

Here are the results of the recent TEI elections:
<br />

Elected to the TEI Council for a term beginning January 1, 2006 and 
<br />
ending December 31, 2007:
<br />

David Birnbaum
<br />
Matthew Driscoll
<br />
Dot Porter
<br />
Laurent Romary
<br />
Conal Tuohy
<br />
Christian Wittern
<br />

Elected to the TEI Board (same term):
<br />

Daniel O'Donnell
<br />
John Unsworth
<br />

I've written to all of the candidates to let them know the outcome, 
<br />
and have sent Daniel Pitti and Chris Ruotolo the requisite 
<br />
information so that the listservs and web site can be updated 
<br />
appropriately.
<br />

Best wishes, Julia
<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 Nov 03 2005 - 14:41:35 EST</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Nov  4 03:23:55 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 04 Nov 2005 09:23:55 +0100
Subject: [tei-council] stepping down
In-Reply-To: <a06200715bf8ff0b51117@[128.148.157.102]>
Message-ID: <ygf8xw4x1lw.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 04 Nov 2005 09:23:55 +0100</span><br />
</address>

Dear Julia,
<br />

I would like to take this opportunity to thank you for the support and
<br />
energy you put in supporting the work of the council.  I am sure there
<br />
will be future opportunities to count on your help.
<br />

All the best,
<br />

Christian
<br />

Julia Flanders <Julia_Flanders_at_Brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev1">> As some of you may already know, at the TEI board meeting a few days
</em><br />
<em class="quotelev1">> ago I stepped down as TEI chair and Matthew Zimmerman agreed to serve
</em><br />
<em class="quotelev1">> as the new chair. So I will henceforth no longer be a member of the
</em><br />
<em class="quotelev1">> TEI council. I've asked Daniel Pitti to remove me from the list and
</em><br />
<em class="quotelev1">> add Matt in my place.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I will be happy to follow up on any loose ends of tasks that I began
</em><br />
<em class="quotelev1">> (e.g. if there are further issues with name  regularization or
</em><br />
<em class="quotelev1">> certainty, etc.) and would also be happy to help with chapter
</em><br />
<em class="quotelev1">> reviewing and other work if needed; just let me know.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> best wishes, Julia
</em><br />
<em class="quotelev1">> _______________________________________________
</em><br />
<em class="quotelev1">> tei-council mailing list
</em><br />
<em class="quotelev1">> tei-council_at_lists.village.Virginia.EDU
</em><br />
<em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
</em><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 Nov 04 2005 - 03:23:57 EST</span>
</div>

From sschreib at umd.edu  Fri Nov  4 08:44:00 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Fri, 04 Nov 2005 08:44:00 -0500
Subject: [tei-council] stepping down
In-Reply-To: <ygf8xw4x1lw.fsf@chwpb.local>
Message-ID: <436B65A0.3050807@umd.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Susan Schreibman <sschreib_at_umd.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 04 Nov 2005 08:44:00 -0500</span><br />
</address>

I  wholeheartedly second Christian's thanks --
<br />

usan
<br />

<p>Christian Wittern wrote:
<br />

<em class="quotelev1">>Dear Julia,
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I would like to take this opportunity to thank you for the support and
</em><br />
<em class="quotelev1">>energy you put in supporting the work of the council.  I am sure there
</em><br />
<em class="quotelev1">>will be future opportunities to count on your help.
</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">>Julia Flanders <Julia_Flanders_at_Brown.edu> writes:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>As some of you may already know, at the TEI board meeting a few days
</em><br />
<em class="quotelev2">>>ago I stepped down as TEI chair and Matthew Zimmerman agreed to serve
</em><br />
<em class="quotelev2">>>as the new chair. So I will henceforth no longer be a member of the
</em><br />
<em class="quotelev2">>>TEI council. I've asked Daniel Pitti to remove me from the list and
</em><br />
<em class="quotelev2">>>add Matt in my place.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>I will be happy to follow up on any loose ends of tasks that I began
</em><br />
<em class="quotelev2">>>(e.g. if there are further issues with name  regularization or
</em><br />
<em class="quotelev2">>>certainty, etc.) and would also be happy to help with chapter
</em><br />
<em class="quotelev2">>>reviewing and other work if needed; just let me know.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>best wishes, Julia
</em><br />
<em class="quotelev2">>>_______________________________________________
</em><br />
<em class="quotelev2">>>tei-council mailing list
</em><br />
<em class="quotelev2">>>tei-council_at_lists.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="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742
Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib_at_umd.<!--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 Nov 04 2005 - 08:44:01 EST</span>
</div>

From Syd_Bauman at Brown.edu  Fri Nov  4 19:44:29 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 4 Nov 2005 19:44:29 -0500
Subject: [tei-council] our time zones
Message-ID: <17260.109.848683.361390@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, 4 Nov 2005 19:44:29 -0500</span><br />
</address>

A personalized world clock for Board and Council. Please let me know
<br />
of any errors or omissions.
<br />

http://www.timeanddate.com/worldclock/custom.html?cities=55,64,105,878,136,195,538,264
<br />

Calgary - Dan O'Donell
<br />
Indianapolis - John Walsh
<br />
Chicago - John Unsworth
<br />
Providence - Syd Bauman, David Birnbaum, Julia Flanders, Daniel
<br />
             Pitti, Dot Porter, Susan Schreibman, Natasha Smith,
<br />
             Perry Willett, Matt Zimmerman, (and Patrick Durusau,
<br />
             yes?)
<br />
London - Lou Burnard, James Cummings, John Lavagnino, Sebastian Rahtz
<br />
Paris - Alejandro Bia, Matthew Driscoll, Veronika Lux, Laurent Romary
<br />
Kyoto - Christian Wittern
<br />
Wellington - Conal Tuohy
<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 Nov 04 2005 - 19:44:41 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Nov  6 08:15:17 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 06 Nov 2005 13:15:17 +0000
Subject: [tei-council] next meeting
Message-ID: <436E01E5.4040203@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, 06 Nov 2005 13:15:17 +0000</span><br />
</address>

A weak response so far to Meetomatic. Can some more of you
<br />

visit http://www.meetomatic.com/respond.asp?id=B64ABH, please?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Nov 06 2005 - 08:15:30 EST</span>
</div>

From mz34 at nyu.edu  Sun Nov  6 23:54:15 2005
From: mz34 at nyu.edu (Matthew Zimmerman)
Date: Sun, 6 Nov 2005 23:54:15 -0500
Subject: [tei-council] Greetings
In-Reply-To: <a06200715bf8ff0b51117@[128.148.157.102]>
Message-ID: <0717CEEE-F6F3-4AC0-848E-2B8C85126867@nyu.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Matthew Zimmerman <mz34_at_nyu.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 6 Nov 2005 23:54:15 -0500</span><br />
</address>

Hello all,
<br />

I think everyone on the council knows me but I just wanted to say an  
<br />
official hello as now I will be participating on the council in my  
<br />
role as Board chair.
<br />

Look forward to the upcoming conference call.
<br />

Matt Zimmerman
<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 Nov 06 2005 - 23:54:19 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Nov  7 04:03:59 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 07 Nov 2005 09:03:59 +0000
Subject: [tei-council] telcon:@ December 16th
Message-ID: <436F187F.8020902@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, 07 Nov 2005 09:03:59 +0000</span><br />
</address>

Meetomatic haf spoken. We should meet on December 16th by phone
<br />
at 1200 GMT (that is what we agreed?).
<br />

Sorry, Matthew, you are the loser on this. But the second alternative
<br />
was to lose Christian, and that seemed like a bad idea.
<br />

Sebastian
<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 Nov 07 2005 - 04:04:03 EST</span>
</div>

From mjd at hum.ku.dk  Mon Nov  7 04:14:28 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Mon, 07 Nov 2005 10:14:28 +0100
Subject: [tei-council] telcon:@ December 16th
In-Reply-To: <436F187F.8020902@oucs.ox.ac.uk>
Message-ID: <436F2904.27978.696022@localhost>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: M. J. Driscoll <mjd_at_hum.ku.dk>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 07 Nov 2005 10:14:28 +0100</span><br />
</address>

On the 16th I'll be in Amsterdam (at a conference). Oh well. I'm sure you'll 
<br />
manage somehow without me.
<br />

MJD
<br />

<p><p><em class="quotelev1">> Meetomatic haf spoken. We should meet on December 16th by phone
</em><br />
<em class="quotelev1">> at 1200 GMT (that is what we agreed?).
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Sorry, Matthew, you are the loser on this. But the second alternative
</em><br />
<em class="quotelev1">> was to lose Christian, and that seemed like a bad idea.
</em><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.village.Virginia.EDU
</em><br />
<em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
</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> Mon Nov 07 2005 - 04:14:40 EST</span>
</div>

From Syd_Bauman at Brown.edu  Mon Nov  7 14:40:14 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 7 Nov 2005 14:40:14 -0500
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367C7EF.2000806@computing-services.oxford.ac.uk>
Message-ID: <17263.44446.140281.141825@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 Nov 2005 14:40:14 -0500</span><br />
</address>

I think I'd prefer to leave it a string, but this may require more
<br />
thought. My current reasoning is as follows.
<br />

If the datatype is xsd:string, it is very easy (both technically and
<br />
politically) for someone to restrict it to only URIs.
<br />

If the datatype is xsd:anyURI, it is easy technically, but possibly
<br />
quite difficult politically to expand it to include something that is
<br />
not a URI. (And Sebastian's LDAP example is a good one, as is my key
<br />
into my EMS Personnel database, which is not available via a URI.)
<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 Nov 07 2005 - 14:40:24 EST</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Nov  7 19:42:21 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 08 Nov 2005 09:42:21 +0900
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <17263.44446.140281.141825@emt.wwp.brown.edu>
Message-ID: <ygfwtjkvuky.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 08 Nov 2005 09:42:21 +0900</span><br />
</address>

Syd Bauman <Syd_Bauman_at_Brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev1">> I think I'd prefer to leave it a string, but this may require more
</em><br />
<em class="quotelev1">> thought. My current reasoning is as follows.
</em><br />

<p>+1 from me.  
<br />

I might construct URI's from @key in my application, but
<br />
I would not want them to start their life as such. @key is a string in
<br />
my world and I would prefer it to stay such.
<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 Nov 07 2005 - 19:43:03 EST</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Nov  7 19:45:08 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 08 Nov 2005 09:45:08 +0900
Subject: [tei-council] telcon:@ December 16th
In-Reply-To: <436F187F.8020902@oucs.ox.ac.uk>
Message-ID: <ygfslu8vugb.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 08 Nov 2005 09:45:08 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk> writes:
<br />

<em class="quotelev1">> Meetomatic haf spoken. We should meet on December 16th by phone
</em><br />
<em class="quotelev1">> at 1200 GMT (that is what we agreed?).
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Sorry, Matthew, you are the loser on this. But the second alternative
</em><br />
<em class="quotelev1">> was to lose Christian, and that seemed like a bad idea.
</em><br />

Thanks for finding out and thanks for not kicking me off.  Yes, we are
<br />
supposed to meet at 1200 GMT this time.  We should try to make it not
<br />
longer than one hour.
<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 Nov 07 2005 - 19:45:48 EST</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Nov  8 05:12:58 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 08 Nov 2005 10:12:58 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <ygfwtjkvuky.fsf@chwpb.local>
Message-ID: <43707A2A.7060302@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, 08 Nov 2005 10:12:58 +0000</span><br />
</address>

Christian Wittern wrote:
<br />
<em class="quotelev1">> Syd Bauman <Syd_Bauman_at_Brown.edu> writes:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>I think I'd prefer to leave it a string, but this may require more
</em><br />
<em class="quotelev2">>>thought. My current reasoning is as follows.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> +1 from me.  
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> I might construct URI's from @key in my application, but
</em><br />
<em class="quotelev1">> I would not want them to start their life as such. @key is a string in
</em><br />
<em class="quotelev1">> my world and I would prefer it to stay such.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Christian
</em><br />
<em class="quotelev1">> 
</em><br />

<p>My reason for making this change is that I want to enable people to do 
<br />
things like
<br />

<person xml:id="foo">....</person>
<br />

<name key="#foo">Mr Phoo</name>
<br />

and get some validation. This seems to be highly desirable, especially 
<br />
when we have a proper personography in place, and I suspect it will 
<br />
become the typical case. After all, it is possible to make almost 
<br />
anything into a URL.
<br />

To support additionally your requirement for "key" explicitly to point 
<br />
to something external and non XML we could do one of the following
<br />

-- use another attribute -- but then people have to choose which and we 
<br />
risk ambiguity if one points at one thing and the other at another
<br />

-- add explicit rules about how a URL is to be constructed from the key 
<br />
value, either in P5 or in the document instance
<br />

What I don't know for sure is what in principle it means to say
<br />
<name key="foo"> where foo is defined as a URL -- it's not a validation 
<br />
error, so it may be that we can just say that if the value is like this 
<br />
it is an application dependent string just like the old key thing was.
<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 Nov 08 2005 - 05:07:41 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Nov  8 06:08:12 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 08 Nov 2005 11:08:12 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <43707A2A.7060302@oucs.ox.ac.uk>
Message-ID: <4370871C.8050501@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, 08 Nov 2005 11:08:12 +0000</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> My reason for making this change is that I want to enable people to do
</em><br />
<em class="quotelev1">> things like
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> <person xml:id="foo">....</person>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> <name key="#foo">Mr Phoo</name>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> and get some validation. 
</em><br />

Hmm.  Who do you think is going to validate this for you? the schema
<br />
won't. There are no
<br />
link checkers for TEI docs.
<br />

I tend towards the mutually exclusive attribute scenario. We use
<br />
this somewhere already, I believe.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Nov 08 2005 - 06:08:31 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Nov  8 06:33:41 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 08 Nov 2005 11:33:41 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <43708B63.7000504@oucs.ox.ac.uk>
Message-ID: <43708D15.6010500@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, 08 Nov 2005 11:33:41 +0000</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> I expect an additional stylesheet to do this for me of course. It's
</em><br />
<em class="quotelev1">> utter rubbish to say that there are no link checkers for TEI docs. We
</em><br />
<em class="quotelev1">> already use this mechanism all over the place, e.g. to check that
</em><br />
<em class="quotelev1">> cross refs  in P5 are valid.
</em><br />

We do, yes, but we don't export that to the punters, or have a mechanism
<br />
how they
<br />
might run it
<br />

<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> I tend towards the mutually exclusive attribute scenario. We use
</em><br />
<em class="quotelev2">>> this somewhere already, I believe.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> That's a possibility I hadn't considered. Anyone else like it?
</em><br />

of course, I may be dreaming about the idea that this is possible!
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Nov 08 2005 - 06:33:52 EST</span>
</div>

From Syd_Bauman at Brown.edu  Tue Nov  8 07:19:59 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 8 Nov 2005 07:19:59 -0500
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <43707A2A.7060302@oucs.ox.ac.uk>
Message-ID: <17264.38895.855177.462433@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, 8 Nov 2005 07:19:59 -0500</span><br />
</address>

<em class="quotelev1">> <person xml:id="foo">....</person>
</em><br />
<em class="quotelev1">> <name key="#foo">Mr Phoo</name>
</em><br />

A quite reasonable desire. But if data.key is declared as xsd:anyURI,
<br />
what is the difference between data.key and data.code?
<br />

Also, URIs can be a pretty messy way of accessing data, even when it
<br />
is available on the web. E.g., the US Library of Congress name
<br />
authority records seem to be available on the web. However,
<br />

  <name key="000058144">Paul Simon</name>
<br />

eems much more robust than
<br />

  <name key="http://aleph2.libnet.ac.il/F/MLEYHY17VCMSJLLV4MSBNUPRP2PGRN8L916VGRP7IR4QU8TTXF-23761?func=full-set-set&set_number=055717&set_entry=000001&format=001">Paul
<br />
  Simon</name>
<br />

<p><em class="quotelev1">> My reason for making this change is that I want to enable people to do 
</em><br />
<em class="quotelev1">> things like
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> <person xml:id="foo">....</person>
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> <name key="#foo">Mr Phoo</name>
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> and get some validation. 
</em><br />

BTW, how does one write a simple link-checker for things like this in
<br />
Schematron? Anyone know? (You can't use <xsl:key>, I don't think; can
<br />
you?) 
<br />

<p><em class="quotelev1">> To support additionally your requirement for "key" explicitly to point 
</em><br />
<em class="quotelev1">> to something external and non XML we could do one of the following
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> -- use another attribute -- but then people have to choose which
</em><br />
<em class="quotelev1">>    and we risk ambiguity if one points at one thing and the other 
</em><br />
<em class="quotelev1">>    at another
</em><br />

Although we could make the attributes mutually exclusive -- ODD
<br />
supports that.
<br />

<p><em class="quotelev1">> -- add explicit rules about how a URL is to be constructed from the key 
</em><br />
<em class="quotelev1">>    value, either in P5 or in the document instance
</em><br />

I don't understand what you might be getting at, here.
<br />

<p><em class="quotelev1">> What I don't know for sure is what in principle it means to say
</em><br />
<em class="quotelev1">> <name key="foo"> where foo is defined as a URL -- it's not a
</em><br />
<em class="quotelev1">> validation error, so it may be that we can just say that if the
</em><br />
<em class="quotelev1">> value is like this it is an application dependent string just like
</em><br />
<em class="quotelev1">> the old key thing was.
</em><br />

It means the "rel_path" portion of a URI with value "foo", usually
<br />
interpreted by systems to be the file in the same directory with name
<br />
"foo".
<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 Nov 08 2005 - 07:20:08 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Nov  8 07:39:41 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 08 Nov 2005 12:39:41 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <17264.38895.855177.462433@emt.wwp.brown.edu>
Message-ID: <43709C8D.6010109@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, 08 Nov 2005 12:39:41 +0000</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev2">>><person xml:id="foo">....</person>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>><name key="#foo">Mr Phoo</name>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>>and get some validation. 
</em><br />
<em class="quotelev2">>>    
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>BTW, how does one write a simple link-checker for things like this in
</em><br />
<em class="quotelev1">>Schematron? Anyone know? (You can't use <xsl:key>, I don't think; can
</em><br />
<em class="quotelev1">>you?) 
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
you can check *this* case, but to be useful you also have to check
<br />
<name key="people.xml#foo">, remember
<br />

<p>
-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Nov 08 2005 - 07:39:53 EST</span>
</div>

From Syd_Bauman at Brown.edu  Tue Nov  8 07:55:39 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 8 Nov 2005 07:55:39 -0500
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <43709C8D.6010109@oucs.ox.ac.uk>
Message-ID: <17264.41035.655726.129590@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, 8 Nov 2005 07:55:39 -0500</span><br />
</address>

Sebastian is quite right, I meant the general case.
<br />

<em class="quotelev1">> you can check *this* case, but to be useful you also have to check
</em><br />
<em class="quotelev1">> <name key="people.xml#foo">, remember
</em><br />

Even this case could be handled by parsing on "#" and using
<br />
document() and id(), I think. But I want to be able to validate at
<br />
least
<br />
  <name key="http://my.names.org/namesFile.xml#foo">
<br />
if not
<br />
  <name key="http://my.names.org/namesFile.xml?query=foo">
<br />
and all sorts of other URIs as well.
<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 Nov 08 2005 - 07:55:47 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Tue Nov  8 08:38:14 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 08 Nov 2005 13:38:14 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <17264.41035.655726.129590@emt.wwp.brown.edu>
Message-ID: <4370AA46.7060607@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, 08 Nov 2005 13:38:14 +0000</span><br />
</address>

Syd Bauman wrote
<br />

<em class="quotelev1">> But I want to be able to validate at
</em><br />
<em class="quotelev1">>least
</em><br />
<em class="quotelev1">>  <name key="http://my.names.org/namesFile.xml#foo">
</em><br />
<em class="quotelev1">>if not
</em><br />
<em class="quotelev1">>  <name key="http://my.names.org/namesFile.xml?query=foo">
</em><br />
<em class="quotelev1">>and all sorts of other URIs as well.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
that's what I meant when I said to Lou that we have no general-purpose
<br />
link checker
<br />
for TEI documents, I now realize. If it was HTML, you'd just ask the W3C
<br />
checker to hoover
<br />
it up.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Tue Nov 08 2005 - 08:38:26 EST</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Tue Nov  8 16:21:37 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 08 Nov 2005 21:21:37 +0000
Subject: [tei-council] versificatory matters
Message-ID: <437116E1.9010209@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, 08 Nov 2005 21:21:37 +0000</span><br />
</address>

I believe we have decided to abolish the numbered variants on <lg> 
<br />
provided by the chapter for verse (<lg1>, <lg2> etc.) in P5 but I can't 
<br />
find any written record of this eminently sensible decision. Before I 
<br />
set to  wielding my editing axe on this topic (treated somewhat skimpily 
<br />
but not insubstantially in chapter VE), does anyone wish to put in a 
<br />
last minute plea for a reprieve?
<br />

While thinking about verse, I would also like to sneak in a new element 
<br />
which should have been there all along: <rhyme>. This will be a phrase 
<br />
level element used to delimit the rhyming word/s of a line. It will have 
<br />
an attribute LABEL  to identify which bit of  the rhyme scheme (e.g. the 
<br />
a or b) this rhyming word instantiates and possibly TYPE to indicate 
<br />
what sort of a rhyme this is (e.g. full, partial, etc)
<br />

<l>Come now you men of wives <rhyme label="b">intellectual</rhyme></l>
<br />
<l>Confess, have they not <rhyme label="b" type="awful">hen-pecked you 
<br />
all</rhyme>?</l>
<br />

(Byron: Don Juan, from memory)
<br />

p.s. I claim no originality for this idea, having nicked it from Wendell 
<br />
Piez's charming sonnet site, 
<br />
http://sonneteer.xmlshoestring.com/sonneteer/index.xml
<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 Nov 08 2005 - 16:21:42 EST</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Nov  8 20:34:42 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 09 Nov 2005 10:34:42 +0900
Subject: Personography discussion (was: Re: [tei-council] datatypes again: make data.key a URI)
In-Reply-To: <17264.41035.655726.129590@emt.wwp.brown.edu>
Message-ID: <ygf1x1qhadp.fsf_-_@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 09 Nov 2005 10:34:42 +0900</span><br />
</address>

Syd Bauman <Syd_Bauman_at_Brown.<!--nospam-->edu> writes:
<br />

<em class="quotelev2">>> <name key="people.xml#foo">, remember
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Even this case could be handled by parsing on "#" and using
</em><br />
<em class="quotelev1">> document() and id(), I think. But I want to be able to validate at
</em><br />
<em class="quotelev1">> least
</em><br />
<em class="quotelev1">>   <name key="http://my.names.org/namesFile.xml#foo">
</em><br />
<em class="quotelev1">> if not
</em><br />
<em class="quotelev1">>   <name key="http://my.names.org/namesFile.xml?query=foo">
</em><br />
<em class="quotelev1">> and all sorts of other URIs as well.
</em><br />

And this is were I think it really gets silly.  Who wants to have to
<br />
put full-blown URIs at every name occurrence?  It seems to me, we
<br />
should at least have a mechanism to put everything except the query
<br />
string somewhere in the header and let @key just provide the query
<br />
string or #anchor.  Such a mechanism would also be useful for other
<br />
cases, for example in @ref at <g>.
<br />

For what its worth, I think now that we should defer a decision on
<br />
this to the general personography discussion.  On that topic, Lou
<br />
agreed to provide a draft working paper that could serve as a base for
<br />
the discussion at a face-to-face meeting by the end of the year.  Are
<br />
there other suggestions on how to proceed on this item?  
<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> Tue Nov 08 2005 - 20:35:17 EST</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Nov  8 20:42:36 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 09 Nov 2005 10:42:36 +0900
Subject: [tei-council] versificatory matters
In-Reply-To: <437116E1.9010209@computing-services.oxford.ac.uk>
Message-ID: <ygfwtjifvg3.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 09 Nov 2005 10:42:36 +0900</span><br />
</address>

Lou Burnard <lou.burnard_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">> I believe we have decided to abolish the numbered variants on <lg>
</em><br />
<em class="quotelev1">> provided by the chapter for verse (<lg1>, <lg2> etc.) in P5 but I
</em><br />
<em class="quotelev1">> can't find any written record of this eminently sensible
</em><br />
<em class="quotelev1">> decision. 
</em><br />

I think it is at
<br />
http://www.tei-c.org.uk/Council/tcm17.xml?style=printable in item 7.7,
<br />
second paragraph.
<br />

<em class="quotelev1">> Before I set to  wielding my editing axe on this topic
</em><br />
<em class="quotelev1">> (treated somewhat skimpily but not insubstantially in chapter VE),
</em><br />
<em class="quotelev1">> does anyone wish to put in a last minute plea for a reprieve?
</em><br />

Not here, I have never used one and have seen them gone long ago. 
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> While thinking about verse, I would also like to sneak in a new
</em><br />
<em class="quotelev1">> element which should have been there all along: <rhyme>. This will be
</em><br />
<em class="quotelev1">> a phrase level element used to delimit the rhyming word/s of a
</em><br />
<em class="quotelev1">> line. It will have an attribute LABEL  to identify which bit of  the
</em><br />
<em class="quotelev1">> rhyme scheme (e.g. the a or b) this rhyming word instantiates and
</em><br />
<em class="quotelev1">> possibly TYPE to indicate what sort of a rhyme this is (e.g. full,
</em><br />
<em class="quotelev1">> partial, etc)
</em><br />

I like the idea. Does this mean the <rhyme> is valid outside <l> as well?
<br />
BTW, some of my recent ODDs oddly did not allow nested <lg>s. While
<br />
you are at it, could you please check if that is a bug in P5? 
<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> Tue Nov 08 2005 - 20:43:13 EST</span>
</div>

From Syd_Bauman at Brown.edu  Tue Nov  8 20:46:47 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 8 Nov 2005 20:46:47 -0500
Subject: Personography discussion (was: Re: [tei-council] datatypes again: make data.key a URI)
In-Reply-To: <ygf1x1qhadp.fsf_-_@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <17265.21767.161741.827152@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, 8 Nov 2005 20:46:47 -0500</span><br />
</address>

<em class="quotelev1">> It seems to me, we should at least have a mechanism to put
</em><br />
<em class="quotelev1">> everything except the query string somewhere in the header and let
</em><br />
<em class="quotelev1">> @key just provide the query string or #anchor.<!--nospam--> Such a mechanism
</em><br />
<em class="quotelev1">> would also be useful for other cases, for example in @ref at <g>.<!--nospam-->
</em><br />

Indeed. We already have the mechanism, but currently it is a
<br />
special-purpose mechanism for canonical references. We may want to
<br />
consider expanding it, but that's potentially a big discussion ...
<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 Nov 08 2005 - 20:46:56 EST</span>
</div>

From mjd at hum.ku.dk  Wed Nov  9 02:53:40 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Wed, 09 Nov 2005 08:53:40 +0100
Subject: [tei-council] versificatory matters
In-Reply-To: <437116E1.9010209@computing-services.oxford.ac.uk>
Message-ID: <4371B914.31481.1FA1E6@localhost>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: M. J. Driscoll <mjd_at_hum.ku.dk>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 09 Nov 2005 08:53:40 +0100</span><br />
</address>

This could presumably also be used for alliteration ("stave-rhyme"), a 
<br />
prominent feature of Germanic verse, incl. Old and Middle English, could it 
<br />
not?
<br />

<line><rhyme type="allit">Hige</ryhme> sceal þe <rhyme 
<br />
type="allit">heardra</rhyme> <caesura/> <rhyme type="allit">heorte</rhyme> 
<br />
þe cenre</line>
<br />
<line><rhyme type="allit">mod</rhyme> sceal þe <rhyme 
<br />
type="allit">mare</rhyme> <caesura/> þe ure <rhyme 
<br />
type="allit">mægen</rhyme> lytlað</line>
<br />

[from The Battle of Maldon]
<br />

Now if we just had a good way of dealing with kennings.
<br />

MJD
<br />

<p><p><em class="quotelev1">> While thinking about verse, I would also like to sneak in a new element 
</em><br />
<em class="quotelev1">> which should have been there all along: <rhyme>. This will be a phrase 
</em><br />
<em class="quotelev1">> level element used to delimit the rhyming word/s of a line. It will have 
</em><br />
<em class="quotelev1">> an attribute LABEL  to identify which bit of  the rhyme scheme (e.g. the 
</em><br />
<em class="quotelev1">> a or b) this rhyming word instantiates and possibly TYPE to indicate 
</em><br />
<em class="quotelev1">> what sort of a rhyme this is (e.g. full, partial, etc)
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> <l>Come now you men of wives <rhyme label="b">intellectual</rhyme></l>
</em><br />
<em class="quotelev1">> <l>Confess, have they not <rhyme label="b" type="awful">hen-pecked you 
</em><br />
<em class="quotelev1">> all</rhyme>?</l>
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> (Byron: Don Juan, from memory)
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> p.s. I claim no originality for this idea, having nicked it from Wendell 
</em><br />
<em class="quotelev1">> Piez's charming sonnet site, 
</em><br />
<em class="quotelev1">> http://sonneteer.xmlshoestring.com/sonneteer/index.xml
</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.village.Virginia.EDU
</em><br />
<em class="quotelev1">> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
</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> Wed Nov 09 2005 - 02:53:52 EST</span>
</div>

From mjd at hum.ku.dk  Wed Nov  9 03:38:29 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Wed, 09 Nov 2005 09:38:29 +0100
Subject: [tei-council] versificatory matters
In-Reply-To: <437116E1.9010209@computing-services.oxford.ac.uk>
Message-ID: <4371C395.16501.48A692@localhost>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: M. J. Driscoll <mjd_at_hum.ku.dk>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 09 Nov 2005 09:38:29 +0100</span><br />
</address>

By the way, it's:
<br />

But - Oh! ye lords of ladies intellectual, 
<br />
Inform us truly, have they not hen-peck'd you all?
<br />
(Don Juan, Canto I, stanza 22)
<br />

Only one of many truly awful rhymes in that poem.
<br />

MJD
<br />

<p><em class="quotelev1">> 
</em><br />
<em class="quotelev1">> <l>Come now you men of wives <rhyme label="b">intellectual</rhyme></l>
</em><br />
<em class="quotelev1">> <l>Confess, have they not <rhyme label="b" type="awful">hen-pecked you 
</em><br />
<em class="quotelev1">> all</rhyme>?</l>
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> (Byron: Don Juan, from memory)
</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 Nov 09 2005 - 03:38:33 EST</span>
</div>

From mjd at hum.ku.dk  Wed Nov  9 06:45:26 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Wed, 09 Nov 2005 12:45:26 +0100
Subject: [tei-council] Kennings
Message-ID: <4371EF66.348.F3D032@localhost>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: M. J. Driscoll <mjd_at_hum.ku.dk>
</span><br />
<span id="date"><dfn>Date</dfn>: Wed, 09 Nov 2005 12:45:26 +0100</span><br />
</address>

Since I brought up the subject perhaps I should explain a bit more about what I 
<br />
mean concerning kennings.
<br />

Kennings are metaphorical compounds extensively used in early Germanic poetry, 
<br />
like hronrade, lit. "whale-road", meaning "sea", in line 10 of Beowulf.
<br />

Like so many other things, kennings really came into their own in Icelandic 
<br />
literature, first in skaldic poetry, subsequently in r?mur or metrical 
<br />
romances.
<br />

Take a simple kenning for a woman, seima-Gn?, consisting of the the genitive 
<br />
plural of seimur ("gold") plus the name of the goddess Gn?. I've been marking 
<br />
this up using <seg>, as in the following example:
<br />

<seg type="kenning">
<br />
<seg function="determinant">seima</seg>
<br />
<seg function="base">Gná</seg>
<br />
</seg>
<br />

The Sydney-based skaldic poetry project has, I know, introduced specialised 
<br />
elements for these things, so their markup of this same kenning would be:
<br />

<kenning referent="woman">
<br />
<det>seima</det>
<br />
<bw>Gná</bw>
<br />
</kenning>
<br />

A better (and more general) solution could certainly be found, however. And 
<br />
besides, this only really works if the parts of the kenning are next to each 
<br />
other and don't overlap with other kennings (as they frequently do in skaldic 
<br />
poetry).
<br />

Any ideas?
<br />

Matthew
<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 Nov 09 2005 - 06:45:31 EST</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Wed Nov  9 07:07:20 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 09 Nov 2005 12:07:20 +0000
Subject: [tei-council] versificatory matters
In-Reply-To: <4371B914.31481.1FA1E6@localhost>
Message-ID: <4371E678.9040104@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, 09 Nov 2005 12:07:20 +0000</span><br />
</address>

M. J. Driscoll wrote:
<br />
<em class="quotelev1">> This could presumably also be used for alliteration ("stave-rhyme"), a 
</em><br />
<em class="quotelev1">> prominent feature of Germanic verse, incl. Old and Middle English, could it 
</em><br />
<em class="quotelev1">> not?
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> <line><rhyme type="allit">Hige</ryhme> sceal þe <rhyme 
</em><br />
<em class="quotelev1">> type="allit">heardra</rhyme> <caesura/> <rhyme type="allit">heorte</rhyme> 
</em><br />
<em class="quotelev1">> þe cenre</line>
</em><br />
<em class="quotelev1">> <line><rhyme type="allit">mod</rhyme> sceal þe <rhyme 
</em><br />
<em class="quotelev1">> type="allit">mare</rhyme> <caesura/> þe ure <rhyme 
</em><br />
<em class="quotelev1">> type="allit">mægen</rhyme> lytlað</line>
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> [from The Battle of Maldon]
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Now if we just had a good way of dealing with kennings.
</em><br />

I've been reading the various suggestions for the <rhyme> element with interest.
<br />
One of my concerns is that as soon as we simply depart from indicating a general
<br />
rhyme scheme on the <lg> is that we enter into the realm of possibly marking up
<br />
all sorts of complicated rhetorical tropes and schemes.  Fair enough, for it to
<br />
be envisioned as a simple <rhyme label="a">, and I have no problem with the
<br />
'a'-ness of that being determined by its ancestral <lg>.  In fact, in recently
<br />
producing some word indexes and tables of rhyme-words, etc. from some medieval
<br />
psalters for a project, I could have used just this structure rather than the
<br />
cobbled together <seg>s that I did.
<br />

My worry is that people won't just limit it to simple straightforward rhymes in
<br />
the modern concept, but other rhetorical structures (such as Matthew's
<br />
alliteration example) which become increasingly complex or interlinear.  The
<br />
reason this worries me is there are some rhetorical structures out there that
<br />
seem quite complicated and that this might find itself being co-opted for lots
<br />
of other (ab)uses.  I'm happy to agree that having <rhyme> is a good thing, but
<br />
perhaps if we are going to add it, we should maybe look again at marking all
<br />
sorts of other rhetorical structures to see if there are some more general
<br />
elements.  These can, I think, generally be done with existing TEI elements but
<br />
if there is a more general solution which works for rhymes and as well as other
<br />
similar things, then that would seem like a good idea.
<br />

Just my initial thoughts, this time at least not from a pub in Sofia.
<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> Wed Nov 09 2005 - 07:07:23 EST</span>
</div>

From Laurent.Romary at loria.fr  Wed Nov  9 08:26:37 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Wed, 9 Nov 2005 14:26:37 +0100
Subject: Personography discussion (was: Re: [tei-council] datatypes again: make data.key a URI)
In-Reply-To: <ygf1x1qhadp.fsf_-_@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <159AD302-CBF6-4CDA-8B56-B013B325B2D9@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, 9 Nov 2005 14:26:37 +0100</span><br />
</address>

Hi,
<br />
Am I being stupid or is it just the purpose of the W3C xml:base  
<br />
attribute? We could integrate it into P5, couldn't we?
<br />
Best,
<br />
Laurent
<br />

Le 9 nov. 05 ? 02:34, Christian Wittern a ?crit :
<br />

<em class="quotelev1">> Syd Bauman <Syd_Bauman_at_Brown.edu> writes:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev3">>>> <name key="people.xml#foo">, remember
</em><br />
<em class="quotelev3">>>>
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev2">>> Even this case could be handled by parsing on "#" and using
</em><br />
<em class="quotelev2">>> document() and id(), I think. But I want to be able to validate at
</em><br />
<em class="quotelev2">>> least
</em><br />
<em class="quotelev2">>>   <name key="http://my.names.org/namesFile.xml#foo">
</em><br />
<em class="quotelev2">>> if not
</em><br />
<em class="quotelev2">>>   <name key="http://my.names.org/namesFile.xml?query=foo">
</em><br />
<em class="quotelev2">>> and all sorts of other URIs as well.
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> And this is were I think it really gets silly.  Who wants to have to
</em><br />
<em class="quotelev1">> put full-blown URIs at every name occurrence?  It seems to me, we
</em><br />
<em class="quotelev1">> should at least have a mechanism to put everything except the query
</em><br />
<em class="quotelev1">> string somewhere in the header and let @key just provide the query
</em><br />
<em class="quotelev1">> string or #anchor.  Such a mechanism would also be useful for other
</em><br />
<em class="quotelev1">> cases, for example in @ref at <g>.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> For what its worth, I think now that we should defer a decision on
</em><br />
<em class="quotelev1">> this to the general personography discussion.  On that topic, Lou
</em><br />
<em class="quotelev1">> agreed to provide a draft working paper that could serve as a base for
</em><br />
<em class="quotelev1">> the discussion at a face-to-face meeting by the end of the year.  Are
</em><br />
<em class="quotelev1">> there other suggestions on how to proceed on this item?
</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="quotelev1">>  Christian Wittern
</em><br />
<em class="quotelev1">>  Institute for Research in Humanities, Kyoto University
</em><br />
<em class="quotelev1">>  47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
</em><br />
<em class="quotelev1">> _______________________________________________
</em><br />
<em class="quotelev1">> tei-council mailing list
</em><br />
<em class="quotelev1">> tei-council_at_lists.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 />

<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 Nov 09 2005 - 08:25:51 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Nov  9 08:35:27 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 09 Nov 2005 13:35:27 +0000
Subject: [tei-council] Re: Personography discussion
In-Reply-To: <159AD302-CBF6-4CDA-8B56-B013B325B2D9@loria.fr>
Message-ID: <4371FB1F.7060802@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 Nov 2005 13:35:27 +0000</span><br />
</address>

Laurent Romary wrote:
<br />

<em class="quotelev1">> Hi,
</em><br />
<em class="quotelev1">> Am I being stupid or is it just the purpose of the W3C xml:base 
</em><br />
<em class="quotelev1">> attribute? We could integrate it into P5, couldn't we?
</em><br />

<p>xml:base would typically apply to links in the  whole document. these
<br />
person links are
<br />
just one small section.
<br />

of course, Christian can always use #foo to point to a section in the
<br />
header which points
<br />
to a further URL if desired.
<br />

but I agree with Christian's conclusion that decision on this should be
<br />
delayed and form
<br />
part of the agenda for a personography meeting. Apropos of which, I will
<br />
be working from
<br />
January for a short time each week on a TEI version of a name-related
<br />
project, and I'd really like
<br />
it if we could  make this a big focus of work in 2006 Q1. It does not
<br />
seem beyond the bounds
<br />
of possibility to get all the work done in time to review at  a council
<br />
meeting in May.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Nov 09 2005 - 08:35:33 EST</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Wed Nov  9 09:08:03 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 09 Nov 2005 14:08:03 +0000
Subject: [tei-council] Re: Personography discussion
In-Reply-To: <4371FB1F.7060802@oucs.ox.ac.uk>
Message-ID: <437202C3.7030204@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, 09 Nov 2005 14:08:03 +0000</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev1">> of course, Christian can always use #foo to point to a section in the
</em><br />
<em class="quotelev1">> header which points
</em><br />
<em class="quotelev1">> to a further URL if desired.
</em><br />

I like that method generally for other things, but you don't necessarily
<br />
want to do that with @key do you?  Wouldn't that necessitate sections in
<br />
the header for every @key? Or all of them being the same?
<br />

<em class="quotelev1">> but I agree with Christian's conclusion that decision on this should be
</em><br />
<em class="quotelev1">> delayed and form
</em><br />
<em class="quotelev1">> part of the agenda for a personography meeting. Apropos of which, I will
</em><br />
<em class="quotelev1">> be working from
</em><br />
<em class="quotelev1">> January for a short time each week on a TEI version of a name-related
</em><br />
<em class="quotelev1">> project, and I'd really like
</em><br />
<em class="quotelev1">> it if we could  make this a big focus of work in 2006 Q1. It does not
</em><br />
<em class="quotelev1">> seem beyond the bounds
</em><br />
<em class="quotelev1">> of possibility to get all the work done in time to review at  a council
</em><br />
<em class="quotelev1">> meeting in May.
</em><br />

Have we settled on who/where/when of this personography meeting?
<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> Wed Nov 09 2005 - 09:08:06 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Nov  9 09:14:53 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 09 Nov 2005 14:14:53 +0000
Subject: [tei-council] Re: Personography discussion
In-Reply-To: <437202C3.7030204@computing-services.oxford.ac.uk>
Message-ID: <4372045D.8090400@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 Nov 2005 14:14:53 +0000</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">>I like that method generally for other things, but you don't necessarily
</em><br />
<em class="quotelev1">>want to do that with @key do you?  Wouldn't that necessitate sections in
</em><br />
<em class="quotelev1">>the header for every @key? Or all of them being the same?
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
I may be talking rubbish. needs  a whiteboard and a cup of tea to sort
<br />
out what I mean
<br />

<em class="quotelev1">>Have we settled on who/where/when of this personography meeting?
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
none of the above, SFAIK
<br />

my default assumptions are
<br />

 - 6-8 people, half from here, half external experts
<br />
 - London
<br />
 - 1st week of February
<br />

which members of the Council would expect to be at such a meeting? and who
<br />
has suggestions for external folk? I'll correlate, if desired.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Nov 09 2005 - 09:14:57 EST</span>
</div>

From Syd_Bauman at Brown.edu  Wed Nov  9 09:22:23 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 9 Nov 2005 09:22:23 -0500
Subject: Personography discussion (was: Re: [tei-council] datatypes again: make data.key a URI)
In-Reply-To: <159AD302-CBF6-4CDA-8B56-B013B325B2D9@loria.fr>
Message-ID: <17266.1567.236846.500723@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, 9 Nov 2005 09:22:23 -0500</span><br />
</address>

<em class="quotelev1">> Am I being stupid or is it just the purpose of the W3C xml:base
</em><br />
<em class="quotelev1">> attribute? We could integrate it into P5, couldn't we? 
</em><br />

Well, xml:base= is somewhat helpful, but doesn't really solve the
<br />
problem, as it applies to *all* pointer attributes.
<br />

  <p xml:base="long://initial.url.path/here/">
<br />
    I would like to say that <name key="#LR">Laurent</name> is
<br />
    a great guy. Proof can be found
<br />
    <ref target="worse://super.long.url/path/here.xml">here</ref>
<br />
  </p>
<br />

What we'd really like is a way of saying "this is the base URI for
<br />
all key= attributes, but not others".
<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 Nov 09 2005 - 09:22:32 EST</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Wed Nov  9 09:47:32 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 09 Nov 2005 14:47:32 +0000
Subject: [tei-council] Re: Personography discussion
In-Reply-To: <17266.1567.236846.500723@emt.wwp.brown.edu>
Message-ID: <43720C04.2020505@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, 09 Nov 2005 14:47:32 +0000</span><br />
</address>

Syd Bauman wrote:
<br />
<em class="quotelev2">>>Am I being stupid or is it just the purpose of the W3C xml:base
</em><br />
<em class="quotelev2">>>attribute? We could integrate it into P5, couldn't we? 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> Well, xml:base= is somewhat helpful, but doesn't really solve the
</em><br />
<em class="quotelev1">> problem, as it applies to *all* pointer attributes.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">>   <p xml:base="long://initial.url.path/here/">
</em><br />
<em class="quotelev1">>     I would like to say that <name key="#LR">Laurent</name> is
</em><br />
<em class="quotelev1">>     a great guy. Proof can be found
</em><br />
<em class="quotelev1">>     <ref target="worse://super.long.url/path/here.xml">here</ref>
</em><br />
<em class="quotelev1">>   </p>
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> What we'd really like is a way of saying "this is the base URI for
</em><br />
<em class="quotelev1">> all key= attributes, but not others".
</em><br />

Is the only way to have all key attributes _be understood to_ point to a
<br />
specific place in the header, and that place have an xml:base ?  Would that
<br />
actually work?  (And then how does one do this if we want to have keys in
<br />
multiple external sources?, etc.)
<br />

Is there a RelaxNG way to validate such a thing?
<br />

I agree that this definitely needs more thought.  However, if a general solution
<br />
is found, it could apply to a lot more than the personographies, couldn't 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> Wed Nov 09 2005 - 09:47:36 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Nov  9 11:44:20 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 09 Nov 2005 16:44:20 +0000
Subject: [tei-council] personography task force
Message-ID: <43722764.7040505@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 Nov 2005 16:44:20 +0000</span><br />
</address>

some of you are sending me names and volunteering to discuss
<br />
personography. It is already
<br />
clear that there are at least 8 people on the council alone who want to
<br />
take part.
<br />

There are 3 ways to proceed:
<br />

 a) make it a council subset meeting
<br />
 b) elect a leader who will invite his/her best shots and sorry, being
<br />
on the council doesn't guarentee you a seat
<br />
 c) invite all and sundry (ie TEI-L) to make a pitch as to why they
<br />
should take part, and pick the
<br />
    8 candidates who make the most convincing case (to be judged by
<br />
Christian)
<br />

views?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Wed Nov 09 2005 - 11:44:26 EST</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Nov 10 23:09:36 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 11 Nov 2005 13:09:36 +0900
Subject: [tei-council] personography task force
In-Reply-To: <43722764.7040505@oucs.ox.ac.uk>
Message-ID: <ygfek5nu8ov.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Fri, 11 Nov 2005 13:09:36 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk> writes:
<br />

<em class="quotelev1">> some of you are sending me names and volunteering to discuss
</em><br />
<em class="quotelev1">> personography. It is already
</em><br />
<em class="quotelev1">> clear that there are at least 8 people on the council alone who want to
</em><br />
<em class="quotelev1">> take part.
</em><br />

This seems to be a hot topic at the moment.
<br />

<em class="quotelev1">> There are 3 ways to proceed:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  a) make it a council subset meeting
</em><br />
<em class="quotelev1">>  b) elect a leader who will invite his/her best shots and sorry, being
</em><br />
<em class="quotelev1">> on the council doesn't guarentee you a seat
</em><br />
<em class="quotelev1">>  c) invite all and sundry (ie TEI-L) to make a pitch as to why they
</em><br />
<em class="quotelev1">> should take part, and pick the
</em><br />
<em class="quotelev1">>     8 candidates who make the most convincing case (to be judged by
</em><br />
<em class="quotelev1">> Christian)
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> views?
</em><br />

Well, the more I think of it the less I like to hurry this through.  I
<br />
would propose a two-layered approach:
<br />

1) For the things that need immediate fix in P5 (e.g. datatypes et.al)
<br />
   Lou promised to write a position paper by the end of the year.
<br />
   This could serve as a base for decisions in a tight time-frame. 
<br />
   personography per se would be out of scope for this.
<br />

2) We encourage all those interested in this to immediately start
<br />
   experimenting by creating extensions that do what people want to do
<br />
   with these persons.  It would also sensible to form a SIG and encourage
<br />
   communication there.  After a while (6, 12 months?) we look
<br />
   at the output of this group and decide whether to charge a more
<br />
   formal work group or let the SIG continue or have a one-off,
<br />
   focused meeting on a defined range of topics to iron out some open
<br />
   points.
<br />

This could be seen as a testbed for future development in the TEI -
<br />
more community based, less relying on an inner circle of all-round
<br />
experts.  I think it is also a Good Thing (tm) to do standardization
<br />
based on existing implementation and praxis, rather than out-of-the-blue.
<br />

comments? views?
<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> Thu Nov 10 2005 - 23:10:11 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Fri Nov 11 04:48:19 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 11 Nov 2005 09:48:19 +0000
Subject: [tei-council] personography task force
In-Reply-To: <ygfek5nu8ov.fsf@chwpb.local>
Message-ID: <437468E3.5010009@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 Nov 2005 09:48:19 +0000</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>Well, the more I think of it the less I like to hurry this through. 
</em><br />
<em class="quotelev1">>
</em><br />
My reaction is opposite, curiously. The more I think of it
<br />
the more I want it looked at now :-}
<br />

<em class="quotelev1">>1) For the things that need immediate fix in P5 (e.g. datatypes et.al)
</em><br />
<em class="quotelev1">>   Lou promised to write a position paper by the end of the year.
</em><br />
<em class="quotelev1">>   This could serve as a base for decisions in a tight time-frame. 
</em><br />
<em class="quotelev1">>   personography per se would be out of scope for this.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
That depends on the scope of what Lou proposes to write
<br />
about. Just datatypes is not enough. I don't think we should
<br />
persist for another year with anomalies like half the personography
<br />
elements being in corpus, for example, and the lack of a death
<br />

<em class="quotelev1">>2) We encourage all those interested in this to immediately start
</em><br />
<em class="quotelev1">>   experimenting by creating extensions that do what people want to do
</em><br />
<em class="quotelev1">>   with these persons.  It would also sensible to form a SIG and encourage
</em><br />
<em class="quotelev1">>   communication there. 
</em><br />
<em class="quotelev1">>
</em><br />
It's not practical to unilaterally form a SIG. Without leadership,
<br />
nothing happens; if there is a leader, we can ask them to form a WG
<br />

<em class="quotelev1">>This could be seen as a testbed for future development in the TEI -
</em><br />
<em class="quotelev1">>more community based, less relying on an inner circle of all-round
</em><br />
<em class="quotelev1">>experts.  I think it is also a Good Thing (tm) to do standardization
</em><br />
<em class="quotelev1">>based on existing implementation and praxis, rather than out-of-the-blue.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
In some ways, yes. The standardization process should
<br />
be based on existing practice, and on a broad input, not
<br />
experts dictating future directions. But that's how the TEI
<br />
_does_ work: we charter a group, appoint a leader, let current
<br />
practitioner parties join, and moderate it with the elected council.
<br />

My view is that names/dates/places is an extremely widely practised thing
<br />
already, and we can see plenty of examples already, some based on the 
<br />
TEI like
<br />
those inscriptionists in Sofia, some very loosely related, like DDI, and 
<br />
some
<br />
new inventions like HEML. We don't need more experimentation, now _is_
<br />
the time for the TEI to crystallize practice - I think we are now at the 
<br />
stage
<br />
you propose for 12 months from now.
<br />

Sebastian
<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 Nov 11 2005 - 04:48:33 EST</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Fri Nov 11 05:17:11 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 11 Nov 2005 10:17:11 +0000
Subject: [tei-council] personography task force
In-Reply-To: <437468E3.5010009@oucs.ox.ac.uk>
Message-ID: <43746FA7.9020909@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, 11 Nov 2005 10:17:11 +0000</span><br />
</address>

Just to clarify on my current commitments...
<br />

1. Classes
<br />

In Bulgaria, Syd and I agreed to divide the task of implementing the 
<br />
Oxford decisions between us. I have done my half, and Syd (witness 
<br />
recent email) has started on his. We hope to have the whole lot done by 
<br />
the end of November.
<br />

2. Structure chapter (ST)
<br />

I want to make a serious attempt at defining a new organization for this 
<br />
chapter. Every time a change is made to the class system, this chapter 
<br />
has to be edited, which is one reason why I have been putting the job 
<br />
off, but it remains, I think, more urgent than anything else. I will 
<br />
work on that during December.
<br />

3. Personography rationalization.
<br />

I have already done some minor spadework on this, in revising the parts 
<br />
of CO which talk about names. I would like to build on this revision, 
<br />
with the aim of producing a new section synthesizing what is currently 
<br />
treated in ND and in CC, for the Council to review in January. Let me 
<br />
stress that my intention is not to revisit the whole question of 
<br />
personal identity, but simply to synthesize what is already present in 
<br />
different parts of the Guidelines into an accessible and useful set of 
<br />
recommendations.
<br />

<p>Lou
<br />

<p><p>Sebastian Rahtz wrote:
<br />

<p><em class="quotelev2">>> 1) For the things that need immediate fix in P5 (e.g. datatypes et.al)
</em><br />
<em class="quotelev2">>>   Lou promised to write a position paper by the end of the year.
</em><br />
<em class="quotelev2">>>   This could serve as a base for decisions in a tight time-frame.   
</em><br />
<em class="quotelev2">>> personography per se would be out of scope for this.
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> That depends on the scope of what Lou proposes to write
</em><br />
<em class="quotelev1">> about. Just datatypes is not enough. I don't think we should
</em><br />
<em class="quotelev1">> persist for another year with anomalies like half the personography
</em><br />
<em class="quotelev1">> elements being in corpus, for example, and the lack of a death
</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> Fri Nov 11 2005 - 05:05:40 EST</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Fri Nov 11 06:30:11 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 11 Nov 2005 11:30:11 +0000 (GMT)
Subject: [tei-council] photos
Message-ID: <20051111113012.4058422677@webmail219.herald.ox.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, 11 Nov 2005 11:30:11 +0000 (GMT)</span><br />
</address>
 ('binary' encoding is not supported, stored as-is)
Just in case anyone is interested my photos of the TEI members' meeting are at:
<br />
http://purl.org/cummings/family/images/Bulgaria2005-10
<br />
or inside a frameset at www.cummingsfamily.org.uk
<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> Fri Nov 11 2005 - 06:30:24 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Nov 13 06:56:21 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 13 Nov 2005 11:56:21 +0000
Subject: [tei-council] @TEIform
Message-ID: <437729E5.80808@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, 13 Nov 2005 11:56:21 +0000</span><br />
</address>

As you all know, any TEI schema or DTD has an attribute "TEIform" for
<br />
every element.
<br />
It contains the name of the element, and is there to help you
<br />
reconstruct documents
<br />
where the element name has changed.
<br />

We now know how to do this better by reference back to the ODD source,
<br />
which also covers attribute names.
<br />

Hands up all those who would be willing to quietly drop this dinosaur
<br />
artefact?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Nov 13 2005 - 06:56:36 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Nov 13 07:03:51 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 13 Nov 2005 12:03:51 +0000
Subject: [tei-council] numbered divs
Message-ID: <43772BA7.9010202@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, 13 Nov 2005 12:03:51 +0000</span><br />
</address>

You'll recall the growing movement to kill the numbered <divN> elements.
<br />
Some suggest that they be made optional, in their own module.
<br />

Experimenting with this makes me realize that it cannot easily work,
<br />
because of the way we construct content models. We say (simplified):
<br />
(
<br />
    div
<br />
    (div | global)*
<br />
|
<br />
    div1
<br />
    (div1 | global)*
<br />
)
<br />

ie if you start with <div>, you cannot lurch off  into <div1>
<br />

If  we now delete div1, we get
<br />
(
<br />
    div
<br />
    (div | global)*
<br />
|
<br />
    (global)*
<br />
)
<br />

which is ambiguous in DTDs (and W3C schemas, I think)
<br />

Of course, you should say  I should detect this in the ODD processing,
<br />
and zap the extra "| (global)*", but
<br />
thats not at all easy.
<br />

if we said
<br />
(
<br />
    div | div1
<br />
    ( div | div1 | global)*
<br />
)
<br />

the problem would go away, at the cost of allowing the absurdity of
<br />

 <div1>
<br />
 </div1>
<br />
 <div>
<br />
 </div>
<br />

does anyone feel that the looseness of this is unacceptable?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Nov 13 2005 - 07:04:03 EST</span>
</div>

From Syd_Bauman at Brown.edu  Sun Nov 13 07:24:04 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 13 Nov 2005 07:24:04 -0500
Subject: [tei-council] @TEIform
In-Reply-To: <437729E5.80808@oucs.ox.ac.uk>
Message-ID: <17271.12388.679670.972562@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, 13 Nov 2005 07:24:04 -0500</span><br />
</address>

<em class="quotelev1">> Hands up all those who would be willing to quietly drop this
</em><br />
<em class="quotelev1">> dinosaur artefact?
</em><br />

As one who has had trouble seeing what value TEIform= brings to the
<br />
TEI scheme since late 2003 or some such, I'm all in favor of dropping
<br />
this attribute with a loud "thud".
<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 Nov 13 2005 - 07:24:12 EST</span>
</div>

From Syd_Bauman at Brown.edu  Sun Nov 13 07:26:44 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 13 Nov 2005 07:26:44 -0500
Subject: [tei-council] @TEIform
In-Reply-To: <17271.12388.679670.972562@emt.wwp.brown.edu>
Message-ID: <17271.12548.977221.416176@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, 13 Nov 2005 07:26:44 -0500</span><br />
</address>

<em class="quotelev1">> As one who has had trouble seeing what value TEIform= brings to the
</em><br />
<em class="quotelev1">> TEI scheme ...
</em><br />

I should have been more specific -- "to the TEI P5 scheme".
<br />

Obviously shouldn't remove TEIform= from P4.  :-)
<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 Nov 13 2005 - 07:26:53 EST</span>
</div>

From Syd_Bauman at Brown.edu  Sun Nov 13 07:40:04 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 13 Nov 2005 07:40:04 -0500
Subject: [tei-council] numbered divs
In-Reply-To: <43772BA7.9010202@oucs.ox.ac.uk>
Message-ID: <17271.13348.990964.718256@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, 13 Nov 2005 07:40:04 -0500</span><br />
</address>

<em class="quotelev1">> does anyone feel that the looseness of this is unacceptable?
</em><br />

Yes, completely.
<br />

<p>On the other hand, you voiced in earlier mail (not to the list) the
<br />
thought of further constraining this back to "only numbered OR only
<br />
un-numbered" with a Schematron rule. This may not be so terrible,
<br />
depending on what our end position is on the use of Schematron.
<br />

<p>The general problem is that dropping all members of a class may make
<br />
some content models ambiguous in DTD (and maybe W3C) land.
<br />

I think it is important to seriously investigate the dummy-element
<br />
insertion idea, which could solve this general problem, not just this
<br />
instance. This is the idea that whenever the odd2dtd processor comes
<br />
across an empty class, it populates that class with one element
<br />
<dummy-do-not-use>. In DTDs this element wouldn't even be declared
<br />
(and thus, regular DTD validation should flag an occurrence of it as
<br />
an error in an instance). In any case (RelaxNG, DTD, W3C Schema), a
<br />
very simple additional Schematron rule would flag all
<br />
<dummy-do-not-use> elements as errors (following is untested
<br />
off-the-top-of-my-head):
<br />

  <s:pattern name="No dummy elements permitted">
<br />
    <s:rule context="tei:dummy-do-not-use">
<br />
      <s:report test="tei:dummy-do-not-use">
<br />
        The <dummy-do-not-use> element should never be used. For the technical
<br />
        explanation of why this element exists see XXXX.
<br />
      </s:report>
<br />
    </s:rule>
<br />
  </s:pattern>
<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 Nov 13 2005 - 07:40:16 EST</span>
</div>

From sschreib at umd.edu  Sun Nov 13 08:11:09 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Sun, 13 Nov 2005 08:11:09 -0500
Subject: [tei-council] @TEIform
In-Reply-To: <437729E5.80808@oucs.ox.ac.uk>
Message-ID: <43773B6D.5080204@umd.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Susan Schreibman <sschreib_at_umd.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 13 Nov 2005 08:11:09 -0500</span><br />
</address>

I've always wondered why it was there and never used it -- I'd be in 
<br />
favor of dropping it
<br />

usan
<br />

Sebastian Rahtz wrote:
<br />

<em class="quotelev1">>As you all know, any TEI schema or DTD has an attribute "TEIform" for
</em><br />
<em class="quotelev1">>every element.
</em><br />
<em class="quotelev1">>It contains the name of the element, and is there to help you
</em><br />
<em class="quotelev1">>reconstruct documents
</em><br />
<em class="quotelev1">>where the element name has changed.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>We now know how to do this better by reference back to the ODD source,
</em><br />
<em class="quotelev1">>which also covers attribute names.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>Hands up all those who would be willing to quietly drop this dinosaur
</em><br />
<em class="quotelev1">>artefact?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742
Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib_at_umd.<!--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> Sun Nov 13 2005 - 08:11:07 EST</span>
</div>

From Laurent.Romary at loria.fr  Sun Nov 13 09:44:48 2005
From: Laurent.Romary at loria.fr (Laurent.Romary_at_loria.fr)
Date: Sun, 13 Nov 2005 15:44:48 +0100
Subject: [tei-council] @TEIform
In-Reply-To: <437729E5.80808@oucs.ox.ac.uk>
Message-ID: <1131893088.43775160b8212@www.loria.fr>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: <Laurent.Romary_at_loria.fr>
</span><br />
<span id="date"><dfn>Date</dfn>: Sun, 13 Nov 2005 15:44:48 +0100</span><br />
</address>

Yes! Please drop it!
<br />
Laurent
<br />

<p>Selon Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk>:
<br />

<em class="quotelev1">> As you all know, any TEI schema or DTD has an attribute "TEIform" for
</em><br />
<em class="quotelev1">> every element.
</em><br />
<em class="quotelev1">> It contains the name of the element, and is there to help you
</em><br />
<em class="quotelev1">> reconstruct documents
</em><br />
<em class="quotelev1">> where the element name has changed.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> We now know how to do this better by reference back to the ODD source,
</em><br />
<em class="quotelev1">> which also covers attribute names.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Hands up all those who would be willing to quietly drop this dinosaur
</em><br />
<em class="quotelev1">> artefact?
</em><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 />
<em class="quotelev1">> OSS Watch: JISC Open Source Advisory Service
</em><br />
<em class="quotelev1">> http://www.oss-watch.ac.uk
</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.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><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 Nov 13 2005 - 09:44:57 EST</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Sun Nov 13 10:03:23 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 13 Nov 2005 15:03:23 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <1131893088.43775160b8212@www.loria.fr>
Message-ID: <437755BB.50401@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>: Sun, 13 Nov 2005 15:03:23 +0000</span><br />
</address>

<em class="quotelev1">>Sebastian Rahtz <sebastian.rahtz_at_oucs.ox.ac.uk>:
</em><br />
<em class="quotelev2">>>We now know how to do this better by reference back to the ODD source,
</em><br />
<em class="quotelev2">>>which also covers attribute names.
</em><br />
<em class="quotelev2">>>Hands up all those who would be willing to quietly drop this dinosaur
</em><br />
<em class="quotelev2">>>artefact?
</em><br />

<p>First, let me say that my gut instinct is to drop it.  Second, by way 
<br />
of playing Devil's Advocate, let me ask why it was there in the first 
<br />
place?
<br />

My assumption has always been that in document instances which 
<br />
conformed to an extended DTD where TEI elements had been renamed, a 
<br />
processed version of the document might exist out of context from its 
<br />
DTD.  (Since it is the processing of the document in conjunction with 
<br />
the DTD which provides the attribute.)  So once a document instance is 
<br />
moved somewhere else from it's DTD, that I have a <chapter> element 
<br />
which is really just a type of <div> becomes problematised because I 
<br />
have not documented that it is just a <div type="chapter">.  However, 
<br />
if I have a @TEIform, then the processed/expanded document, even in 
<br />
absence of its DTD will have @TEIform="div", thus providing some 
<br />
perhaps crucial information to someone happening upon the document 
<br />
years later.
<br />

What I'm wondering about the reference-back-to-ODD-source method is 
<br />
that it depends upon the existence of another file (much like, you can 
<br />
argue, the unprocessed file does to its DTD).  I'm more than happy to 
<br />
drop @TEIform, because it has never been any actual use to me, 
<br />
however, I am wary about just zapping it without being sure that we're 
<br />
providing as reliable a mechanism since Lou and others must surely 
<br />
have thought it a good idea at some point.  Well, that is the best I 
<br />
can do as a Devil's advocate I think.
<br />

So explain to me again how the reference back to the ODD source works? 
<br />
  I'm of course in favour of that as a mechanism since it also covers 
<br />
attribute names.
<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 Nov 13 2005 - 10:03:16 EST</span>
</div>

From jawalsh at indiana.edu  Sun Nov 13 10:52:55 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Sun, 13 Nov 2005 10:52:55 -0500
Subject: [tei-council] @TEIform
In-Reply-To: <437755BB.50401@computing-services.oxford.ac.uk>
Message-ID: <56C36E44-BB65-483F-A9BB-23111CA4E4C5@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>: Sun, 13 Nov 2005 10:52:55 -0500</span><br />
</address>

Hi all,
<br />

I'm in agreement with James.  I'd like to hear a bit more about the  
<br />
"reference-back-to-ODD-source method" before agreeing to drop  
<br />
TEIform.  For something like my Comic Book Markup Language, a TEI  
<br />
extension set that is more of a radical departure from vanilla TEI  
<br />
than the norm, the TEIform element can be useful for tracing one's  
<br />
way back to the original TEI elements.
<br />

John
<br />

--
| John A. Walsh
| Associate Director for Projects and Services, Digital Library Program
| Associate Librarian, University Libraries
| Adjunct Associate Professor, Department of English
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 Fax:812-856-2062 <mailto:jawalsh_at_indiana.<!--nospam-->edu>
On Nov 13, 2005, at 10:03 AM, James Cummings wrote:
>> Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk>:
>>> We now know how to do this better by reference back to the ODD  
>>> source,
>>> which also covers attribute names.
>>> Hands up all those who would be willing to quietly drop this  
>>> dinosaur
>>> artefact?
>
>
> First, let me say that my gut instinct is to drop it.  Second, by  
> way of playing Devil's Advocate, let me ask why it was there in the  
> first place?
>
> My assumption has always been that in document instances which  
> conformed to an extended DTD where TEI elements had been renamed, a  
> processed version of the document might exist out of context from  
> its DTD.  (Since it is the processing of the document in  
> conjunction with the DTD which provides the attribute.)  So once a  
> document instance is moved somewhere else from it's DTD, that I  
> have a <chapter> element which is really just a type of <div>  
> becomes problematised because I have not documented that it is just  
> a <div type="chapter">.  However, if I have a @TEIform, then the  
> processed/expanded document, even in absence of its DTD will have  
> @TEIform="div", thus providing some perhaps crucial information to  
> someone happening upon the document years later.
>
> What I'm wondering about the reference-back-to-ODD-source method is  
> that it depends upon the existence of another file (much like, you  
> can argue, the unprocessed file does to its DTD).  I'm more than  
> happy to drop @TEIform, because it has never been any actual use to  
> me, however, I am wary about just zapping it without being sure  
> that we're providing as reliable a mechanism since Lou and others  
> must surely have thought it a good idea at some point.  Well, that  
> is the best I can do as a Devil's advocate I think.
>
> So explain to me again how the reference back to the ODD source  
> works?  I'm of course in favour of that as a mechanism since it  
> also covers attribute names.
>
> -James
> _______________________________________________
> 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> Sun Nov 13 2005 - 10:53:06 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Nov 13 11:18:40 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 13 Nov 2005 16:18:40 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <437755BB.50401@computing-services.oxford.ac.uk>
Message-ID: <43776760.8060201@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, 13 Nov 2005 16:18:40 +0000</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> My assumption has always been that in document instances which
</em><br />
<em class="quotelev1">> conformed to an extended DTD where TEI elements had been renamed, a
</em><br />
<em class="quotelev1">> processed version of the document might exist out of context from its
</em><br />
<em class="quotelev1">> DTD.  (Since it is the processing of the document in conjunction with
</em><br />
<em class="quotelev1">> the DTD which provides the attribute.)  So once a document instance is
</em><br />
<em class="quotelev1">> moved somewhere else from it's DTD, that I have a <chapter> element
</em><br />
<em class="quotelev1">> which is really just a type of <div> becomes problematised because I
</em><br />
<em class="quotelev1">> have not documented that it is just a <div type="chapter">.  However,
</em><br />
<em class="quotelev1">> if I have a @TEIform, then the processed/expanded document, even in
</em><br />
<em class="quotelev1">> absence of its DTD will have @TEIform="div", thus providing some
</em><br />
<em class="quotelev1">> perhaps crucial information to someone happening upon the document
</em><br />
<em class="quotelev1">> years later.
</em><br />

This is all true _only_ if you have taken your source document with its
<br />
DTD, and run it through some sort
<br />
of normalization process.  The TEIform attribute of your <chapter> is
<br />
provided only by the DTD, not
<br />
in the instance (does anyone use TEIform manually?). I suggest that the
<br />
using the "normalized" form of
<br />
document, with all implied attributes inserted, is not
<br />
remotely common working practice.
<br />
If you keep the DTD around, then things are OK.
<br />

In P5 world, you have to track two support files, the original ODD file,
<br />
and the generated schema file; the downside is
<br />
that you may use the schema file every day, but the ODD only once in a
<br />
blue moon, so you may get confused.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> So explain to me again how the reference back to the ODD source works?
</em><br />
<em class="quotelev1">>  I'm of course in favour of that as a mechanism since it also covers
</em><br />
<em class="quotelev1">> attribute names.
</em><br />

I find <chapter>. I read the ODD source to see if if
<br />
"elementSpec/altltIdent[.='chapter']" exists.
<br />
If so, I grab ../@ident, and rename my <chapter> to whatever that is.
<br />

easy, no?
<br />

of course, a variant ODD processor might generate you a custom XSL
<br />
script or the like to do the job
<br />
straight off.
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Nov 13 2005 - 11:18:45 EST</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Sun Nov 13 11:31:55 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 13 Nov 2005 16:31:55 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <43776760.8060201@oucs.ox.ac.uk>
Message-ID: <43776A7B.6010904@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>: Sun, 13 Nov 2005 16:31:55 +0000</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev1">> This is all true _only_ if you have taken your source document with its
</em><br />
<em class="quotelev1">> DTD, and run it through some sort
</em><br />
<em class="quotelev1">> of normalization process.  The TEIform attribute of your <chapter> is
</em><br />
<em class="quotelev1">> provided only by the DTD, not
</em><br />
<em class="quotelev1">> in the instance (does anyone use TEIform manually?). I suggest that the
</em><br />
<em class="quotelev1">> using the "normalized" form of
</em><br />
<em class="quotelev1">> document, with all implied attributes inserted, is not
</em><br />
<em class="quotelev1">> remotely common working practice.
</em><br />

I agree, that is why I was careful to say processed/expanded instance 
<br />
document.  I know of no one who uses TEIform manually.  And yes, I 
<br />
don't think most people use a normalized document with all those expanded.
<br />

<em class="quotelev1">> If you keep the DTD around, then things are OK.
</em><br />

Yes, though after initial creation/validation there are many who 
<br />
misplace their DTDs.
<br />

<em class="quotelev1">> In P5 world, you have to track two support files, the original ODD file,
</em><br />
<em class="quotelev1">> and the generated schema file; the downside is
</em><br />
<em class="quotelev1">> that you may use the schema file every day, but the ODD only once in a
</em><br />
<em class="quotelev1">> blue moon, so you may get confused.
</em><br />

This is what makes me wary.  While I can picture people keeping their 
<br />
schemas around (as much as I can picture them keeping their DTDs 
<br />
around), once the schema is created, I find it very likely that people 
<br />
will mistakenly misplace their ODD sources.  But I suppose we just 
<br />
have to remind people that ODD is part of their project documentation 
<br />
of how they differ from TEI.
<br />

<em class="quotelev1">> I find <chapter>. I read the ODD source to see if if
</em><br />
<em class="quotelev1">> "elementSpec/altltIdent[.='chapter']" exists.
</em><br />
<em class="quotelev1">> If so, I grab ../@ident, and rename my <chapter> to whatever that is.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> easy, no?
</em><br />

Yes, perhaps not as easy as just looking at the @TEIform ... but still 
<br />
fairly straightforward if I have the ODD source.
<br />

<em class="quotelev1">> of course, a variant ODD processor might generate you a custom XSL
</em><br />
<em class="quotelev1">> script or the like to do the job
</em><br />
<em class="quotelev1">> straight off.
</em><br />

Do you have an XSL already which does this for simple syntactic sugar 
<br />
renamings?
<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 Nov 13 2005 - 11:31:49 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Nov 13 11:33:40 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 13 Nov 2005 16:33:40 +0000
Subject: [tei-council] numbered divs
In-Reply-To: <17271.13348.990964.718256@emt.wwp.brown.edu>
Message-ID: <43776AE4.2020701@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, 13 Nov 2005 16:33:40 +0000</span><br />
</address>

Syd Bauman wrote:
<br />

<em class="quotelev1">>On the other hand, you voiced in earlier mail (not to the list) the
</em><br />
<em class="quotelev1">>thought of further constraining this back to "only numbered OR only
</em><br />
<em class="quotelev1">>un-numbered" with a Schematron rule. This may not be so terrible,
</em><br />
<em class="quotelev1">>depending on what our end position is on the use of Schematron.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
it's the thin end of the wedge, of course; how do we decide
<br />
what constraints to delegate? of course, this
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">>The general problem is that dropping all members of a class may make
</em><br />
<em class="quotelev1">>some content models ambiguous in DTD (and maybe W3C) land.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>I think it is important to seriously investigate the dummy-element
</em><br />
<em class="quotelev1">>insertion idea, which could solve this general problem, not just this
</em><br />
<em class="quotelev1">>instance. This is the idea that whenever the odd2dtd processor comes
</em><br />
<em class="quotelev1">>across an empty class, it populates that class with one element
</em><br />
<em class="quotelev1">><dummy-do-not-use>. 
</em><br />
<em class="quotelev1">>
</em><br />
Its an interesting idea. The flaw in practice is that the simplification
<br />
of smoothing out things to clean up after element removal is done
<br />
before odd2dtd kicks in. So it would need a another reimplementation
<br />
of the ODD processing, paralleling the scale of work I did in April.
<br />
Marginally easier, perhaps, to attempt to locate the ambiguous bits
<br />
in the odd2 processing.
<br />

Wouldn't your dummy element be offered all the time by the
<br />
editor as a possible choice?
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Nov 13 2005 - 11:33:47 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Sun Nov 13 11:37:27 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 13 Nov 2005 16:37:27 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <43776A7B.6010904@computing-services.oxford.ac.uk>
Message-ID: <43776BC7.60407@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, 13 Nov 2005 16:37:27 +0000</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">> While I can picture people keeping their schemas around (as much as I
</em><br />
<em class="quotelev1">> can picture them keeping their DTDs around), once the schema is
</em><br />
<em class="quotelev1">> created, I find it very likely that people will mistakenly misplace
</em><br />
<em class="quotelev1">> their ODD sources.  But I suppose we just have to remind people that
</em><br />
<em class="quotelev1">> ODD is part of their project documentation of how they differ from TEI.
</em><br />

if they use ODD properly, they'll have their documentation in there too.
<br />

<em class="quotelev2">>> of course, a variant ODD processor might generate you a custom XSL
</em><br />
<em class="quotelev2">>> script or the like to do the job
</em><br />
<em class="quotelev2">>> straight off.
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Do you have an XSL already which does this for simple syntactic sugar
</em><br />
<em class="quotelev1">> renamings?
</em><br />
<em class="quotelev1">>
</em><br />
I showed something like it to you in my talk in Sofia :-}
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Sun Nov 13 2005 - 11:37:32 EST</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Nov 13 22:41:13 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 14 Nov 2005 12:41:13 +0900
Subject: [tei-council] @TEIform
In-Reply-To: <43776A7B.6010904@computing-services.oxford.ac.uk>
Message-ID: <ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 14 Nov 2005 12:41:13 +0900</span><br />
</address>

James Cummings <James.Cummings_at_computing-services.<!--nospam-->oxford.ac.uk> writes:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> This is what makes me wary.  While I can picture people keeping their
</em><br />
<em class="quotelev1">> schemas around (as much as I can picture them keeping their DTDs
</em><br />
<em class="quotelev1">> around), once the schema is created, I find it very likely that people
</em><br />
<em class="quotelev1">> will mistakenly misplace their ODD sources.  But I suppose we just
</em><br />
<em class="quotelev1">> have to remind people that ODD is part of their project documentation
</em><br />
<em class="quotelev1">> of how they differ from TEI.
</em><br />

We have discussed at some point if/how an instance document should
<br />
mention its ODD source, but I don't think we have come to a
<br />
conclusion.  I would be uncomfortable dropping @TEIform (to which I do
<br />
not object)without at least this mechanism in place.
<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> Sun Nov 13 2005 - 22:41:49 EST</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Mon Nov 14 03:26:50 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Mon, 14 Nov 2005 08:26:50 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43784A4A.4080208@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>: Mon, 14 Nov 2005 08:26:50 +0000</span><br />
</address>

Christian Wittern wrote:
<br />
<em class="quotelev1">> James Cummings <James.Cummings_at_computing-services.oxford.ac.uk> writes:
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev2">>>This is what makes me wary.  While I can picture people keeping their
</em><br />
<em class="quotelev2">>>schemas around (as much as I can picture them keeping their DTDs
</em><br />
<em class="quotelev2">>>around), once the schema is created, I find it very likely that people
</em><br />
<em class="quotelev2">>>will mistakenly misplace their ODD sources.  But I suppose we just
</em><br />
<em class="quotelev2">>>have to remind people that ODD is part of their project documentation
</em><br />
<em class="quotelev2">>>of how they differ from TEI.
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> We have discussed at some point if/how an instance document should
</em><br />
<em class="quotelev1">> mention its ODD source, but I don't think we have come to a
</em><br />
<em class="quotelev1">> conclusion.  I would be uncomfortable dropping @TEIform (to which I do
</em><br />
<em class="quotelev1">> not object)without at least this mechanism in place.
</em><br />

Having a place in the teiHeader to refer to an ODD...or even embed it 
<br />
(or this that too horribly recursive?) seems reasonable.  Perhaps a 
<br />
URI attribute in tagsDecl?  Would such a thing point just to the ODD 
<br />
source or to generated schemas as well?
<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> Mon Nov 14 2005 - 03:26:49 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Nov 14 04:06:20 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 14 Nov 2005 09:06:20 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <4378538C.4050801@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, 14 Nov 2005 09:06:20 +0000</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>We have discussed at some point if/how an instance document should
</em><br />
<em class="quotelev1">>mention its ODD source, but I don't think we have come to a
</em><br />
<em class="quotelev1">>conclusion.  I would be uncomfortable dropping @TEIform (to which I do
</em><br />
<em class="quotelev1">>not object)without at least this mechanism in place.
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
Since a DOCTYPE is not mandated (or even used, by some
<br />
applications), the status quo is that there is no default
<br />
link from an instance to a DTD (which is
<br />
where the @TEIform is).....
<br />

<p>sebastian
<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 Nov 14 2005 - 04:06:23 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Nov 14 04:19:56 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 14 Nov 2005 09:19:56 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <43784A4A.4080208@computing-services.oxford.ac.uk>
Message-ID: <437856BC.70803@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, 14 Nov 2005 09:19:56 +0000</span><br />
</address>

James Cummings wrote:
<br />

<em class="quotelev1">> Having a place in the teiHeader to refer to an ODD...or even embed it 
</em><br />
<em class="quotelev1">> (or this that too horribly recursive?) 
</em><br />

ounds expensive...
<br />

<em class="quotelev1">> seems reasonable.  Perhaps a URI attribute in tagsDecl?  Would such a 
</em><br />
<em class="quotelev1">> thing point just to the ODD source or to generated schemas as well?
</em><br />

oh gosh you'll start up Syd's thread again. Mind you, I don't object to 
<br />
adding a URI hook
<br />
linking to an ODD somewhere in the header.
<br />

But let's recall James Clark's belief (strongly supported in some circles)
<br />
that an instance may have several schemata against which it may or may not
<br />
be valid. There is no one right answer. So it goes against this argument
<br />
to associate an instance with just one {XSD,RNG,DTD}.
<br />

However, an ODD does some more work. In this case it defines
<br />
relationships between used element names and TEI ur-element
<br />
names. In some ideal world, we would extract just that info
<br />
and put it in the header - and how would we keep it up to date
<br />
and accurate, etc? If we use <equiv> in the manner I suggested in Sofia,
<br />
we need external data sources to do the translation anyway.
<br />

We worry that a document may become separated from its metadata,
<br />
or the metadata lost. And? A binary program separated from its source
<br />
happens too. Its bad. But you cannot legislate against it.
<br />

We have already accepted that the I18N work presupposes the
<br />
ability to translate from an instance which has translated names;
<br />
this needs an ODD, since @TEIform does not help with attributes.<!--nospam-->
<br />

In the new world where DTDs no  longer reign supreme,
<br />
attributes with default values, like @TEIform, are an anachronistic
<br />
pain in the neck. They arent there when you might like them, if you
<br />
use schema processing, and they pop up when you don't want them
<br />
(when an editor shows you a list of 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> Mon Nov 14 2005 - 04:19:59 EST</span>
</div>

From lou.burnard at computing-services.oxford.ac.uk  Mon Nov 14 04:56:36 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 14 Nov 2005 09:56:36 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <437856BC.70803@oucs.ox.ac.uk>
Message-ID: <43785F54.2060800@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, 14 Nov 2005 09:56:36 +0000</span><br />
</address>

Sebastian Rahtz wrote:
<br />

<em class="quotelev1">> James Cummings wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> Having a place in the teiHeader to refer to an ODD...or even embed it 
</em><br />
<em class="quotelev2">>> (or this that too horribly recursive?) 
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> sounds expensive...
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>> seems reasonable.  Perhaps a URI attribute in tagsDecl?  Would such a 
</em><br />
<em class="quotelev2">>> thing point just to the ODD source or to generated schemas as well?
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev1">> oh gosh you'll start up Syd's thread again. Mind you, I don't object 
</em><br />
<em class="quotelev1">> to adding a URI hook
</em><br />
<em class="quotelev1">> linking to an ODD somewhere in the header.
</em><br />

<p>This sounds useful to me. And not expensive!
<br />

<p><em class="quotelev1">>
</em><br />
<em class="quotelev1">> But let's recall James Clark's belief (strongly supported in some 
</em><br />
<em class="quotelev1">> circles)
</em><br />
<em class="quotelev1">> that an instance may have several schemata against which it may or may 
</em><br />
<em class="quotelev1">> not
</em><br />
<em class="quotelev1">> be valid. There is no one right answer. So it goes against this argument
</em><br />
<em class="quotelev1">> to associate an instance with just one {XSD,RNG,DTD}.
</em><br />
<em class="quotelev1">>
</em><br />

Not so sure I am persuaded by this argument. I can think of cases where 
<br />
it makes quite a bit of sense to say that a given instance *was* 
<br />
validated against a specific schema instance (or , in our case, a given 
<br />
ODD).  There is also the problem that not all schema languages support 
<br />
the same constraints of course.
<br />

<p><em class="quotelev1">> However, an ODD does some more work. In this case it defines
</em><br />
<em class="quotelev1">> relationships between used element names and TEI ur-element
</em><br />
<em class="quotelev1">> names. In some ideal world, we would extract just that info
</em><br />
<em class="quotelev1">> and put it in the header
</em><br />

we do that already, even in our current sublunary world. namely viz 
<br />
tagsdecl.
<br />
Hmm, we could conceivably add an attribute to that giving the canonical 
<br />
name for each element used?
<br />

<em class="quotelev1">> - and how would we keep it up to date
</em><br />
<em class="quotelev1">> and accurate, etc? If we use <equiv> in the manner I suggested in Sofia,
</em><br />
<em class="quotelev1">> we need external data sources to do the translation anyway.
</em><br />
<em class="quotelev1">>
</em><br />

Maybe its the content of the equiv element which needs to go into the 
<br />
header, rather than a pointer to the ODD itself?
<br />

<em class="quotelev1">> We worry that a document may become separated from its metadata,
</em><br />
<em class="quotelev1">> or the metadata lost. And? A binary program separated from its source
</em><br />
<em class="quotelev1">> happens too. Its bad. But you cannot legislate against it.
</em><br />
<em class="quotelev1">>
</em><br />

Not a good argument. Many binaries contain (often in excurciating 
<br />
detail) lots of information about when they were last compiled and 
<br />
against what.
<br />

<em class="quotelev1">> We have already accepted that the I18N work presupposes the
</em><br />
<em class="quotelev1">> ability to translate from an instance which has translated names;
</em><br />
<em class="quotelev1">> this needs an ODD, since @TEIform does not help with attributes.<!--nospam-->
</em><br />
<em class="quotelev1">>
</em><br />

This on the other hand is  very good argument
<br />

<em class="quotelev1">> In the new world where DTDs no  longer reign supreme,
</em><br />
<em class="quotelev1">> attributes with default values, like @TEIform, are an anachronistic
</em><br />
<em class="quotelev1">> pain in the neck. They arent there when you might like them, if you
</em><br />
<em class="quotelev1">> use schema processing, and they pop up when you don't want them
</em><br />
<em class="quotelev1">> (when an editor shows you a list of attributes).
</em><br />
<em class="quotelev1">>
</em><br />

<p>I agree, on balance.
<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 Nov 14 2005 - 04:56:39 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Nov 14 06:24:23 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 14 Nov 2005 11:24:23 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <43785F54.2060800@computing-services.oxford.ac.uk>
Message-ID: <437873E7.4010904@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, 14 Nov 2005 11:24:23 +0000</span><br />
</address>

Lou Burnard wrote:
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> we do that already, even in our current sublunary world. namely viz 
</em><br />
<em class="quotelev1">> tagsdecl.
</em><br />
<em class="quotelev1">> Hmm, we could conceivably add an attribute to that giving the 
</em><br />
<em class="quotelev1">> canonical name for each element used?
</em><br />

but that a) doesn't cover attributes, and b) only covers simple renaming.
<br />

<em class="quotelev1">>
</em><br />
<em class="quotelev1">> Maybe its the content of the equiv element which needs to go into the 
</em><br />
<em class="quotelev1">> header, rather than a pointer to the ODD itself?
</em><br />

how would they get there, tho?
<br />

James and I suggested to each other today that Roma should spit
<br />
out an XSLT script for a given ODD which performed the canonicalisation
<br />
for instances against that ODD. How would that suit?
<br />

This would require some decisions on what "canonicalisation" means.
<br />
Redoing the names of things is fine, but what does the script do
<br />

 - when an element is added (make it into a <seg type=$name>?)
<br />
 - when an attribute is added  (???? squash it into @rend?)
<br />
 - when a datatype is changed (do nothing?)
<br />

obviously the canonicalisation does not (cannot) guarentee validitity 
<br />
against a
<br />
core schema set.
<br />

The I18N stuff requires this script generation anyway, probably.
<br />

Sebastian
<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 Nov 14 2005 - 06:24:27 EST</span>
</div>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Nov 14 07:36:42 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 14 Nov 2005 21:36:42 +0900
Subject: [tei-council] @TEIform
In-Reply-To: <4378538C.4050801@oucs.ox.ac.uk>
Message-ID: <ygfu0efxv6t.fsf@chwpb.local>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Christian Wittern <wittern_at_kanji.zinbun.kyoto-u.ac.jp>
</span><br />
<span id="date"><dfn>Date</dfn>: Mon, 14 Nov 2005 21:36:42 +0900</span><br />
</address>

Sebastian Rahtz <sebastian.rahtz_at_oucs.<!--nospam-->ox.ac.uk> writes:
<br />

<em class="quotelev1">> Christian Wittern wrote:
</em><br />
<em class="quotelev1">>
</em><br />
<em class="quotelev2">>>We have discussed at some point if/how an instance document should
</em><br />
<em class="quotelev2">>>mention its ODD source, but I don't think we have come to a
</em><br />
<em class="quotelev2">>>conclusion.  I would be uncomfortable dropping @TEIform (to which I do
</em><br />
<em class="quotelev2">>>not object)without at least this mechanism in place.
</em><br />
<em class="quotelev2">>>  
</em><br />
<em class="quotelev2">>>
</em><br />
<em class="quotelev1">> Since a DOCTYPE is not mandated (or even used, by some
</em><br />
<em class="quotelev1">> applications), the status quo is that there is no default
</em><br />
<em class="quotelev1">> link from an instance to a DTD (which is
</em><br />
<em class="quotelev1">> where the @TEIform is).....
</em><br />

Well -- I agree that these are different beasts, and I am not asking
<br />
for a link to a schema, but rather to an ODD.  
<br />

A dedicated attribute that takes a URI value would be good enough for
<br />
most cases, although I also see that for some cases embedding seems to
<br />
be elegant, which is something we have discussed recently in another
<br />
context as well.  Maybe we should call it the kangaroo method and make
<br />
it a general principle for auxiliary data (charDesc, prosopography,
<br />
you-name-it).  Is this something in scope for the SO group?
<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 Nov 14 2005 - 07:37:24 EST</span>
</div>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Nov 14 07:59:35 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 14 Nov 2005 12:59:35 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <ygfu0efxv6t.fsf@chwpb.local>
Message-ID: <43788A37.4000608@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, 14 Nov 2005 12:59:35 +0000</span><br />
</address>

Christian Wittern wrote:
<br />

<em class="quotelev1">>A dedicated attribute that takes a URI value would be good enough for
</em><br />
<em class="quotelev1">>most cases, although I also see that for some cases embedding seems to
</em><br />
<em class="quotelev1">>be elegant, which is something we have discussed recently in another
</em><br />
<em class="quotelev1">>context as well.  Maybe we should call it the kangaroo method and make
</em><br />
<em class="quotelev1">>it a general principle for auxiliary data (charDesc, prosopography,
</em><br />
<em class="quotelev1">>you-name-it).  Is this something in scope for the SO group?
</em><br />
<em class="quotelev1">>  
</em><br />
<em class="quotelev1">>
</em><br />
You are suggesting a new section in the header which is used to
<br />
link to metadata? I do like the idea at first sight.
<br />

curiously, I just had a discussion here about
<br />
where to reference an RSS feed which relates to the current
<br />
document (we have currently have it in <notesStmt>, which
<br />
is not ideal).
<br />

-- 
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.<!--nospam-->village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

<span id="received"><dfn>Received on</dfn> Mon Nov 14 2005 - 07:59:52 EST</span>
</div>

From Laurent.Romary at loria.fr  Mon Nov 14 09:18:57 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Mon, 14 Nov 2005 15:18:57 +0100
Subject: [tei-council] @TEIform
In-Reply-To: <43788A37.4000608@oucs.ox.ac.uk>
Message-ID: <3A5C92E3-87B5-4A62-9C6E-D68FD091AAA0@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, 14 Nov 2005 15:18:57 +0100</span><br />
</address>

Sorry to be abrupt here, but as I see it from the discussion so far:  
<br />
apart from the fear to loose a mechanism that is not used nor liked  
<br />
by anyone and the fact that there is a continuous thread on refereing  
<br />
to a schema in the header, do we have a good reason to pospone the  
<br />
final eradication of @TEIForm? ("Burn!")
<br />
Laurent
<br />
_______________________________________________
<br />
tei-council mailing list
<br />
tei-council_at_lists.village.Virginia.EDU
<br />
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
<br />
<span id="received"><dfn>Received on</dfn> Mon Nov 14 2005 - 09:17:58 EST</span>
</div>

From James.Cummings at computing-services.oxford.ac.uk  Mon Nov 14 09:58:49 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Mon, 14 Nov 2005 14:58:49 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <437873E7.4010904@oucs.ox.ac.uk>
Message-ID: <4378A629.4020507@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>: Mon, 14 Nov 2005 14:58:49 +0000</span><br />
</address>

Sebastian Rahtz wrote:
<br />
<em class="quotelev1">> James and I suggested to each other today that Roma should spit
</em><br />
<em class="quotelev1">> out an XSLT script for a given ODD which performed the canonicalisation
</em><br />
<em class="quotelev1">> for instances against that ODD. How would that suit?
</em><br />

As you know, I would like that very much.
<br />

<em class="quotelev1">> This would require some decisions on what "canonicalisation" means.
</em><br />
<em class="quotelev1">> Redoing the names of things is fine, but what does the script do
</em><br />
<em class="quotelev1">> 
</em><br />
<em class="quotelev1">> - when an element is added (make it into a <seg type=$name>?)
</em><br />

Or should this depend on its model class, if it uses an existing one?
<br />

<em class="quotelev1">> - when an attribute is added  (???? squash it into @rend?)
</em><br />

While I don't like that (especially not using @rend...) if I have
<br />
several attributes that I'd added. Let's say I add @favouriteColour
<br />
@eyeColour and @hairColour to <person> for some strange reason.  Does
<br />
that mean that we get:
<br />
<person rend="favouriteColour:009900; eyeColour:Brown; hairColour:Brown;">
<br />
Surely @rend is the wrong thing to use.
<br />
Let's see... an attribute for storing this kind of information...we could
<br />
call it @TEIForm. ;-)  *duck*
<br />

<em class="quotelev1">> - when a datatype is changed (do nothing?)
</em><br />

Frightening.
<br />

<p>-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> Mon Nov 14 2005 - 09:58:52 EST</span>
</div>

From mz34 at nyu.edu  Tue Nov 15 10:25:01 2005
From: mz34 at nyu.edu (Matthew Zimmerman)
Date: Tue, 15 Nov 2005 10:25:01 -0500
Subject: [tei-council] Council Chair
Message-ID: <38576D65-D2D8-4AAE-8F7F-26820445B316@nyu.edu>

<div class="mail">
<address class="headers">
<span id="from">
<dfn>From</dfn>: Matthew Zimmerman <mz34_at_nyu.edu>
</span><br />
<span id="date"><dfn>Date</dfn>: Tue, 15 Nov 2005 10:25:01 -0500</span><br />
</address>

I am happy to announce that the Board has unanimously voted to  
<br />
reappoint Christian Wittern as chair of the TEI-C Technical Council  
<br />
for another term from Jan 1, 2006 to Dec 31, 2006, and Christian has  
<br />
graciously accepted.
<br />

MZ
<br />
_________________
<br />
Matthew Zimmerman
<br />
Faculty Technology Services, NYU
<br />
Tel: 212.998.3038
<br />
Fax: 212.995.4120
<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 Nov 15 2005 - 10:25:05 EST</span>
</div>

From Syd_Bauman at Brown.edu  Thu Nov 17 06:52:47 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 17 Nov 2005 06:52:47 -0500
Subject: [tei-council] Use of <imprint> wrapper inside <bibl>-like-things
Message-ID: <17276.28431.472950.912641@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, 17 Nov 2005 06:52:47 -0500</span><br />
</address>

At the "class" sub-committee meeting in Oxford in September, it was
<br />
decided to drop the <imprint> element from <bibl> and <biblItem> (but
<br />
not from <monogr>). The effect of this change from the
<br />
sub-committee's point of view is to make the TEI class system a
<br />
little simpler and more coherent. That's a good thing. The result
<br />
from the encoder's point of view is that things that are encoded as
<br />

  <bibl xml:id="IMEV">
<br />
    <author>Carleton Brown</author> and <author>Rossell Hope Robbins</author>
<br />
    <title level="m">The index of Middle English verse

      New York

      1943

in P4 would need to become

    Carleton Brown and Rossell Hope Robbins

    The index of Middle English verse

    New York

    1943

in P5.

I am posting here just to double-check that this change is OK with

Council. While all of us at the meeting were convinced that the extra

level of nesting is not helpful, I think it would be a good idea to

ask some librarians, catalogers, bibliographers, etc.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Nov 17 2005 - 06:52:59 EST

From Syd_Bauman at Brown.edu  Thu Nov 17 06:58:43 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 17 Nov 2005 06:58:43 -0500
Subject: [tei-council] Use of  wrapper inside -like-things
In-Reply-To: <17276.28431.472950.912641@emt.wwp.brown.edu>
Message-ID: <17276.28787.809885.530496@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Thu, 17 Nov 2005 06:58:43 -0500

> At the "class" sub-committee meeting in Oxford in September, it was

> decided to drop the  element from  and  (but

> not from ).

Ooops. Hit 'send' before I added my footnote:

See http://www.tei-c.org/Council/tcm20.xml?style=printable, section

    #3, item #16.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Nov 17 2005 - 06:58:52 EST

From Syd_Bauman at Brown.edu  Thu Nov 17 07:03:53 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 17 Nov 2005 07:03:53 -0500
Subject: [tei-council] numbered divs
In-Reply-To: <43776AE4.2020701@oucs.ox.ac.uk>
Message-ID: <17276.29097.983336.541874@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Thu, 17 Nov 2005 07:03:53 -0500

> it's the thin end of the wedge, of course; how do we decide what

> constraints to delegate? of course, this

It is not so obvious to me that this particular constraint should be

delegated to Schematron, as opposed to schema-enforced, at least not

at the moment.

> Its an interesting idea. The flaw in practice is that the

> simplification of smoothing out things to clean up after element

> removal is done before odd2dtd kicks in. 

Oh, blimey.

> Wouldn't your dummy element be offered all the time by the editor

> as a possible choice?

Depends on how smart the editor is, but yes, many would do that.

(Which is why there should be only 1 such dummy GI, and its name

should make it obvious it is not a real element.)

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Nov 17 2005 - 07:04:03 EST

From lou.burnard at computing-services.oxford.ac.uk  Thu Nov 17 07:12:06 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 17 Nov 2005 12:12:06 +0000
Subject: [tei-council] Use of  wrapper inside -like-things
In-Reply-To: <17276.28787.809885.530496@emt.wwp.brown.edu>
Message-ID: <437C7396.5070906@oucs.ox.ac.uk>

From: Lou Burnard 

Date: Thu, 17 Nov 2005 12:12:06 +0000

Council members might also be interested to check the current state of 

document edw92, which includes the status of all the changes on that list.

http://www.tei-c.org/Drafts/edw92.xml

Syd Bauman wrote:

>>At the "class" sub-committee meeting in Oxford in September, it was

>>decided to drop the  element from  and  (but

>>not from ).

> 

> 

> Ooops. Hit 'send' before I added my footnote:

> 

> See http://www.tei-c.org/Council/tcm20.xml?style=printable, section

>     #3, item #16.

> 

> _______________________________________________

> 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 Nov 17 2005 - 07:07:41 EST

From Syd_Bauman at Brown.edu  Thu Nov 17 07:10:40 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 17 Nov 2005 07:10:40 -0500
Subject: [tei-council] @TEIform
In-Reply-To: <437873E7.4010904@oucs.ox.ac.uk>
Message-ID: <17276.29504.203713.362607@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Thu, 17 Nov 2005 07:10:40 -0500

> James and I suggested to each other today that Roma should spit out

> an XSLT script for a given ODD which performed the canonicalisation

> for instances against that ODD. How would that suit?

Well I like the idea a whole lot, but only if it's used to

canonicalize that which can be: restrictions and isomorphisms. True

extensions need human intervention and should be left alone. (By this

auto-canonicalize software, at least.)

Thus the auto-partial-canoncializer stylesheet should leave added

eleements and attributes alone. Changed datatypes will be a pain in

the keester, as it will be at least very difficult, if not

impossible, to determine whether or not the new datatype defines a

set of values that is a subset of the canonical one's.

> The I18N stuff requires this script generation anyway, probably.

I think this is its main use. And also for projects that create

, 
, and , all analogous to .

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Nov 17 2005 - 07:10:48 EST

From sebastian.rahtz at oucs.ox.ac.uk  Thu Nov 17 07:24:11 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 17 Nov 2005 12:24:11 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <[tei-council] @TEIform>
Message-ID: <437C766B.1040003@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Thu, 17 Nov 2005 12:24:11 +0000

I am not sure this message got through, as it had an attachment.

I said

"here's a laugh for you, an XSLT script which transforms an instance

back to canonical form by reading its ODD and looking

for altIdent. See if you can catch it out."

http://www.tei-c.org/P5/canonicalise.xsl

-- 
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 Nov 17 2005 - 07:24:24 EST

From sebastian.rahtz at oucs.ox.ac.uk  Thu Nov 17 07:25:17 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 17 Nov 2005 12:25:17 +0000
Subject: [tei-council] @TEIform -> /dev/null
Message-ID: <437C76AD.3000308@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Thu, 17 Nov 2005 12:25:17 +0000

I also said this, with an attachment:

"Just to prove it can be done, the attached XSLT transform is designed to

be run on a (compiled) ODD file.

It will construct a new custom XSLT script which will "canonicalize" XML

instances which are valid

against schemas from the original ODD, making normal TEI again. It deals

with renamed attributes

and elements, and  constructs. I leave it as an

exercise for the reader (that's you,

James) to add sensible support for new elements or attributes.

_now_  can I delete @TEIform, pretty please?

A prize for the person who explains why I put in that condition of

"(compiled)" up there.

Another prize for the first person to construct an ODD and actually test

that this works."

http://www.tei-c.org/P5/oddtofilter.xsl

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 Nov 17 2005 - 07:25:30 EST

From sebastian.rahtz at oucs.ox.ac.uk  Thu Nov 17 07:31:34 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 17 Nov 2005 12:31:34 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <17276.29504.203713.362607@emt.wwp.brown.edu>
Message-ID: <437C7826.20502@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Thu, 17 Nov 2005 12:31:34 +0000

Syd Bauman wrote:

>Well I like the idea a whole lot, but only if it's used to

>canonicalize that which can be: restrictions and isomorphisms. True

>extensions need human intervention and should be left alone. (By this

>auto-canonicalize software, at least.)

>  

>

That would be the default action of my script.

>I think this is its main use. And also for projects that create

>, , and , all analogous to .

>  

>

they'll need to use my  route, of course.

-- 
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 Nov 17 2005 - 07:31:46 EST

From lou.burnard at computing-services.oxford.ac.uk  Thu Nov 17 07:40:18 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 17 Nov 2005 12:40:18 +0000
Subject: [tei-council] @TEIform -> /dev/null
In-Reply-To: <437C76AD.3000308@oucs.ox.ac.uk>
Message-ID: <437C7A32.1010804@oucs.ox.ac.uk>

From: Lou Burnard 

Date: Thu, 17 Nov 2005 12:40:18 +0000

Sebastian Rahtz wrote:

> I also said this, with an attachment:

> 

> 

> _now_  can I delete @TEIform, pretty please?

> 

> 

When I saw him yesterday, Laurent was quite emphatic on the necessity 

for doing this AS SOON AS POSSIBLE

I suggest you make it so without further delay.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Nov 17 2005 - 07:35:52 EST

From pwillett at umich.edu  Thu Nov 17 07:52:59 2005
From: pwillett at umich.edu (Perry Willett)
Date: Thu, 17 Nov 2005 07:52:59 -0500
Subject: [tei-council] Use of  wrapper inside -like-things
In-Reply-To: <17276.28431.472950.912641@emt.wwp.brown.edu>
Message-ID: <000401c5eb75$da0c5730$922bd38d@CLUBSODA>

From: Perry Willett 

Date: Thu, 17 Nov 2005 07:52:59 -0500

Speaking for myself and not for the entire library profession,  (or

 in  for that matter) has always struck me as

unnecessary. Seems like a vestige of MARC or something.

Perry Willett

University of Michigan

pwillett_at_umich.edu

-----Original Message-----

From: tei-council-bounces_at_lists.village.Virginia.EDU

[mailto:tei-council-bounces_at_lists.village.Virginia.EDU] On Behalf Of Syd

Bauman

Sent: Thursday, November 17, 2005 6:53 AM

To: TEI Council

Subject: [tei-council] Use of  wrapper inside -like-things

At the "class" sub-committee meeting in Oxford in September, it was

decided to drop the  element from  and  (but

not from ). The effect of this change from the

sub-committee's point of view is to make the TEI class system a

little simpler and more coherent. That's a good thing. The result

from the encoder's point of view is that things that are encoded as

    Carleton Brown and Rossell Hope

Robbins

    The index of Middle English verse

      New York

      1943

in P4 would need to become

    Carleton Brown and Rossell Hope

Robbins

    The index of Middle English verse

    New York

    1943

in P5.

I am posting here just to double-check that this change is OK with

Council. While all of us at the meeting were convinced that the extra

level of nesting is not helpful, I think it would be a good idea to

ask some librarians, catalogers, bibliographers, etc.

_______________________________________________

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 Nov 17 2005 - 07:53:08 EST

From sebastian.rahtz at oucs.ox.ac.uk  Thu Nov 17 09:25:56 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 17 Nov 2005 14:25:56 +0000
Subject: [tei-council] @TEIform -> /dev/null
In-Reply-To: <437C7A32.1010804@oucs.ox.ac.uk>
Message-ID: <437C92F4.8060804@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Thu, 17 Nov 2005 14:25:56 +0000

> When I saw him yesterday, Laurent was quite emphatic on the necessity 

> for doing this AS SOON AS POSSIBLE

I sympathize, but why is it urgent? has it been traced as the cause of 

Paris riots?

>

> I suggest you make it so without further delay.

>

I'm very very reluctant indeed to make a new release at this moment,

while edw92 is on the work bench.

I can remove the code in the stylesheets, though.

ebastian

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Nov 17 2005 - 09:25:58 EST

From nsmith at email.unc.edu  Thu Nov 17 09:42:54 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Thu, 17 Nov 2005 09:42:54 -0500 (Eastern Standard Time)
Subject: [tei-council] Use of  wrapper inside -like-things
In-Reply-To: <437C7396.5070906@oucs.ox.ac.uk>
Message-ID: 

From: Natasha Smith 

Date: Thu, 17 Nov 2005 09:42:54 -0500 (Eastern Standard Time)

> Council members might also be interested to check the current state of 

> document edw92, which includes the status of all the changes on that list. 

> http://www.tei-c.org/Drafts/edw92.xml

> > See http://www.tei-c.org/Council/tcm20.xml?style=printable, section 

#3, item #16.

read both documents and agree with the decision to move  out from

 and .

best, ns

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Nov 17 2005 - 09:43:04 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Nov 18 18:57:40 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 19 Nov 2005 08:57:40 +0900
Subject: [tei-council] W3C Xpointer schema registry
Message-ID: 

From: Christian Wittern 

Date: Sat, 19 Nov 2005 08:57:40 +0900

Dear council members,

As instructed during the last call, I wrote a message to Henry

Thompson of the W3C, to express the TEI's interest in getting the

registry up and running.  It took me a while to write the latter, but

within hours from me writing it, the XPointer scheme registry got

announced on the W3C web page[1].  I never thought that TEI lobbying

could be *that* effective:-)

Now it is essential that we move along quickly to get our schemes

registered.  I think Syd would be the right person to ask to submit

our proposal.  You will need a public access account of the W3C for

this, for which you apply at [1].

Does this seem the right course of action?

Christian

[1] http://www.w3.org/

[2] http://cgi.w3.org/MemberAccess/Public

-- 
 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 Nov 18 2005 - 18:57:45 EST

From Syd_Bauman at Brown.edu  Fri Nov 18 20:17:29 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 18 Nov 2005 20:17:29 -0500
Subject: [tei-council] W3C Xpointer schema registry
In-Reply-To: 
Message-ID: <17278.32041.403478.1413@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Fri, 18 Nov 2005 20:17:29 -0500

> As instructed during the last call, I wrote a message to Henry

> Thompson of the W3C, to express the TEI's interest in getting the

> registry up and running. It took me a while to write the latter,

> but within hours from me writing it, the XPointer scheme registry

> got announced on the W3C web page[1]. I never thought that TEI

> lobbying could be *that* effective:-)

Wow! Way to go, Christian! 

I'll forward this on to the SOM WG.

> Now it is essential that we move along quickly to get our schemes

> registered. I think Syd would be the right person to ask to submit

> our proposal. You will need a public access account of the W3C for

> this, for which you apply at [1].

OK. I'll plan to work on this very soon; hopefully will start

tonight, finish tomorrow.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Nov 18 2005 - 20:17:38 EST

From lou.burnard at computing-services.oxford.ac.uk  Sat Nov 19 14:41:33 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 19 Nov 2005 19:41:33 +0000
Subject: [tei-council] W3C Xpointer schema registry
In-Reply-To: <17278.32041.403478.1413@emt.wwp.brown.edu>
Message-ID: <437F7FED.8040501@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Sat, 19 Nov 2005 19:41:33 +0000

Syd Bauman wrote:

> 

>>Now it is essential that we move along quickly to get our schemes

>>registered. I think Syd would be the right person to ask to submit

>>our proposal. You will need a public access account of the W3C for

>>this, for which you apply at [1].

> 

> 

> OK. I'll plan to work on this very soon; hopefully will start

> tonight, finish tomorrow.

> 

Hold on there a minute. I hate to sound like a wet blanket, but I really 

don't think this is more urgent than completing the class work. That may 

be because I don't know exactly what it is that you are expecting Syd to 

do , of course, but my belief remains that the highest priority at the 

moment is for the editors to complete the work initiated in Oxford, and 

not to be distracted by other considerations.

I am also a bit worried that we should be sending off proposals to the 

W3C, of any kind, which have not actually been seen by the COuncil as 

yet. Or were these "schemes" seen so long ago that I have forgotten them 

already?

> _______________________________________________

> 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 Nov 19 2005 - 14:29:13 EST

From Syd_Bauman at Brown.edu  Sat Nov 19 18:29:09 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 19 Nov 2005 18:29:09 -0500
Subject: [tei-council] classy measurements
Message-ID: <17279.46405.734463.561853@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sat, 19 Nov 2005 18:29:09 -0500

At the class meeting in Oxford we decided to create a new attribute

class "att.measurement" to have the attributes unit=, quantity=, and

commodity= for . This all seems like a very good idea on the

surface, but digging a bit deeper it reveals places where our goals

compete with one another, and problems with our declaration system.

unit symbols

---- -------

First, there is the question as to what to recommend people use as

the symbol for a variety of common units. In general, our goal is to

depend on outside standards wherever reasonable. Symbols for units

seems like a great place for TEI to say only what's necessary, and

point to other standards for the rest. The problem is, there are lots

of standards out there, and they often disagree, usually subtly. At a

minimum, there's

* SI (also ISO 1000?), *the* international system of units, aka

  "metric system", by BIPM

* ISO 31, in particular ISO 31-0

* ISO 2955, about which I know very little except that some people

  think it's obsolete

* ANSI X3.50, the American extension of 2955, which also does not

  seem to be readily available 

* ASTM 1238 and its super-set HL7

* ENV 12435 (which I *think* is the European equivalent of the

  American HL7)

* UCUM, The Unified Code for Units of Measures

* Unicode / ISO 10646

Several of these were invented without consideration of machine

interchange of data; several were invented specifically to address

machine interchange of data *using limited character sets*. But none

of them seem to address how to perform machine interchange of data

*using Unicode* (even Unicode itself; I can pretty easily find the

code-points and names of various characters, but not much about their

semantics and intended use).

This is a bit of a problem, because we (alright, I) would like some

guidance on which, if any, of the Unicode characters for unit symbols

should be used. E.g., Unicode seems to suggest that the double-prime

character (U+2033) be used for inches or seconds, and there are

characters for degrees Celsius, ounces, and angstroms. Also there are

a lot of characters that look like they are designed for specific

unit use, but I haven't been able to find out for sure. The names are

a bit odd, and they're in the CJK compatibility block. E.g., U+3392

looks like it would be used for megahertz. (See, e.g.,

http://www.fileformat.info/info/unicode/char/3392/index.htm)

I also think it very important to provide guidance on how to make

explicit the difference between standard and binary values, if the

encoder so desires. (I.e., "MB" vs. "MiB". See, e.g.,

http://www.iec.ch/zone/si/si_bytes.htm if interested.)

The Unified Code for Units of Measures is specifically designed to

'unify' the other standards that address machine interchange.

Furthermore, it does include the binary prefixes. Thus, it initially

looks like a really good candidate. However, it is expressly intended

for use with limited character sets. In particular, it only takes

characters from 7-bit ASCII. While I understand that no one may be

crying over the loss of U+3392 for megahertz, the inability to use mu

for micro or omega for ohm seems silly.

Furthermore, this specification is very detailed. E.g., in some cases

it forces differentiation of which standard a unit comes from. So,

e.g., there are three different symbols for "inch":

 [in_i] = inch, international = 2.54 cm

 [in_us] = the inch as used in USA from 1893 to 1959 = m/39.37

 [in_br] = the British imperial inch = 2.539998 cm

Not only are these symbols ugly and cumbersome, I think the *vast*

majority of TEI users do not care which inch they're using. So to be

forced to pick one would be an annoying burden.

Unless someone knows more about this or has a better idea, I'm going

to suggest that for now the documentation for this class should list

some of the most common symbols in the "suggested values include"

list, and suggest users refer to a standard, and list a bunch of

possible standards (perhaps in the bibliography).

Later, after we've finished straightening out the classes, I think 2

or 3 of us should come up with a concrete proposal for how to encode

units in a Unicode environment. How to put such a proposal into a

tagdoc file is another problem entirely (which I foreshadowed with

"problems with our declaration system", above :-), because the values

of ident= of  need to be xsd:Names. This suggestion defers

having to deal with this, too.

Regularization vs. Normalization

-------------- --- -------------

Second is the question of whether these attributes are used for

regularization or normalization. My suggestion is that the Guidelines

explicitly state that these attributes can be used either for

regularization:

  The following has been recommended in neuralgia of the uterus: Mix

  together 
  quantity="1.5">one plus a half grain of alcoholic extract of

  belladonna and ...

or normalization:

  The following has been recommended in neuralgia of the uterus: Mix

  together 
  quantity="97.2">one plus a half grain of alcoholic extract of

  belladonna and ...

and that we have no recommendation for doing both simultaneously.

type=, anyone?

------ -------

If the class subcommittee decided whether the new attributes would

replace type= of  or be added in addition to it, this

decision was not recorded in the minutes. Unless someone can think of

a good reason to drop type= of , I'm going to suggest we

keep it on the somewhat feeble grounds that it can't hurt much, and

it may be quite helpful if we've overlooked something.

I plan to have these three suggestions wrapped into the tagdoc

available on Sourceforge within a few hours.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sat Nov 19 2005 - 18:29:19 EST

From Syd_Bauman at Brown.edu  Sat Nov 19 18:43:08 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 19 Nov 2005 18:43:08 -0500
Subject: [tei-council] W3C Xpointer schema registry
In-Reply-To: <437F7FED.8040501@computing-services.oxford.ac.uk>
Message-ID: <17279.47244.877033.841725@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sat, 19 Nov 2005 18:43:08 -0500

[Cross-posted to Council and SO]

> Hold on there a minute. I hate to sound like a wet blanket, but I

> really don't think this is more urgent than completing the class

> work.

I disagree -- this is potentially *very* time sensitive. Maybe not,

but we have no way of knowing who else is queued up waiting to

register scheme names, and I don't think we should take the chance.

Turns out the W3C isn't open for business now, so I have to wait

until Monday.

> I am also a bit worried that we should be sending off proposals to

> the W3C, of any kind, which have not actually been seen by the

> COuncil as yet. Or were these "schemes" seen so long ago that I

> have forgotten them already?

Perhaps. They were first seen by the group as a whole in Ghent, I

think. But don't fret too much, even if you haven't committed them to

memory and written java implementations of them. If I understand

correctly, what we are registering with W3C is the name, not the

semantics. That is, we want to be first to the punch so that a

reference to the match() XPointer scheme means the TEI match()

XPointer scheme, not Joe's match() XPointer scheme. If we get there

first, Joe will be the one who needs to use a different name or use

the cumbersome namespace mechanism the XPointer Framework provides.

As a reminder to everyone, the names we're planning to register are

  xpath()

  left()

  right()

  range()

  string-range()

  match()

We had xpath2() in an earlier version of the list, but decided to

drop it because XPath 2.0 was only a draft at the time. Has it become

a real official W3C recommendation? If so, we should go ahead and add

xpath2() back to the list, no?

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sat Nov 19 2005 - 18:43:17 EST

From James.Cummings at computing-services.oxford.ac.uk  Sat Nov 19 19:56:25 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 20 Nov 2005 00:56:25 +0000
Subject: [tei-council] W3C Xpointer schema registry
In-Reply-To: <17279.47244.877033.841725@emt.wwp.brown.edu>
Message-ID: <437FC9B9.40803@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Sun, 20 Nov 2005 00:56:25 +0000

Syd Bauman wrote:

> We had xpath2() in an earlier version of the list, but decided to

> drop it because XPath 2.0 was only a draft at the time. Has it become

> a real official W3C recommendation? If so, we should go ahead and add

> xpath2() back to the list, no?

"This specification will remain a Candidate Recommendation until at 

least 28 February 2006."

I think it is fairly stable, though others may know better.  I'd say 

include it in the list.

I'm sure this has all been thought through before, but is there a need 

for both an xpath() and xpath2()?  (Just strikes me as problematic, 

what happens when xpath3 (if ever) comes along.)  Do they need to be 

separate because of the issues of backwards compatibility?

http://www.w3.org/TR/2005/CR-xpath20-20051103/#id-backwards-compatibility

-James

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sat Nov 19 2005 - 19:56:19 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Nov 20 18:05:58 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 21 Nov 2005 08:05:58 +0900
Subject: [tei-council] W3C Xpointer schema registry
In-Reply-To: <437F7FED.8040501@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Mon, 21 Nov 2005 08:05:58 +0900

Lou Burnard oxford.ac.uk> writes:

> Syd Bauman wrote:

>

>> 

>>>Now it is essential that we move along quickly to get our schemes

>>>registered. I think Syd would be the right person to ask to submit

>>>our proposal. You will need a public access account of the W3C for

>>>this, for which you apply at [1].

>> OK. I'll plan to work on this very soon; hopefully will start

>> tonight, finish tomorrow.

>> 

>

> Hold on there a minute. I hate to sound like a wet blanket, but I

> really don't think this is more urgent than completing the class

> work. That may be because I don't know exactly what it is that you are

> expecting Syd to do , of course, but my belief remains that the

> highest priority at the moment is for the editors to complete the work

> initiated in Oxford, and not to be distracted by other considerations.

>

Syd first has to apply for an account, which should not take more than

five minutes.

> I am also a bit worried that we should be sending off proposals to the

> W3C, of any kind, which have not actually been seen by the COuncil as

> yet. Or were these "schemes" seen so long ago that I have forgotten

> them already?

Please have a look at 

http://www.tei-c.org/P5/Guidelines/SA.html#SATS

As Syd said, we need to register the names most urgently, since that

is a first-come, first served situation.  But I would also like to ask

Council members to look at the above again and raise any concerns or

issues that needs updating.

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 Nov 20 2005 - 18:06:04 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Nov 20 20:14:17 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 21 Nov 2005 10:14:17 +0900
Subject: [tei-council] classy measurements
In-Reply-To: <17279.46405.734463.561853@emt.wwp.brown.edu>
Message-ID: 

From: Christian Wittern 

Date: Mon, 21 Nov 2005 10:14:17 +0900

Syd Bauman edu> writes:

> unit symbols

> ---- -------

> First, there is the question as to what to recommend people use as

> the symbol for a variety of common units. In general, our goal is to

> depend on outside standards wherever reasonable. Symbols for units

> seems like a great place for TEI to say only what's necessary, and

> point to other standards for the rest. The problem is, there are lots

> of standards out there, and they often disagree, usually subtly. At a

> minimum, there's

>

[...]

> Several of these were invented without consideration of machine

> interchange of data; several were invented specifically to address

> machine interchange of data *using limited character sets*. But none

> of them seem to address how to perform machine interchange of data

> *using Unicode* (even Unicode itself; I can pretty easily find the

> code-points and names of various characters, but not much about their

> semantics and intended use).

>

> This is a bit of a problem, because we (alright, I) would like some

> guidance on which, if any, of the Unicode characters for unit symbols

> should be used. E.g., Unicode seems to suggest that the double-prime

> character (U+2033) be used for inches or seconds, and there are

> characters for degrees Celsius, ounces, and angstroms. Also there are

> a lot of characters that look like they are designed for specific

> unit use, but I haven't been able to find out for sure. The names are

> a bit odd, and they're in the CJK compatibility block. E.g., U+3392

> looks like it would be used for megahertz. (See, e.g.,

> http://www.fileformat.info/info/unicode/char/3392/index.htm)

As a general principle, compatibility characters are in Unicode for

compatibility with pre-existing standards, for the purpose of allowing

text encoded in these other encodings converted back and forth to

Unicode.   The should *never* be used in text that started life in

Unicode.  For that reason, we should not recommend the use of any of

these at all.  

Now with respect to the problem you have here, that is, assigning

single codepoints to units of measurement, this is something the

Unicode consortium deliberately avoided, except for these

compatibility characters.  Therefore you will find for each of these

compatibility characters a mapping to a codepoint sequence that should

be used in lieu of this single codepoint.  In the case you cite,

e.g. U+3392, this is the sequence 004D M 0048 H 007A z, which expands

to "MHz".  

I think this was a sensible decision and am very glad the UTC avoided

the mistake of some other standard bodies to assign codepoints to

standard units, it makes our life much easier in this respect.  It

would therefore enough to us to recommend the SI endorsed abbreviation

of the unit, IMHO.

> Furthermore, this specification is very detailed. E.g., in some cases

> it forces differentiation of which standard a unit comes from. So,

> e.g., there are three different symbols for "inch":

>

>  [in_i] = inch, international = 2.54 cm

>  [in_us] = the inch as used in USA from 1893 to 1959 = m/39.37

>  [in_br] = the British imperial inch = 2.539998 cm

>

> Not only are these symbols ugly and cumbersome, I think the *vast*

> majority of TEI users do not care which inch they're using. So to be

> forced to pick one would be an annoying burden.

>

>

> Unless someone knows more about this or has a better idea, I'm going

> to suggest that for now the documentation for this class should list

> some of the most common symbols in the "suggested values include"

> list, and suggest users refer to a standard, and list a bunch of

> possible standards (perhaps in the bibliography).

If you look at the Unicode codepoint area U+3380 to 33DF you see a

pretty long list -- do you really want to include them all?  I think

it would be better to just state the general principle in the tagdoc

and point to a list where these codes are enumerated.

>

> Later, after we've finished straightening out the classes, I think 2

> or 3 of us should come up with a concrete proposal for how to encode

> units in a Unicode environment. How to put such a proposal into a

> tagdoc file is another problem entirely (which I foreshadowed with

> "problems with our declaration system", above :-), because the values

> of ident= of  need to be xsd:Names. This suggestion defers

> having to deal with this, too.

See above.  none of our business, luckily.

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 Nov 20 2005 - 20:14:24 EST

From Syd_Bauman at Brown.edu  Mon Nov 21 10:28:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 21 Nov 2005 10:28:11 -0500
Subject: [tei-council] classy measurements
In-Reply-To: 
Message-ID: <17281.59275.939497.508402@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Mon, 21 Nov 2005 10:28:11 -0500

> As a general principle, compatibility characters are in Unicode for

> compatibility ... we should not recommend the use of any of these

> at all.

Good. That knocks one set of problems off the list, and I was mighty

suspicious of those characters, anyway.

> Now with respect to the problem you have here, that is, assigning

> single codepoints to units of measurement,

Just want to make clear ... I am not *trying* to assign single

code-point symbols to units of measurement: I am trying to assign the

*right* symbols to units of measurement. I'm actually kinda pleased

those compatibility characters aren't the right ones to use. In

general I prefer the SI symbols when they're available.

> If you look at the Unicode codepoint area U+3380 to 33DF you see a

> pretty long list -- do you really want to include them all?

Uhhh... no, not at all. I only want to include a few units for now

(which is why I said "list some of the most common symbols"), but

more importantly these are all compatibility characters, and thus off

the table, are they not?

>  I think it would be better to just state the general principle in

> the tagdoc and point to a list where these codes are enumerated.

As I said, this is the general goal, but I haven't found a single,

one-stop-shopping document we can point to.

> > Later, after we've finished straightening out the classes, I

> > think 2 or 3 of us should come up with a concrete proposal for

> > how to encode units in a Unicode environment. How to put such a

> > proposal into a tagdoc file is another problem entirely (which I

> > foreshadowed with "problems with our declaration system", above

> > :-), because the values of ident= of  need to be

> > xsd:Names. This suggestion defers having to deal with this, too.

> 

> See above. none of our business, luckily.

I'm sorry, I don't understand what part you don't think we should be

worrying about. If we don't give TEI users advice on how to encode

units, who will?

Remember, it's not obvious; furthermore it's often arbitrary. In such

cases, the world is generally better off if we all agree on one

particularly arbitrary representation, so they're all the same. E.g.,

it would be a lot nicer if *everyone* used "in" instead of some TEI

folks using "in", some using "inch", and some using "inches".

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Mon Nov 21 2005 - 10:28:22 EST

From nil at scorpio.services.brown.edu  Mon Nov 21 16:15:42 2005
From: nil at scorpio.services.brown.edu (nil_at_scorpio.services.brown.edu)
Date: Mon, 21 Nov 2005 16:15:42 -0500
Subject: [tei-council] TEI XPointer scheme names submitted to W3C for registration
Message-ID: <17282.14590.694464.747657@emt.wwp.brown.edu>

From: 

Date: Mon, 21 Nov 2005 16:15:42 -0500

The TEI scheme names have been submitted to the W3C for consideration

for the registry. See

http://www.w3.org/2005/04/xpointer-schemes/

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Mon Nov 21 2005 - 16:15:51 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Nov 21 17:59:10 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 22 Nov 2005 07:59:10 +0900
Subject: [tei-council] classy measurements
In-Reply-To: <17281.59275.939497.508402@emt.wwp.brown.edu>
Message-ID: 

From: Christian Wittern 

Date: Tue, 22 Nov 2005 07:59:10 +0900

Syd Bauman edu> writes:

>> If you look at the Unicode codepoint area U+3380 to 33DF you see a

>> pretty long list -- do you really want to include them all?

>

> Uhhh... no, not at all. I only want to include a few units for now

> (which is why I said "list some of the most common symbols"), but

> more importantly these are all compatibility characters, and thus off

> the table, are they not?

Well, I mentioned this not to use the codepoints, but as an instance

of an enumeration of units for measurements.  And you have all the

*standard denominations* in the mapping to expansions. 

>> > Later, after we've finished straightening out the classes, I

>> > think 2 or 3 of us should come up with a concrete proposal for

>> > how to encode units in a Unicode environment. How to put such a

>> > proposal into a tagdoc file is another problem entirely (which I

>> > foreshadowed with "problems with our declaration system", above

>> > :-), because the values of ident= of  need to be

>> > xsd:Names. This suggestion defers having to deal with this, too.

>> 

>> See above. none of our business, luckily.

>

> I'm sorry, I don't understand what part you don't think we should be

> worrying about. If we don't give TEI users advice on how to encode

> units, who will?

My comment related only to the part *in a Unicode environment*, which

does not really make a difference here.  Advice and examples is

needed, of course.

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 Nov 21 2005 - 17:59:48 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Dec  9 08:13:00 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 09 Dec 2005 22:13:00 +0900
Subject: [tei-council] Council telecon 2005-12-16 at 1200 UTC: preparations, agenda items
Message-ID: 

From: Christian Wittern 

Date: Fri, 09 Dec 2005 22:13:00 +0900

Dear Council members,

As you know, we will hold our next teleconference call the next

Friday, December 16th, the time has changed from our usual 1300 UTC to

1200 UTC to make it slightly less inconvenient for our new member

Conal Tuohy from New Zealand to participate.  Apologies to those for

whom the new time is less convenient.

John, could I ask you to make the necessary technical arrangements for

the call and post an announcement here how to connect.

Also, as usual, please send me any agenda items you might have.

Please report on progress of action items (see

http://www.tei-c.org/Council/tcm19.xml?style=printable for the minutes

from our last call and

http://www.tei-c.org/Council/tcm20.xml?style=printable for the "Class

actions"), preferably to the list *before* the call, but we will also

make the usual review of actions at the beginning.  It would be nice,

if Lou and/or Syd could give us a brief "State of P5" address, again

preferably in writing to the list.

The season being what it is, I expect everybody to be occupied with

other things, so I hope we can be brief on the call (for the

newcomers: we usually plan for 60 minutes, but end up taking around

90, the record being around 120).

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 Dec 09 2005 - 08:13:08 EST

From Syd_Bauman at Brown.edu  Fri Dec  9 14:13:21 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 9 Dec 2005 14:13:21 -0500
Subject: [tei-council] 6 of 7 TEI XPointer scheme names registered
Message-ID: <17305.55121.868097.610301@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Fri, 9 Dec 2005 14:13:21 -0500

I am pleased to report that 6 of the 7 XPointer Scheme scheme names

the TEI submitted for registration have been registered without

comment. The 7th, "xpath()", is currently under discussion on the

relevant W3c list, the question being should it be "xpath()" or

"xpath1()". I have sent mail to the list basically saying that I

don't think the TEI cares which it is, but it hasn't been posted yet.

(I think this falls squarely into the class of things for which the

actual answer doesn't matter, so long as we all agree on it.)

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 09 2005 - 14:13:35 EST

From jawalsh at indiana.edu  Tue Dec 13 07:10:51 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Tue, 13 Dec 2005 07:10:51 -0500
Subject: [tei-council] Conference Call Instructions
Message-ID: 

From: John A. Walsh 

Date: Tue, 13 Dec 2005 07:10:51 -0500

Hi all,

Please see below for conference call instructions.

John

---
You have been invited to participate in a Conference Call on  
12/16/2005 from 12:00:00 to 14:00:00 UCT.
The Conference Access Information is listed below:
Conf Id:		2947
Date:		12/16/2005
Begin Time:	12:00:00 UCT
End Time:	14:00:00 UCT
Voice Status:	Active
Announcement
	Entry:	Tone Only
	Exit:	Tone Only
Access Type:	PIN
Attendee Type:	Guest
Phone Number:	(812) 856-3600
PIN:		000920#
This email was automatically generated by the  IU UITS Conference  
system. Please do not reply to this message.
For conferencing assistance please call 812-855-4848.
--
| John A. Walsh
| Associate Director for Projects and Services, Digital Library Program
| Associate Librarian, University Libraries
| Adjunct Associate Professor, Department of English
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 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 Dec 13 2005 - 07:10:59 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Dec 13 20:20:04 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 14 Dec 2005 10:20:04 +0900
Subject: [tei-council] draft agenda for TEI council telecon 2005-12-16 1200 UTC
Message-ID: 

From: Christian Wittern 

Date: Wed, 14 Dec 2005 10:20:04 +0900

TEI Council Members and Editors:

This is the draft agenda for the conference call the TEI Council will

hold Friday, December 16th, 2005 at 1200 UTC.

Please read through the following, in advance of the call.  

INSTRUCTIONS for conference call:

Participants will dial in to +1-812-856-3600

The Conference Access Information is listed below:

Conf Id:        2974

Date:        12/16/2005

PIN:        000920#

Expected members to participate:

Syd Bauman, Alejandro Bia, David Birnbaum, Lou Burnard, James

Cummings, Matthew Driscoll, Dot Porter, Susan Schreibman, Sebastian

Rahtz, Laurent Romary, Natasha Smith, Conal Tuohy, John Walsh, Perry

Willett, Christian Wittern, Matthew Zimmerman

(please alert me if I did forget anyone!)

Edward Vanhoutte excused himself and is busy working on his thesis while we talk.

In addition to the voice connection, we also expect to communicate via

IRC. Instructions to connect are as follows (quoted from James

Cumming's message):

Ok, on the day of the council call I'll set up a password (or 'key')

protected channel called #tei-council the joining instructions are the

same and I'd still suggest joining the #tei-c one.  Once there type:

/join #tei-council 2expensive

and in most IRC clients that will get you there.

(instructions also at: http://www.tei-c.org.uk/wiki/index.php/IRC)

Agenda:

7 items, ca 5-20 minutes apiece.

-----------------------------------------------------

1) Review of the minutes and action items (10 min)

   Minutes of the meeting are at

         http://www.tei-c.org/Council/tcm19.html and

         http://www.tei-c.org/Council/tcm20.html

         To speed up the review of action items, *please report to the

         council list* before the call as far as possible! 

         We will discuss the reports during the call as necessary.

------------------------------------------------------------

2) Review of WG etc. progress (10 min) : 

-----------------------------------------------------

3) Proposal for new prosopography WG

  As discussed on the Council list, a new prosopography WG has been

  proposed.  I would like to take the necessary steps for starting the

  WG, that is finding a chair, writing up the charge, find members and

  start work.

4) P5 progress:  (20 min)

- on attributes and datatypes

- on classes

- other changes

-----------------------------------------------------

5) Other business  (5 minutes)

 TBA

-----------------------------------------------------

6) Meetings: (5 minutes)

   Next teleconference: Mid February, please have your diarys ready. 

   Council meeting 2006?

-- 
 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 Dec 13 2005 - 20:20:38 EST

From Conal.Tuohy at vuw.ac.nz  Wed Dec 14 00:03:42 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Wed, 14 Dec 2005 18:03:42 +1300
Subject: [tei-council] encoding page scans
Message-ID: 

From: Conal Tuohy 

Date: Wed, 14 Dec 2005 18:03:42 +1300

Afternoon all! My first post on the TEI Council list is about encoding

images of page scans in TEI. 

A couple of months ago Jamie Norrish started a short thread on TEI-L

about this issue, but I don't feel that the issue has been adequately

addressed. Of course, it may be that I've missed something in P5 and

that this is now all sorted. I hope so :-)

If I haven't missed anthing, then at the moment there isn't a really

good way to encode these scans (they are not figures, but graphics

having a different relationship to the text). Many people are encoding

these in TEI, but there's no consensus on how to do it. Recently I've

come across another TEI customisation in which the URIs of scanned pages

are encoded as pb/@url. I've seen others in which it is encoded as

pb/@entity (a reference to an unparsed entity, like P4's

figure/@entity). There are other practices in use too. 

At the NZETC we are encoding page scans (in P4) using a list of figure

elements inside a note in the TEI.2/teiHeader/fileDesc/noteStmt, each of

which is linked to the corresponding pb element with a @corresp. It

seems awkward (to put it mildly) to encode the figures in a notesStmt,

but it seemed preferable to encoding them as part of the text (as had

been our practice). 

Of course METS provides one solution. But it seems like overkill to add

a METS wrapper around a TEI file just to support a single feature which

(to me) seems already like a natural piece of TEI, and which has several

times been hacked into TEI anyway. In the earlier thread, Christian

argued that the images were alternate representations of the whole text,

and hence didn't belong in the file at all. I can see his point (I

think), but I don't find it convincing. 

Can we establish a standard mechanism in TEI for this purpose? Off the

top of my head I would prefer to nest a graphic element inside a pb, but

to me the important thing is just that some simple mechanism is provided

within the standard TEI schema without customisation.

Cheers

Con

PS incidentally, I note that graphic/@scale has type data.probability.

Shouldn't this be a real number? 

--
Conal Tuohy
Senior Programmer
+64-4-463-6844
+64-21-237-2498
conal_at_nzetc.org
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 Dec 14 2005 - 00:04:01 EST

From sebastian.rahtz at oucs.ox.ac.uk  Wed Dec 14 04:09:52 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 14 Dec 2005 09:09:52 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: 
Message-ID: <439FE160.10701@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Wed, 14 Dec 2005 09:09:52 +0000

I agree, its a running sore.

Don't forget, by the way, that for some people  points forward, for 

others it points back.

If we all used , that would need clearing up too.

Your "list of figure elements inside a note in the TEI.2/teiHeader/fileDesc/noteStmt" seems to me closer

to the right way. I'm with Christian, in the idea of a complete parallel document.

The question is not "what is the answer", but "what mechanism shall we use

to establish the answer".....

Sebastian

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Dec 14 2005 - 04:10:05 EST

From lou.burnard at computing-services.oxford.ac.uk  Wed Dec 14 09:58:53 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 14 Dec 2005 14:58:53 +0000
Subject: [tei-council] measured and measurement
Message-ID: <43A0332D.2030404@oucs.ox.ac.uk>

From: Lou Burnard 

Date: Wed, 14 Dec 2005 14:58:53 +0000

The MS module defines an attribute class "measured" which adds 

attributes "unit" and "scope" to a number of elements.

The ST module defines an attribute class "measurement" which adds 

attributes "unit" "quantity" and "commodity"

There is evidentluy some overlap here, but I'm not sure how best to 

resolve it.

Constructive suggestions would be welcomed.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Dec 14 2005 - 09:56:35 EST

From dporter at uky.edu  Wed Dec 14 11:27:02 2005
From: dporter at uky.edu (Dot Porter)
Date: Wed, 14 Dec 2005 11:27:02 -0500
Subject: [tei-council] encoding page scans
In-Reply-To: 
Message-ID: <96f3df640512140827o3876ddc8s30c6e45bd8a793e5@mail.gmail.com>

From: Dot Porter 

Date: Wed, 14 Dec 2005 11:27:02 -0500

I agree that it is be preferable to provide image file references via

indexing - either through a  METS file or a list of files in the TEI

Header -  rather than including them in the text encoding itself using

something like pb/@url. My main reason is that a single page in TEI

may point to multiple scanned images - the same manuscript page under

different lighting conditions, for example. Building those links into

the pb element would make it cumbersome to link one encoded page to

several different files, while a index could group images of the same

page together providing a single reference for the pb.

Going a step further, what if we want to create relationships between

areas of that page scan and the corresponding range in the TEI text?

Is this something that the TEI should cover, or is it better to rely

on other standards (METS, SVG)? The Edition Production Technology[1]

depends on @coords, which can be added to any tag and which indicates

where the tag contents reside on the image. Unfortunately this only

allows for one set of coordinates, even if there are multiple image

files for the same page. For another project, I've been working on a

system for encoding multiple sets of coordinates in a METS Structural

Map (stored in a separate file, rather than as a wrapper for the TEI),

and it seems to work pretty well. The UVic Image Markup Tool[2] uses

SVG within the TEI body to link to both file and coordinates; another

approach might be to have a TEI module for incorporating image files

and their areas in a project.

Dot

[1] http://beowulf.engl.uky.edu/~eft/EPPT-Demo.html

[2] http://www.tapor.uvic.ca/~mholmes/image_markup/

On 12/14/05, Conal Tuohy ac.nz> wrote:

> Afternoon all! My first post on the TEI Council list is about encoding

> images of page scans in TEI.

>

> A couple of months ago Jamie Norrish started a short thread on TEI-L

> about this issue, but I don't feel that the issue has been adequately

> addressed. Of course, it may be that I've missed something in P5 and

> that this is now all sorted. I hope so :-)

>

> If I haven't missed anthing, then at the moment there isn't a really

> good way to encode these scans (they are not figures, but graphics

> having a different relationship to the text). Many people are encoding

> these in TEI, but there's no consensus on how to do it. Recently I've

> come across another TEI customisation in which the URIs of scanned pages

> are encoded as pb/@url. I've seen others in which it is encoded as

> pb/@entity (a reference to an unparsed entity, like P4's

> figure/@entity). There are other practices in use too.

>

> At the NZETC we are encoding page scans (in P4) using a list of figure

> elements inside a note in the TEI.2/teiHeader/fileDesc/noteStmt, each of

> which is linked to the corresponding pb element with a @corresp. It

> seems awkward (to put it mildly) to encode the figures in a notesStmt,

> but it seemed preferable to encoding them as part of the text (as had

> been our practice).

>

> Of course METS provides one solution. But it seems like overkill to add

> a METS wrapper around a TEI file just to support a single feature which

> (to me) seems already like a natural piece of TEI, and which has several

> times been hacked into TEI anyway. In the earlier thread, Christian

> argued that the images were alternate representations of the whole text,

> and hence didn't belong in the file at all. I can see his point (I

> think), but I don't find it convincing.

>

> Can we establish a standard mechanism in TEI for this purpose? Off the

> top of my head I would prefer to nest a graphic element inside a pb, but

> to me the important thing is just that some simple mechanism is provided

> within the standard TEI schema without customisation.

>

> Cheers

>

> Con

>

> PS incidentally, I note that graphic/@scale has type data.probability.

> Shouldn't this be a real number?

>

> --

> Conal Tuohy

> Senior Programmer

> +64-4-463-6844

> +64-21-237-2498

> conal_at_nzetc.org

> 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

>

--
***************************************
Dot Porter, Program Coordinator
Collaboratory for Research in Computing for Humanities
University of Kentucky
351 William T. Young Library
Lexington, KY  40506
dporter_at_uky.edu          859-257-9549
***************************************
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Dec 14 2005 - 11:27:08 EST

From Conal.Tuohy at vuw.ac.nz  Wed Dec 14 18:01:37 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Thu, 15 Dec 2005 12:01:37 +1300
Subject: [tei-council] encoding page scans
In-Reply-To: <[tei-council] encoding page scans>
Message-ID: 

From: Conal Tuohy 

Date: Thu, 15 Dec 2005 12:01:37 +1300

Dot Porter wrote:

> I agree that it is be preferable to provide image file references via

> indexing - either through a  METS file or a list of files in the TEI

> Header -  rather than including them in the text encoding itself using

> something like pb/@url. My main reason is that a single page in TEI

> may point to multiple scanned images - the same manuscript page under

> different lighting conditions, for example. Building those links into

> the pb element would make it cumbersome to link one encoded page to

> several different files, while a index could group images of the same

> page together providing a single reference for the pb.

That's true. And there's different purposes (thumbnail, reference), and

formats too (e.g. JPEG, TIFF, etc)

> Going a step further, what if we want to create relationships between

> areas of that page scan and the corresponding range in the TEI text?

> Is this something that the TEI should cover, or is it better to rely

> on other standards (METS, SVG)? The Edition Production Technology[1]

I have a preference for something internal to TEI for the sake of making

it very easy to encode in the simple case. But I'm not too fussed so

long as some recommended practice is documented as part of the TEI

guidelines.

> depends on @coords, which can be added to any tag and which indicates

> where the tag contents reside on the image. Unfortunately this only

> allows for one set of coordinates, even if there are multiple image

> files for the same page. For another project, I've been working on a

The same problem as above then - the links should go from the image to

the text, rather than the other way? Or we could use link/@targets to

encode n-ary links, i.e. a single link element indicating a

correspondence between some text markup and 1 or more graphics (or

regions within graphics)? The weakness of link/@targets for multiple

links is that it doesn't attach any semantics to the different links.

> system for encoding multiple sets of coordinates in a METS Structural

> Map (stored in a separate file, rather than as a wrapper for the TEI),

> and it seems to work pretty well. 

I'm sure it does :-) and I've read the METS profiles for doing it[1]

though I've never done it myself ... but do you think it should really

be necessary to go to these lengths? It seems to me that we could use

METS to handle TEI figure elements too. Page scans are a different level

of description of the text from figures, but TEI is full of different

analytical levels of all kinds, so I don't find that argument convincing

in itself. But I suppose I could be convinced :-) The main thing, to my

mind, is that the guidelines should clearly document some standard

practice that doesn't involve treating page scans as figures, or making

custom extensions to the TEI schema.

Dot, could you post a little example of the METS and TEI markup you are

using to associate an image file with a TEI page?

> The UVic Image Markup Tool[2] uses

> SVG within the TEI body to link to both file and coordinates; 

That's an interesting example. I agree that inline SVG could be a good

way to mark up regions within a graphic. Just a quibble, though: in your

example, is the link between the graphical region and the text

represented by a purely conventional correspondence between the @n and

the @xml:id attributes? In the guidelines it suggest using a ptr to

provide a TEI-namespaced proxy for the SVG region, then linking the ptr

and the text markup with a TEI  element. 

> another

> approach might be to have a TEI module for incorporating image files

> and their areas in a project.

This last is the approach I think I would prefer. One of my criteria for

such a feature would be that in the simplest case it should be dead easy

to associate a page image with a page. Whereas the METS approach is

perfectly capable, but it's probably not so convenient for encoders, I

would guess. Having a separate file is an extra hassle, for a start,

though perhaps a "METS" TEI module could be produced which would add

METS as a root element, and introduce the TEI element embedded in the

METS structure map? Could the same be done with SVG? That could be a way

to at least provide recommended encoding mechanisms defined using the

standard TEI customisation practice.

Cheers

Con

[1] http://www.loc.gov/standards/mets/profiles/00000005.xml

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Dec 14 2005 - 18:01:47 EST

From Conal.Tuohy at vuw.ac.nz  Wed Dec 14 18:03:15 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Thu, 15 Dec 2005 12:03:15 +1300
Subject: [tei-council] encoding page scans
In-Reply-To: <[tei-council] encoding page scans>
Message-ID: 

From: Conal Tuohy 

Date: Thu, 15 Dec 2005 12:03:15 +1300

Sebastian Rahtz wrote:

> Your "list of figure elements inside a note in the 

> TEI.2/teiHeader/fileDesc/noteStmt" seems to me closer

> to the right way. 

Perhaps something could be added to the Source Description, rather than

the Notes Statement? That might be a better place to encode references

to page scans, and then standard linking mechanisms (link, @corresp,

whatever) could be used to align them to pages.

"The  element is the seventh and final component of the

 element. It is a mandatory element, and is used to record

details of the source or sources from which a computer file is derived.

"

e.g.

        ...

                ...

> I'm with Christian, in the idea of a 

> complete parallel document.

Though there's a considerable extra burden to encoders that way, I

think.

> The question is not "what is the answer", but "what mechanism 

> shall we use

> to establish the answer".....

I'm not sure if I understand that ... could you clarify? I'm sorry if

I'm not going about this in the correct way ... I am new here :-)

Con

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Dec 14 2005 - 18:03:19 EST

From sebastian.rahtz at oucs.ox.ac.uk  Wed Dec 14 18:15:31 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 14 Dec 2005 23:15:31 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: 
Message-ID: <43A0A793.5000408@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Wed, 14 Dec 2005 23:15:31 +0000

Conal Tuohy wrote:

>

>

>	...

>	

>		

>			

>		

>		

>			

>		

>		...

>	

>

>  

>

not sure about , but something like that, yes

>I'm not sure if I understand that ... could you clarify? I'm sorry if

>I'm not going about this in the correct way ... I am new here :-)

>

>

>  

>

What I am saying is that we should not attempt to solve this

solely within the TEI Council, but should consult more widely.

How do we do that? by a work group? a SIG?

-- 
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 Dec 14 2005 - 18:15:50 EST

From sebastian.rahtz at oucs.ox.ac.uk  Wed Dec 14 18:24:33 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 14 Dec 2005 23:24:33 +0000
Subject: [tei-council] measured and measurement
In-Reply-To: <43A0332D.2030404@oucs.ox.ac.uk>
Message-ID: <43A0A9B1.6050703@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Wed, 14 Dec 2005 23:24:33 +0000

Lou Burnard wrote:

> The MS module defines an attribute class "measured" which adds 

> attributes "unit" and "scope" to a number of elements.

>

> The ST module defines an attribute class "measurement" which adds 

> attributes "unit" "quantity" and "commodity"

>

> There is evidentluy some overlap here, but I'm not sure how best to 

> resolve it.

>

quantity, commodity and scope seem to be distinct, and unit is the same. 

so why don't

you just merge them?

-- 
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 Dec 14 2005 - 18:24:52 EST

From lou.burnard at computing-services.oxford.ac.uk  Wed Dec 14 19:57:33 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop)
Date: Thu, 15 Dec 2005 00:57:33 +0000
Subject: [tei-council] (very) Brief status report on P5
Message-ID: <43A0BF7D.6040102@computing-services.oxford.ac.uk>

From: Lou's Laptop 

Date: Thu, 15 Dec 2005 00:57:33 +0000

[Syd may want to add to this]

1. During October there was extensive work on attributes and datatypes, 

which was completed in time for a release of P5 (0.2.1) to take place on 

the 21st.

2. During November, the priority was to work on classes. A detailed 

programme of work was agreed following the Council meeting in Oxford, 

and is now complete. Full details of the changes made are available from 

http://www.tei-c.org/Drafts/edw92.xml

3. Some outstanding issues remain on the class front, in particular  

there is still need for a  review of many chapters not discussed at the  

Oxford meeting.  Enough work has been done, however, to proceed to the 

revision of chapter ST, which is the next priority.

4. In December, Matthew Driscoll visited Oxford, resulting in a number 

of minor corrections to the MS chapter.

5. A new "listPerson" element has been introduced to facilitate encoding 

of "personographical" data: this was tested on some data supplied by 

Matthew which now forms a new component of the test suite.

6. New material for inclusion in chapters SA and NH has been received 

but not yet reviewed by both editors.

in haste

Lou

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Wed Dec 14 2005 - 19:57:42 EST

From dporter at uky.edu  Thu Dec 15 17:38:52 2005
From: dporter at uky.edu (Dot Porter)
Date: Thu, 15 Dec 2005 17:38:52 -0500
Subject: [tei-council] encoding page scans
In-Reply-To: 
Message-ID: <96f3df640512151438n226bde3btd50baad9f7d5513e@mail.gmail.com>

From: Dot Porter 

Date: Thu, 15 Dec 2005 17:38:52 -0500

Hi Conal,

Some comments on your comments...

On 12/14/05, Conal Tuohy ac.nz> wrote:

> Dot Porter wrote:

>

> > depends on @coords, which can be added to any tag and which indicates

> > where the tag contents reside on the image. Unfortunately this only

> > allows for one set of coordinates, even if there are multiple image

> > files for the same page. For another project, I've been working on a

>

> The same problem as above then - the links should go from the image to

> the text, rather than the other way? Or we could use link/@targets to

> encode n-ary links, i.e. a single link element indicating a

> correspondence between some text markup and 1 or more graphics (or

> regions within graphics)? The weakness of link/@targets for multiple

> links is that it doesn't attach any semantics to the different links.

>

Oh, I don't really like this idea for the very same reason you give -

I'd rather have a linking system where the relationships between the

text and image are defined, rather than just noted. (I've actually

stopped using linkGrp/link completely... I use METS instead...)

> > system for encoding multiple sets of coordinates in a METS Structural

> > Map (stored in a separate file, rather than as a wrapper for the TEI),

> > and it seems to work pretty well.

>

> I'm sure it does :-) and I've read the METS profiles for doing it[1]

> though I've never done it myself ... but do you think it should really

> be necessary to go to these lengths?

I rather hope it isn't *necessary* but it does seem to work - though

it is incredibly intensive on the encoding side. I've just built a

small sample of material, using oXygen, and taking coordinates from

EPT and PhotoShop. It would be impossible to do more without special

software support.

 The main thing, to my

> mind, is that the guidelines should clearly document some standard

> practice that doesn't involve treating page scans as figures, or making

> custom extensions to the TEI schema.

>

yes, yes, yes

> Dot, could you post a little example of the METS and TEI markup you are

> using to associate an image file with a TEI page?

>

Boy, okay. The project is an edition of the Venetus A manuscript - the

earliest surviving copy of the Iliad, containing the main text plus

several layers of annotation.

Much simplified: First, we encode the main text and the annotations

separately (in separate documents, one document per book). In the main

text, the poetic lines () are assigned IDs based on the book and

line number - for example, Book 4 line 537 has xml:id="book.4.537".

IDs for the annotations are assigned based on the type of annotation

(marginal, interlinear, etc.), book number, the group number

(annotations are in groups of two or more), and then the number of the

specific annotation in a group. So an ID for a group of marginal

annotations would be xml:id="m.4.15", while the first annotation in

the group would be xml:id="m.4.15.1".

In the METS file, there are three file groups: two for the TEI files

and one for the facsimile scans. Each file is assigned its own ID. We

then use structural maps to link the text with the corresponding

image. In this example, we note the location (using COORDS) of the

first group of annotations in book 4 on the image:

FILEID links up to the file groups; COORDS records the coordinates on

the image file; BEGIN records the xml:id of the line in the TEI file

(multiple lines would have both BEGIN and END).

I also have a .pdf presentation that I put together in the hopes that

I wouldn't completely confuse the non-tech editors. The .zip file also

includes a sample METS file:

http://www.rch.uky.edu/Venetus/Venetus-METS.zip

> > The UVic Image Markup Tool[2] uses

> > SVG within the TEI body to link to both file and coordinates;

>

> That's an interesting example. I agree that inline SVG could be a good

> way to mark up regions within a graphic. Just a quibble, though: in your

> example, is the link between the graphical region and the text

> represented by a purely conventional correspondence between the @n and

> the @xml:id attributes? In the guidelines it suggest using a ptr to

> provide a TEI-namespaced proxy for the SVG region, then linking the ptr

> and the text markup with a TEI  element.

>

Well unfortunately as it is now, the system that the UVic IMT uses

doesn't actually link the graphical region and text on anything other

than the page-level - it's really a tool (and a markup system) for

annotating image areas, rather than a tool for linking images to text.

I think that the concept of combining SVG with TEI has applications

for the question at hand, though.

> > another

> > approach might be to have a TEI module for incorporating image files

> > and their areas in a project.

>

> This last is the approach I think I would prefer. One of my criteria for

> such a feature would be that in the simplest case it should be dead easy

> to associate a page image with a page. Whereas the METS approach is

> perfectly capable, but it's probably not so convenient for encoders, I

> would guess.

I would not call it "convenient", no. But I've had fun with it.

> Having a separate file is an extra hassle, for a start,

Yes.

> though perhaps a "METS" TEI module could be produced which would add

> METS as a root element, and introduce the TEI element embedded in the

> METS structure map?

This is interesting. Or a METS structural map in the TEI Header?

Could the same be done with SVG? That could be a way

> to at least provide recommended encoding mechanisms defined using the

> standard TEI customisation practice.

>

I don't know. But I do think that we'll be better off if we do take a

good look at what's already out there for describing images (METS, SVG

- others?) and get together a group of people who have been thinking

about these issues. So to Sebastian's last question - I think a work

group would be a useful step.

Talk to y'all tomorrow!

Dot

> Cheers

>

> Con

>

> [1] http://www.loc.gov/standards/mets/profiles/00000005.xml

> _______________________________________________

> tei-council mailing list

> tei-council_at_lists.village.Virginia.EDU

> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

>

--
***************************************
Dot Porter, Program Coordinator
Collaboratory for Research in Computing for Humanities
University of Kentucky
351 William T. Young Library
Lexington, KY  40506
dporter_at_uky.edu          859-257-9549
***************************************
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Dec 15 2005 - 17:39:05 EST

From lou.burnard at computing-services.oxford.ac.uk  Thu Dec 15 18:31:07 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 15 Dec 2005 23:31:07 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: <96f3df640512151438n226bde3btd50baad9f7d5513e@mail.gmail.com>
Message-ID: <43A1FCBB.60907@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Thu, 15 Dec 2005 23:31:07 +0000

> 

>  The main thing, to my

> 

>>mind, is that the guidelines should clearly document some standard

>>practice that doesn't involve treating page scans as figures, or making

>>custom extensions to the TEI schema.

>>

> 

> yes, yes, yes

> 

> 

No no no! In P5 we have a generic  and a generic  

element which could surely be used to mark the presence of a pagescan if 

you like. Whether you want to wrap them up in a (P5) 
  or in 

something else is a different question, of course. Also, at P5, you 

can't use the TEI without doing some kind of "custom extensions", so 

there's nothing to be afraid of there!

>>Dot, could you post a little example of the METS and TEI markup you are

>>using to associate an image file with a TEI page?

>>

> 

[details snipped]

> 

>   

>     

>       

>         

>       

>       

>         

>       

>     

> 

> FILEID links up to the file groups; COORDS records the coordinates on

> the image file; BEGIN records the xml:id of the line in the TEI file

> (multiple lines would have both BEGIN and END).

This seems to confuse two different things: the first  is pointing 

to an area, and second one to a sequence of lines, isn't it?

In P5, you can use a URI to point in either case, so the syntax is 

likely to be a lot less verbose tho not particularly more perspicuous.

Then you could either use the corresp attribute to say that the two 

things correspond, or a standoff  to associate them.

>>>The UVic Image Markup Tool[2] uses

>>>SVG within the TEI body to link to both file and coordinates;

>>

I think we're using the word "link" in a different sense here. SVG is an 

XML notation, albeit from a different namespace, so you can just embed 

it within your TEI document if you like. And indeed we have examples 

which do.

>>That's an interesting example. I agree that inline SVG could be a good

>>way to mark up regions within a graphic. Just a quibble, though: in your

>>example, is the link between the graphical region and the text

>>represented by a purely conventional correspondence between the @n and

>>the @xml:id attributes? In the guidelines it suggest using a ptr to

>>provide a TEI-namespaced proxy for the SVG region, then linking the ptr

>>and the text markup with a TEI  element.

>>

That's sort of what I said above, except that I wasn't talking about SVG!

Another thing to throw into the pot: There are formats like DjaVu which 

embed in a single object a compressed page image and an XML transcript 

of it. Anyone got any views on how that affects these issues?

p.s. shouldnt this conversation be going on on tei-l?

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Dec 15 2005 - 18:16:57 EST

From lou.burnard at computing-services.oxford.ac.uk  Thu Dec 15 18:37:51 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 15 Dec 2005 23:37:51 +0000
Subject: [tei-council] measured and measurement
In-Reply-To: <43A0A9B1.6050703@oucs.ox.ac.uk>
Message-ID: <43A1FE4F.6050007@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Thu, 15 Dec 2005 23:37:51 +0000

Sebastian Rahtz wrote:

> Lou Burnard wrote:

> 

>> The MS module defines an attribute class "measured" which adds 

>> attributes "unit" and "scope" to a number of elements.

>>

>> The ST module defines an attribute class "measurement" which adds 

>> attributes "unit" "quantity" and "commodity"

>>

>> There is evidentluy some overlap here, but I'm not sure how best to 

>> resolve it.

>>

> quantity, commodity and scope seem to be distinct, and unit is the same. 

> so why don't

> you just merge them?

> 

The trouble is that qty, unit, cdty all relate to a single measurement 

e.g. "one hogshead of boiling oil" whereas scope is used to summarize 

the applicability of the qty and unit across a number of measurements

e.g. "14 picas in most cases". I suppose I might want to say something 

like "15 hogsheads of boiling oil, mostly " to mean that some of the 

hogsheads were a bit lukewarm, maybe, or contained something other than 

oil, but it's a bit of a stretch.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Dec 15 2005 - 18:23:41 EST

From Conal.Tuohy at vuw.ac.nz  Thu Dec 15 18:56:24 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Fri, 16 Dec 2005 12:56:24 +1300
Subject: [tei-council] encoding page scans
In-Reply-To: <[tei-council] encoding page scans>
Message-ID: 

From: Conal Tuohy 

Date: Fri, 16 Dec 2005 12:56:24 +1300

Conal:

> >  The main thing, to my

> > 

> >>mind, is that the guidelines should clearly document some standard

> >>practice that doesn't involve treating page scans as 

> figures, or making

> >>custom extensions to the TEI schema.

Dot:

> > yes, yes, yes

Lou:

> No no no! In P5 we have a generic  and a generic  

> element which could surely be used to mark the presence of a 

> pagescan if 

> you like. Whether you want to wrap them up in a (P5)   or in 

> something else is a different question, of course. 

Page scans are surely not figures?

What are the intended semantics of  when not contained in a

? Should  be reserved for formal figures, and bare

 used for everything else? 

I haven't seen the  element ... I will take a look.

> Also, at P5, you 

> can't use the TEI without doing some kind of "custom extensions", so 

> there's nothing to be afraid of there!

I'm sure I don't understand what you meant by that :-) but to clarify

what I meant above: I think there should be a standard encoding in TEI

(i.e. a standard module, not one that people have to write themselves)

which defines markup for page facsimiles. 

I would be interested in the idea that a light-weight encoding practice

(such as is commonly used today) might be mapped to a more sophisticated

one using ODD. So a sophisticated module would provide a rich semantic

basis, for interchange, and a light-weight extension module could be

used as a shorthand for the common simple case of one image file per pb

element. I'm not sure how easy it is in ODD to map something simple like

 to a more generally-capable markup -

especially if the more general markup linked to graphic elements encoded

in the teiHeader or something. Do any of the ODD experts have a feel for

that? Is it feasible at all?

> p.s. shouldnt this conversation be going on on tei-l?

Perhaps?

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Dec 15 2005 - 18:56:29 EST

From sebastian.rahtz at oucs.ox.ac.uk  Thu Dec 15 19:06:05 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 16 Dec 2005 00:06:05 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: 
Message-ID: <43A204ED.4050901@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Fri, 16 Dec 2005 00:06:05 +0000

Conal Tuohy wrote:

>What are the intended semantics of  when not contained in a

>? Should  be reserved for formal figures, and bare

> used for everything else? 

>  

>

 can _contain_ , and much else besides.

You use  anywhere you want to include an external

image file, no more and no less. So if we defined ,

its child would be 

>I haven't seen the  element ... I will take a look.

>

>  

>

Lou meant , its just a way of including images

in the text by using encoding binary data

>I think there should be a standard encoding in TEI

>(i.e. a standard module, not one that people have to write themselves)

>which defines markup for page facsimiles. 

>  

>

I agree.

>I would be interested in the idea that a light-weight encoding practice

>(such as is commonly used today) might be mapped to a more sophisticated

>one using ODD. So a sophisticated module would provide a rich semantic

>basis, for interchange, and a light-weight extension module could be

>used as a shorthand for the common simple case of one image file per pb

>element. I'm not sure how easy it is in ODD to map something simple like

> to a more generally-capable markup -

>especially if the more general markup linked to graphic elements encoded

>in the teiHeader or something. Do any of the ODD experts have a feel for

>that? Is it feasible at all?

>  

>

I think I'd want to sit down with you and some scrap paper

and really get to grips with what ODD is and isn't before

I could answer that.

Would you be _very_ unhappy with a secondary TEI

document consisting of a series of  elements,

whose body would contain  elements, structured to

cover Dot's point about multiple versions? Noting that this

would allow, inter alia, for _alternative_ transcriptons in different

TEI documents, linked to this document which describes a series

of page scans?

-- 
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 Dec 15 2005 - 19:06:26 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Dec 15 19:09:26 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 16 Dec 2005 09:09:26 +0900
Subject: UPDATED: [tei-council] draft agenda for TEI council telecon 2005-12-16 1200 UTC
In-Reply-To: 
Message-ID: 

From: Christian Wittern 

Date: Fri, 16 Dec 2005 09:09:26 +0900

In light of the recent discussion, I would like to modify item 3

to make it a more general consideration of future TEI development. For

the convenience of having a complete agenda in one place, I will just

quote the rest as well.   -- Chris

Christian Wittern zinbun.kyoto-u.ac.jp> writes:

> TEI Council Members and Editors:

>

> This is the draft agenda for the conference call the TEI Council will

> hold Friday, December 16th, 2005 at 1200 UTC.

>

> Please read through the following, in advance of the call.  

>

>

> INSTRUCTIONS for conference call:

>

> Participants will dial in to +1-812-856-3600

>

> The Conference Access Information is listed below:

>

> Conf Id:        2974

> Date:        12/16/2005

>

> PIN:        000920#

>

> Expected members to participate:

>

> Syd Bauman, Alejandro Bia, David Birnbaum, Lou Burnard, James

> Cummings, Matthew Driscoll, Dot Porter, Susan Schreibman, Sebastian

> Rahtz, Laurent Romary, Natasha Smith, Conal Tuohy, John Walsh, Perry

> Willett, Christian Wittern, Matthew Zimmerman

>

> (please alert me if I did forget anyone!)

>

> Edward Vanhoutte excused himself and is busy working on his thesis while we talk.

>

>

> In addition to the voice connection, we also expect to communicate via

> IRC. Instructions to connect are as follows (quoted from James

> Cumming's message):

>

> Ok, on the day of the council call I'll set up a password (or 'key')

> protected channel called #tei-council the joining instructions are the

> same and I'd still suggest joining the #tei-c one.  Once there type:

> /join #tei-council 2expensive

> and in most IRC clients that will get you there.

>

> (instructions also at: http://www.tei-c.org.uk/wiki/index.php/IRC)

>

>

> Agenda:

>

> 7 items, ca 5-20 minutes apiece.

>

> -----------------------------------------------------

>

>

> 1) Review of the minutes and action items (10 min)

>

>    Minutes of the meeting are at

> 	 http://www.tei-c.org/Council/tcm19.html and

> 	 http://www.tei-c.org/Council/tcm20.html

> 	 To speed up the review of action items, *please report to the

> 	 council list* before the call as far as possible! 

> 	 

> 	 We will discuss the reports during the call as necessary.

>

>

> ------------------------------------------------------------

>

> 2) Review of WG etc. progress (10 min) : 

>   

>

> -----------------------------------------------------

>

3) Proposal for new work items

  We need to decide on where we want to go this next year.  We should have

  enough money to fund about one WG meeting (in Europe, ~6 members?)

  beside the Council meeting. 

  Proposals floating around ask for a personography task force (I take

  task force to mean, as we used the word earlier, a group charged

  with a rather specific task and a lifespan in the order of 6 months)

  and a page-linking task force.  

  Are there other areas in urgent need of attention? We need to think

  about how to prioritize this and allocate our efforts accordingly

>

> 4) P5 progress:  (20 min)

>

> - on attributes and datatypes

>

> - on classes

>

> - other changes

>

>

> -----------------------------------------------------

>

> 5) Other business  (5 minutes)

>

>

>  TBA

>

> -----------------------------------------------------

>

> 6) Meetings: (5 minutes)

>

>    Next teleconference: Mid February, please have your diarys ready. 

>    

>    Council meeting 2006?

>

>

>

>

> -- 

>  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 
 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 Dec 15 2005 - 19:09:34 EST

From Conal.Tuohy at vuw.ac.nz  Thu Dec 15 20:35:10 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Fri, 16 Dec 2005 14:35:10 +1300
Subject: UPDATED: [tei-council] draft agenda for TEI council telecon2005-12-16 1200 UTC
In-Reply-To: 
Message-ID: 

From: Conal Tuohy 

Date: Fri, 16 Dec 2005 14:35:10 +1300

> Christian Wittern zinbun.kyoto-u.ac.jp> writes:

> 3) Proposal for new work items

>  

>   We need to decide on where we want to go this next year.  

> We should have

>   enough money to fund about one WG meeting (in Europe, ~6 members?)

>   beside the Council meeting. 

> 

>   Proposals floating around ask for a personography task force (I take

>   task force to mean, as we used the word earlier, a group charged

>   with a rather specific task and a lifespan in the order of 6 months)

>   and a page-linking task force.  

> 

>   Are there other areas in urgent need of attention? We need to think

>   about how to prioritize this and allocate our efforts accordingly

I have only one other item: more explicit identification of external

vocabularies used in TEI taxonomies. 

I would like to establish guidelines for explicitly linking to external

vocabularies via URI, so that indexing and cataloguing software can more

easily merge metadata from TEI documents in bulk, i.e. to promote

commensurability of the indexes. At the moment the guidelines provide

for an external vocabulary (a ) to be identified with a bibl,

but I'd like us to endorse a way to include a URI as part of that

identity, to facilitate merging. 

It's probably an easy one I think, but it is important to us in NZ.

We need it to help us to construct a union catalogue from TEI documents

which are independently encoded and catalogued by a number of agencies.

The NZ government has recently launched a "National Digital

Strategy"[1], and things are starting to happen ... we have the prospect

that a large number of "community" agencies of all types may soon be

digitising, encoding, and cataloguing texts, so we will need some clear

guidelines soon. Also we have other agencies locally (here and in

Australia) adopting TEI for encyclopedia applications, where this is

also useful. It's also potentially useful to the Ontology SIG I would

think.

In general (and this applies to the page-facsimile issue too), we are

trying to make it easier for the National Library of NZ to adopt TEI as

a general rule for text encoding. This is not yet a fait accompli. I

think there's a risk that some half-baked (non-TEI) solution will catch

on, especially (a cynic might say) given the involvement of Microsoft[2]

(I know - I'm running a risk writing this using Microsoft Outlook!). 

That's it from me.

Cheers

Con

[1] http://www.digitalstrategy.govt.nz/

[2]

http://www.digitalstrategy.govt.nz/templates/Page____268.aspx#Can%20trai

ning%20be%20funded?

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Dec 15 2005 - 20:35:15 EST

From Conal.Tuohy at vuw.ac.nz  Thu Dec 15 21:01:08 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Fri, 16 Dec 2005 15:01:08 +1300
Subject: [tei-council] encoding page scans
In-Reply-To: <[tei-council] encoding page scans>
Message-ID: 

From: Conal Tuohy 

Date: Fri, 16 Dec 2005 15:01:08 +1300

Sebastian Rahtz wrote: 

>  can _contain_ , and much else besides.

> You use  anywhere you want to include an external

> image file, no more and no less. So if we defined ,

> its child would be 

OK

Conal:

> >I would be interested in the idea that a light-weight 

> encoding practice

> >(such as is commonly used today) might be mapped to a more 

> sophisticated

> >one using ODD. 

Sebastian:

> I think I'd want to sit down with you and some scrap paper

> and really get to grips with what ODD is and isn't before

> I could answer that.

Hmmm ... that might take a while to arrange :-)

I'm not sure that I expressed myself that clearly - I wondered just how

far ODD's "filter" system could go in terms of mapping TEI instances to

other schemas - is there anything it can't do, in principle? 

The reason I wondered was that it seemed to me that a good general

markup solution might be considerably more verbose than a light-weight

variant , and since a light-weight style has some

value, therefore that might be a constraint on the form of the more

general markup. I will need to get to grips with ODD and try it out, but

I think it should work. 

If the standard page facsimile markup were to encode facsimile elements

in the sourceDesc (with links pointing into the text), then an ODD

customisation for a light-weight page-facsimile markup would define a

sourceDesc whose content model EXCLUDED facsimile elements, but it could

define a filter to generate those basic facsimile elements from

//pb/@url, and the links from //pb/@xml:id

Sebastian:

> Would you be _very_ unhappy with a secondary TEI

> document consisting of a series of  elements,

> whose body would contain  elements, structured to

> cover Dot's point about multiple versions? Noting that this

> would allow, inter alia, for _alternative_ transcriptons in different

> TEI documents, linked to this document which describes a series

> of page scans?

I would be very happy if that were allowed, but I would very much like

the ability to encode them in a single file, as well. I think simplicity

is a key requirement, actually. Otherwise METS is just as good, I think.

Con

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Dec 15 2005 - 21:01:12 EST

From Syd_Bauman at Brown.edu  Fri Dec 16 01:06:56 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 16 Dec 2005 01:06:56 -0500
Subject: [tei-council] encoding page scans
In-Reply-To: 
Message-ID: <17314.22912.871433.552250@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Fri, 16 Dec 2005 01:06:56 -0500

CT> PS incidentally, I note that graphic/@scale has type

CT> data.probability. Shouldn't this be a real number?

Hmmm... perhaps. Remember that data.probability is a real number

between 0 and 1 (inclusive). It is probably unreasonable to have a

negative value for scale= of , but a value > 1 may make

sense. In which case, the desired constraint is

   xsd:double { minInclusive="0" }

and no existing TEI datatype will do the job. We could

a) decide negative values are OK (what do they mean?) and use

   tei.numeric 

b) use data.numeric, and live with the fact that the schema permits

   negative values that make no sense (prose remarks and perhaps

   Schematron rules would disallow negative values)

c) use data.outputMeasurement

d) create new TEI datatype

e) use RelaxNG code directly, w/o a datatype

I don't like (c), it has the wrong semantics.

SR> Don't forget, by the way, that for some people  points

SR> forward, for others it points back. If we all used , that

SR> would need clearing up too.

How much stronger than the current "By convention,  elements

should appear at the start of the page to which they refer." do you

think we should get?

LB> p.s. shouldnt this conversation be going on on tei-l?

CT> Perhaps?

I think it should be. But the real problem is we can't just post to

TEI-L and tell people to read the archives of this discussion,

because the archives of this list are viewable by subscribers only,

and thus are closed to public scrutiny. While I suppose there may be

an occasional sensitive discussion, generally speaking I'm of a mind

that the deliberations of Council should be open.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 16 2005 - 01:07:04 EST

From Syd_Bauman at Brown.edu  Fri Dec 16 01:31:25 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 16 Dec 2005 01:31:25 -0500
Subject: [tei-council] (very) Brief status report on P5
In-Reply-To: <43A0BF7D.6040102@computing-services.oxford.ac.uk>
Message-ID: <17314.24381.659915.394768@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Fri, 16 Dec 2005 01:31:25 -0500

Thank you, Lou, for posting this. 

> [Syd may want to add to this]

Only 2 things come to mind to add, one which has occurred since Lou

posted the list.

7. Most of our XPointer scheme names have been registered with W3C. 

8. Spurred by Torsten Schassan's bug report on Sourceforge[1] I went

   through and fixed lots of phrase-level encodings in the content of

   P5, mostly by fixing type= of . Well over 120 fixes made.

   28 s found which I want to ask Lou about before changing

   them. (Expect that list over the weekend, Lou :-)

> 1. During October there was extensive work on attributes and datatypes, 

> which was completed in time for a release of P5 (0.2.1) to take place on 

> the 21st.

> 

> 2. During November, the priority was to work on classes. A detailed 

> programme of work was agreed following the Council meeting in Oxford, 

> and is now complete. Full details of the changes made are available from 

> http://www.tei-c.org/Drafts/edw92.xml

> 

> 3. Some outstanding issues remain on the class front, in particular  

> there is still need for a  review of many chapters not discussed at the  

> Oxford meeting.  Enough work has been done, however, to proceed to the 

> revision of chapter ST, which is the next priority.

> 

> 4. In December, Matthew Driscoll visited Oxford, resulting in a number 

> of minor corrections to the MS chapter.

> 

> 5. A new "listPerson" element has been introduced to facilitate encoding 

> of "personographical" data: this was tested on some data supplied by 

> Matthew which now forms a new component of the test suite.

> 

> 6. New material for inclusion in chapters SA and NH has been received 

> but not yet reviewed by both editors.

Note

----
[1] http://sourceforge.net/tracker/index.php?func=detail&aid=1378784&group_id=106328&atid=644062
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 16 2005 - 01:31:34 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Dec 16 02:35:44 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 16 Dec 2005 16:35:44 +0900
Subject: UPDATED: [tei-council] draft agenda for TEI council telecon2005-12-16 1200 UTC
In-Reply-To: 
Message-ID: 

From: Christian Wittern 

Date: Fri, 16 Dec 2005 16:35:44 +0900

"Conal Tuohy" ac.nz> writes:

>> Christian Wittern zinbun.kyoto-u.ac.jp> writes:

>

>> 3) Proposal for new work items

>>  

>

> I have only one other item: more explicit identification of external

> vocabularies used in TEI taxonomies. 

>

> I would like to establish guidelines for explicitly linking to external

> vocabularies via URI, so that indexing and cataloguing software can more

> easily merge metadata from TEI documents in bulk, i.e. to promote

> commensurability of the indexes. At the moment the guidelines provide

> for an external vocabulary (a ) to be identified with a bibl,

> but I'd like us to endorse a way to include a URI as part of that

> identity, to facilitate merging. 

Fair enough. Looking at

http://www.tei-c.org.uk/P5/Guidelines/HD.html#HD55 I wonder if what we

need here is an endorsed way to provide a URL within  and

friends (do we have that?).  This looks like a pretty frequent

requirement in bibliographic citations to me.

Would that solve the problem at hand, Conal?

> In general (and this applies to the page-facsimile issue too), we are

> trying to make it easier for the National Library of NZ to adopt TEI as

> a general rule for text encoding. This is not yet a fait accompli. I

> think there's a risk that some half-baked (non-TEI) solution will catch

> on, especially (a cynic might say) given the involvement of Microsoft[2]

> (I know - I'm running a risk writing this using Microsoft Outlook!). 

>

That is certainly something I would like to see happen and we should

do what we can to facilitate it.

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 Dec 16 2005 - 02:35:55 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Dec 16 02:48:51 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 16 Dec 2005 16:48:51 +0900
Subject: [tei-council] encoding page scans
In-Reply-To: <43A1FCBB.60907@computing-services.oxford.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Fri, 16 Dec 2005 16:48:51 +0900

Lou Burnard oxford.ac.uk> writes:

>>  The main thing, to my

>> 

>>>mind, is that the guidelines should clearly document some standard

>>>practice that doesn't involve treating page scans as figures, or making

>>>custom extensions to the TEI schema.

>>>

>> yes, yes, yes

yes.  What we do need in the Guidelines is some recommendation on how

to do this.  It is a common requirement and it would be helpful if we

show people how to do it in a way that is likely to be similar to what

her neighbour is doing.  I think we might want to have one

quick-and-dirty way of doing this, which is I think what Conal is

asking for, which might be completely done within TEI.  Digital

Libraries and the like might want to adopt a more sophisticated

strategy, where METS gets into the game, which would also be helpful

if we document a recommended way.  I see a task force here as well.

> No no no! In P5 we have a generic  and a generic 

> element which could surely be used to mark the presence of a pagescan

> if you like. Whether you want to wrap them up in a (P5)   or

> in something else is a different question, of course. Also, at P5, you

> can't use the TEI without doing some kind of "custom extensions", so

> there's nothing to be afraid of there!

Yeah, quite right in the general case.  Nevertheless, we do want to

continue to give recommendations on best practice and the like.

Common requirements like this *should* be discussed in the Guidelines. 

>

>> 

>>   

>>     

>>       

>>         

>>       

>>       

>>         

>>       

>>     

>> FILEID links up to the file groups; COORDS records the coordinates

>> on

>> the image file; BEGIN records the xml:id of the line in the TEI file

>> (multiple lines would have both BEGIN and END).

>

> This seems to confuse two different things: the first  is

> pointing to an area, and second one to a sequence of lines, isn't

> it?

Right.  And the point is to say that these two components do

correspondend to each other.

> In P5, you can use a URI to point in either case, so the syntax is

> likely to be a lot less verbose tho not particularly more perspicuous.

>

> Then you could either use the corresp attribute to say that the two

> things correspond, or a standoff  to associate them.

>

I still think that for these cases there is no good reason to

re-invent METS.

>

> Another thing to throw into the pot: There are formats like DjaVu

> which embed in a single object a compressed page image and an XML

> transcript of it. Anyone got any views on how that affects these

> issues?

>

Now, here we do have a good case for a customization.  My djvu.odd would

just add some @coords to every  element, most likely.  But you

still need to have a place to put the image location.  I recently

briefly looked at Scansofts Omnipage, which produces (horrible,

horrible) XML which contains all this information, just crying for

being domesticated in TEI.

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 Dec 16 2005 - 02:48:57 EST

From sebastian.rahtz at oucs.ox.ac.uk  Fri Dec 16 04:11:43 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 16 Dec 2005 09:11:43 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: <17314.22912.871433.552250@emt.wwp.brown.edu>
Message-ID: <43A284CF.10703@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Fri, 16 Dec 2005 09:11:43 +0000

Syd Bauman wrote:

>Hmmm... perhaps. Remember that data.probability is a real number

>between 0 and 1 (inclusive). It is probably unreasonable to have a

>negative value for scale= of , but a value > 1 may make

>sense. In which case, the desired constraint is

>   xsd:double { minInclusive="0" }

>and no existing TEI datatype will do the job. We could

>a) decide negative values are OK (what do they mean?) and use

>   tei.numeric 

>b) use data.numeric, and live with the fact that the schema permits

>   negative values that make no sense (prose remarks and perhaps

>   Schematron rules would disallow negative values)

>c) use data.outputMeasurement

>d) create new TEI datatype

>e) use RelaxNG code directly, w/o a datatype

>  

>

I'd go straight to b) and live with the common sense approach.

>SR> Don't forget, by the way, that for some people  points

>SR> forward, for others it points back. If we all used , that

>SR> would need clearing up too.

>

>How much stronger than the current "By convention,  elements

>should appear at the start of the page to which they refer." do you

>think we should get?

>  

>

Stronger :-}

in what sense does a  "refer" to a page? its a page boundary,

by definition it occurs between two pages, favouring neither.

is there a page boundary at the start of every document?

perhaps I'm biased from a typesetting background, but I treat

 like a LaTeX \newpage, so it occurs at the point where

I expect a new page to start; and at the start of the document

I have implictly started a new page anyway.

ebastian

>

>  

>

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 16 2005 - 04:11:47 EST

From sebastian.rahtz at oucs.ox.ac.uk  Fri Dec 16 04:16:59 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 16 Dec 2005 09:16:59 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: 
Message-ID: <43A2860B.50002@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Fri, 16 Dec 2005 09:16:59 +0000

I note that the W3C has a concept of non-normative "Note" documents,

which are not Recommendations, but sometimes have equivalent respect

and moral power. We don't have anything like that, and I think its a lack.

We have the Guidelines, in all their raging glory, and a set of

discussion documents which never leave /Drafts/ (how weird is that?), and

then we drift into things of educational status like the TEI Lite document.

These last few days, we've identified two clear areas where we feel

the TEI should take a lead, but we don't think that the message is

so definite that it should be in the Guidelines.

Am I going astray here? do others feel that in fact these

recommendations _should_ always be part of the Guidelines?

Sebastian

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 16 2005 - 04:17:07 EST

From Conal.Tuohy at vuw.ac.nz  Fri Dec 16 04:18:44 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Fri, 16 Dec 2005 22:18:44 +1300
Subject: UPDATED: [tei-council] draft agenda for TEI council telecon2005-12-16 1200 UTC
In-Reply-To: 
Message-ID: 

From: Conal Tuohy 

Date: Fri, 16 Dec 2005 22:18:44 +1300

Conal:

> At the moment the guidelines provide

> for an external vocabulary (a ) to be identified with a bibl,

> but I'd like us to endorse a way to include a URI as part of that

> identity, to facilitate merging. 

Christian:

> Fair enough. Looking at

> http://www.tei-c.org.uk/P5/Guidelines/HD.html#HD55 I wonder if what we

> need here is an endorsed way to provide a URL within  and

> friends (do we have that?).  This looks like a pretty frequent

> requirement in bibliographic citations to me.

> 

> Would that solve the problem at hand, Conal?

Yes. Perhaps just adding ref to model.biblPart? 

Con

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 16 2005 - 04:18:56 EST

From Conal.Tuohy at vuw.ac.nz  Fri Dec 16 04:21:36 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Fri, 16 Dec 2005 22:21:36 +1300
Subject: [tei-council] encoding page scans
In-Reply-To: <43A284CF.10703@oucs.ox.ac.uk>
Message-ID: 

From: Conal Tuohy 

Date: Fri, 16 Dec 2005 22:21:36 +1300

Sebastian Rahtz wrote:

> in what sense does a  "refer" to a page? its a page boundary,

> by definition it occurs between two pages, favouring neither.

That's true. Maybe the facsimiles should refer to the region between 2 page-breaks, then? Using an appropriate xpointer scheme, or perhaps with start and end attributes? 

Con

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 16 2005 - 04:24:12 EST

From sebastian.rahtz at oucs.ox.ac.uk  Fri Dec 16 04:29:39 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 16 Dec 2005 09:29:39 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: 
Message-ID: <43A28903.7000902@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Fri, 16 Dec 2005 09:29:39 +0000

Conal Tuohy wrote:

>>in what sense does a  "refer" to a page? its a page boundary,

>>by definition it occurs between two pages, favouring neither.

>>    

>>

>

>That's true. Maybe the facsimiles should refer to the region between 2 page-breaks, then? Using an appropriate xpointer scheme, or perhaps with start and end attributes?

>  

>

that certainly would be less ambiguous. It would also allow for the 

situation

where the page facsimile was of a double page spread; I am sure none

of you do that, of course :-}

Sebastian

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 16 2005 - 04:29:45 EST

From lou.burnard at computing-services.oxford.ac.uk  Fri Dec 16 04:45:27 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 16 Dec 2005 09:45:27 +0000
Subject: UPDATED: [tei-council] draft agenda for TEI council	telecon2005-12-16 1200 UTC
In-Reply-To: 
Message-ID: <43A28CB7.8020707@computing-services.oxford.ac.uk>

From: Lou Burnard 

Date: Fri, 16 Dec 2005 09:45:27 +0000

 (and ) are already available inside , inasmuch as 

 allows model.phrase

Conal Tuohy wrote:

> Conal:

> 

>>At the moment the guidelines provide

>>for an external vocabulary (a ) to be identified with a bibl,

>>but I'd like us to endorse a way to include a URI as part of that

>>identity, to facilitate merging. 

> 

> 

> Christian:

> 

>>Fair enough. Looking at

>>http://www.tei-c.org.uk/P5/Guidelines/HD.html#HD55 I wonder if what we

>>need here is an endorsed way to provide a URL within  and

>>friends (do we have that?).  This looks like a pretty frequent

>>requirement in bibliographic citations to me.

>>

>>Would that solve the problem at hand, Conal?

> 

> 

> Yes. Perhaps just adding ref to model.biblPart? 

> 

> 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 Fri Dec 16 2005 - 04:31:46 EST

From sebastian.rahtz at oucs.ox.ac.uk  Fri Dec 16 04:39:27 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 16 Dec 2005 09:39:27 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: 
Message-ID: <43A28B4F.1030301@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Fri, 16 Dec 2005 09:39:27 +0000

Conal Tuohy wrote:

>I'm not sure that I expressed myself that clearly - I wondered just how

>far ODD's "filter" system could go in terms of mapping TEI instances to

>other schemas - is there anything it can't do, in principle? 

>  

>

the filtering I talked about in Sofia deals with one element

at a time. So if it was a matter of redoing a whole structure,

i'm wary

>The reason I wondered was that it seemed to me that a good general

>markup solution might be considerably more verbose than a light-weight

>variant 

>

In general, I dont think verbosity is a bad thing...

>If the standard page facsimile markup were to encode facsimile elements

>in the sourceDesc (with links pointing into the text), then an ODD

>customisation for a light-weight page-facsimile markup would define a

>sourceDesc whose content model EXCLUDED facsimile elements, but it could

>define a filter to generate those basic facsimile elements from

>//pb/@url, and the links from //pb/@xml:id

>

maybe. that would be pushing the ODD stuff into new territory;

you have to realize that the  mechanism is barely

explored, and there are few examples of its use.  I'd be delighted

to see experiments in this area!

Sebastian

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 16 2005 - 04:39:31 EST

From sebastian.rahtz at oucs.ox.ac.uk  Fri Dec 16 06:31:50 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 16 Dec 2005 11:31:50 +0000
Subject: [tei-council] fun for the conference call
Message-ID: <43A2A5A6.8060401@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Fri, 16 Dec 2005 11:31:50 +0000

http://kitchen-cam.oucs.ox.ac.uk/ is showing my office, with James

and Lou expected to be sitting at the table for the conference call

in half an hour

--
-- 
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 Dec 16 2005 - 06:32:29 EST

From sebastian.rahtz at oucs.ox.ac.uk  Fri Dec 16 07:15:01 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 16 Dec 2005 12:15:01 +0000
Subject: [tei-council] personography strawman proposal from LB, MJD, SR
Message-ID: <43A2AFC5.4080405@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Fri, 16 Dec 2005 12:15:01 +0000

We suggest that a full-scale work group starting now from first

principles is not the best use of time or money.

A lot of work has already been done in this area, by a number of

different people, many of them using TEI with a few minor variations. It

seems then that what is needed would be more a clear statement of best

practice than  a  radically new set of TEI tags.

We propose work in 3 stages:

1. clearing up TEI P5 to add a few obviously missing elements (, 

)

and attributes  (generalising and simplifying ways of approximate dating 

for example),

and testing that P5 then covers a realistic quantity of existing person 

data.

Drafting a new section for P5  to describe this revised material (much

of it is already present in P5, but in the Corpus chapter).

2. investigating in a systematic way other existing schemata to see how 

they handle

person data and how their feature sets compare to those of what we have 

in P5.

This would aim to produce a kind of "cross-walk" of existing person data

schemata and some sample data sets.

3. organize a workgroup meeting to review the outputs from the first two

stages and  to develop the TEI recommendation.

Stage 1 has been largely completed already (it finished late last night;

P5 now adequately describes MJD's large set of person data, and my 

gravestone material).

For Stage 2, we suggest that part of the funds allocated to this area be 

used to fund

a student researcher in Copenhagen for  5 days work under the 

supervision of MJD.

For Stage 3, we propose that MJD be asked to convene a workgroup which 

will be funded to

meet once in the early spring, report to the Council in May, and 

conclude by the summer.

Work group objectives:

* review the TEI elements which are used to describe people, including

   where necessary those relating to place and date, and integrate them 

into a new module.

* review TEI customizations (eg Epidoc and the other classical 

archaeology work)

  which deal with people and work with their

  authors to incorporate any useful additions into the TEI core.

* investigate other encoding schemes which cover historical persons (eg 

HEML)

   and make recommendations on how the TEI scheme should relate to them.

-- 
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 Dec 16 2005 - 07:15:22 EST

From mz34 at nyu.edu  Fri Dec 16 08:50:57 2005
From: mz34 at nyu.edu (Matthew Zimmerman)
Date: Fri, 16 Dec 2005 08:50:57 -0500
Subject: [tei-council] missed conference call
Message-ID: <8F8299E2-E1D7-4A2C-AF08-D95C03DC7226@nyu.edu>

From: Matthew Zimmerman 

Date: Fri, 16 Dec 2005 08:50:57 -0500

A very auspicious start for me as TEI chair.

My lame explanation is I set the alarm for 5 A.M. so I could get to  

the office by 7 A.M. in case of a transit strike here, and apparently  

didn't turn the alarm on.

Hope my absence didn't hold up any work

MZ

_________________

Matthew Zimmerman

Faculty Technology Services, NYU

Tel: 212.998.3038

Fax: 212.995.4120

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 16 2005 - 08:50:59 EST

From lou.burnard at computing-services.oxford.ac.uk  Fri Dec 16 08:59:55 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 16 Dec 2005 13:59:55 +0000
Subject: [tei-council] missed conference call
In-Reply-To: <8F8299E2-E1D7-4A2C-AF08-D95C03DC7226@nyu.edu>
Message-ID: <43A2C85B.5020208@oucs.ox.ac.uk>

From: Lou Burnard 

Date: Fri, 16 Dec 2005 13:59:55 +0000

Not only did we manage without you, but somehow we failed to allocate 

any work to you!

Matthew Zimmerman wrote:

> A very auspicious start for me as TEI chair.

> 

> My lame explanation is I set the alarm for 5 A.M. so I could get to  the 

> office by 7 A.M. in case of a transit strike here, and apparently  

> didn't turn the alarm on.

> 

> Hope my absence didn't hold up any work

> 

> MZ

> _________________

> Matthew Zimmerman

> Faculty Technology Services, NYU

> Tel: 212.998.3038

> Fax: 212.995.4120

> 

> 

> _______________________________________________

> 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 Dec 16 2005 - 08:57:38 EST

From mz34 at nyu.edu  Fri Dec 16 09:10:33 2005
From: mz34 at nyu.edu (Matthew Zimmerman)
Date: Fri, 16 Dec 2005 09:10:33 -0500
Subject: [tei-council] missed conference call
In-Reply-To: <43A2C85B.5020208@oucs.ox.ac.uk>
Message-ID: 

From: Matthew Zimmerman 

Date: Fri, 16 Dec 2005 09:10:33 -0500

Now that isn't right!

On Dec 16, 2005, at 8:59 AM, Lou Burnard wrote:

> Not only did we manage without you, but somehow we failed to  

> allocate any work to you!

>

> Matthew Zimmerman wrote:

>> A very auspicious start for me as TEI chair.

>> My lame explanation is I set the alarm for 5 A.M. so I could get  

>> to  the office by 7 A.M. in case of a transit strike here, and  

>> apparently  didn't turn the alarm on.

>> Hope my absence didn't hold up any work

>> MZ

>> _________________

>> Matthew Zimmerman

>> Faculty Technology Services, NYU

>> Tel: 212.998.3038

>> Fax: 212.995.4120

>> _______________________________________________

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

MZ

_________________

Matthew Zimmerman

Faculty Technology Services, NYU

Tel: 212.998.3038

Fax: 212.995.4120

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 16 2005 - 09:10:39 EST

From Conal.Tuohy at vuw.ac.nz  Fri Dec 16 09:28:53 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Sat, 17 Dec 2005 03:28:53 +1300
Subject: [tei-council] Facsimile work
Message-ID: 

From: Conal Tuohy 

Date: Sat, 17 Dec 2005 03:28:53 +1300

I have created a page on the wiki with some notes about the Facsimile work item (I've categorised it as a SIG on the Wiki). http://www.tei-c.org/wiki/index.php/SIG:Facsimile

I think the next thing is to solicit examples of current practice, and for me and Dot to make a module that is functionally equivalent to her METS structure map.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 16 2005 - 09:28:57 EST

From lou.burnard at computing-services.oxford.ac.uk  Fri Dec 16 13:01:06 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 16 Dec 2005 18:01:06 +0000
Subject: [tei-council] Notes from today
Message-ID: <43A300E2.6070607@oucs.ox.ac.uk>

From: Lou Burnard 

Date: Fri, 16 Dec 2005 18:01:06 +0000

Please check at http://www.tei-c.org/Council/tcm21.xml for any gross 

errors or misrepresentation

Lou

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 16 2005 - 12:58:50 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Dec 16 16:23:33 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 17 Dec 2005 06:23:33 +0900
Subject: [tei-council] state of physical bibliography WG
Message-ID: 

From: Christian Wittern 

Date: Sat, 17 Dec 2005 06:23:33 +0900

Dear Council members,

As promised during yesterdays call, here is the message that came in

from Murray.

Julia, your message is timely. With the undergraduate term over, I am

about to e-mail the current members with a report on the progress of

my researches over the last few weeks and to suggest a plan of action.

For whatever reason, the current membership of the workgroup seems to

be such that forward progress in this workgroup will ultimately happen

because of the chair's own initiatives--some members even ignored my

request for information about their interest in continuing the work of

the group. I definitely will be recruiting further members, in part in

an attempt to change this climate; in particular, I am hoping to get

Elizabeth Solopova (who works with manuscript cataloguing at the

Bodleian) and Bettina Wagner (Bayerische Staatsbibliothek Muenchen,

description of incunabula) to join. Much of my own work over the fall

has been directed to assessing the feasability of the initial plans,

as the workgroup (i.e. principally you) clarified those to me during

the summer.

There are two main problems I see with those initial plans: a) an

encoding that can be induced (with no or little transformation) to

spit out in print a Bowers-like collation formula (a stated goal in

discussion in summer) may be incompatible with an encoding that allows

a full and explicit encoding of the physical facts of the printed book

(an implicit goal of all discussion so far), because Bowers depends on

various kinds of implicit  representation throughout (I will elaborate

on this  in discussion with the workgroup); and b) Bowers-like

collation formalae are not entirely compatible with the collation

symbolism commonly applied to medieval manuscripts and incunabulae

(primarily because Bowers depends on regular sequences of signings,

which are generally absent in MSS) and only partially compatible with

the collational formulae used outside of the English-speaking world.

Two alternatives are therefore presented: to consider that what we

want to encode is a Bowers (or other) formula, let the norms of the

particular sub-discipline or research culture govern its arrangement,

and throw up our hands about the direct physical description of the

document (in which case a simple  tag with allowance for the

kinds of typographical representations that people use is all that is

needed); or to decide that what we really want to do is encode the

physical structure of the book, manuscript, etc. (in which case an

encoding of a certain degree of generality (higher than Bowers

formulas) and explicitness (higher than Bowers formulas) is

required). I think the latter has more chance of being useful to more

people over a longer time and will be arguing for that route, and also

for the addition of members who can speak to usages outside of the

English-speaking of book describers who deal with letterpress books

after 1700.

That's where things stand right now, Christian.

Murray McGillivray

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 Dec 16 2005 - 16:24:09 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sat Dec 17 18:47:17 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 18 Dec 2005 08:47:17 +0900
Subject: [tei-council] Notes from today
In-Reply-To: <43A300E2.6070607@oucs.ox.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Sun, 18 Dec 2005 08:47:17 +0900

Lou Burnard oxford.ac.uk> writes:

> Please check at http://www.tei-c.org/Council/tcm21.xml for any gross

> errors or misrepresentation

>

As always, thanks a lot for the quick and elegant handling of this.

It looks fine to me as it is.

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 Sat Dec 17 2005 - 18:47:27 EST

From lou.burnard at computing-services.oxford.ac.uk  Sun Dec 18 13:49:53 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop)
Date: Sun, 18 Dec 2005 18:49:53 +0000
Subject: [tei-council] customization in P5
Message-ID: <43A5AF51.9070600@computing-services.oxford.ac.uk>

From: Lou's Laptop 

Date: Sun, 18 Dec 2005 18:49:53 +0000

At present, there are two ways in which I can make a TEI schema.  I can 

either write an ODD and crunch it through the appropriate stylesheet, or 

I can hack together an invocation of the relevant modules using 

constructs specific to my chosen schema language (e.g. a DTD subset for 

DTD language or a RelaxNG schema with rferences to the right patterns) 

.  The constructs I use are quite different for different target 

languages, especially if I want to delete or emend elements or add new 

ones.  In P4, much of chapter ST is given over to explaining how  the 

customization mechanism is implemented in DTD world, but there is no 

discussion at all about how I might combine RelaxNG modules. And I don't 

have the faintest idea how I'd do it in W3C schema, before you ask.

 As I go about revising this chapter, I keep wondering whether or not 

any of this is still needed. If our recommendation is (as I think we 

agreed in Paris that it should be) to express each TEI customization 

declaratively as an ODD, why should we bother people with x.entities and 

things  like  ? If you run your ODD 

through the appropriate stylesheet, what you get out is a flat schema in 

the target language, not one that  invokes a set of modules at all. It 

uses lots of parameter entities, but they are not the ones defined in 

chapter ST.

Some time ago, the Meta group noted that if  we continued to  support 

modifiable DTD fragments, we would have to find some way of 

round-tripping between a TEI DTD modification subset and the 

corresponding ODD. This was not something we wanted to contemplate at 

the time, nor does it fill me with enthusiasm at the moment. Neither 

does the thought of maintaining  multiple ways of doing the same TEI 

customization independent of each other.

I don't have an answer to this and it raises difficult problems. If we 

say that the only means of TEI customization supported is via an ODD 

spec we need to put more thought into specifying exactly what an ODD 

conformant processor does. If we say that there are many means of 

customization, we need to explain all of them in quite some detail. Hmmm.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Dec 18 2005 - 13:50:02 EST

From sebastian.rahtz at oucs.ox.ac.uk  Sun Dec 18 14:30:20 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 18 Dec 2005 19:30:20 +0000
Subject: [tei-council] date, venue for next meeting
Message-ID: <43A5B8CC.5070600@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 18 Dec 2005 19:30:20 +0000

for the sake of argument, can we look at the last week of May 2006 and

do comparative costings for Tokyo and Washington? How about if people

estimated travel costs for those two locations? I am happy to do 

correlate a

table if desired.

for example, for me Tokyo costs ?490 (more or less), and Washington 

about ?450.

But I refuse to fly to an airport named after Ronald Reagan :-}

I did this on the basis of May 20th-25th.

Oxford would cost me nothing, Paris about ?150

What are chances of cheapish hotels in Kyoto? or Washington?

On the whole, Paris likely to be cheapest :-}

-- 
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 Dec 18 2005 - 14:30:43 EST

From Laurent.Romary at loria.fr  Sun Dec 18 15:11:40 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Sun, 18 Dec 2005 21:11:40 +0100
Subject: [tei-council] customization in P5
In-Reply-To: <43A5AF51.9070600@computing-services.oxford.ac.uk>
Message-ID: <0C1F90AB-A52F-480C-A0D2-EF09E17A3650@loria.fr>

From: Laurent Romary 

Date: Sun, 18 Dec 2005 21:11:40 +0100

As a matter of fact, a whole week of meetings, ending in a full  

afternoon of Roma/ODD tutorial in Nancy at the very time of our  

conference call put me in the best position just to forget it... I  

should send tankers of apologies to all of you, but Lou's message  

cheers me up a little bit since I can give you a kind of feedback  

from the mass. It appears that the principles of ODD, combined with  

the nice features of Roma do reach people's mind as we teach them. My  

audience was made of colleagues from Nancy who, for most of them, had  

experience of DTDs/Schemas and the like. They al appreciated the  

prospect of not having to fiddle with those things anymore and are  

very pleased with the idea of just having ODD as the sole  

custumization means for the TEI (or sole specification language for  

any kind of XML application, but this is rather out of topic).

So I would like to suggest that the council fully endorses the  

proposition of the Meta group that we highly recommend not to hack  

DTDs/Schemas for customize the TEI tagset, but ony use ODD specs. I  

then agree to put the issue of defining what an ODD conformant  

processor is on the agenda of my meeting with Lou next week.

Best wishes,

Laurent

PS: the DTD which is generated when deleting  a lot of elements from  

the 4 basic module (e.g. just to keep text/(front,body,back)/p) is  

not as robust as the corresponding RelaxNG schema). Incomplete  

stements are generated which prevent any further processing.

Le 18 d?c. 05 ? 19:49, Lou's Laptop a ?crit :

> At present, there are two ways in which I can make a TEI schema.  I  

> can either write an ODD and crunch it through the appropriate  

> stylesheet, or I can hack together an invocation of the relevant  

> modules using constructs specific to my chosen schema language  

> (e.g. a DTD subset for DTD language or a RelaxNG schema with  

> rferences to the right patterns) .  The constructs I use are quite  

> different for different target languages, especially if I want to  

> delete or emend elements or add new ones.  In P4, much of chapter  

> ST is given over to explaining how  the customization mechanism is  

> implemented in DTD world, but there is no discussion at all about  

> how I might combine RelaxNG modules. And I don't have the faintest  

> idea how I'd do it in W3C schema, before you ask.

>

> As I go about revising this chapter, I keep wondering whether or  

> not any of this is still needed. If our recommendation is (as I  

> think we agreed in Paris that it should be) to express each TEI  

> customization declaratively as an ODD, why should we bother people  

> with x.entities and things  like 

> "INCLUDE"> ? If you run your ODD through the appropriate  

> stylesheet, what you get out is a flat schema in the target  

> language, not one that  invokes a set of modules at all. It uses  

> lots of parameter entities, but they are not the ones defined in  

> chapter ST.

>

> Some time ago, the Meta group noted that if  we continued to   

> support modifiable DTD fragments, we would have to find some way of  

> round-tripping between a TEI DTD modification subset and the  

> corresponding ODD. This was not something we wanted to contemplate  

> at the time, nor does it fill me with enthusiasm at the moment.  

> Neither does the thought of maintaining  multiple ways of doing the  

> same TEI customization independent of each other.

>

> I don't have an answer to this and it raises difficult problems. If  

> we say that the only means of TEI customization supported is via an  

> ODD spec we need to put more thought into specifying exactly what  

> an ODD conformant processor does. If we say that there are many  

> means of customization, we need to explain all of them in quite  

> some detail. Hmmm.

>

>

>

>

> _______________________________________________

> 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 Sun Dec 18 2005 - 15:09:58 EST

From sebastian.rahtz at oucs.ox.ac.uk  Sun Dec 18 16:29:48 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 18 Dec 2005 21:29:48 +0000
Subject: [tei-council] customization in P5
In-Reply-To: <0C1F90AB-A52F-480C-A0D2-EF09E17A3650@loria.fr>
Message-ID: <43A5D4CC.50200@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 18 Dec 2005 21:29:48 +0000

> So I would like to suggest that the council fully endorses the  

> proposition of the Meta group that we highly recommend not to hack  

> DTDs/Schemas for customize the TEI tagset, but ony use ODD specs.

Just to be clear, this was the proposition of the whole council already, 

in Paris. I wrote a document which

outlined 3 ways of using the TEI, which I sent in from Timor, and the 

council firmly said "No", as I recall.

So I don't think we need formally discuss it more, it was already stated.

I think Lou should cut down chapter ST a lot,  and let it reference the 

customization chapter. That's

the one which needs bringing to the fore, and explaining how to use the 

TEI in anger (that's constructive

anger, not the sort I vented in the poor DHQ list, if any of you are on 

that).

>

> PS: the DTD which is generated when deleting  a lot of elements from  

> the 4 basic module (e.g. just to keep text/(front,body,back)/p) is  

> not as robust as the corresponding RelaxNG schema). Incomplete  

> stements are generated which prevent any further processing.

I am slightly surprised by that. Can you give me a sample ODD which 

generates Relax properly, but not DTD?

Such things need sorting out.

You may find the next release better, as a lot of the class changes 

affected this situation.

-- 
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 Dec 18 2005 - 16:30:19 EST

From Syd_Bauman at Brown.edu  Sun Dec 18 16:54:49 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 18 Dec 2005 16:54:49 -0500
Subject: [tei-council] customization in P5
In-Reply-To: <0C1F90AB-A52F-480C-A0D2-EF09E17A3650@loria.fr>
Message-ID: <17317.55977.731817.556417@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sun, 18 Dec 2005 16:54:49 -0500

I personally think that we should explicitly drop the idea of support

for customizations in DTD, W3C Schema, or any language other than ODD

and RelaxNG. Even the RelaxNG customizations should be downplayed as

something one does only when necessary, or for throw-away

one-time-use schemas. Moreover, my vague recollection from the

2005-04 meeting in Paris is that exactly this was decided there.

Various opinions were expressed as to whether customizations should

be permitted in RelaxNG (some against, many abstaining, and only 1 in

favor -- me), but nobody defended permitting customizations in DTD or

XSD. However, I can't find any reference to this in the minutes,

though. (Which would be my fault, I know.)-:

Thus I think the chapters on structure (ST) and customization (MD)

should barely mention DTDs nor W3C Schemas if at all. The chapter on

conformance (CF) should mention them only in as far as to point out

they are not the canonical expression of TEI constraints. (Of course,

neither is the RelaxNG, but it's at least a step closer.)

This would be a reversal of a decision Council made at the Oxford

meeting in 2003 (a decision I have to admit I supported at the time),

but I think it would be a really good idea to unchain TEI from DTDs

and XSDs as much as possible. It is not at all clear to me that the

effort and compromises needed to support even generating schemata in

DTDs and XSDs is worth it -- certainly the effort and compromises

needed to support customizations in those languages doesn't even come

close to being worth the benefit.

While I'm at it, there is another decision Council made at that

meeting which needs attention. We agreed then that the formal

definitions in the HTML version of P5 should be expressible in one 

or more of

   RelaxNG compact

   RelaxNG XML

   W3C Schema

   DTD

at user option. I think we should explicitly say that we will work on

releasing P5 with only RelaxNG compact declarations in the HTML

first, and then work on permitting expression of the latter 3 only if

there is some demand.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Dec 18 2005 - 16:54:59 EST

From sebastian.rahtz at oucs.ox.ac.uk  Sun Dec 18 17:31:39 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 18 Dec 2005 22:31:39 +0000
Subject: [tei-council] customization in P5
In-Reply-To: <17317.55977.731817.556417@emt.wwp.brown.edu>
Message-ID: <43A5E34B.1020609@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Sun, 18 Dec 2005 22:31:39 +0000

I don't agree with Syd's hard line; though I do find it sympathetic.

My reasons are simple:

 a) We have no mandate to undo the widely published and unchallenged

     declaration that we will support DTD and W3C Schema.

 b) As things stand, supporting DTD and W3C Schema is not an impossibly

     big burden (that's probably the most controversial part of this, of 

course;

     I know Syd would make interesting changes to content models if he 

could,

     but is prevented from doing so by DTD constraints)

 c) W3C Schema and DTD are, for good or bad, the constraints systems

     supported by a majority of tools. If we said we didn't care about them,

     we'd be isolating ourselves.

 d) If we dropped XSD and DTD, and gave ourselves the freedom to

     use Relax in an idiomatic way, we'd risk delaying P5 by another year.

     Is this the moment to throw things into flux again?

My feeling is that our direction is clear, to work on additional modules,

make increased use of the class system, write better tools, do I18N,

improve documentation etc. Rethinking decisions about constraint languages

is, to my mind, a low priority.

But I say again, my heart is with Syd on this; just not my head.....

Let me note that if we do only support ODD-generated schemas,

we have to drop the DTD and Relax NG parameterized schema fragments

entirely. We can't say "here they are, but you mustn't use them". It

plainly _is_ possible today to use P5 in the same way as we used to use

P4, with DTD subsets.

-- 
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 Dec 18 2005 - 17:32:04 EST

From Syd_Bauman at Brown.edu  Sun Dec 18 22:29:03 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 18 Dec 2005 22:29:03 -0500
Subject: [tei-council] customization in P5
In-Reply-To: <43A5E34B.1020609@oucs.ox.ac.uk>
Message-ID: <17318.10495.850620.656380@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sun, 18 Dec 2005 22:29:03 -0500

Sebastian, do you realize that we're talking about customization

here, not creation of schemas? Your arguments seem to be discussing

the latter, so I wanted to check that we are on the same page before

I responded at length. The question at hand is whether or not we

should support users writing customizations in:

* ODD	       (of course)

* RelaxNG      (I think so)

* DTD

* W3C Schema

Although your last paragraph does seem to be about customization, so

I'll address it now.

> Let me note that if we do only support ODD-generated schemas, we

> have to drop the DTD and Relax NG parameterized schema fragments

> entirely. We can't say "here they are, but you mustn't use them".

I'm not sure what you mean by the RelaxNG parameterized schema

fragments, but dropping the parameterization of the DTD fragments

would be a Good Thing. I think creating them has been a waste of your

valuable time, as will be maintaining them in the future.

> It plainly _is_ possible today to use P5 in the same way as we used

> to use P4, with DTD subsets.

Has anyone tested this? I will buy you a (cheap American) beer if it

does not turn out not to have problems, and there are not lots of

customizations that are trivial in ODD that are difficult in DTD.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sun Dec 18 2005 - 22:29:12 EST

From sebastian.rahtz at oucs.ox.ac.uk  Mon Dec 19 04:20:07 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 19 Dec 2005 09:20:07 +0000
Subject: [tei-council] customization in P5
In-Reply-To: <17318.10495.850620.656380@emt.wwp.brown.edu>
Message-ID: <43A67B47.5050304@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Mon, 19 Dec 2005 09:20:07 +0000

Syd Bauman wrote:

>Sebastian, do you realize that we're talking about customization

>here, not creation of schemas?

>

I am not sure I get what the difference is? isnt

every real life schema a customization?

>I'm not sure what you mean by the RelaxNG parameterized schema

>fragments,

>

i mean what ends up in Schema/ when you do "make schemas".

you've probably never used them....

> but dropping the parameterization of the DTD fragments

>would be a Good Thing. I think creating them has been a waste of your

>valuable time, as will be maintaining them in the future.

>  

>

arguably. but the work is done now.

and another point - *we* may not want to generate DTDs

from ODD, but its one of the claims of the ODD system. The

folks in the W3C using it *definitely* want (parameterized) DTDs!

>>It plainly _is_ possible today to use P5 in the same way as we used

>>to use P4, with DTD subsets.

>>    

>>

>

>Has anyone tested this? I will buy you a (cheap American) beer if it

>does not turn out not to have problems, and there are not lots of

>customizations that are trivial in ODD that are difficult in DTD.

>  

>

I didn't make a claim  for the latter!  but look at most

of the .xml files in Test in SF; they refer to the DTDs with

a DOCTYPE, as in (eg)

]>

thats a customization, in my book. add in  if you 

want,

and it'll work.

ebastian

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Mon Dec 19 2005 - 04:20:11 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Dec 20 03:34:32 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 20 Dec 2005 17:34:32 +0900
Subject: [tei-council] date, venue for next meeting
In-Reply-To: <43A5B8CC.5070600@oucs.ox.ac.uk>
Message-ID: 

From: Christian Wittern 

Date: Tue, 20 Dec 2005 17:34:32 +0900

Sebastian Rahtz ox.ac.uk> writes:

> for the sake of argument, can we look at the last week of May 2006 and

> do comparative costings for Tokyo and Washington? How about if people

> estimated travel costs for those two locations? I am happy to do

> correlate a

> table if desired.

>

> for example, for me Tokyo costs ??490 (more or less), and Washington

> about ??450.

If we do the meeting in Kyoto, which I would recommend, you should

look for flights into Kansai (sometimes called Osaka) Airport (KIX).

I could go to Washington for about 800 Euro, to Paris or London for

about 750 Euro. Kyoto would cost me noting.  These fares are based on

the Feb. prices, since the search engine I used does not give prices

for May (and most Airlines have not published the discounted prices

for May yet anyway).

>

> Oxford would cost me nothing, Paris about ??150

>

> What are chances of cheapish hotels in Kyoto? or Washington?

>

> On the whole, Paris likely to be cheapest :-}

I just did a quick search here,

http://domestic.hotel.travel.yahoo.co.jp/bin/ajsearch?tuki=12&hi=20&haku=1&pnum=1&rnum=12&ken=26&larea=&marea=&os=1&pmin=&pmax=2&via=top&x=42&y=12

which revealed that there seem to be quite some options for "cheapish"

hotels in Kyoto -- in this case, less than 10000 Yen (about 70 Euro)

per night.  You might have to put up with staff that only barely

understands, much less speaks English though. 

I would like to add that the decision should not be solely on economic

grounds.  As I said during the call, I would try to organize some

workshop with the meeting, which will allow me to pay some travel out

of the pockets of a grant.  I just had a word with the powers to be

and the prospect for this seems to be quite good.  The catch with the

workshop is, that we will need to publish a report with the papers

presented, but again that should not be a problem I hope. 

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 Dec 20 2005 - 03:35:07 EST

From mjd at hum.ku.dk  Tue Dec 20 04:17:41 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Tue, 20 Dec 2005 10:17:41 +0100
Subject: [tei-council] date, venue for next meeting
In-Reply-To: 
Message-ID: <43A7DA45.30256.3137F9@localhost>

From: M. J. Driscoll 

Date: Tue, 20 Dec 2005 10:17:41 +0100

A bit of checking on the internet suggests that it would be only slightly 

dearer for me to go to Kyoto (ca. 900 EUR) than to Washington (ca. 800 EUR).  

Paris or Oxford would only be about a quarter of that, probably even less the 

way things are going. On the other hand, I've been to Oxford, Paris and 

Washington, whereas I've never set foot in the land of the rising sun. Let's go 

for it.

Matthew

> Sebastian Rahtz ox.ac.uk> writes:

> 

> > for the sake of argument, can we look at the last week of May 2006 and

> > do comparative costings for Tokyo and Washington? How about if people

> > estimated travel costs for those two locations? I am happy to do

> > correlate a

> > table if desired.

> >

> > for example, for me Tokyo costs ??490 (more or less), and Washington

> > about ??450.

> 

> If we do the meeting in Kyoto, which I would recommend, you should

> look for flights into Kansai (sometimes called Osaka) Airport (KIX).

> 

> I could go to Washington for about 800 Euro, to Paris or London for

> about 750 Euro. Kyoto would cost me noting.  These fares are based on

> the Feb. prices, since the search engine I used does not give prices

> for May (and most Airlines have not published the discounted prices

> for May yet anyway).

> 

> >

> > Oxford would cost me nothing, Paris about ??150

> >

> > What are chances of cheapish hotels in Kyoto? or Washington?

> >

> > On the whole, Paris likely to be cheapest :-}

> 

> I just did a quick search here,

> 

> http://domestic.hotel.travel.yahoo.co.jp/bin/ajsearch?tuki=12&hi=20&haku=1&pnum=

> 1&rnum=12&ken=26&larea=&marea=&os=1&pmin=&pmax=2&via=top&x=42&y=12

> 

> which revealed that there seem to be quite some options for "cheapish"

> hotels in Kyoto -- in this case, less than 10000 Yen (about 70 Euro)

> per night.  You might have to put up with staff that only barely

> understands, much less speaks English though. 

> 

> I would like to add that the decision should not be solely on economic

> grounds.  As I said during the call, I would try to organize some

> workshop with the meeting, which will allow me to pay some travel out

> of the pockets of a grant.  I just had a word with the powers to be

> and the prospect for this seems to be quite good.  The catch with the

> workshop is, that we will need to publish a report with the papers

> presented, but again that should not be a problem I hope. 

> 

> 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

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Dec 20 2005 - 04:17:48 EST

From sschreib at umd.edu  Tue Dec 20 08:08:37 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Tue, 20 Dec 2005 08:08:37 -0500
Subject: [tei-council] date, venue for next meeting
In-Reply-To: 
Message-ID: <43A80255.3050902@umd.edu>

From: Susan Schreibman 

Date: Tue, 20 Dec 2005 08:08:37 -0500

Hotels near the university of Maryland range from $150 for the nicest 

hotel on campus, to around $80.00, for a Best Western type hotel.

It would cost me:

$1250 to get to Tokyo

$800.00 to get to Paris

$700 to get to Oxford

one caveat with Maryland, is that we'd need to sort out transportation 

to dinner. I could rent a van from the campus pool, but it would not be 

large enough for everybody, so we might need to rent a car in addition 

unless somebody was driving in. That might cost an additional $300.00 

(based on a rental for four days)

Another option would be have Council members stay in a hotel in DC, and 

take the metro out to U of Maryland for the meeting (c 50 minutes). In 

that case, hotels would cost on average $170 a night, with minimal 

transport costs.

usan

usan

Christian Wittern wrote:

>Sebastian Rahtz ox.ac.uk> writes:

>

>  

>

>>for the sake of argument, can we look at the last week of May 2006 and

>>do comparative costings for Tokyo and Washington? How about if people

>>estimated travel costs for those two locations? I am happy to do

>>correlate a

>>table if desired.

>>

>>for example, for me Tokyo costs ??490 (more or less), and Washington

>>about ??450.

>>    

>>

>

>If we do the meeting in Kyoto, which I would recommend, you should

>look for flights into Kansai (sometimes called Osaka) Airport (KIX).

>

>I could go to Washington for about 800 Euro, to Paris or London for

>about 750 Euro. Kyoto would cost me noting.  These fares are based on

>the Feb. prices, since the search engine I used does not give prices

>for May (and most Airlines have not published the discounted prices

>for May yet anyway).

>

>  

>

>>Oxford would cost me nothing, Paris about ??150

>>

>>What are chances of cheapish hotels in Kyoto? or Washington?

>>

>>On the whole, Paris likely to be cheapest :-}

>>    

>>

>

>I just did a quick search here,

>

>http://domestic.hotel.travel.yahoo.co.jp/bin/ajsearch?tuki=12&hi=20&haku=1&pnum=1&rnum=12&ken=26&larea=&marea=&os=1&pmin=&pmax=2&via=top&x=42&y=12

>

>which revealed that there seem to be quite some options for "cheapish"

>hotels in Kyoto -- in this case, less than 10000 Yen (about 70 Euro)

>per night.  You might have to put up with staff that only barely

>understands, much less speaks English though. 

>

>I would like to add that the decision should not be solely on economic

>grounds.  As I said during the call, I would try to organize some

>workshop with the meeting, which will allow me to pay some travel out

>of the pockets of a grant.  I just had a word with the powers to be

>and the prospect for this seems to be quite good.  The catch with the

>workshop is, that we will need to publish a report with the papers

>presented, but again that should not be a problem I hope. 

>

>All the best,

>

>Christian

>

>

>  

>

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742
Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib_at_umd.edu
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Dec 20 2005 - 08:08:48 EST

From Syd_Bauman at Brown.edu  Tue Dec 20 10:05:19 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Dec 2005 10:05:19 -0500
Subject: [tei-council] date, venue for next meeting
In-Reply-To: 
Message-ID: <17320.7599.127590.653431@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Tue, 20 Dec 2005 10:05:19 -0500

Round-trip travel for me looks like it would be

  dest.          USD               EUR

  -----          ---               ---

* Kyoto:    1200 to 1500  ~=  1000 to 1300

* Paris:     800          ~=   700        

* Oxford:    600 to  700  ~=   500 to  600

* Maryland:   54 to  133  ~=    45 to  112

Reminder to US travelers: SWA flies to BWI, but does not show up on

travel search engines like travelocity, orbitz, or on travel agency

tools, you have to look at them separately

(http://www.southwest.com/). It's worth looking, they are often not

much more than half the price of the competition. But be warned --

their system can't handle flights in May yet, so I had to ask for

March :-)

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Dec 20 2005 - 10:05:27 EST

From lou.burnard at computing-services.oxford.ac.uk  Tue Dec 20 10:36:17 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 20 Dec 2005 15:36:17 +0000
Subject: [tei-council] date, venue for next meeting
In-Reply-To: <17320.7599.127590.653431@emt.wwp.brown.edu>
Message-ID: <43A824F1.1080102@oucs.ox.ac.uk>

From: Lou Burnard 

Date: Tue, 20 Dec 2005 15:36:17 +0000

A rather cursory scan of lowest fares available on travelocity.com for 

the period May-Jun next year showed prices around $1000 for routes 

BWI-KIX and JFK-KIX. Also JFK-CDG at around $500. Both JFK-LHR and 

BOS-LHR are around $400

However, I think we agreed in thetelecon that our preference would be to 

go for Kyoto unles the costs turned out to be really silly. Which they 

don't seem to be so far.

Interestingly for Conall, I see that the best fare Auckland to 

Washington NZ air offers is just under 3000 NZD, while there is a direct 

flight to KIX for a paltry 2000 NZD. (But I don't know what the NZD is 

worth)

Syd Bauman wrote:

> Round-trip travel for me looks like it would be

> 

>   dest.          USD               EUR

>   -----          ---               ---

> * Kyoto:    1200 to 1500  ~=  1000 to 1300

> * Paris:     800          ~=   700        

> * Oxford:    600 to  700  ~=   500 to  600

> * Maryland:   54 to  133  ~=    45 to  112

> 

> Reminder to US travelers: SWA flies to BWI, but does not show up on

> travel search engines like travelocity, orbitz, or on travel agency

> tools, you have to look at them separately

> (http://www.southwest.com/). It's worth looking, they are often not

> much more than half the price of the competition. But be warned --

> their system can't handle flights in May yet, so I had to ask for

> March :-)

> 

> _______________________________________________

> 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 Dec 20 2005 - 10:34:19 EST

From Syd_Bauman at Brown.edu  Tue Dec 20 11:03:10 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Dec 2005 11:03:10 -0500
Subject: [tei-council] Facsimile work
In-Reply-To: 
Message-ID: <17320.11070.48915.632252@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Tue, 20 Dec 2005 11:03:10 -0500

> I have created a page on the wiki with some notes about the

> Facsimile work item (I've categorised it as a SIG on the Wiki).

> http://www.tei-c.org/wiki/index.php/SIG:Facsimile

Wow, quick work Conal. Excellent. Page itself looks good, if

(understandably at this point) a bit sketchy. One question or perhaps

nit-pick. From the introduction:

   "... about markup of facsimile images with correspondence to parts

    of the text."

I had thought of the effort more as about how one encodes the

correspondence of encoded text with an image of its source, and

perhaps about how one encodes metadata about that image. But the

actual markup of facsimile images seems to me to mean something

somewhat different, and out of scope.

Did you actually want this to be a SIG, or just stuck it there for

lack of a better place on the wiki? If the latter, let's put our

heads together with James and find or create a better place.

If you really want this to be a SIG, there is a relatively

unobtrusive procedure to follow. I just realized that the procedure

for SIG creation is described in a document to which only the Board

of Directors has access. I'm not sure why that is, and will write to

the Board about it soon. In the meantime, here's a quick summary:

* Send mail to SIG coordinator (currently Susan S., I think)

  requesting SIG. Request should include

  - brief description of SIG mission (can be 1 sentence, basically

    exists to prove you know "TEI" does not stand for "Tax Executives

    Institute" (see http://www.tei-c.org/Publicity/not_the_tei.htm if

    you haven't already))

  - name & e-mail addr of contact person

* SIG coordinator presents SIG to Council, who vote approval or

  disapproval Council has never disapproved, and I doubt they ever

  will -- this step exists mostly to ensure

  a) Council is kept in the loop, and

  b) we don't have 2 SIGs doing same thing who don't know about each

     other

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Dec 20 2005 - 11:03:18 EST

From James.Cummings at computing-services.oxford.ac.uk  Tue Dec 20 11:54:54 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 20 Dec 2005 16:54:54 +0000
Subject: [tei-council] Facsimile work
In-Reply-To: <[tei-council] Facsimile work>
Message-ID: <43A8375E.8010500@computing-services.oxford.ac.uk>

From: James Cummings 

Date: Tue, 20 Dec 2005 16:54:54 +0000

Syd Bauman wrote:

>> Did you actually want this to be a SIG, or just stuck it there for

>> lack of a better place on the wiki? If the latter, let's put our

>> heads together with James and find or create a better place.

I think I suggested Conal stick it under the SIG area for now, just until it was

decided whether it should become one or not.  That allows an already understood

structure, and participation from outside the council.  If Conal wants to follow

this up to make it an actual SIG then great, but if not we can easily create

somewhere else on the wiki to put such things.

Suggestions appreciated,

-James

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Dec 20 2005 - 11:54:56 EST

From Syd_Bauman at Brown.edu  Tue Dec 20 12:13:45 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Dec 2005 12:13:45 -0500
Subject: [tei-council] customization in P5
In-Reply-To: <43A67B47.5050304@oucs.ox.ac.uk>
Message-ID: <17320.15305.824106.237559@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Tue, 20 Dec 2005 12:13:45 -0500

> I am not sure I get what the difference is? isnt every real life

> schema a customization?

No, every real life schema is the result of a customization. The

language the customization is made in and the language the schema is

expressed in can be different. E.g. In order to create a new content

model for  I could write

i.e., RelaxNG, in my ODD customization file, and generate from it

DTD, XSD, or RNG. Or I might write

     ( biblStruct+ )

i.e., DTD, in my ODD customization file (yes, I know ODD does not

currently support this), and generate from it DTD, XSD, or RNG.

Or I might generate a customization in ODD (probably via Roma web

interface, but that's unimportant) that just does module selection,

generate DTDs from that, and then do something like

etc. in my extension files.

I am arguing that it is not worth supporting the writing of

customizations in other languages -- customizations should be written

in RelaxNG, preferably inside your ODD. The argument "but I know the

DTD language, not RelaxNG" just doesn't hold water for me. If you

know DTD, learning enough RelaxNG to mimic what you can do with a

DTD takes less than an hour.

> >I'm not sure what you mean by the RelaxNG parameterized schema

> >fragments,

> i mean what ends up in Schema/ when you do "make schemas". you've

> probably never used them....

I think I had used them at one point long ago, but even if I did, I

never knew what they were called :-)

> >but dropping the parameterization of the DTD fragments would be a

> >Good Thing. I think creating them has been a waste of your

> >valuable time, as will be maintaining them in the future.

> arguably. but the work is done now.

But maintenance is still a potential time drain, and one that not

only produces no discernable benefit that I can ascertain, arguably

it in fact has some moral drawbacks. DTDs are simply not as

expressive as even ODD-limited RelaxNG, and really should be avoided.

By permitting this sort of shenanigans, we are both enabling people

to not take the short amount of time needed to learn RelaxNG, and,

perhaps worse, allowing for potentially very complex situations to

arise when someone makes a DTD that is a flattened file based on DTD

extension files that are to be used in conjunction with a

Roma-generated DTD that itself has customizations (other than simple

module selection).

> and another point - *we* may not want to generate DTDs from ODD,

> but its one of the claims of the ODD system.

This discussion isn't about generating DTDs from ODD. (Although you

are correct, I'm not all that psyched about that, either.) It's about

using DTD as a customization language.

> The folks in the W3C using it *definitely* want (parameterized)

> DTDs!

Why do they want the result DTDs parameterized? Is Felix actually

writing DTD extensions to P5 Roma-generated DTDs?

> ... but look at most of the .xml files in Test in SF; they refer to

> the DTDs with a DOCTYPE, as in (eg)

>   

>     

>     

>     

>     ]>

>   

> thats a customization, in my book. add in  if

> you want, and it'll work.

Yes, quite right. But what if I want to add an updated version of the

WWP extensions, which have over 590 declarations? Has anyone tested

something of that scale? I haven't. And I'm not eager to. When the

WWP moves to P5 it is possible (although unlikely) that we will still

want to use DTDs for awhile longer. But I'll certainly write the

customization in RelaxNG in ODD, generating DTDs iff need be.

But of course, we're not really discussing the right question, here,

which isn't "should ODDs permit DTD and XSD customization", but

rather the question (IIRC) Lou initially raised, which was "should ST

discuss" these issues. In my current anti-DTD state of mind, I would

say no, even if it can be done, it should be explained in a separate

HOWTO, not in the Guidelines themselves. But that may be silly, and

bears some thought.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Dec 20 2005 - 12:13:53 EST

From sebastian.rahtz at oucs.ox.ac.uk  Tue Dec 20 15:50:37 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 20 Dec 2005 20:50:37 +0000
Subject: [tei-council] customization in P5
In-Reply-To: <17320.15305.824106.237559@emt.wwp.brown.edu>
Message-ID: <43A86E9D.9050104@oucs.ox.ac.uk>

From: Sebastian Rahtz 

Date: Tue, 20 Dec 2005 20:50:37 +0000

Syd Bauman wrote:

>I am arguing that it is not worth supporting the writing of

>customizations in other languages -- customizations should be written

>in RelaxNG, preferably inside your ODD

>

It depends what you mean by "support".  Do you mean

that we should not make DTD fragments?

>. DTDs are simply not as

>expressive as even ODD-limited RelaxNG, and really should be avoided.

>  

>

they do have one advantage - you can do customization

at the instance level. you might well say that this is

pure evil anyway....

>>The folks in the W3C using it *definitely* want (parameterized)

>>DTDs!

>>    

>>

>

>Why do they want the result DTDs parameterized? Is Felix actually

>writing DTD extensions to P5 Roma-generated DTDs?

>  

>

no. but he may include the ITS DTD, generated from ODDs, inside

another DTD, where he may need the parameterization.

Felix isn't writing TEI at all, remember. He's defining his own language.

>

>Yes, quite right. But what if I want to add an updated version of the

>WWP extensions, which have over 590 declarations? Has anyone tested

>something of that scale?

>

I don't see why it wouldnt work. Why should it be different

than it was before? Mind you, converting that extension

file would be no joke at all!

>rather the question (IIRC) Lou initially raised, which was "should ST

>discuss" these issues. In my current anti-DTD state of mind, I would

>say no, even if it can be done, it should be explained in a separate

>HOWTO, not in the Guidelines themselves. 

>  

>

I don't feel that radical. But equally if the section doesn't

get written, I won't call it a showstopper.

-- 
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 Dec 20 2005 - 15:51:07 EST

From Conal.Tuohy at vuw.ac.nz  Tue Dec 20 17:01:41 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Wed, 21 Dec 2005 11:01:41 +1300
Subject: [tei-council] Facsimile work
In-Reply-To: <[tei-council] Facsimile work>
Message-ID: 

From: Conal Tuohy 

Date: Wed, 21 Dec 2005 11:01:41 +1300

> > I have created a page on the wiki with some notes about the

> > Facsimile work item (I've categorised it as a SIG on the Wiki).

> > http://www.tei-c.org/wiki/index.php/SIG:Facsimile

Syd:

> Wow, quick work Conal. Excellent. Page itself looks good, if

> (understandably at this point) a bit sketchy. 

I've had some correspondence with Dot and I expect to put up some more

stuff this week based on that, BTW. I'll post to the list when I have.

I'm off to the beach for my holidays on Monday, away from internet,

mobile phones - even electricity - so I want to get in on the wiki

before then, in case anyone is interested to see it over the next couple

of weeks :-)

> One question or perhaps

> nit-pick. From the introduction:

> 

>    "... about markup of facsimile images with correspondence to parts

>     of the text."

> 

> I had thought of the effort more as about how one encodes the

> correspondence of encoded text with an image of its source, and

> perhaps about how one encodes metadata about that image. But the

> actual markup of facsimile images seems to me to mean something

> somewhat different, and out of scope.

I had originally thought that too. Actually my own agenda is to provide

a simple markup, as well as a slightly more complex markup which would

have linked image files to text, but Dot's work convinced me otherwise.

I now think that TEI markup should allow the links between images and

text to be more granular in that a link might just point to a region

within the image. Probably just using inline SVG, though, so it

shouldn't make the TEI markup too image-flavoured, though I think it

will mean that the links should be "stand-off".

> Did you actually want this to be a SIG, or just stuck it there for

> lack of a better place on the wiki? If the latter, let's put our

> heads together with James and find or create a better place.

It's as James says; I just stuck it there (on his suggestion) because it

was SIG-ish, and I hadn't really considered setting one up formally. Now

that you mention it though, I think it is a good idea, since it's not

just me.

> If you really want this to be a SIG, there is a relatively

> unobtrusive procedure to follow. I just realized that the procedure

> for SIG creation is described in a document to which only the Board

> of Directors has access. I'm not sure why that is, and will write to

> the Board about it soon. In the meantime, here's a quick summary:

> 

> * Send mail to SIG coordinator (currently Susan S., I think)

>   requesting SIG. Request should include

>   - brief description of SIG mission (can be 1 sentence, basically

>     exists to prove you know "TEI" does not stand for "Tax Executives

>     Institute" (see http://www.tei-c.org/Publicity/not_the_tei.htm if

>     you haven't already))

LOL! 

>   - name & e-mail addr of contact person

OK. I have done this. Hope Susan is the right person! If not she will no

doubt let me know.

> * SIG coordinator presents SIG to Council, who vote approval or

>   disapproval Council has never disapproved, and I doubt they ever

>   will -- this step exists mostly to ensure

>   a) Council is kept in the loop, and

>   b) we don't have 2 SIGs doing same thing who don't know about each

>      other

I don't imagine this will be any more controversial than usual :-)

C

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Tue Dec 20 2005 - 17:01:56 EST

From Syd_Bauman at Brown.edu  Thu Dec 22 09:44:36 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 22 Dec 2005 09:44:36 -0500
Subject: [tei-council] date, venue for next meeting
In-Reply-To: <43A824F1.1080102@oucs.ox.ac.uk>
Message-ID: <17322.48084.497106.253779@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Thu, 22 Dec 2005 09:44:36 -0500

Not sure why Lou got so much better rates on travelocity.com than I

got on expedia.com. Nonetheless, one corection to my post:

> >                 USD               EUR

> > * Maryland:   54 to  133  ~=    45 to  112

Should have been 108 to  133  ~=    91 to  112

(The "54" is a one-way fare. :-)

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Thu Dec 22 2005 - 09:44:44 EST

From Syd_Bauman at Brown.edu  Thu Dec 22 09:55:53 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 22 Dec 2005 09:55:53 -0500
Subject: [tei-council] Facsimile work
In-Reply-To: 
Message-ID: <17322.48761.582737.925590@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Thu, 22 Dec 2005 09:55:53 -0500

> I'm off to the beach for my holidays on Monday, ...

Oooohhh ...

> ... so I want to get in on the wiki before then, in case anyone is

> interested to see it over the next couple of weeks :-)

Good of you.

> I now think that TEI markup should allow the links between images

> and text to be more granular in that a link might just point to a

> region within the image. Probably just using inline SVG, though, so

> it shouldn't make the TEI markup too image-flavoured, though I

> think it will mean that the links should be "stand-off".

Whether such links are stand-off or in-line is an issue for

discussion, but the ability to point to a particular area of an image

is, IMHO, almost a requirement of TEI P5 markup. (After all, P4 could

do it, albeit only in a rudimentary manner:

http://www.tei-c.org/P4X/SA.html#SAXR1SP.)

The Stand-Off Markup, XLink and XPointer WG has a paper that, IIRC,

addresses this topic:

http://www.tei-c.org/Activities/SO/sow04.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 Thu Dec 22 2005 - 09:56:05 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Dec 29 21:35:44 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 30 Dec 2005 11:35:44 +0900
Subject: [tei-council] Thank you and good bye to outgoing Council members
Message-ID: 

From: Christian Wittern 

Date: Fri, 30 Dec 2005 11:35:44 +0900

Dear council members,

As the year approaches its end, all of Japan is busy cleaning shops

and poaches, washing cars and houses, wiping Buddhas and Bodhisattvas

and testing the temple gongs to make sure everything is ready for the

New Year.  Before I do the same to my office, and the network will go

down for maintenance as well, there are some last things that require

attention.

With the end of this year, the terms on the Council of Perry Willett

and Edward Vanhoutte will be fulfilled.  I would like to take this

opportunity to thank both of you for your time and devotion (even with

so many other committments requiring time and energy) to the TEI

Consortium, its members and the council.  I am sure we will be able

continue to count on your support and expertise as a member of the TEI

community.

I hope this message finds all of you in good spirits and I wish you

have a good beginning of the New Year 2006, whatever it might hold for

you and the TEI (some more releases of P5 for sure)

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 Thu Dec 29 2005 - 21:36:19 EST

From edward.vanhoutte at kantl.be  Fri Dec 30 04:01:33 2005
From: edward.vanhoutte at kantl.be (Edward Vanhoutte)
Date: Fri, 30 Dec 2005 10:01:33 +0100
Subject: [tei-council] Thank you and good bye to outgoing Council members
In-Reply-To: 
Message-ID: <43B4F76D.2090606@kantl.be>

From: Edward Vanhoutte 

Date: Fri, 30 Dec 2005 10:01:33 +0100

Dear Christian and council members,

thank you very much for your kind wishes. It was a privilege to serve on 

the Council although I do realize my input has been rather minimal.

Keep up the good work and never forget the average moderate technical 

skills of much of the TEI community (hence the wide succes of TEILite). 

Since this has always been one of my main concerns, I'm happy to report 

that funding has been secured from King's College London, in 

collaboration with The Centre for Scholarly Editing and Document Studies 

(CTB) of the Royal Academy of Dutch Language and Literature (Belgium) 

and University College London for the construction of a suite of online 

tutorials called "TEI by Example".  These online tutorials would provide 

a useful teaching and learning aid to those embarking on a markup 

project in TEI and will of course address P5. Ron Van den Branden will 

be the executive project officer and the project will be managed by 

Melissa Terras and myself. Development of the tutorials will begin at 

the CTB in January 2006. We hope to announce a first release in Autumn 

2006.

Best wishes and so long,

Edward

Christian Wittern wrote:

>Dear council members,

>

>As the year approaches its end, all of Japan is busy cleaning shops

>and poaches, washing cars and houses, wiping Buddhas and Bodhisattvas

>and testing the temple gongs to make sure everything is ready for the

>New Year.  Before I do the same to my office, and the network will go

>down for maintenance as well, there are some last things that require

>attention.

>

>With the end of this year, the terms on the Council of Perry Willett

>and Edward Vanhoutte will be fulfilled.  I would like to take this

>opportunity to thank both of you for your time and devotion (even with

>so many other committments requiring time and energy) to the TEI

>Consortium, its members and the council.  I am sure we will be able

>continue to count on your support and expertise as a member of the TEI

>community.

>

>I hope this message finds all of you in good spirits and I wish you

>have a good beginning of the New Year 2006, whatever it might hold for

>you and the TEI (some more releases of P5 for sure)

>

>All the best,

>

>Christian Wittern

>

>

>

>

>  

>

-- 
================
Edward Vanhoutte
Researcher
University of Antwerp
Associate Editor, Literary and Linguistic Computing
University of Antwerp - CDE
Dept. of Literature
Universiteitsplein 1
b-2610 Wilrijk
Belgium
edward dot vanhoutte at kantl dot be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm
_______________________________________________
tei-council mailing list
tei-council_at_lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 30 2005 - 04:03:30 EST

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Dec 30 18:54:24 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 31 Dec 2005 08:54:24 +0900
Subject: [tei-council] Thank you and good bye to outgoing Council members
In-Reply-To: 
Message-ID: 

From: Christian Wittern 

Date: Sat, 31 Dec 2005 08:54:24 +0900

Council members,

As Susan reminded me (thanks!!), Natasha Smith is also leaving the

Council -- I must have forgotten this in the hope that she would be

continuing, sorry for that.  It goes without saying, that my thanks

and best wishes extend to Natasha as well.  Thank you for your time

and effort and please continue to support the TEI!

All the best,

Christian

Christian Wittern zinbun.kyoto-u.ac.jp> writes:

> Dear council members,

>

> As the year approaches its end, all of Japan is busy cleaning shops

> and poaches, washing cars and houses, wiping Buddhas and Bodhisattvas

> and testing the temple gongs to make sure everything is ready for the

> New Year.  Before I do the same to my office, and the network will go

> down for maintenance as well, there are some last things that require

> attention.

>

> With the end of this year, the terms on the Council of Perry Willett

> and Edward Vanhoutte will be fulfilled.  I would like to take this

> opportunity to thank both of you for your time and devotion (even with

> so many other committments requiring time and energy) to the TEI

> Consortium, its members and the council.  I am sure we will be able

> continue to count on your support and expertise as a member of the TEI

> community.

>

> I hope this message finds all of you in good spirits and I wish you

> have a good beginning of the New Year 2006, whatever it might hold for

> you and the TEI (some more releases of P5 for sure)

>

> 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

-- 
 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 Dec 30 2005 - 18:54:27 EST

From Syd_Bauman at Brown.edu  Fri Dec 30 23:05:05 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 30 Dec 2005 23:05:05 -0500
Subject: [tei-council] summary of SO WG outputs
Message-ID: <17334.881.28807.793922@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Fri, 30 Dec 2005 23:05:05 -0500

Action SB by 2005-12-31: Circulate summary report on SO workgroup

                         outputs to date

---------

The TEI Work-group on Stand-Off Markup, XLink and XPointer ("SO") was

conceived and authorized by Council at its January 2002 meeting in

London, and actually formed and charged the following summer. The

group, chaired by David Durand, has never had a face-to-face meeting,

met by conference call an average of ~ twice per month during its

first 1.5 years of existence, but has not met since then. The group

has produced several papers, some of which supersede others. Those

that have been superseded are listed last.

* SO W 02 "summary of technical rationale for decisions on XPointer

  and stand off markup"

  http://www.tei-c.org/Activities/SO/sow02.xml?style=printable

  Last updated 19 Nov 03. 

  White paper on issues, particularly ID v. XPointer.

* SO W 04 "Notes on Media formats and XPointer"

  http://www.tei-c.org/Activities/SO/sow04.xml?style=printable

  Last updated Fri, 17 Oct 03.

  A useful paper by Chris Caton that basically recommends the use of

  SVG and SMIL in TEI documents. I am sorry to report that this paper

  has been almost completely ignored by Council, as I think the

  approaches it recommends should at least be seriously considered and

  debated.

  Note: when Chris says that entities are depreciated, he means

  attributes of type ENTITY, not entity references.

* SO W 05 "Corpus Applications"

  http://www.tei-c.org/Activities/SO/sow05.xml?style=printable

  Last updated Thu, 06 Nov 03.

  A somewhat incomplete paper that requires technical updating to

  match current recommendations, that nonetheless deserves attention

  as it offers advice on markup up various linguistic properties of

  texts, particularly in the context of large corpora. The original

  propose of this paper was to demonstrate the use of various

  techniques described in the chapter on linking, segmentation, and

  alignment, but I suspect a lot of the advice it gives should be in

  the chapter on Language Corpora.

* SO W 06 "Stand-off Markup"

  http://www.tei-c.org/Activities/SO/sow06.xml?style=printable

  Last updated Tue, 06 May 03.

  This is Fabio's paper on XInclude, which DD and I are currently in

  the process of re-working and inserting into the chapter on linking,

  segmentation, and alignment. (I *think* this is probably the paper

  Lou was referring to on the conference call, and I was just confused

  that he was referring to something newer -- Lou, if Fabio has done

  something since that I'm unaware of, please let me know.)

* SO W 07 "Graphs"

  http://www.tei-c.org/Activities/SO/sow07.xml?style=printable

  Last updated Fri, 02 May 03.

  Also by Chris Caton, this paper analyzes how RDF might be used to

  encode graphs (and therefore trees) instead of TEI-specific markup.

  He basically encodes the example in P4 using mostly RDF. I just

  noticed, however, that the colors in the examples are no longer

  coming through.

* SO W 09 "Basic working decisions on pointing and linking"

  http://www.tei-c.org/Activities/SO/sow09.xml?style=printable

  Last updated Sat, 02 Oct 04

  On or about its conference call of 2004-03-29, Council requested

  that the WG (i.e., DD) produce a summary document of its decisions

  and recommendations so far, particularly in the area of XML's

  ID/IDREF mechanism and W3C's XPointer Framework. This is that

  summary document.

* SO W 01 "Differences Between XPointer and the TEI Extended Pointer

           Mechanism"

  This document has been superseded by SO W 02

* SO W 03 "Linking, Segmentation, and Alignment"

  This document has been incorporated into P5.

* SO W 08 "Canonical References"

  This document has been incorporated into P5.

In addition to the above papers, the WG has produced a proof-of-

concept Perl program that converts TEI P4 extended pointer syntax to

XPaths. I have not been able to run it for awhile, though, as the

underlying library it depends on for parsing has changed. It is at

http://www.tei-c.org/Activities/SO/exp-conv.tgz.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Fri Dec 30 2005 - 23:05:15 EST

From Syd_Bauman at Brown.edu  Sat Dec 31 13:03:53 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 31 Dec 2005 13:03:53 -0500
Subject: [tei-council] class struggle procedure suggestion
Message-ID: <17334.51209.622738.261571@emt.wwp.brown.edu>

From: Syd Bauman 

Date: Sat, 31 Dec 2005 13:03:53 -0500

Action SB by 2005-12-31: organize a proposal on how best to prosecute

                         the class struggle

Personally, I like the idea of working on this via conference call

with each participant looking at the same information on his or her

screen. However, the various technical solutions for that (VNC,

Marratech) seem at first glance like significant overkill.

Thus, I'm going to suggest we try conference calls with a deliberate

plan to try to stay on the same page.

1. ED W 84 needs to be updated to reflect the current P5 

2. ED W 84 needs to be updated so that each record is easily uniquely

   identified [1]

3. For each set of modules listed below, the Class Crew holds a

   conference call going through the module as we did for header,

   core, etc. in Oxford. We should set aside 2 hrs for each call,

   hoping to be done in half that.

4. Notes from conference call should be posted very rapidly, ideally

   less than 24 hrs later.

5. Brief discussion period among Class Crew to affirm notes and hammer

   out any details (by default 1 week)

6. Editors implement agreed changes, post about any problems

   encountered (approximately 1 week)

7. ED W 84 is updated to reflect this set of changes

I don't see any reason not to start before the next Council call.

(Have we decided on the date for that call? Fri 24 Feb was

suggested.) I am going to suggest Thu 26 Jan at 14:00Z for the first

Class Crew conference call (C4 for short, although we hope not to be

as explosive :-).

Module Sets

------ ----

* gaiji, nets, figures

* transcr, textcrit, namesdates

* analysis, corpus, spoken (and personography, if it exists by then)

* iso-fs, declarefs

* drama, tagdocs, linking

* msdescription (perhaps MD & DB should be included in con call)

* dictionaries

There is almost nothing to be done for the following modules, so they

have not been included in the above sets:

* verse (only element empty)

* certainty (all elements empty, already a member of a model class)

* concurrent-decl (scheduled for execution by firing squad)

Notes

-----

[1] My personal suggestion would be to add an incrementing record

    number to each cell in the "module" column, but the details don't

    really matter. The point is to make it so that in a web browser,

    which typically has very limited searching capabilities, every

    participant can find the record in question ASAP -- if someone

    says "look at person", the others need to search through at least

    every occurrence of "person" in content models, etc., if not every

    occurrence of "personPart", "personGrp", etc.; if someone says

    "look at record 0283", everyone else can be on the same record v.

    fast.

_______________________________________________

tei-council mailing list

tei-council_at_lists.village.Virginia.EDU

http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

Received on Sat Dec 31 2005 - 13:04:03 EST

From lou.burnard at computing-services.oxford.ac.uk  Wed Jan  5 15:49:45 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 05 Jan 2005 20:49:45 +0000
Subject: [tei-council] Moving P5 to Sourceforge
Message-ID: <41DC52E9.3020102@computing-services.oxford.ac.uk>

At the council meeting in May 2004, it was agreed that the development
of TEI P5 should be done in public, using the version control system
provided by Sourceforge. The proviso was that the existing source should
first be cleaned up, and any large-scale changes made before the move.
These changes have now been made, and it is now time to consider exactly
how we will carry out the move to Sourceforge.

P5 is currently managed  at Oxford using a content management system
called Perforce. Moving the current data across to the CVS version
control system used on sourceforge is easy enough, but preserving all
the associated revision information is more problematic.  We identify
four possibilities:

1. convert the entire change history, including deletions, renames,
branching etc
2. convert recent change history of current files only
3. forget the history and import only the current state
4. import a snapshot and preserve the history externally

A full conversion (1) is technically possible, but forbiddingly
difficult to get right; it also has the disadvantage that it shows
everyone earlier messy states, and artefacts we wanted to remove. A
partial conversion (2) is less difficult, but would probably be regarded
as of purely symbolic interest. Losing history altogether (3) seems
entirely wrong, so we propose to attempt (4) the last method. This
involves the following steps:

1. Check and housekeep the current P5 tree to ensure it is usable
freestanding and complete; [to be complete by Jan 10]

2. Freeze current Perforce system, disallowing any further writes [to be
done January 14].  All information (including history) will remain
readable by the editors and assistants as now, for as long as our
perforce licence holds out.

3. Take a snapshot of the P5 tree and import it into CVS on Sourceforge
[to be done on Jan 14th]

4. Locate all the changes in Perforce which relate to the P5 tree
(about 400) and extract the details of each change to a text file; place
these files on the TEI web site with an HTML index file to allow
interested parties to reconstruct their history. [to be completed by Jan
31st]

5. On the TEI web site, document the tools and procedures needed to make
use of the P5 sources in CVS [to be completed by Jan 31st]

6. Make all future changes to P5 using CVS

Lou Burnard
Sebastian Rahtz
Syd Bauman

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Jan  6 08:00:05 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 06 Jan 2005 22:00:05 +0900
Subject: [tei-council] Moving P5 to Sourceforge
In-Reply-To: <41DC52E9.3020102@computing-services.oxford.ac.uk>
	(Lou Burnard's message of "Wed, 05 Jan 2005 20:49:45 +0000")
References: <41DC52E9.3020102@computing-services.oxford.ac.uk>
Message-ID: 

Lou Burnard  writes:

>
> 1. convert the entire change history, including deletions, renames,
> branching etc

Is there a chance to convert this to ChangeLog files that could be
held in that directory?  If I am not mistaken, CVS does allow this,
but I do not know about Perforce.  (I am thinking of something like
C-x v l in Emacs on a CVS managed file).

[1..5 deleted]
>
> 6. Make all future changes to P5 using CVS
>

This looks plausible enough to me.

C. Wittern

-- 

 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From sebastian.rahtz at computing-services.oxford.ac.uk  Thu Jan  6 08:55:50 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Thu, 06 Jan 2005 13:55:50 +0000
Subject: [tei-council] Moving P5 to Sourceforge
In-Reply-To: 
References: <41DC52E9.3020102@computing-services.oxford.ac.uk>

Message-ID: <41DD4366.3030006@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>
>Is there a chance to convert this to ChangeLog files that could be
>held in that directory?  If I am not mistaken, CVS does allow this,
>but I do not know about Perforce.  (I am thinking of something like
>C-x v l in Emacs on a CVS managed file).
>  
>
It is not directly possible. It could be done by munging the output from
"p4 describe". The default is seen in the example below. If you think it 
is worthwhile,
we could probably take the part before the detailed changes, and put all 
these together in
a ChangeLog.

Sebastian

Change 44653 by lou at janus on 2005/01/05 11:11:42

Affected files ...

... //TEI/P5/Source/TE/te.odd#11 edit

Differences ...

==== //TEI/P5/Source/TE/te.odd#11 (ktext) ====

8c8
< $Date: 2005/01/04 $
---
 > $Date: 2005/01/05 $
17,20c17,24
< applications in Terminology ? Machine-readable terminology
< intyerchange format (MARTIF) ? negotiated interchange and the
< family of emerging standards comprising ISO CD 12620  Computer
< applications in terminology ? Data categories.
---
 > 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

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jan  7 04:08:26 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 07 Jan 2005 09:08:26 +0000
Subject: [tei-council] licensing on XSLT stylesheets
Message-ID: <41DE518A.6080304@computing-services.oxford.ac.uk>

You'll recall I asked late last year about this, and got a fair amount 
of unanimity that
GPL was desirable. However, the oXygen folks argue pretty convincingly 
that the LGPL
would be better for this sort of software. It would afford the 
protection we want,
and not produce problems for people like oXygen.

I therefore propose to make a new release under an LGPL. Does anyone object?

Sebastian

From Syd_Bauman at Brown.edu  Fri Jan  7 11:37:39 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 7 Jan 2005 11:37:39 -0500
Subject: [tei-council] licensing on XSLT stylesheets
In-Reply-To: <41DE518A.6080304@computing-services.oxford.ac.uk>
References: <41DE518A.6080304@computing-services.oxford.ac.uk>
Message-ID: <16862.47827.669631.7801@emt.wwp.brown.edu>

> You'll recall I asked late last year about this, and got a fair
> amount of unanimity that GPL was desirable. However, the oXygen
> folks argue pretty convincingly that the LGPL would be better for
> this sort of software. It would afford the protection we want, and
> not produce problems for people like oXygen.
> 
> I therefore propose to make a new release under an LGPL. Does
> anyone object?

So the stylesheets are a library being linked with the application,
eh? Well, if that's the case, the open source fanatic part of me
wants to say "no", we should stick up for open source and stick with
GPL. But the text encoding TEIer part of me says that anything we can
do to spread TEI is good, even if it means shaking hands with
(although not getting into bed with) proprietary software. And the
practical, reasonable side of me realizes that

a) TEI needs oXygen more than oXygen needs TEI. oXygen is not about
   to become open source. Thus, if we stay with GPL, oXygen will just
   drop the stylesheets, and TEI users will lose out.

b) The amount of benefit the open source community (primarily jEdit,
   here) gains by having access to TEI stylesheets when their
   proprietary competitor (oXygen) does not have such access is, I'm
   sorry to say, really very slight.

So, somewhat grudgingly, I'm inclined to say we should switch to
LGPL.

P.S.
----
The difference, BTW, is that GPL requires that any derivative
software, even if large parts of the resulting program are *not*
based on GPLed code, must be under the GPL itself. LGPL permits
derivative software to be under a proprietary license in some
circumstances.

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jan  7 12:08:55 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 07 Jan 2005 17:08:55 +0000
Subject: [tei-board] Re: [tei-council] licensing on XSLT stylesheets
In-Reply-To: <16862.47827.669631.7801@emt.wwp.brown.edu>
References: <41DE518A.6080304@computing-services.oxford.ac.uk>
	<16862.47827.669631.7801@emt.wwp.brown.edu>
Message-ID: <41DEC227.3060404@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>So the stylesheets are a library being linked with the application,
>eh?
>
I think this is actually quite a good description of them, yes.

>So, somewhat grudgingly, I'm inclined to say we should switch to
>LGPL.
>  
>
it does seem pragmatic

I did it

Sebastian

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jan 14 15:56:29 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 14 Jan 2005 20:56:29 +0000
Subject: [tei-council] council annual meeting
Message-ID: <41E831FD.6080202@computing-services.oxford.ac.uk>

So, what is the plan for this year's meeting? does anyone feel a 
consensus has been reached yet?

-- 
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 nsmith at email.unc.edu  Mon Jan 17 10:08:12 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Mon, 17 Jan 2005 10:08:12 -0500
Subject: [tei-council] council annual meeting
References: <41E831FD.6080202@computing-services.oxford.ac.uk>
Message-ID: <007b01c4fca6$5ce92350$6501a8c0@lib.unc.edu>

I would like to second Sebastian's question - any decision reached? I need
to make a few commitments for march-may and would like to avoid scheduling
conflicts...
best, ns

----- Original Message ----- 
From: "Sebastian Rahtz" 
To: "TEICouncil" 
Sent: Friday, January 14, 2005 3:56 PM
Subject: [tei-council] council annual meeting

> So, what is the plan for this year's meeting? does anyone feel a
> consensus has been reached yet?
>
> -- 
> 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 wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Jan 18 01:15:32 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 18 Jan 2005 15:15:32 +0900
Subject: [tei-council] council annual meeting
In-Reply-To: <007b01c4fca6$5ce92350$6501a8c0@lib.unc.edu> (Natasha Smith's
	message of "Mon, 17 Jan 2005 10:08:12 -0500")
References: <41E831FD.6080202@computing-services.oxford.ac.uk>
	<007b01c4fca6$5ce92350$6501a8c0@lib.unc.edu>
Message-ID: 

Sorry, Sebastian's message seems to have fallen in some bit-bucket,
maybe due to some problems I had with my machine here:-(

"Natasha Smith"  writes:

> I would like to second Sebastian's question - any decision reached? I need
> to make a few commitments for march-may and would like to avoid scheduling
> conflicts...

OK, so let's try it again.  We had so far reached consensus that end
of March or end of April would be a sensible target for a meeting,
with a location in Europe, where possible locations are Copenhagen,
France (Paris or Nancy) and Oxford.  Matthew, James and Laurent --
could you please provide us with an estimate of how much we'd have to
budget for housing in the respective locations (assuming that travel
will make not much of a difference for these locations and would be
difficult to estimate anyway).

The timing of the meeting depends also on what we need to get done
before we meet and on what schedule this could be achieved, especially
whether we will have a META meeting to discuss the tei-class system.
Sebastian, Lou - any news on this?  If no such meeting is planned, I'd
suggest that we meet end of March before Sebastian leaves.

There is a document called "Current State of P5" at
http://www.tei-c.org/Drafts/edw18.html, which has some milestones
towards the end, but it needs to be updated.  Syd, Lou, could you
please look into this and update the document as needed (or is there
maybe a better way to do the scheduling at SF?) It would be good if we
could find out what needs to be done for P5 and by which steps we will
get there.

We will hold our next telephone conference on Jan 31, at 1300
UTC.  Please send me any agenda items that needs to be included.
Also, please look at the meeting notes at
http://www.tei-c.org/Council/tcm14.html which contain action items on
JF and SR concerning style-sheets [I see that SR just uploaded
stylesheets, but none of the SF mirrors seem to have them right now]
and on PW concerning biblItem.  There is also an action on all to look
at the SF tracker and post comments.  [I just tried to do so, but SF
is in read-only mode -- looks like I am not the only one with hardware
problems at the moment]

All the best,

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  Tue Jan 18 04:46:13 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Tue, 18 Jan 2005 10:46:13 +0100
Subject: [tei-council] council annual meeting
In-Reply-To: 
References: <007b01c4fca6$5ce92350$6501a8c0@lib.unc.edu> (Natasha
	Smith's	message of "Mon, 17 Jan 2005 10:08:12 -0500")
Message-ID: <41ECE8F5.11274.848470@localhost>

Copenhagen is one of the more expensive cities in Europe, 
I'm afraid, and a recent rise in the cost of public 
transport has not helped the matter; I believe we are now 
second only to Oslo. Relative to the general cost of 
living, however, hotels are not fantastically expensive, 
and certainly cheaper than, say, Chicago; one night in a 
decent hotel will set you back about $100 at the current 
rate of exchange (the dollar may of course be worth even 
less by April). We have complete facilities for meetings 
and so on here at the Institute, which would not cost 
anything, so the only real problem is accommodation, and of 
course, meals, which can, again, be rather expensive (but 
generally worth it, especially if someone else is paying). 
There's always shawarma, and of course the ubiquitous hot-
dog stands, for those willing to eat such things.

Getting here is easy enough. In fact, Copenhagen is quite 
centrally located, being almost exactly midway between 
Kyoto and San Francisco, going the one way, and Troms? and 
Rome going the other. Direct flight are available from most 
European cites, and often at absurdly low prices with Ryan 
Air, Virgin, Snowflake etc. (my son once flew from Stansted 
for 10p + taxes). There are direct flights from the bigger 
American cities with SAS or, with a brief stop-over in 
Iceland, with Icelandair, who are usually slightly cheaper. 
Those of you who live in the sticks would probably have had 
to change anyway.

As far as dates are concerned I'm easy. Apart from five 
days in the middle of April (13th-17th) I'm here.

And as a final enticement, this year marks the 200th 
anniversary of the birth of H. C. (probably know to you as 
Hans Christian) Andersen, the ugly duckling man, so what 
better time to visit "Wonderful Copenhagen"?

Matthew

From lou.burnard at computing-services.oxford.ac.uk  Sun Jan 23 11:22:31 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 23 Jan 2005 16:22:31 +0000
Subject: [tei-council] TARGET/s and IDREFS attributes
In-Reply-To: <16879.48416.192086.883455@emt.wwp.brown.edu>
References: <41E9953A.2030105@computing-services.oxford.ac.uk>
	<16877.23875.953031.69580@emt.wwp.brown.edu>
	<41ED6E83.5080508@computing-services.oxford.ac.uk>
	<16879.48416.192086.883455@emt.wwp.brown.edu>
Message-ID: <41F3CF47.8060701@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>>I wondered about that.It seems very confusing to have the same name
>>sometimes mean one thing, sometimes several things, and sometimes
>>several things which are to be treated as one thing. Don't you
>>think it might be worth trying to rationalize them? (the old
>>target/targets was a half hearted step in that direction)
> 
> 
> Yes, I think it is a worthy endeavor. The problem is, if my
> recollection serves, that what we need are three categories:
> 
> * only 1 URI           currently target= of gloss, term, specGrpRef,
>                        and tei.formPointers
> * 1 or more URIs       currently target= of catRef, note, ptr, ref
> * at least 2 URIs      currently targets= of alt, join, link
> 
> Worth toying around with what other names we might use.
> 
> 

There's another distinction: when the target is 2 or more URIs, 
sometimes (as in link,join) the semantics of the element make clear 
whether or not resolution of the link should produce a single item; 
other times (as in note, ptr) it is not clear at all.
In P4 (and I see it has survived unchanged in your revision for P5) 
there is an example like this for a table of contents
 How does one decide whether this means "pages 
213-245" or "pages 213 and 245"? Most of the examples in CO and 
elsewhere suggest that the latter is the more likely intention; yet 
there is an explicit statement in SA to the contrary! ("when the target 
attribute specifies more than one element, the indicated elements are 
intended to be combined or aggregated in some way..."). Well,  I haven't 
checked all the examples where URIlists have been used but I'll bet most 
of them will fall foul of this usage rule.

I suggest the following:

1. target should *always* be a single URI
2. targets should *always* be a URIlist
3. Current cases where target takes a list of URIs should all be checked 
and fixed as follows:
-- if the URIlist components are discrete (i.e. not to be aggregated), 
they should be represented by multiple s
-- if the said components *are* to be aggregated, this should be done by 
means of an intermediate . So

 (discrete) becomes  (could be grouped into a  if you like, or in 
some cases follow the suggestion for  below)

 (indiscrete) becomes

Mutatis mutandis, I think this applies also to .

 should probably be changed so that it has + content; this 
  might also be a sensible pattern for other things like the 
IDREFS-valued attributes in FS chapter to follow, except that I think 
that horse has already bolted.

Did the work group ever seriously consider getting rid of all IDREFS 
values and replacing them with child elements? It would be a pretty neat 
solution in most real-life cases I can think of.

I'm CCing this to the Council in case anyone there has an opinion.

Lou

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Jan 23 21:33:10 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 24 Jan 2005 11:33:10 +0900
Subject: [tei-council] Preparation for next conference call
Message-ID: 

Dear Council members,

In an attempt to make the conference calls functioning a bit more
smoothly, I would like to ask work group chairs or contact persons to
send us a few lines as an update on their current work. Please send us
the reports to this list by Thursday Jan. 27.

For the currently active WG's, I would like to ask
Sebastian to report for META,
Syd to report for SO,
Laurent to report for FS,
Matthew to report for MS,
Julia to report for PB,
Perry to give us an update on the biblItem activity

(Apologies if I forgot something, I am writing this from the top of my
head in a Beijing hotel room.)

Also, if there are other things to report (, SF, etc), please
do write up a few lines and send it to the list. 

I am still collecting agenda items, so please send me what you think
needs to be discussed.

I also hope that we can decide on time and place for the meeting at
the call.  Currently it looks (to me) like a meeting at Copenhagen
late April would be most doable.  If that is not possible for anybody,
please come up with a new suggestion now!

Now, off to the airport..

All the best,

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  Sun Jan 23 22:06:38 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 23 Jan 2005 22:06:38 -0500
Subject: [tei-council] TARGET/s and IDREFS attributes
In-Reply-To: <41F3CF47.8060701@computing-services.oxford.ac.uk>
References: <41E9953A.2030105@computing-services.oxford.ac.uk>
	<16877.23875.953031.69580@emt.wwp.brown.edu>
	<41ED6E83.5080508@computing-services.oxford.ac.uk>
	<16879.48416.192086.883455@emt.wwp.brown.edu>
	<41F3CF47.8060701@computing-services.oxford.ac.uk>
Message-ID: <16884.26174.703865.696281@emt.wwp.brown.edu>

> > Yes, I think it is a worthy endeavor. The problem is, if my
> > recollection serves, that what we need are three categories:
> > 
> > * only 1 URI           currently target= of gloss, term, specGrpRef,
> >                        and tei.formPointers
> > * 1 or more URIs       currently target= of catRef, note, ptr, ref
> > * at least 2 URIs      currently targets= of alt, join, link
> > 
> > Worth toying around with what other names we might use.
> 
> There's another distinction: when the target is 2 or more URIs, 
> sometimes (as in link,join) the semantics of the element make clear 
> whether or not resolution of the link should produce a single item; 
> other times (as in note, ptr) it is not clear at all.

I'll talk about the issue itself in a minute, but first allow me to
point out that distinction you are making divides the elements almost
exactly as they are currently divided. , , and  fall
into the category where the semantics are quite clear (for  the
targets are alternatives to one another; for  the targets are
associated by whatever semantic is associated with the type= of the
, and for  the targets are to be thought of as a single
element) and lo and behold, the name of their attribute is targets=.
The semantics of multiple pointers are not as clear for ,
, and , and lo and behold the name of their attribute is
target=. The only outlier is , for which the semantics of
multiple values are clearly defined (the text falls into more than
one classification category), but the value is target=.

> In P4 (and I see it has survived unchanged in your revision for
> P5) there is an example like this for a table of contents  target="p213 p245"/> 

Could you point me to the specific example you have in mind? I
can't seem to find it.

> How does one decide whether this means "pages 213-245" or "pages
> 213 and 245"? Most of the examples in CO and elsewhere suggest
> that the latter is the more likely intention; 

My recollection is that the Guidelines never explicitly say that
generic target="#A #B" means "A & B" as opposed to "A through B,
inclusive", or vice-versa; but as you point out quite a few examples
demonstrate the "A & B" usage.

> yet there is an explicit statement in SA to the contrary! ("when
> the target attribute specifies more than one element, the
> indicated elements are intended to be combined or aggregated in
> some way...").

I do not understand how saying "A and B should be combined or
aggregated in some way" at all implies that A *through* B should be
combined or aggregated (although it does leave that possibility open,
a loophole that perhaps we should close, perhaps not).

> Well, I haven't checked all the examples where URIlists have been
> used but I'll bet most of them will fall foul of this usage rule.

I'm not sure I understand -- you think most examples of attributes
which are declared as URIlist and have multiple URIs in their value
will be ambiguous as to whether "A & B" or "A through B" is intended?
I really doubt that, but if there's any real danger someone (I can
already hear myself getting elected) should go through 'em and make
it clear which is intended. Are there any cases for which "A through
B" would be the intended semantic?

> I suggest the following:
> 1. target should *always* be a single URI
> 2. targets should *always* be a URIlist
> 3. Current cases where target takes a list of URIs should all be checked 
>    and fixed as follows:
>    - if the URIlist components are discrete (i.e. not to be aggregated), 
>      they should be represented by multiple s
>    - if the said components *are* to be aggregated, this should be done by 
>      means of an intermediate .

By "case" do you mean an attribute & element combination or an
individual example in the Guidelines?

Seems to me all  and s will fall into the discrete
category. I like the idea of removing target= from  and
giving it  children:

  element catRef {
     tei.global.attributes,
     catRef.attributes.scheme,
     ptr+
  }

But  already has content, and a  may well already be a
child of , for good reason:
  For an introduction,
    see . 
Where do you suggest the new -as-target= go?

The "aggregated points to " idea only makes sense when the
aggregation is not some generic aggregation, but is specifically an
aggregation of XML elements for the purpose of creating a single
virtual element. In which case, I very much like this idea, as it's
already what I would recommend.

A counter proposal:
* , , , and tei.formPointers (,
  , , ) get target= declared as URI (i.e., no change)
* , , , and  get targets= declared as URIlist
  (i.e., change their target= to tagets=)
* what used to be targets= of , , and  gets a new
  name(s).

The new name for , , and  might be one name so that
they can all be a member of a class, or it might be a different name
for each element so it can make sense semanticly. E.g.

(I don't really like those -- hope someone can come up w/ better names)

> Did the work group ever seriously consider getting rid of all
> IDREFS values and replacing them with child elements? It would be
> a pretty neat solution in most real-life cases I can think of.

The SO WG considered it, you & I have considered it, and IIRC,
Council has even considered it. The conversation stopper has always
been the same. I ask the question: "OK, what are we going to do with
the fact that *every* TEI element carries at least 5 attributes
declared as IDREFS (corresp=, synch=, exclude=, select=, and ana=),
and a whole bunch more carry decls=?" No one has ever come up with
any suggestion for how to handle all those attributes as children
(not to mention domains= of , , & ; and
who=, which like target= has several instantiations that are URI and
several that are URIlist) at all, let alone how to handle them
elegantly.

There's probably more to say on this topic, but that's enough for
now.

From James.Cummings at computing-services.oxford.ac.uk  Tue Jan 25 11:56:08 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 25 Jan 2005 16:56:08 +0000
Subject: [tei-council] [Fwd: RE: Query: Meeting Rooms/Accomodation etc.]
Message-ID: <41F67A28.9060208@computing-services.oxford.ac.uk>

Dear Council Members,

Rewley House finally got back to me.  Find below the rates for using 
their meeting rooms and accommodation.  Unless Lou/Sebastian have other 
Oxford locations they want to suggest, then this is the proposed 
location should it be held in Oxford.  We could, of course, use
OUCS meeting rooms which would save a little bit.

-James

-------- Original Message --------
Subject: RE: Query: Meeting Rooms/Accommodation etc.
Date: Tue, 25 Jan 2005 16:39:23 -0000
From: Moore, Claire 
To: 'James.Cummings at computing-services.oxford.ac.uk'	 

Dear James

Many thanks for your email. Not really sure what happened to your last
email, as I do not seem to have received it! Any way!! I am pleased to
advise our rates are as follows:

Small meeting room which can accommodate up to 12 people  ?50.00 per Half
day

?90.00 per full day

Larger meeting room which can accommodate up to 20 people ?90.00 per half
day

?155.00 per full day

Tea & Coffee, which will be served in the Common Room ?1.40 per person

Alternatively, we can deliver this to the meeting room at a cost of ?2.50
per person.

Three Course Lunch ?9.50 per person.

We can also provide a working sandwich lunch, which will be served in the
room, at a cost of ?7.50 per person.

Single room bed & breakfast ?52.75 per room per night

Should any of your residential delegates wish to dine in our restaurant in
the evening, we can provide a Three Course Dinner at ?14.00 per person. This
however, must be booked in advance.

 From your email, I gather you are not familiar with Rewley house? If you
would like to come over one day to take a look around, I will be more than
happy to meet with you. Please feel free to give me a call, to arrange this.

I trust you will find the above information of interest. Once you have some
definate dates, please contact me once again, and subject to availability,
will make the booking for you.

I look forward to hearing from you soon.

With best wishes,

Claire Moore
Residential Centre Projects Assistant
01865 280155
------------------
-- 
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 Jan 26 10:50:17 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 26 Jan 2005 10:50:17 -0500
Subject: [tei-council] time of conference call
Message-ID: <16887.48185.348924.145263@emt.wwp.brown.edu>

IIRC the call is scheduled for 13:00 UTC on Mon 31 Jan. The following
link will list that time in all time zones:
http://www.timeanddate.com/worldclock/fixedtime.html?month=1&day=31&year=2005&hour=13&min=0&sec=0&p1=0

Who is sponsoring the call (John, maybe?)? What are the dialing
instructions?

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jan 26 18:48:09 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 27 Jan 2005 08:48:09 +0900
Subject: [tei-council] time of conference call
In-Reply-To: <16887.48185.348924.145263@emt.wwp.brown.edu> (Syd Bauman's
	message of "Wed, 26 Jan 2005 10:50:17 -0500")
References: <16887.48185.348924.145263@emt.wwp.brown.edu>
Message-ID: 

Syd Bauman  writes:

> IIRC the call is scheduled for 13:00 UTC on Mon 31 Jan. The following
> link will list that time in all time zones:
> http://www.timeanddate.com/worldclock/fixedtime.html?month=1&day=31&year=2005&hour=13&min=0&sec=0&p1=0
>
> Who is sponsoring the call (John, maybe?)? What are the dialing
> instructions?

John Walsh send me the following instructions:

Participants will dial in to +1 812 856 3550.

When prompted, enter the code "0920" followed by "#".

It's scheduled for 8am-10am Eastern Standard Time.

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

I am still waiting for agenda items; am planning now to announce the
agenda tomorrow (Friday) evening, Taiwanese time.

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 28 08:46:33 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 28 Jan 2005 21:46:33 +0800
Subject: [tei-council] Agenda for TEI council conference call on Jan 31,
	2005 at 1300 UTC
Message-ID: 

TEI Council Members and Editors:

This is the agenda for the conference call the TEI Council will
hold this coming Monday, Jan. 31, 2005 at 1300 UTC.

Please read through the following, including the referenced documents,
in advance of the call.

INSTRUCTIONS for conference call:

Participants will dial in to +1 812 856 3550.

When prompted, enter the code "0920" followed by "#".

It's scheduled for 8am-10am Eastern Standard Time.

Expected members to participate:

Syd Bauman, Alejandro Bia, Lou Burnard, James Cummings, Matthew
Driscoll, Julia Flanders, Sebastian Rahtz, Laurent Romary, Natasha
Smith, Susan Schreibman, Edward Vanhoutte, John Walsh, Perry Willett,
Christian Wittern.

Agenda:

6 items

-----------------------------------------------------

1) Review of the minutes from the call of Nov. 30th (10 min)

   Minutes of the meeting are at
   http://www.tei-c.org/Council/tcm14.html. Review of action items,
   progress.

------------------------------------------------------------

2) Independent Headers  John Walsh writes:

Natasha Smith and I have been working, with feedback from Syd and Lou,
on revising Ch. 24 of the Guidelines on "The Independent Header."  The
general idea is to remove the concept of the Independent Header,
because nobody actually uses Independent Headers, but retain and
expand  on information about mapping from the header to other metadata
standards.  We can provide a brief update of this work as an agenda
item.

------------------------------------------------------------

3) Review of WG reports (10 min) : 

  Standoff Markup, (Manuscripts), Feature Structures, Physical
  Bibliography, biblItem

Matthew Driscoll writes:

I am afraid that there is an meeting here on Monday 
afternoon which I must attend. This will mean that I will 
not be able to participate in the conference call.

As I explained in my report prior to the members' meeting, 
the work of the task force on manuscript description is 
essentially finished, which means that I have nothing to 
report anyway. There is still some discussion going on on 
Sourceforge, but nothing of any great importance.

-----------------------------------------------------

4) P5 progress Lou Burnard writes:  (20 min)

Two draft documents for consideration by Council are now available: I
apologise for the delay, and also to  Syd who hasn't yet had a chance
to see them and may wish to provide further input.

EDW81 (http://www.tei-c.org/Drafts/edw81.html) is simply an updated
version showing where I think we now are with each chapter of P5

TCW05 (http://www.tei-c.org/Council/tcw05.html) is a report from me
and Sebastian summarizing work done here (with contributions from Syd)
in moving P5 forward since the Members' meeting.

----------
In preparation, council members are also encouraged to look at the
recent P5 snapshot release available from tei.sf.net

5) Other business  (5 minutes)

   TBA

6) Meetings: (5 minutes)

   Council meeting date / location:
   End of April (eg. 04/28-04/29 for a 2 day meeting?)
   Copenhagen?  Oxford?

   Please have your diaries ready, I would like to reach a decision
   this time

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 sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jan 28 09:02:07 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 28 Jan 2005 14:02:07 +0000
Subject: [tei-council] Preparation for next conference call
In-Reply-To: 
References: 
Message-ID: <41FA45DF.20804@computing-services.oxford.ac.uk>

Christian Wittern wrote:

> I am writing this from the top of my
>head in a Beijing hotel room.)
>  
>
I am puzzled by this. I can see how you might use the top of your head
to make notes, but how do you read them back. Do you
use Da Vinci mirror writing?

or are you in fact standing on your head?

-- 
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 28 18:15:36 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 29 Jan 2005 07:15:36 +0800
Subject: [tei-council] Preparation for next conference call
In-Reply-To: <41FA45DF.20804@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Fri, 28 Jan 2005 14:02:07 +0000")
References: 
	<41FA45DF.20804@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

> Christian Wittern wrote:
>
>> I am writing this from the top of my
>>head in a Beijing hotel room.)
>>  
>>
> I am puzzled by this. I can see how you might use the top of your head
> to make notes, but how do you read them back. Do you
> use Da Vinci mirror writing?
>
> or are you in fact standing on your head?
>

Have you ever been in a Beijing hotel room?  I can't reproduce it now,
since I am sitting now in a monastery's guest house north of Taipei
preparing for a class.

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  Sat Jan 29 22:45:26 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 29 Jan 2005 22:45:26 -0500
Subject: [tei-council] Agenda for TEI council conference call on Jan 31,
	2005 at 1300 UTC
In-Reply-To: 
References: 
Message-ID: <16892.22614.445266.155616@emt.wwp.brown.edu>

Lou, Sebastian --
  Thanks for writing this up. I gave it a quick scan, and overall
looks good. Minor quibbles below.

> EDW81 (http://www.tei-c.org/Drafts/edw81.html)

[Lou -- I'm happy to just make these updates directly to edw81 if you
like.] 

State of the Patient

* PR has been deleted

* CR has been merged into SA

Tasklist::urgent

1. Hey! You (Lou) promised more examples than just Lite.

13. I think discussion of standoff does not belong in NH. SA is
    1probably the right place.

Tasklist::nonurgent

1. I still don't know exactly what you (Lou) mean by this, but also
   IIRC the current prose in CH does not match the WG's final
   reccomendation, and thus needs updating.

2. Mostly done as described in edw79

5. What's CP?

Tasklist::after all else

3. As I've said before, I think it is unacceptable to remove BIB.
   Furthermore, I think 80% or so of it can be finished now, without
   waiting, and perhaps (per Lou & my conversation earlier this week)
   I should even do that this coming week.

> TCW05 (http://www.tei-c.org/Council/tcw05.html) 

* In the list of 3-stage validation:
  - we should mention the errors from jing that we are ignoring in
    pass 1
  - I think the wording for pass 2 is really confusing (implies that
    there is a separate schema for each example), but I'm too tired
    right now to come up with a better one

* Two sentences later, the explanation of multiple occurences of same
  xml:id= values is a little confusing. Suggested replacement:

          Stage 2 caught many instances of duplicate IDs. It is a
          feature of xml:id that all values must be unique across the
          whole document, whatever namespace is used. This means that
          3 examples in a row which in P4 used
          ]]> to make some point would
          now cause a validation
          error if all 3 are simply converted to
          ]]>.
          Whether having such examples is desirable, acceptable, or
          plain wrong caused a heated debate between LB, SB, and SR;
          but in the end all the values of xml:id were made unique by
          means of tedious hand-editing.

From Syd_Bauman at Brown.edu  Sat Jan 29 23:08:24 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 29 Jan 2005 23:08:24 -0500
Subject: [tei-council] on META and P5EC
In-Reply-To: 
References: 
Message-ID: <16892.23992.514712.514728@emt.wwp.brown.edu>

Sebastian & Lou have suggested in TCW05
(http://www.tei-c.org/Council/tcw05.html) that "Council may wish to
consider replacing the current Meta work-group with a new 'P5
Editorial Committee'". While I think consideration may be a useful
exercise, at the moment I think Council should reject this idea.

META should not be disbanded. While their work has reached an
important stage, and they are taking a well-deserved and appropriate
respite, it is not a foregone conclusion that there won't be more
work to do. Besides major issues like co-occurrence constraints and
the Durand conundrum, there are also minor issues that may arise,
including delving further into the meaning and application of
, adding features for handling overlapping hierarchies easier,
and constructing datatypes that more properly represent textual data
(I'm thinking of dates & times here, but there may be others).

Moreover, I will not be at all surprised if the first time ODD is
employed to create some other tagset (besides P5) problems we've not
anticipated arise.

The general idea of a P5 editorial committee is probably a good one.
But I'm of the (strong) opinion that Council *is* that committee.
This is what you were elected to do. Being on Council involves work,
including (to some extent) overseeing the editors, and you should be
doing it. While Council has the authority to farm this responsibility
out to another committee (and there may be reasons for doing so that
Lou & Sebastian have thought of that haven't occurred to me), I'm of
a mind that if it is too unwieldy to have all of Council more
involved (and I'm inclined to say it shouldn't be), that Council
should generate a subcommittee of itself for this purpose.

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jan 30 06:35:46 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 30 Jan 2005 11:35:46 +0000
Subject: [tei-council] on META and P5EC
In-Reply-To: <16892.23992.514712.514728@emt.wwp.brown.edu>
References: 
	<16892.23992.514712.514728@emt.wwp.brown.edu>
Message-ID: <41FCC692.1010004@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>work to do. Besides major issues like co-occurrence constraints and
>the Durand conundrum
>
I really have no idea where to go with this. We've discussed
it several times, and people like Syd and I have come up with
various ideas, but I at least waver on a practically
daily basis between:

 1. leave it as is
 2. tinker with it to get more features
 3. throw it all away a la Docbook

My feeling is that that we cannot reach any consensus without
a larger group of people using ODDs. The people I know of
who have written or edited a New Generation ODD from scratch are:
me,  Laurent, Stuart Brown, and Tone Merete. That's not a large
enough sample to say whether it is good enough or not.

>there are also minor issues that may arise,
>including delving further into the meaning and application of
>, adding features for handling overlapping hierarchies easier,
>and constructing datatypes that more properly represent textual data
>(I'm thinking of dates & times here, but there may be others).
>  
>
these don't really strike me as META matters. the group's summary says:

* The ODD format should be revised: DONE
* The ODD format and the current TEI  DTD for tag documentation
(TSD) should be combined : DONE
* Additional processors should be created to make not
only XML DTDs (and possibly SGML as well), but also at least
one XML schema format: DONE
* Where possible, data types should be converted to use the
datatype library of the W3C: DONE
* The Pizza Chef should be rewritten to allow user choice
of DTD or schema output: DONE

so I'd argue that ongoing work should revert back to normal methods
(whatever they are!)

>Moreover, I will not be at all surprised if the first time ODD is
>employed to create some other tagset (besides P5) problems we've not
>anticipated arise.
>  
>
that's an interesting research topic, I agree. 

-- 
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  Sun Jan 30 17:37:26 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 30 Jan 2005 22:37:26 +0000
Subject: [tei-council] on META and P5EC
In-Reply-To: <16892.23992.514712.514728@emt.wwp.brown.edu>
References: 
	<16892.23992.514712.514728@emt.wwp.brown.edu>
Message-ID: <41FD61A6.6030603@computing-services.oxford.ac.uk>

Maybe it would be useful for Council to address the question of whether 
or not a distinct P5 Editorial Committee should be set up separately 
from the question of whether or not the Meta workgroup needs to continue 
to exist.

In my opinion, at least, Syd is right to say that there are interesting 
areas not directly related to the production of P5 which we might to 
address in the future by means of something like a Meta workgroup 
(though I think its membership needs some more attention). But the 
current highest priority is to work on P5, for which I continue to think 
a small focussed group like that proposed might be a useful agency. Of 
course, if the Council members wish to take on that job, and have the 
time and energy to discharge it properly, that would be excellent.

Lou

Syd Bauman wrote:

> Sebastian & Lou have suggested in TCW05
> (http://www.tei-c.org/Council/tcw05.html) that "Council may wish to
> consider replacing the current Meta work-group with a new 'P5
> Editorial Committee'". While I think consideration may be a useful
> exercise, at the moment I think Council should reject this idea.
> 
> META should not be disbanded. While their work has reached an
> important stage, and they are taking a well-deserved and appropriate
> respite, it is not a foregone conclusion that there won't be more
> work to do. Besides major issues like co-occurrence constraints and
> the Durand conundrum, there are also minor issues that may arise,
> including delving further into the meaning and application of
> , adding features for handling overlapping hierarchies easier,
> and constructing datatypes that more properly represent textual data
> (I'm thinking of dates & times here, but there may be others).
> 
> Moreover, I will not be at all surprised if the first time ODD is
> employed to create some other tagset (besides P5) problems we've not
> anticipated arise.
> 
> The general idea of a P5 editorial committee is probably a good one.
> But I'm of the (strong) opinion that Council *is* that committee.
> This is what you were elected to do. Being on Council involves work,
> including (to some extent) overseeing the editors, and you should be
> doing it. While Council has the authority to farm this responsibility
> out to another committee (and there may be reasons for doing so that
> Lou & Sebastian have thought of that haven't occurred to me), I'm of
> a mind that if it is too unwieldy to have all of Council more
> involved (and I'm inclined to say it shouldn't be), that Council
> should generate a subcommittee of itself for this purpose.
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Jan 31 12:03:37 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 31 Jan 2005 17:03:37 +0000
Subject: [tei-council] release of tei on sourceforge
Message-ID: <41FE64E9.6010109@computing-services.oxford.ac.uk>

I have added a new File Release on Sourceforge, called "tei". This is a 
runtime set of DTD, Schema, and XSLT files
which provide a working TEI P4 and P5 (or so I claim :-}), packaged as a 
.tar.gz. The version number is the date.

Perhaps others could look and comment, and use this as partof the 
discussion about packaging the TEI?

-- 
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 computing-services.oxford.ac.uk  Mon Jan 31 12:09:31 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 31 Jan 2005 17:09:31 +0000
Subject: [tei-council] documenting stylesheets
Message-ID: <41FE664B.30209@computing-services.oxford.ac.uk>

apropos of stylesheets and documentation, one of the tasks I will
be undertaking in Timor is writing extensive documentation about
my stylesheets. It won't all be available under a free license,
but I'll make sure the reference material about parameterisation etc
is owned by the TEI for distribution.

By the way, a new release of my XSLT coming your way shortly; the main aim
being to simplify and integrate the choices about top-level
layout, including material from Oxford which uses CSS for layout.

Apropos of discussions on TEI-L, I may have time while away to complete
the work needed to make XHTML output.

-- 
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 31 14:21:42 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 31 Jan 2005 14:21:42 -0500
Subject: [tei-council] notes from today's conference call
Message-ID: <16894.34118.127799.941802@emt.wwp.brown.edu>

First draft is now available at
  http://www.tei-c.org/Council/tcm15.html
  http://www.tei-c.org/Council/tcm15.xml

Please send in any corrections, addtions, etc.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Jan 31 21:37:09 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 01 Feb 2005 10:37:09 +0800
Subject: [tei-council] notes from today's conference call
In-Reply-To: <16894.34118.127799.941802@emt.wwp.brown.edu> (Syd Bauman's
	message of "Mon, 31 Jan 2005 14:21:42 -0500")
References: <16894.34118.127799.941802@emt.wwp.brown.edu>
Message-ID: 

Syd Bauman  writes:

> First draft is now available at
>   http://www.tei-c.org/Council/tcm15.html
>   http://www.tei-c.org/Council/tcm15.xml
>

Great, thank you.  The notes look fine to me.

Chris

-- 

 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 Jan 31 21:40:13 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 01 Feb 2005 10:40:13 +0800
Subject: [tei-council] Next conference call
Message-ID: 

Dear Council members,

It occurred to me that I forgot to confirm a date for the next
conference call.  Keeping with our 2 month schedule, the next call
would be due end of March.  Since the last Monday might fall in the
Easter holiday in some areas, I propose to have the call on Monday
March 21, at 1300 UTC.

If that is not convenient for anybody, please speak out now!

All the best,

Christian

-- 

 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From edward.vanhoutte at kantl.be  Tue Feb  1 04:23:37 2005
From: edward.vanhoutte at kantl.be (Edward Vanhoutte)
Date: Tue,  1 Feb 2005 10:23:37 +0100
Subject: [tei-council] Next conference call
Message-ID: <200502011009.j11A9Ms5017752@relay.hostbasket.com>

I'm teaching on Mondays in the second term (TEI) and will be unable to join. But don't let me the problem.

Best,

Edward

Christian Wittern  wrote :

> Dear Council members,
> 
> It occurred to me that I forgot to confirm a date for the next
> conference call.  Keeping with our 2 month schedule, the next call
> would be due end of March.  Since the last Monday might fall in the
> Easter holiday in some areas, I propose to have the call on Monday
> March 21, at 1300 UTC.
> 
> If that is not convenient for anybody, please speak out now!
> 
> 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
================
Edward Vanhoutte
Coordinator
Centrum voor Teksteditie en Bronnenstudie - CTB (KANTL)
Centre for Scholarly Editing and Document Studies
Reviews Editor, Literary and Linguistic Computing
Koninklijke Academie voor Nederlandse Taal- en Letterkunde
Royal Academy of Dutch Language and Literature
Koningstraat 18 / b-9000 Gent / Belgium
tel: +32 9 265 93 51 / fax: +32 9 265 93 49
edward.vanhoutte at kantl.be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm

From sschreib at umd.edu  Tue Feb  1 21:28:30 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Tue, 1 Feb 2005 21:28:30 -0500
Subject: [tei-council] Next conference call
In-Reply-To: <200502011009.j11A9Ms5017752@relay.hostbasket.com>
Message-ID: <200502020228.AKN28511@md0.mail.umd.edu>

Dear Christian,

The week of 21 March is our spring break, so I would hate to make a meeting
that Monday morning. 

Shall we decide on another day of the week to meet as Edward can't make
Mondays this semester?

Susan

____________________________________________
Susan Schreibman, PhD
Assistant Dean,  Head of Digital Collections & Research
University of Maryland Libraries
McKeldin Library
University of  Maryland, College Park, 20742
phone: 301 314 0358
fax: 301 314 9408
email: sschreib at umd.edu

-----Original Message-----
From: tei-council-bounces at lists.village.Virginia.EDU
[mailto:tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of Edward
Vanhoutte
Sent: Tuesday, February 01, 2005 4:24 AM
To: Christian Wittern; tei-council at lists.village.Virginia.EDU
Subject: Re: [tei-council] Next conference call

I'm teaching on Mondays in the second term (TEI) and will be unable to join.
But don't let me the problem.

Best,

Edward

Christian Wittern  wrote :

> Dear Council members,
> 
> It occurred to me that I forgot to confirm a date for the next
> conference call.  Keeping with our 2 month schedule, the next call
> would be due end of March.  Since the last Monday might fall in the
> Easter holiday in some areas, I propose to have the call on Monday
> March 21, at 1300 UTC.
> 
> If that is not convenient for anybody, please speak out now!
> 
> 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
================
Edward Vanhoutte
Coordinator
Centrum voor Teksteditie en Bronnenstudie - CTB (KANTL)
Centre for Scholarly Editing and Document Studies
Reviews Editor, Literary and Linguistic Computing
Koninklijke Academie voor Nederlandse Taal- en Letterkunde
Royal Academy of Dutch Language and Literature
Koningstraat 18 / b-9000 Gent / Belgium
tel: +32 9 265 93 51 / fax: +32 9 265 93 49
edward.vanhoutte at kantl.be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm

_______________________________________________
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  Wed Feb  2 21:10:10 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 03 Feb 2005 11:10:10 +0900
Subject: [tei-council] Next conference call
In-Reply-To: <200502020228.AKN28511@md0.mail.umd.edu> (Susan Schreibman's
	message of "Tue, 1 Feb 2005 21:28:30 -0500")
References: <200502020228.AKN28511@md0.mail.umd.edu>
Message-ID: 

"Susan Schreibman"  writes:

> Dear Christian,
>
> The week of 21 March is our spring break, so I would hate to make a meeting
> that Monday morning. 
>
> Shall we decide on another day of the week to meet as Edward can't make
> Mondays this semester?

Thats what we should do, I think.  Please fill out the following
questionaire and send it back to the list.  To make it feasable for
everybody to attend the meetings will have to be at 1300 UTC.  Please
remember: for countries or areas using daylight saving time in part of
the year, this means that the times will not always be the same.

Day    I will be able to attend        can't make it 

3/14
3/15
3/16
3/17
3/18

3/21
3/22
3/23
3/24
3/25

3/28
3/29
3/30
3/31
4/1

I rarely do have appointments at 10 pm (except, of course for TEI
calls), so I expect to be able to make it on any of these 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 Laurent.Romary at loria.fr  Thu Feb  3 01:36:47 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Thu, 3 Feb 2005 07:36:47 +0100
Subject: [tei-council] Next conference call
In-Reply-To: 
References: <200502020228.AKN28511@md0.mail.umd.edu>

Message-ID: <4c3d8089a93300e95ff2d74a36937d57@loria.fr>

Le 3 f?vr. 05, ? 03:10, Christian Wittern a ?crit :

> Thats what we should do, I think.  Please fill out the following
> questionaire and send it back to the list.  To make it feasable for
> everybody to attend the meetings will have to be at 1300 UTC.  Please
> remember: for countries or areas using daylight saving time in part of
> the year, this means that the times will not always be the same.

I have somehow the feeling that I should read the above advice 
carefully...

>
>
> Day    I will be able to attend        can't make it
>
> 3/14 OK
> 3/15 OK
> 3/16 NO
> 3/17 NO
> 3/18 NO
>
> 3/21 OK
> 3/22 NO
> 3/23 OK
> 3/24 OK
> 3/25 OK
>
> 3/28 NO
> 3/29 NO
> 3/30 NO
> 3/31 NO
> 4/1 NO

Have a good day!
Laurent

From Syd_Bauman at Brown.edu  Thu Feb  3 02:27:44 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 3 Feb 2005 02:27:44 -0500
Subject: [tei-council] Next conference call
In-Reply-To: 
References: <200502020228.AKN28511@md0.mail.umd.edu>

Message-ID: <16897.53872.792178.169060@emt.wwp.brown.edu>

> Day    I will be able to attend        can't make it 
> 
> 3/14	
> 3/15	yes
> 3/16  yes
> 3/17	
> 3/18	yes
> 
> 3/21		no
> 3/22		no
> 3/23  yes
> 3/24
> 3/25  yes
> 
> 3/28
> 3/29  yes
> 3/30	yes
> 3/31
> 4/1   yes

All unmarked are "probably".

From mjd at hum.ku.dk  Thu Feb  3 02:47:58 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Thu, 03 Feb 2005 08:47:58 +0100
Subject: [tei-council] Next conference call
In-Reply-To: 
References: <200502020228.AKN28511@md0.mail.umd.edu> (Susan
	Schreibman's	message of "Tue, 1 Feb 2005 21:28:30 -0500")
Message-ID: <4201E53E.22727.11C66A@localhost>

>From my point of view things look like this:

3/14-3/18: any day this week is fine with me
3/21-3/23: same here
3/24-3/28: these are holidays here in God-fearing Denmark, so I hope to be in my dacha.
3/29-3/30: OK
3/31-4/1: otherwise engaged

all the best,
Matthew

From James.Cummings at computing-services.oxford.ac.uk  Thu Feb  3 06:00:01 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 03 Feb 2005 11:00:01 +0000
Subject: [tei-council] Next conference call
In-Reply-To: 
References: <200502020228.AKN28511@md0.mail.umd.edu>

Message-ID: <42020431.4040903@computing-services.oxford.ac.uk>

Christian Wittern wrote:
> Thats what we should do, I think.  Please fill out the following
> questionaire and send it back to the list.  To make it feasable for
> everybody to attend the meetings will have to be at 1300 UTC.  Please
> remember: for countries or areas using daylight saving time in part of
> the year, this means that the times will not always be the same.
> 
> 
  Day    I will be able to attend        can't make it

  3/14 	OK
  3/15	OK
  3/16		NO
  3/17		NO
  3/18		NO

  3/21	OK
  3/22	OK
  3/23	OK
  3/24	OK
  3/25		NO (University Shut)

  3/28		NO (University Shut)
  3/29	OK
  3/30	OK
  3/31	OK
  4/1	OK

Except for the 16/17/18 of March, I'm usually available any days.  The 
University is officially closed on Good Friday and Easter Monday (though 
I suppose it would be possible to come in anyways).

-- 
Dr James Cummings, Oxford Text Archive, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk

From edward.vanhoutte at kantl.be  Thu Feb  3 06:33:49 2005
From: edward.vanhoutte at kantl.be (Edward Vanhoutte)
Date: Thu,  3 Feb 2005 12:33:49 +0100
Subject: [tei-council] Next conference call
Message-ID: <200502031219.j13CJSlY004455@relay.hostbasket.com>

> Day    I will be able to attend        can't make it 
> 
> 3/14                                    x
> 3/15                                    x
> 3/16                                    x
> 3/17                                    x
> 3/18                                    x
> 
> 3/21                                    x
> 3/22   x
> 3/23   x
> 3/24   x
> 3/25   x
> 
> 3/28                                    x
> 3/29   x
> 3/30   x
> 3/31   x
> 4/1    x

Edward

================
Edward Vanhoutte
Coordinator
Centrum voor Teksteditie en Bronnenstudie - CTB (KANTL)
Centre for Scholarly Editing and Document Studies
Reviews Editor, Literary and Linguistic Computing
Koninklijke Academie voor Nederlandse Taal- en Letterkunde
Royal Academy of Dutch Language and Literature
Koningstraat 18 / b-9000 Gent / Belgium
tel: +32 9 265 93 51 / fax: +32 9 265 93 49
edward.vanhoutte at kantl.be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm

From edward.vanhoutte at kantl.be  Thu Feb  3 06:36:21 2005
From: edward.vanhoutte at kantl.be (Edward Vanhoutte)
Date: Thu,  3 Feb 2005 12:36:21 +0100
Subject: [tei-council] Next conference call
Message-ID: <200502031221.j13CLxlY004747@relay.hostbasket.com>

OK, more clear now

> Day    I will be able to attend        can't make it 
> 
> 3/14 NO
> 3/15 NO
> 3/16 NO
> 3/17 NO
> 3/18 NO
> 
> 3/21 NO
> 3/22 YES
> 3/23 YES
> 3/24 YES
> 3/25 YES
> 
> 3/28 NO
> 3/29 YES
> 3/30 YES
> 3/31 YES
> 4/1 YES

Edward
================
Edward Vanhoutte
Coordinator
Centrum voor Teksteditie en Bronnenstudie - CTB (KANTL)
Centre for Scholarly Editing and Document Studies
Reviews Editor, Literary and Linguistic Computing
Koninklijke Academie voor Nederlandse Taal- en Letterkunde
Royal Academy of Dutch Language and Literature
Koningstraat 18 / b-9000 Gent / Belgium
tel: +32 9 265 93 51 / fax: +32 9 265 93 49
edward.vanhoutte at kantl.be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm

From abia at umh.es  Thu Feb  3 07:49:13 2005
From: abia at umh.es (Alejandro Bia)
Date: Thu, 03 Feb 2005 13:49:13 +0100
Subject: [tei-council] Next conference call
In-Reply-To: 
References: <200502020228.AKN28511@md0.mail.umd.edu>
	<200502020228.AKN28511@md0.mail.umd.edu>
Message-ID: <5.2.0.9.0.20050203131102.03ec0608@mussol.umh.es>

Dear all,

My availability follows:

At 03:10 03/02/2005, Christian Wittern wrote:

>Day
>
>3/14 NO (I'M TEACHING AT THE SAME TIME)
>3/15 YES
>3/16 YES
>3/17 NO (APPOINTED MEETING)
>3/18 YES
>
>3/21 NO (I'M TEACHING AT THE SAME TIME)
>3/22 YES
>3/23 YES
>3/24 PREFERRABLY NOT, BUT COULD BE (UNIVERSITY HOLIDAYS)
>3/25 PREFERRABLY NOT, BUT COULD BE (UNIVERSITY HOLIDAYS)
>
>3/28 PREFERRABLY NOT, BUT COULD BE (UNIVERSITY HOLIDAYS)
>3/29 PREFERRABLY NOT, BUT COULD BE (UNIVERSITY HOLIDAYS)
>3/30 PREFERRABLY NOT, BUT COULD BE (UNIVERSITY HOLIDAYS)
>3/31 PREFERRABLY NOT, BUT COULD BE (UNIVERSITY HOLIDAYS)
>4/1  PREFERRABLY NOT, BUT COULD BE (UNIVERSITY HOLIDAYS)

Best regards,
Alex.-

---------------------------------------------------------
ALEJANDRO BIA-PLATAS
e-mail: abia at umh.es

   Departamento de Estad?stica y Matem?tica Aplicada
   Universidad Miguel Hern?ndez
   Edificio Torretamarit
   Avenida de la Universidad s/n, E-03202, Elche, ESPA?A
   http://www.umh.es/
   Tel: +34 966658542
   Fax: +34 966658715
   Tel?fono m?vil: +34 610806427

--------------------------------------------------------- 

From pwillett at umich.edu  Thu Feb  3 08:38:53 2005
From: pwillett at umich.edu (Perry Willett)
Date: Thu, 3 Feb 2005 08:38:53 -0500
Subject: [tei-council] Next conference call
In-Reply-To: 
Message-ID: <000901c509f5$b6b01e00$922bd38d@CLUBSODA>

Basically, Mon-Wed, okay; Thurs-Fri, no good.

Perry Willett
University of Michigan
pwillett at umich.edu

----------------------
Day    I will be able to attend        can't make it 

3/14: YES
3/15: YES
3/16: YES
3/17: NO
3/18: NO

3/21: YES
3/22: YES
3/23: YES
3/24: NO
3/25: NO

3/28: YES
3/29: YES
3/30: YES
3/31: NO
4/1:  NO

From nsmith at email.unc.edu  Thu Feb  3 09:07:01 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Thu, 3 Feb 2005 09:07:01 -0500 (Eastern Standard Time)
Subject: [tei-council] Next conference call
In-Reply-To: <42020431.4040903@computing-services.oxford.ac.uk>
Message-ID: 

>   Day    I will be able to attend        can't make it

   3/14 YES
   3/15	YES
   3/16		NO
   3/17	YES
   3/18		NO

   3/21		NO
   3/22		NO
   3/23	YES
   3/24	YES
   3/25		NO

   3/28	YES
   3/29	YES
   3/30	YES
   3/31	YES
   4/1		NO

all the best, ns

From Julia_Flanders at Brown.edu  Thu Feb  3 10:26:46 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 3 Feb 2005 10:26:46 -0500
Subject: [tei-council] Next conference call
In-Reply-To: 
References: <200502020228.AKN28511@md0.mail.umd.edu>

Message-ID: 

I'm available on any of those days.

>Day    I will be able to attend        can't make it
>
>3/14	YES
>3/15	YES
>3/16	YES
>3/17	YES
>3/18	YES
>
>3/21	YES
>3/22	YES
>3/23	YES
>3/24	YES
>3/25	YES
>
>3/28	YES
>3/29	YES
>3/30	YES
>3/31	YES
>4/1	YES

From sschreib at umd.edu  Thu Feb  3 12:36:02 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Thu, 03 Feb 2005 12:36:02 -0500
Subject: [tei-council] Next conference call
In-Reply-To: 
Message-ID: 

> 
> Day    I will be able to attend        can't make it
> 
> 3/14  X
> 3/15  X
> 3/16  X
> 3/17  X
> 3/18  X
> 
> 3/21              No
> 3/22              No
> 3/23              No
> 3/24              No
> 3/25              No
> 
> 3/28  X
> 3/29  X
> 3/30  X
> 3/31  X
> 4/1   X
> 
> I rarely do have appointments at 10 pm (except, of course for TEI
> calls), so I expect to be able to make it on any of these days.
> 
> All the best,
> 
> Christian
> 

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Feb  3 19:14:02 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 04 Feb 2005 09:14:02 +0900
Subject: [tei-council] Next conference call
In-Reply-To:  (Susan Schreibman's message of
	"Thu, 03 Feb 2005 12:36:02 -0500")
References: 
Message-ID: 

Dear Council members,

>From the responses that came in so far, I gather that 3/29 would fit
everybody, although it looks slightly inconvenient to Alejandro.  So,
with my apologies to him, I would like to set the date for the next
call to Tue March 29, at 1300 UTC

Christian Wittern

-- 

 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 Feb  4 10:14:33 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 04 Feb 2005 15:14:33 +0000
Subject: [tei-council] Next conference call
In-Reply-To: 
References:  
Message-ID: <42039159.6040300@computing-services.oxford.ac.uk>

Is OK by me.

Could I also remind Council members that at the last conference call 
they agreed to send me details of their preferred xml editing 
environment (software, platform, etc.) AND any opinions they might have 
on how the editorial process for P5 should be managed.

So far I have received responses from Julia, James, Susan, Syd, Chris, 
and  John. Sebastian and me I think I know about. Should I hang on for 
word from the remaining six council members, or should I assume that 
they have no opinions on either matter?

Christian Wittern wrote:

> Dear Council members,
> 
>>From the responses that came in so far, I gather that 3/29 would fit
> everybody, although it looks slightly inconvenient to Alejandro.  So,
> with my apologies to him, I would like to set the date for the next
> call to Tue March 29, at 1300 UTC
> 
> Christian Wittern
> 

From jawalsh at indiana.edu  Mon Feb 14 06:53:12 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Mon, 14 Feb 2005 06:53:12 -0500
Subject: [tei-council] url vs xlink:href
Message-ID: <5ff1cb4b05fed0e10cbcd0ea053b5be6@indiana.edu>

Hi All,

This may have been discussed before I recently joined the council, but 
is there a reason why P5 uses "url" instead of "xlink:href" for its 
general purpose linking attribute?

John
| John A. Walsh, Associate Director for Projects and Services
| Digital Library Program / Indiana University Libraries
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 Fax:812-856-2062 

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Feb 14 08:26:54 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 14 Feb 2005 13:26:54 +0000
Subject: [tei-council] url vs xlink:href
In-Reply-To: <5ff1cb4b05fed0e10cbcd0ea053b5be6@indiana.edu>
References: <5ff1cb4b05fed0e10cbcd0ea053b5be6@indiana.edu>
Message-ID: <4210A71E.5000606@computing-services.oxford.ac.uk>

John A. Walsh wrote:

> Hi All,
>
> This may have been discussed before I recently joined the council, but 
> is there a reason why P5 uses "url" instead of "xlink:href" for its 
> general purpose linking attribute?
>
sow09:

"This has since been rejected once it was
  realized that in TEI this attribute can point to multiple
  places (i.e., is of type tei.pointers), unlike the HTML
            attribute which can only point to one element."

You may well argue that we should make the ability to point to multiple 
places
be a special case, or not allowed at all.

The endless problems caused by trying to implement xml:lang and xml:id
make me feel decidely against xlink:href. "href" would be plausible, 
bearing in
mind the above.

-- 
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 Feb 14 10:03:31 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Mon, 14 Feb 2005 15:03:31 +0000
Subject: [tei-council] url vs xlink:href
In-Reply-To: <4210A71E.5000606@computing-services.oxford.ac.uk>
References: <5ff1cb4b05fed0e10cbcd0ea053b5be6@indiana.edu>
	<4210A71E.5000606@computing-services.oxford.ac.uk>
Message-ID: <4210BDC3.4070705@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> John A. Walsh wrote:
> 
>> Hi All,
>>
>> This may have been discussed before I recently joined the council, but 
>> is there a reason why P5 uses "url" instead of "xlink:href" for its 
>> general purpose linking attribute?
>>
> sow09:
> 
> "This has since been rejected once it was
>  realized that in TEI this attribute can point to multiple
>  places (i.e., is of type  type="datatype">tei.pointers), unlike the HTML
>            attribute which can only point to one element."

Forgive me if I'm mistaken, but isn't this quote talking about the 
possible (and then rejected) change of name of the 'target' attribute, 
not the url attribute?  For John, 
http://www.tei-c.org/Council/tcm11.html#body.1_div.13 is where the 
council suggested the SO wg think again in respect to renaming @target 
to be @href.  As @target on  seems in the current P5 draft to be of 
datatype.uriList, and so can contain multiple URIs, this makes sense.

But John's question, I'm assuming, was about the use of @url not @target:

@url as used on say  is xsd:anyURI, presumably because it needs 
to point to one particular thing.

But interestingly, the SO wg seems to suggest use of @xlink:href
when using SVG (http://www.tei-c.org/Activities/SO/sow04.html), but I 
don't know whether this was followed up or not, or considered outside 
the scope since I'm assuming it is what is used in SVG.  Can someone 
remind me (also as a newcomer) whether it was the decision and rational 
was concerning use of SVG to be used within /? Is this 
the recommend use or only offered as an extension?

@url as used seems to point to only one thing (unlike @target). 
@xlink:href also seems to point to only one thing.

If we are going to have to be processing xlink:href when used with 
SVG...should we use it elsewhere?

Just musing out loud,
-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 computing-services.oxford.ac.uk  Mon Feb 14 10:27:01 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 14 Feb 2005 15:27:01 +0000
Subject: [tei-council] url vs xlink:href
In-Reply-To: <4210BDC3.4070705@computing-services.oxford.ac.uk>
References: <5ff1cb4b05fed0e10cbcd0ea053b5be6@indiana.edu>	<4210A71E.5000606@computing-services.oxford.ac.uk>
	<4210BDC3.4070705@computing-services.oxford.ac.uk>
Message-ID: <4210C345.20009@computing-services.oxford.ac.uk>

James Cummings wrote:

>
> Forgive me if I'm mistaken, but isn't this quote talking about the 
> possible (and then rejected) change of name of the 'target' attribute, 
> not the url attribute?  For John, 
> http://www.tei-c.org/Council/tcm11.html#body.1_div.13 is where the 
> council suggested the SO wg think again in respect to renaming @target 
> to be @href.  As @target on  seems in the current P5 draft to be 
> of datatype.uriList, and so can contain multiple URIs, this makes sense.
>
> But John's question, I'm assuming, was about the use of @url not @target:

surely @url and @target are the same thing? as it stands in P5, we only 
have @target

>
> @url as used on say  is xsd:anyURI, presumably because it 
> needs to point to one particular thing.
>
its probably  which is out of sync, and should be xlink:xref

> But interestingly, the SO wg seems to suggest use of @xlink:href
> when using SVG (http://www.tei-c.org/Activities/SO/sow04.html), but I 
> don't know whether this was followed up or not, or considered outside 
> the scope since I'm assuming it is what is used in SVG.  Can someone 
> remind me (also as a newcomer) whether it was the decision and 
> rational was concerning use of SVG to be used within 
> /? Is this the recommend use or only offered as an 
> extension?

that whole business of SVG inside / seems to me merely 
illustrative and not TEI normative in any sense

>
> @url as used seems to point to only one thing (unlike @target). 
> @xlink:href also seems to point to only one thing.
>
> If we are going to have to be processing xlink:href when used with 
> SVG...should we use it elsewhere?

maybe.  it would conform with the depressing state of using xml:id, 
xml:lang and xml:base, and make
my life even more difficult by making practically every TEI document use 
_3_ namespaces

-- 
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 Feb 14 10:37:09 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Mon, 14 Feb 2005 15:37:09 +0000
Subject: [tei-council] url vs xlink:href
In-Reply-To: <4210C345.20009@computing-services.oxford.ac.uk>
References: <5ff1cb4b05fed0e10cbcd0ea053b5be6@indiana.edu>	<4210A71E.5000606@computing-services.oxford.ac.uk>
	<4210BDC3.4070705@computing-services.oxford.ac.uk>
	<4210C345.20009@computing-services.oxford.ac.uk>
Message-ID: <4210C5A5.90207@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> surely @url and @target are the same thing? as it stands in P5, we only 
> have @target

Ah ok, it probably hasn't been updated in the draft I have (from your 
debian packages), hence my confusion.

> its probably  which is out of sync, and should be xlink:xref

Ah, ok.

> that whole business of SVG inside / seems to me merely 
> illustrative and not TEI normative in any sense

That is what I thought, but wanted to be sure.

> maybe.  it would conform with the depressing state of using xml:id, 
> xml:lang and xml:base, and make
> my life even more difficult by making practically every TEI document use 
> _3_ namespaces

True.  XLink doesn't seemed to have ever had the popular support in 
implementation as the other recommendations.  Is this a reason to avoid it?

-James
-- 
Dr James Cummings, Oxford Text Archive, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk

From pwillett at umich.edu  Mon Feb 28 11:36:00 2005
From: pwillett at umich.edu (Perry Willett)
Date: Mon, 28 Feb 2005 11:36:00 -0500 (EST)
Subject: [tei-council] location for council meeting
Message-ID: 

Has the location for the council meeting been decided/announced? I'd like
to make travel plans soons. Thanks,

Perry Willett
University of Michigan
pwillett at umich.edu

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Feb 28 21:07:04 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 01 Mar 2005 11:07:04 +0900
Subject: [tei-council] location for council meeting
In-Reply-To: 
	(Perry
	Willett's message of "Mon, 28 Feb 2005 11:36:00 -0500 (EST)")
References: 
Message-ID: 

Perry Willett  writes:

> Has the location for the council meeting been decided/announced? I'd like
> to make travel plans soons. Thanks,

As you can see in the minutes for the last call
(http://www.tei-c.org/Council/tcm15.html),
the location is AFNOR in Paris, dates are April 28 (afternoon) and 29
(fullday) with the option to continue on Saturday April 30 if
necessary.

Hope to see you there,

Christian 

From jawalsh at indiana.edu  Mon Feb 28 21:52:05 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Mon, 28 Feb 2005 21:52:05 -0500
Subject: [tei-council] location for council meeting
In-Reply-To: 
References: 

Message-ID: <338c5477afa46c30caf5c5132f56529f@indiana.edu>

Hi All,

Where will we be staying?  Can Laurent (or anyone else) recommend some 
hotels near AFNOR?

John
| John A. Walsh, Associate Director for Projects and Services
| Digital Library Program / Indiana University Libraries
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 Fax:812-856-2062 
On Feb 28, 2005, at 9:07 PM, Christian Wittern wrote:

> Perry Willett  writes:
>
>> Has the location for the council meeting been decided/announced? I'd 
>> like
>> to make travel plans soons. Thanks,
>
>
> As you can see in the minutes for the last call
> (http://www.tei-c.org/Council/tcm15.html),
> the location is AFNOR in Paris, dates are April 28 (afternoon) and 29
> (fullday) with the option to continue on Saturday April 30 if
> necessary.
>
> Hope to see you there,
>
> Christian
>
> _______________________________________________
> 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  Tue Mar  1 04:24:57 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 01 Mar 2005 09:24:57 +0000
Subject: [tei-council] location for council meeting
In-Reply-To: <338c5477afa46c30caf5c5132f56529f@indiana.edu>
References: 	
	<338c5477afa46c30caf5c5132f56529f@indiana.edu>
Message-ID: <422434E9.3040802@computing-services.oxford.ac.uk>

AFNor is located in a unlovely business park, with no decent hotels 
anywhere near. Laurent's usual recommendation is to find a hotel in the 
neighbourhood of the Gare du Nord (of which there are dozens), from 
which trains for Afnor leave every 10 minutes or so.

  John A. Walsh wrote:

> Hi All,
> 
> Where will we be staying?  Can Laurent (or anyone else) recommend some 
> hotels near AFNOR?
> 
> John
> | John A. Walsh, Associate Director for Projects and Services
> | Digital Library Program / Indiana University Libraries
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | Voice:812-855-8758 Fax:812-856-2062 
> On Feb 28, 2005, at 9:07 PM, Christian Wittern wrote:
> 
>> Perry Willett  writes:
>>
>>> Has the location for the council meeting been decided/announced? I'd 
>>> like
>>> to make travel plans soons. Thanks,
>>
>>
>>
>> As you can see in the minutes for the last call
>> (http://www.tei-c.org/Council/tcm15.html),
>> the location is AFNOR in Paris, dates are April 28 (afternoon) and 29
>> (fullday) with the option to continue on Saturday April 30 if
>> necessary.
>>
>> Hope to see you there,
>>
>> 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
> 

From Laurent.Romary at loria.fr  Tue Mar  1 05:26:17 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Tue, 1 Mar 2005 11:26:17 +0100
Subject: [tei-council] location for council meeting
In-Reply-To: <338c5477afa46c30caf5c5132f56529f@indiana.edu>
References: 

	<338c5477afa46c30caf5c5132f56529f@indiana.edu>
Message-ID: <40bf379152bf2f3fda3771cf42637c76@loria.fr>

Dear all,
It just happens that AFNOR is just one stop from Gare du Nord by RER. 
Which means that usually people like to go to nice little hotels in the 
center of Paris, depending on their visiting plans (quartier latin , 
etc. ;-)). I remember that we already put together some basic 
information for our previous meetings at AFNOR.
Otherwise, some of us tend to stay at the Ibis Gare de l'Est, but it is 
just a matter of habit.
Lou: is there a page like an existing page somewhere in the TEI website?
Best
Laurent

Le 1 mars 05, ? 03:52, John A. Walsh a ?crit :

> Hi All,
>
> Where will we be staying?  Can Laurent (or anyone else) recommend some 
> hotels near AFNOR?
>
> John
> | John A. Walsh, Associate Director for Projects and Services
> | Digital Library Program / Indiana University Libraries
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | Voice:812-855-8758 Fax:812-856-2062 
> On Feb 28, 2005, at 9:07 PM, Christian Wittern wrote:
>
>> Perry Willett  writes:
>>
>>> Has the location for the council meeting been decided/announced? I'd 
>>> like
>>> to make travel plans soons. Thanks,
>>
>>
>> As you can see in the minutes for the last call
>> (http://www.tei-c.org/Council/tcm15.html),
>> the location is AFNOR in Paris, dates are April 28 (afternoon) and 29
>> (fullday) with the option to continue on Saturday April 30 if
>> necessary.
>>
>> Hope to see you there,
>>
>> 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
>

From lou.burnard at computing-services.oxford.ac.uk  Tue Mar  1 05:36:37 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 01 Mar 2005 10:36:37 +0000
Subject: [tei-council] location for council meeting
In-Reply-To: <40bf379152bf2f3fda3771cf42637c76@loria.fr>
References: 		<338c5477afa46c30caf5c5132f56529f@indiana.edu>
	<40bf379152bf2f3fda3771cf42637c76@loria.fr>
Message-ID: <422445B5.2000204@computing-services.oxford.ac.uk>

I will  dig out the one we used last time: but my laptop has just come 
back (fixed!) from IBM so all work is going to take a backseat for the 
next hour or so!

Laurent Romary wrote:
> Dear all,
> It just happens that AFNOR is just one stop from Gare du Nord by RER. 
> Which means that usually people like to go to nice little hotels in the 
> center of Paris, depending on their visiting plans (quartier latin , 
> etc. ;-)). I remember that we already put together some basic 
> information for our previous meetings at AFNOR.
> Otherwise, some of us tend to stay at the Ibis Gare de l'Est, but it is 
> just a matter of habit.
> Lou: is there a page like an existing page somewhere in the TEI website?
> Best
> Laurent
> 
> Le 1 mars 05, ? 03:52, John A. Walsh a ?crit :
> 
>> Hi All,
>>
>> Where will we be staying?  Can Laurent (or anyone else) recommend some 
>> hotels near AFNOR?
>>
>> John
>> | John A. Walsh, Associate Director for Projects and Services
>> | Digital Library Program / Indiana University Libraries
>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
>> | Voice:812-855-8758 Fax:812-856-2062 
>> On Feb 28, 2005, at 9:07 PM, Christian Wittern wrote:
>>
>>> Perry Willett  writes:
>>>
>>>> Has the location for the council meeting been decided/announced? I'd 
>>>> like
>>>> to make travel plans soons. Thanks,
>>>
>>>
>>>
>>> As you can see in the minutes for the last call
>>> (http://www.tei-c.org/Council/tcm15.html),
>>> the location is AFNOR in Paris, dates are April 28 (afternoon) and 29
>>> (fullday) with the option to continue on Saturday April 30 if
>>> necessary.
>>>
>>> Hope to see you there,
>>>
>>> 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
>>
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 
> 

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Mar  1 13:26:04 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 01 Mar 2005 18:26:04 +0000
Subject: [tei-council] new look TEI web site
Message-ID: <4224B3BC.2040506@computing-services.oxford.ac.uk>

I'd like to invite you all to visit http://www.tei-c.org.uk/ and have a 
crawl around.

This is the same filestore as the existing web site, but the XML source
is being rendered dynamically using Apache Cocoon. The look has been 
adjusted
to include a standard navigation bar, a breadcrumb trail, and a search box.

Although this is not a content reorganisation, it goes some of the way 
towards
bringing the TEI web site into the 20th century rant from Lou

Daniel and his crew at Virginia are looking at replicating the setup
there; if that goes well, we'll be able to offer this on tei-c.org if
it passes tests.

I suggest, unless people think this is a bad direction entirely, that we
allow a 2-3 week test period and then see if its ready for prime time.

-- 
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  Tue Mar  1 15:27:16 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 01 Mar 2005 20:27:16 +0000
Subject: [tei-council] new look TEI web site
In-Reply-To: <4224B3BC.2040506@computing-services.oxford.ac.uk>
References: <4224B3BC.2040506@computing-services.oxford.ac.uk>
Message-ID: <4224D024.6070008@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> I'd like to invite you all to visit http://www.tei-c.org.uk/ and have a 
> crawl around.

Sebastian,

- The png logo seems to have disappeared? I know it is attached as a 
background image in the CSS...but you get an error from Cocoon saying
it can't find it in eXist. http://www.tei-c.org.uk/logos/TEI-glow.png

- As mentioned in my last big long list of suggested changes (Sent 
privately), the members area is still unpassword protected. (Not that 
this bothers me...)

- One thing that bothers me, but I'd be interested in what others think:
The very front page gives you a three column layout with CSS floated 
columns. All very good.  But then when you click on a link and actually 
'enter' the site proper, you get the top-down menu navigation of the 
menu.  I think what I find jarring is the switch from one style to the 
other. (I much prefer the top-menu navigation, as it happens, even 
though I've used the former 3-column layout many times myself.)  Might 
it be more consistent to have only the the top-menu navigation?

-James

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Mar  1 15:32:51 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 01 Mar 2005 20:32:51 +0000
Subject: [tei-council] Re: [tei-board] new look TEI web site
In-Reply-To: 
References: <4224B3BC.2040506@computing-services.oxford.ac.uk>

Message-ID: <4224D173.8010903@computing-services.oxford.ac.uk>

Matthew Zimmerman wrote:

>
> So, do you want specific feedback about the layout, design, etc. 
> etc... or is that something that is going to be dealt with later by 
> the Virginia folks or one of John's students?

I am interested in feedback about the layout, because this is more or 
less now the default of my stylesheets;
even if the TEI C does better in due course, I want my stylesheets to 
produce something plausible now.

I regard this as a placeholder for the next 6 months; I don't want to 
pressurize Virginia to do a complete rethink
a lot faster than that, but equally I don't want to leave things as they 
are.

> My initial response is that something has to be done to make ti more 
> "readable". It seems a bit "busy" to me. My eye doesn't get drawn to 
> any one place and I can't tell the difference between headers and 
> text. Also I think the horizontal menu and bread crumbs seem to clash 
> with each other.
>
I was copying things like 
http://www.oucs.ox.ac.uk/ltg/reports/plag_index.xml; do you find that 
better? is
this a matter of colours?

I encourage any of you who are comfortable with CSS to grab a copy of 
one of the pages as HTML,
get the CSS from /stylesheets/teic.css and experiment with colours and 
spacing.

-- 
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 computing-services.oxford.ac.uk  Tue Mar  1 15:36:49 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 01 Mar 2005 20:36:49 +0000
Subject: [tei-council] new look TEI web site
In-Reply-To: <4224D024.6070008@computing-services.oxford.ac.uk>
References: <4224B3BC.2040506@computing-services.oxford.ac.uk>
	<4224D024.6070008@computing-services.oxford.ac.uk>
Message-ID: <4224D261.90905@computing-services.oxford.ac.uk>

James Cummings wrote:

>
> - The png logo seems to have disappeared? I know it is attached as a 
> background image in the CSS...but you get an error from Cocoon saying
> it can't find it in eXist. http://www.tei-c.org.uk/logos/TEI-glow.png

I don't get any error, sorry

>
> - As mentioned in my last big long list of suggested changes (Sent 
> privately), the members area is still unpassword protected. (Not that 
> this bothers me...)
>
I am hoping someone will tell me how to do this in Tomcat...

> The very front page gives you a three column layout with CSS floated 
> columns. All very good.  But then when you click on a link and 
> actually 'enter' the site proper, you get the top-down menu navigation 
> of the menu.  I think what I find jarring is the switch from one style 
> to the other. (I much prefer the top-menu navigation, as it happens, 
> even though I've used the former 3-column layout many times myself.)  
> Might it be more consistent to have only the the top-menu navigation?

could do.

as you know, I am used to this from our work, so I find it difficult to 
get new designs in my head.

easy enough to switch.

-- 
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  Tue Mar  1 16:03:05 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 01 Mar 2005 21:03:05 +0000
Subject: [tei-council] new look TEI web site
In-Reply-To: <4224D261.90905@computing-services.oxford.ac.uk>
References: <4224B3BC.2040506@computing-services.oxford.ac.uk>
	<4224D024.6070008@computing-services.oxford.ac.uk>
	<4224D261.90905@computing-services.oxford.ac.uk>
Message-ID: <4224D889.9060401@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> James Cummings wrote:
> 
>>
>> - The png logo seems to have disappeared? I know it is attached as a 
>> background image in the CSS...but you get an error from Cocoon saying
>> it can't find it in eXist. http://www.tei-c.org.uk/logos/TEI-glow.png
> I don't get any error, sorry

Screenshots sent offlist to prove I'm not going crazy. ;-)

> I am hoping someone will tell me how to do this in Tomcat...

For some reason using Realms, as the tomcat user guide seems to suggest,
does seem like overkill. 
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html

I vaguely recall that there is a way to do session-based authentication 
in eXist entirely in the sitemap with  or some such.  (You set 
the use up as a user in eXist, and then try to log into that via the 
sitemap, and only that user has rights to read that particular 
collection.)  Would that kind of system be suitable?
Quickly looking up a reference: http://www.exist-db.org/security.html#N1021D

> as you know, I am used to this from our work, so I find it difficult to 
> get new designs in my head.

Well, I *like* the way the oucs pages work... it is just switching 
between the two systems I don't like.  (Though I'm not entirely 
convinced by the choice of yellow (for logo or for page background)...
but my tastes certainly not the most mainstream.)

-James

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Mar  1 16:13:08 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 01 Mar 2005 21:13:08 +0000
Subject: [tei-council] new look TEI web site
In-Reply-To: <4224D889.9060401@computing-services.oxford.ac.uk>
References: <4224B3BC.2040506@computing-services.oxford.ac.uk>	<4224D024.6070008@computing-services.oxford.ac.uk>	<4224D261.90905@computing-services.oxford.ac.uk>
	<4224D889.9060401@computing-services.oxford.ac.uk>
Message-ID: <4224DAE4.9090607@computing-services.oxford.ac.uk>

James Cummings wrote:

>
> For some reason using Realms, as the tomcat user guide seems to suggest,
> does seem like overkill. 
> http://jakarta.apache.org/tomcat/tomcat-5.5-doc/realm-howto.html
>
>

not exactly

AuthType Basic
AuthName "Members Only Area"
AuthUserFile /home/www/htdocs/TEI/Members/.htpasswd
require valid-user

is 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 computing-services.oxford.ac.uk  Wed Mar  2 11:25:06 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 02 Mar 2005 16:25:06 +0000
Subject: [tei-council] new look TEI web site
In-Reply-To: <2dab74bf7cec851ee84b3858fce48945@nyu.edu>
References: <4224B3BC.2040506@computing-services.oxford.ac.uk>
	<4224D024.6070008@computing-services.oxford.ac.uk>
	<4224D261.90905@computing-services.oxford.ac.uk>
	<4224D889.9060401@computing-services.oxford.ac.uk>
	<4224DAE4.9090607@computing-services.oxford.ac.uk>
	<2dab74bf7cec851ee84b3858fce48945@nyu.edu>
Message-ID: <4225E8E2.3040108@computing-services.oxford.ac.uk>

Matthew Zimmerman wrote:

> The logo is no longer available for me either and I do get the error:
>
> Resource Not Found
>
> Message: Resource Not Found
>
> Description: The requested resource "/exist/TEIC/logos/TEI-glow.png" 
> could not be found
>
> Sender: org.apache.cocoon.servlet.CocoonServlet
>
> Source: Cocoon Servlet
>
weird, isnt it. I get that too now. Why it worked a few days ago, I have 
no idea!

-- 
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 computing-services.oxford.ac.uk  Wed Mar  2 11:33:17 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 02 Mar 2005 16:33:17 +0000
Subject: [tei-council] new look TEI web site
In-Reply-To: <2dab74bf7cec851ee84b3858fce48945@nyu.edu>
References: <4224B3BC.2040506@computing-services.oxford.ac.uk>
	<4224D024.6070008@computing-services.oxford.ac.uk>
	<4224D261.90905@computing-services.oxford.ac.uk>
	<4224D889.9060401@computing-services.oxford.ac.uk>
	<4224DAE4.9090607@computing-services.oxford.ac.uk>
	<2dab74bf7cec851ee84b3858fce48945@nyu.edu>
Message-ID: <4225EACD.7030202@computing-services.oxford.ac.uk>

In an act of inconceivable dumbness, I deleted the
lines in the Cocoon setup which let out PNG files.
Logo fixed 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 Julia_Flanders at Brown.edu  Wed Mar  2 12:12:58 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Wed, 2 Mar 2005 12:12:58 -0500
Subject: [tei-council] new look TEI web site
In-Reply-To: <4224B3BC.2040506@computing-services.oxford.ac.uk>
References: <4224B3BC.2040506@computing-services.oxford.ac.uk>
Message-ID: 

I'd like to back away from the specific discussion for a moment. 
Sebastian, I'm concerned that this partial redesign is live on the UK 
mirror *before* having been looked at or reviewed by the TEI board. 
I'm not even sure we discussed the idea of having an interim 
redesign; when you mentioned working with Cocoon to have a new 
dynamically generated site I assumed that you would be working with 
the same look as the current TEI site, and that any material changes 
would  be reviewed privately before going live. As an interim 
redesign, I don't think this new site is ready for prime time. Could 
we please restore the old UK mirror for the time being, while we sort 
out what we're going to do? We've had the existing site for long 
enough that a little longer won't kill us.

I'd also like to propose that we leave the redesign (as to structure 
and appearance) to Virginia (as discussed on the TEI board list). I 
don't think it's a good use of time to have false starts; I'd like to 
see a more systematic process which takes into account all of the 
TEI's needs, and allows for review in advance of publication. This, 
as I understand it, is what Virginia is planning and I think we 
should let them carry it out.

I hope this doesn't sound ungrateful--experimenting with the 
technical infrastructure for the site seems like a good thing, but 
I'd prefer that we be more careful with the public face of the TEI.

Best wishes, Julia

At 6:26 PM +0000 3/1/05, Sebastian Rahtz wrote:
>I'd like to invite you all to visit http://www.tei-c.org.uk/ and 
>have a crawl around.
>
>This is the same filestore as the existing web site, but the XML source
>is being rendered dynamically using Apache Cocoon. The look has been adjusted
>to include a standard navigation bar, a breadcrumb trail, and a search box.
>
>Although this is not a content reorganisation, it goes some of the way towards
>bringing the TEI web site into the 20th century rant from Lou
>
>Daniel and his crew at Virginia are looking at replicating the setup
>there; if that goes well, we'll be able to offer this on tei-c.org if
>it passes tests.
>
>I suggest, unless people think this is a bad direction entirely, that we
>allow a 2-3 week test period and then see if its ready for prime time.
>
>--
>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  2 19:38:31 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 03 Mar 2005 00:38:31 +0000
Subject: [tei-council] Afnor Info
Message-ID: <42265C87.1030907@computing-services.oxford.ac.uk>

Council Members attending next months meeting at AFNOR are recommended 
to book themselves into any one of the hotels in the region around Gare 
du Nord, Paris: in the 10eme.  I have no particular recommendation on 
this subject and there are dozens of websites which will do a better job 
than me. Laurent who is a creature of habit always stays at the same 
hotel  -- the Ibis Gare de L'est --  but if someone is willing to put 
effort into researching a better alternative they should do so!

I can however provide some useful information about getting to AFNOR :

Directions to AFNOR:

Association Fran?aise de Normalisation
11, avenue Francis de Pressens?
93571 Saint-Denis La Plaine Cedex

Tel. : (0)1 41 62 80 00
Fax : (0)1 49 17 90 00

But you really really don't want to go there except for a meeting, which 
is done as follows:

Take the RER (high speed metro) train from Gare du Nord in the direction 
of Roissy (Charles de Gaulle) airport, making sure *not* to get on a 
train which is going non-stop-to-the-airport. You can buy tickets from 
machines at Gare du Nord (your destination is outside the usual Metro 
zone, so your average metro ticket isn't good enough). Leave the train 
at La Stade de France, which should be the first stop (unless as 
aforesaid you've got on the wrong train, in which case you have no 
choice but to proceed towards the airport and then come back again). It 
takes about 10-15 minutes.

As you walk out of the station, you will see directly ahead of you a 
large white circular building labelled AFNOR. Walk down the nice 
tree-lined street towards it, taking care not to get killed crossing the 
intersection in front of it.  This is France. They drive their cars fast 
and on the wrong side of the road.

Do we have any idea what time the meeting will start on Thursday? I 
have  an engagement in London on the Weds evening, which may finish too 
late for me to get the last train that evening; in which case I may be 
arriving Thurs morning with a bad hangover....

Lou

From James.Cummings at computing-services.oxford.ac.uk  Thu Mar  3 05:17:28 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 03 Mar 2005 10:17:28 +0000
Subject: [tei-council] new look TEI web site
In-Reply-To: 
References: <4224B3BC.2040506@computing-services.oxford.ac.uk>

Message-ID: <4226E438.4020207@computing-services.oxford.ac.uk>

Julia Flanders wrote:
> I'd like to back away from the specific discussion for a moment. 
> Sebastian, I'm concerned that this partial redesign is live on the UK 
> mirror *before* having been looked at or reviewed by the TEI board. 

As an aside to this, can I ask what the status is of the UK site?  I 
never viewed it strictly as a 'mirror' of the .org (US, International,
whatever we should call it) site.  I always just assumed that, although 
it functioned as a mirror of the main site, it was always unofficially 
so.  More of a preview / development site than strictly a mirror.  Is it 
listed as such on the website?  How are users meant to know they have it 
as an option? I'm just curious, since I'm sure all this pre-dates my 
involvement with the TEI.

I don't disagree in any way that the content of the website, and its 
structural organisation would not benefit from careful reorganisation.

-James

I'm
> not even sure we discussed the idea of having an interim redesign; when 
> you mentioned working with Cocoon to have a new dynamically generated 
> site I assumed that you would be working with the same look as the 
> current TEI site, and that any material changes would  be reviewed 
> privately before going live. As an interim redesign, I don't think this 
> new site is ready for prime time. Could we please restore the old UK 
> mirror for the time being, while we sort out what we're going to do? 
> We've had the existing site for long enough that a little longer won't 
> kill us.
> 
> I'd also like to propose that we leave the redesign (as to structure and 
> appearance) to Virginia (as discussed on the TEI board list). I don't 
> think it's a good use of time to have false starts; I'd like to see a 
> more systematic process which takes into account all of the TEI's needs, 
> and allows for review in advance of publication. This, as I understand 
> it, is what Virginia is planning and I think we should let them carry it 
> out.
> 
> I hope this doesn't sound ungrateful--experimenting with the technical 
> infrastructure for the site seems like a good thing, but I'd prefer that 
> we be more careful with the public face of the TEI.
> 
> Best wishes, Julia
> 
> 
> At 6:26 PM +0000 3/1/05, Sebastian Rahtz wrote:
> 
>> I'd like to invite you all to visit http://www.tei-c.org.uk/ and have 
>> a crawl around.
>>
>> This is the same filestore as the existing web site, but the XML source
>> is being rendered dynamically using Apache Cocoon. The look has been 
>> adjusted
>> to include a standard navigation bar, a breadcrumb trail, and a search 
>> box.
>>
>> Although this is not a content reorganisation, it goes some of the way 
>> towards
>> bringing the TEI web site into the 20th century rant from 
>> Lou
>>
>> Daniel and his crew at Virginia are looking at replicating the setup
>> there; if that goes well, we'll be able to offer this on tei-c.org if
>> it passes tests.
>>
>> I suggest, unless people think this is a bad direction entirely, that we
>> allow a 2-3 week test period and then see if its ready for prime time.
>>
>> -- 
>> 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
> 
> 

-- 
Dr James Cummings, Oxford Text Archive, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk

From Julia_Flanders at Brown.edu  Thu Mar  3 11:56:33 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 3 Mar 2005 11:56:33 -0500
Subject: [tei-council] new look TEI web site
In-Reply-To: <4226E438.4020207@computing-services.oxford.ac.uk>
References: <4224B3BC.2040506@computing-services.oxford.ac.uk>

	<4226E438.4020207@computing-services.oxford.ac.uk>
Message-ID: 

I've searched the TEI-L list archives, and there are quite a lot of 
postings which assume that the UK site is an official mirror:

--people are directed, without comment, to files that are available on it
--in cases where the Virginia site is down, people are reminded to 
use the UK site (with assumption that one can expect it to act as a 
substitute)
--it's referred to as "the UK mirror site"

Users know it's an option because of references of this sort; I don't 
know whether the relationship between the two was stated  explicitly 
when the two sites were initially launched.

Julia

At 10:17 AM +0000 3/3/05, James Cummings wrote:
>As an aside to this, can I ask what the status is of the UK site?  I 
>never viewed it strictly as a 'mirror' of the .org (US, 
>International,
>whatever we should call it) site.  I always just assumed that, 
>although it functioned as a mirror of the main site, it was always 
>unofficially so.  More of a preview / development site than strictly 
>a mirror.  Is it listed as such on the website?  How are users meant 
>to know they have it as an option? I'm just curious, since I'm sure 
>all this pre-dates my involvement with the TEI.
>
>I don't disagree in any way that the content of the website, and its 
>structural organisation would not benefit from careful 
>reorganisation.
>
>-James

From James.Cummings at computing-services.oxford.ac.uk  Thu Mar  3 12:18:30 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 03 Mar 2005 17:18:30 +0000
Subject: [tei-council] new look TEI web site
In-Reply-To: 
References: <4224B3BC.2040506@computing-services.oxford.ac.uk>		<4226E438.4020207@computing-services.oxford.ac.uk>

Message-ID: <422746E6.2030608@computing-services.oxford.ac.uk>

Julia Flanders wrote:
> I've searched the TEI-L list archives, and there are quite a lot of 
> postings which assume that the UK site is an official mirror:
> 
> --people are directed, without comment, to files that are available on it

Thanks for the answers, you are right then, to users it must appear as a 
mirror site, whatever its actual function.  I'm of the opinion that if 
it is a mirror then all files should exist at both locations, and people 
should always be directed to the .org version.  (If one day Virginia 
want to do load balancing and direct people from Europe automatically to 
the UK version, then that might justify the existence of the UK 
version.)  But, is there really the need for a UK mirror?  I don't 
recall ever having a problem getting to the Virginia site or it being 
slow.  What is the point of it otherwise?  Perhaps we should create
http://dev.tei-c.org/ as a development site (hosted where-ever, perhaps
on the current www.tei-c.org.uk).

-James
-- 
Dr James Cummings, Oxford Text Archive, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk

From Julia_Flanders at Brown.edu  Thu Mar  3 15:18:54 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 3 Mar 2005 15:18:54 -0500
Subject: [tei-council] new look TEI web site
In-Reply-To: <422746E6.2030608@computing-services.oxford.ac.uk>
References: <4224B3BC.2040506@computing-services.oxford.ac.uk>

	<4226E438.4020207@computing-services.oxford.ac.uk>

	<422746E6.2030608@computing-services.oxford.ac.uk>
Message-ID: 

Yes, the Board is discussing and deciding on the issue of whether 
there's a need for a UK mirror, and on the function/location of a 
development site.

Although the strategic issues are being addressed over the way on the 
board list, if members of the Council have feedback to offer (at a 
conceptual, not a detail level) on the TEI web site, you should feel 
free to send it to Sebastian and to Matt Gibson, who is UVa's 
representative on the Board. Virginia will be undertaking a more 
thorough redesign of the entire TEI site later in the year, and 
thoughts about the site (as always) are helpful in identifying areas 
that need work.

However, it's probably a better use of people's time to review the 
sourceForge materials.

best, Julia

At 5:18 PM +0000 3/3/05, James Cummings wrote:
>Julia Flanders wrote:
>>  I've searched the TEI-L list archives, and there are quite a lot 
>>of postings which assume that the UK site is an official mirror:
>>  --people are directed, without comment, to files that are available on it
>
>Thanks for the answers, you are right then, to users it must appear 
>as a mirror site, whatever its actual function.  I'm of the opinion 
>that if it is a mirror then all files should exist at both 
>locations, and people should always be directed to the .org version. 
>(If one day Virginia want to do load balancing and direct people 
>from Europe automatically to the UK version, then that might justify 
>the existence of the UK version.)  But, is there really the need for 
>a UK mirror?  I don't recall ever having a problem getting to the 
>Virginia site or it being slow.  What is the point of it otherwise? 
>Perhaps we should create
>http://dev.tei-c.org/ as a development site (hosted where-ever, perhaps
>on the current www.tei-c.org.uk).
>
>-James
>--
>Dr James Cummings, Oxford Text Archive, University of Oxford
>James dot Cummings at oucs dot ox dot ac dot uk

From nsmith at email.unc.edu  Fri Mar  4 21:31:27 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Fri, 4 Mar 2005 21:31:27 -0500
Subject: [tei-council] new look TEI web site
References: <4224B3BC.2040506@computing-services.oxford.ac.uk><4226E438.4020207@computing-services.oxford.ac.uk><422746E6.2030608@computing-services.oxford.ac.uk>

Message-ID: <014201c5212b$6f084350$6801a8c0@lib.unc.edu>

> However, it's probably a better use of people's time to review the
> sourceForge materials.

which reminded the following from the recent minutes that call us to act
more than ASAP:

... SB to initiate a test prodding system for Council to consider SF feature
request artifacts. The basic idea is that SB will periodically post a
specific topic for discussion, and immediately council members will review
and discuss it. Hopefully within a brief period some closure (perhaps even a
decision!) will be obtained, and an individual council member will volunteer
to shepherd the issue through whatever progress is then required. If no one
volunteers, council members may be assigned alphabetically.
Action SB by 2005-02-07: Post first feature request artifact prod to council

 best, ns

From Syd_Bauman at Brown.edu  Fri Mar  4 22:15:40 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 4 Mar 2005 22:15:40 -0500
Subject: [tei-council] new look TEI web site
In-Reply-To: <014201c5212b$6f084350$6801a8c0@lib.unc.edu>
References: <4224B3BC.2040506@computing-services.oxford.ac.uk>

	<4226E438.4020207@computing-services.oxford.ac.uk>

	<422746E6.2030608@computing-services.oxford.ac.uk>

	<014201c5212b$6f084350$6801a8c0@lib.unc.edu>
Message-ID: <16937.9308.186787.948142@emt.wwp.brown.edu>

> which reminded the following from the recent minutes that call us
> to act more than ASAP:

Yup. I had just talked to Julia about this last week. I expect to
have something out to y'all by Monday.

From lou.burnard at computing-services.oxford.ac.uk  Sat Mar  5 07:21:20 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 05 Mar 2005 12:21:20 +0000
Subject: [tei-council] P5 editing environments
Message-ID: <4229A440.8090200@computing-services.oxford.ac.uk>

At the last council call I was actioned to request input from all 
council members about (a) their personal preference for a TEI editing 
environment (b) their opinion as to the desirability of setting up a 
distinct editorial subcommittee

On the first question I received five responses, from Christian, James, 
John, Syd, Julia,  and Susan. If other council members have sent me a 
response, please could they re-send it or remind me? (I am not expecting 
a response from myself or Sebastian, since I know what it would be in 
both cases!)

There seems to be a consensus in favour of our current distribution 
mechanism, which is reassuring. It's also clear that we need to do more 
on making the installation process for Macs a bit less hostile. Maybe 
someone would like to work on that? And I don't know anything about 
jEdit -- could Susan tell us what  (if anything) we should do to make 
that easier to use with P5?

Responses are quoted below.

As to the editing environment, I am using GNU Emacs or XEmacs on MacOS 
X, occasionally also Oxygen (mainly for teaching purposes). For the 
moment, I personally am fine with a tarball that I can unzip in 
/usr/local/somewhere, but in the longterm a fink package or even a Mac 
OS package is desirable.

As for my personal use of TEI P5: primary system: Debian GNU/Linux running Emacs/tei-nxml secondary system: Mac OS X running oXygen
tertiary system: Mac OS X running Emacs/nxml
quaternary system: Mac OS X running jEdit
quinary system: SunOS (solaris) running Emacs/nxml
senary system: Debian GNU/Linux running oXygen
(I haven't actually used any but the 1st 2 yet.) The WWP encoders use
the SunOS system, so eventually I will have to have P5 working fine
and dandy on that, but there's no rush there. I won't be
experimenting with P5 on that system for quite awhile.

My XML editor of choice is emacs with James Clark's nxml-mode.  I also 
use Oxygen on occasion for some tasks.  I'm generally working on a 
Unix-like operating system, usually Mac OS X, sometimes a flavor of 
Linux.  I keep my catalogs in /etc/xml and my DTDs, schema, entity 
files, and other miscellaneous XML stuff in /usr/local/lib/xml.  I 
think /etc/xml is a convention of sorts across Unixes.  I picked 
/usr/local/lib/xml myself.  From this morning's discussion it sounds 
like /usr/share/xml or /usr/local/share/xml may be more of a 
convention.  For myself, I don't need any special packages or 
installers, just the files, but I'm sure user-friendly packages and 
installers will be appreciated by many TEI users.

Hi Lou -- I use jEdit -- I've used it on a PC, but now I have both a PC 
and a Mac -- so I'd like to use it in both environments

Lou, I'd be using oXygen on a Mac in private life; at the WWP we'd be 
using emacs under unix.

I use tei-emacs and oXygen on both Debian Linux (unstable) and
Windows XP. If you want my two euro-cents: I think the path layout on windows, 
should just be: c:\Program Files\TEI\ Which then contains a tei-emacs directory where the tei-emacs for windows would install, and then an exact mirror of the debian packages
from /usr/share/xml/tei, so a schemas and a stylesheet directory.  And 
it should also contain a 'doc' directory that contains everything under 
/usr/share/doc/tei-doc/ ... or at least something similar that is 
trivial to build automatically from the same process used to build the 
debian packages.  People will have to customise their editors to work 
with it (or those creating the editors) in any case, so making it the 
simplest and most easily contained structure seems reasonable to me. 
Well, you did ask for our opinions.

--------------------

On the second question, I received so little input that I don't think anything can be said about what the Council's overall view is. The comments I received are quoted below:

---

I think the editorial committee is a good idea, and I'd be willing to 
serve on such a committee.  I think three members of the Council would 
be a good number for this committee.  My understanding is that we are 
not to nominate people at this point, but rather express our general 
opinions about the topic and our own willingness to serve.

Also, I have no problems with the existence of a TEI P5 Editorial 
Management Committee, though don't think it is something anyone would 
think that I'm qualified for myself

I would also be willing to serve on the editorial committee.  One of the tasks I see for this
committee with a high prioriry is to devise a process for reaching
decisions on the road to P5 and resolving conflicts, for example
between WG's and the Editors.  We also need to think about how exactly
getting the Council members to do the work they have been elected for.

---

From lou.burnard at computing-services.oxford.ac.uk  Sat Mar  5 13:46:21 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 05 Mar 2005 18:46:21 +0000
Subject: [tei-council] P5 Progress report
Message-ID: <4229FE7D.8070604@computing-services.oxford.ac.uk>

At our last conference call, council members were requested to read and 
comment on the schedule of work outlined in edw81, which gives brief 
characterizations of the state of each chapter of P5.

Since that date, some progress has been made on defining one particular 
global task: the "war on attributes". There is a new draft document for 
Council members to read on this topic at 
www.tei-c.org.uk/Drafts/edw86.xml which contains some general remarks 
about how attribute values and datatypes might be standardized in P5 
(these are just suggestions at the moment). It also contains a list of 
all the current "CDATA"-valued attributes together with a suggestion for 
how they  should be treated in P5. Council is particularly requested to 
review this list and comment.

Over the last month the bulk of my TEI time has been divided amongst the 
following activities:
1. revising teaching materials to use TEI P5 and developing some new 
material about ODDs (see www.tei-c.org.uk/Talks/OUCS/2005-02)
2. working on edw86
3. defining a proposed replacement for the current  element (I 
hope to circulate a brief discussion of that in the next day or so)
4. working with the ms description taskforce on some last minute 
revisions to chapter MS (now available in CVS)

I know that Syd has been busy  with the self-appointed workgroup 
revising biblStruct, but I have not yet been able to review that work.

Lou

From Syd_Bauman at Brown.edu  Mon Mar  7 01:16:23 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 7 Mar 2005 01:16:23 -0500
Subject: [tei-council] CARP01: content of 
Message-ID: <16939.61879.141802.781452@emt.wwp.brown.edu>

As per the decision on our last conference call (see http://www.tei-
c.org/Council/tcm15.html#id2288873), this is an official prod for
Council consideration and resolution, which, if you really like
acronyms, could be called Council CARP (consideration and resolution
prod -- no, I don't want to call it 'consideration, resolution, and
progress' :-).

I thought we should start with an easy one. The Character Encoding WG
pointed out that nothing that might need to have a character outside
of Unicode or be expressed in a different language should be in an
attribute value. Council charged the editors with reporting what this
means -- what we should do with our various attributes. In ED W 79
(http://www.tei-c.org/Drafts/edw79.html) and again in ED W 86 the
editors say that the value= attribute of the  element should
become the content of the  element.

Meanwhile, back on Sourceforge, Andreas Nolda posted a feature
request for giving the empty  element content, so that he
could give it some markup. The editors chimed in saying, yes, it's
probably a good idea. No one else has posted a word.

So the only real question left, IMHO, is what should the content of
 be? Lou & I have made several suggestions in the discussion
on Sourceforge. So each and every council member should head over to
feature request #1007353 at
https://sourceforge.net/tracker/index.php?func=detail&aid=1007353&group_id=106328&atid=644065
read the entire artifact (it's only 4 posts long -- and I apologize
in advance for how ugly mine looks: I spent time trying to make sure
that it came out looking OK, but apparently Sourceforge's input field
and output display are of different widths, sigh), and post your
thoughts and opinions here[1].

This one is straight forward enough that I'm hoping we won't need any
significant further progress through which to shepherd the issue. We
should just try to reach complete and final resolution on the issue
before Thu 17 Mar, and I'll try to implement it before I leave on Sat
19 for a conference.

Note
----
[1] Did we decide whether discussion should take place here on this
    list or on the feature request tracker on Sourceforge? 

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Mar  7 06:19:55 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 07 Mar 2005 20:19:55 +0900
Subject: [tei-council] review process for P5 (MS chapter)  -- vote required
Message-ID: 

Dear Council members,

In an attempt to move forward P5, Lou suggested to me to establish a
review process for areas in need of specific attention.  One of the
areas where such a process could be fruitful,  he suggested, would be
the MS chapter.  We do have a new draft from the WG, but it would be
good to get a more diversified range of opinions on the currently
state, especially with view to possible omissions or oversights, etc.
I would like therefore to ask Council members to form an opinion on
this issue and express it here on our list.  If the Council accepts
this, I would like to ask Matthew as the Chair of the MS effort to
name about 7 or 8 people we could ask to act as reviewers.  If this
works out well, we might also consider this model for other chapters
and /or proposed changes.

All the best,

Christian

From James.Cummings at computing-services.oxford.ac.uk  Mon Mar  7 07:06:25 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Mon, 07 Mar 2005 12:06:25 +0000
Subject: [tei-council] CARP01: content of 
In-Reply-To: <16939.61879.141802.781452@emt.wwp.brown.edu>
References: <16939.61879.141802.781452@emt.wwp.brown.edu>
Message-ID: <422C43C1.1070506@computing-services.oxford.ac.uk>

Syd Bauman wrote:
> [1] Did we decide whether discussion should take place here on this
>     list or on the feature request tracker on Sourceforge? 

In the spirit of keeping TEI decisions transparent, Open TEI, then I'd 
encourage people use sourceforge to do this.  I have already done so, 
and however naive my comments may be, I'm happy for others to see them.

-James
-- 
Dr James Cummings, Oxford Text Archive, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk

From nsmith at email.unc.edu  Mon Mar  7 08:57:19 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Mon, 7 Mar 2005 08:57:19 -0500 (Eastern Standard Time)
Subject: [tei-council] CARP01: content of 
In-Reply-To: <16939.61879.141802.781452@emt.wwp.brown.edu>
Message-ID: 

> Note
> ----
> [1] Did we decide whether discussion should take place here on this
>     list or on the feature request tracker on Sourceforge? 

My preferance would be SF, unless we want to keep thoughts really to
ourselves. best, ns

From Syd_Bauman at Brown.edu  Mon Mar  7 09:05:31 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 7 Mar 2005 09:05:31 -0500
Subject: [tei-council] CARP01: content of 
In-Reply-To: <422C43C1.1070506@computing-services.oxford.ac.uk>
References: <16939.61879.141802.781452@emt.wwp.brown.edu>
	<422C43C1.1070506@computing-services.oxford.ac.uk>
Message-ID: <16940.24491.758706.462040@emt.wwp.brown.edu>

> In the spirit of keeping TEI decisions transparent, Open TEI, then
> I'd encourage people use sourceforge to do this. I have already
> done so, and however naive my comments may be, I'm happy for others
> to see them.

Really good point. I have to admit I was thinking purely of
expediency, here. Seems to me there are potentially quite a few
people who will notice incoming e-mail, but will not make the effort
to go to an artifact[1] and read it, let alone log in and comment or
click on "monitor".

I have a vague recollection that this was one of the reasons for the
CARP program, but I'm not at all sure. If we can maintain a
discussion on SF, out in public, all the better. (I'll try to comment
on your actual comments on SF myself this afternoon.)

Note
----
[1] In this case
    http://sourceforge.net/tracker/index.php?func=detail&aid=1007353&group_id=106328&atid=644065

From lou.burnard at computing-services.oxford.ac.uk  Mon Mar  7 10:19:59 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 07 Mar 2005 15:19:59 +0000
Subject: [tei-council] CARP01: content of 
In-Reply-To: 
References: 
Message-ID: <422C711F.405@computing-services.oxford.ac.uk>

What she said.

It's not difficult to monitor the progress of artefacts on SF. That's 
what it is for.

Natasha Smith wrote:

>>Note
>>----
>>[1] Did we decide whether discussion should take place here on this
>>    list or on the feature request tracker on Sourceforge? 
> 
> 
> My preferance would be SF, unless we want to keep thoughts really to
> ourselves. best, ns
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Mar 11 08:55:06 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 11 Mar 2005 13:55:06 +0000
Subject: [tei-council] another new look
Message-ID: <4231A33A.5000002@computing-services.oxford.ac.uk>

try http://www.tei-c.org:81/ now.

away with all this excessive colouring!

sebastian

From pwillett at umich.edu  Fri Mar 11 09:44:05 2005
From: pwillett at umich.edu (Perry Willett)
Date: Fri, 11 Mar 2005 09:44:05 -0500
Subject: [tei-council] another new look
In-Reply-To: <4231A33A.5000002@computing-services.oxford.ac.uk>
Message-ID: <001401c52648$c93f0b20$922bd38d@CLUBSODA>

Overall, I like the new look. Maybe I like it because I was tired of the old
one. But I'm not the person you want making design decisions.

A few points:

1) I think the list of members needs to be more prominent. People like to
know who else is in the club if they're thinking about joining. And the
"Members" link should probably say something like "Members only area"--it's
where I expected to find the list of members.

2) I think the link to the home page should be in the upper left navigation
bar, along with "Activities", etc.

3) There's mention of a "TEI Boar" on this page:

It's probably a typo for "TEI Board," but it evokes a lot of vivid imagery.

Perry

-----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: Friday, March 11, 2005 8:55 AM
To: TEI Council
Cc: james at computing-services.oxford.ac.uk
Subject: [tei-council] another new look

try http://www.tei-c.org:81/ now.

away with all this excessive colouring!

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 computing-services.oxford.ac.uk  Fri Mar 11 10:43:26 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 11 Mar 2005 15:43:26 +0000
Subject: [tei-council] another new look
In-Reply-To: <001401c52648$c93f0b20$922bd38d@CLUBSODA>
References: <001401c52648$c93f0b20$922bd38d@CLUBSODA>
Message-ID: <4231BC9E.4020000@computing-services.oxford.ac.uk>

Perry Willett wrote:

>1) I think the list of members needs to be more prominent. People like to
>know who else is in the club if they're thinking about joining. And the
>"Members" link should probably say something like "Members only area"--it's
>where I expected to find the list of members.
>
>2) I think the link to the home page should be in the upper left navigation
>bar, along with "Activities", etc.
>
>3) There's mention of a "TEI Boar" on this page:
>
>It's probably a typo for "TEI Board," but it evokes a lot of vivid imagery.
>  
>
Thanks, I'll see if I can fix these up later

sebastian

From nsmith at email.unc.edu  Fri Mar 11 11:57:08 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Fri, 11 Mar 2005 11:57:08 -0500
Subject: [tei-council] another new look
References: <4231A33A.5000002@computing-services.oxford.ac.uk>
Message-ID: <011801c5265b$5d0cda50$6401a8c0@lib.unc.edu>

Hello:

I like the look - clean and elegant. I think it's big step forward and it
certainly reflects current webpages "look and feel."

A few suggestions:

  1.. I think the order of options of the main page should be different -
the "main stuff" fist:

The TEI Guidelines: the chief deliverable of the TEI project

Projects using the TEI

TEI Tutorials

TEI Software

TEI History

Just the FAQ

Then about TEI-C:

All about the TEI Consortium: its organization and constitution

List of current members (I agree with Perry that it's a very important
attracting point)

Activities: ongoing activities organized by the TEI consortium

SIGs

How to join

Members only area

Maybe we can even divide those two different - at least in my mind - groups
of topics more visually on the main page.

 2. Subsequently, the order on the upper navigation bar/ header on every
page should be changed

from

Activities | Consortium | FAQs | Guidelines | History | Join in/Contact |
Members | Projects | SIGs | Software | Tutorials

To something like:

Home| Guidelines| Projects | Tutorials| Software| Activities| Consortium |
History | Join in/Contact | Members |FAQs

Actually, I would even propose to consider dividing those links between
header and footer, and moving links to TEI-C-related topics to the footer.
Pages on average are not that long and links will note be lost from users'
eyes.

Header:

Home | Guidelines | Projects | Tutorials | Software | History |

Footer:

Consortium | Members [List of current members not "Members only area"]  |
Activities | Join in/Contact us | FAQs | Members only area

3. Bread crumbs are great - I love them. I would suggest though to make them
of a smaller font (that what they usually are on pages), otherwise they
blend with the header.

4. I am not sure I am clear what "Skip links" means. What does it do? Not
much, but it distracts from more important information and make page
unnecessary busy.

5. on page http://www.tei-c.org:81/Faq/#rh-col I am not sure you need the
list of FAQs both as a list and TOC on the left side. It's a bit confusing.

6. Page http://www.tei-c.org:81/Software/

TOC on the left contains two divs - 1. TEI-Specific tools and 2. Generic
tools

The Software page itself is the same as div1 "TEI-Specific tools". Maybe it
should include a short intro to two following sections of "TEI-Specific" and
"Generic" tools? Also, it would be helpful if on page "Generic Tools" 9
http://www.tei-c.org:81/Software/index.xml.ID=body.1_div.2)  breadcrumbs to
have the full path -Home>Software>Generic Tools, and to be truncated on
Software.

7. I would suggest to link TEI-C logo to the home page (usability studies
show that people tend to click on any logo, or identity-like symbols.

8. Finally, I would suggest to get rid of a link to "TEI home page" on the
right side under the upper navigation bar -  anyway it's lost among all the
options/links.

Those are my two cents/pennies/kopeks worth comments. Will send more if you
want :-))

Best, ns

----- Original Message ----- 
From: "Sebastian Rahtz" 
To: "TEI Council" 
Cc: 
Sent: Friday, March 11, 2005 8:55 AM
Subject: [tei-council] another new look

> try http://www.tei-c.org:81/ now.
>
> away with all this excessive colouring!
>
> 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 computing-services.oxford.ac.uk  Fri Mar 11 11:55:04 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 11 Mar 2005 16:55:04 +0000
Subject: [tei-council] another new look
In-Reply-To: <011801c5265b$5d0cda50$6401a8c0@lib.unc.edu>
References: <4231A33A.5000002@computing-services.oxford.ac.uk>
	<011801c5265b$5d0cda50$6401a8c0@lib.unc.edu>
Message-ID: <4231CD68.7080607@computing-services.oxford.ac.uk>

Natasha Smith wrote:

>  1.. I think the order of options of the main page should be different -
>the "main stuff" fist:
>  
>
this is a helpful idea, to break up the main panel into "TEI " and "TEI 
Consortium".
I'll have a go at that

sebastian

From nsmith at email.unc.edu  Sat Mar 12 09:32:49 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Sat, 12 Mar 2005 09:32:49 -0500
Subject: [tei-council] review process for P5 (MS chapter) -- vote required
References: 
Message-ID: <006301c52710$5e50f0d0$6401a8c0@lib.unc.edu>

I fully support this constructive and - in my opinion - effective proposal.

best, ns

----- Original Message ----- 
From: "Christian Wittern" 
To: 
Sent: Monday, March 07, 2005 6:19 AM
Subject: [tei-council] review process for P5 (MS chapter) -- vote required

> 
> Dear Council members,
> 
> In an attempt to move forward P5, Lou suggested to me to establish a
> review process for areas in need of specific attention.  One of the
> areas where such a process could be fruitful,  he suggested, would be
> the MS chapter.  We do have a new draft from the WG, but it would be
> good to get a more diversified range of opinions on the currently
> state, especially with view to possible omissions or oversights, etc.
> I would like therefore to ask Council members to form an opinion on
> this issue and express it here on our list.  If the Council accepts
> this, I would like to ask Matthew as the Chair of the MS effort to
> name about 7 or 8 people we could ask to act as reviewers.  If this
> works out well, we might also consider this model for other chapters
> and /or proposed changes.
> 
> All the best,
> 
> Christian
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 

From sschreib at umd.edu  Sat Mar 12 11:29:28 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Sat, 12 Mar 2005 11:29:28 -0500
Subject: [tei-council] review process for P5 (MS chapter) -- vote required
In-Reply-To: 
Message-ID: <200503121629.APR31886@md0.mail.umd.edu>

sounds like an excellent place to start

susan

____________________________________________
Susan Schreibman, PhD
Assistant Dean,  Head of Digital Collections & Research
University of Maryland Libraries
McKeldin Library
University of  Maryland, College Park, 20742
phone: 301 314 0358
fax: 301 314 9408
email: sschreib at umd.edu

-----Original Message-----
From: tei-council-bounces at lists.village.Virginia.EDU
[mailto:tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of
Christian Wittern
Sent: Monday, March 07, 2005 6:20 AM
To: tei-council at lists.village.Virginia.EDU
Subject: [tei-council] review process for P5 (MS chapter) -- vote required

Dear Council members,

In an attempt to move forward P5, Lou suggested to me to establish a
review process for areas in need of specific attention.  One of the
areas where such a process could be fruitful,  he suggested, would be
the MS chapter.  We do have a new draft from the WG, but it would be
good to get a more diversified range of opinions on the currently
state, especially with view to possible omissions or oversights, etc.
I would like therefore to ask Council members to form an opinion on
this issue and express it here on our list.  If the Council accepts
this, I would like to ask Matthew as the Chair of the MS effort to
name about 7 or 8 people we could ask to act as reviewers.  If this
works out well, we might also consider this model for other chapters
and /or proposed changes.

All the best,

Christian
_______________________________________________
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  Sun Mar 13 10:55:46 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Sun, 13 Mar 2005 16:55:46 +0100
Subject: [tei-council] review process for P5 (MS chapter) -- vote required
In-Reply-To: <006301c52710$5e50f0d0$6401a8c0@lib.unc.edu>
References: 
	<006301c52710$5e50f0d0$6401a8c0@lib.unc.edu>
Message-ID: <867dcb02c2af29d11844cb234ba611d2@loria.fr>

So do I.
Laurent

Le 12 mars 05, ? 15:32, Natasha Smith a ?crit :

> I fully support this constructive and - in my opinion - effective 
> proposal.
>
> best, ns
>
> ----- Original Message -----
> From: "Christian Wittern" 
> To: 
> Sent: Monday, March 07, 2005 6:19 AM
> Subject: [tei-council] review process for P5 (MS chapter) -- vote 
> required
>
>
>>
>> Dear Council members,
>>
>> In an attempt to move forward P5, Lou suggested to me to establish a
>> review process for areas in need of specific attention.  One of the
>> areas where such a process could be fruitful,  he suggested, would be
>> the MS chapter.  We do have a new draft from the WG, but it would be
>> good to get a more diversified range of opinions on the currently
>> state, especially with view to possible omissions or oversights, etc.
>> I would like therefore to ask Council members to form an opinion on
>> this issue and express it here on our list.  If the Council accepts
>> this, I would like to ask Matthew as the Chair of the MS effort to
>> name about 7 or 8 people we could ask to act as reviewers.  If this
>> works out well, we might also consider this model for other chapters
>> and /or proposed changes.
>>
>> All the best,
>>
>> 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
>

From Syd_Bauman at Brown.edu  Tue Mar 15 16:25:39 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 15 Mar 2005 16:25:39 -0500
Subject: [tei-council] CARP01: content of 
Message-ID: <16951.21203.614443.33017@emt.wwp.brown.edu>

Everyone is supposed to contribute to the discussion right away, so
that we can get resolution by Thu 17, two days from now. With thanks
to James, John, and Natasha some progress is being made. However, we
are still missing comments from 3/4 of Council -- you know who you
are[1]. 

So go over to
https://sourceforge.net/tracker/index.php?func=detail&aid=1007353&group_id=106328&atid=644065
now, read, & comment. Just to make it more enticing, I'll post
something new there in a few minutes. Be the first to debunk my idea!

Notes
-----
[1] But just in case there's any doubt:
      Alejandro Bia
      Matthew Driscoll
      Julia Flanders
      Sebastian Rahtz
      Laurent Romary
      Susan Schreibman
      Edward Vanhoutte
      C. Perry Willett
      Christian Wittern

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Mar 15 18:38:34 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 16 Mar 2005 08:38:34 +0900
Subject: [tei-council] CARP01: content of 
In-Reply-To: <16951.21203.614443.33017@emt.wwp.brown.edu> (Syd Bauman's
	message of "Tue, 15 Mar 2005 16:25:39 -0500")
References: <16951.21203.614443.33017@emt.wwp.brown.edu>
Message-ID: 

Syd,

Thanks for your effort.  While it might not be running smoothly yet,
it looks like we do actually get some work done this way...

All the best,

Christian

Syd Bauman  writes:

> Everyone is supposed to contribute to the discussion right away, so
> that we can get resolution by Thu 17, two days from now. With thanks
> to James, John, and Natasha some progress is being made. However, we
> are still missing comments from 3/4 of Council -- you know who you
> are[1]. 
>
> So go over to
> https://sourceforge.net/tracker/index.php?func=detail&aid=1007353&group_id=106328&atid=644065
> now, read, & comment. Just to make it more enticing, I'll post
> something new there in a few minutes. Be the first to debunk my idea!
>
>
> Notes
> -----
> [1] But just in case there's any doubt:
>       Alejandro Bia
>       Matthew Driscoll
>       Julia Flanders
>       Sebastian Rahtz
>       Laurent Romary
>       Susan Schreibman
>       Edward Vanhoutte
>       C. Perry Willett
>       Christian Wittern
>
> _______________________________________________
> 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 wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Mar 15 18:42:15 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 16 Mar 2005 08:42:15 +0900
Subject: [tei-council] review process for P5 (MS chapter)  -- vote required
In-Reply-To:  (Christian
	Wittern's message of "Mon, 07 Mar 2005 20:19:55 +0900")
References: 
Message-ID: 

Council members,

It has been almost ten days since I posted this and I have seen three
positive votes (one from Laurent in a private mail).  I would not like
to rely solely on silent consent, so please put your voice on the
record.   We need to be able to come to decisions like these in a
timely manner, so that the work can be done.

All the best,

Christian

Christian Wittern  writes:

> Dear Council members,
>
> In an attempt to move forward P5, Lou suggested to me to establish a
> review process for areas in need of specific attention.  One of the
> areas where such a process could be fruitful,  he suggested, would be
> the MS chapter.  We do have a new draft from the WG, but it would be
> good to get a more diversified range of opinions on the currently
> state, especially with view to possible omissions or oversights, etc.
> I would like therefore to ask Council members to form an opinion on
> this issue and express it here on our list.  If the Council accepts
> this, I would like to ask Matthew as the Chair of the MS effort to
> name about 7 or 8 people we could ask to act as reviewers.  If this
> works out well, we might also consider this model for other chapters
> and /or proposed changes.
>
> All the best,
>
> Christian
> _______________________________________________
> 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 Julia_Flanders at brown.edu  Tue Mar 15 20:05:36 2005
From: Julia_Flanders at brown.edu (Julia Flanders)
Date: Tue, 15 Mar 2005 20:05:36 -0500
Subject: [tei-council] review process for P5 (MS chapter) -- vote required
In-Reply-To: 
References: 

Message-ID: <42378660.10907@brown.edu>

This seems reasonable to me.

Christian Wittern wrote:

>Council members,
>
>It has been almost ten days since I posted this and I have seen three
>positive votes (one from Laurent in a private mail).  I would not like
>to rely solely on silent consent, so please put your voice on the
>record.   We need to be able to come to decisions like these in a
>timely manner, so that the work can be done.
>
>All the best,
>
>Christian
>
>
>
>Christian Wittern  writes:
>
>  
>
>>Dear Council members,
>>
>>In an attempt to move forward P5, Lou suggested to me to establish a
>>review process for areas in need of specific attention.  One of the
>>areas where such a process could be fruitful,  he suggested, would be
>>the MS chapter.  We do have a new draft from the WG, but it would be
>>good to get a more diversified range of opinions on the currently
>>state, especially with view to possible omissions or oversights, etc.
>>I would like therefore to ask Council members to form an opinion on
>>this issue and express it here on our list.  If the Council accepts
>>this, I would like to ask Matthew as the Chair of the MS effort to
>>name about 7 or 8 people we could ask to act as reviewers.  If this
>>works out well, we might also consider this model for other chapters
>>and /or proposed changes.
>>
>>All the best,
>>
>>Christian
>>_______________________________________________
>>tei-council mailing list
>>tei-council at lists.village.Virginia.EDU
>>http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>    
>>
>
>  
>

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Mar 16 03:11:10 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 16 Mar 2005 08:11:10 +0000
Subject: [tei-council] review process for P5 (MS chapter) -- vote required
In-Reply-To: <42378660.10907@brown.edu>
References: 	
	<42378660.10907@brown.edu>
Message-ID: <4237EA1E.8020007@computing-services.oxford.ac.uk>

Julia Flanders wrote:

> This seems reasonable to me.

i vote yea

-- 
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  Thu Mar 17 04:11:14 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 17 Mar 2005 09:11:14 +0000
Subject: [tei-council] review process for P5 (MS chapter) -- vote required
In-Reply-To: 
References: 

Message-ID: <423949B2.50904@oucs.ox.ac.uk>

Christian Wittern wrote:

>Council members,
>
>It has been almost ten days since I posted this and I have seen three
>positive votes (one from Laurent in a private mail).  I would not like
>to rely solely on silent consent, so please put your voice on the
>record.   We need to be able to come to decisions like these in a
>timely manner, so that the work can be done.
>  
>
I think it is a good idea as well.

-James

>All the best,
>
>Christian
>
>
>
>Christian Wittern  writes:
>
>  
>
>>Dear Council members,
>>
>>In an attempt to move forward P5, Lou suggested to me to establish a
>>review process for areas in need of specific attention.  One of the
>>areas where such a process could be fruitful,  he suggested, would be
>>the MS chapter.  We do have a new draft from the WG, but it would be
>>good to get a more diversified range of opinions on the currently
>>state, especially with view to possible omissions or oversights, etc.
>>I would like therefore to ask Council members to form an opinion on
>>this issue and express it here on our list.  If the Council accepts
>>this, I would like to ask Matthew as the Chair of the MS effort to
>>name about 7 or 8 people we could ask to act as reviewers.  If this
>>works out well, we might also consider this model for other chapters
>>and /or proposed changes.
>>
>>All the best,
>>
>>Christian
>>_______________________________________________
>>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  Fri Mar 18 02:41:48 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 18 Mar 2005 16:41:48 +0900
Subject: [tei-council] review process for P5 (MS chapter)  -- vote required
In-Reply-To:  (Christian
	Wittern's message of "Mon, 07 Mar 2005 20:19:55 +0900")
References: 
Message-ID: 

Dear Council members,

There have been no objections but only votes in favor of this
procedure, so I would like to ask Matthew (and Lou) to proceed and
implement it.  Please keep us informed of the progress.

All the best,

Christian Wittern

Christian Wittern  writes:

> Dear Council members,
>
> In an attempt to move forward P5, Lou suggested to me to establish a
> review process for areas in need of specific attention.  One of the
> areas where such a process could be fruitful,  he suggested, would be
> the MS chapter.  We do have a new draft from the WG, but it would be
> good to get a more diversified range of opinions on the currently
> state, especially with view to possible omissions or oversights, etc.
> I would like therefore to ask Council members to form an opinion on
> this issue and express it here on our list.  If the Council accepts
> this, I would like to ask Matthew as the Chair of the MS effort to
> name about 7 or 8 people we could ask to act as reviewers.  If this
> works out well, we might also consider this model for other chapters
> and /or proposed changes.
>
> All the best,
>
> Christian
> _______________________________________________
> 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  Tue Mar 22 03:18:32 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 22 Mar 2005 17:18:32 +0900
Subject: [tei-council] Next council call on Tuesday March 29th, 2005 
Message-ID: 

Dear Council members,

The next conference call is scheduled a week from now.  I would like
to ask council members to revisit the minutes from last call (which I
just visited on the UK site at
http://www.tei-c.org.uk/Council/tcm15.xml?style=printable ; the US
site seems to be encountering difficulties) and look for unfinished 
due items. 

I would also like to ask council members and especially Lou and Syd to
send me items that needs to go in to the agenda.

Finally, with regard to active WG's I'd appreciate if we could be
informed about the recent activity in advance of the call with a short
message to this list. --  Julia, please tell us about how the PB problem
unfolded.  Syd, could you tell us about SO, or ask DD to do so?
Laurent, any news about FS?  Matthew, do you have a list of reviewers
for MS? John, is there anything to report about the SH chapter and
related discussions?

All the best,

Christian

From Syd_Bauman at Brown.edu  Thu Mar 24 11:08:33 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 24 Mar 2005 11:08:33 -0500
Subject: [tei-council] 
Message-ID: <16962.58881.505768.284052@emt.wwp.brown.edu>

Since no one has objected[1] to my proposal of macro.paraContent as
the content of  (and ) for an entire week now, I'm
going to go ahead and implement it.

Note
----
[1] Not that anyone agreed, either.

From Syd_Bauman at Brown.edu  Thu Mar 24 11:14:41 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 24 Mar 2005 11:14:41 -0500
Subject: [tei-council] Next council call on Tuesday March 29th, 2005 
In-Reply-To: 
References: 
Message-ID: <16962.59249.376135.877830@emt.wwp.brown.edu>

> The next conference call is scheduled a week from now.

Egads! Thank you for the reminder. Somehow this had completely
slipped from my calendar.

> I would also like to ask council members and especially Lou and Syd
> to send me items that needs to go in to the agenda.

Nothing jumps to my befuddled mind right now, but will keep you
informed. 

> Syd, could you tell us about SO, or ask DD to do so?

There has been absolutely no activety from SO at all. On the other
hand, the only activity I asked for (and this was some weeks to
months ago) was for Chris Catton to review the new  element
proposed on Sourceforge. I will ask the group to review the SA
chapter at some point, but since I still have quite a bit to do on it
first, I hadn't yet. I don't expect to delve into SA until after I
return from a vacation in April at the earliest.

From Syd_Bauman at Brown.edu  Thu Mar 24 12:13:06 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 24 Mar 2005 12:13:06 -0500
Subject: [tei-council] CARP02:  should be typed
Message-ID: <16962.62754.952831.165370@emt.wwp.brown.edu>

CW> Thanks for your effort. While it might not be running smoothly
CW> yet, it looks like we do actually get some work done this
CW> way...

While you are correct, Christian, personally, I don't think the
"discuss on Sourceforge" plan worked all that well. Fewer than half
of the Council posted any comments at all.

Consideration and Resolution Prod #2
------------- --- ---------- ---- --
I am deliberately once again picking an item which I think Council
can simply solve, as opposed to determine a method to solve, over the
next week.

Some time ago John proposed that  should be in the
'tei.typed' class, in which case it would gain both a type= and a
subtype= attribute.

The Sourceforge artifact is at
  http://sourceforge.net/tracker/index.php?func=detail&aid=980854&group_id=106328&atid=644065

I'd like to straighten all the attributes of . (Remember
that it won't have reg= anymore, as regularization will need to be
expressed as an element, in case it needs to have its language
indicated, e.g.)

We'll give Sourceforge another try. This means that *every* member of
Council should, *right now*, go to the above URL and (after logging
in, if needed) click on the "monitor" button. Even if you don't read
it now, even if you don't post soon (or ever -- which would be bad),
you should start monitoring now.

From jawalsh at indiana.edu  Thu Mar 24 12:21:27 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Thu, 24 Mar 2005 12:21:27 -0500
Subject: [tei-council] Conference Call instructions
Message-ID: <6d6c787dcaae179d2fd0e1d68702eb0f@indiana.edu>

Hi All,

The instructions for dialing in to the conference call are the same as 
last time.

DIAL?? 1-812-856-3550 ........ at recording enter your 4-digit pass 
code (0920) followed by pound (#) sign.

John
| John A. Walsh, Associate Director for Projects and Services
| Digital Library Program / Indiana University Libraries
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 Fax:812-856-2062 

From sebastian.rahtz at computing-services.oxford.ac.uk  Thu Mar 24 12:20:41 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Thu, 24 Mar 2005 17:20:41 +0000
Subject: [tei-council] CARP02:  should be typed
In-Reply-To: <16962.62754.952831.165370@emt.wwp.brown.edu>
References: <16962.62754.952831.165370@emt.wwp.brown.edu>
Message-ID: <4242F6E9.7080601@computing-services.oxford.ac.uk>

I think this is an unfortunate example. Picking on  and saying
"should it be in tei.typed" seems like an inefficient way of reviewing
all the classes and their membership.

I'll comment on SF as well

Sebastian

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Mar 24 19:41:11 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 25 Mar 2005 09:41:11 +0900
Subject: [tei-council] CARP02:  should be typed
In-Reply-To: <16962.62754.952831.165370@emt.wwp.brown.edu> (Syd Bauman's
	message of "Thu, 24 Mar 2005 12:13:06 -0500")
References: <16962.62754.952831.165370@emt.wwp.brown.edu>
Message-ID: 

Syd Bauman  writes:

> CW> Thanks for your effort. While it might not be running smoothly
> CW> yet, it looks like we do actually get some work done this
> CW> way...
>
> While you are correct, Christian, personally, I don't think the
> "discuss on Sourceforge" plan worked all that well. Fewer than half
> of the Council posted any comments at all.

Well, obviously it depends on what you see as "success".  I think that
a strength of the council membership is its diversity, which on the
other hand of course means that not everybody feels inclined to
contribute to every discussion.  We did however have an informed
discussion and somehow arrived at a point where the result seemed
obvious. 

> We'll give Sourceforge another try. This means that *every* member of
> Council should, *right now*, go to the above URL and (after logging
> in, if needed) click on the "monitor" button. Even if you don't read
> it now, even if you don't post soon (or ever -- which would be bad),
> you should start monitoring now.

Which will result in  email messages being sent to our account
whenever somebody posts a new comment -- a real nice feature.

heading over to sf now...

All the best,

Christian

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Mar 24 19:44:24 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 25 Mar 2005 09:44:24 +0900
Subject: [tei-council] CARP02:  should be typed
In-Reply-To: <4242F6E9.7080601@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Thu, 24 Mar 2005 17:20:41 +0000")
References: <16962.62754.952831.165370@emt.wwp.brown.edu>
	<4242F6E9.7080601@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

> I think this is an unfortunate example. Picking on  and saying
> "should it be in tei.typed" seems like an inefficient way of reviewing
> all the classes and their membership.
>

While this is not related directly to this activity as a whole, I
think we also should not let the SF requests completely determine our
working agenda.  The class-review-item has been on our plate for quite
a while and I for one do not see any action (and no obvious place to
start either).

It seems desirable to me to revisit the work plan this coming Tuesday
and think about how we can make best use of the two days in  Paris
next month.

All the best,

Christian

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sat Mar 26 17:33:19 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 27 Mar 2005 07:33:19 +0900
Subject: [tei-council] P5 work process
Message-ID: 

Dear Council members,

A focus of the upcoming conference call, for which I hope to send out
the agenda tomorrow, will have to be the P5 work process and here
especially preparations for the face to face meeting in Paris.

I assume that council members are by now familiar with edw81, at
http://www.tei-c.org/Drafts/edw81.html, which lays out more or less
what needs to be done.  I am wondering if we could ask council members
to adopt two or three chapters and look carefully at them in light of
the issues outlined in edw81 and propose changes.  This seems more
workable than expecting everybody to look at all.  If this seems
acceptable, I would propose that we assign the chapters to council
members on Tuesday.  Please look at edw81 once again and think about
which chapter you would like to adopt.

Happy Easter! if that is happens to be on your agenda today --

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  Sat Mar 26 18:26:39 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 27 Mar 2005 08:26:39 +0900
Subject: [tei-council] parsing odds
Message-ID: 

Sebastian, Lou, Council members

I wonder if this is the right place to raise this, but anyway:

In trying to do something useful with the P5 sources, I tried to
inject them into eXist.  Using the scripts on sf did not produce
anything at all (eXist complains about data not being allowed in the
prolog of teinames.xml etc.), so I used client.sh to upload the
sources.

To my surprise, I found that 29 of the .odd files would not parse. The
reason is that they use entities which have not been declared within
the file (since there is no internal subset in the file, appearently
they are only ment to be referenced from the driver file).  One
solution that has been proposed for this general problem is xinclude
(a recommendation now since Dec.2004). This allows to have internal
subsets, but files can nevertheless be referenced from a driver file.  

So my question is:  Would it make sense to introduce xinclude here to
overcome this?  Am I missing somethign obvious or are there other
obstacles to this?

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 computing-services.oxford.ac.uk  Sat Mar 26 18:36:36 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 26 Mar 2005 23:36:36 +0000
Subject: [tei-council] parsing odds
In-Reply-To: 
References: 
Message-ID: <4245F204.7000004@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>In trying to do something useful with the P5 sources, I tried to
>inject them into eXist.  Using the scripts on sf did not produce
>anything at all (eXist complains about data not being allowed in the
>prolog of teinames.xml etc.)
>
can you expand on this? what scripts? if there are errors,
lets fix them....

> so I used client.sh to upload the
>sources.
>  
>
look at the Makefile target "split", it makes a set of useable XML files
from each chapter, just for this purpose. thats how the eXist database
used by Roma is peopled.

>To my surprise, I found that 29 of the .odd files would not parse. The
>reason is that they use entities which have not been declared within
>the file (since there is no internal subset in the file, appearently
>they are only ment to be referenced from the driver file). 
>
correct. thats the way it is designed to work. for good or bad.

> One
>solution that has been proposed for this general problem is xinclude
>(a recommendation now since Dec.2004). This allows to have internal
>subsets, but files can nevertheless be referenced from a driver file.  
>  
>
one downside is that it limits you to tools which understand
XInclude. support is by no means universal, I think.

I can't quote chapter and verse, but Lou and I have certainly
argued around this, and experimented, on several occasions;
I know I made the XInclude  argument several times, but
we didn't adopt it.

I think its a red herring, to be honest.

-- 
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 Julia_Flanders at brown.edu  Sat Mar 26 20:31:47 2005
From: Julia_Flanders at brown.edu (Julia Flanders)
Date: Sat, 26 Mar 2005 20:31:47 -0500
Subject: [tei-council] P5 work process
In-Reply-To: 
References: 
Message-ID: <42460D03.3080200@brown.edu>

This sounds like a good plan to me.

--Julia

Christian Wittern wrote:

>I assume that council members are by now familiar with edw81, at
>http://www.tei-c.org/Drafts/edw81.html, which lays out more or less
>what needs to be done.  I am wondering if we could ask council members
>to adopt two or three chapters and look carefully at them in light of
>the issues outlined in edw81 and propose changes.  This seems more
>workable than expecting everybody to look at all.  If this seems
>acceptable, I would propose that we assign the chapters to council
>members on Tuesday.  Please look at edw81 once again and think about
>which chapter you would like to adopt.
>
>Happy Easter! if that is happens to be on your agenda today --
>
>All the best,
>
>Christian
>
>
>
>  
>

From nsmith at email.unc.edu  Sun Mar 27 12:09:14 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Sun, 27 Mar 2005 12:09:14 -0500
Subject: [tei-council] P5 work process
References:  <42460D03.3080200@brown.edu>
Message-ID: <003101c532ef$b48e89e0$6401a8c0@lib.unc.edu>

agreed.

best, ns

----- Original Message ----- 
From: "Julia Flanders" 
To: 
Sent: Saturday, March 26, 2005 8:31 PM
Subject: Re: [tei-council] P5 work process

> This sounds like a good plan to me.
> 
> --Julia
> 
> Christian Wittern wrote:
> 
> >I assume that council members are by now familiar with edw81, at
> >http://www.tei-c.org/Drafts/edw81.html, which lays out more or less
> >what needs to be done.  I am wondering if we could ask council members
> >to adopt two or three chapters and look carefully at them in light of
> >the issues outlined in edw81 and propose changes.  This seems more
> >workable than expecting everybody to look at all.  If this seems
> >acceptable, I would propose that we assign the chapters to council
> >members on Tuesday.  Please look at edw81 once again and think about
> >which chapter you would like to adopt.
> >
> >Happy Easter! if that is happens to be on your agenda today --
> >
> >All the best,
> >
> >Christian
> >
> >
> >
> >  
> >
> 
> _______________________________________________
> 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  Sun Mar 27 21:54:06 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 28 Mar 2005 11:54:06 +0900
Subject: [tei-council] parsing odds
In-Reply-To: <4245F204.7000004@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Sat, 26 Mar 2005 23:36:36 +0000")
References: 
	<4245F204.7000004@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

> Christian Wittern wrote:
>
>>In trying to do something useful with the P5 sources, I tried to
>>inject them into eXist.  Using the scripts on sf did not produce
>>anything at all (eXist complains about data not being allowed in the
>>prolog of teinames.xml etc.)
>>
> can you expand on this? what scripts? if there are errors,
> lets fix them....

Well, I suspect it has to do with incompatibilities with the most
recent eXist and SOAP::Lite, but at the moment, I do not have time to
go into this:-(

> look at the Makefile target "split", it makes a set of useable XML files
> from each chapter, just for this purpose. thats how the eXist database
> used by Roma is peopled.

I see.  So I will do accordingly.

> one downside is that it limits you to tools which understand
> XInclude. support is by no means universal, I think.
>
> I can't quote chapter and verse, but Lou and I have certainly
> argued around this, and experimented, on several occasions;
> I know I made the XInclude  argument several times, but
> we didn't adopt it.
>
> I think its a red herring, to be honest.

In that case there is no need to press this issue now.

All the best,

Christian

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Mar 28 01:38:22 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 28 Mar 2005 15:38:22 +0900
Subject: [tei-council] Agenda for conference call of the TEI Council on
 2005-03-29 at 1300 UTC
Message-ID: 

TEI Council Members and Editors:

This is the agenda for the conference call the TEI Council will
hold tomorrow, Tuesday, March. 29, 2005 at 1300 UTC.

Please read through the following, in advance of the call.  

INSTRUCTIONS for conference call:

Participants will dial in to +1 812 856 3550.

When prompted, enter the code "0920" followed by "#".

Expected members to participate:

Syd Bauman, Alejandro Bia, Lou Burnard, James Cummings, Matthew
Driscoll, Julia Flanders, Sebastian Rahtz, Laurent Romary, Natasha
Smith, Susan Schreibman, Edward Vanhoutte, John Walsh, Perry Willett,
Christian Wittern.

Agenda:

6 items, not more than 10-20 minutes apiece.

-----------------------------------------------------

1) Review of the minutes from the call of Jan. 31th (10 min)

   Minutes of the meeting are at
   http://www.tei-c.org/Council/tcm15.html. Review of action items,
   progress.

------------------------------------------------------------

2) Review of WG etc. progress (10 min) : 

  Standoff Markup,  Feature Structures, Physical
  Bibliography, biblItem, IHS

-----------------------------------------------------

3) P5 progress 

Christain Wittern writes:  (20 min)

"I assume that council members are by now familiar with edw81, at
http://www.tei-c.org/Drafts/edw81.html, which lays out more or less
what needs to be done.  I am wondering if we could ask council members
to adopt two or three chapters and look carefully at them in light of
the issues outlined in edw81 and propose changes.  This seems more
workable than expecting everybody to look at all.  If this seems
acceptable, I would propose that we assign the chapters to council
members on Tuesday.  Please look at edw81 once again and think about
which chapter you would like to adopt."

In preparation, council members are also encouraged to look at the P5
CVS available from tei.sf.net

We will also need to think about other open issues of P5, e.g. a
review of the tei class system.

-----------------------------------------------------

4) Council work procedure for resolving open issues in the SF tracking
   system (10 min)

Since the last call, we tried to implement a procedure to resolve
stuff on SF.  I'd like to review and refine the procedure in light of
our experiences.

-----------------------------------------------------

5) Other business  (5 minutes)

   TBA

-----------------------------------------------------

6) Meetings: (5 minutes)

   Face to Face meeting in Paris, AFNOR April 28-29, 2005.

From lou.burnard at computing-services.oxford.ac.uk  Mon Mar 28 05:48:03 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 28 Mar 2005 11:48:03 +0100
Subject: [tei-council] Agenda for conference call of the TEI Council on
	2005-03-29 at 1300 UTC
In-Reply-To: 
References: 
Message-ID: <4247E0E3.8010002@computing-services.oxford.ac.uk>

Could we also add a review of edw86 to the agenda? This is the document 
I circulated to this list on 5 March about the "rationalization of 
attributes" : see my note of 5 March with the subject "P5 Progress Report"

Christian Wittern wrote:
> 
> TEI Council Members and Editors:
> 
> This is the agenda for the conference call the TEI Council will
> hold tomorrow, Tuesday, March. 29, 2005 at 1300 UTC.
> 
> Please read through the following, in advance of the call.  
> 
> 
> INSTRUCTIONS for conference call:
> 
> Participants will dial in to +1 812 856 3550.
> 
> When prompted, enter the code "0920" followed by "#".
> 
> 
> Expected members to participate:
> 
> Syd Bauman, Alejandro Bia, Lou Burnard, James Cummings, Matthew
> Driscoll, Julia Flanders, Sebastian Rahtz, Laurent Romary, Natasha
> Smith, Susan Schreibman, Edward Vanhoutte, John Walsh, Perry Willett,
> Christian Wittern.
> 
> 
> Agenda:
> 
> 6 items, not more than 10-20 minutes apiece.
> 
> -----------------------------------------------------
> 
> 
> 1) Review of the minutes from the call of Jan. 31th (10 min)
> 
>    Minutes of the meeting are at
>    http://www.tei-c.org/Council/tcm15.html. Review of action items,
>    progress.
> 
> 
> 
> ------------------------------------------------------------
> 
> 2) Review of WG etc. progress (10 min) : 
> 
>   Standoff Markup,  Feature Structures, Physical
>   Bibliography, biblItem, IHS
> 
> 
> 
> -----------------------------------------------------
> 
> 3) P5 progress 
> 
> Christain Wittern writes:  (20 min)
> 
> "I assume that council members are by now familiar with edw81, at
> http://www.tei-c.org/Drafts/edw81.html, which lays out more or less
> what needs to be done.  I am wondering if we could ask council members
> to adopt two or three chapters and look carefully at them in light of
> the issues outlined in edw81 and propose changes.  This seems more
> workable than expecting everybody to look at all.  If this seems
> acceptable, I would propose that we assign the chapters to council
> members on Tuesday.  Please look at edw81 once again and think about
> which chapter you would like to adopt."
> 
> In preparation, council members are also encouraged to look at the P5
> CVS available from tei.sf.net
> 
> We will also need to think about other open issues of P5, e.g. a
> review of the tei class system.
> 
> -----------------------------------------------------
>  
> 4) Council work procedure for resolving open issues in the SF tracking
>    system (10 min)
> 
> Since the last call, we tried to implement a procedure to resolve
> stuff on SF.  I'd like to review and refine the procedure in light of
> our experiences.
> 
> 
> -----------------------------------------------------
> 
> 5) Other business  (5 minutes)
> 
> 
>    TBA
> 
> 
> -----------------------------------------------------
> 
> 6) Meetings: (5 minutes)
> 
>    Face to Face meeting in Paris, AFNOR April 28-29, 2005.
> 
> 
> _______________________________________________
> 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 28 08:01:55 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 28 Mar 2005 22:01:55 +0900
Subject: [tei-council] Agenda for conference call of the TEI Council on
	2005-03-29 at 1300 UTC
In-Reply-To: <4247E0E3.8010002@computing-services.oxford.ac.uk> (Lou
	Burnard's message of "Mon, 28 Mar 2005 11:48:03 +0100")
References: 
	<4247E0E3.8010002@computing-services.oxford.ac.uk>
Message-ID: 

Lou Burnard  writes:

> Could we also add a review of edw86 to the agenda? This is the
> document I circulated to this list on 5 March about the
> "rationalization of attributes" : see my note of 5 March with the
> subject "P5 Progress Report"

Sorry, this must have escaped my attention.  Yes, we will also discuss
http://www.tei-c.org.uk/Drafts/edw86.xml?style=printable -- under item
3) seems to be the best fit.

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 computing-services.oxford.ac.uk  Mon Mar 28 16:11:24 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 28 Mar 2005 22:11:24 +0100
Subject: [tei-council] P5 work process
In-Reply-To: 
References: 
Message-ID: <424872FC.6090003@computing-services.oxford.ac.uk>

As another contribution to the debate, I have written 
http://www.tei-c.org/Drafts/edw87.xml, which attempts
to set some rules by which the TEI class system could be revised, and 
provides some data on
the subject.

My view is that the most effective way to proceed is to agree these 
rules (or amend them),
and then for one person to go off and prepare a complete worked-through
proposal for all the new names and memberships. Hopefully, this would be 95%
non-controversial, and the council would argue about the edge cases.

I would very much like to see _more_ rules about how to construct names 
of things!

If you haven't thought about TEI classes and their naming before,
this is probably dry stuff. But this stuff is going to become more and 
more visible,
and it behooves us to get it looking right.

Note that this work  would be

 * low-impact from the point of view of existing documents;
 * low-impact for authors and editors
 * (very very) high-impact for people who edit schemas or DTDs by hand
 * moderately high impact for people who write ODDs (ie one could write 
a converter)

-- 
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 Julia_Flanders at Brown.edu  Mon Mar 28 16:42:03 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Mon, 28 Mar 2005 16:42:03 -0500
Subject: [tei-council] Agenda for conference call of the TEI Council
	on 	2005-03-29 at 1300 UTC
In-Reply-To: <4247E0E3.8010002@computing-services.oxford.ac.uk>
References: 
	<4247E0E3.8010002@computing-services.oxford.ac.uk>
Message-ID: 

Lou, looking at the discusson on SourceForge and at your summary in 
edw86, could I ask for a bit of clarification? edw86 proposes that 
text attributes be treated as a child of their original parent 
element, and that

"The content models for elements bearing such attributes should be 
expanded to include . The proposed tei.remarks class 
has the following members:  , ,  (and 
 if we really need it which I doubt),  (if different 
from  which I doubt),  and probably some others yet to be 
determined."

However, on SourceForge your initial proposal centered on elements 
from macro.glossSeq (altIdent?, equiv*, gloss?, desc?). Which one 
represents the proposal we should be considering?

Julia

At 11:48 AM +0100 3/28/05, Lou Burnard wrote:
>Could we also add a review of edw86 to the agenda? This is the 
>document I circulated to this list on 5 March about the 
>"rationalization of attributes" : see my note of 5 March with the 
>subject "P5 Progress Report"

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Mar 29 04:02:37 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 29 Mar 2005 18:02:37 +0900
Subject: [tei-council] Todays call at UTC 1300
Message-ID: 

Council members,

this is just a short note to remind you that todays call starts at
1300 UTC.  If the place you are staying has switched to Daylight
Saving Time (or even "Summertime"), it will not be the same local time
as the last call in January.  Please take that into account when
dialing in.

Talk to you in 4 hours from now,

Christian

-- 

 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From edward.vanhoutte at kantl.be  Tue Mar 29 08:00:20 2005
From: edward.vanhoutte at kantl.be (Edward Vanhoutte)
Date: Tue, 29 Mar 2005 15:00:20 +0200
Subject: [tei-council] Conference Call instructions
In-Reply-To: <6d6c787dcaae179d2fd0e1d68702eb0f@indiana.edu>
References: <6d6c787dcaae179d2fd0e1d68702eb0f@indiana.edu>
Message-ID: <42495164.9080308@kantl.be>

Dear all,

on trying to dial in, I get the message that "access to this conference 
has been restricted". How should I proceed to get access?

Edward

John A. Walsh wrote:

> Hi All,
> 
> The instructions for dialing in to the conference call are the same as 
> last time.
> 
> DIAL   1-812-856-3550 ........ at recording enter your 4-digit pass code 
> (0920) followed by pound (#) sign.
> 
> John
> | John A. Walsh, Associate Director for Projects and Services
> | Digital Library Program / Indiana University Libraries
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | Voice:812-855-8758 Fax:812-856-2062 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 

-- 

----------------
Weg met het plan voor de verkoop van het Academiegebouw en de verhuizing 
van de Koninklijke Academie voor Nederlandse Taal- en Letterkunde. Teken 
de petitie op 

No to the sale of the building of the Royal Academy of Dutch Language 
and Literature and the planned relocation of the Academy. Sign the 
petition on 

================
Edward Vanhoutte
Coordinator
Centrum voor Teksteditie en Bronnenstudie - CTB (KANTL)
Centre for Scholarly Editing and Document Studies
Associate Editor, Literary and Linguistic Computing
Koninklijke Academie voor Nederlandse Taal- en Letterkunde
Royal Academy of Dutch Language and Literature
Koningstraat 18 / b-9000 Gent / Belgium
tel: +32 9 265 93 51 / fax: +32 9 265 93 49
edward dot vanhoutte at kantl dot be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm

From lou.burnard at computing-services.oxford.ac.uk  Tue Mar 29 07:59:27 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 29 Mar 2005 13:59:27 +0100
Subject: [tei-council] Conference Call instructions
In-Reply-To: <42495164.9080308@kantl.be>
References: <6d6c787dcaae179d2fd0e1d68702eb0f@indiana.edu>
	<42495164.9080308@kantl.be>
Message-ID: <4249512F.20303@computing-services.oxford.ac.uk>

I was just wodnering the same thing...

Edward Vanhoutte wrote:

> Dear all,
> 
> on trying to dial in, I get the message that "access to this conference 
> has been restricted". How should I proceed to get access?
> 
> Edward
> 
> John A. Walsh wrote:
> 
>> Hi All,
>>
>> The instructions for dialing in to the conference call are the same as 
>> last time.
>>
>> DIAL   1-812-856-3550 ........ at recording enter your 4-digit pass 
>> code (0920) followed by pound (#) sign.
>>
>> John
>> | John A. Walsh, Associate Director for Projects and Services
>> | Digital Library Program / Indiana University Libraries
>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
>> | Voice:812-855-8758 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 pwillett at umich.edu  Tue Mar 29 08:01:16 2005
From: pwillett at umich.edu (Perry Willett)
Date: Tue, 29 Mar 2005 08:01:16 -0500
Subject: [tei-council] Conference Call instructions
In-Reply-To: <4249512F.20303@computing-services.oxford.ac.uk>
Message-ID: <001301c5345f$67d92a30$922bd38d@CLUBSODA>

Seems to work now.

-----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: Tuesday, March 29, 2005 7:59 AM
To: Edward Vanhoutte
Cc: TEICouncil Council'
Subject: Re: [tei-council] Conference Call instructions

I was just wodnering the same thing...

Edward Vanhoutte wrote:

> Dear all,
> 
> on trying to dial in, I get the message that "access to this conference 
> has been restricted". How should I proceed to get access?
> 
> Edward
> 
> John A. Walsh wrote:
> 
>> Hi All,
>>
>> The instructions for dialing in to the conference call are the same as 
>> last time.
>>
>> DIAL   1-812-856-3550 ........ at recording enter your 4-digit pass 
>> code (0920) followed by pound (#) sign.
>>
>> John
>> | John A. Walsh, Associate Director for Projects and Services
>> | Digital Library Program / Indiana University Libraries
>> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
>> | Voice:812-855-8758 Fax:812-856-2062 
>> _______________________________________________
>> 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 computing-services.oxford.ac.uk  Tue Mar 29 10:05:51 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 29 Mar 2005 16:05:51 +0100
Subject: [tei-council] edw86
Message-ID: <42496ECF.8000605@computing-services.oxford.ac.uk>

just for fun, I made EDW86 start with  instead of , which makes
it render differently. Just in case you were confused....

I just said to Lou, and he agreed, that the best way forward is to merge
the Principles sections of  edw86 and edw87 into one doc, and merge
the Practices sections of both into one (separate) doc. there is sufficient
overlap between the two principles to make it worth combining them in 
the same style.

-- 
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 computing-services.oxford.ac.uk  Tue Mar 29 10:44:02 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 29 Mar 2005 16:44:02 +0100
Subject: [tei-council] making TEI CVS more useable
Message-ID: <424977C2.3000306@computing-services.oxford.ac.uk>

after a brief chat with James, I have made some changes to the top-level 
Makefile for TEI P5
as found in CVS:

 - make it use http://www.tei-c.org/stylesheet for the source of its XSL 
(override with ${S})
 - add an "install" target which creates a suitable hierarchy in 
${PREFIX} (defaults to /usr/local/tei)

James will now review this, pretending to be a real person, and write an
appropriate top-level README document explaining what the Makefile is
for, what the dependencies are, what the uses are that you might make of it.
This document will intertwingle a bit with what Lou is writing; hopefully
at the end of it, the person who wants to grab TEI P5 from CVS and create
schemas which they can use in Oxygen will have some idea what to do.

-- 
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 pwillett at umich.edu  Tue Mar 29 17:19:12 2005
From: pwillett at umich.edu (Perry Willett)
Date: Tue, 29 Mar 2005 17:19:12 -0500
Subject: [tei-council] biblItem proposal and discussion
In-Reply-To: 
Message-ID: <007101c534ad$58d15eb0$922bd38d@CLUBSODA>

There was some question during the conference call about just where the
discussion around this biblItem proposal could be found. There were probably
announcements galore about this that went by me, but there's a separate
Sourceforge project called "xml-bibliography":

I'll try to summarize the discussion there and bring the proposal
up-to-date.

Perry Willett
University of Michigan
pwillett at umich.edu

PS--sorry I had to leave the conf call at 14:30 UTC--had another meeting.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Mar 29 21:07:25 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 30 Mar 2005 11:07:25 +0900
Subject: [tei-council] edw86
In-Reply-To: <42496ECF.8000605@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Tue, 29 Mar 2005 16:05:51 +0100")
References: <42496ECF.8000605@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

> I just said to Lou, and he agreed, that the best way forward is to merge
> the Principles sections of  edw86 and edw87 into one doc, and merge
> the Practices sections of both into one (separate) doc. there is sufficient
> overlap between the two principles to make it worth combining them in
> the same style.

That would certainly be helpful. 

The discussion of this yesterday did not reveal any strong opposition
to this and certainly can be seen as an indication that the Council
thinks this is the right direction.  I also agree to the opinions
expressed that we should strive to finalize these proposals in Paris.

In preparation for this, I wonder if we could have a (albeit
preliminary) implementation of this.  At least for me, it is always
easier to think about this, if I can have some examples for playing
around with.  I also think that such an implementation would make it
easier to discover areas that need further attention and have not
fully been developed so far.

Any opinions?

All the best,

Christian

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Mar 30 02:59:41 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 30 Mar 2005 08:59:41 +0100
Subject: [tei-council] edw86
In-Reply-To: 
References: <42496ECF.8000605@computing-services.oxford.ac.uk>

Message-ID: <424A5C6D.1090504@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>In preparation for this, I wonder if we could have a (albeit
>preliminary) implementation of this. 
>  
>
What do you want an implementation of? most of the work
proposed is attribute -> element renames, renaming classes,
and changing membership, etc which does not need any software.

Something that is _hard_ to implement is the system whereby 
and  inherit a "type" attribute from a "teiatt.typed" class, but
specify different constraints (value lists). After a long discussion
with Lou last night, I realized that this needs a fairly serious rewrite
of Odd to RelaxNG. That is  Good Thing, as it will solve
some other problems, but don't expect it before Paris.

Much of what those EDW documents propose is simply cleaning and 
rationalizing.

Sebastian

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Mar 30 17:33:35 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 31 Mar 2005 07:33:35 +0900
Subject: [tei-council] edw86
In-Reply-To: <424A5C6D.1090504@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Wed, 30 Mar 2005 08:59:41 +0100")
References: <42496ECF.8000605@computing-services.oxford.ac.uk>

	<424A5C6D.1090504@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

> Christian Wittern wrote:
>
>>In preparation for this, I wonder if we could have a (albeit
>> preliminary) implementation of this.  
>>
> What do you want an implementation of? most of the work
> proposed is attribute -> element renames, renaming classes,
> and changing membership, etc which does not need any software.

I was especially thinking about the attribute->child element process.
Here we need to think about content models, sibling-relationship etc.
This is where I would like to see a ODD or Schema that actually
implements this, even if that is only experimental.

>
> Something that is _hard_ to implement is the system whereby 
> and  inherit a "type" attribute from a "teiatt.typed" class, but
> specify different constraints (value lists). After a long discussion
> with Lou last night, I realized that this needs a fairly serious rewrite
> of Odd to RelaxNG. That is  Good Thing, as it will solve
> some other problems, but don't expect it before Paris.
>

Does this also require changes to ODD?

> Much of what those EDW documents propose is simply cleaning and
> rationalizing.
>
That is what I understand;-0

All the best,

Christian

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Mar 30 17:38:37 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 30 Mar 2005 23:38:37 +0100
Subject: [tei-council] edw86
In-Reply-To: 
References: <42496ECF.8000605@computing-services.oxford.ac.uk>		<424A5C6D.1090504@computing-services.oxford.ac.uk>

Message-ID: <424B2A6D.5070501@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>I was especially thinking about the attribute->child element process.
>Here we need to think about content models, sibling-relationship etc.
>This is where I would like to see a ODD or Schema that actually
>implements this, even if that is only experimental.
>
>  
>
I'll have to leave that to Lou. He can fork P5 and make an experimental
release.

>>Something that is _hard_ to implement is the system whereby 
>>and  inherit a "type" attribute from a "teiatt.typed" class, but
>>specify different constraints (value lists). After a long discussion
>>with Lou last night, I realized that this needs a fairly serious rewrite
>>of Odd to RelaxNG. That is  Good Thing, as it will solve
>>some other problems, but don't expect it before Paris.
>>
>>Does this also require changes to ODD?
>>
>>    
>>
I believe not. It may require some decisions about what
certain combinations of ODD markup actually mean

I hope I'll know in a month.

-- 
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  Thu Mar 31 16:43:43 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop)
Date: Thu, 31 Mar 2005 22:43:43 +0100
Subject: [tei-council] Minutes available
Message-ID: <424C6F0F.8090700@oucs.ox.ac.uk>

Apologies for the slight delay in getting this done... notes from the 
council phone call on Tuesday are now online at 
http://www.tei-c.org/Council/tcm16.xml

Please review for errors or omissions, and please also note that we seem 
to have agreed to give ourselves lots of work to do this month...

Lou

From lou.burnard at computing-services.oxford.ac.uk  Thu Mar 31 17:04:21 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop)
Date: Thu, 31 Mar 2005 23:04:21 +0100
Subject: [tei-council] delayed note for reviewers
Message-ID: <424C73E5.5070904@oucs.ox.ac.uk>

I've just remembered that this listserv not only declines to forward 
notes with attachments, but doesnt tell you that it hasn't.

Which is why the following (cut and pasted this time) didn't get to you 
36 hours ago....

As promised earlier, here's a draft of the letter Matthew and I are 
proposing to send out to potential reviewers of the MS chapter.  
Comments and suggestions for improvement gratefully received: we need to 
get this rolling in a week or so though.

Lou

------------------------------------------------------------------------

Notes for Reviewers of P5 drafts

Thank you for agreeing to participate in a formal review of a new or
significantly changed section in the TEI Guidelines. Your input will
be of great assistance to the TEI Editors and the TEI Technical
Council in the production of TEI P5, and is much appreciated.

You are encouraged both to make general comments about the usability or
relevance of the draft material under review, and to make specific
suggestions for any changes you think advisable or essential. At this
stage, proof reading and reporting of typographic errors are of lesser
importance, but notification of any such errors will also be gratefully
received. 

The questions we would like you to address in your review are:

- coverage: does the draft cover all significant topics relevant to the
  subject matter? are all aspects of the topics addressed  treated
  adequately and consistently? 

- clarity: is the draft likely to be comprehensible to its intended
  audience? is its treatment of specialised topics accessible to the
  well-informed but non-specialist reader? 

- correctness: are the encoding techniques proposed in the draft
  adequate to the needs of the community? do you envisage any
  particular problems in converting between the draft's
  recommendations and any other encoding system commonly used in the
  field?

- consistency: is the draft internally consistent in its style and
coverage, or are some topics treated less adequately than others? are
the recommendations of the draft consistent in style and substance
with the rest of the TEI Guidelines?

Wherever possible, please supply clear indications of what in your
opinion is necessary to improve the draft. Specific suggestions are
much more helpful than general statements.

Please review the examples as well as the descriptive text: any
suggestions for additional or alternative usage examples for the
topics described are particularly helpful.

Please also, if possible, test the recommendations of the chapter in
your own TEI processing environment. To do this,we recommend you to
download and install a complete release of TEI P5, since there are
likely to be interdependencies between almost any part of the
Guidelines and any other, even for a relatively self-contained chapter
such as that on manuscript description. Information on how to download
is provided at http://www.tei-c.org/P5/index.xml and a more detailed
document on how to install the new system is in preparation (a draft
is available at http://www.tei-c.org/Drafts/edw88.xml).

The full release also includes some sample testfiles which may be
useful as a template for your own testing: look at the files in the
Test directory

If you plan only to review the prose of the
draft, then of course you need only access the relevant web pages at
http://www.tei-c.org/P5/Guidelines/

Your review can be as long or as short as you think fit. If you would like
to discuss aspects of the review with other specialists in
the field, please use the discussion list maintained by the TEI SIG in
Manuscripts Join 
	    mailing list. 
Please send a copy of your final review to the address
editors at tei-c.org by 15 May 2005.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Mar 31 23:08:18 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 01 Apr 2005 13:08:18 +0900
Subject: [tei-council] delayed note for reviewers
In-Reply-To: <424C73E5.5070904@oucs.ox.ac.uk> (Lou's Laptop's message of
	"Thu, 31 Mar 2005 23:04:21 +0100")
References: <424C73E5.5070904@oucs.ox.ac.uk>
Message-ID: 

This looks entirely adequate to me, altough I did not have a chance to
look at the linked documents, since tei-c.org seems to be taking a nap.

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 computing-services.oxford.ac.uk  Fri Apr  1 03:54:49 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 01 Apr 2005 09:54:49 +0100
Subject: [tei-council] delayed note for reviewers
In-Reply-To: 
References: <424C73E5.5070904@oucs.ox.ac.uk> 
Message-ID: <424D0C59.60205@computing-services.oxford.ac.uk>

Christian Wittern wrote:
> This looks entirely adequate to me, altough I did not have a chance to
> look at the linked documents, since tei-c.org seems to be taking a nap.

I attempted to look at the minutes of the conference call and
had the same problem.  Moreover, when I tried to look at them
on the org.uk mirror, I got errors.  Which I'll now go see if I can correct.

http://www.tei-c.org.uk/Council/tcm16.xml

-----------------

Message: The end-tag for element type "label" must end with a '>' delimiter.

Description: org.apache.cocoon.ProcessingException: Failed to execute 
pipeline.: 
file:/rts-dev/www/tei/htdocs/Council/tcm16.xml:97:15:org.xml.sax.SAXParseException: 
The end-tag for element type "label" must end with a '>' delimiter.

Sender: org.apache.cocoon.servlet.CocoonServlet

Source: Cocoon Servlet

Request URI

TEIC/Council/tcm16.xml

column

15

line

97

cause

org.xml.sax.SAXParseException: The end-tag for element type "label" must 
end with a '>' delimiter.

location

file:/rts-dev/www/tei/htdocs/Council/tcm16.xml

request-uri

/exist/TEIC/Council/tcm16.xml

-----------------

-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  Fri Apr  1 18:44:43 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 02 Apr 2005 08:44:43 +0900
Subject: [tei-council] delayed note for reviewers
In-Reply-To: <424D0C59.60205@computing-services.oxford.ac.uk> (James
	Cummings's message of "Fri, 01 Apr 2005 09:54:49 +0100")
References: <424C73E5.5070904@oucs.ox.ac.uk> 
	<424D0C59.60205@computing-services.oxford.ac.uk>
Message-ID: 

James Cummings  writes:

> I attempted to look at the minutes of the conference call and
> had the same problem.  Moreover, when I tried to look at them
> on the org.uk mirror, I got errors.  Which I'll now go see if I can correct.
>
> http://www.tei-c.org.uk/Council/tcm16.xml

Thanks for validating the notes, and thanks to Lou for writing them
up. They are now visible even here and look good to me.  We do indeed
have a lot on the plate, but I am confident that we now are on a good
track to a successful meeting in Paris and for further development of
P5. 

For those who have not yet sent me their preferences for adopting a
chapter, please do so now!

All the best,

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  Sat Apr  2 16:29:26 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 2 Apr 2005 16:29:26 -0500
Subject: [tei-council] biblItem proposal and discussion
In-Reply-To: <007101c534ad$58d15eb0$922bd38d@CLUBSODA>
References: 
	<007101c534ad$58d15eb0$922bd38d@CLUBSODA>
Message-ID: <16975.3766.77777.196382@emt.wwp.brown.edu>

IIRC from the conference call, Lou would like Council to take a look
at  and , compare and contrast them, and
ascertain which one, or both, should be in P5. If I understand
correctly Perry is going to bring the proposal document[1] up-to-date
(it is quite outdated -- still has that  thing,
which is just oh so 2004 :-).

Ideally there would be a working paper on this issue for you to read
written by some combination of me, Perry, Paul Tremblay, and the
xml-biblio group. However, I'm going away for the next week and a
half, and most likely will not be able to put any significant effort
into such a project during my trip.

In the interim,  is discussed, including examples, in the
released versions of P5 (0.1.1 & 0.1.2) [2], pretty much untouched
from P4.  is discussed in subsequent versions which can be
checked out from the CVS source tree; one such version can be viewed
at http://bauman.zapto.org/~syd/Guidelines/ref-BIBLITEM.html. Note
that there are 2 relatively simple examples on that page, but the
examples in the main text of the Guidelines have not yet been changed
from  to .

Notes
-----
[1] http://www.tei-c.org/Council/sfw01.xml
[2] http://prdownloads.sourceforge.net/tei/tei-p5-doc-0.1.2.zip?download
    See file tei-p5-doc-0.1.1/Guidelines/ref-BIBLSTRU.html

From nsmith at email.unc.edu  Sun Apr  3 21:05:03 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Sun, 3 Apr 2005 21:05:03 -0400
Subject: [tei-council] Minutes available
References: <424C6F0F.8090700@oucs.ox.ac.uk>
Message-ID: <00c501c538b2$55812bb0$6401a8c0@lib.unc.edu>

Thank you, Lou, for making the minutes available. The UVa site is still "at
rest", but the UK's is good as it can be.

just one small slip:

2nd para in "3. Work on P5":
instead of ED86 and EDW87, should be EDW86 and EDW87

Also, in your "note to reviewers" I would suggest to include the uk address,
as an alternative url. I do not know what's going on at UVa (and for how
long it will continue), but I've been having trouble connecting to the main
site repeatedly.

Indeed, a lot to do...

best, ns

----- Original Message ----- 
From: "Lou's Laptop" 
To: 
Sent: Thursday, March 31, 2005 5:43 PM
Subject: [tei-council] Minutes available

> Apologies for the slight delay in getting this done... notes from the
> council phone call on Tuesday are now online at
> http://www.tei-c.org/Council/tcm16.xml
>
> Please review for errors or omissions, and please also note that we seem
> to have agreed to give ourselves lots of work to do this month...
>
> Lou
>
>
> _______________________________________________
> 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  Wed Apr  6 23:06:53 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 07 Apr 2005 12:06:53 +0900
Subject: [tei-council] P5 Chapter review
Message-ID: 

Dear Council members,

As promised, here the results of the "Adopt a Chapter" action.  I have
received four responses, one of them (SB) said he could not review
chapters.  The other three wished to adopt the following:

Edward:

PH, TC, PR

James:

In order of preference:

SG - Gentle Intro
PH - Transcription Primary Sources
ND - Names & Dates
DR - Drama
HD - Header

Natasha:

      1. HD The TEI Header (already working on w/John Walsh)

2. SH  The independent header (already working on w/John Walsh)

     3. CO Elements Available in All TEI Documents

4. PR Base Tag Set form Prose

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

With this, I would like to suggest the following:

Edvard, please look at PH, TC, PR

Natasha and John please look at HD, SH (& CR if possible) and CO

James, please adopt SG, ND and DR -- James said, he would prefer to
collaborate, so if anybody would like to work with him, please talk to
him directly

Christian will look at  DS, DI and AI.  Since I worked on CH and WD, I
would prefer if sb else could review them, but I'd be happy to
collaborate on that.

Other chapters in need of review, in my order of preference:

VE Verse Base
TS Speech Transcription 
CE Certainty
GD Graphs etc
CC Corpora

So those who are yet undecided, please select from them in preference.

For these new chapters or substantially changed chapters: CH, WD, FS,
FD, SA I think we might be better off in adopting a process for
external review, if the test-run with MS looks promising.

While detailed reviews might not be ready for the Paris meeting, I
would like to alot time for a preliminary report, so please start
working as soon as possible!

All the best,

Christian

From lou.burnard at computing-services.oxford.ac.uk  Sun Apr 10 16:28:39 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop)
Date: Sun, 10 Apr 2005 20:28:39 +0000
Subject: [tei-council] P5 how to 
Message-ID: <42598C77.4080102@oucs.ox.ac.uk>

I have made a bit more progress on the promised "Getting started with 
P5" howto document: enough to make it seem worthwhile posting on the web 
for your comment, and (I hope) offers of help to expand it a bit more....

Please have a quick look at http://www.tei-c.org/P5/p5howto.xml and let 
me know whether you think this is going in the right direction

Lou

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Apr 11 04:41:19 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 11 Apr 2005 17:41:19 +0900
Subject: [tei-council] P5 Chapter review
In-Reply-To:  (Christian
	Wittern's message of "Thu, 07 Apr 2005 12:06:53 +0900")
References: 
Message-ID: 

Council members,

with mail from Julia, Perry and Susan, I'll offer the following update:

Christian Wittern  writes:

>
> Edvard, please look at PH, TC, PR
>
> Natasha and John please look at HD, SH (& CR if possible) and CO
>
> James, please adopt SG, ND and DR -- James said, he would prefer to
> collaborate, so if anybody would like to work with him, please talk to
> him directly

Perry offered to work with James on DR

>
> Christian will look at  DS, DI and AI.  Since I worked on CH and WD, I
> would prefer if sb else could review them, but I'd be happy to
> collaborate on that.
>
> Other chapters in need of review, in my order of preference:
>
> VE Verse Base     
 --> Julia 

> TS Speech Transcription 

--> Perry

> CE Certainty

--> Julia

> GD Graphs etc
> CC Corpora

--> Perry

Susan said she will work with Matthews on MS and might also look at
VE -- maybe together with Julia?

Perry, I know you are on "shakier ground" here but I hope this is OK
in light of the other's preferences.

In hurry,

All the best -- Christian

From mjd at hum.ku.dk  Mon Apr 11 06:44:55 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Mon, 11 Apr 2005 12:44:55 +0200
Subject: [tei-council] TEI P5 chapter on MS description
Message-ID: <425A7147.11247.F8E8E2@localhost>

Dear colleague,

As you know, the TEI has recently announced the 
availability of a major new section of the TEI Guidelines 
concerned with manuscript description. This chapter 
contains much additional material, largely derived from 
work carried out during the last few years in the MASTER, 
Digital Scriptorium, and other significant projects. Like 
other parts of the next release of the TEI Guidelines, the 
chapter is already open for public comment via the TEI 
Sourceforge and TEI-L lists, and significant proposals have 
already been acted on to improve the draft. 

It seems to us and to the TEI Council that it would be 
highly desirable also to request a formal detailed review 
of the whole chapter from a small number of recognised 
experts in the field, and I am writing to ask whether you 
would be willing to provide such a review. The Council has 
requested this review in part as a means of determining the 
future course of action, in particular whether or not to 
set up a work group to tackle areas not covered in the 
draft. Your input would be of great assistance to the TEI 
Editors and the TEI Technical Council in the production of 
TEI P5, and would be much appreciated.

On the assumption that you are able to provide such a 
review, a more detailed description of what is needed 
follows. If you cannot, please let us know as soon as 
possible (and please forgive us for bothering you).

You are encouraged both to make general comments about the 
usability or relevance of the draft material under review, 
and to make specific suggestions for any changes you think 
advisable or essential. At this stage, proof reading and 
reporting of typographic errors are of lesser importance, 
but notification of any such errors will also be gratefully 
received. 

The questions we would like you to address in your review 
are:

- coverage: does the draft cover all significant topics 
relevant to the subject matter? are all aspects of the 
topics addressed treated adequately and consistently? 

- clarity: is the draft likely to be comprehensible to its 
intended audience? is its treatment of specialised topics 
accessible to the well-informed but non-specialist reader? 

- correctness: are the encoding techniques proposed in the 
draft adequate to the needs of the community? do you 
envisage any particular problems in converting between the 
draft's recommendations and any other encoding system 
commonly used in the field?

- consistency: is the draft internally consistent in its 
style and coverage, or are some topics treated less 
adequately than others? are the recommendations of the 
draft consistent in style and substance with the rest of 
the TEI Guidelines?

Wherever possible, please supply clear indications of what 
in your opinion is necessary to improve the draft; specific 
suggestions are much more helpful than general statements.

Please review the examples as well as the descriptive text: 
any suggestions for additional or alternative usage 
examples for the topics described are particularly helpful.

Please also, if possible, test the recommendations of the 
chapter in your own TEI processing environment. To do this, 
we recommend you to download and install a complete release 
of TEI P5, since there are likely to be interdependencies 
between almost any part of the Guidelines and any other, 
even for a relatively self-contained chapter such as that 
on manuscript description. Information on how to download 
is provided at http://www.tei-c.org/P5/index.xml and a more 
detailed document on how to install the new system is in 
preparation (a draft is available at http://www.tei-
c.org/Drafts/edw88.xml).

The full release also includes some sample testfiles which 
may be useful as a template for your own testing: look at 
the files in the Test directory

If you plan only to review the prose of the draft, then of 
course you need only access the web pages at http://www.tei-
c.org/P5/ where you will find links to the most recent 
draft in HTML format.

Your review can be as long or as short as you think fit. If 
you would like to discuss aspects of the review with other 
specialists in the field, please use the discussion list 
maintained by the TEI Manuscripts SIG (see http://www.tei-
c.org/Activities/SIG/ for details on this and other SIGs).

DEADLINE

Please send a copy of your final review to the addresses 
editors at tei-c.org and mjd at hum.ku.dk to arrive by midnight 
on 15 June 2005. It is planned to collate all the reviews 
and publish their recommendations together with a detailed 
response from the Council within two months of that date.

Yours sincerely,

Matthew Driscoll 

From lou.burnard at computing-services.oxford.ac.uk  Mon Apr 11 09:32:04 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 11 Apr 2005 14:32:04 +0100
Subject: [tei-council] P5 how to
In-Reply-To: <1113226066.425a7b526b6e1@www.loria.fr>
References: <42598C77.4080102@oucs.ox.ac.uk>
	<1113226066.425a7b526b6e1@www.loria.fr>
Message-ID: <425A7C54.9070908@oucs.ox.ac.uk>

Bien spott? Laurent!

It should of course be http://www.tei-c.org/Drafts/edw88.xml

my apologies for the typo

Laurent.Romary at loria.fr wrote:

>Salut Lou,
>Le lien ne marche pas! Ce n'est pas la bonne adresse?
>Amiti?s,
>Laurent
>
>Selon Lou's Laptop :
>
>  
>
>>I have made a bit more progress on the promised "Getting started with
>>P5" howto document: enough to make it seem worthwhile posting on the web
>>for your comment, and (I hope) offers of help to expand it a bit more....
>>
>>Please have a quick look at http://www.tei-c.org/P5/p5howto.xml and let
>>me know whether you think this is going in the right direction
>>
>>Lou
>>
>>_______________________________________________
>>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  Wed Apr 13 07:26:52 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 13 Apr 2005 12:26:52 +0100
Subject: [tei-council] Possible error in Source/TD/td.odd ?
Message-ID: <425D01FC.3010001@computing-services.oxford.ac.uk>

Dear TEI council,
Maybe one of you can explain why I can't now get the cvs copy of P5 to 
make schemas?

Having done a 'cvs update' in my ~/documents/tei/cvs/P5/ directory,
I then try 'make schemas'

I get:
---------------
warning: failed to load external entity "Source/TD/attref.odd"
Source/TD/td.odd:994: error: Failure to process entity attref.odd
&attref.odd;
             ^
Source/TD/td.odd:994: parser error : Entity 'attref.odd' not defined
&attref.odd;
             ^
Source/TD/td.odd:1207: parser error : chunk is not well balanced
^
Source-driver.xml:186: error: Failure to process entity td.odd
         &td.odd;
                 ^
Source-driver.xml:186: parser error : Entity 'td.odd' not defined
         &td.odd;
                 ^
-:1: parser error : Document is empty
^
-:1: parser error : Start tag expected, '<' not found
^
unable to parse -
make: *** [schemas] Error 6
---------------

If I look at Source/TD/td.odd line 994, there is indeed an
entity &attref.odd; and equally no attref.odd in the Source/TD directory.

Since this worked just a couple days ago I guess something must have 
changed?

-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 computing-services.oxford.ac.uk  Wed Apr 13 08:15:37 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 13 Apr 2005 13:15:37 +0100 (BST)
Subject: [tei-council] Possible error in Source/TD/td.odd ?
In-Reply-To: <425D01FC.3010001@computing-services.oxford.ac.uk>
Message-ID: <20050413121537.B65302A07C@webmail223.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/20050413/970f9437/attachment.ksh 

From lou.burnard at computing-services.oxford.ac.uk  Wed Apr 13 08:19:03 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 13 Apr 2005 13:19:03 +0100
Subject: [tei-council] Possible error in Source/TD/td.odd ?
In-Reply-To: <425D01FC.3010001@computing-services.oxford.ac.uk>
References: <425D01FC.3010001@computing-services.oxford.ac.uk>
Message-ID: <425D0E37.2040401@oucs.ox.ac.uk>

Apologies, this was my fault. I had misplaced one of a batch of files 
which arrived from East Timor yesterday morning.

Should be OK now!

L

James Cummings wrote:

> Dear TEI council,
> Maybe one of you can explain why I can't now get the cvs copy of P5 to 
> make schemas?
>
> Having done a 'cvs update' in my ~/documents/tei/cvs/P5/ directory,
> I then try 'make schemas'
>
> I get:
> ---------------
> warning: failed to load external entity "Source/TD/attref.odd"
> Source/TD/td.odd:994: error: Failure to process entity attref.odd
> &attref.odd;
>             ^
> Source/TD/td.odd:994: parser error : Entity 'attref.odd' not defined
> &attref.odd;
>             ^
> Source/TD/td.odd:1207: parser error : chunk is not well balanced
> ^
> Source-driver.xml:186: error: Failure to process entity td.odd
>         &td.odd;
>                 ^
> Source-driver.xml:186: parser error : Entity 'td.odd' not defined
>         &td.odd;
>                 ^
> -:1: parser error : Document is empty
> ^
> -:1: parser error : Start tag expected, '<' not found
> ^
> unable to parse -
> make: *** [schemas] Error 6
> ---------------
>
> If I look at Source/TD/td.odd line 994, there is indeed an
> entity &attref.odd; and equally no attref.odd in the Source/TD directory.
>
> Since this worked just a couple days ago I guess something must have 
> changed?
>
> -James

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Apr 13 08:54:06 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 13 Apr 2005 21:54:06 +0900
Subject: [tei-council] Possible error in Source/TD/td.odd ?
In-Reply-To: <425D0E37.2040401@oucs.ox.ac.uk> (Lou Burnard's message of
	"Wed, 13 Apr 2005 13:19:03 +0100")
References: <425D01FC.3010001@computing-services.oxford.ac.uk>
	<425D0E37.2040401@oucs.ox.ac.uk>
Message-ID: 

Lou Burnard  writes:

> Apologies, this was my fault. I had misplaced one of a batch of files
> which arrived from East Timor yesterday morning.
>
> Should be OK now!
>

Hmm.  I am still getting this error.  

Christian

From James.Cummings at computing-services.oxford.ac.uk  Wed Apr 13 09:51:27 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 13 Apr 2005 14:51:27 +0100
Subject: [tei-council] Possible error in Source/TD/td.odd ?
In-Reply-To: 
References: <425D01FC.3010001@computing-services.oxford.ac.uk>	<425D0E37.2040401@oucs.ox.ac.uk>

Message-ID: <425D23DF.7090408@computing-services.oxford.ac.uk>

Christian Wittern wrote:
> Lou Burnard  writes:
> 
> 
>>Apologies, this was my fault. I had misplaced one of a batch of files
>>which arrived from East Timor yesterday morning.
>>
>>Should be OK now!
> 
> Hmm.  I am still getting this error.  

I just did an entirely new cvs checkout of the P5 module (to 
double-check) and still didn't get the correct file.  It seems that 
commits to CVS take quite a long time to be available?  But that just 
sounds 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  Wed Apr 13 10:06:30 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 13 Apr 2005 15:06:30 +0100
Subject: [tei-council] Possible error in Source/TD/td.odd ?
In-Reply-To: <425D23DF.7090408@computing-services.oxford.ac.uk>
References: <425D01FC.3010001@computing-services.oxford.ac.uk>	<425D0E37.2040401@oucs.ox.ac.uk>

	<425D23DF.7090408@computing-services.oxford.ac.uk>
Message-ID: <425D2766.1090805@oucs.ox.ac.uk>

James Cummings wrote:

> Christian Wittern wrote:
>
>> Lou Burnard  writes:
>>
>>
>>> Apologies, this was my fault. I had misplaced one of a batch of files
>>> which arrived from East Timor yesterday morning.
>>>
>>> Should be OK now!
>>
>>
>> Hmm.  I am still getting this error.  
>
>
> I just did an entirely new cvs checkout of the P5 module (to 
> double-check) and still didn't get the correct file.  It seems that 
> commits to CVS take quite a long time to be available?  But that just 
> sounds wrong...
>
> -James

lou at janus:~/TEI-SF/P5/Source/TD$ cvs add attref.odd
louburnard at cvs.sourceforge.net's password:
cvs add: attref.odd already exists, with version number 1.1
lou at janus:~/TEI-SF/P5/Source/TD$                  

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Apr 13 23:34:04 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 14 Apr 2005 12:34:04 +0900
Subject: [tei-council] P5 how to
In-Reply-To: <42598C77.4080102@oucs.ox.ac.uk> (Lou's Laptop's message of
	"Sun, 10 Apr 2005 20:28:39 +0000")
References: <42598C77.4080102@oucs.ox.ac.uk>
Message-ID: 

"Lou's Laptop"  writes:

> I have made a bit more progress on the promised "Getting started with
> P5" howto document: enough to make it seem worthwhile posting on the
> web for your comment, and (I hope) offers of help to expand it a bit
> more....
>
> Please have a quick look at http://www.tei-c.org/P5/p5howto.xml and
> let me know whether you think this is going in the right direction
>
I have now had a look at the document and I do think it goes in the
right direction.  It gets a bit thin towards the end... An example
that shows the file based on a RNG schema would help, I think.  Not
sure if we should specifically cater to oxygen users here, this might
alienate other commercial vendors.

On a slightly different topic, while studying this material I was also
looking at chapter 3, Structure of the TEI Document Type Definition
and noticed that there is a lot of work that needs to be done.  This
is one of the chapters I excluded from my list of chapters for review
since I think the editors will have to take care of it.  To me, the
mixture of generic description (TEI schema) and specific mentioning of
DTD language is utterly confusing and makes it difficult to infer
which layer of the text (e.g. P4 or P5) I am currently looking at.  I
think it is highly desirably to make this chapter more readable, since
access to P5 more or less depends on this.  

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 computing-services.oxford.ac.uk  Thu Apr 14 03:42:43 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 14 Apr 2005 08:42:43 +0100
Subject: [tei-council] P5 how to
In-Reply-To: 
References: <42598C77.4080102@oucs.ox.ac.uk> 
Message-ID: <425E1EF3.70504@computing-services.oxford.ac.uk>

Christian Wittern wrote:
> Not sure if we should specifically cater to oxygen users here, this might
> alienate other commercial vendors.

This worried me as well.  I suppose one could say that we would be 
willing to write two sentences for any editor which comes bundled with
TEI schema, if asked?  (I mean how many would that be?) oXygen doesn't
come with P5 at the moment, but I'm sure they will include it when it
is released.  A blurb about oXygen would go something like this in
my mind:  "If you are using oXygen then you may associate a schema with
a particular document on creation, or via the menu or toolbar.  This 
will allow validation and context-sensitive prompting when creating 
elements."

 > I
> think it is highly desirably to make this chapter more readable, since
> access to P5 more or less depends on this.  

I'm assuming that this might also be the proper place to discuss Roma, 
ODD and such things in more detail?

-James

From lou.burnard at computing-services.oxford.ac.uk  Thu Apr 14 04:05:10 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 14 Apr 2005 09:05:10 +0100
Subject: [tei-council] chapter ST [was P5 how to] 
In-Reply-To: 
References: <42598C77.4080102@oucs.ox.ac.uk> 
Message-ID: <425E2436.4030405@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>
> 
> On a slightly different topic, while studying this material I was also
> looking at chapter 3, Structure of the TEI Document Type Definition
> and noticed that there is a lot of work that needs to be done.  This
> is one of the chapters I excluded from my list of chapters for review
> since I think the editors will have to take care of it.

That is correct. It's my main objective as soon as the work on classes 
etc. has settled down a bit. This is the chapter in which all the 
classes are actually first defined, so it cannot be completed until the 
class reorganization is if not complete at least clearly agreed. But I 
agree that the chapter  should certainly have a health warning at its start.

   To me, the
> mixture of generic description (TEI schema) and specific mentioning of
> DTD language is utterly confusing and makes it difficult to infer
> which layer of the text (e.g. P4 or P5) I am currently looking at.  I
> think it is highly desirably to make this chapter more readable, since
> access to P5 more or less depends on this.  
> 

I agree. It's just rather a difficult task when so much of the rest of 
the system is in flux.

> All the best,
> 
> Christian
> 

From sschreib at umd.edu  Thu Apr 14 20:30:06 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Thu, 14 Apr 2005 20:30:06 -0400
Subject: [tei-council] P5 how to
In-Reply-To: 
Message-ID: <200504150029.AUP06014@md0.mail.umd.edu>

I tried to look at the document a couple of times, but get exception errors

/home5/tei/web/P5/p5howto.xml (No such file or directory)

org.apache.cocoon.ResourceNotFoundException: Resource not found.:
org.apache.excalibur.source.SourceNotFoundException:
file:/home5/tei/web/P5/p5howto.xml doesn't exist.

susan

-----Original Message-----
From: tei-council-bounces at lists.village.Virginia.EDU
[mailto:tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of
Christian Wittern
Sent: Wednesday, April 13, 2005 11:34 PM
To: Lou's Laptop
Cc: tei-council at lists.village.Virginia.EDU
Subject: Re: [tei-council] P5 how to

"Lou's Laptop"  writes:

> I have made a bit more progress on the promised "Getting started with
> P5" howto document: enough to make it seem worthwhile posting on the
> web for your comment, and (I hope) offers of help to expand it a bit
> more....
>
> Please have a quick look at http://www.tei-c.org/P5/p5howto.xml and
> let me know whether you think this is going in the right direction
>
I have now had a look at the document and I do think it goes in the
right direction.  It gets a bit thin towards the end... An example
that shows the file based on a RNG schema would help, I think.  Not
sure if we should specifically cater to oxygen users here, this might
alienate other commercial vendors.

On a slightly different topic, while studying this material I was also
looking at chapter 3, Structure of the TEI Document Type Definition
and noticed that there is a lot of work that needs to be done.  This
is one of the chapters I excluded from my list of chapters for review
since I think the editors will have to take care of it.  To me, the
mixture of generic description (TEI schema) and specific mentioning of
DTD language is utterly confusing and makes it difficult to infer
which layer of the text (e.g. P4 or P5) I am currently looking at.  I
think it is highly desirably to make this chapter more readable, since
access to P5 more or less depends on this.  

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

From lou.burnard at computing-services.oxford.ac.uk  Fri Apr 15 03:38:57 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 15 Apr 2005 08:38:57 +0100
Subject: [tei-council] P5 how to
In-Reply-To: <200504150029.AUP06014@md0.mail.umd.edu>
References: <200504150029.AUP06014@md0.mail.umd.edu>
Message-ID: <425F6F91.7090306@computing-services.oxford.ac.uk>

Dear Susan

I have twice posted to the list apologising for this mistake. The 
correct address is

http://www.tei-c.org/Drafts/edw88.xml

Please confirm that you got this message

Lou

Susan Schreibman wrote:

> I tried to look at the document a couple of times, but get exception errors
> 
> /home5/tei/web/P5/p5howto.xml (No such file or directory)
> 
> org.apache.cocoon.ResourceNotFoundException: Resource not found.:
> org.apache.excalibur.source.SourceNotFoundException:
> file:/home5/tei/web/P5/p5howto.xml doesn't exist.
> 
> susan
> 
> 
> -----Original Message-----
> From: tei-council-bounces at lists.village.Virginia.EDU
> [mailto:tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of
> Christian Wittern
> Sent: Wednesday, April 13, 2005 11:34 PM
> To: Lou's Laptop
> Cc: tei-council at lists.village.Virginia.EDU
> Subject: Re: [tei-council] P5 how to
> 
> "Lou's Laptop"  writes:
> 
> 
>>I have made a bit more progress on the promised "Getting started with
>>P5" howto document: enough to make it seem worthwhile posting on the
>>web for your comment, and (I hope) offers of help to expand it a bit
>>more....
>>
>>Please have a quick look at http://www.tei-c.org/P5/p5howto.xml and
>>let me know whether you think this is going in the right direction
>>
> 
> I have now had a look at the document and I do think it goes in the
> right direction.  It gets a bit thin towards the end... An example
> that shows the file based on a RNG schema would help, I think.  Not
> sure if we should specifically cater to oxygen users here, this might
> alienate other commercial vendors.
> 
> On a slightly different topic, while studying this material I was also
> looking at chapter 3, Structure of the TEI Document Type Definition
> and noticed that there is a lot of work that needs to be done.  This
> is one of the chapters I excluded from my list of chapters for review
> since I think the editors will have to take care of it.  To me, the
> mixture of generic description (TEI schema) and specific mentioning of
> DTD language is utterly confusing and makes it difficult to infer
> which layer of the text (e.g. P4 or P5) I am currently looking at.  I
> think it is highly desirably to make this chapter more readable, since
> access to P5 more or less depends on this.  
> 
> All the best,
> 
> Christian
> 

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Apr 15 11:03:57 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 15 Apr 2005 23:03:57 +0800
Subject: [tei-council] P5 Chapter review
In-Reply-To:  (Christian
	Wittern's message of "Mon, 11 Apr 2005 17:41:19 +0900")
References: 

Message-ID: 

Laurent, thanks for offering to work on the revision of the transcription
of speech chapter -- could you please contact Perry and see if you can
coordinate your efforts with him?

All the best,

Christian

Christian Wittern  writes:

>
>> TS Speech Transcription 
>
> --> Perry

-- 

 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  Fri Apr 15 11:38:28 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 15 Apr 2005 16:38:28 +0100
Subject: [tei-council] CVS README
Message-ID: <425FDFF4.4000709@computing-services.oxford.ac.uk>

At the last conference call I was asked to write a README file for the CVS 
copy of P5.  Below is my first draft (text then XML since attachments seem 
to bounce); any corrections or suggestions for improvement are appreciated.
I know there is a lot one could add, but I thought I'd keep it simple to 
start.

-----------
CVS P5 README File

__README for TEI P5 CVS__

   This file contains some basic information about the files included in the
   P5 module, and what can be generated from them. The Source/ folder is by
   far the most important. This contains the source files for the  P5 version
   of the TEI Guidelines and Schema. These are organised in folders by chapter
   of the Guidelines, and each contain one or more file in ODD (One Document
   Does it all) format. This is an XML format developed by the TEI for
   creating guidelines and schema.

_Generating Other Formats_

   A Makefile is provided to generate HTML versions of the guidelines, DTDs
   and schemas, amongst various other possibilities. There are a number of
   variables that one can change at the beginning of the Makefile. These are:

* TEISERVER: 
   This is the eXist server storing TEI files used by the 'fasicule' target.
   You must have internet access to this target. By default this is:    

* PREFIX: 
   This is the default location under which you wish to install files
   locally if you use the 'install' target. By default this is: /usr/local/tei

* XSL: 
   This is the location of the XSLT stylesheets required for the
   transformation of ODD files. By default this is a URL pointing to:    

   however, if you want to use a local copy of the stylesheets you may wish to
   change this. Possible options include the folder for the CVS copy of the
   stylesheets, or /usr/share/xml/tei/stylesheet which is the location used by
   the debian package for TEI stylesheets.
   The makefile has a number of requirements, these include internet access
   (or a local copy of the stylesheets), and up-to-date versions of the perl,
   jing, trang, xmllint and xsltproc programs. If you do not have these
   installed then many of the make targets will not work. Fortunately, there
   is a target which will check to make sure you have these installed: 'make check'.

_Makefile Targets_

* Check: 
Usage: "make check"

   This target checks to see whether you have perl, jing, trang, xmllint and
   xsltproc installed.

* Default: 
Usage: "make"

   This is the default target and creates the TEI P5 DTDs, Schemas and HTML
   version of the Guidelines.

* Convert: 
Usage: "make convert"

   This target creates the both TEI P5 DTDs and Schemas.

* DTDs: 
Usage: "make dtds"

   This target creates DTDs for TEI P5 in the DTD/ folder.

* Schemas: 
Usage: "make schemas"

   This target creates RelaxNG Schemas for TEI P5 in the Schema/ folder.

* HTML: 
Usage: "make html"

   This target creates an HTML version of the TEI Guidelines in the
   Guidelines/ folder.

* XML: 
Usage: "make xml"

   This target creates a TEI P5 XML version of the Guidelines as
   Guidelines.xml in the current (P5) folder.

* Split: 
Usage: "make split"

   This target creates a set of TEI P5 XML files that are a version of the
   Guidelines split into chapters, in the split/ folder.

* exist: 
Usage: "make exist"

   This target updates a locally running copy of the eXist XML database with
   the TEI files. The files are added via the SOAP interface and the database
   is assumed to be running at:  

* Clean: 
Usage: "make clean"

   This target removes most of the files created by the other targets.

* Install: 
Usage: "make install"

   This target installs a separate local copy of the DTDs, Schema, and HTML
   version of the guidelines under the file path given by the PREFIX variable.

-----
Revised:  2005/04/10  by  jamesc

-----------

And the XML version:

CVS P5 README File

A README file for the CVS P5 release of the Text
Encoding Initiative guidelines and schema. 

Born Digital.

$Date: 2005/04/10 $

$Author: jamesc $

Initial composition of file.

README for TEI P5 CVS

    This file contains some basic information about the files included in the
    P5 module, and what can be generated from them. The Source/ folder is by
    far the most important. This contains the source files for the  P5 version
    of the TEI Guidelines and Schema. These are organised in folders by chapter
    of the Guidelines, and each contain one or more file in ODD (One Document
    Does it all) format. This is an XML format developed by the TEI for
    creating guidelines and schema.

Generating Other Formats

    A Makefile is provided to generate HTML versions of the guidelines, DTDs
    and schemas, amongst various other possibilities. There are a number of
    variables that one can change at the beginning of the Makefile. These are:

TEISERVER

    This is the eXist server storing TEI files used by the 'fasicule' target.
    You must have internet access to this target. By default this is: 
    http://www.tei-c.org.uk/Query/

PREFIX

    This is the default location under which you wish to install files
    locally if you use the 'install' target. By default this is: /usr/local/tei

XSL

    This is the location of the XSLT stylesheets required for the
    transformation of ODD files. By default this is a URL pointing to: 
    http://www.tei-c.org/stylesheet 
    however, if you want to use a local copy of the stylesheets you may wish to
    change this. Possible options include the folder for the CVS copy of the
    stylesheets, or /usr/share/xml/tei/stylesheet which is the location used by
    the debian package for TEI stylesheets. 

    The makefile has a number of requirements, these include internet access
    (or a local copy of the stylesheets), and up-to-date versions of the perl,
    jing, trang, xmllint and xsltproc programs. If you do not have these
    installed then many of the make targets will not work. Fortunately, there
    is a target which will check to make sure you have these installed: 'make check'.

Makefile Targets
Check
Usage: make check

    This target checks to see whether you have perl, jing, trang, xmllint and
    xsltproc installed. 

Default
Usage: make

    This is the default target and creates the TEI P5 DTDs, Schemas and HTML
    version of the Guidelines. 

Convert
Usage: make convert

    This target creates the both TEI P5 DTDs and Schemas. 

DTDs
Usage: make dtds

    This target creates DTDs for TEI P5 in the DTD/ folder. 

Schemas
Usage: make schemas

    This target creates RelaxNG Schemas for TEI P5 in the Schema/ folder. 

HTML
Usage: make html

    This target creates an HTML version of the TEI Guidelines in the
    Guidelines/ folder. 

XML
Usage: make xml

    This target creates a TEI P5 XML version of the Guidelines as
    Guidelines.xml in the current (P5) folder. 

Split
Usage: make split

    This target creates a set of TEI P5 XML files that are a version of the
    Guidelines split into chapters, in the split/ folder.

exist
Usage: make exist

    This target updates a locally running copy of the eXist XML database with
    the TEI files. The files are added via the SOAP interface and the database
    is assumed to be running at:  http://localhost:8080/

Clean
Usage: make clean

    This target removes most of the files created by the other targets.

Install
Usage: make install

    This target installs a separate local copy of the DTDs, Schema, and HTML
    version of the guidelines under the file path given by the PREFIX variable.

--------------

-- 
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 16 03:26:00 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 16 Apr 2005 03:26:00 -0400
Subject: [tei-council] CVS README
In-Reply-To: <425FDFF4.4000709@computing-services.oxford.ac.uk>
References: <425FDFF4.4000709@computing-services.oxford.ac.uk>
Message-ID: <16992.48648.567828.308516@emt.wwp.brown.edu>

James --

First off, thank you for doing this. This will make the use of the
CVS version of the source ODDs much more accessible to lots of
people. Overall I think it looks very good. Specific nit-picks are
inserted left-aligned below, interspersed with the XML source which
is indented by 6 or more columns, with some general comments at the
end. Hope this is readable and helpful.

This level of  is unnecessary. All of its children could be the
direct children of  instead.

        README for TEI P5 CVS
I'm concerned that the title and the content don't match. The content
gives lots of (very good) information on using the Makefile on a
GNU/Linux or other unixy system. But it doesn't say anything about 
* what and how to get from CVS
* where to put it
* how to update it
* what all those files are for
* how to submit suggestions or patches
* other things I may not have thought of 
I'm not suggesting you need to write all this ever, let alone before
the file is released. I think your "keep it simple to start" policy
is fine. But I am suggesting that either the title should be less
ambitious or specific placeholder s should be inserted to be
filled in later.

        This file contains some basic information about the
          files included in the P5 module, and what can be
Is it called a "module" (by Sourceforge)?

          generated from them. The Source/ folder is by far the
s/folder/directory/, no? (If so, everywhere.)

          most important. This contains the source files for the
          P5 version of the TEI Guidelines and Schema. These are
s/Schema/associated schemas/

          organised in folders by chapter of the Guidelines, and
          each contain one or more file in ODD (One Document Does
          it all) format. This is an XML format developed by the
          TEI for creating guidelines and schema.
Last sentence: "This is a TEI format specifically intended for writing
Guidelines about encoding, from which schemas and reference
documentation can be automatically extracted." or some such.

I think using type= of  is probably a good idea. In P3 they were
required, but because an SGML defaulting mechanism not available in P4
was used, the content model was loosened in P4 to make them optional.
Indeed there are cases (and the P3 Guidelines themselves were a
perfect example) where type= didn't serve a useful purpose, so there's
a pretty strong argument for leaving it optional. But nonetheless, I
personally think it can often be quite helpful, at least for the
humans.

          Generating Other Formats
           A Makefile is provided to generate HTML versions of
            the guidelines, DTDs and schemas, amongst various
"... of the guidelines, schemas, and DTDs, amongst various ..."

            other possibilities. There are a number of
            variables that one can change at the beginning of
            the Makefile. These are:

            TEISERVER
            This is the eXist server storing TEI files
              used by the 'fasicule' target. You must have
Shouldn't that be fasicule or
some such? :-)

              internet access to this target. By default this
"either internet access or a locally served TEI eXist database to use
this"

              is http://www.tei-c.org.uk/Query/

            PREFIX
            This is the default location under which you
              wish to install files locally if you use the
              'install' target. By default this is
              /usr/local/tei
We (TEI internal documentation writers) really need to develop and
document a convention for encoding all sorts of things, among them
file paths. I'm thinking  at the moment. Any
thoughts?

            XSL
            This is the location of the XSLT stylesheets
              required for the transformation of ODD files.
              By default this is a URL pointing to http://www.tei-c.org/stylesheet 
              however, if you want to use a local copy of the
              stylesheets you may wish to change this.
              Possible options include the folder for the CVS
              copy of the stylesheets, or
              /usr/share/xml/tei/stylesheet which is the
              location used by the debian package for TEI
s/debian/Debian/

              stylesheets. 

          The makefile has a number of requirements, these
            include internet access (or a local copy of the
            stylesheets), and up-to-date versions of the perl,
            jing, trang, xmllint and xsltproc programs. If you
            do not have these installed then many of the make
            targets will not work. Fortunately, there is a
            target which will check to make sure you have these
            installed: 'make check'.
Perhaps make check ? 
Maybe make check   ?
In truth (as I say above), we need a general purpose documentation
schema, and perhaps it should contain special purpose elements for
things like file names, file paths, URLs (that are not references),
system commands, error messages, command output, etc.

I think I'd encode all the following as triplets:

 Makefile Targets

   Check
   Usage: make check
   This target checks to see whether you have perl, jing,
   trang, xmllint and xsltproc installed.

            Makefile Targets
            Check
            Usage: make check
               This target checks to see whether you
              have perl, jing, trang, xmllint and xsltproc
Missing the Oxford comma after "xmllint".

              installed. 
            Default
            Usage: make
               This is the default target and creates
              the TEI P5 DTDs, Schemas and HTML version of
"the TEI P5 schemas in RelaxNG & DTD and the HTML version of"

              the Guidelines. 
            Convert
I had not even taken notice of this one, let alone ever used it. :-)

            Usage: make convert
               This target creates the TEI P5 DTDs and
              Schemas. 
As with "default".

            DTDs
            Usage: make dtds
               This target creates DTDs for TEI P5 in
              the DTD/ folder. 
            Schemas
            Usage: make schemas
               This target creates RelaxNG Schemas for
              TEI P5 in the Schema/ folder. 
            HTML
            Usage: make html
               This target creates an HTML version of
              the TEI Guidelines in the Guidelines/ folder.
            XML
The output of this target (Guidelines.xml) as intended to be the
Guidelines expressed in TEI Lite. Thus perhaps this label should be
"TEI Lite" or some such.

            Usage: make xml
               This target creates a TEI P5 XML version
s/TEI P5 XML/TEI Lite (P5)/

              of the Guidelines as Guidelines.xml in the
              current (P5) folder.
"current directory (i.e., P5/)."

            Split
            Usage: make split
               This target creates a set of TEI P5 XML
              files that are a version of the Guidelines
              split into chapters, in the split/ folder.
The output of this target is also XML, but is not TEI Lite (as with
the 'xml' target), but rather still ODD. The important thing here
(IMHO) is that the resulting files have had entity references
resolved.

            exist
            Usage: make exist
               This target updates a locally running
              copy of the eXist XML database with the TEI
              files. The files are added via the SOAP
              interface and the database is assumed to be
              running at the http://localhost:8080/ URL.
Should this really be a ref with a target=? What happens if one clicks
on it?

            Clean
            Usage: make clean
               This target removes most of the files
              created by the other targets.
            Install
            Usage: make install
               This target installs a separate local
              copy of the DTDs, Schema, and HTML version of
              the guidelines under the file path given by the
              PREFIX variable.
May want to add "(See , above.)", and then put an
id=PFX on the entry for that variable.

I gather you've ignored the dist, valid, validate, test, pdf, and
fasicule targets on purpose. Probably reasonable. But what about
"html-web" target? Do you know the difference between it and "html"?
(I don't -- I know it's the same except for slightly different
stylesheets, but even having glanced at the stylesheets and scanned
the results, I don't know what or why is really different. I suspect
the -web version is intended to have a useful navigation bar down the
left-hand column.)

I think the order of targets might use some thought. I'm inclined to
suggest that the more complex targets that call others be listed
later, so they can just refer to the previous ones. E.g. that 'make
convert' is the same as 'make dtds; make schemas'. Either that or just
list 'em in alphabetical order. (Then what do you do with "default",
or my suggestion that the label for 'xml' be "Lite"? Hmmm...)

Again, I'm really glad you're doing this. It's a Good Thing(tm :-).

From James.Cummings at computing-services.oxford.ac.uk  Sat Apr 16 18:57:31 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sat, 16 Apr 2005 23:57:31 +0100
Subject: [tei-council] CVS README
In-Reply-To: <16992.48648.567828.308516@emt.wwp.brown.edu>
References: <425FDFF4.4000709@computing-services.oxford.ac.uk>
	<16992.48648.567828.308516@emt.wwp.brown.edu>
Message-ID: <4261985B.1020401@computing-services.oxford.ac.uk>

Syd Bauman wrote:
>       
> This level of  is unnecessary. All of its children could be the
> direct children of  instead.

I've noticed I've often a tendency towards unnecessarily overnesting.

>         README for TEI P5 CVS
> I'm concerned that the title and the content don't match. 

What about "CVS P5 Module README File" ?

The content
> gives lots of (very good) information on using the Makefile on a
> GNU/Linux or other unixy system. But it doesn't say anything about 
> * what and how to get from CVS
> * where to put it
> * how to update it

In my view, if they are reading this file, then they've already
got the P5 Module from CVS and don't need instructions for getting
it.  The proper place for this information, I'd think is the TEI
CVS page http://sourceforge.net/cvs/?group_id=106328 though this
also links to the sourceforge Basic Introduction to CVS I'd prefer
not duplicate the information that the better qualified provide.

 > * what all those files are for
 > * how to submit suggestions or patches

These two I agree with, but should either go in a README for
each CVS module or somehow in an overall one.  (But since
you have to check out each module individually, an overall
one is impossible and I'm assuming the TEI CVS page
http://sourceforge.net/cvs/?group_id=106328 I suppose.

> Is it called a "module" (by Sourceforge)?
Yup. I think to distinguish from the stable releases you
can download which they call 'packages'.

>           generated from them. The Source/ folder is by far the
> s/folder/directory/, no? (If so, everywhere.)

Strangely I originally wrote directory and changed it to folder for
some unknown reason.

>           P5 version of the TEI Guidelines and Schema. These are
> s/Schema/associated schemas/

Done.

> Last sentence: "This is a TEI format specifically intended for writing
> Guidelines about encoding, from which schemas and reference
> documentation can be automatically extracted." or some such.

Done.

>         
> I think using type= of  is probably a good idea. In P3 they were
> required, but because an SGML defaulting mechanism not available in P4
> was used, the content model was loosened in P4 to make them optional.
> Indeed there are cases (and the P3 Guidelines themselves were a
> perfect example) where type= didn't serve a useful purpose, so there's
> a pretty strong argument for leaving it optional. But nonetheless, I
> personally think it can often be quite helpful, at least for the
> humans.

As someone who often overuses @type I'm happy to do so -- but what
type are these divisions?

> "... of the guidelines, schemas, and DTDs, amongst various ..."
Done.

> Shouldn't that be fasicule or
> some such? :-)
Done.

> "either internet access or a locally served TEI eXist database to use
> this"
Done.
>               /usr/local/tei
> We (TEI internal documentation writers) really need to develop and
> document a convention for encoding all sorts of things, among them
> file paths. I'm thinking  at the moment. Any
> thoughts?

I've done that for now; perhaps  ?

>               copy of the stylesheets, or
>               /usr/share/xml/tei/stylesheet which is the

and here

>               location used by the debian package for TEI
> s/debian/Debian/

Done.

>             installed: 'make check'.
> Perhaps make check ? 
> Maybe make check   ?

Used  for now.

> I think I'd encode all the following as triplets:
>   
>    Check
>    Usage: make check
>    This target checks to see whether you have perl, jing,
>    trang, xmllint and xsltproc installed.
>   
Done.
>  

> Missing the Oxford comma after "xmllint".
Done.

> "the TEI P5 schemas in RelaxNG & DTD and the HTML version of"
Done.

>             Convert
> I had not even taken notice of this one, let alone ever used it. :-)

Since it was a simple one I included it.

> As with "default".
Done.

>             XML
> The output of this target (Guidelines.xml) as intended to be the
> Guidelines expressed in TEI Lite. Thus perhaps this label should be
> "TEI Lite" or some such.
That means to me that this would produce a version of the TEI Lite 
DTD/Schema/Guidelines not that it produces P5 Guidelines in Lite.
Not sure what it should be then.

> s/TEI P5 XML/TEI Lite (P5)/
Done.
> "current directory (i.e., P5/)."
Done.
> The output of this target is also XML, but is not TEI Lite (as with
> the 'xml' target), but rather still ODD. The important thing here
> (IMHO) is that the resulting files have had entity references
> resolved.
Done.

>               running at the                  target="http://localhost:8080/"
>                 >http://localhost:8080/ URL.
> Should this really be a ref with a target=? What happens if one clicks
> on it?

It takes you to the Jetty server (if you've not embedded eXist into 
Cocoon and are using the default).  I could change this to
http://localhost:8080/exist/ which would point to the local
exist homepage.  In fact, But really this target uses 
http://localhost:8080/cocoon/services/Admin?WSDL so assumes
use of sebastian's packages.  Perhaps I should remove reference to it?

> May want to add "(See , above.)", and then put an
> id=PFX on the entry for that variable.

Done.
> I gather you've ignored the dist, valid, validate, test, pdf, and
> fasicule targets on purpose. Probably reasonable. But what about
> "html-web" target? Do you know the difference between it and "html"?
> (I don't -- I know it's the same except for slightly different
> stylesheets, but even having glanced at the stylesheets and scanned
> the results, I don't know what or why is really different. I suspect
> the -web version is intended to have a useful navigation bar down the
> left-hand column.)

Yes, I ignored those because I thought it less likely that people would
need them (or those that would won't need help). Test, in specific, uses
software which 'make check' doesn't test for (and which it turns out I
didn't have installed).

> I think the order of targets might use some thought. I'm inclined to
> suggest that the more complex targets that call others be listed
> later, so they can just refer to the previous ones. E.g. that 'make
> convert' is the same as 'make dtds; make schemas'. Either that or just
> list 'em in alphabetical order. (Then what do you do with "default",
> or my suggestion that the label for 'xml' be "Lite"? Hmmm...)

Yeah, I thought about that kind of thing as well -- but perhaps it
should follow whatever order is in the Makefile (or that changed
to such an ordered principle...)  My order was based mostly on my
perception of frequency of use.

-James

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Apr 21 08:05:12 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 21 Apr 2005 14:05:12 +0200
Subject: [tei-council] Agenda items, documents for Paris meeting
Message-ID: 

Dear Council meeting,

As you know, the TEI Technical Council will hold a two-day meeting
starting a week from now on April 28th 1400 local time in Paris.

In preparation for that meeting, I would like to ask you to send me
any items that needs to be put on the agenda for discussion.  Also,
any documents the Council is expected to review should be available as
soon as possible -- experience shows that having time to think over it
can make a huge difference.

Please look also at the action items in
http://www.tei-c.org.uk/Council/tcm16.xml?style=printable 
and act as necessary.

Looking forward to seeing all of you soon,

Christian Wittern

-- 

 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From jawalsh at indiana.edu  Fri Apr 22 09:36:59 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Fri, 22 Apr 2005 08:36:59 -0500
Subject: [tei-council] Update on revisions to Chapter 24,
	The Independent Header (SH)
Message-ID: 

Hi all,

Below is an update on work on Ch. 24, along with the spreadsheet 
discussed in our last conference call.  I sent this out last night, but 
I think it got blocked because I included attachments.  The previously 
attached documents are now available as links at:

http://www.dlib.indiana.edu/~jawalsh/tmp/council/ch24Update.xml (this 
update in TEI format)
http://www.dlib.indiana.edu/~jawalsh/tmp/council/teiHeaderMappings.sxc 
(Open Office format)
http://www.dlib.indiana.edu/~jawalsh/tmp/council/teiHeaderMappings.xls 
(Excel format)

John

Update on revisions to Chapter 24, The Independent Header (SH)
==============================================================

Natasha Smith and I have been working to revise and update Chapter
24 on the Independent Header. We were told by the editors that, since
there is no evidence that independent headers are actually used by the
TEI community, we should remove references to independent headers but
retain and update the still valuable information regarding mapping from
the TEI Header to other metadata formats, such as MARC. The eventual
goal is to eliminate this chapter and incorporate the metadata mapping
information into Chapter 5, "The TEI Header."

We have completed the task of editing the chapter to remove
references to independent headers, and we have begun the work of
revising and updating the metadata mapping sections. To facilitate the
process of updating the metadata mapping information, we have created a
spreadsheet of the TEI Header elements, in their various hierarchical
contexts. This spreadsheet will be used by library catalogers and
metadata experts to indicate mappings to other metadata standards, such
as MARC and Dublin Core. The completed spreadsheet could also be used to
generate a reference table for the P5 Guidelines. The spreadsheet is
pretty comprehensive but does not yet include the msDescription
elements. Also note that the spreadsheet refers to P4 documentation
rather than P5. I feel that the P4 documentation is, at this point,
easier to use and fuller with examples and so will be more useful to the
catalogers and metadata experts, who are not necessarily TEI experts. We
have recruited some catalogers and metadata experts to help with this
process, but we haven't yet given them the spreadsheet and set them to
work.

Next Steps:

    1. Give catalogers the spreadsheet to document mappings from TEI
       Header to MARC and Dublin Core.
    2. Draft a section that discusses use of namespaces to incorporate
       other metadata standards into TEI.
    3. Assemble all the parts and revise for improved organization and 
style.
    4. Seek feedback from TEI in Libraries group and wider TEI community.

The spreadsheet is attached in Open Office and Excel format.

| John A. Walsh, Associate Director for Projects and Services
| Digital Library Program / Indiana University Libraries
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 Fax:812-856-2062 

From Julia_Flanders at Brown.edu  Fri Apr 22 14:52:39 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Fri, 22 Apr 2005 14:52:39 -0400
Subject: [tei-council] Agenda items, documents for Paris meeting
In-Reply-To: 
References: 
Message-ID: 

I was asked to circulate a summary of the PB workgroup's results to 
date. Terry's report which he put together for the November 
conference call is actually quite complete and contains examples 
which are now visible (for a while they were malfunctioning); see:

http://www.tei-c.org/Activities/PB/pbr01.html

In Safari, you'll need to view source to see the examples. Firefox 
shows them properly.

The other action item to me concerned the TEI wiki. I'm happy to 
report that Sebastian, Lou, and James Cummings (and perhaps unseen 
others at Oxford) have set up wiki software which is now accessible 
both from http://www.tei-c.org/wiki and http://www.tei-c.org.uk/wiki. 
There's a link to the wiki from the main TEI site (on the navigation 
bar). James, Matt Zimmerman, and Daniel O'Donnell have done some very 
good work setting up an area devoted to stylesheets, with some good 
models for people to emulate, and I've put the call for stylesheets 
up. I'm waiting another couple of days while they work out a few more 
details before announcing both the wiki and the call for stylesheets 
on TEI-L, but I think it's just about as good as complete. The wiki 
also contains spaces for the SIGs and a few other areas, and of 
course anyone can create new spaces as needed. The wiki group agreed 
to keep things fairly open for the time being (anyone can register an 
account and make changes) but to keep an eye on things and see how it 
goes.

Best, Julia

At 2:05 PM +0200 4/21/05, Christian Wittern wrote:
>Dear Council meeting,

>Please look also at the action items in
>http://www.tei-c.org.uk/Council/tcm16.xml?style=printable
>and act as necessary.
>
>Looking forward to seeing all of you 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

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sat Apr 23 03:00:36 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 23 Apr 2005 09:00:36 +0200
Subject: [tei-council] Agenda items, documents for Paris meeting
In-Reply-To:  (Julia Flanders's
	message of "Fri, 22 Apr 2005 14:52:39 -0400")
References: 

Message-ID: 

Julia Flanders  writes:

> I was asked to circulate a summary of the PB workgroup's results to
> date. Terry's report which he put together for the November conference
> call is actually quite complete and contains examples which are now
> visible (for a while they were malfunctioning); see:
>
> http://www.tei-c.org/Activities/PB/pbr01.html

Thank you, this looks very interesting.  
>
> In Safari, you'll need to view source to see the examples. Firefox
> shows them properly.
>
> The other action item to me concerned the TEI wiki. I'm happy to
> report that Sebastian, Lou, and James Cummings (and perhaps unseen
> others at Oxford) have set up wiki software which is now accessible
> both from http://www.tei-c.org/wiki and
> http://www.tei-c.org.uk/wiki. 

Cocoon insists that you need a slash at the end of these URLs.  Again,
this looks very nice and useful.  I hope the community will use it.

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  Sun Apr 24 05:03:57 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 24 Apr 2005 11:03:57 +0200
Subject: [tei-council] P5 Howto - how?
Message-ID: 

Council members,

Having spent a fair amount of time trying to get P5 customizations
according to the P5 Howto working, the only thing I can say is, it does not
seem to work as advertised, at least not on my system.

Here is the ODD fragment I am trying to use, it lives in steininschriften.odd:

I have a P5 CVS tree from SF, do a "make install" and get some errors,
since there are some namespace-related bugs in the XSL that generates
the Guidelines, but I do end up having a schema/relaxng/p5 and schema/dtd/p5
subdirectory in /usr/local/tei/.

Now trying to run Roma (from the P5 dir in the CVS tree, after having
put fix_rnc_whitespace.pl on the path:

~/src/tei/P5/Roma --schema=/usr/local/tei/schema/relaxng/p5/ --nodtd --debug --xsl=http://www.tei-c.org/stylesheet/base steininschriften.odd  mySchemas
========= 2005-04-24 10:54:13.N Roma starts, info:
Test for software: xmllint, xsltproc, trang, and perl
/sw/bin/xmllint
/sw/bin/xsltproc
/Users/chris/bin/trang
/usr/bin/perl
TEI stylesheet tree: http://www.tei-c.org/stylesheet/base
Results to: mySchemas
Process steininschriften.odd to create stone{.dtd|.xsd|.doc.xml|.rng|.rnc} in mySchemas
========= 2005-04-24 10:54:13.N Roma starts, execution:
1. make Relax NG from ODD
warning: failed to load external entity "http://www.tei-c.org/stylesheet/base/p5/odds/odd2odd.xsl"
cannot parse http://www.tei-c.org/stylesheet/base/p5/odds/odd2odd.xsl
warning: failed to load external entity "stone.compiled.odd"
unable to parse stone.compiled.odd
stone.rng:1: parser error : Document is empty

^
stone.rng:1: parser error : Start tag expected, '<' not found

^
2. make Relax NG compact from XML
/Users/chris/tmp/HD/mySchemas/stone.rng:1: fatal: Document root element is missing.

ERROR:  trang fails.
============================================================

Roma seems to look for a file odd2odd.xsl which is nowhere to be
found, not in the CVS tree and not on the server and fails miserably.

Now, the second option is to run the online version, so I go to
http://www.tei-c.org.uk, upload my file, click on "Submit Query" and
proceed to "Schemas".  Trying to generate a schema results in the
message:

Time to give you a schema

MESSAGES
/tmp/f3a07941ebdaa21bb2e1e9d6fb0f7b7c.tmp:5:36: error: reference to undefined pattern "TEI"
Schema
Could not create schema

============================================================
This makes sense, since when I look at the Modules page, there seems
to be no module selected at all, at least no one shows up in the
list. I suspect that the input file has not been parsed correctly.

I wonder if I am doing something wrong here?  Have other council
members been successful in proceeding according to the Howto?

Slightly desperated,

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  Sun Apr 24 06:33:15 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 24 Apr 2005 12:33:15 +0200
Subject: [tei-council] P5 Howto - how?
In-Reply-To:  (Christian Wittern's message of
	"Sun, 24 Apr 2005 11:03:57 +0200")
References: 
Message-ID: 

Update:

I retrieved Roma V.1.11 from SF and successfully generated a schema
with that version.

Just for the record...

All the best,

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  Sun Apr 24 08:22:45 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 24 Apr 2005 08:22:45 -0400
Subject: [tei-council] P5 Howto - how?
In-Reply-To: 
References: 

Message-ID: <17003.36757.764722.863741@emt.wwp.brown.edu>

CW> I retrieved Roma V.1.11 from SF and successfully generated a
CW> schema with that version.

I have been having similar problems with 1.13 myself. Even though
Sourceforge will do a very nice job showing the differences[1], it
can be quite difficult to figure out. I believe (but I'm not sure)
that one of the major changes between 1.11 and 1.13 is that the
former generated the 'compiled.rng' file by applying
expandincludes.xsl to the .rng file that was the output of step 1
"make Relax NG from ODD"; the latter tries to generate the
'compiled.rng' file by applying odd2odd.xsl to the ODD file specified
on the Roma commandline (and fails for lack of odd2odd.xsl).

So it looks like backing out to 1.11 will *run* as long as the value
of --xsl= is set to a local directory. (If you want to use the web
for --xsl, try commenting out line 132.) I.e., it looks like all the
component parts that 1.11 calls exist. However, I don't know that
there haven't been significant changes to the .xsl files that are
called that depend on them being called in the way they are by 1.13
instead of by 1.11. It is certainly worth a try, though (and I plan
to do so right after breakfast ... :-)

CW> [Error from Roma web interface] makes sense, since when I look at
CW> the Modules page, there seems to be no module selected at all, at
CW> least no one shows up in the list. I suspect that the input file
CW> has not been parsed correctly.

I got this error once out of the two times I generated a schema via
the web yesterday. I fixed it very quickly by manually adding the
required modules: core, tei, header, & textstructure.

Notes
-----
[1] Try, e.g.,
http://cvs.sourceforge.net/viewcvs.py/tei/P5/Roma?sortby=date&r1=text&tr1=1.11&r2=text&tr2=1.13&diff_format=h

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Apr 24 12:25:32 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 24 Apr 2005 18:25:32 +0200
Subject: [tei-council] Draft agenda for AFNOR meeting 4/28-4/29
Message-ID: 

TEI Council Members,

This is the draft agenda for the TEI Council meeting to be held April
28th and 29th at AFNOR, Paris.  Please report any omissions as soon as
possible.

Please read through the following, and bring it along for the meeting.

Expected members to participate:

Syd Bauman, Alejandro Bia, Lou Burnard, James Cummings, Matthew
Driscoll, Julia Flanders, Laurent Romary, Natasha Smith, Susan
Schreibman, Edward Vanhoutte, John Walsh, Perry Willett, Christian
Wittern.

Sebastian Rahtz will not be able to participate.

Agenda:

1. Review of minutes from 3/29, adaption of agenda.

2. Principles of attribute usage in P5 (EDW86)

3. Principles of class definitions in P5 (EDW87)

-- in both cases we want to leave the meeting knowing that Council has
   read and understood the proposals for action contained; and that it
   either agrees to them or proposes alternatives

4. New work items
-- biblItem (Syd was supposed to be doing this)
-- PhysBib stuff (from Julia)
-- Revisions to Roma (assuming I can get the damn thing to work)
-- there may be others 
   (I have just been spending 10 days with people working on stone
   inscriptions from China and they say they want to describe their
   stones, with TEI)

5. Chapter Reviews

6. WG Reports

7. Other items

-- 

 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  Sun Apr 24 12:28:52 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 24 Apr 2005 18:28:52 +0200
Subject: [tei-council] P5 Howto - how?
In-Reply-To: <17003.36757.764722.863741@emt.wwp.brown.edu> (Syd Bauman's
	message of "Sun, 24 Apr 2005 08:22:45 -0400")
References:  
	<17003.36757.764722.863741@emt.wwp.brown.edu>
Message-ID: 

Syd Bauman  writes:

>
> CW> [Error from Roma web interface] makes sense, since when I look at
> CW> the Modules page, there seems to be no module selected at all, at
> CW> least no one shows up in the list. I suspect that the input file
> CW> has not been parsed correctly.
>
> I got this error once out of the two times I generated a schema via
> the web yesterday. I fixed it very quickly by manually adding the
> required modules: core, tei, header, & textstructure.

Yes, but then what is the point of uploading the customization?

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 Apr 24 19:18:12 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 25 Apr 2005 00:18:12 +0100
Subject: [tei-council] Draft agenda for AFNOR meeting 4/28-4/29
In-Reply-To: 
References: 
Message-ID: <426C2934.3030008@computing-services.oxford.ac.uk>

What time will the meeting start on the 28th?

I apologise in advance for being late -- my train is due to arrive GdN 
at 1250, so I doubt if I will be able to get to Afnor till 2 pm at the 
earliest.

a bientot!

Lou

Christian Wittern wrote:

>TEI Council Members,
>
>This is the draft agenda for the TEI Council meeting to be held April
>28th and 29th at AFNOR, Paris.  Please report any omissions as soon as
>possible.
>
>Please read through the following, and bring it along for the meeting.
>
>
>
>Expected members to participate:
>
>Syd Bauman, Alejandro Bia, Lou Burnard, James Cummings, Matthew
>Driscoll, Julia Flanders, Laurent Romary, Natasha Smith, Susan
>Schreibman, Edward Vanhoutte, John Walsh, Perry Willett, Christian
>Wittern.
>
>
>Sebastian Rahtz will not be able to participate.
>
>
>Agenda:
>
>1. Review of minutes from 3/29, adaption of agenda.
>
>2. Principles of attribute usage in P5 (EDW86)
>
>3. Principles of class definitions in P5 (EDW87)
>
>-- in both cases we want to leave the meeting knowing that Council has
>   read and understood the proposals for action contained; and that it
>   either agrees to them or proposes alternatives
>
>4. New work items
>-- biblItem (Syd was supposed to be doing this)
>-- PhysBib stuff (from Julia)
>-- Revisions to Roma (assuming I can get the damn thing to work)
>-- there may be others 
>   (I have just been spending 10 days with people working on stone
>   inscriptions from China and they say they want to describe their
>   stones, with TEI)
>
>
>5. Chapter Reviews
>
>6. WG Reports
>
>7. Other items
>
> 
>  
>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Apr 25 05:34:04 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 25 Apr 2005 11:34:04 +0200
Subject: [tei-council] Draft agenda for AFNOR meeting 4/28-4/29
In-Reply-To: <426C2934.3030008@computing-services.oxford.ac.uk> (Lou
	Burnard's message of "Mon, 25 Apr 2005 00:18:12 +0100")
References: 
	<426C2934.3030008@computing-services.oxford.ac.uk>
Message-ID: 

Lou Burnard  writes:

> What time will the meeting start on the 28th?

We agreed to start at 1400, so you have 70 minutes to come to AFNOR:-)

>
> I apologise in advance for being late -- my train is due to arrive GdN
> at 1250, so I doubt if I will be able to get to Afnor till 2 pm at the
> earliest.
>

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 computing-services.oxford.ac.uk  Tue Apr 26 20:34:32 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 27 Apr 2005 01:34:32 +0100 (BST)
Subject: [tei-council] not a report
Message-ID: <20050427003432.D36D92268A@webmail218.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/20050427/a77f2a62/attachment.ksh 

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Apr 27 04:09:31 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 27 Apr 2005 10:09:31 +0200
Subject: [tei-council] not a report
In-Reply-To: <20050427003432.D36D92268A@webmail218.herald.ox.ac.uk> (Sebastian
	Rahtz's message of "Wed, 27 Apr 2005 01:34:32 +0100 (BST)")
References: <20050427003432.D36D92268A@webmail218.herald.ox.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

> I cannot offer a formal report, but I would like to note for the council's
> interest that I have reimplemented a fair chunk of the way Roma works
> in order to meet some long-standing objectives.

This looks great, thanks a lot (I hope to test it later today on my
train to Paris)

All the best,

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  Mon May  2 10:10:56 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 2 May 2005 10:10:56 -0400
Subject: [tei-council] travel reimbursement form
Message-ID: <17014.13552.2218.678830@emt.wwp.brown.edu>

You can find slightly different versions of the travel reimbursement
form at

  http://www.tei-c.org/Members/TEI_travel_form.pdf
and 
  http://www.tei-c.org/travel_form.pdf

The former one has slightly larger type, and is therefore a bit
easier to use, but the latter one is a bit easier to get. The only
real difference I noticed was the address to which to send the form,
which is in Norway, and therefore both are now wrong. I believe the
correct address would be

 Text Encoding Initiative Consortium
 Attn: Daniel Pitti
 319 Alderman Library
 P.O. Box 400115
 University of Virginia
 Charlottesville, Virginia 22904-4115

(I will double-check with Daniel and post here only if that address
is significantly incorrect.)

From Julia_Flanders at Brown.edu  Mon May  2 14:38:39 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Mon, 2 May 2005 14:38:39 -0400
Subject: [tei-council] travel reimbursement
Message-ID: 

Dear Council members,

The travel reimbursement form may be found at

http://www.tei-c.org/travel_form.pdf

This form still carries the old TEI administrative address in Norway. 
An updated form will be posted shortly, but in the meantime please 
note that all reimbursement requests should be sent to the following 
address:

Text Encoding Initiative Consortium
Institute for Advanced Technology in the Humanities
319 Alderman Library
P.O. Box 400115
University of Virginia
Charlottesville, Virginia 22904-4115

Please attach your original receipts, including boarding passes, 
ticket stubs, and meal receipts. If you paid TEI-related expenses for 
someone else (e.g. if you paid for someone else's lunch at AFNOR), 
please enclose a note mentioning this so that it's clear to Daniel 
how the costs are justified.

Thanks--Julia

From James.Cummings at computing-services.oxford.ac.uk  Sun May  1 18:12:02 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Mon, 02 May 2005 00:12:02 +0200
Subject: [tei-council] Photos
Message-ID: <42755432.7020109@computing-services.oxford.ac.uk>

In case anyone was interested in some of the photos I took of council
members while in Paris, they are online.  I was putting my other photos
online so thought I'd do so with these as well.

http://oucs-jamesc.oucs.ox.ac.uk:8080/gallery/Tei-Council-2005-04/

-James

From lou.burnard at computing-services.oxford.ac.uk  Tue May  3 17:20:48 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 3 May 2005 22:20:48 +0100
Subject: [tei-council] Photos
In-Reply-To: <42755432.7020109@computing-services.oxford.ac.uk>
References: <42755432.7020109@computing-services.oxford.ac.uk>
Message-ID: <4ee3e3dbf68b679785649291dfa79eb1@computing-services.oxford.ac.uk>

Not to be outdone....

http://www.burnards.net/Paris/

L

On 1 May 2005, at 23:12, James Cummings wrote:

> In case anyone was interested in some of the photos I took of council
> members while in Paris, they are online.  I was putting my other photos
> online so thought I'd do so with these as well.
>
> http://oucs-jamesc.oucs.ox.ac.uk:8080/gallery/Tei-Council-2005-04/
>
> -James
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
 From the Macmini at Burnard Towers

From lou.burnard at computing-services.oxford.ac.uk  Wed May  4 12:36:31 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 04 May 2005 17:36:31 +0100
Subject: [tei-council] edw87 updated; edw86 less so
Message-ID: <4278FA0F.7070501@oucs.ox.ac.uk>

I hope everyone had a bearable journey home (and a nice sunny weekend 
too), and thanks for all the input.

I've made a start on updating the two working papers we spent the first 
part of the meeting on, as far as I can. The changes needed to edw87 
were fairly straightforward, and I had made enough notes to give me 
confidence I have done that one right. There were quite a few 
suggestions for edw87 (as far as I recall) for which input from others 
is neded, so I am less confident that I have done that right.

No doubt the minutes will reveal all, when they appear.

Onward and upward!

Lou

From Julia_Flanders at Brown.edu  Wed May  4 13:45:17 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Wed, 4 May 2005 13:45:17 -0400
Subject: [tei-council] PB group, new chair
Message-ID: 

I am happy to report that Murray McGillivray has agreed to take over 
the leadership of the PB workgroup. I've forwarded him the Council's 
recommendations for things the group should look at. If anyone has 
additional thoughts, please send them along.

Best wishes, Julia

From Syd_Bauman at Brown.edu  Wed May  4 22:05:34 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 4 May 2005 22:05:34 -0400
Subject: [tei-council] first draft of minutes of 2005-04-28/29 meeting
	available
Message-ID: <17017.32622.51973.739412@emt.wwp.brown.edu>

First draft of minutes is now available at
   http://www.tei-c.org/Council/tcm17.xml?style=printable
but is deliberately not linked from the Council index page (or
anywhere else) yet. Everyone should please read them (particularly
searching for your own name or initials or the string "[?") and post
any corrections, additions, omissions, deletions, complaints, etc.

From lou.burnard at computing-services.oxford.ac.uk  Thu May  5 13:02:16 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 05 May 2005 18:02:16 +0100
Subject: [tei-council] first draft of minutes of 2005-04-28/29 meeting
	available
In-Reply-To: <17017.32622.51973.739412@emt.wwp.brown.edu>
References: <17017.32622.51973.739412@emt.wwp.brown.edu>
Message-ID: <427A5198.8040905@oucs.ox.ac.uk>

Thanks for these Syd. I've now made some updates, clarifying points of 
uncertainty to the best of my ability and removing one or two typos. The 
only thing I cannot help with is the item that reads

tei.numeric ? missed something here?

as I don't remember what it was that was being discussed at this point. 
Unless anyone else can remember, I suggest you should delete this from 
the record!

The revised draft is at

 http://www.tei-c.org/Council/tcm17.xml

as usual.

Thanks again to all Council members for your active participation -- and willingness to take on new burdens! -- at what was definitely a very productive meeting.

Lou

Syd Bauman wrote:

>First draft of minutes is now available at
>   http://www.tei-c.org/Council/tcm17.xml?style=printable
>but is deliberately not linked from the Council index page (or
>anywhere else) yet. Everyone should please read them (particularly
>searching for your own name or initials or the string "[?") and post
>any corrections, additions, omissions, deletions, complaints, etc.
>
>_______________________________________________
>tei-council mailing list
>tei-council at lists.village.Virginia.EDU
>http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
>  
>

From Julia_Flanders at Brown.edu  Thu May  5 13:59:37 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 5 May 2005 13:59:37 -0400
Subject: [tei-council] first draft of minutes of 2005-04-28/29 meeting
	available
In-Reply-To: <427A5198.8040905@oucs.ox.ac.uk>
References: <17017.32622.51973.739412@emt.wwp.brown.edu>
	<427A5198.8040905@oucs.ox.ac.uk>
Message-ID: 

The point on tei.numeric that I remember was that we were going to 
consider whether we needed a TEI data type that could accommodate 
more specific kinds of numeric data....? I remember Laurent 
suggesting a tei.formula (or something to that effect), which could 
be what this is gesturing towards.

EDW86 seems to be malformed and can't be read at the moment, so I 
can't jog my memory by looking at the list of proposed datatypes.

best, Julia

>tei.numeric ? missed something here?
>
>as I don't remember what it was that was being discussed at this 
>point. Unless anyone else can remember, I suggest you should delete 
>this from the record!

From lou.burnard at computing-services.oxford.ac.uk  Thu May  5 15:44:02 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 5 May 2005 20:44:02 +0100
Subject: [tei-council] first draft of minutes of 2005-04-28/29 meeting
	available
In-Reply-To: 
References: <17017.32622.51973.739412@emt.wwp.brown.edu>
	<427A5198.8040905@oucs.ox.ac.uk>

Message-ID: <6330b2d3c9db3a066fde449be8ea2f24@computing-services.oxford.ac.uk>

On 5 May 2005, at 18:59, Julia Flanders wrote:

> The point on tei.numeric that I remember was that we were going to 
> consider whether we needed a TEI data type that could accommodate more 
> specific kinds of numeric data....? I remember Laurent suggesting a 
> tei.formula (or something to that effect), which could be what this is 
> gesturing towards.
>
> EDW86 seems to be malformed and can't be read at the moment, so I 
> can't jog my memory by looking at the list of proposed datatypes.
>

Aaargh! Thanks for pointing this out -- I have now fixed the stupid 
tagging error.

Here's the text I added to edw86  which I think expresses what we were 
discussing:

The suggested tei.numeric is a deliberately vague general class, 
intended to encompass a number of more precise datatypes (analogous 
therefore to tei.tempexp). For example, we might want to restrict some 
attribute values to a quantity which might be represented either as a 
real number in the range 0 to 1 or as a percentage; in other cases, it 
might make no sense to have any non-integral value, or to permit a 
negative value. We have nothing analogous to the valList to express 
these constraints on numeric values.

Lou "thumbs" Burnard

> best, Julia
>
>> tei.numeric ? missed something here?
>>
>> as I don't remember what it was that was being discussed at this 
>> point. Unless anyone else can remember, I suggest you should delete 
>> this from the record!
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>
 From the Macmini at Burnard Towers

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu May  5 18:48:37 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 06 May 2005 07:48:37 +0900
Subject: [tei-council] first draft of minutes of 2005-04-28/29 meeting
	available
In-Reply-To: <17017.32622.51973.739412@emt.wwp.brown.edu> (Syd Bauman's
	message of "Wed, 4 May 2005 22:05:34 -0400")
References: <17017.32622.51973.739412@emt.wwp.brown.edu>
Message-ID: 

Syd Bauman  writes:

> First draft of minutes is now available at
>    http://www.tei-c.org/Council/tcm17.xml?style=printable
> but is deliberately not linked from the Council index page (or
> anywhere else) yet. Everyone should please read them (particularly
> searching for your own name or initials or the string "[?") and post
> any corrections, additions, omissions, deletions, complaints, etc.

Thanks a lot, Syd.  This looks like a pretty fair summary of our work.
Here is a small nit to pick:

Meetings were held at AFNOR (room 34), from 14:15 to 18:00 on Thu 28
and from 09:05 to 16:51 on Fri 29, with a lunch break from 12:30 to
13:45. Because her purse had been stolen in Paris, Susan Schreibman
was unable to attend on Saturday; Laurent Romary left at 12:28 on
Saturday

Saturday --> Friday

All the best,

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  Thu May  5 19:16:39 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 5 May 2005 19:16:39 -0400
Subject: [tei-council] first draft of minutes of 2005-04-28/29 meeting
	available
In-Reply-To: 
References: <17017.32622.51973.739412@emt.wwp.brown.edu>

Message-ID: <17018.43351.201800.497555@emt.wwp.brown.edu>

> Thanks a lot, Syd. This looks like a pretty fair summary of our
> work. Here is a small nit to pick:
> 
> Saturday --> Friday

Whoah! Guess I was more jet-lagged than I thought.
Fixed, thanks.

From lou.burnard at computing-services.oxford.ac.uk  Fri May  6 08:58:46 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 06 May 2005 13:58:46 +0100
Subject: [tei-council] ODD manual
Message-ID: <427B6A06.2060403@oucs.ox.ac.uk>

I have now found time to unpack some of the goodies Sebastian has been 
despatching from the other side of the world. One is a preliminary draft 
for a "TEI Customization Handbook" which aims to set out all you need in 
order to adapt the TEI for your own needs.  He intended to distribute 
this to the Council before the Paris meeting, but the PDF file he sent 
was stripped by the listserv in virginia, and I was too preoccupied with 
other things to do anything about sending out an alternative.

Anyway, please visit http://www.tei-c.org/ODD/Manual/ now to see the 
draft in question.

I think the doc is a good start but needs quite a bit more work. The 
tone is closer to that of TD , the reference chapter of P5 (which it 
overlaps somewhat) than of -- say -- the TEI Lite tutorial: I feel that 
it needs to be chattier and more accessible, with plenty of simpler 
examples before hitting people with e.g. xinclude. Above all, it should 
take a more "cookbook" style approach e.g. in presenting Roma.  I think 
the order of presentation is wrong: dtd and relaxng wrappers should be 
relegated to an appendix.  The lists of classes currently in the 
appendix are necessary, but probably should be referenced from here, not 
included in the document, as we will soon have far too many such lists 
to cope with.

But I think the coverage is right: do Council members have suggestions 
for other topics they think such a document really must address, bearing 
in mind the distinction we made at the Paris meeting between
(a) reference documentation in the P5 Guidelines (TD, CF)
(b) tutorial introductions (this document)

Lou

From Laurent.Romary at loria.fr  Fri May  6 09:29:12 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Fri, 6 May 2005 15:29:12 +0200
Subject: [tei-council] ODD manual
In-Reply-To: <427B6A06.2060403@oucs.ox.ac.uk>
References: <427B6A06.2060403@oucs.ox.ac.uk>
Message-ID: 

Having just gone through the document, I actually think it of great 
help for ODD beginners. I would just suggest not to blur the picture 
with the first sections related to DTDs and Schemas. I would move them 
as appendices to the main document. I would also make a stringer view 
on the fact that point 3 is the recommended one when listing the ways 
of customizing the TEI.
Best,
Laurent

Le 6 mai 05, ? 14:58, Lou Burnard a ?crit :

> I have now found time to unpack some of the goodies Sebastian has been 
> despatching from the other side of the world. One is a preliminary 
> draft for a "TEI Customization Handbook" which aims to set out all you 
> need in order to adapt the TEI for your own needs.  He intended to 
> distribute this to the Council before the Paris meeting, but the PDF 
> file he sent was stripped by the listserv in virginia, and I was too 
> preoccupied with other things to do anything about sending out an 
> alternative.
>
> Anyway, please visit http://www.tei-c.org/ODD/Manual/ now to see the 
> draft in question.
>
> I think the doc is a good start but needs quite a bit more work. The 
> tone is closer to that of TD , the reference chapter of P5 (which it 
> overlaps somewhat) than of -- say -- the TEI Lite tutorial: I feel 
> that it needs to be chattier and more accessible, with plenty of 
> simpler examples before hitting people with e.g. xinclude. Above all, 
> it should take a more "cookbook" style approach e.g. in presenting 
> Roma.  I think the order of presentation is wrong: dtd and relaxng 
> wrappers should be relegated to an appendix.  The lists of classes 
> currently in the appendix are necessary, but probably should be 
> referenced from here, not included in the document, as we will soon 
> have far too many such lists to cope with.
>
> But I think the coverage is right: do Council members have suggestions 
> for other topics they think such a document really must address, 
> bearing in mind the distinction we made at the Paris meeting between
> (a) reference documentation in the P5 Guidelines (TD, CF)
> (b) tutorial introductions (this document)
>
> Lou
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

From Julia_Flanders at Brown.edu  Fri May  6 13:22:31 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Fri, 6 May 2005 13:22:31 -0400
Subject: [tei-council] ODD manual
In-Reply-To: <427B6A06.2060403@oucs.ox.ac.uk>
References: <427B6A06.2060403@oucs.ox.ac.uk>
Message-ID: 

I really enjoyed reading this document (!?!). I agree, it will 
benefit from being made even more accessible, and from explaining 
things in a bit more detail. But overall I think it's a really good 
start.

A few points for revision which you may already have noted:

--move the explanation of the mode= attribute on  to 
precede the discussion of adding a new element, since that example 
uses the mode= attribute; might even want to have a little section 
heading there like "modifications to the schema" or whatever, with a 
topic sentence like "You can add, replace, remove, or change elements 
using the mode= attribute on ..."

--I think you need to briefly describe the nature, usage, and 
implications of the tei class system at some point fairly early on, 
or at least mention that it exists and point the reader to the 
appendix. (And even in that case, the appendix in its current form 
doesn't discuss any issues surrounding the use of classes--for 
instance, making sure the novice knows that an element may belong to 
more than one class, or that the classes have no relation to the 
modules. So some more extended discussion of how it all works would 
be great.) I first noticed the need in section 4 (Writing ODD 
specifications) in the example of adding a new element, where it 
points out that you can specify what class(es) the new element will 
be added to. By the time we get to the example of adding the  
element the need is more acute. For instance, when reading through 
the example, I find myself wondering what the implications of 
including an element in a particular class are: does it mean that it 
gets to use certain attributes? can one add an element to any class 
at will or is there a possibility of producing something that is 
self-contradictory at a technical level (that is, it's not just 
silly--it doesn't work). I don't think (anticipating a possible 
objection) that the class system needs to be presented in huge detail 
to bog the reader down, just a brief explanation to anticipate these 
kinds of questions, with a pointer to some more complete account 
elsewhere.

--I was glad to see the sentence (after that example) "There is no 
need to specify a module for the element to appear in, as this would 
not be used for anything." and in fact I thought it could have been 
stated even earlier, after that first  example (that was 
where the question occurred to me). Perhaps this sentence could be 
placed together with "For objects which are not new, you should 
specify the module in which it was originally defined" right near the 
beginning of the section on modifications. At the moment, 
instructions like these are scattered through as comments on 
examples, rather than being given together as a set of principles--I 
wonder whether the latter might be a useful approach (perhaps with 
reminders as glosses/commentary on specific examples).

--the  example takes several readings to grasp; I think it's 
confusing partly because it's sort of a meta-example, and this isn't 
made absolutely clear in the prose. (I even misread "This 
document..." as meaning "the document you're about to see in the next 
example" rather than "the document you're reading", and I think that 
it could also be made much clearer that the  element is not 
a TEI element. Possible rewrite for that sentence: "The document you 
are now reading, for instance, pulls in tables created by automatic 
processes using a non-TEI element :
[example]
This  element needs to be able to appear almost everywhere, 
so we want to add it to a TEI class whose members are permitted 
almost everywhere; tei.Incl does this job nicely."

--Appendix C, TEI Macros needs more explanatory prose, and also needs 
to make clearer what the stuff in the green boxes is. This section is 
more or less opaque to a novice.

At whatever point in the revision process you think it would be 
useful, I'd be glad to send a list of things that need clarification 
for a more novice reader (i.e. if you want to do the revisions you 
suggest first, I could do a pass on the results).

Best wishes, Julia

At 1:58 PM +0100 5/6/05, Lou Burnard wrote:
>I have now found time to unpack some of the goodies Sebastian has 
>been despatching from the other side of the world. One is a 
>preliminary draft for a "TEI Customization Handbook" which aims to 
>set out all you need in order to adapt the TEI for your own needs. 
>He intended to distribute this to the Council before the Paris 
>meeting, but the PDF file he sent was stripped by the listserv in 
>virginia, and I was too preoccupied with other things to do anything 
>about sending out an alternative.
>
>Anyway, please visit http://www.tei-c.org/ODD/Manual/ now to see the 
>draft in question.
>
>I think the doc is a good start but needs quite a bit more work. The 
>tone is closer to that of TD , the reference chapter of P5 (which it 
>overlaps somewhat) than of -- say -- the TEI Lite tutorial: I feel 
>that it needs to be chattier and more accessible, with plenty of 
>simpler examples before hitting people with e.g. xinclude. Above 
>all, it should take a more "cookbook" style approach e.g. in 
>presenting Roma.  I think the order of presentation is wrong: dtd 
>and relaxng wrappers should be relegated to an appendix.  The lists 
>of classes currently in the appendix are necessary, but probably 
>should be referenced from here, not included in the document, as we 
>will soon have far too many such lists to cope with.
>
>But I think the coverage is right: do Council members have 
>suggestions for other topics they think such a document really must 
>address, bearing in mind the distinction we made at the Paris 
>meeting between
>(a) reference documentation in the P5 Guidelines (TD, CF)
>(b) tutorial introductions (this document)
>
>Lou
>_______________________________________________
>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  Fri May  6 22:04:25 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 07 May 2005 11:04:25 +0900
Subject: [tei-council] ODD manual
In-Reply-To:  (Julia Flanders's
	message of "Fri, 6 May 2005 13:22:31 -0400")
References: <427B6A06.2060403@oucs.ox.ac.uk>

Message-ID: 

Julia Flanders  writes:

> I really enjoyed reading this document (!?!). I agree, it will benefit
> from being made even more accessible, and from explaining things in a
> bit more detail. But overall I think it's a really good start.

Having briefly read through the document, I can only second Julia's
statement.  I wish we had this document available a week before the
Council meeting...  Naturally, I now hope that the new [Rr]oma will be
beginning to take orders soon:-)

The appendices about the tei classes and macros are extremely
valuable, this is material I long tried to find without success.  Is
this reflecting the current state of P5?

All the best,

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  Sat May  7 19:00:52 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 7 May 2005 19:00:52 -0400
Subject: [tei-council] CVS README
In-Reply-To: <4261985B.1020401@computing-services.oxford.ac.uk>
References: <425FDFF4.4000709@computing-services.oxford.ac.uk>
	<16992.48648.567828.308516@emt.wwp.brown.edu>
	<4261985B.1020401@computing-services.oxford.ac.uk>
Message-ID: <17021.18596.791121.964838@emt.wwp.brown.edu>

James --
  Where is the current version of the CVS P5 Module README (or
whatever it's called) file?

  Thanks

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon May  9 02:07:44 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 09 May 2005 15:07:44 +0900
Subject: [tei-council] P5, roma and bibl[Item|Struct]
Message-ID: 

Council members,

In trying to follow the fine manual on ODD and actually develop some
of my customizations toward P5, I tried to provide myself with a
usable roma today.  To this end, I followed the following steps:

- updated my CVS tree of the TEI modules on SF
- copied a version of the P5 to a temporary location (did not want to
  mess up the working directory)
- extracted the files from Sebastian (p5.tar.gz and xsl.tar.gz) over
  this, both for the files from 4/27 and those of 4/28; the xsl files
  went into a previously created installation at /usr/local/share/xml/tei/stylesheet
- I did issue a make after setting my XSL to the above directory /base/p5 in
  the Makefile. 
- This gave me functional stuff (I think) in $P5/Split and
  $P5/Schemas, but the build of the html version of the Guidelines
  still failes (due to Sebastians restructuring of the directory
  structure of the Stylesheets section, I think)
- Since the various exist related scripts called from the Makefile did
  not seem to work with my version of exist, I created and populated
  the TEI collection by hand.
- I now used the new roma script Sebastian send with the other files
  on 4/27. 
- This gave me RN[GC] and DTD files, but the XSD production ended with
  the message that "biblStruct" was not defined.

I now went back to the non-patched version of the TEI SF tree and
grepped through the Source directories, this indeed turned up both
references to biblStruct and biblItem in CO/ (and possibly
elsewhere).   I wonder why we do have  in here and why it
seems to be more priviliged than ? 

This seems to be the last(?) stumbling block here and I would hope
that Syd or Lou will be able to remove it...

If you followed me so far, you might want to try it yourself; to make
this possible, I moved the stylesheets into exist as well, my
invocation of roma (I renamed roma to roma-new) is then:

sh roma-new --teiserver=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/ --xsl=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/stylesheet Test/testlite.odd

called from the P5 directory.

The relevant output portion is as follows:

========= 2005-05-09 15:04:08 Roma starts, info:
Test for software: xmllint, xsltproc, trang, and perl
/sw/bin/xmllint
/sw/bin/xsltproc
/Users/chris/bin/trang
/usr/bin/perl
TEI database server: http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/
TEI stylesheet tree: http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/stylesheet
Results to: RomaResults
Process Test/testlite.odd to create testlite{.dtd|.xsd|.doc.xml|.rng|.rnc} in RomaResults
========= 2005-05-09 15:04:10.N Roma starts, execution:
1. make Relax NG from ODD
2. make Relax NG compact from XML
3. make XSD from Relax NG and then mangle XSD
/private/tmp/P5/RomaResults/testlite.rng:4364: error: reference to undefined pattern "biblStruct"

ERROR:  trang fails.
This was a fatal error. 2005-05-09 15:04:35.N

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  Mon May  9 04:43:59 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 09 May 2005 09:43:59 +0100
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: 
References: 
Message-ID: <427F22CF.1050305@oucs.ox.ac.uk>

Christian Wittern wrote:
> Council members,
> 
[...]

> - This gave me functional stuff (I think) in $P5/Split and
>   $P5/Schemas, but the build of the html version of the Guidelines
>   still failes (due to Sebastians restructuring of the directory
>   structure of the Stylesheets section, I think)

The xsl files guidelines.xsl and guidelines-print.xsl in the P5 
directory need to be changed to reference the new stylesheet directory 
name -- I got that far last night!

[...]

> I now went back to the non-patched version of the TEI SF tree and
> grepped through the Source directories, this indeed turned up both
> references to biblStruct and biblItem in CO/ (and possibly
> elsewhere).   I wonder why we do have  in here and why it
> seems to be more priviliged than ? 
> 

This is very odd. Syd did remove biblStruct from the CVS tree, but I 
thought I had prevailed on him to put it  back. Certainly it seems to be 
there now (I just did a CVS update to check). Can you confirm that there 
is a line declaring it in your copy of P5/fileents.dtd ?

> This seems to be the last(?) stumbling block here and I would hope
> that Syd or Lou will be able to remove it...
> 
> If you followed me so far, you might want to try it yourself; to make
> this possible, I moved the stylesheets into exist as well, my
> invocation of roma (I renamed roma to roma-new) is then:
> 
>

I am lost in admiration!

  sh roma-new 
--teiserver=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/ 
--xsl=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/stylesheet 
Test/testlite.odd
> 
> called from the P5 directory.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon May  9 08:50:55 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 09 May 2005 21:50:55 +0900
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: <427F22CF.1050305@oucs.ox.ac.uk> (Lou Burnard's message of
	"Mon, 09 May 2005 09:43:59 +0100")
References:  <427F22CF.1050305@oucs.ox.ac.uk>
Message-ID: 

Lou Burnard  writes:

> Christian Wittern wrote:
>> I now went back to the non-patched version of the TEI SF tree and
>> grepped through the Source directories, this indeed turned up both
>> references to biblStruct and biblItem in CO/ (and possibly
>> elsewhere).   I wonder why we do have  in here and why it
>> seems to be more priviliged than ? 
>
> This is very odd. Syd did remove biblStruct from the CVS tree, but I
> thought I had prevailed on him to put it  back. Certainly it seems to
> be there now (I just did a CVS update to check). Can you confirm that
> there is a line declaring it in your copy of P5/fileents.dtd ?

OK, now I understand.  The file in CVS (1.7) is dated 4/21 (on my
system), the one in Sebastians "patch" 4/7 and probably older.  What a
mess.  Here is the relevant part of the Changelog:
----------------------------
revision 1.7
date: 2005/04/15 15:30:45;  author: sbauman;  state: Exp;  lines: +13 -10
Re-instate .
----------------------------
revision 1.6
date: 2005/04/11 16:41:30;  author: louburnard;  state: Exp;  lines: +1 -0
SPQR's changes from Dili

What I do not understand is why there is still a biblitem even in the
latest version? And what about references to these things in the other
files?

Well, I'll just give it another try.

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  Mon May  9 08:54:13 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 09 May 2005 13:54:13 +0100
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: 
References:  <427F22CF.1050305@oucs.ox.ac.uk>

Message-ID: <427F5D75.70107@oucs.ox.ac.uk>

The problem is that Sebastian's files won't reflect any changes made to 
CVS after he left. Which is why I am being a bit careful about just 
uploading them all without checking. Since there are a lot of them, this 
takes time...

Christian Wittern wrote:
> Lou Burnard  writes:
> 
> 
>>Christian Wittern wrote:
>>
>>>I now went back to the non-patched version of the TEI SF tree and
>>>grepped through the Source directories, this indeed turned up both
>>>references to biblStruct and biblItem in CO/ (and possibly
>>>elsewhere).   I wonder why we do have  in here and why it
>>>seems to be more priviliged than ? 
>>
>>This is very odd. Syd did remove biblStruct from the CVS tree, but I
>>thought I had prevailed on him to put it  back. Certainly it seems to
>>be there now (I just did a CVS update to check). Can you confirm that
>>there is a line declaring it in your copy of P5/fileents.dtd ?
> 
> 
> OK, now I understand.  The file in CVS (1.7) is dated 4/21 (on my
> system), the one in Sebastians "patch" 4/7 and probably older.  What a
> mess.  Here is the relevant part of the Changelog:
> ----------------------------
> revision 1.7
> date: 2005/04/15 15:30:45;  author: sbauman;  state: Exp;  lines: +13 -10
> Re-instate .
> ----------------------------
> revision 1.6
> date: 2005/04/11 16:41:30;  author: louburnard;  state: Exp;  lines: +1 -0
> SPQR's changes from Dili
> 
> What I do not understand is why there is still a biblitem even in the
> latest version? And what about references to these things in the other
> files?
> 
> Well, I'll just give it another try.
> 
> All the best,
> 
> Christian
> 
> 

From Syd_Bauman at Brown.edu  Mon May  9 14:16:18 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 9 May 2005 14:16:18 -0400
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: 
References:  <427F22CF.1050305@oucs.ox.ac.uk>

Message-ID: <17023.43250.121807.807560@emt.wwp.brown.edu>

I am planning to take James' HOWTO and, pretending I've never done
this before, build a P5 following the instructions. I plan to report
both my findings on how good the instructions are, and the status of
the buildability of P5 and status of stuff. However, you (CW)
have beaten me to the latter, and so far as I can tell, you're
description of the problem is right.

Lou is correct, I did put  back into the P5 source.

> What I do not understand is why there is still a biblitem even in
> the latest version?

I wasn't aware there is any reason to take it out. Lou's (and, since
he has now prevailed upon me, my) thinking is that Council will need
to look at both of these elements and decide which one(s) stay in P5.
Obviously since our Paris meeting Council will be waiting to hear
from me about my success or failuer of the P5 bibliography first.
(About which I hope to have something intelligent to say at our 08
Jul conference call.)

From sschreib at umd.edu  Mon May  9 17:45:15 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Mon, 9 May 2005 17:45:15 -0400
Subject: [tei-council] problems with online Roma
Message-ID: <200505092145.AJC07737@md2.mail.umd.edu>

>
hi all -- I'm not sure this ever got to the council list as it got bumped at
UVA -- if it did, forgive for reposting
 * * * 

>I've been trying to get the new version of Roma to work for me a couple of 
>times, and I keep stalling. I tried both using Firefox and IE on a PC using
XP. The >first submit button works fine on 
>http://tei.oucs.ox.ac.uk/Roma/.
>
>But then, after I fill up my details under
>http://tei.oucs.ox.ac.uk/Roma/
startroma.php
>
>and press submit, I don't go to another form, nor do I get some type of 
>success message - so I am not sure if after pressing submit I should be 
>taken to another page, or I should choose an option myself from the tabs 
>across the top.
>
>I decided to go to the Modules tab myself, and I got the following error 
>message. This is the second time I've tried using the new interface, and I 
>have come up against the same problem (at first I thought it might just be 
>internet gremlins). Perhaps I am doing something wrong. If I am, perhaps I 
>could help to make the Customization Handbook clearer so that others don't 
>make the same mistake. I also could not seem to get help to work.
>
>susan
>
>
>Warning: file(http://localhost:8080/cocoon/Query//modules.xq) 
>[function.file]: failed to 
>open stream: HTTP request failed! HTTP/1.1 404 Not Found in 
>/usr/share/tei-roma/roma/roma.php on line 554
>
>Warning: join() 
>[function.join]: Bad 
>arguments. in /usr/share/tei-roma/roma/roma.php on line 554
>
>Warning: DOMDocument::loadXML() 
>[function.loadXML]: Empty 
>string supplied as input in /usr/share/tei-roma/roma/roma.php on line 554
>
>Warning: importNode() expects parameter 1 to be DOMNode, null given in 
>/usr/share/tei-roma/roma/roma.php on line 555
>
>Warning: appendChild() expects parameter 1 to be DOMNode, null given in 
>/usr/share/tei-roma/roma/roma.php on line 556
>

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon May  9 07:36:36 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 09 May 2005 12:36:36 +0100
Subject: [tei-council] ODD manual
In-Reply-To: 
References: <427B6A06.2060403@oucs.ox.ac.uk>	

Message-ID: <427F4B44.2020007@computing-services.oxford.ac.uk>

Christian Wittern wrote:

> I wish we had this document available a week before the
>Council meeting...
>
that was indeed the intention, and the writing was done in time.
Sadly, email is not as reliable as it might be.

>  Naturally, I now hope that the new [Rr]oma will be
>beginning to take orders soon:-)
>  
>
I'm going to Australia on 22nd May, and I expect to find
some networking there which will let me do some serious
uploads.

>The appendices about the tei classes and macros are extremely
>valuable, this is material I long tried to find without success.  Is
>this reflecting the current state of P5?
>  
>
it is automatically generated from the P5 on my computer;
not all of which is even in CVS yet. I need to do some delicate merging
when I get online.

-- 
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 computing-services.oxford.ac.uk  Mon May  9 08:05:54 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 09 May 2005 13:05:54 +0100
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: 
References: 
Message-ID: <427F5222.4090600@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>- This gave me functional stuff (I think) in $P5/Split and
>  $P5/Schemas, but the build of the html version of the Guidelines
>  still failes (due to Sebastians restructuring of the directory
>  structure of the Stylesheets section, I think)
>  
>
that's expected, yes. My whole stylesheet collection
is restructured and mangled and breaks almost all
existing wrapper stylesheets :-}

>- This gave me RN[GC] and DTD files, but the XSD production ended with
>  the message that "biblStruct" was not defined.
>  
>
this is an ongoing issue with the source tree, that the bibl* work
is only half-complete. you just have to work around it for now. I cannot
say for certain why my setup works, I must have done
some temporary hack to get it working.

>If you followed me so far, you might want to try it yourself; to make
>this possible, I moved the stylesheets into exist as well, my
>invocation of roma (I renamed roma to roma-new) is then:
>
>sh roma-new --teiserver=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/ --xsl=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/stylesheet Test/testlite.odd
>
>  
>
you have no idea now happy it makes me to see 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 sebastian.rahtz at computing-services.oxford.ac.uk  Mon May  9 08:22:20 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 09 May 2005 13:22:20 +0100
Subject: [tei-council] ODD manual
In-Reply-To: <427B6A06.2060403@oucs.ox.ac.uk>
References: <427B6A06.2060403@oucs.ox.ac.uk>
Message-ID: <427F55FC.7070200@computing-services.oxford.ac.uk>

Lou Burnard wrote:

> TEI Lite tutorial: I feel that it needs to be chattier and more 
> accessible, with plenty of simpler examples before hitting people with 
> e.g. xinclude. Above all, it should take a more "cookbook" style 
> approach e.g. in presenting Roma.  

yes, I agree that the Roma section remains skeletal. I would much 
appreciate considerably more text in this area.

> I think the order of presentation is wrong: dtd and relaxng wrappers 
> should be relegated to an appendix.

that was one of things I was hoping to get comments on, about how 
important it was to mention this, and in what order.

perhaps surprisingly, I feel more strongly than most of you seem to that 
the Relax Wrapper Method
is worth explaining. It is the more likely route to take if you want to 
pull TEI into another scheme.

> The lists of classes currently in the appendix are necessary, but 
> probably should be referenced from here, not included in the document, 
> as we will soon have far too many such lists to cope with.

the reference lists are a detail we can sort out later, I think

Lou, since I am now working in other areas for the rest of my time here 
(ie worrying about writing talks
to give in Australia....), feel free to hack the document around as much 
as you see fit.

-- 
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 computing-services.oxford.ac.uk  Mon May  9 08:38:06 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 09 May 2005 13:38:06 +0100
Subject: [tei-council] ODD manual
In-Reply-To: 
References: <427B6A06.2060403@oucs.ox.ac.uk>

Message-ID: <427F59AE.5030909@computing-services.oxford.ac.uk>

Julia Flanders wrote:

>  For instance, when reading through the example, I find myself 
> wondering what the implications of including an element in a 
> particular class are: does it mean that it gets to use certain 
> attributes? can one add an element to any class at will or is there a 
> possibility of producing something that is self-contradictory at a 
> technical level (that is, it's not just silly--it doesn't work). I 
> don't think (anticipating a possible objection) that the class system 
> needs to be presented in huge detail to bog the reader down, just a 
> brief explanation to anticipate these kinds of questions, with a 
> pointer to some more complete account elsewhere. 

You have come across, I think, a tension in this document which is 
caused by not knowing what what else
people will have read when they come to this stuff.  My intention in 
writing it is that it will appear in a book
about the TEI, which would be self-contained (ie, not mandate access to 
the complete Guidelines). So an earlier chapter would
have explained the class system and answered your (entirely sensible) 
questions.

of course, the big chapter in the Guidelines will need lots of rewriting 
in this area too.

how to predict whether what you do will cause self-contradictory results 
is a thorny issue,
which Laurent's folks raised too. Yesterday I made an Odd which deleted 
 but not 
.
Not surprisingly, the schema was invalid. All my tools so far fail to 
give much help in warning me
this was a dumb thing to do.

-- 
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 computing-services.oxford.ac.uk  Mon May  9 19:28:41 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 10 May 2005 00:28:41 +0100
Subject: [tei-council] ODD manual
In-Reply-To: 
References: <427B6A06.2060403@oucs.ox.ac.uk>

Message-ID: <427FF229.2040608@computing-services.oxford.ac.uk>

Of course,  really the best thing everyone can do is actually try to write
an ODD for themselves, and test whether

a) they can express what they need
b) the result comes out as expected

adding more real-life examples to the manual would be a great help.

if you do get it working, really watch out for b). If one of you
cannot come up with an ODD spec which makes the tools
fall over in a complete heap, I'd be very surprised.

sebastian

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue May 10 07:31:45 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 10 May 2005 20:31:45 +0900
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: <427F5222.4090600@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Mon, 09 May 2005 13:05:54 +0100")
References: 
	<427F5222.4090600@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

>>
>>sh roma-new --teiserver=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/ --xsl=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/stylesheet Test/testlite.odd
>>
>>  
>>
> you have no idea now happy it makes me to see this.....
>

You are welcome, of course, but with the recent snapshots of eXist this really
is as easy as it can get -- no magic Cocoon vodoo, no knocking on
wood, no feng-shui and no you name it...

I wish the same could be said of roma, but for now I will just sit
back and remain silent until things calmed down.

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 computing-services.oxford.ac.uk  Tue May 10 08:31:44 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 10 May 2005 13:31:44 +0100
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: <17023.43250.121807.807560@emt.wwp.brown.edu>
References: 
	<427F22CF.1050305@oucs.ox.ac.uk>	
	<17023.43250.121807.807560@emt.wwp.brown.edu>
Message-ID: <4280A9B0.1040703@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>I am planning to take James' HOWTO and, pretending I've never done
>this before, build a P5 following the instructions. I plan to report
>both my findings on how good the instructions are, and the status of
>the buildability of P5 and status of stuff. 
>
I wouldn't do this for another 2 weeks, if I was you.
You'll just find bugs I have already fixed, probably....

-- 
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 computing-services.oxford.ac.uk  Tue May 10 08:40:33 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 10 May 2005 13:40:33 +0100
Subject: [tei-council] problems with online Roma
In-Reply-To: <200505092145.AJC07737@md2.mail.umd.edu>
References: <200505092145.AJC07737@md2.mail.umd.edu>
Message-ID: <4280ABC1.8050202@computing-services.oxford.ac.uk>

Susan Schreibman wrote:

>
>  
>
>>and press submit, I don't go to another form, nor do I get some type of 
>>success message - so I am not sure if after pressing submit I should be 
>>taken to another page, or I should choose an option myself from the tabs 
>>across the top.
>>    
>>
the latter. its a modal system, not a linear wizard

>>I decided to go to the Modules tab myself, and I got the following error 
>>message. This is the second time I've tried using the new interface, and I 
>>have come up against the same problem (at first I thought it might just be 
>>internet gremlins). Perhaps I am doing something wrong. 
>>
no, I think public roma remains broke.

>> I also could not seem to get help to work.
>>
>>    
>>
it probably does not do what you think. it simply makes help
text visible on each form

-- 
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 May 11 18:56:31 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 12 May 2005 07:56:31 +0900
Subject: [tei-council] P5, roma and bibl[Item|Struct] (Solved!!)
In-Reply-To:  (Christian Wittern's message of
	"Tue, 10 May 2005 20:31:45 +0900")
References: 
	<427F5222.4090600@computing-services.oxford.ac.uk>

Message-ID: 

Christian Wittern  writes:

> Sebastian Rahtz  writes:
>
>>>sh roma-new --teiserver=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/ --xsl=http://chw.zinbun.kyoto-u.ac.jp:8080/exist/servlet/db/TEI/stylesheet Test/testlite.odd

>> you have no idea now happy it makes me to see this.....
>>
>
> I wish the same could be said of roma, but for now I will just sit
> back and remain silent until things calmed down.

Or so I wrote, but I just could not keep my hands off -- and I finally
found that the problem was a missing &biblstru; in Source/CO/CO.odd.
With this in place I can now finally build my own, custom made,
shining schemas out of my ODDs.  Heureka!

On the way to this, I have learnt quite a lot about the various nuts
and bolts alleyways, unexpected views and hidden traps of Roma.  I now
think I now why the system bears this name...

What still puzzles me is that the declaration for biblStruct was
missing in all files, but it was only during the XSD build with trang
that this problem showed.  Roma would go ahead happily and build RNG
and DTD for me out of these faulty files and pretending they were fine
without a blinker.  This is what Julia and Sebastian alluded to
earlier, I think.  So maybe trang could in fact be used to detect at
least some of the more obvious bullets in ones own foot?!

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  Wed May 11 23:43:58 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 12 May 2005 12:43:58 +0900
Subject: [tei-council] roma testrive
Message-ID: 

Dear Council members, 

Now that I finally are in a position to testdrive roma, I came up with
something that looks like a bug, but might as well be a
misunderstanding:

In my odd, I have the following snippet:

which I put after all the other moduleRefs.

Invoking my shiny new roma, I get:
/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:2920: error: multiple definitions of "name" without "combine" attribute
/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:3926: error: multiple definitions of "note" without "combine" attribute
/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:7672: error: multiple definitions of "language" without "combine" attribute
/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:16468: error: multiple definitions of "#start" without "combine" attribute

All these look like things that exist both in tei and mods, but surely
they should be distinguished by their namespace?!

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  Wed May 11 23:43:58 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 12 May 2005 12:43:58 +0900
Subject: [tei-council] roma testrive
Message-ID: 

Dear Council members, 

Now that I finally are in a position to testdrive roma, I came up with
something that looks like a bug, but might as well be a
misunderstanding:

In my odd, I have the following snippet:

which I put after all the other moduleRefs.

Invoking my shiny new roma, I get:
/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:2920: error: multiple definitions of "name" without "combine" attribute
/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:3926: error: multiple definitions of "note" without "combine" attribute
/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:7672: error: multiple definitions of "language" without "combine" attribute
/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:16468: error: multiple definitions of "#start" without "combine" attribute

All these look like things that exist both in tei and mods, but surely
they should be distinguished by their namespace?!

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 computing-services.oxford.ac.uk  Wed May 11 07:33:45 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 11 May 2005 12:33:45 +0100
Subject: [tei-council] P5, roma and bibl[Item|Struct]
In-Reply-To: 
References: 	<427F5222.4090600@computing-services.oxford.ac.uk>

Message-ID: <4281ED99.8080504@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>
>I wish the same could be said of roma, but for now I will just sit
>back and remain silent until things calmed down.
>
>  
>
if you use a decent setup, then

 apt-get install tei-roma

will do the job.... (in due course)

-- 
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 computing-services.oxford.ac.uk  Wed May 11 21:33:54 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Thu, 12 May 2005 02:33:54 +0100
Subject: [tei-council] P5, roma and bibl[Item|Struct] (Solved!!)
In-Reply-To: 
References: 
	<427F5222.4090600@computing-services.oxford.ac.uk>

Message-ID: <4282B282.9050509@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>Or so I wrote, but I just could not keep my hands off -- and I finally
>found that the problem was a missing &biblstru; in Source/CO/CO.odd.
>  
>
that figures.

>On the way to this, I have learnt quite a lot about the various nuts
>and bolts alleyways, unexpected views and hidden traps of Roma.  I now
>think I now why the system bears this name...
>  
>
it is excellent to know that you are finding all this out, as
you'll now be able to write lots of documentation....

> Roma would go ahead happily and build RNG
>and DTD for me out of these faulty files and pretending they were fine
>without a blinker. 
>
you're hitting lazy evaluation. the reference is not checked until
runtime.

> This is what Julia and Sebastian alluded to
>earlier, I think.  So maybe trang could in fact be used to detect at
>least some of the more obvious bullets in ones own foot?!
>  
>
informally, yes. but there is a big difficulty in relating the error message
from trang back to the source ODD, which is what you really want. You
got enough information about biblStruct to know where to look, but
you are on the very high end of the scale of expertise by now, and most
people wouldn't have a clue.

The revised Roma that you are now running does do a lot more than
before to work around your attempts to shoot yourself.  If you
opt to delete , and there is a content model of

we used to make  a  to make this work, but
that meant the DTD ended up with ()*. So now I detect  is no
longer available, and zap the entire  clause. The code
which does this (template "simplifyRelax" in odd2odd.xsl) is not
foolproof, and may need  tweaking, but it covers the simpler cases.

-- 
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 May 12 10:12:57 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 12 May 2005 10:12:57 -0400
Subject: [tei-council] P5, roma and bibl[Item|Struct] (Solved!!)
In-Reply-To: <4282B282.9050509@computing-services.oxford.ac.uk>
References: 
	<427F5222.4090600@computing-services.oxford.ac.uk>

	<4282B282.9050509@computing-services.oxford.ac.uk>
Message-ID: <17027.25705.833205.662785@emt.wwp.brown.edu>

> >Or so I wrote, but I just could not keep my hands off -- and I
> >finally found that the problem was a missing &biblstru; in
> >Source/CO/CO.odd.
> >
> that figures.

Do you mean the &biblstru.odd; reference? It *is* in the current copy
in the CVS tree, right? I see it on line 3472.

I hope you're using and old version Christian; otherwise we have
problems. I just spent half an hour tracking through this stuff, and
as far as I can tell, it's there.

For those interested in some of the cool stuff we get from
Sourceforge (which partially makes up for these kinds of headaches),
check out
  http://cvs.sourceforge.net/viewcvs.py/tei/P5/Source/CO/co.odd?r1=1.4&r2=1.5

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu May 12 18:25:09 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 13 May 2005 07:25:09 +0900
Subject: [tei-council] P5, roma and bibl[Item|Struct] (Solved!!)
In-Reply-To: <17027.25705.833205.662785@emt.wwp.brown.edu> (Syd Bauman's
	message of "Thu, 12 May 2005 10:12:57 -0400")
References: 
	<427F5222.4090600@computing-services.oxford.ac.uk>

	<4282B282.9050509@computing-services.oxford.ac.uk>
	<17027.25705.833205.662785@emt.wwp.brown.edu>
Message-ID: 

Syd Bauman  writes:

>> >Or so I wrote, but I just could not keep my hands off -- and I
>> >finally found that the problem was a missing &biblstru; in
>> >Source/CO/CO.odd.
>> >
>> that figures.
>
> Do you mean the &biblstru.odd; reference? It *is* in the current copy
> in the CVS tree, right? I see it on line 3472.
>
> I hope you're using and old version Christian; otherwise we have
> problems. I just spent half an hour tracking through this stuff, and
> as far as I can tell, it's there.

No, I applied Sebastians "patch", (as I explained at the beginning of
this thread) that is, I just copied everything he sent over the CVS
checkout, which was one reason for all this mess.  

>
> For those interested in some of the cool stuff we get from
> Sourceforge (which partially makes up for these kinds of headaches),
> check out
>   http://cvs.sourceforge.net/viewcvs.py/tei/P5/Source/CO/co.odd?r1=1.4&r2=1.5

Yes, of course, but in this case it did not really help.  Sebastian, I
hope you are back to using CVS soon:-)

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 May 12 18:29:17 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 13 May 2005 07:29:17 +0900
Subject: [tei-council] P5, roma and bibl[Item|Struct] (Solved!!)
In-Reply-To: <4282B282.9050509@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Thu, 12 May 2005 02:33:54 +0100")
References: 
	<427F5222.4090600@computing-services.oxford.ac.uk>

	<4282B282.9050509@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

> it is excellent to know that you are finding all this out, as
> you'll now be able to write lots of documentation....

As you see, for the moment I am spending my time kicking the tires,
which seems to through a lot of dust.

> The revised Roma that you are now running does do a lot more than
> before to work around your attempts to shoot yourself.  If you
> opt to delete , and there is a content model of
>
>  
>
> we used to make  a  to make this work, but
> that meant the DTD ended up with ()*. 

Wouldn't it be easier to post-fix that in the DTD, if that gives you
overall a cleaner production line?

> So now I detect  is no
> longer available, and zap the entire  clause. The code
> which does this (template "simplifyRelax" in odd2odd.xsl) is not
> foolproof, and may need  tweaking, but it covers the simpler cases.

I have not yet been brave enough to delve into odd2odd in any
detail:-)

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 computing-services.oxford.ac.uk  Fri May 13 02:48:44 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 13 May 2005 07:48:44 +0100
Subject: [tei-council] roma testrive
In-Reply-To: 
References: 
Message-ID: <42844DCC.6040603@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>Dear Council members, 
>	       
>
>which I put after all the other moduleRefs.
>
>Invoking my shiny new roma, I get:
>/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:2920: error: multiple definitions of "name" without "combine" attribute
>/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:3926: error: multiple definitions of "note" without "combine" attribute
>/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:7672: error: multiple definitions of "language" without "combine" attribute
>/Users/chris/work/projects/hd-stones/RomaResults/stone.rng:16468: error: multiple definitions of "#start" without "combine" attribute
>
>All these look like things that exist both in tei and mods, but surely
>they should be distinguished by their namespace?!
>
>  
>
No, because these are the names of Relax patterns, which are
not namespaced. Only the _elements_ (and attributes) have a namespace.

This is an annoyance, which it is hard to work around without renaming the
patterns on one side of another.

The start thing is a pain.   do something like this:

In case I added support for this after I send you the files before, I'm
sending you privately fresh copies of the XSLT on my system.

-- 
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 computing-services.oxford.ac.uk  Sun May 15 21:46:27 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 16 May 2005 02:46:27 +0100
Subject: [tei-council] P5, roma and bibl[Item|Struct] (Solved!!)
In-Reply-To: 
References: 	<427F5222.4090600@computing-services.oxford.ac.uk>	
		<4282B282.9050509@computing-services.oxford.ac.uk>

Message-ID: <4287FB73.4090707@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>As you see, for the moment I am spending my time kicking the tires,
>which seems to through a lot of dust.
>  
>
shows they are well travelled

>
>>we used to make  a  to make this work, but
>>that meant the DTD ended up with ()*. 
>>    
>>
>
>Wouldn't it be easier to post-fix that in the DTD, if that gives you
>overall a cleaner production line?
>  
>
My current view is that this *is* the cleaner production line, doing
all the work at the odd2odd stage, so that resulting expanded ODD
is easy to translate to schema or DTD. We could imagine writing a direct
ODD to W3C schema, for instance.

Naturally, the whole ODD-processing production line can
be re-implemented in the future if anyone ever has a proper
computer scientist to assign to the job. If I was doing a risk
analysis of the TEI, I'd say that one of the problems of P5 is that
we are too dependent on  single tool chain, just as we were with P4.
It's one of the reason why I favour promoting "native" use of Relax NG,
as it gives an alternative technology. Of course, it still depends on the
base ODD to Relax conversion, but I am fairly confident that this is stable
and replicable.

-- 
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 May 16 14:50:29 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 16 May 2005 14:50:29 -0400
Subject: [tei-council] Photos
In-Reply-To: <4ee3e3dbf68b679785649291dfa79eb1@computing-services.oxford.ac.uk>
References: <42755432.7020109@computing-services.oxford.ac.uk>
	<4ee3e3dbf68b679785649291dfa79eb1@computing-services.oxford.ac.uk>
Message-ID: <17032.60277.660535.790063@emt.wwp.brown.edu>

> Not to be outdone....

Well, I've already been outdone by both James and Lou, but to
contribute my small bit ...

http://bauman.zapto.org/gallery/TEI_Council_Paris_2005

From Julia_Flanders at Brown.edu  Fri May 20 10:58:25 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Fri, 20 May 2005 10:58:25 -0400
Subject: [tei-council] Funding for Multilingual TEI
Message-ID: 

I've just had email from Harold Short, mentioning a funding 
opportunity which might be valuable for the TEI.

The ALLC has a "project support" scheme which provides funding of 
about 5000 pounds for relevant projects. Harold has indicated that 
the ALLC would be very interested in funding a proposal from the TEI 
to do some work on some aspect of "Multilingual TEI". He also says 
that the ALLC Committee has indicated a willingness to receive an 
application for double the normal funding limit (i.e. a total of 
10000 GBP).  He suggests that such a project might serve as a pilot 
for a larger-scale application to the EU.

I'm also posting this to the TEI Board, since they need to be 
involved in the larger strategic decisions. I've proposed that we 
might designate a small group with a representative from the Board 
and at least one from the Council, to take charge of putting together 
the proposal.

But the question of what would be the most important area to focus on 
is up to the Council to determine. Is there an appropriately sized 
chunk of work we could identify, that such a proposal could fund?

Best wishes, Julia

From Julia_Flanders at Brown.edu  Fri May 20 16:22:23 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Fri, 20 May 2005 16:22:23 -0400
Subject: [tei-council] more on internationalization
Message-ID: 

Syd and I were talking about this issue a little more, and it seemed 
to us that two valuable ways to increase the multilinguality of the 
TEI universe would be:

1. Provide the TEI tagset in several languages other than English
--complete the existing provision for tag names and attributes in 
German, French, and Spanish
--add to this list of languages, perhaps to include Italian, a 
Scandinavian language, an Eastern European language?

2. Provide the P5 how-to, ODD manual, and an Introduction to TEI 
document in several languages other than English

It would also be nice to translate the Guidelines themselves, but 
that would be beyond the scope of this initial funding. And I think 
covering more languages is in some ways more useful than covering 
more information--for one thing, diplomatically, it sends a stronger 
signal of inclusiveness, and doesn't ask us to decide which language 
is most important to start with.

I don't have a sense of how much work is involved in either task; 
ideally, we would use the funding to leverage some volunteer time. 
How much time did it take to translate the tagset into German or 
French or Spanish?

Best wishes, Julia

From Syd_Bauman at Brown.edu  Fri May 20 16:28:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 20 May 2005 16:28:11 -0400
Subject: [tei-council] more on internationalization
In-Reply-To: 
References: 
Message-ID: <17038.18523.9421.66382@emt.wwp.brown.edu>

> --complete the existing provision for tag names and attributes in
> German, French, and Spanish

My fault for leading you astray there, Julia. To my (limited)
knowledge, we only have markup names in German and Spanish, no French.
We have all 3 for the Roma (web) interface. I am not sure how
complete the lists of German and Spanish markup names are.

From edward.vanhoutte at kantl.be  Fri May 20 16:31:00 2005
From: edward.vanhoutte at kantl.be (Edward Vanhoutte)
Date: Fri, 20 May 2005 22:31:00 +0200
Subject: [tei-council] more on internationalization
In-Reply-To: 
References: 
Message-ID: <428E4904.2050702@kantl.be>

I think a third valuable way is the translation of the on-line workshops 
which could come out of project 'TEI by example. Creating a toolkit for 
teaching text encoding' which was submitted in february to the ALLC 
project support programme by Melissa Terras and myself and which was 
widely supported by many of you.

Edward

Julia Flanders wrote:

> Syd and I were talking about this issue a little more, and it seemed 
> to us that two valuable ways to increase the multilinguality of the 
> TEI universe would be:
>
> 1. Provide the TEI tagset in several languages other than English
> --complete the existing provision for tag names and attributes in 
> German, French, and Spanish
> --add to this list of languages, perhaps to include Italian, a 
> Scandinavian language, an Eastern European language?
>
> 2. Provide the P5 how-to, ODD manual, and an Introduction to TEI 
> document in several languages other than English
>
> It would also be nice to translate the Guidelines themselves, but that 
> would be beyond the scope of this initial funding. And I think 
> covering more languages is in some ways more useful than covering more 
> information--for one thing, diplomatically, it sends a stronger signal 
> of inclusiveness, and doesn't ask us to decide which language is most 
> important to start with.
>
> I don't have a sense of how much work is involved in either task; 
> ideally, we would use the funding to leverage some volunteer time. How 
> much time did it take to translate the tagset into German or French or 
> Spanish?
>
> Best wishes, Julia
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- 

================
Edward Vanhoutte
Coordinator
Centrum voor Teksteditie en Bronnenstudie - CTB (KANTL)
Centre for Scholarly Editing and Document Studies
Associate Editor, Literary and Linguistic Computing
Koninklijke Academie voor Nederlandse Taal- en Letterkunde
Royal Academy of Dutch Language and Literature
Koningstraat 18 / b-9000 Gent / Belgium
tel: +32 9 265 93 51 / fax: +32 9 265 93 49
edward dot vanhoutte at kantl dot be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm

From James.Cummings at computing-services.oxford.ac.uk  Fri May 20 17:44:46 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 20 May 2005 22:44:46 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
References: 
Message-ID: <428E5A4E.2020302@computing-services.oxford.ac.uk>

Julia Flanders wrote:
> 1. Provide the TEI tagset in several languages other than English
> --complete the existing provision for tag names and attributes in 
> German, French, and Spanish
> --add to this list of languages, perhaps to include Italian, a 
> Scandinavian language, an Eastern European language?

Could I point out a type of language that is under-represented here?
Although I don't know any oriental language, it strikes me that they
(perhaps Japanese) would be quite interesting to have the TEI tagset
in such a language.  This would also encourage take-up of TEI in
oriental text-encoding projects.  Of course, I'm suggesting this
with only a sliver of a guess about the possible problems in taxonomy, 
etc.  But if this really is the brave new world of Unicode, then it 
seems to me that something very non-western in its character set should 
be included.

I'm not necessarily suggesting this as a proposed output for any 
particular funding bid, but something we should keep in mind.

-James

From Syd_Bauman at Brown.edu  Fri May 20 20:01:31 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 20 May 2005 20:01:31 -0400
Subject: [tei-council] more on internationalization
In-Reply-To: <428E5A4E.2020302@computing-services.oxford.ac.uk>
References: 
	<428E5A4E.2020302@computing-services.oxford.ac.uk>
Message-ID: <17038.31323.343827.318387@emt.wwp.brown.edu>

> Could I point out a type of language that is under-represented here?
> Although I don't know any oriental language, ...

Absolutely! In the conversation Julia refers to we had spoken about
oriental and other languages briefly, but were not sure the EU (or
ALLC) was interested in funding these.

Doesn't mean they're not important, though. I don't know what funding
agencies there are in, say, Japan, Taiwan, India, Egypt, etc., but it
might be interesting to think about simultaneously hitting several,
in a sense saying "look, these folks are getting it translated to
*their* language, what about you"? Just a thought.

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat May 21 05:35:45 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 21 May 2005 10:35:45 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: <17038.18523.9421.66382@emt.wwp.brown.edu>
References: 
	<17038.18523.9421.66382@emt.wwp.brown.edu>
Message-ID: <428F00F1.5060507@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>>--complete the existing provision for tag names and attributes in
>>German, French, and Spanish
>>    
>>
>
>My fault for leading you astray there, Julia. To my (limited)
>knowledge, we only have markup names in German and Spanish, no French.
>We have all 3 for the Roma (web) interface. I am not sure how
>complete the lists of German and Spanish markup names are.
>  
>
Some names are in French, but a lot remains to be done

of 487 elements in the database, 484 are in German and Spanish,
127 in Catalan and 125 in French.

-- 
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 computing-services.oxford.ac.uk  Sat May 21 05:38:31 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 21 May 2005 10:38:31 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
References: 
Message-ID: <428F0197.60802@computing-services.oxford.ac.uk>

Julia Flanders wrote:

>
> 1. Provide the TEI tagset in several languages other than English
> --complete the existing provision for tag names and attributes in 
> German, French, and Spanish

It would also help a lot, of course, to translate the  or  
for each element and attribute.
Without that, its not clear whether anyone will use the translated names.

> I don't have a sense of how much work is involved in either task; 
> ideally, we would use the funding to leverage some volunteer time. How 
> much time did it take to translate the tagset into German or French or 
> Spanish?

The German took about 2 man weeks, I think. But that was problematic, 
because Arno was
not very familiar with the territory, and Christian thinks some of his 
words are not right.
So each translation needs a reviewer.

-- 
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 May 22 05:34:16 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 22 May 2005 18:34:16 +0900
Subject: [tei-council] more on internationalization
In-Reply-To: <428F0197.60802@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Sat, 21 May 2005 10:38:31 +0100")
References: 
	<428F0197.60802@computing-services.oxford.ac.uk>
Message-ID: 

Julia,

I think this is an excellent opportunity.

Sebastian Rahtz  writes:

> Julia Flanders wrote:
>
>>
>> 1. Provide the TEI tagset in several languages other than English
>> --complete the existing provision for tag names and attributes in
>> German, French, and Spanish
>
> It would also help a lot, of course, to translate the  or
>  for each element and attribute.
> Without that, its not clear whether anyone will use the translated
> names.

I second this.  Even translated tag-names might be difficult to
understand due to the necessary terseness.  Translated tag-names also
open the door to all kinds of misunderstandings when talking about the
tags; but I do see the neccessity.  
 and  on the other hand are slightly more verbose and
with things like oxygen, they can even be displayed directly to the
encoder while doing the work.  BTW, I have been wondering if the
current ODDs do allow for multiple, multilingual  and 
elements?  

I know of a group in Taiwan that might be interested to chime in with
Chinese, and even for Japanese I could try to do something, if this
sounds interesting.  Getting funding for this over here, is probably a
different story

> The German took about 2 man weeks, I think. But that was problematic,
> because Arno was
> not very familiar with the territory, and Christian thinks some of his
> words are not right.
> So each translation needs a reviewer.

Ideally the translator should be familiar with the TEI Guidelines and
text encoding.  And yes, the budget should allow for a review process.

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 computing-services.oxford.ac.uk  Sun May 22 10:16:07 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 22 May 2005 15:16:07 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
References: 	<428F0197.60802@computing-services.oxford.ac.uk>

Message-ID: <42909427.8020800@computing-services.oxford.ac.uk>

Christian Wittern wrote:

> and  on the other hand are slightly more verbose and
>with things like oxygen, they can even be displayed directly to the
>encoder while doing the work.  BTW, I have been wondering if the
>current ODDs do allow for multiple, multilingual  and 
>elements?  
>  
>
hmm. that needs some thought.

-- 
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 computing-services.oxford.ac.uk  Sun May 22 10:19:45 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 22 May 2005 15:19:45 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
References: 	<428F0197.60802@computing-services.oxford.ac.uk>

Message-ID: <42909501.6060604@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>
>  
> and  on the other hand are slightly more verbose and
>with things like oxygen, they can even be displayed directly to the
>encoder while doing the work.  BTW, I have been wondering if the
>current ODDs do allow for mult
>
this is important, by the way, as it gives an immediate visibly
useful demo of the work. In fact, keeping tag names in English
but translaating the  is arguably the most useful thing to do.

-- 
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  Sun May 22 11:27:46 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 22 May 2005 16:27:46 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
References: 
	<428F0197.60802@computing-services.oxford.ac.uk>

Message-ID: 

On 22 May 2005, at 10:34, Christian Wittern wrote:
>>
>> It would also help a lot, of course, to translate the  or
>>  for each element and attribute.
>> Without that, its not clear whether anyone will use the translated
>> names.
>
> I second this.  Even translated tag-names might be difficult to
> understand due to the necessary terseness.  Translated tag-names also
> open the door to all kinds of misunderstandings when talking about the
> tags; but I do see the neccessity.
>  and  on the other hand are slightly more verbose and
> with things like oxygen, they can even be displayed directly to the
> encoder while doing the work.  BTW, I have been wondering if the
> current ODDs do allow for multiple, multilingual  and 
> elements?

They should do.

I also think it is *much* more useful  to translate e.g. the desc and 
gloss elements than it is to simply translate the tagnames.  Now that 
we have gone to the effort of making it possible for systems to take 
full advantage of the doc umentation within an ODD, providing it in 
languages other than English is definitely the way to go.

 From the Macmini at Burnard Towers

From Syd_Bauman at Brown.edu  Sun May 22 16:05:18 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 22 May 2005 16:05:18 -0400
Subject: [tei-council] more on internationalization
In-Reply-To: 
References: 
	<428F0197.60802@computing-services.oxford.ac.uk>

Message-ID: <17040.58878.18583.934942@emt.wwp.brown.edu>

> I also think it is *much* more useful to translate e.g. the desc
> and gloss elements than it is to simply translate the tagnames.

While I'm not as confident as Lou seems to be, I think this is
probably the better way to go, too. There are lots of tag and
attribute names that are not initially obvious even to a native
English speaker. Changing them to something that's not initially
obvious in the reader's native language would help less than
providing a brief prose explanation in the reader's native language. 

I haven't thought through how this fits into the funding question,
but it is important.

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon May 23 10:05:34 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 23 May 2005 15:05:34 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: <17040.58878.18583.934942@emt.wwp.brown.edu>
References: 	<428F0197.60802@computing-services.oxford.ac.uk>		
	<17040.58878.18583.934942@emt.wwp.brown.edu>
Message-ID: <4291E32E.4030706@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>
>I haven't thought through how this fits into the funding question,
>but it is important.
>
>  
>
I think it potentially makes the job easier, to translate a sentence of 
text rather
than agonzing over with  should be in Chinese or Berber.  Almost
anyone can do the former, but the latter requires someone used to tagging,
I think.

the file teinames.xml in the Sourceforge I18N area
has the infrastructure ready for this to work, with some
Spanish translattions by Alejandro.

-- 
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 Julia_Flanders at Brown.edu  Mon May 23 10:09:57 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Mon, 23 May 2005 10:09:57 -0400
Subject: [tei-council] more on internationalization
In-Reply-To: <17040.58878.18583.934942@emt.wwp.brown.edu>
References: 
	<428F0197.60802@computing-services.oxford.ac.uk>

	<17040.58878.18583.934942@emt.wwp.brown.edu>
Message-ID: 

This sounds good to me as well.

So, for how many languages could we translate  and  (and 
perhaps tag names as well, or perhaps not) for $20,000? If 
translating the tag names alone, imperfectly, took two weeks, would 
one month per language for the initial translation, plus something 
for the review, be enough?

And how much would that month reasonably cost us?

To identify the translators, would it be worth our posting a call on 
TEI-L, announcing the proposal and indicating that we're seeking 
translators who would be willing to contribute some time (i.e. they'd 
get paid, but probably not fully for what their time is worth)? and 
also reviewers? Or would we prefer to identify translators ourselves?

Best, Julia

At 4:05 PM -0400 5/22/05, Syd Bauman wrote:
>>  I also think it is *much* more useful to translate e.g. the desc
>>  and gloss elements than it is to simply translate the tagnames.
>
>While I'm not as confident as Lou seems to be, I think this is
>probably the better way to go, too. There are lots of tag and
>attribute names that are not initially obvious even to a native
>English speaker. Changing them to something that's not initially
>obvious in the reader's native language would help less than
>providing a brief prose explanation in the reader's native language.
>
>I haven't thought through how this fits into the funding question,
>but it is important.
>
>_______________________________________________
>tei-council mailing list
>tei-council at lists.village.Virginia.EDU
>http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon May 23 10:13:28 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 23 May 2005 15:13:28 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
References: 	<428F0197.60802@computing-services.oxford.ac.uk>			<17040.58878.18583.934942@emt.wwp.brown.edu>

Message-ID: <4291E508.30601@computing-services.oxford.ac.uk>

Julia Flanders wrote:

>
> So, for how many languages could we translate  and  (and 
> perhaps tag names as well, or perhaps not) for $20,000? If translating 
> the tag names alone, imperfectly, took two weeks,

dont trust that report of mine. I'd have to ask Arno

> would one month per language for the initial translation, plus 
> something for the review, be enough?
>
I think thats too much.  I think a competent person would translate the 
necessary 1000 or so sentences in
a week.  say that cost $1000, we could do 20 languages.  be more 
pessimistic and double that,
and we still could commission 10 translations.

> And how much would that month reasonably cost us?
>
> To identify the translators, would it be worth our posting a call on 
> TEI-L, announcing the proposal and indicating that we're seeking 
> translators who would be willing to contribute some time (i.e. they'd 
> get paid, but probably not fully for what their time is worth)? and 
> also reviewers? Or would we prefer to identify translators ourselves?

I think its worth asking on TEI-L. Other people may have experience
of commissioning translation, or be able to offer to do it themselves.

of course, we cant do nowt until the editors confirm the  and 
 texts are
stable....

-- 
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 mjd at hum.ku.dk  Mon May 23 10:27:08 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Mon, 23 May 2005 16:27:08 +0200
Subject: [tei-council] more on internationalization
In-Reply-To: 
References: <17040.58878.18583.934942@emt.wwp.brown.edu>
Message-ID: <4292045C.16098.17CF072@localhost>

Just wanted to say that I think this is all a very good 
idea and will gladly contribute; I could, for example, 
arrange for translations into Danish (or some other 
Scandinavian language) and, say, Bulgarian (or Czech).

MJD

> This sounds good to me as well.
> 
> So, for how many languages could we translate  and
>  (and perhaps tag names as well, or perhaps not) for
> $20,000? If translating the tag names alone, imperfectly,
> took two weeks, would one month per language for the initial
> translation, plus something for the review, be enough?
> 
> And how much would that month reasonably cost us?
> 
> To identify the translators, would it be worth our posting a
> call on TEI-L, announcing the proposal and indicating that
> we're seeking translators who would be willing to contribute
> some time (i.e. they'd get paid, but probably not fully for
> what their time is worth)? and also reviewers? Or would we
> prefer to identify translators ourselves?
> 
> Best, Julia
> 
> At 4:05 PM -0400 5/22/05, Syd Bauman wrote:
> >>  I also think it is *much* more useful to translate e.g.
> >>  the desc and gloss elements than it is to simply
> >>  translate the tagnames.
> >
> >While I'm not as confident as Lou seems to be, I think this
> >is probably the better way to go, too. There are lots of
> >tag and attribute names that are not initially obvious even
> >to a native English speaker. Changing them to something
> >that's not initially obvious in the reader's native
> >language would help less than providing a brief prose
> >explanation in the reader's native language.
> >
> >I haven't thought through how this fits into the funding
> >question, but it is important.
> >
> >_______________________________________________
> >tei-council mailing list
> >tei-council at lists.village.Virginia.EDU
> >http://lists.village.Virginia.EDU/mailman/listinfo/tei-coun
> >cil
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-counc
> il

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon May 23 18:46:13 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 24 May 2005 07:46:13 +0900
Subject: [tei-council] more on internationalization
In-Reply-To: <4291E32E.4030706@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Mon, 23 May 2005 15:05:34 +0100")
References: 
	<428F0197.60802@computing-services.oxford.ac.uk>

	<17040.58878.18583.934942@emt.wwp.brown.edu>
	<4291E32E.4030706@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

> I think it potentially makes the job easier, to translate a sentence
> of text rather
> than agonzing over with  should be in Chinese or Berber.  Almost
> anyone can do the former, but the latter requires someone used to tagging,
> I think.
-- I had the same example in mind ;-)
>
> the file teinames.xml in the Sourceforge I18N area
> has the infrastructure ready for this to work, with some
> Spanish translattions by Alejandro.

To me the file under sf/P5 looks much more complete.  however, I do
not see es there, only s. Are they (in current TEI
editorial praxis) mutually exclusive, or what is there relationship?

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 May 23 18:48:40 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 24 May 2005 07:48:40 +0900
Subject: [tei-council] more on internationalization
In-Reply-To:  (Julia Flanders's
	message of "Mon, 23 May 2005 10:09:57 -0400")
References: 
	<428F0197.60802@computing-services.oxford.ac.uk>

	<17040.58878.18583.934942@emt.wwp.brown.edu>

Message-ID: 

Julia Flanders  writes:

> To identify the translators, would it be worth our posting a call on
> TEI-L, announcing the proposal and indicating that we're seeking
> translators who would be willing to contribute some time (i.e. they'd
> get paid, but probably not fully for what their time is worth)? and
> also reviewers? Or would we prefer to identify translators
> ourselves?

I think one way to proceed would to form a subcommitee (not necessary
only from the Council) for handling this and leave the details on how
to proceed to them.  However, we should define our requirements before,
e.g. what languages we want to cover etc. 

Christian

-- 
 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon May 23 19:08:46 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 24 May 2005 00:08:46 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
References: 	<428F0197.60802@computing-services.oxford.ac.uk>			<17040.58878.18583.934942@emt.wwp.brown.edu>	<4291E32E.4030706@computing-services.oxford.ac.uk>

Message-ID: <4292627E.5070600@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>
>>the file teinames.xml in the Sourceforge I18N area
>>has the infrastructure ready for this to work, with some
>>Spanish translattions by Alejandro.
>>    
>>
>
>To me the file under sf/P5 looks much more complete.  
>
no, they are the same. just some formatting differences. I will
delete the one under P5

>however, I do
>not see es there, only s. Are they (in current TEI
>editorial praxis) mutually exclusive, or what is there relationship?
>  
>
a good question. no, they are not mutually exclusive,
and I think Lou and Laurent would claim to know the difference,
but I am not convinced that they are used consistently.  
is used for attributes in the way  is used for elements,
so far as I can see.

-- 
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 computing-services.oxford.ac.uk  Mon May 23 19:21:12 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 24 May 2005 00:21:12 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: 
References: 	<428F0197.60802@computing-services.oxford.ac.uk>			<17040.58878.18583.934942@emt.wwp.brown.edu>	

Message-ID: <42926568.2020904@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>I think one way to proceed would to form a subcommitee (not necessary
>only from the Council) for handling this and leave the details on how
>to proceed to them.  However, we should define our requirements before,
>e.g. what languages we want to cover etc. 
>
>  
>
since Alejandro did so much work already, I think it would be well
worth finishing Spanish.  I also think French should be done, for 
historical reasons.
After that, how to decide on priorities?

 * How many Danes doing text encoding cannot read English?
 * how many Bulgarians do text encoding?
 * can we ever get the encoding right for Chinese?
 * what's the best language for India?

I think we may have to be driven by who comes forward.

what's the timescale on this application, Julia?

My main worry about starting this exercise is that it provides a distraction
from P5, and is impacted by it. Since the elements and attributes for P5
are not frozen yet, is it sensible to start translating? yes, 99% of it 
will be unchanged,
but there is a management problem if we are trying to merge material into
a moving target.

Note the discussions around Ghent-time about where to store this stuff.
Back then we were thinking that the translations should be external
(as in current teinames.xml), mainly because attributes are repeated so 
much.
However, then we talked about names, and I think we mostly agreed that 
"type"
always means the same thing; but is its / the same in each 
case?
how much do we normalize the description of attributes; and if we don't, how
do we avoid translating the same text hundreds of times?

-- 
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  Mon May 23 23:25:19 2005
From: Laurent.Romary at loria.fr (Laurent.Romary at loria.fr)
Date: Tue, 24 May 2005 05:25:19 +0200
Subject: [tei-council] more on internationalization
In-Reply-To: <42926568.2020904@computing-services.oxford.ac.uk>
References: 
	<428F0197.60802@computing-services.oxford.ac.uk>

	<17040.58878.18583.934942@emt.wwp.brown.edu>

	<42926568.2020904@computing-services.oxford.ac.uk>
Message-ID: <1116905119.42929e9f22530@www.loria.fr>

Selon Sebastian Rahtz :

> since Alejandro did so much work already, I think it would be well
> worth finishing Spanish.  I also think French should be done, for
> historical reasons.
As a matter of fact, there is already a group of French colleagues who have been
working on some kind of translation activities for a few month. We have recently
made them move to consider the translation of P5 element descriptions and/or to
prepare introductory material in French. We also asked for them to consider
compiling examples that would feed  with more French looking data.
Lou should meet them when he goes to Lyon at the end of this month.

> My main worry about starting this exercise is that it provides a distraction
> from P5, and is impacted by it. Since the elements and attributes for P5
> are not frozen yet, is it sensible to start translating? yes, 99% of it
> will be unchanged,
> but there is a management problem if we are trying to merge material into
> a moving target.

I agree with this, this is why the first emergency is to have a document
planning those translation activities (list of "stable chapters", priorities,
etc.).

Laurent

From Laurent.Romary at loria.fr  Tue May 24 02:45:24 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Tue, 24 May 2005 08:45:24 +0200
Subject: [tei-council] more on internationalization
In-Reply-To: <4292627E.5070600@computing-services.oxford.ac.uk>
References: 	<428F0197.60802@computing-services.oxford.ac.uk>			<17040.58878.18583.934942@emt.wwp.brown.edu>	<4291E32E.4030706@computing-services.oxford.ac.uk>

	<4292627E.5070600@computing-services.oxford.ac.uk>
Message-ID: <84f94aa8aa7f60c40fcd27b82be8072f@loria.fr>

It is probably a good time to state their meaning more precisely. 
Basically (and under Lou's control):
-  makes explicit the name that is encoded in the tag name 
(respStmt -> responsability statement); in a sense it provides a term 
(a noun phrase that can be used to designate the corresponding concept)
-  is the definitional field for the element. It is where a TEI 
user should find the reference information for it.
Best,
Laurent

Le 24 mai 05, ? 01:08, Sebastian Rahtz a ?crit :

>> however, I do
>> not see es there, only s. Are they (in current TEI
>> editorial praxis) mutually exclusive, or what is there relationship?
>>
> a good question. no, they are not mutually exclusive,
> and I think Lou and Laurent would claim to know the difference,
> but I am not convinced that they are used consistently.  
> is used for attributes in the way  is used for elements,
> so far as I can see.

From mjd at hum.ku.dk  Tue May 24 03:25:25 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Tue, 24 May 2005 09:25:25 +0200
Subject: [tei-council] more on internationalization
In-Reply-To: <42926568.2020904@computing-services.oxford.ac.uk>
References: 
Message-ID: <4292F305.12687.49B458@localhost>

> After that, how to decide on priorities?
> 
>  * How many Danes doing text encoding cannot read English? 

Probably not many, but then there aren't that many Danes 
doing text encoding. The point, though, is that just 
because people _can_ use something in a foreign language 
doesn't mean they wouldn't prefer to have it in their own, 
and the question we should rather be asking is how many 
Danes (Swedes, Germans, whatever) would be doing text 
encoding if the schemes and tools were available to them in 
their own languages. Even Microsoft's worked that one out.

*
>  how many Bulgarians do text encoding?

Any number of them, as you'll discover in October. But here 
the everybody-speaks-English-don't-they?-attitude is even 
less appropriate, since in Bulgaria, as in most of the 
world, everybody doesn't speak English (thank God), and 
shouldn't have to. Which I thought was the whole point of 
this exercise.

MJD

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue May 24 04:09:33 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 24 May 2005 09:09:33 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: <84f94aa8aa7f60c40fcd27b82be8072f@loria.fr>
References: 	<428F0197.60802@computing-services.oxford.ac.uk>			<17040.58878.18583.934942@emt.wwp.brown.edu>	<4291E32E.4030706@computing-services.oxford.ac.uk>		<4292627E.5070600@computing-services.oxford.ac.uk>
	<84f94aa8aa7f60c40fcd27b82be8072f@loria.fr>
Message-ID: <4292E13D.1070805@computing-services.oxford.ac.uk>

Laurent Romary wrote:

> It is probably a good time to state their meaning more precisely. 
> Basically (and under Lou's control):
> -  makes explicit the name that is encoded in the tag name 
> (respStmt -> responsability statement); in a sense it provides a term 
> (a noun phrase that can be used to designate the corresponding concept)
> -  is the definitional field for the element. It is where a TEI 
> user should find the reference information for it.
>

so  should have been used relatively rarely? it seems to have 
been (ab)used to describe  entries, eg

        indicates what kind of section is changing at this 
milestone.

          page breaks in the reference edition.

this should have been , right?

It won't be hard to do an analysis of  all this, but I think it
may mean some global changes.

-- 
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 computing-services.oxford.ac.uk  Tue May 24 04:47:59 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 24 May 2005 09:47:59 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: <4292F305.12687.49B458@localhost>
References: 
	<4292F305.12687.49B458@localhost>
Message-ID: <4292EA3F.5060206@computing-services.oxford.ac.uk>

M. J. Driscoll wrote:

> But here 
>the everybody-speaks-English-don't-they?-attitude is even 
>less appropriate, since in Bulgaria, as in most of the 
>world, everybody doesn't speak English (thank God), and 
>shouldn't have to. Which I thought was the whole point of 
>this exercise.
>

indeed. so what is the algorithm for priorititizing languages? we can choose
between:

 1 easy to do (ie we know someone who can control the work, like Laurent 
for French or Alejandro for Spanish)
 2 number of native speakers (in which case Bahasa might be on the list)
 3 number of known interests in text encoding (er, thats hard.)
 4 perception of "importance" of language (er, thats hard too)
 5 sticking pins in a world map

to my mind, no 1 is the practical choice. no sense in picking, say, 
Korean and then
not being able to locate a good person.

if we ask the ALLC for money to try and do (say) 6 languages,
then we can ask the members first and then  TEI-L second
for bids.

-- 
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 May 24 05:12:18 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Tue, 24 May 2005 11:12:18 +0200
Subject: [tei-council] more on internationalization
In-Reply-To: <4292E13D.1070805@computing-services.oxford.ac.uk>
References: 	<428F0197.60802@computing-services.oxford.ac.uk>			<17040.58878.18583.934942@emt.wwp.brown.edu>	<4291E32E.4030706@computing-services.oxford.ac.uk>		<4292627E.5070600@computing-services.oxford.ac.uk>
	<84f94aa8aa7f60c40fcd27b82be8072f@loria.fr>
	<4292E13D.1070805@computing-services.oxford.ac.uk>
Message-ID: <818bac0274670fbfa40f08a7e013840f@loria.fr>

You got it right, Sebastian. At least we should try to use the two 
elements as consistantly as possible in future element description and 
correct mismatches progressively as we see them (that could be part of 
the chapter reviewing check list).
Laurent

Le 24 mai 05, ? 10:09, Sebastian Rahtz a ?crit :

> Laurent Romary wrote:
>
>> It is probably a good time to state their meaning more precisely. 
>> Basically (and under Lou's control):
>> -  makes explicit the name that is encoded in the tag name 
>> (respStmt -> responsability statement); in a sense it provides a term 
>> (a noun phrase that can be used to designate the corresponding 
>> concept)
>> -  is the definitional field for the element. It is where a TEI 
>> user should find the reference information for it.
>>
>
> so  should have been used relatively rarely? it seems to have 
> been (ab)used to describe  entries, eg
>
>    
>        
>        indicates what kind of section is changing at this 
> milestone.
>
>
>       xmlns:rng="http://relaxng.org/ns/structure/1.0"/>
>      
>        
>
>          
>          page breaks in the reference edition.
>        
>        
>
>
> this should have been , right?
>
> It won't be hard to do an analysis of  all this, but I think it
> may mean some global changes.
>
> -- 
> 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 computing-services.oxford.ac.uk  Tue May 24 05:14:19 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 24 May 2005 10:14:19 +0100
Subject: [tei-council] more on internationalization
In-Reply-To: <818bac0274670fbfa40f08a7e013840f@loria.fr>
References: 	<428F0197.60802@computing-services.oxford.ac.uk>			<17040.58878.18583.934942@emt.wwp.brown.edu>	<4291E32E.4030706@computing-services.oxford.ac.uk>		<4292627E.5070600@computing-services.oxford.ac.uk>
	<84f94aa8aa7f60c40fcd27b82be8072f@loria.fr>
	<4292E13D.1070805@computing-services.oxford.ac.uk>
	<818bac0274670fbfa40f08a7e013840f@loria.fr>
Message-ID: <4292F06B.4060301@computing-services.oxford.ac.uk>

Laurent Romary wrote:

> You got it right, Sebastian. At least we should try to use the two 
> elements as consistantly as possible in future element description and 
> correct mismatches progressively as we see them (that could be part of 
> the chapter reviewing check list).
>
are chapter reviewers reading XML source, or formatted results?

-- 
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 May 24 05:22:09 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Tue, 24 May 2005 11:22:09 +0200
Subject: [tei-council] more on internationalization
In-Reply-To: <4292F06B.4060301@computing-services.oxford.ac.uk>
References: 	<428F0197.60802@computing-services.oxford.ac.uk>			<17040.58878.18583.934942@emt.wwp.brown.edu>	<4291E32E.4030706@computing-services.oxford.ac.uk>		<4292627E.5070600@computing-services.oxford.ac.uk>
	<84f94aa8aa7f60c40fcd27b82be8072f@loria.fr>
	<4292E13D.1070805@computing-services.oxford.ac.uk>
	<818bac0274670fbfa40f08a7e013840f@loria.fr>
	<4292F06B.4060301@computing-services.oxford.ac.uk>
Message-ID: 

Le 24 mai 05, ? 11:14, Sebastian Rahtz a ?crit :

> Laurent Romary wrote:
>
>> You got it right, Sebastian. At least we should try to use the two 
>> elements as consistantly as possible in future element description 
>> and correct mismatches progressively as we see them (that could be 
>> part of the chapter reviewing check list).
>>
> are chapter reviewers reading XML source, or formatted results?
>

My experience with the print dictionary chapter shows that you have no 
choice: you need to go through the various files to understand 
precisely what action is to be taken for each element or class.

From Julia_Flanders at Brown.edu  Tue May 24 09:44:41 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Tue, 24 May 2005 09:44:41 -0400
Subject: [tei-council] more on internationalization
In-Reply-To: <4292EA3F.5060206@computing-services.oxford.ac.uk>
References: 
	<4292F305.12687.49B458@localhost>
	<4292EA3F.5060206@computing-services.oxford.ac.uk>
Message-ID: 

I would suggest that we make a longer list of languages in which we 
know text encoding work is being done (as determined, for instance, 
by the range of countries in which we have members), and use this as 
a master list to track our progress. That list could be cast into 
rough groups:
--highest priority: languages where there is a great deal of TEI work 
being done;
--middle priority: languages where there is some TEI work being done;
--low priority: languages where there is little or no TEI work being 
done but where we believe there is potential;
--not on the list: languages where we believe having a translation 
would not have any appreciable influence at the moment (e.g. Tlingit)

Then submit a call and see what proposals we receive. We could fund 
all the proposals in our high-priority group, and keep the others for 
a more substantial EU proposal, or a proposal to another funding 
body. Creating a master plan in this way would help us make a 
persuasive funding proposal and also provide a sense of long-term 
goals and progress.

It may be in any case that the ALLC wishes to give priority in any 
case to European languages (I can check on this with Harold). I'll 
also check on the timeline to see whether this proposal can wait 
until P5 issues have been firmed up.

best, Julia

At 9:47 AM +0100 5/24/05, Sebastian Rahtz wrote:
>M. J. Driscoll wrote:
>
>>  But here the everybody-speaks-English-don't-they?-attitude is even 
>>less appropriate, since in Bulgaria, as in most of the world, 
>>everybody doesn't speak English (thank God), and shouldn't have to. 
>>Which I thought was the whole point of this exercise.
>>
>
>indeed. so what is the algorithm for priorititizing languages? we can choose
>between:
>
>1 easy to do (ie we know someone who can control the work, like 
>Laurent for French or Alejandro for Spanish)
>2 number of native speakers (in which case Bahasa might be on the list)
>3 number of known interests in text encoding (er, thats hard.)
>4 perception of "importance" of language (er, thats hard too)
>5 sticking pins in a world map
>
>to my mind, no 1 is the practical choice. no sense in picking, say, 
>Korean and then
>not being able to locate a good person.
>
>if we ask the ALLC for money to try and do (say) 6 languages,
>then we can ask the members first and then  TEI-L second
>for bids.
>
>--
>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 wittern at kanji.zinbun.kyoto-u.ac.jp  Tue May 24 20:45:08 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 25 May 2005 09:45:08 +0900
Subject: [tei-council] more on internationalization
In-Reply-To:  (Julia Flanders's
	message of "Tue, 24 May 2005 09:44:41 -0400")
References: 
	<4292F305.12687.49B458@localhost>
	<4292EA3F.5060206@computing-services.oxford.ac.uk>

Message-ID: 

Julia Flanders  writes:

> I would suggest that we make a longer list of languages in which we
> know text encoding work is being done (as determined, for instance, by
> the range of countries in which we have members), and use this as a
> master list to track our progress. That list could be cast into rough
> groups:
> --highest priority: languages where there is a great deal of TEI work
>   being done;
> --middle priority: languages where there is some TEI work being done;
> --low priority: languages where there is little or no TEI work being
>   done but where we believe there is potential;
> --not on the list: languages where we believe having a translation
>   would not have any appreciable influence at the moment
>   (e.g. Tlingit)

This sounds like a good strategy, except that I think it would benefit
from trying to be a bit more foreword looking by not only assess the
current membership, but also areas where the TEI sees a potential (or
a need) to develop more.  

I can tell you from years of experience that TEI is a hard sell in
China, Taiwan and Japan -- for many reasons, but prominent among them
the perceived un-accessibility due to text and examples coming from
western languages and perceived "centeredness in a western mind-set".
So while you will probably find Chinese and Japanese at the very
bottom of the list in terms of members from countries using these
languages, it would benefit the long-term strategy of the TEI to
consider these languages for the proposal, in the case the ALLC would
consider supporting them.  One could of course always say if they are
interested, they should be looking for their own funding
opportunities, but since they are not interested...  

Another possibility would be to offer a matching-funds scheme to
extend the reach we can have with this initial grant?

>
> Then submit a call and see what proposals we receive. We could fund
> all the proposals in our high-priority group, and keep the others for
> a more substantial EU proposal, or a proposal to another funding
> body. Creating a master plan in this way would help us make a
> persuasive funding proposal and also provide a sense of long-term
> goals and progress.

If we think of approaching the EU, languages that could not possibly
supported by the EU could be given a higher priority for the ALLC
proposal. 
>
> It may be in any case that the ALLC wishes to give priority in any
> case to European languages (I can check on this with Harold). I'll
> also check on the timeline to see whether this proposal can wait until
> P5 issues have been firmed up.

I think it is quite timely for this issue to come up now, so that we
can make sure P5 supports this kind of internationalization
technically and conceptually.  Hopefully the appearance of some
translations and their apparent usefulness will then spur others to
come.  

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  Wed May 25 22:13:15 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 26 May 2005 11:13:15 +0900
Subject: [tei-council] TEI and ISO 639-6
Message-ID: 

Dear Council members,

A friend send me an email, which contained the following sentence,
attributed to  Debbie Garside of linguaphone ICT:

"Links to the TEI have already been established and the model that is
currently being created  for ISO 639-6 will take on board the needs of
these industries."

He asked me for further clarification and I have to admit here that I
do remember faintly that this came up once (although the link to
ethnologue does seem stronger), but I do not remember that we did
establish some formal relationship -- Can somebody help me here?

(I am a bit embarrassed with this and have thought for a while that we
need a better way to keep track of these issues -- a search interface
to the minutes and WG documents would probably be a great improvement)

ALl the best,

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  Thu May 26 00:00:28 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 26 May 2005 00:00:28 -0400
Subject: [tei-council] TEI and ISO 639-6
In-Reply-To: 
References: 
Message-ID: <17045.18908.159191.211732@emt.wwp.brown.edu>

I have no recollection of this at all. A search, however, reveals
that Lou posted "[Fwd: Re: Language codes]" to tei-chars on
2004-06-16 13:15+0100, to which there was only 1 reply by Martin
Duerst approx 22 hours later. This posting discusses a draft of
ISO 639-6.

From Laurent.Romary at loria.fr  Thu May 26 02:43:01 2005
From: Laurent.Romary at loria.fr (Laurent.Romary at loria.fr)
Date: Thu, 26 May 2005 08:43:01 +0200
Subject: [tei-council] TEI and ISO 639-6
In-Reply-To: 
References: 
Message-ID: <1117089781.42956ff576438@www.loria.fr>

I do hope it is not related to the fact that we have regular exchanges in the
ISO framework, since I personally do not remember making the link with the TEI.
There are several ongoing projects related to further parts of ISO 639, and the
difficulties to reconcile the Ethnologue and Linguasphere groups (to simplify
the matter) would make me suggest to adopt a stand-by position regarding the
topic.
Best,
Laurent

Selon Christian Wittern :

>
> Dear Council members,
>
> A friend send me an email, which contained the following sentence,
> attributed to  Debbie Garside of linguaphone ICT:
>
> "Links to the TEI have already been established and the model that is
> currently being created  for ISO 639-6 will take on board the needs of
> these industries."
>
> He asked me for further clarification and I have to admit here that I
> do remember faintly that this came up once (although the link to
> ethnologue does seem stronger), but I do not remember that we did
> establish some formal relationship -- Can somebody help me here?
>
> (I am a bit embarrassed with this and have thought for a while that we
> need a better way to keep track of these issues -- a search interface
> to the minutes and WG documents would probably be a great improvement)
>
> 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
>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu May 26 18:56:30 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 27 May 2005 07:56:30 +0900
Subject: [tei-council] TEI and ISO 639-6
In-Reply-To: <1117089781.42956ff576438@www.loria.fr> (Laurent Romary's
	message of "Thu, 26 May 2005 08:43:01 +0200")
References: 
	<1117089781.42956ff576438@www.loria.fr>
Message-ID: 

Laurent.Romary at loria.fr writes:

> I do hope it is not related to the fact that we have regular exchanges in the
> ISO framework, since I personally do not remember making the link with the TEI.
> There are several ongoing projects related to further parts of ISO 639, and the
> difficulties to reconcile the Ethnologue and Linguasphere groups (to simplify
> the matter) would make me suggest to adopt a stand-by position regarding the
> topic.

Thanks Laurent.  It thus seems that somebody tries to capitalize on a
non-existing link with the TEI.  If nothing else, it proves at least
that the TEI seems to be thought of as heavy enought to be used in
such a manouever.

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 May 27 03:57:40 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 27 May 2005 08:57:40 +0100
Subject: [tei-council] TEI and ISO 639-6
In-Reply-To: 
References: 
	<1117089781.42956ff576438@www.loria.fr>

Message-ID: <9427861c06d050a1343941826b34c172@computing-services.oxford.ac.uk>

I met the lady mentioned as the source of this rumour at an ISO meeting 
somewhere last year (Jeju?  Lisbon? it's all a blur)  and had a brief 
conversation with her about the TEI's proposals on language 
identification, mentioning in particular Christian's name as the head 
of the relevant TEI  work group and the fact that we were adopting an 
ISDO multipart identifier approach. As is my wont I also doubtless made 
warm and encouraging noises about the TEI always being willing to work 
with other communities and steal those ideas which we liked. I then 
participated in a meeting of the ISO workgroup concerned (SC4/WG2 I 
think?) and witnessed at first hand the awful mess which is ISO 639-6 
at present. To my partially-informed eye, the proposals coming out of 
the Linguasphere lobby (which was heavily represented at this meeting) 
looked  inappropriate for TEI use (or any one else's really); a point 
which I made in the meeting. I was also struck by the very unseemly way 
in which the politics of the meeting were handled. So, I agree with 
Laurent, this is a can of worms we should keep our nose out of. 
(Irrelevant linguistic note for Laurent:  if you "stand by" you are 
usually holding back from action but expecting to receive orders to 
proceed at short notice: cf "back up"; I think a better idiom here 
would be that we recommend a  "stand off" or "hands off" position)

Lou (just back from Croatia and catching up on email)

On 26 May 2005, at 23:56, Christian Wittern wrote:

> Laurent.Romary at loria.fr writes:
>
>> I do hope it is not related to the fact that we have regular 
>> exchanges in the
>> ISO framework, since I personally do not remember making the link 
>> with the TEI.
>> There are several ongoing projects related to further parts of ISO 
>> 639, and the
>> difficulties to reconcile the Ethnologue and Linguasphere groups (to 
>> simplify
>> the matter) would make me suggest to adopt a stand-by position 
>> regarding the
>> topic.
>
> Thanks Laurent.  It thus seems that somebody tries to capitalize on a
> non-existing link with the TEI.  If nothing else, it proves at least
> that the TEI seems to be thought of as heavy enought to be used in
> such a manouever.
>
> 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
>
>
 From the Macmini at Burnard Towers

From Syd_Bauman at Brown.edu  Sun May 29 13:51:12 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 29 May 2005 13:51:12 -0400
Subject: [tei-council] Dr. Julia
Message-ID: <17050.272.505003.743056@emt.wwp.brown.edu>

Congratulations to Julia H. Flanders, Director of the Women Writers
Project and Chair of the TEI Consortium. Julia received her Ph.D. in
English from Brown University just over half an hour ago.

From Syd_Bauman at Brown.edu  Wed Jun  1 23:54:32 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 1 Jun 2005 23:54:32 -0400
Subject: [tei-council] attributes/datatypes action item progress report
Message-ID: <17054.33528.315110.391865@emt.wwp.brown.edu>

In Paris y'all tasked me with going through all TEI attributes and
attempting to classify each as a particular datatype, noting those
that are singular or for some other reason don't fall into a datatype
well, and considering what datatypes are needed, what extra
constraints are needed, etc.

I had hoped to finish going through them by today. I'm almost there.
This turns out to be an enormous task, for which I've put off several
other things (e.g., shopping for a digital camera, meeting with David
Durand about SA).

There are 541 separate attributes to be considered. Of those, I've
examined *all* 298 non-"text" attributes, and along the way an
additional 17 of the "text" ones. I had put the "text" ones off until
last because for the most part these are going to be textual
attributes that we've already considered in both EDW79 and EDW86, and
thus should be pretty easy. (Although, as I say it, I'm worried those
may be "famous last words" :-)

(BTW, I put "text" in quotes because I think that the keyword "text"
should occur in the TEI schemas only once: in the declaration of the
macro 'tei.text' (or whatever we decide to call it). In attribute
declarations the keyword "token" or "xsd:token" should be used
instead.[1] In element declarations, tei.text should be used.[2])

I plan to finish up the "text" attributes in the next day or two, and
hope to write up a report shortly thereafter.

Notes
-----
[1] The only difference between "token" and "xsd:token" is that param
    patterns can only be used to restrict the latter, not the former.
    I.e., 
    element file {
       attribute name { xsd:token { maxLength = "32" } },
       attribute type { "alias" | "folder" | "plain" },
       empty
    }
    is a valid declaration, but the same thing without "xsd:" causes
    an error.
[2] tei.text = mixed { g* }
    This is because wherever what we used to call PCDATA is allowed,
    the  element must be permitted, in case a non-Unicode
    character is required. There are some exceptions, I suppose.
    E.g., it's hard to imagine the content of  requiring
    characters outside of Unicode.

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jun  7 15:54:41 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 07 Jun 2005 20:54:41 +0100
Subject: [tei-council] documentation for XSLT stylesheets
Message-ID: <42A5FB81.8000504@computing-services.oxford.ac.uk>

I'd appreciate it if a few of you could test my new stylesheet documentation
at http://www.tei-c.org.uk/Stylesheets/teic/ and points south. This is
the outcome
of my work in Timor seriously restructuring the stylesheets, and I hope
the result is more useable and useful. As you'll find, there is

 1 general documentation
 2 detailed documentation of parameters you can change
 3 generated javadoc-like interface to stylesheet source
 4 stylebear web form for generating customizations.

2, 3 and 4 are generated from the documentation embedded in the
stylesheets, using xsltdoc
(for which thanks to Christian for the pointer).

-- 
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 Jun  7 18:52:19 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 08 Jun 2005 07:52:19 +0900
Subject: [tei-council] documentation for XSLT stylesheets
In-Reply-To: <42A5FB81.8000504@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Tue, 07 Jun 2005 20:54:41 +0100")
References: <42A5FB81.8000504@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

> I'd appreciate it if a few of you could test my new stylesheet documentation
> at http://www.tei-c.org.uk/Stylesheets/teic/ and points south. This is
> the outcome
> of my work in Timor seriously restructuring the stylesheets, and I hope
> the result is more useable and useful. 

Very glad to see you back here:-)

I would definitely say so, this looks like a big improvement over what
we had before.  The organization and presentation of the material also
looks pretty understandable -- I will have to test it more thoroughly
next time when I try to use the new stylesheets:-)  

The template listing is particularily welcome , which makes the whole
thing a lot easier to navigate.  One thing though, the links from
there do not seem to work: They do have a #foobar anchor link, but
this does not seem to correspond to the one used in the target page,
so all links end up at the top of the page.

Anyway, thanks a lot for your efforts in this area,

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 computing-services.oxford.ac.uk  Wed Jun  8 01:58:59 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 08 Jun 2005 06:58:59 +0100
Subject: [tei-council] documentation for XSLT stylesheets
In-Reply-To: 
References: <42A5FB81.8000504@computing-services.oxford.ac.uk>

Message-ID: <42A68923.2030205@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>The template listing is particularily welcome , which makes the whole
>thing a lot easier to navigate.  One thing though, the links from
>there do not seem to work: They do have a #foobar anchor link, but
>this does not seem to correspond to the one used in the target page,
>so all links end up at the top of the page.
>  
>

can you me more precise? I cant see what you mean.

-- 
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 Jun  8 03:05:16 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 08 Jun 2005 16:05:16 +0900
Subject: [tei-council] documentation for XSLT stylesheets
In-Reply-To: <42A68923.2030205@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Wed, 08 Jun 2005 06:58:59 +0100")
References: <42A5FB81.8000504@computing-services.oxford.ac.uk>

	<42A68923.2030205@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

> Christian Wittern wrote:
>
>>The template listing is particularily welcome , which makes the whole
>>thing a lot easier to navigate.  One thing though, the links from
>>there do not seem to work: They do have a #foobar anchor link, but
>>this does not seem to correspond to the one used in the target page,
>>so all links end up at the top of the page.
>>  
>>
>
> can you me more precise? I cant see what you mean.

Sure.  I am on the Functions/Templates list page at 

http://www.tei-c.org.uk/Stylesheets/teic/xsltdoc/functionTemplateList.html

Now, let say I want to inspect the "addID" template in [fo], the third
in this list.  The link on this page is to

http://www.tei-c.org.uk/Stylesheets/teic/xsltdoc/common/tei-param.xsl.xd.html#d94e1698

but if I click there, I am taken to the top of the page 

http://www.tei-c.org.uk/Stylesheets/teic/xsltdoc/common/tei-param.xsl.xd.html

as it turns out, there does not seem to be something about "addID" on
this page at all.  The same is also true for the few other things I
clicked on on this page.

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 computing-services.oxford.ac.uk  Wed Jun  8 04:37:36 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 08 Jun 2005 09:37:36 +0100
Subject: [tei-council] documentation for XSLT stylesheets
In-Reply-To: 
References: <42A5FB81.8000504@computing-services.oxford.ac.uk>		<42A68923.2030205@computing-services.oxford.ac.uk>

Message-ID: <42A6AE50.5030206@computing-services.oxford.ac.uk>

Christian Wittern wrote:
> as it turns out, there does not seem to be something about "addID" on
> this page at all.  The same is also true for the few other things I
> clicked on on this page.

I think that is the problem, because some of the other ones I tried worked fine.

-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 computing-services.oxford.ac.uk  Wed Jun  8 11:23:21 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 08 Jun 2005 16:23:21 +0100
Subject: [tei-council] documentation for XSLT stylesheets
In-Reply-To: 
References: <42A5FB81.8000504@computing-services.oxford.ac.uk>		<42A68923.2030205@computing-services.oxford.ac.uk>

Message-ID: <42A70D69.9090000@computing-services.oxford.ac.uk>

>http://www.tei-c.org.uk/Stylesheets/teic/xsltdoc/functionTemplateList.html
>
>Now, let say I want to inspect the "addID" template in [fo], the third
>in this list.  The link on this page is to
>
>http://www.tei-c.org.uk/Stylesheets/teic/xsltdoc/common/tei-param.xsl.xd.html#d94e1698
>
>but if I click there, I am taken to the top of the page 
>
>http://www.tei-c.org.uk/Stylesheets/teic/xsltdoc/common/tei-param.xsl.xd.html
>
>as it turns out, there does not seem to be something about "addID" on
>this page at all. 
>  
>
hmm. now I see what you mean. This is a bug in the xsltdoc stuff. I'll
see what I can 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 wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Jun 10 04:14:57 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 10 Jun 2005 17:14:57 +0900
Subject: [tei-council] Excuse from Council duties for Edward Vanhoutte
Message-ID: 

Dear Council members,

Edward has asked to be excused from his duties to the TEI Council
until the end of the year -- he said he needs the time to write up his
PhD thesis.  Fortunately, though, part of his thesis will focus on
issues relevant to chap. 18 and 19:

He writes:

> A critical evaluation of the TEI options for scholarly editing (ch. 18
> & 19) is planned for the third and last section of my thesis, which
> should be written in October-November.

So we will count on this as a contribution to P5 (and review of PH and
TC)!

As for his other responsibilities:

> So, if it's possible, I'd like to be ecxused from any formal
> responsibilities I've taken on. This is the study of the certainty
> issue in the TEI encoding and the review of chapters PH, TC, PR.

If I am not mistaken, we need thus mainly help with the review of the
one-page-chapter 8, PR.

Best wishes to Edward for a successful writing session!

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  Sat Jun 11 10:50:16 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 11 Jun 2005 15:50:16 +0100
Subject: [tei-council] Further ruminations on index
Message-ID: <42AAFA28.6030202@computing-services.oxford.ac.uk>

In response to Michael Beddow's comments on the proposed revision for 
the  element, I have now redrafted the section in question, but  
in the process, I hit on two other questions on which Council's opinions 
would be much appreciated:

a) the  element, used to mark the point where a  div typically 
containing an index or toc is to be generated, currently has no way of 
specifying headers or footers for the generated div, other than by the 
use of the global n attribute. That overloading seems to be inadequate, 
as well as potentially falling foul of all the other known problems 
inherent in text-valued attributes.  I therefore propose to change the 
content of divGen from  "empty" to  "zero-or-more elements from the 
tei.divtop class". Any objections/counter suggestions?

b) the  element currently has a close relative called  
which is used when the indexed point is a span. The only difference 
between the two is that the latter has an additional attribute "to" 
which indicates the end of the  span. It seems to me that this is a 
rather cumbersome method of doing the job. Furthermore, since  
(and therefore ) can now be nested recursively, the content 
model gets a little complicated. It occurs to me that we could simplify 
matters by (a) removing  (b) defining an attribute "scope" or 
"range" or even "target" on  with a default value of "here" but 
with the option to include any URL.

If you share my view that this might be a good idea, bear in mind that 
we will need to do the same thing for all the other xxxSpan elements 
(,  etc.) , which is partly why I have not implemented 
it yet.  What do you think?

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jun 12 06:32:30 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 12 Jun 2005 11:32:30 +0100
Subject: [tei-council] Further ruminations on index
In-Reply-To: <42AAFA28.6030202@computing-services.oxford.ac.uk>
References: <42AAFA28.6030202@computing-services.oxford.ac.uk>
Message-ID: <42AC0F3E.6010404@computing-services.oxford.ac.uk>

Lou Burnard wrote:

> a) the  element, used to mark the point where a  div typically
> containing an index or toc is to be generated, currently has no way of
> specifying headers or footers for the generated div, other than by the
> use of the global n attribute. That overloading seems to be
> inadequate, as well as potentially falling foul of all the other known
> problems inherent in text-valued attributes.  I therefore propose to
> change the content of divGen from  "empty" to  "zero-or-more elements
> from the tei.divtop class". Any objections/counter suggestions?

It strikes me as a cleaner way to proceed. Speaking as an implementor,
it would make my life easier not having
to maintain a separate place where the heading is specified

>
> b) the  element currently has a close relative called
>  which is used when the indexed point is a span. The only
> difference between the two is that the latter has an additional
> attribute "to" which indicates the end of the  span. It seems to me
> that this is a rather cumbersome method of doing the job. Furthermore,
> since  (and therefore ) can now be nested
> recursively, the content model gets a little complicated. It occurs to
> me that we could simplify matters by (a) removing  (b)
> defining an attribute "scope" or "range" or even "target" on 
> with a default value of "here" but with the option to include any URL.

I seem to recall suggesting the same thing a few months back when this
came up before, so I like 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 computing-services.oxford.ac.uk  Sat Jun 18 07:45:36 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 18 Jun 2005 12:45:36 +0100
Subject: [tei-council] tei skeletons
Message-ID: <42B40960.8030601@computing-services.oxford.ac.uk>

no, not the ones in cupboards, the ones you load in your editor to start
off a new document.

I want to make a collection of these (in P5) as a Debian package, and to
make ready for Emacs and oXygen.
I have a simple one for vanilla TEI, but would like suggestions for
others, probably with associated schemas.

Ideas? contributions? bad plan?

-- 
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 Jun 18 07:59:19 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Sat, 18 Jun 2005 13:59:19 +0200
Subject: [tei-council] tei skeletons
In-Reply-To: <42B40960.8030601@computing-services.oxford.ac.uk>
References: <42B40960.8030601@computing-services.oxford.ac.uk>
Message-ID: <9f2e970be069a18c9a6ed10e1d23ea10@loria.fr>

Hi Seb,
Do you mean something like this (for a dictionary)? :

                 ...
                 ...

                     ..

                     ...

                 ...

Le 18 juin 05, ? 13:45, Sebastian Rahtz a ?crit :

> no, not the ones in cupboards, the ones you load in your editor to 
> start
> off a new document.
>
> I want to make a collection of these (in P5) as a Debian package, and 
> to
> make ready for Emacs and oXygen.
> I have a simple one for vanilla TEI, but would like suggestions for
> others, probably with associated schemas.
>
> Ideas? contributions? bad plan?
>
> -- 
> 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 computing-services.oxford.ac.uk  Sat Jun 18 08:13:02 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 18 Jun 2005 13:13:02 +0100
Subject: [tei-council] tei skeletons
In-Reply-To: <9f2e970be069a18c9a6ed10e1d23ea10@loria.fr>
References: <42B40960.8030601@computing-services.oxford.ac.uk>
	<9f2e970be069a18c9a6ed10e1d23ea10@loria.fr>
Message-ID: <42B40FCE.6060802@computing-services.oxford.ac.uk>

yes, precisely. what is the corresponding ODD?

-- 
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 Jun 18 08:30:46 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Sat, 18 Jun 2005 14:30:46 +0200
Subject: [tei-council] tei skeletons
In-Reply-To: <42B40FCE.6060802@computing-services.oxford.ac.uk>
References: <42B40960.8030601@computing-services.oxford.ac.uk>
	<9f2e970be069a18c9a6ed10e1d23ea10@loria.fr>
	<42B40FCE.6060802@computing-services.oxford.ac.uk>
Message-ID: 

The ODD is the standard print dictionary chapter specification. Is 
there a need to provide something more specific (like requiring at 
least one entry within a div)?

Le 18 juin 05, ? 14:13, Sebastian Rahtz a ?crit :

> yes, precisely. what is the corresponding ODD?
>
> -- 
> 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 Jun 18 09:10:34 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 18 Jun 2005 14:10:34 +0100
Subject: [tei-council] tei skeletons
In-Reply-To: <42B40960.8030601@computing-services.oxford.ac.uk>
References: <42B40960.8030601@computing-services.oxford.ac.uk>
Message-ID: <42B41D4A.3080209@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:

>no, not the ones in cupboards, the ones you load in your editor to start
>off a new document.
>
>I want to make a collection of these (in P5) as a Debian package, and to
>make ready for Emacs and oXygen.
>I have a simple one for vanilla TEI, but would like suggestions for
>others, probably with associated schemas.
>
>Ideas? contributions? bad plan?
>
>  
>
One for a manuscript description would be useful, I think. Matthew?

L

From James.Cummings at computing-services.oxford.ac.uk  Sat Jun 18 11:16:38 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sat, 18 Jun 2005 08:16:38 -0700
Subject: [tei-council] tei skeletons
In-Reply-To: <42B41D4A.3080209@computing-services.oxford.ac.uk>
References: <42B40960.8030601@computing-services.oxford.ac.uk>
	<42B41D4A.3080209@computing-services.oxford.ac.uk>
Message-ID: <42B43AD6.1050808@computing-services.oxford.ac.uk>

Lou Burnard wrote:
> Sebastian Rahtz wrote:
> 
>> no, not the ones in cupboards, the ones you load in your editor to start
>> off a new document.
>>
>> I want to make a collection of these (in P5) as a Debian package, and to
>> make ready for Emacs and oXygen.
>> I have a simple one for vanilla TEI, but would like suggestions for
>> others, probably with associated schemas.
>>
>> Ideas? contributions? bad plan?
>>
>>  
>>
> One for a manuscript description would be useful, I think. Matthew?

Since it involves a change of root element, a teiCorpus one might be a 
good example.  It could be a longer one also including a blank 
 element in the header, maybe example langUsage and category, 
and then more than one TEI element with some basic linguistic tagging 
in it?  Sort of a start your own linguistic corpus skeleton?

-James

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jun 18 18:47:14 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 18 Jun 2005 23:47:14 +0100
Subject: [tei-council] tei skeletons
In-Reply-To: <42B43AD6.1050808@computing-services.oxford.ac.uk>
References: <42B40960.8030601@computing-services.oxford.ac.uk>	<42B41D4A.3080209@computing-services.oxford.ac.uk>
	<42B43AD6.1050808@computing-services.oxford.ac.uk>
Message-ID: <42B4A472.2030704@computing-services.oxford.ac.uk>

James Cummings wrote:

>
> Since it involves a change of root element, a teiCorpus one might be a
> good example.  It could be a longer one also including a blank
>  element in the header, maybe example langUsage and category,
> and then more than one TEI element with some basic linguistic tagging
> in it?  Sort of a start your own linguistic corpus skeleton?

this is out of my territory. can you supply?

-- 
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  Sat Jun 18 20:03:28 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sat, 18 Jun 2005 17:03:28 -0700
Subject: [tei-council] tei skeletons
In-Reply-To: <42B4A472.2030704@computing-services.oxford.ac.uk>
References: <42B40960.8030601@computing-services.oxford.ac.uk>	<42B41D4A.3080209@computing-services.oxford.ac.uk>
	<42B43AD6.1050808@computing-services.oxford.ac.uk>
	<42B4A472.2030704@computing-services.oxford.ac.uk>
Message-ID: <42B4B650.5050005@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> James Cummings wrote:
> 
> 
>>Since it involves a change of root element, a teiCorpus one might be a
>>good example.  It could be a longer one also including a blank
>> element in the header, maybe example langUsage and category,
>>and then more than one TEI element with some basic linguistic tagging
>>in it?  Sort of a start your own linguistic corpus skeleton?
> 
> 
> this is out of my territory. can you supply?
> 

I am happy to do so, though (as lou comments privately) on reflection 
most people editing Corpora probably don't do so as a teiCorpus 
document to begin with, and so maybe a skeleton is a bit silly.  But, 
I might argue, it would act as a reminder that one could do so.  If it 
was just very basic and didn't include langUsage, category etc.  but 
just the basic structural divisions, then it is just a reiteration of 
the basic template so I'm not sure if it is very helpful.

But I'm supposed to be listening to Ian Lancashire, so just append the 
basic structural version here.  If others think doing one with 
examples of basic corpus elements would be useful, then I'm happy to 
do so.  (Though really just more example texts seem better)

-James

-----

                 ...
                 ...

                 ...

                 ...

                     ...
                     ...

                     ...

                     ...

                     ...

                     ...
                     ...

                     ...

                     ...

                     ...

From Julia_Flanders at brown.edu  Mon Jun 20 23:56:32 2005
From: Julia_Flanders at brown.edu (Julia Flanders)
Date: Mon, 20 Jun 2005 23:56:32 -0400
Subject: [tei-council] help with certainty?
Message-ID: <42B78FF0.10700@brown.edu>

Edward Vanhoutte has had to withdraw from working on the certainty 
issue, and I'm wondering whether any other member of the TEI council has 
a secret hankering to work on this issue with me. If not I can take a 
stab on my own, but would welcome a co-investigator.

Best, Julia

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jun 22 22:23:10 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 23 Jun 2005 11:23:10 +0900
Subject: [tei-council] preparing for next council call
Message-ID: 

Dear Council members,

In the midst of the rainy season, Kyoto is dump, hot and almost
unbearable, especially after the paradise-like athmosphere of British
Columbia.  

If my memory serves me right (unlikely as that might seem under these
conditions), we agreed to hold the next conference on July 8, 1300
UTC, although the minutes of our Paris meeting at
http://www.tei-c.org.uk/Council/tcm17.xml?style=printable are silent
about that.

In preparation for this, I would like to ask everybody to look at the
minutes, especially at the action items and, in the spirit of item 10
on that list, please report on the progress here to this list *prior*
to the call. 

In addition to that, "Input for TEI P5: a summary" at
http://www.tei-c.org.uk/Drafts/edw83.xml does mention a few additional
assigments of chapters, but we have failed to track the progress.  I
dont see mentioned the assignment of "11 Transcriptions of Speech" to
Thomas Schmidt, Hamburg -- this is based on information by Andreas
Witt -- does it have any substance?

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 computing-services.oxford.ac.uk  Thu Jun 23 03:44:16 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Thu, 23 Jun 2005 08:44:16 +0100 (BST)
Subject: [tei-council] preparing for next council call
In-Reply-To: 
Message-ID: <20050623074416.1F20E2DE1F@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/20050623/4924c4a0/attachment.ksh 

From sebastian.rahtz at computing-services.oxford.ac.uk  Thu Jun 23 18:07:48 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Thu, 23 Jun 2005 23:07:48 +0100
Subject: [tei-council] roma and documentation and I18N
Message-ID: <42BB32B4.8040202@computing-services.oxford.ac.uk>

I have just reengineered the way Roma does internationalization, and the
way it does documentation.
The result should be closer to what one would expect. If you now visit
http://tei.oucs.ox.ac.uk/Roma/,
make a customization, change the language, and request HTML
documentation, you will see what
I mean. Schemas will also now pick up translated  strings, so
they'll then appear in eg oXygen.

What was the change, you ask? I now run the I18N process _after_ making
an ODD2ODD expansion
of the original ODD. It simplifies things a lot.

-- 
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 Jun 26 07:15:15 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 26 Jun 2005 20:15:15 +0900
Subject: [tei-council] Re: roma, documentation, i18n
In-Reply-To: <42BBD6E2.5040302@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Fri, 24 Jun 2005 10:48:18 +0100")
References: <42BB332D.1040305@computing-services.oxford.ac.uk>

	<42BBBD3D.3060003@computing-services.oxford.ac.uk>

	<42BBD6E2.5040302@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian, Council members,

Sebastian and I are discussing proposals for how to maintain
translations of  and  elements.  

Sebastian Rahtz  writes:

> Christian Wittern wrote:
>
>>One way would be to allow multiple  and  elements in the
>>ODD, but it would be difficult to maintain, I guess.
>>  
>>
> its possible, I suppose.
>
> I think we should discuss this by email, decide on a plan,
> and ratify it at the council phone call

My stab at this would be to maintain the stuff in a stripped down ODD
file, one per target language, which has a  for each
element, in change mode and the only change is to provide the 
or  elements in the target language.  You could easily generate
such a beast and pull in the current english one for reference, if
desired.

These files should then be kept on SF in the I18N module. Does that
sound doable?  Or are there any better ideas?

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 computing-services.oxford.ac.uk  Sun Jun 26 09:40:36 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 14:40:36 +0100
Subject: [tei-council] Re: roma, documentation, i18n
In-Reply-To: 
References: <42BB332D.1040305@computing-services.oxford.ac.uk>		<42BBBD3D.3060003@computing-services.oxford.ac.uk>		<42BBD6E2.5040302@computing-services.oxford.ac.uk>

Message-ID: <42BEB054.2080705@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>My stab at this would be to maintain the stuff in a stripped down ODD
>file, one per target language, which has a  for each
>element, in change mode and the only change is to provide the 
>or  elements in the target language.  You could easily generate
>such a beast and pull in the current english one for reference, if
>desired.
>  
>
this coincides nicely with a conversation I had with Lou on Friday,
where we came to the same conclusion. One advantage is that
if the changes are written as a genuine ODD file, the person
working on it can generate test schemas and documentation locally.
However, for general use, we periodically merge all the separate I18N
files into the main P5 source, and enhance the processors to
do the right thing with multple  and 

>These files should then be kept on SF in the I18N module. 
>  
>
yes, this sounds good, to let someone else pick up just the translations
and work
on them.

of course, we have the perpetual problem that when a new element is added,
or the  is altered in the English original, we have to bring all
the translations
into sync.

dont forget attributes, and vallists, by the way

-- 
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 computing-services.oxford.ac.uk  Sun Jun 26 14:04:56 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 19:04:56 +0100
Subject: [tei-council] another agenda item
Message-ID: <42BEEE48.4030308@computing-services.oxford.ac.uk>

I'd like us to re-discuss, albeit at not too much length,
the schema by which P5 gets "released" to the public.
At present, there are the following ways in which a change
gets pushed out:

 1 on Sourceforge, in CVS. any one monitoring CVS gets the gory fixes,
which are not even guarenteed to be internally consistent
 2 on Sourceforge, as file releases. these are zip files containing the
P5 materials in a supposedly runtime tree structure
 3 on the TEI web site, in the form of the HTML version of the Guidelines
 4 on the web, as the eXist database behind Roma, also used for the
/Query/tag.xq?name=foo interface;
   noting that Roma conceptually lives on both tei.oucs.ox.ac.uk and on
tei-c.org.uk, which can be kept apart
 5 in Debian packages
 6 bundled in TEI Emacs
 7 in TEI Knoppix CDs and DVDs

of these, only the first and second are clear; #1 happens when anyone
makes a change; and #2 happens
when the Council authorizes a new numbered release. The others happen
currently at mostly my whim,
and sometimes at Lou's whim.  This isn't right, and I do admit that its
quite largely my fault.

I think we should have clearer rules on what triggers any of these
releases
(since only #1 is really a Release").

If someone would like to write down a set of rules, and the Council
agrees to them,
I promise to abide by them in future....

-- 
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 Jun 26 16:18:08 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 26 Jun 2005 16:18:08 -0400
Subject: [tei-council] another agenda item
In-Reply-To: <42BEEE48.4030308@computing-services.oxford.ac.uk>
References: <42BEEE48.4030308@computing-services.oxford.ac.uk>
Message-ID: <17087.3456.464155.297244@emt.wwp.brown.edu>

>  1. on Sourceforge, in CVS. any one monitoring CVS gets the gory
>     fixes, which are not even guarenteed to be internally consistent
>  2. on Sourceforge, as file releases. these are zip files containing the
>     P5 materials in a supposedly runtime tree structure
>  3. on the TEI web site, in the form of the HTML version of the Guidelines
>  4. on the web, as the eXist database behind Roma, also used for
>     the /Query/tag.xq?name=foo interface; noting that Roma
>     conceptually lives on both tei.oucs.ox.ac.uk and on tei-c.org.uk,
>     which can be kept apart
>  5. in Debian packages
>  6. bundled in TEI Emacs
>  7. in TEI Knoppix CDs and DVDs

> of these, only the first and second are clear; #1 happens when
> anyone makes a change; and #2 happens when the Council authorizes a
> new numbered release.

One thing missing here is the issue of where bug fixes fit in. It makes 
sense for the editors to be able to push out file releases of this sort 
without pestering the Council.

We also haven't distinguish between the fairly frequent "releases"
that happen as we make minor updates (especially within the
development process) and the more formal increments (e.g. P5.1, P6,
etc.). It seems to me that the Council should be directly involved in
the major updates (e.g., new chapter, significant change to class
system, etc.), and not involved in the minor development updates or
bug-fix updates. Not so sure about the intermediate ones.

> (since only #1 is really a Release").

I don't think #1 is a release -- it's the current work repository. #2
is the only thing that is really a "release" at the moment. What is
lacking is an agreement on what should trigger a new file release in
Sourceforge (i.e., a new #2). I'd propose that in this pre-release
protion of P5's lifecycle, pretty much any significant change
(including bug fixes) that results in a self-consistent, self-
validating, working version of the Guidelines should trigger a new
release on Sourceforge. 

Whether or not Council should be directly involved in this triggering
is an open question in my mind. I'm inclined to say no for small
things, yes for larger things, and just to trust the editors'
judgement as to what's small and what's large.

Personally I would like to see 3 & 4 follow 2 fairly quickly; i.e.,
shortly (hopefully measured in minutes to hours) after a new
Sourceforge file release is made available, that version is
propagated to the TEI website, both as HTML and in the eXist
database.

I presume that our build process all but requires that 5 follow 1. As
for 6 & 7 these are "products" of your making, and it seems to me you
get to decide what version of the pre-release of P5 they use.
Personally I'd be inclined to have them follow #2, also, but at
whatever pace you determine.

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jun 26 16:27:43 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 21:27:43 +0100
Subject: [tei-council] another agenda item
In-Reply-To: <17087.3456.464155.297244@emt.wwp.brown.edu>
References: <42BEEE48.4030308@computing-services.oxford.ac.uk>
	<17087.3456.464155.297244@emt.wwp.brown.edu>
Message-ID: <42BF0FBF.8080300@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>One thing missing here is the issue of where bug fixes fit in. It makes 
>sense for the editors to be able to push out file releases of this sort 
>without pestering the Council.
>  
>
yes; it needs  articulating what a "release" is. I think the council
should approve release 1.0 and 1.1, but that the editors can release
1.1.1 and 1.1.2

>We also haven't distinguish between the fairly frequent "releases"
>that happen as we make minor updates (especially within the
>development process) and the more formal increments (e.g. P5.1, P6,
>etc.). It seems to me that the Council should be directly involved in
>the major updates (e.g., new chapter, significant change to class
>system, etc.), and not involved in the minor development updates or
>bug-fix updates. Not so sure about the intermediate ones.
>  
>
I agree. It's just slightly hard to be sure how to classify some changes

>
>>(since only #1 is really a Release").
>>    
>>
>
>I don't think #1 is a release -- it's the current work repository. #2
>is the only thing that is really a "release" at the moment
>
yes, my typo. I meant "#2"

>I'd propose that in this pre-release
>protion of P5's lifecycle, pretty much any significant change
>(including bug fixes) that results in a self-consistent, self-
>validating, working version of the Guidelines should trigger a new
>release on Sourceforge. 
>  
>
I could buy that. If its OK that this could happen every week or two
at times.

>Personally I would like to see 3 & 4 follow 2 fairly quickly; i.e.,
>shortly (hopefully measured in minutes to hours) after a new
>Sourceforge file release is made available, that version is
>propagated to the TEI website, both as HTML and in the eXist
>database.
>  
>
agreed.  they need much better automation

>I presume that our build process all but requires that 5 follow 1.
>
not sure I follow that? can you expand?

-- 
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 computing-services.oxford.ac.uk  Sun Jun 26 16:39:00 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 21:39:00 +0100
Subject: [tei-council] exemplars
Message-ID: <42BF1264.7060407@computing-services.oxford.ac.uk>

Further to the "skeletons" thread, I have created 10 exemplars of TEI P5
use; currently available as a Debian package (tei-p5-exemplars)
and in CVS as P5/Exemplars. They comprise an ODD specification, and a
skeleton XML file;
the ODD is expanded to DTD/XSD/RNG/RNC in the Debian package, of
course.  These files are called
up Emacs, for examples, when you ask to create a "TEI for Drama" file;
it would be easy to imagine them
in oXygen doing the same thing.

I make no great claims for the excellence of these creatures, and will
not be at all offended
if people say "throw them all away and use these ones instead". but I do
think the idea is
important, and I'd be keen to get someone else working on them.

(blame Lou for the name, by the way)

-- 
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 Jun 26 16:42:58 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 26 Jun 2005 16:42:58 -0400
Subject: [tei-council] which version of the stylesheets?
Message-ID: <17087.4946.143837.806952@emt.wwp.brown.edu>

If I'm being an idiot I apologize in advance and blame the weather
for my inability to think. But is there any easy way to ascertain
which version of Sebastian's stylesheets are bundled with oXygen 6.0?
Is it really version 2.1 (which is the highest number associated with
the word "version" when I grep for it)? Is there some documentation I
should have read that would have told me?

From James.Cummings at computing-services.oxford.ac.uk  Sun Jun 26 16:50:31 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 26 Jun 2005 21:50:31 +0100
Subject: [tei-council] exemplars
In-Reply-To: <42BF1264.7060407@computing-services.oxford.ac.uk>
References: <42BF1264.7060407@computing-services.oxford.ac.uk>
Message-ID: <42BF1517.7090509@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> the ODD is expanded to DTD/XSD/RNG/RNC in the Debian package, of
> course.  These files are called

Is there are reason why the odd files should be included btw? 
Shouldn't there be examples of odd files as well?  Or are these in 
another package?

-James

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jun 26 16:53:03 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 21:53:03 +0100
Subject: [tei-council] which version of the stylesheets?
In-Reply-To: <17087.4946.143837.806952@emt.wwp.brown.edu>
References: <17087.4946.143837.806952@emt.wwp.brown.edu>
Message-ID: <42BF15AF.5050308@computing-services.oxford.ac.uk>

For the record, only version 5.0.9 onwards is supported by the author...

-- 
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 computing-services.oxford.ac.uk  Sun Jun 26 16:55:09 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 21:55:09 +0100
Subject: [tei-council] exemplars
In-Reply-To: <42BF1517.7090509@computing-services.oxford.ac.uk>
References: <42BF1264.7060407@computing-services.oxford.ac.uk>
	<42BF1517.7090509@computing-services.oxford.ac.uk>
Message-ID: <42BF162D.3040105@computing-services.oxford.ac.uk>

James Cummings wrote:

> Sebastian Rahtz wrote:
>
>> the ODD is expanded to DTD/XSD/RNG/RNC in the Debian package, of
>> course.  These files are called
>
>
> Is there are reason why the odd files should be included btw?
> Shouldn't there be examples of odd files as well?  Or are these in
> another package?

my packaging error, sorry.

before I go to fix it, what do you think the right location is?

-- 
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 Jun 26 17:03:26 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 26 Jun 2005 22:03:26 +0100
Subject: [tei-council] exemplars
In-Reply-To: <42BF162D.3040105@computing-services.oxford.ac.uk>
References: <42BF1264.7060407@computing-services.oxford.ac.uk>
	<42BF1517.7090509@computing-services.oxford.ac.uk>
	<42BF162D.3040105@computing-services.oxford.ac.uk>
Message-ID: <42BF181E.6000501@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> James Cummings wrote:
> 
> 
>>Sebastian Rahtz wrote:
>>
>>
>>>the ODD is expanded to DTD/XSD/RNG/RNC in the Debian package, of
>>>course.  These files are called
>>
>>
>>Is there are reason why the odd files should be included btw?
>>Shouldn't there be examples of odd files as well?  Or are these in
>>another package?
> 
> 
> my packaging error, sorry.
> 
> before I go to fix it, what do you think the right location is?

Good question.  /usr/share/xml/tei/schema/odds/ ?
or /usr/share/doc/tei/odds/ ?

-James

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jun 26 17:21:21 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 22:21:21 +0100
Subject: [tei-council] exemplars
In-Reply-To: <42BF181E.6000501@computing-services.oxford.ac.uk>
References: <42BF1264.7060407@computing-services.oxford.ac.uk>	<42BF1517.7090509@computing-services.oxford.ac.uk>	<42BF162D.3040105@computing-services.oxford.ac.uk>
	<42BF181E.6000501@computing-services.oxford.ac.uk>
Message-ID: <42BF1C51.8040009@computing-services.oxford.ac.uk>

James Cummings wrote:

>
> Good question.  /usr/share/xml/tei/schema/odds/ ?
> or /usr/share/doc/tei/odds/ ?

I'm inclining to the former

-- 
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 Jun 26 17:41:51 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 26 Jun 2005 17:41:51 -0400
Subject: [tei-council] exemplars
In-Reply-To: <42BF1C51.8040009@computing-services.oxford.ac.uk>
References: <42BF1264.7060407@computing-services.oxford.ac.uk>
	<42BF1517.7090509@computing-services.oxford.ac.uk>
	<42BF162D.3040105@computing-services.oxford.ac.uk>
	<42BF181E.6000501@computing-services.oxford.ac.uk>
	<42BF1C51.8040009@computing-services.oxford.ac.uk>
Message-ID: <17087.8479.882119.785101@emt.wwp.brown.edu>

> > Good question.  /usr/share/xml/tei/schema/odds/ ?
> > or /usr/share/doc/tei/odds/ ?
> 
> I'm inclining to the former

I don't think of an ODD as a schema; perhaps it's a schema
description, but not a schema.

I think I'd lean towards
  /usr/share/xml/tei/odds/

From Syd_Bauman at Brown.edu  Sun Jun 26 17:59:39 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 26 Jun 2005 17:59:39 -0400
Subject: [tei-council] Re: which version of the stylesheets?
In-Reply-To: <42BF17A9.3090708@oxygenxml.com>
References: <17087.4946.143837.806952@emt.wwp.brown.edu>
	<42BF17A9.3090708@oxygenxml.com>
Message-ID: <17087.9547.440952.184705@emt.wwp.brown.edu>

> Help->About->Components -- Frameworks -- TEI XSL. It is 2.1.

Right! Thank you. Yes, and I notice something I've mentioned before
as a problem -- that the version of the TEI DTDs is listed as "P4",
whereas it really should be more precise: P4:2004-07.

Sebastian -- is version 2.1 still available anywhere?

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jun 26 18:04:16 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 26 Jun 2005 23:04:16 +0100
Subject: [tei-council] Re: which version of the stylesheets?
In-Reply-To: <17087.9547.440952.184705@emt.wwp.brown.edu>
References: <17087.4946.143837.806952@emt.wwp.brown.edu>	<42BF17A9.3090708@oxygenxml.com>
	<17087.9547.440952.184705@emt.wwp.brown.edu>
Message-ID: <42BF2660.6010109@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>>Help->About->Components -- Frameworks -- TEI XSL. It is 2.1.
>>    
>>
>
>Right! Thank you. Yes, and I notice something I've mentioned before
>as a problem -- that the version of the TEI DTDs is listed as "P4",
>whereas it really should be more precise: P4:2004-07.
>
>Sebastian -- is version 2.1 still available anywhere?
>
>  
>
Deep in Perforce, somewhere. Issued 2003-09-17, so thats
prehistory.

-- 
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 Jun 26 18:37:43 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 27 Jun 2005 07:37:43 +0900
Subject: [tei-council] Re: roma, documentation, i18n
In-Reply-To: <42BEB054.2080705@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Sun, 26 Jun 2005 14:40:36 +0100")
References: <42BB332D.1040305@computing-services.oxford.ac.uk>

	<42BBBD3D.3060003@computing-services.oxford.ac.uk>

	<42BBD6E2.5040302@computing-services.oxford.ac.uk>

	<42BEB054.2080705@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

>>
> this coincides nicely with a conversation I had with Lou on Friday,
> where we came to the same conclusion. One advantage is that
> if the changes are written as a genuine ODD file, the person
> working on it can generate test schemas and documentation locally.
> However, for general use, we periodically merge all the separate I18N
> files into the main P5 source, and enhance the processors to
> do the right thing with multple  and 

What would be the advantage of pulling this into the main P5 source?
I see only added maintainance cost with no real benefit.  You could as
easily pull them out and merge them into the tree on runtime.

>
>>These files should then be kept on SF in the I18N module. 
>>  
>>
> yes, this sounds good, to let someone else pick up just the translations
> and work
> on them.
>
> of course, we have the perpetual problem that when a new element is added,
> or the  is altered in the English original, we have to bring all
> the translations
> into sync.

Yeah, well.  If this happens, we trigger a notice to the
tei-translators mailing list, I assume.

>
> dont forget attributes, and vallists, by the way

But attributes should be covered within the elementSpec, shouldnt
they.

What to do about vallists is an interesting question that needs to be
discussed.

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  Sun Jun 26 18:46:23 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 27 Jun 2005 07:46:23 +0900
Subject: [tei-council] another agenda item
In-Reply-To: <17087.3456.464155.297244@emt.wwp.brown.edu> (Syd Bauman's
	message of "Sun, 26 Jun 2005 16:18:08 -0400")
References: <42BEEE48.4030308@computing-services.oxford.ac.uk>
	<17087.3456.464155.297244@emt.wwp.brown.edu>
Message-ID: 

Syd Bauman  writes:

>>  1. on Sourceforge, in CVS. any one monitoring CVS gets the gory
>>     fixes, which are not even guarenteed to be internally consistent
>>  2. on Sourceforge, as file releases. these are zip files containing the
>>     P5 materials in a supposedly runtime tree structure
>>  3. on the TEI web site, in the form of the HTML version of the Guidelines
>>  4. on the web, as the eXist database behind Roma, also used for
>>     the /Query/tag.xq?name=foo interface; noting that Roma
>>     conceptually lives on both tei.oucs.ox.ac.uk and on tei-c.org.uk,
>>     which can be kept apart
>>  5. in Debian packages
>>  6. bundled in TEI Emacs
>>  7. in TEI Knoppix CDs and DVDs
>
>> of these, only the first and second are clear; #1 happens when
>> anyone makes a change; and #2 happens when the Council authorizes a
>> new numbered release.

Did we have this policy?  If not, I assume we should introduce it:-)

To me, anything above 2 is merely derived and does not need additional
authorization or whatever, it just needs to be part of the workflow.
Most of that could be triggered automatically, I assume.  The timing
of 7, on the other hand would presumably not depend on the release
state, but more on the need to have such a beast at a certain time
(e.g. for classes, conference, members meeting etc.)
Roma OTOH would quite closely follow the CVS version, right?
>
> One thing missing here is the issue of where bug fixes fit in. It makes 
> sense for the editors to be able to push out file releases of this sort 
> without pestering the Council.

Bug fixes go inot CVS immediately.  They do not necessarily trigger a
new release -- maybe a minor release if they are serious.

> We also haven't distinguish between the fairly frequent "releases"
> that happen as we make minor updates (especially within the
> development process) and the more formal increments (e.g. P5.1, P6,
> etc.). It seems to me that the Council should be directly involved in
> the major updates (e.g., new chapter, significant change to class
> system, etc.), and not involved in the minor development updates or
> bug-fix updates. Not so sure about the intermediate ones.

Thas sounds goot to me.

>
>
>> (since only #1 is really a Release").
>
> I don't think #1 is a release -- it's the current work repository. #2
> is the only thing that is really a "release" at the moment. What is
> lacking is an agreement on what should trigger a new file release in
> Sourceforge (i.e., a new #2). I'd propose that in this pre-release
> protion of P5's lifecycle, pretty much any significant change
> (including bug fixes) that results in a self-consistent, self-
> validating, working version of the Guidelines should trigger a new
> release on Sourceforge.

Then you might end up with frequent new snapshots, which might be of
mixed quality (cf the eXist development model).  I assume that people
interested that much in the day-to-day development could as easily
follow the CVS.

Apart from that, I think it would make sense to delegate the timings
of the other releases to Sebastian (or whoever is involved), they do
not seem to fall directly into the area of the work the council is
supervising.

All the best,

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  Mon Jun 27 00:40:35 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 27 Jun 2005 00:40:35 -0400
Subject: [tei-council] another agenda item
In-Reply-To: 
References: <42BEEE48.4030308@computing-services.oxford.ac.uk>
	<17087.3456.464155.297244@emt.wwp.brown.edu>

Message-ID: <17087.33603.667507.593350@emt.wwp.brown.edu>

> Did we have this policy? If not, I assume we should introduce it:-)

I didn't think so, and as I said, I don't think it's necessarily the
right way to proceed. 

> > I'd propose that in this pre-release protion of P5's lifecycle,
> > pretty much any significant change (including bug fixes) that
> > results in a self-consistent, self- validating, working version
> > of the Guidelines should trigger a new release on Sourceforge.
> 
> Then you might end up with frequent new snapshots, which might be
> of mixed quality (cf the eXist development model). I assume that
> people interested that much in the day-to-day development could as
> easily follow the CVS.

What is the eXist development model?

In any case, the logic behind my suggestion was that although the
content of the snapshot releases might be mixed in nature, we'd only
make snaphots of "working" versions of the Guidelines, specifically
to avoid poor-quality snapshots. The idea being that CVS followers
take their chances, but snapshot downloaders should get the newest we
can provide that we know is at least rudimentarily OK.

Another policy to add on top would be to say that we don't make a new
snapshot unless not only is it a self-validating, self-consistent,
consistent version, but it is in some way better than the previous
snapshot. 

> Apart from that, I think it would make sense to delegate the
> timings of the other releases to Sebastian (or whoever is
> involved), they do not seem to fall directly into the area of the
> work the council is supervising.

While it may be Sebastian who does the actual work, I believe that
Council should set the basic principles or Guidelines, and the
editors should decide when snapshots are in order according to them.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Jun 27 01:18:21 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 27 Jun 2005 14:18:21 +0900
Subject: [tei-council] another agenda item
In-Reply-To: <17087.33603.667507.593350@emt.wwp.brown.edu> (Syd Bauman's
	message of "Mon, 27 Jun 2005 00:40:35 -0400")
References: <42BEEE48.4030308@computing-services.oxford.ac.uk>
	<17087.3456.464155.297244@emt.wwp.brown.edu>

	<17087.33603.667507.593350@emt.wwp.brown.edu>
Message-ID: 

Syd Bauman  writes:

> What is the eXist development model?

To provide a snapshot every couple of (days|weeks) to make it easier
to follow development.
The downside of this is that in most cases it is too frequent for most
people to follow.  
>
> In any case, the logic behind my suggestion was that although the
> content of the snapshot releases might be mixed in nature, we'd only
> make snaphots of "working" versions of the Guidelines, specifically
> to avoid poor-quality snapshots. The idea being that CVS followers
> take their chances, but snapshot downloaders should get the newest we
> can provide that we know is at least rudimentarily OK.

That implies that we will need to have some kind of QA process before
the snapshot release, not just packaging.

>
> Another policy to add on top would be to say that we don't make a new
> snapshot unless not only is it a self-validating, self-consistent,
> consistent version, but it is in some way better than the previous
> snapshot. 
>
>
>> Apart from that, I think it would make sense to delegate the
>> timings of the other releases to Sebastian (or whoever is
>> involved), they do not seem to fall directly into the area of the
>> work the council is supervising.
>
> While it may be Sebastian who does the actual work, I believe that
> Council should set the basic principles or Guidelines, and the
> editors should decide when snapshots are in order according to them.

Right.  The quote above relates to the other derived releases (debian,
DVD) Sebastian was asking about.

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 computing-services.oxford.ac.uk  Mon Jun 27 04:16:29 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 27 Jun 2005 09:16:29 +0100
Subject: [tei-council] another agenda item
In-Reply-To: <17087.33603.667507.593350@emt.wwp.brown.edu>
References: <42BEEE48.4030308@computing-services.oxford.ac.uk>	<17087.3456.464155.297244@emt.wwp.brown.edu>	
	<17087.33603.667507.593350@emt.wwp.brown.edu>
Message-ID: <42BFB5DD.502@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>In any case, the logic behind my suggestion was that although the
>content of the snapshot releases might be mixed in nature, we'd only
>make snaphots of "working" versions of the Guidelines, specifically
>to avoid poor-quality snapshots. 
>  
>
thats fine, of course.

>Another policy to add on top would be to say that we don't make a new
>snapshot unless not only is it a self-validating, self-consistent,
>consistent version, but it is in some way better than the previous
>snapshot. 
>  
>
what changes would one make which would not make the thing "better"?
any bug fix makes the system better for someone.

-- 
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 computing-services.oxford.ac.uk  Mon Jun 27 04:30:44 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 27 Jun 2005 09:30:44 +0100
Subject: [tei-council] another agenda item
In-Reply-To: 
References: <42BEEE48.4030308@computing-services.oxford.ac.uk>	<17087.3456.464155.297244@emt.wwp.brown.edu>

Message-ID: <42BFB934.30003@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>Roma OTOH would quite closely follow the CVS version, right?
>  
>
would it? I really think we want more clarity on this sort of thing.
when someone comes to the web site and accesses the P5 HTML Guidelines,
and then uses the Query interface (or Roma), they should really get the
same result, I think. Either CVS *or* the current minor release *or* the
current
major release. Not a mixture.

>
>Then you might end up with frequent new snapshots, which might be of
>mixed quality (cf the eXist development model).  I assume that people
>interested that much in the day-to-day development could as easily
>follow the CVS.
>  
>
the flaw there is that we do not, so everyone tells me, have
a documented or easy to use system for people to work with
the CVS sources. If you assure me that Joe Fairly Clued-Up Encoder
can do a cvs update, and then generate schemas or read the documentation,
then its OK; but I keep being told the opposite...

>Apart from that, I think it would make sense to delegate the timings
>of the other releases to Sebastian (or whoever is involved), they do
>not seem to fall directly into the area of the work the council is
>supervising.
>  
>
Things like the TEI Knoppix CD is a separate activity, I agree. But
unless the TEI Consortium fully endorses distribution methods
other then CVS and SF File Releases, we are not in a healthy state.
As it stands, we are in a  fairly ridiculous position that only
Debian Linux users get a decent service; to make matters worse,
the releases of the various  formats are not under the control of
the editors, since neither of them has the infrastructure to
prepare and release the materials.

One solution would be create a new job of Release Manager,
who determined when and how minor releases happened; the
Council would be consulted on major releases; the editors
would be left to coordinate the actual code work in the background.

I am not confident that the system as of today works; neither of
the editors is able to keep up with the current work plan, let alone
take on more work, the public is getting confused messages
about versions from  all over the place, and the council is not
visibly taking charge.

-- 
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 Jun 27 04:27:28 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 27 Jun 2005 09:27:28 +0100
Subject: [tei-council] another agenda item
In-Reply-To: 
References: <42BEEE48.4030308@computing-services.oxford.ac.uk>	<17087.3456.464155.297244@emt.wwp.brown.edu>		<17087.33603.667507.593350@emt.wwp.brown.edu>

Message-ID: <42BFB870.10708@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>
>To provide a snapshot every couple of (days|weeks) to make it easier
>to follow development.
>The downside of this is that in most cases it is too frequent for most
>people to follow.  
>  
>

I agree. A nightly build is too frequent, particularly if we continue 
with the current spasmodic rate of progress.

>>In any case, the logic behind my suggestion was that although the
>>content of the snapshot releases might be mixed in nature, we'd only
>>make snaphots of "working" versions of the Guidelines, specifically
>>to avoid poor-quality snapshots. The idea being that CVS followers
>>take their chances, but snapshot downloaders should get the newest we
>>can provide that we know is at least rudimentarily OK.
>>    
>>
>
>That implies that we will need to have some kind of QA process before
>the snapshot release, not just packaging.
>  
>

What would we need beyond the current "make; make validate; make test" 
cycle?

>  
>

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Jun 27 04:33:11 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 27 Jun 2005 09:33:11 +0100
Subject: [tei-council] Re: roma, documentation, i18n
In-Reply-To: 
References: <42BB332D.1040305@computing-services.oxford.ac.uk>		<42BBBD3D.3060003@computing-services.oxford.ac.uk>		<42BBD6E2.5040302@computing-services.oxford.ac.uk>		<42BEB054.2080705@computing-services.oxford.ac.uk>

Message-ID: <42BFB9C7.5020808@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>What would be the advantage of pulling this into the main P5 source?
>I see only added maintainance cost with no real benefit.  You could as
>easily pull them out and merge them into the tree on runtime.
>  
>
perhaps its matter of semantics; if the main ODD processing
software expects to find the various language-specific s
in site in the main document, then it does not much matter whether
the merge is at runtime or at source. I just want to avoid a "normal"
ODD processor from having to know about the language modules.

>  
>
>>dont forget attributes, and vallists, by the way
>>    
>>
>
>But attributes should be covered within the elementSpec, shouldnt
>they.
>
>  
>
and the classSpecs.

-- 
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 Jun 27 04:35:31 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 27 Jun 2005 09:35:31 +0100
Subject: [tei-council] Re: roma, documentation, i18n
In-Reply-To: <42BFB9C7.5020808@computing-services.oxford.ac.uk>
References: <42BB332D.1040305@computing-services.oxford.ac.uk>		<42BBBD3D.3060003@computing-services.oxford.ac.uk>		<42BBD6E2.5040302@computing-services.oxford.ac.uk>		<42BEB054.2080705@computing-services.oxford.ac.uk>	
	<42BFB9C7.5020808@computing-services.oxford.ac.uk>
Message-ID: <42BFBA53.4040702@computing-services.oxford.ac.uk>

It's also a philosophical point. ODD is "one" document does it all. In a 
semi-normative document like P5 you need to have one canonical 
translation for each language, and the logical place to store that 
canonical translation is in the canon. I see the language module files 
which Sebastian is talking about as being exactly analogous to other 
non-canonical schema modifications.

Theres a whole lot of quality control issues here too, of course: at 
what point and how does who decide that translation x is canonical, and 
can therefore be merged into the source?

I also think it's important for a useful to be able to see other 
translations. If, for example, I were translating into Italian, I would 
probably find a pre-existing French translation helpful.

Lou

 Sebastian Rahtz wrote:

>Christian Wittern wrote:
>
>  
>
>>What would be the advantage of pulling this into the main P5 source?
>>I see only added maintainance cost with no real benefit.  You could as
>>easily pull them out and merge them into the tree on runtime.
>> 
>>
>>    
>>
>perhaps its matter of semantics; if the main ODD processing
>software expects to find the various language-specific s
>in site in the main document, then it does not much matter whether
>the merge is at runtime or at source. I just want to avoid a "normal"
>ODD processor from having to know about the language modules.
>
>  
>
>> 
>>
>>    
>>
>>>dont forget attributes, and vallists, by the way
>>>   
>>>
>>>      
>>>
>>But attributes should be covered within the elementSpec, shouldnt
>>they.
>>
>> 
>>
>>    
>>
>and the classSpecs.
>
>
>  
>

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Jun 27 07:44:58 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 27 Jun 2005 12:44:58 +0100
Subject: [tei-council] another agenda item
In-Reply-To: <42BFB870.10708@computing-services.oxford.ac.uk>
References: <42BEEE48.4030308@computing-services.oxford.ac.uk>	<17087.3456.464155.297244@emt.wwp.brown.edu>		<17087.33603.667507.593350@emt.wwp.brown.edu>	
	<42BFB870.10708@computing-services.oxford.ac.uk>
Message-ID: <42BFE6BA.4020203@computing-services.oxford.ac.uk>

Lou Burnard wrote

>>
>
> I agree. A nightly build is too frequent, particularly if we continue
> with the current spasmodic rate of progress.

lets not continue like that, then....  let's have a roadmap, with dated
milestones,
and stick to it.

>
> What would we need beyond the current "make; make validate; make test"
> cycle?

so long as everyone has that cycle working properly, then its OK. but we
have
had a fair degree of difficulty in getting more than one development system
in sync with any others...

-- 
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 computing-services.oxford.ac.uk  Mon Jun 27 07:46:57 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 27 Jun 2005 12:46:57 +0100
Subject: [tei-council] Re: roma, documentation, i18n
In-Reply-To: <42BFBA53.4040702@computing-services.oxford.ac.uk>
References: <42BB332D.1040305@computing-services.oxford.ac.uk>		<42BBBD3D.3060003@computing-services.oxford.ac.uk>		<42BBD6E2.5040302@computing-services.oxford.ac.uk>		<42BEB054.2080705@computing-services.oxford.ac.uk>		<42BFB9C7.5020808@computing-services.oxford.ac.uk>
	<42BFBA53.4040702@computing-services.oxford.ac.uk>
Message-ID: <42BFE731.6020407@computing-services.oxford.ac.uk>

Lou Burnard wrote:

>
> Theres a whole lot of quality control issues here too, of course: at
> what point and how does who decide that translation x is canonical,
> and can therefore be merged into the source?

agreed, this is a question. by supporting language modules externally
and internally, we would
have a cleanish system for supporting this notion.

-- 
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 Jun 27 23:36:15 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 28 Jun 2005 12:36:15 +0900
Subject: [tei-council] ITS@W3C  (was:Re: roma, documentation, i18n)
In-Reply-To: <42BFB9C7.5020808@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Mon, 27 Jun 2005 09:33:11 +0100")
References: <42BB332D.1040305@computing-services.oxford.ac.uk>

	<42BBBD3D.3060003@computing-services.oxford.ac.uk>

	<42BBD6E2.5040302@computing-services.oxford.ac.uk>

	<42BEB054.2080705@computing-services.oxford.ac.uk>

	<42BFB9C7.5020808@computing-services.oxford.ac.uk>
Message-ID: 

Council members,

As it happens, I had a long conversation with Felix Sasaki yesterday,
who joined the W3C host in Japan this April and works there on i18n
issues.  He mentioned work going on at the W3C at the ITS
(Internationalization Tag Set,
cf. http://www.w3.org/International/its/) group, which seems to have
some overlap with our problem here. The mission statement for the
group is as follows:

Mission: Develop a set of elements and attributes that can be used
with new DTDs/Schemas to support the internationalization and
localization of documents; and provide best practice techniques for
developers of DTDs/Schemas that show how to enable
internationalization of their documents.

They are not ready and it might be overkill, but it seems to me that
we should monitor this.

He asked also if somebody from the TEI would be interested to join
this group; we also discussed if the TEI could/should consider to
enter into some formal relation with the W3C.  I would be interested
in opinions from the Council members on the desirability of such a
development.

Sebastian Rahtz  writes:

> Christian Wittern wrote:
>
>>What would be the advantage of pulling this into the main P5 source?
>>I see only added maintainance cost with no real benefit.  You could as
>>easily pull them out and merge them into the tree on runtime.
>>  
>>
> perhaps its matter of semantics; if the main ODD processing
> software expects to find the various language-specific s
> in site in the main document, then it does not much matter whether
> the merge is at runtime or at source. I just want to avoid a "normal"
> ODD processor from having to know about the language modules.
>
>>>dont forget attributes, and vallists, by the way

>>But attributes should be covered within the elementSpec, shouldnt
>>they.
>>
> and the classSpecs.

-- 
 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  Tue Jun 28 04:00:49 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 28 Jun 2005 09:00:49 +0100
Subject: [tei-council] ITS@W3C 
In-Reply-To: 
References: <42BB332D.1040305@computing-services.oxford.ac.uk>		<42BBBD3D.3060003@computing-services.oxford.ac.uk>		<42BBD6E2.5040302@computing-services.oxford.ac.uk>		<42BEB054.2080705@computing-services.oxford.ac.uk>		<42BFB9C7.5020808@computing-services.oxford.ac.uk>

Message-ID: <42C103B1.6030208@computing-services.oxford.ac.uk>

Well, this does seem to overlap quite a lot... and it would be nice if 
we could persuade W3C to adopt ODD oor something like it...  I met Felix 
at Extreme last year and formed a high opinion of him, so I think 
working with him might be well worthwhile.

If we were to set up with W3C something like the existing liaison with 
ISO, would we be able to say that the TEI runs the internet?

Seriously, tho. Yes, I agree that this would be worth pursuing, and I am 
willing to help pursue it, or persuade Sebastian to, assuming either of 
us can find the time.

Lou

Christian Wittern wrote:

>Council members,
>
>As it happens, I had a long conversation with Felix Sasaki yesterday,
>who joined the W3C host in Japan this April and works there on i18n
>issues.  He mentioned work going on at the W3C at the ITS
>(Internationalization Tag Set,
>cf. http://www.w3.org/International/its/) group, which seems to have
>some overlap with our problem here. The mission statement for the
>group is as follows:
>
>Mission: Develop a set of elements and attributes that can be used
>with new DTDs/Schemas to support the internationalization and
>localization of documents; and provide best practice techniques for
>developers of DTDs/Schemas that show how to enable
>internationalization of their documents.
>
>
>They are not ready and it might be overkill, but it seems to me that
>we should monitor this.
>
>He asked also if somebody from the TEI would be interested to join
>this group; we also discussed if the TEI could/should consider to
>enter into some formal relation with the W3C.  I would be interested
>in opinions from the Council members on the desirability of such a
>development.
>
>Sebastian Rahtz  writes:
>
>  
>
>>Christian Wittern wrote:
>>
>>    
>>
>>>What would be the advantage of pulling this into the main P5 source?
>>>I see only added maintainance cost with no real benefit.  You could as
>>>easily pull them out and merge them into the tree on runtime.
>>> 
>>>
>>>      
>>>
>>perhaps its matter of semantics; if the main ODD processing
>>software expects to find the various language-specific s
>>in site in the main document, then it does not much matter whether
>>the merge is at runtime or at source. I just want to avoid a "normal"
>>ODD processor from having to know about the language modules.
>>
>>    
>>
>>>>dont forget attributes, and vallists, by the way
>>>>        
>>>>
>
>  
>
>>>But attributes should be covered within the elementSpec, shouldnt
>>>they.
>>>
>>>      
>>>
>>and the classSpecs.
>>    
>>
>
>  
>

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jun 28 04:25:25 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 28 Jun 2005 09:25:25 +0100
Subject: [tei-council] ITS@W3C 
In-Reply-To: 
References: <42BB332D.1040305@computing-services.oxford.ac.uk>		<42BBBD3D.3060003@computing-services.oxford.ac.uk>		<42BBD6E2.5040302@computing-services.oxford.ac.uk>		<42BEB054.2080705@computing-services.oxford.ac.uk>		<42BFB9C7.5020808@computing-services.oxford.ac.uk>

Message-ID: <42C10975.2040901@computing-services.oxford.ac.uk>

I would rank getting closer to the W3C as pretty important. The work put
into the ODD
system will be as nothing if it has no impact on the real world.

I'm more than happy to put effort into this; if Lou tells me I can treat it
as part of my job, I can join the working group and represent the TEI.

-- 
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 Jun 28 05:04:24 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 28 Jun 2005 18:04:24 +0900
Subject: [tei-council] ITS@W3C
In-Reply-To: <42C103B1.6030208@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Tue, 28 Jun 2005 09:00:49 +0100")
References: <42BB332D.1040305@computing-services.oxford.ac.uk>

	<42BBBD3D.3060003@computing-services.oxford.ac.uk>

	<42BBD6E2.5040302@computing-services.oxford.ac.uk>

	<42BEB054.2080705@computing-services.oxford.ac.uk>

	<42BFB9C7.5020808@computing-services.oxford.ac.uk>

	<42C103B1.6030208@computing-services.oxford.ac.uk>
Message-ID: 

Lou Burnard  writes:

> Well, this does seem to overlap quite a lot... and it would be nice if
> we could persuade W3C to adopt ODD oor something like it...  I met
> Felix at Extreme last year and formed a high opinion of him, so I
> think working with him might be well worthwhile.

It seems to be a bit optimistic to me to assume they will adopt ODD,
but one could give it a try.  If Sebastian could join that WG for the
TEI that would be great. 

>
> If we were to set up with W3C something like the existing liaison with
> ISO, would we be able to say that the TEI runs the internet?

Sure. And that is the last step before world domination.

All the best,

Christian

-- 
 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From Julia_Flanders at Brown.edu  Tue Jun 28 16:07:03 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Tue, 28 Jun 2005 16:07:03 -0400
Subject: [tei-council] working on certainty
Message-ID: 

While I am happy to continue to work on certainty, I will not be able 
to complete a review/report on this by July 1, now that Edward is no 
longer able to work with me  on it. I'll try to get this done before 
the conference call, but probably not much before.

best wishes, Julia

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Jun 28 18:21:17 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 29 Jun 2005 07:21:17 +0900
Subject: [tei-council] working on certainty
In-Reply-To:  (Julia Flanders's
	message of "Tue, 28 Jun 2005 16:07:03 -0400")
References: 
Message-ID: 

Julia Flanders  writes:

> While I am happy to continue to work on certainty, I will not be able
> to complete a review/report on this by July 1, now that Edward is no
> longer able to work with me  on it. I'll try to get this done before
> the conference call, but probably not much before.

Julia, thank you for your efforts.  I think we will be fine if we can
get a status report for the conference call, maybe combined with an
estimate of the remaining work and time schedule.

All the best,

Christian

-- 
 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  Wed Jun 29 02:29:00 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Wed, 29 Jun 2005 08:29:00 +0200
Subject: [tei-council] ITS@W3C 
In-Reply-To: <42C10975.2040901@computing-services.oxford.ac.uk>
References: <42BB332D.1040305@computing-services.oxford.ac.uk>		<42BBBD3D.3060003@computing-services.oxford.ac.uk>		<42BBD6E2.5040302@computing-services.oxford.ac.uk>		<42BEB054.2080705@computing-services.oxford.ac.uk>		<42BFB9C7.5020808@computing-services.oxford.ac.uk>

	<42C10975.2040901@computing-services.oxford.ac.uk>
Message-ID: 

I would strongly support this idea!
Laurent

Le 28 juin 05, ? 10:25, Sebastian Rahtz a ?crit :

> I would rank getting closer to the W3C as pretty important. The work 
> put
> into the ODD
> system will be as nothing if it has no impact on the real world.
>
> I'm more than happy to put effort into this; if Lou tells me I can 
> treat it
> as part of my job, I can join the working group and represent the TEI.
>
> -- 
> 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 wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Jun 30 01:40:53 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 30 Jun 2005 14:40:53 +0900
Subject: [tei-council] [AIR] action item report: Epigraphical encoding 
Message-ID: 

Dear Council members,

This is a report about my follow up to section 8.4 of the minutes at
http://www.tei-c.org.uk/Council/tcm17.xml?style=printable 

I have been looking around to see what people in the epigraphical
field been doing.  Elli Mylonas pointed me to a number of ressources,
among other things the EpiDoc group and a mailing list, both run by
Tom Elliot.  He responded today, after more than a month, that he will
be following up soon.  

I looked briefly at EpiDoc, which looks like it could use a lot of
work. On the upside, they came up with Guidelines of their own for
their user community and some stylesheets to get things going.
Development seems to be rather slow.   I will work further with them
and will see if a common base for further development can be found.
There are some projects, most notably the Aphrodisias project at Kings
College etc.

All the best,

Christian

-- 
 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From jawalsh at indiana.edu  Fri Jul  1 13:09:13 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Fri, 1 Jul 2005 12:09:13 -0500
Subject: [tei-council] Re: next conference call of TEI council
In-Reply-To: 
References: 
Message-ID: <410EA325-18A4-4CE8-8E34-F3AD3B469CD6@indiana.edu>

Christian,

I've scheduled the conference call for next week at 1300 UTC.

The instructions (number, code, etc.) remain the same:

When dialing into the conference bridge??from

Long Distance................. DIAL   1-812-856-3550 ........ at  
recording enter your 4-digit pass code followed by pound (#) sign.

Participants Code: 0920

John
| John A. Walsh, Associate Director for Projects and Services
| Digital Library Program / Indiana University Libraries
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 Fax:812-856-2062 

On Jun 22, 2005, at 8:31 PM, Christian Wittern wrote:

>
> Hi John,
>
> If memory serves me right, we agreed to hold the next conference call
> on July 8, usual time (= 1300 UTC).  Does that conform with your
> recollections?  If so, I would appreciate if you could set up the call
> and notify us of the procedures.
>
> Thanks for prividing this to the TEI:-)
>
> 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 Jul  1 19:03:40 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 02 Jul 2005 08:03:40 +0900
Subject: [tei-council] Re: next conference call of TEI council
In-Reply-To: <410EA325-18A4-4CE8-8E34-F3AD3B469CD6@indiana.edu> (John A.
	Walsh's message of "Fri, 1 Jul 2005 12:09:13 -0500")
References: 
	<410EA325-18A4-4CE8-8E34-F3AD3B469CD6@indiana.edu>
Message-ID: 

Thanks John,

so we will talk on July 8th at the usual time. 

As mentioned previously, I would like to see reports on action items
previous to the call.  In your reports, which might be brief, please
indicate where you are seeking input from the council.  In addition to
that, please give me items you want to see on the agenda.  So far I
have

- principles for publication of snapshots etc. of P5
  Status: a proposal from Sebastian and subsequent discussion, we need to come
  to a decision.

- I18N infrastructure for translations of gloss and desc, vallists etc
  Status: some discussion, but no proposal yet - need to consider
  aligning with W3C ITS effort.

Anything else?

All the best,

Christian

"John A. Walsh"  writes:

> Christian,
>
> I've scheduled the conference call for next week at 1300 UTC.
>
> The instructions (number, code, etc.) remain the same:
>
> When dialing into the conference bridge??from
>
> Long Distance................. DIAL   1-812-856-3550 ........ at
> recording enter your 4-digit pass code followed by pound (#) sign.
>
> Participants Code: 0920
>
> John
> | John A. Walsh, Associate Director for Projects and Services
> | Digital Library Program / Indiana University Libraries
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | Voice:812-855-8758 Fax:812-856-2062 
>
> On Jun 22, 2005, at 8:31 PM, Christian Wittern wrote:
>
>>
>> Hi John,
>>
>> If memory serves me right, we agreed to hold the next conference call
>> on July 8, usual time (= 1300 UTC).  Does that conform with your
>> recollections?  If so, I would appreciate if you could set up the call
>> and notify us of the procedures.
>>
>> Thanks for prividing this to the TEI:-)
>>
>> All the best,
>>
>> Christian
>>
>> -- 
>>  Christian Wittern
>>  Institute for Research in Humanities, Kyoto University
>>  47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN
>>
>
>
>
>

-- 

 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From jawalsh at indiana.edu  Sat Jul  2 06:15:10 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Sat, 2 Jul 2005 05:15:10 -0500
Subject: [tei-council] Oxygen P5 Instructions
Message-ID: <1E9CCE26-ADDE-474C-B8A4-7AE5CD7CF707@indiana.edu>

Hi all,

In response to action item " Instructions for using a P5 grammar in  
oXygen," I've posted instructions for setting up P5 grammars in the  
Oxygen XML Editor.

HTML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/ 
oxygenValidationInstructions.html
TEI/XML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/ 
oxygenValidationInstructions.xml

John
| John A. Walsh, Associate Director for Projects and Services
| Digital Library Program / Indiana University Libraries
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 Fax:812-856-2062 

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jul  2 10:56:01 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 02 Jul 2005 15:56:01 +0100
Subject: [tei-council] Oxygen P5 Instructions
In-Reply-To: <1E9CCE26-ADDE-474C-B8A4-7AE5CD7CF707@indiana.edu>
References: <1E9CCE26-ADDE-474C-B8A4-7AE5CD7CF707@indiana.edu>
Message-ID: <42C6AB01.2020400@computing-services.oxford.ac.uk>

John A. Walsh wrote:

> Hi all,
>
> In response to action item " Instructions for using a P5 grammar in 
> oXygen," I've posted instructions for setting up P5 grammars in the 
> Oxygen XML Editor.
>
> HTML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/
> oxygenValidationInstructions.html
> TEI/XML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/
> oxygenValidationInstructions.xml
>
any reason not to put this on the TEI web site?

-- 
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 computing-services.oxford.ac.uk  Sat Jul  2 18:05:06 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 02 Jul 2005 23:05:06 +0100
Subject: [tei-council] directory layout of a TEI distribution
Message-ID: <42C70F92.3080708@computing-services.oxford.ac.uk>

Some of us have been having a discussion with the oXygen folks about
a common layout for TEI-related files (docs, schemas, dtds, skeleton files,
kitchen sink etc). Christian rightly said that the Council should be
discussing this,
so here goes.

The following diagram shows the layout I am using for my Debian Linux
packages
(starting at /usr/share).

The xml/tei tree is pretty well mandated by conformance to standards
for Debian (though please point out any really silly stuff), but the doc
tree
is more open for discussion.  How should the HTML guidelines relate to
the skeletons?
what should the "skeletons" be called? where is the documentation for
these exemplars?
should I use "p4" or "P4" consistently?

I'd like to absolutely clear on this before the phone call at the latest,
so if you can tear yourselves away from Pink Floyd at Live8 for a few
minutes...

share
|-- doc
|   `-- tei
|       |-- P4
|       |   `-- Figures
|       |-- P5
|       |-- Pictures
|       |-- skeletons
|       |   |-- p4
|       |   `-- p5
|       `-- web
|           `-- Query
`-- xml
    `-- tei
        |-- odd
        |-- schema
        |   |-- dtd
        |   |   |-- p4
        |   |   `-- p5
        |   |-- relaxng
        |   |   |-- p4
        |   |   `-- p5
        |   `-- xsd
        |       `-- p5
        `-- stylesheet
            |-- base
            |   |-- p4
            |   |   |-- common
            |   |   |-- fo
            |   |   |-- html
            |   |   `-- latex
            |   `-- p5
            |       |-- common
            |       |-- fo
            |       |-- html
            |       `-- latex
            |-- odds
            |-- slides
            `-- teic

38 directories

-- 
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 Jul  2 18:37:40 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 2 Jul 2005 18:37:40 -0400
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C70F92.3080708@computing-services.oxford.ac.uk>
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
Message-ID: <17095.5940.562704.110577@emt.wwp.brown.edu>

Does SyncRO Soft need to know the layout of the doc/ hierarchy? I was
under the (perhaps mistaken) impression they were interested in our
hammering down the tei/schema/ and tei/stylesheet directories layout
and canonical web location, so that they can mirror that layout and
point to the canonical location from their frameworks/ directory.

> share
> |-- doc
> |   `-- tei
> |       |-- P4
> |       |   `-- Figures
> |       |-- P5
> |       |-- Pictures
> |       |-- skeletons
> |       |   |-- p4
> |       |   `-- p5
> |       `-- web
> |           `-- Query

I understand what's in doc/tei/P4/Figures, and I even undertand why
it's named "Figures/" (as is customary in the TEI depot and website)
as opposed to "figures/" (which would be far more common, if not
customary, in Debian). But I don't understand why there isn't such a
directory inside /doc/tei/P5/, nor what is in doc/tei/Pictures. I
can look, of course, but not everyone on this list has a Debian
system with your stuff on it handy, and I still don't understand
a) why it's there ... this stuff isn't needed to read the Guidelines,
   is it? and
b) why we have GIF files instead of PNGs. Are GIFs back to being
   politically acceptable now?

What is in skeletons/? What are web/ and web/Query? (Which I don't
have.) 

> `-- xml
>     `-- tei
>         |-- odd

Perhaps this directory should be called /xml/tei/src/ instead? And
shouldn't there be a p5/ child of this directory? That way, if & when
the Board permits the source of P4 to be public, or if & when there
ever are ODDs for P6 (or perhaps a P5.1 beast) we could put it in
this directory, too

>         |-- schema
>         |   |-- dtd
>         |   |   |-- p4
>         |   |   `-- p5
>         |   |-- relaxng
>         |   |   |-- p4
>         |   |   `-- p5

My objection to there being RelaxNG schema for P4 still holds.[1]
I doubt I'm going to win this one, but there should at least be a
README file reminding users that technically, a DOCTYPE declaration
is required in P4, IMHO. (Or, we should create a P4.1 that drops that
requirement.) 

>         |   `-- xsd
>         |       `-- p5
>         `-- stylesheet
>             |-- base
>             |   |-- p4
>             |   |   |-- common
>             |   |   |-- fo
>             |   |   |-- html
>             |   |   `-- latex
>             |   `-- p5
>             |       |-- common
>             |       |-- fo
>             |       |-- html
>             |       `-- latex
>             |-- odds
>             |-- slides
>             `-- teic

Obviously, you're the stylesheet dude, you organize these as you see
fit. But I'm awfully curious ... why is it that odds/, slides/, and
teic/ are at the root level, and are not each split up into p4/ and
p5? (OK, I understand odds/ not being split, as those stylesheets
have nothing to do with the P4 ODD language; but one can write slides
in P4 or P5, no? We have hundreds of P4 files and dozens of P5 files
on the tei-c website, no?)

Note
----
[1] For those who did not get a copy of my 2003-10-12 mail to the
    Debian-layout-designers, here's what it said:

        Since P4 is inextricably tied to DTDs, and no instance can be
        TEI P4 conformant unless it has a DOCTYPE declaration that
        points to a DTD (and it's valid against that DTD), I would
        say that schemas for P4 in languages other than DTD should
        not be provided.

From Syd_Bauman at Brown.edu  Sat Jul  2 20:15:22 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 2 Jul 2005 20:15:22 -0400
Subject: [tei-council] some reports in
Message-ID: <17095.11802.296394.473670@emt.wwp.brown.edu>

Julia's review of Chapter 9, base prose for verse, is now available at
http://www.tei-c.org/Council/ChapterReviews/VE.xml?style=printable.
BTW, don't blame Julia for it's being a day later than promised. She
sent it to me & Susan to put up on Thu, it was my confusion that
caused the delay.

My first cut at attributes and datatypes is available at 
http://www.tei-c.org/Drafts/edw90.xml?style=printable. I'm afraid the
database of devilish details I had hoped to have ready for you is not
quite up to snuff. You can see an out-of-date version (link is in the
paper), but it's just too painful to make the current stuff live
right now. Hopefully in two or three days.

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul  3 06:42:11 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 03 Jul 2005 11:42:11 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <17095.5940.562704.110577@emt.wwp.brown.edu>
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
	<17095.5940.562704.110577@emt.wwp.brown.edu>
Message-ID: <42C7C103.5070409@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>Does SyncRO Soft need to know the layout of the doc/ hierarchy?
>
they need the skeleton files, which I currently have in doc

>I understand what's in doc/tei/P4/Figures
>
i need to look at this again

>What is in skeletons/?
>
exemplars

> What are web/ and web/Query? (Which I don't
>have.) 
>  
>
the material for eXist connection

>
>  
>
>>`-- xml
>>    `-- tei
>>        |-- odd
>>    
>>
>
>Perhaps this directory should be called /xml/tei/src/ instead?
>
could be

> And
>shouldn't there be a p5/ child of this directory?
>
yes, I agree now that you mention it

>
>
>My objection to there being RelaxNG schema for P4 still holds.[1]
>  
>
its just tei lite....

-- 
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 Jul  3 08:11:56 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 03 Jul 2005 13:11:56 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C70F92.3080708@computing-services.oxford.ac.uk>
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
Message-ID: <42C7D60C.1030809@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> How should the HTML guidelines relate to
> the skeletons?
> what should the "skeletons" be called? where is the documentation for
> these exemplars?

For the record, I view 'skeletons' and 'exemplars' as completely 
different things.  The skeleton gives you an empty skeleton framework 
for starting a particular type of document quickly, whereas an 
exemplar acts as a detailed example with text demonstrating and 
explaining particular markup solutions.

> should I use "p4" or "P4" consistently?

Yes.  That is, it should be consistent, whichever is more official?

On the below:  Although I'm used to the way the debian packages are 
structured at the moment.  Should the rational be to divide by 
aspect(?) and then by version, or by version and then aspect of the TEI.

So: TEI -- P4-- Guidelines
      |      |-- Skeletons
      |
      |----P5 -- Guidelines
            |-- Skeletons

or
    TEI -- Guidelines -- P4
      |           |------P5
      |
      | -- Skeletons -- P4
                  | --- P5

In comparing the Doc tree and the schema and stylesheet tree don't we 
seem to be mixing and matching both of these two types of layout?

(i.e. p4/common p5/common etc.)

I'm assuming that keeping the versions entirely separate is beneficial 
in terms of version control, thus perhaps it should be 
doc/tei/p4/skeletons and xml/tei/p4/odd|schema|stylesheet and 
xml/tei/p5/odd|schema|stylesheet

Just my two pence after staying up too late watching Live8.

-James

> 
> share
> |-- doc
> |   `-- tei
> |       |-- P4
> |       |   `-- Figures
> |       |-- P5
> |       |-- Pictures
> |       |-- skeletons
> |       |   |-- p4
> |       |   `-- p5
> |       `-- web
> |           `-- Query
> `-- xml
>     `-- tei
>         |-- odd
>         |-- schema
>         |   |-- dtd
>         |   |   |-- p4
>         |   |   `-- p5
>         |   |-- relaxng
>         |   |   |-- p4
>         |   |   `-- p5
>         |   `-- xsd
>         |       `-- p5
>         `-- stylesheet
>             |-- base
>             |   |-- p4
>             |   |   |-- common
>             |   |   |-- fo
>             |   |   |-- html
>             |   |   `-- latex
>             |   `-- p5
>             |       |-- common
>             |       |-- fo
>             |       |-- html
>             |       `-- latex
>             |-- odds
>             |-- slides
>             `-- teic
> 
> 38 directories
> 

From Syd_Bauman at Brown.edu  Sun Jul  3 11:46:07 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 3 Jul 2005 11:46:07 -0400
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C7C103.5070409@computing-services.oxford.ac.uk>
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
	<17095.5940.562704.110577@emt.wwp.brown.edu>
	<42C7C103.5070409@computing-services.oxford.ac.uk>
Message-ID: <17096.2111.324392.413116@emt.wwp.brown.edu>

Sebastian Rahtz writes:

> they need the skeleton files, which I currently have in doc

Ah, right.

> >What is in skeletons/?
> exemplars

Hmmm... not that it's a big deal, in part because there aren't that
many places to look for such things, but an exemplar is typically
more than a skeleton. Any reason not to either
a) put skeletons in there, or
b) call the directory "exemplars/" or "examples/"?

> the material for eXist connection

Is this going to SyncRO Soft, too?

> >My objection to there being RelaxNG schema for P4 still holds.[1]
> >
> its just tei lite....

I was under the impression that we were agreed that customizations
would not go in the general xml/schema/[language]/[release]/
directory. I'm very confident we agreed they would not be in the same
Debian package. In either case, I have concerns about the idea of
putting only TEI Lite (or any other particular customizations, for
that matter) in a directory that is parallel to one that has the
entire set of TEI schema files. At the very least it seems that would
be quite confusing to users.

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul  3 12:49:29 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 03 Jul 2005 17:49:29 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C7D60C.1030809@computing-services.oxford.ac.uk>
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
	<42C7D60C.1030809@computing-services.oxford.ac.uk>
Message-ID: <42C81719.8010206@computing-services.oxford.ac.uk>

James Cummings wrote:

>
> For the record, I view 'skeletons' and 'exemplars' as completely
> different things.  The skeleton gives you an empty skeleton framework
> for starting a particular type of document quickly, whereas an
> exemplar acts as a detailed example with text demonstrating and
> explaining particular markup solutions.

ah. I blame Lou, he told me to use the word "exemplar". you want me to
revert to "skeletons"?

>
>> should I use "p4" or "P4" consistently?
>
>
> Yes.  That is, it should be consistent, whichever is more official?

I think the system from which we are starting, the Debian standards,
would seldom
use uppercase, so probably should be "p4" passim

>
>
> On the below:  Although I'm used to the way the debian packages are
> structured at the moment.  Should the rational be to divide by
> aspect(?) and then by version, or by version and then aspect of the TEI.

the Debian agreement seemed to be to do aspect/version.

>
> In comparing the Doc tree and the schema and stylesheet tree don't we
> seem to be mixing and matching both of these two types of layout?

hmm. you are probably right. they should be the same

I am reluctant to switch the stylesheets again, though.

ugh

-- 
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 computing-services.oxford.ac.uk  Sun Jul  3 12:53:30 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 03 Jul 2005 17:53:30 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <17096.2111.324392.413116@emt.wwp.brown.edu>
References: <42C70F92.3080708@computing-services.oxford.ac.uk>	<17095.5940.562704.110577@emt.wwp.brown.edu>	<42C7C103.5070409@computing-services.oxford.ac.uk>
	<17096.2111.324392.413116@emt.wwp.brown.edu>
Message-ID: <42C8180A.2070008@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>
>Any reason not to either
>a) put skeletons in there, or
>b) call the directory "exemplars/" or "examples/"?
>  
>
I don't have strong feelings about the name. And I am ambivalent
over whether it comes under "doc" or "xm". I sort of incline to the latter
now...

>
>  
>
>>the material for eXist connection
>>    
>>
>
>Is this going to SyncRO Soft, too?
>  
>
no.

>
>I was under the impression that we were agreed that customizations
>would not go in the general xml/schema/[language]/[release]/
>directory.
>
where do they go, then?

> I'm very confident we agreed they would not be in the same
>Debian package.
>
yes, sure. but thats another issue. this tree represents
an amalgamation of lots of files

> In either case, I have concerns about the idea of
>putting only TEI Lite (or any other particular customizations, for
>that matter) in a directory that is parallel to one that has the
>entire set of TEI schema files. At the very least it seems that would
>be quite confusing to users.
>  
>
I see the concern. what do you suggest?

-- 
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 Jul  3 13:08:55 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 03 Jul 2005 18:08:55 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C81719.8010206@computing-services.oxford.ac.uk>
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
	<42C7D60C.1030809@computing-services.oxford.ac.uk>
	<42C81719.8010206@computing-services.oxford.ac.uk>
Message-ID: <42C81BA7.3090509@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> James Cummings wrote:
> 
> 
>>For the record, I view 'skeletons' and 'exemplars' as completely
>>different things.  The skeleton gives you an empty skeleton framework
>>for starting a particular type of document quickly, whereas an
>>exemplar acts as a detailed example with text demonstrating and
>>explaining particular markup solutions.
> 
> 
> ah. I blame Lou, he told me to use the word "exemplar". you want me to
> revert to "skeletons"?

Well, as long as we are consistent, I don't mind terribly.  It might 
be good to have a collection of actual exemplars or examples.    I.e. 
throughout the Guidelines we have examples of use.  Now usually those 
examples are clearly defined demonstrations of the elements under 
discussion, but often involving all sorts of other elements. Should we 
have (or is there) an easy way to get some sort of index of examples? 
  (i.e. Show me all the examples using  or ).  Would that 
be helpful to users, or am I off my rocker?

-James

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul  3 18:39:41 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 03 Jul 2005 23:39:41 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C81BA7.3090509@computing-services.oxford.ac.uk>
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
	<42C7D60C.1030809@computing-services.oxford.ac.uk>
	<42C81719.8010206@computing-services.oxford.ac.uk>
	<42C81BA7.3090509@computing-services.oxford.ac.uk>
Message-ID: <42C8692D.2040002@computing-services.oxford.ac.uk>

I have revised my proposal, with the results appended

I have not changed the XSL layout, as it has a fair few ramifications
for me to clean up.

share
|-- doc
|   `-- tei
|       |-- html
|       |   |-- base
|       |   |   |-- p4
|       |   |   |   `-- Figures
|       |   |   `-- p5
|       |   `-- exemplars
|       |       `-- p5
|       |-- web
|       |   `-- Query
|       `-- xml
|           `-- exemplars
|               `-- p5
`-- xml
    `-- tei
        |-- odd
        |   `-- exemplars
        |       |-- p4
        |       `-- p5
        |-- schema
        |   |-- dtd
        |   |   |-- p4
        |   |   `-- p5
        |   |-- relaxng
        |   |   |-- p4
        |   |   `-- p5
        |   `-- xsd
        |       `-- p5
        `-- stylesheet
            |-- base
            |   |-- p4
            |   |   |-- common
            |   |   |-- fo
            |   |   |-- html
            |   |   `-- latex
            |   `-- p5
            |       |-- common
            |       |-- fo
            |       |-- html
            |       `-- latex
            |-- odds
            |-- slides
            `-- teic

44 directories

-- 
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 computing-services.oxford.ac.uk  Sun Jul  3 18:49:05 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 03 Jul 2005 23:49:05 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C81BA7.3090509@computing-services.oxford.ac.uk>
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
	<42C7D60C.1030809@computing-services.oxford.ac.uk>
	<42C81719.8010206@computing-services.oxford.ac.uk>
	<42C81BA7.3090509@computing-services.oxford.ac.uk>
Message-ID: <42C86B61.5000909@computing-services.oxford.ac.uk>

James Cummings wrote:

> Should we have (or is there) an easy way to get some sort of index of
> examples?  (i.e. Show me all the examples using  or ). 
> Would that be helpful to users, or am I off my rocker?
>
>
apart for the examples which are not well-formed (not many of these at
all now), it would be easy
run a script over the rest and build an index. I can't recall off hand,
I don't think we currently
generate an anchor in the online system for examples, but it would be
trivial to do so.

of course, the entry for  would be huge....

do others want 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 wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Jul  3 19:03:22 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 04 Jul 2005 08:03:22 +0900
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C8692D.2040002@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Sun, 03 Jul 2005 23:39:41 +0100")
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
	<42C7D60C.1030809@computing-services.oxford.ac.uk>
	<42C81719.8010206@computing-services.oxford.ac.uk>
	<42C81BA7.3090509@computing-services.oxford.ac.uk>
	<42C8692D.2040002@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

> I have revised my proposal, with the results appended
>
> I have not changed the XSL layout, as it has a fair few ramifications
> for me to clean up.

Hmm.  Now the exemplars are scattered all over the place, which will
make it difficult to get a coherent view of them... Honestly, I would
see them as part of the documentation (documenting different aspects)
and thus would prefer to see them in one tree under doc/tei/examplars.

On a slightly different note, where are users supposed to put the
stuff they get from Roma?  At least for oXygen, that should also fit
into the overall framework, shouldnt it? 

All the best,

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  Sun Jul  3 21:33:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 3 Jul 2005 21:33:11 -0400
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C7D60C.1030809@computing-services.oxford.ac.uk>
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
	<42C7D60C.1030809@computing-services.oxford.ac.uk>
Message-ID: <17096.37335.871356.300761@emt.wwp.brown.edu>

James Cummings writes:

> Yes. That is, it should be consistent, whichever is more official?

I think "P" is more official, but the reason may be a poor one --
that back in the old days one or both editors used a system that
didn't permit lowercase letters in filenames. For use in the Debian
world I think standardizing on "p" is probably the better way to go. 

> On the below: Although I'm used to the way the debian packages
> are structured at the moment. Should the rational be to divide by
> aspect(?) and then by version, or by version and then aspect of
> the TEI.

I think there's a lot to be said for version then aspect, but at
least as far as the /usr/share/xml/tei/ tree is concerned, I don't
think we really have a choice in that Debian already has a pretty
firm plan for where things should go, and we don't want to be the odd
man out.

You are right, though, it does appear a little inconsistent. 

More on this soon; I just noted that more mail on this thread has
arrived.

From Syd_Bauman at Brown.edu  Sun Jul  3 21:52:53 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 3 Jul 2005 21:52:53 -0400
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C8692D.2040002@computing-services.oxford.ac.uk>
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
	<42C7D60C.1030809@computing-services.oxford.ac.uk>
	<42C81719.8010206@computing-services.oxford.ac.uk>
	<42C81BA7.3090509@computing-services.oxford.ac.uk>
	<42C8692D.2040002@computing-services.oxford.ac.uk>
Message-ID: <17096.38517.295386.134376@emt.wwp.brown.edu>

Where in this proposal do the ODD source files to P5 go, if at all?
Into /usr/share/xml/tei/odd/? (Which, in the oXygen world, will be
../oxygen/frameworks/tei/odd/.)

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Jul  4 02:32:02 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 04 Jul 2005 07:32:02 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: 
References: <42C70F92.3080708@computing-services.oxford.ac.uk>	<42C7D60C.1030809@computing-services.oxford.ac.uk>	<42C81719.8010206@computing-services.oxford.ac.uk>	<42C81BA7.3090509@computing-services.oxford.ac.uk>	<42C8692D.2040002@computing-services.oxford.ac.uk>

Message-ID: <42C8D7E2.5080008@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>
>
>Hmm.  Now the exemplars are scattered all over the place, which will
>make it difficult to get a coherent view of them...
>
but thats inevitable, surely? the runtime files, the documentation (two
forms),
and the source don't belong in the same tree, once you start down the
Linux-like route.

> Honestly, I would
>see them as part of the documentation (documenting different aspects)
>and thus would prefer to see them in one tree under doc/tei/examplars.
>  
>
but they are also runtime files (schemas). which I currently
put under schema/relaxng/p5, but now I see that it does not
seem quite right

its difficult to reconcile the "debian package" view, which
has no problem with all the files in one directory, because the
package metadata discriminates, and the "human" view
which wants to put files in lots of small directories so that they
can be more easily moved around

>On a slightly different note, where are users supposed to put the
>stuff they get from Roma?  At least for oXygen, that should also fit
>into the overall framework, shouldnt it? 
>  
>
either
   share/tei/xml/schema/relaxng/p5/local
or
   share/tei/xml/schema/relaxng/local
I am not sure which. Is it subsidiary to p5
or in parallel?

of course, many people on Linux won't have access to that tree
at all.

-- 
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 computing-services.oxford.ac.uk  Mon Jul  4 02:33:41 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 04 Jul 2005 07:33:41 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <17096.38517.295386.134376@emt.wwp.brown.edu>
References: <42C70F92.3080708@computing-services.oxford.ac.uk>	<42C7D60C.1030809@computing-services.oxford.ac.uk>	<42C81719.8010206@computing-services.oxford.ac.uk>	<42C81BA7.3090509@computing-services.oxford.ac.uk>	<42C8692D.2040002@computing-services.oxford.ac.uk>
	<17096.38517.295386.134376@emt.wwp.brown.edu>
Message-ID: <42C8D845.10706@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>Where in this proposal do the ODD source files to P5 go, if at all?
>Into /usr/share/xml/tei/odd/? (Which, in the oXygen world, will be
>../oxygen/frameworks/tei/odd/.)
>
>  
>
share/xml/tei/odd/base/p5

-- 
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 Jul  4 03:26:48 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 04 Jul 2005 16:26:48 +0900
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C8D7E2.5080008@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Mon, 04 Jul 2005 07:32:02 +0100")
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
	<42C7D60C.1030809@computing-services.oxford.ac.uk>
	<42C81719.8010206@computing-services.oxford.ac.uk>
	<42C81BA7.3090509@computing-services.oxford.ac.uk>
	<42C8692D.2040002@computing-services.oxford.ac.uk>

	<42C8D7E2.5080008@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

> Christian Wittern wrote:
>
>>
>>
>>Hmm.  Now the exemplars are scattered all over the place, which will
>>make it difficult to get a coherent view of them...
>>
> but thats inevitable, surely? the runtime files, the documentation (two
> forms),
> and the source don't belong in the same tree, once you start down the
> Linux-like route.
>
>> Honestly, I would
>>see them as part of the documentation (documenting different aspects)
>>and thus would prefer to see them in one tree under doc/tei/examplars.
>>  
>>
> but they are also runtime files (schemas). which I currently
> put under schema/relaxng/p5, but now I see that it does not
> seem quite right
>
> its difficult to reconcile the "debian package" view, which
> has no problem with all the files in one directory, because the
> package metadata discriminates, and the "human" view
> which wants to put files in lots of small directories so that they
> can be more easily moved around

On Debian, you could at least use symlinks from somewhere in the doc
substree to all these other places.  But maybe I am just being
stubborn and this is not needed at all... 
>
>>On a slightly different note, where are users supposed to put the
>>stuff they get from Roma?  At least for oXygen, that should also fit
>>into the overall framework, shouldnt it? 
>>  
>>
> either
>    share/tei/xml/schema/relaxng/p5/local
> or
>    share/tei/xml/schema/relaxng/local
> I am not sure which. Is it subsidiary to p5
> or in parallel?

Rather subsidiary, I would think.

>
> of course, many people on Linux won't have access to that tree
> at all.

Wouldnt it be rather

/usr/local/share/tei/xml/schema whatever

on these systems?

Anyway, I just wanted to be sure that we do have a "recommended
location", since that will probably make it easier to write tutorials,
software etc.

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 Jul  4 08:35:29 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 04 Jul 2005 21:35:29 +0900
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To:  (Christian Wittern's message of
	"Mon, 04 Jul 2005 16:26:48 +0900")
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
	<42C7D60C.1030809@computing-services.oxford.ac.uk>
	<42C81719.8010206@computing-services.oxford.ac.uk>
	<42C81BA7.3090509@computing-services.oxford.ac.uk>
	<42C8692D.2040002@computing-services.oxford.ac.uk>

	<42C8D7E2.5080008@computing-services.oxford.ac.uk>

Message-ID: 

Christian Wittern  writes:

>>>Hmm.  Now the exemplars are scattered all over the place, which will
>>>make it difficult to get a coherent view of them...
>>>
>> but thats inevitable, surely? the runtime files, the documentation (two
>> forms),
>> and the source don't belong in the same tree, once you start down the
>> Linux-like route.
>>
>>> Honestly, I would
>>>see them as part of the documentation (documenting different aspects)
>>>and thus would prefer to see them in one tree under doc/tei/examplars.
>>>  
>>>
>> but they are also runtime files (schemas). which I currently
>> put under schema/relaxng/p5, but now I see that it does not
>> seem quite right
>>
>> its difficult to reconcile the "debian package" view, which
>> has no problem with all the files in one directory, because the
>> package metadata discriminates, and the "human" view
>> which wants to put files in lots of small directories so that they
>> can be more easily moved around

Well yes, now that I have thought of this a bit more, I think a way
out of this would be to have a HTML page for each exemplar that
documents its use and links to the relevant files for the inspection
of the user.  What do you think, Sebastian?

Christian

-- 

 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From nsmith at email.unc.edu  Mon Jul  4 22:23:59 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Mon, 4 Jul 2005 22:23:59 -0400
Subject: [tei-council] ITS@W3C  (was:Re: roma, documentation, i18n)
References: <42BB332D.1040305@computing-services.oxford.ac.uk><42BBBD3D.3060003@computing-services.oxford.ac.uk><42BBD6E2.5040302@computing-services.oxford.ac.uk><42BEB054.2080705@computing-services.oxford.ac.uk><42BFB9C7.5020808@computing-services.oxford.ac.uk>

Message-ID: <065c01c58108$9a3170a0$6401a8c0@lib.unc.edu>

I fully support this move and hope we will be successful in forming a good
working relationship with W3C. And thank you to Sebastian for agreeing to
put effort - and time! - into it.

on the related topic and following-up the conversation of 5/23-5/24 about
the priority of languages. I agree with Christian that we might be more
interested in investing in regions/languages that are not yet covered to the
extent they should be - as they have real potential (ex., Japan, China,
Korea.) But I understand that the practicality and reality (I can start with
as simple as finding not just *a* translator, but a reliable one) might
change the priority list and its order.

Finally, I wanted to check what we already have on the site and remembering
that tei has been translated at some point to Russian, I did search and
discovered the following broken links on http://www.tei-c.org.uk/Lite/

http://www.tei-c.org.uk/Lite/teiu5_fr.tei

http://www.tei-c.org.uk/Lite/teiu5_zh.xsw

http://www.tei-c.org.uk/Lite/teiu5_kr.tei

http://www.tei-c.org.uk/Lite/teiu5_ru.rtf

also, in http://www.tei-c.org.uk/Software/ there is a link to TEI Tools by
Boris Tobotras that is password-protected:

http://xtalk.price.ru/SGML/TEItools/index-en.html

best, n

----- Original Message ----- 
From: "Christian Wittern" 
To: 
Sent: Monday, June 27, 2005 11:36 PM
Subject: [tei-council] ITS at W3C (was:Re: roma, documentation, i18n)

>
> Council members,
>
> As it happens, I had a long conversation with Felix Sasaki yesterday,
> who joined the W3C host in Japan this April and works there on i18n
> issues.  He mentioned work going on at the W3C at the ITS
> (Internationalization Tag Set,
> cf. http://www.w3.org/International/its/) group, which seems to have
> some overlap with our problem here. The mission statement for the
> group is as follows:
> 
> Mission: Develop a set of elements and attributes that can be used
> with new DTDs/Schemas to support the internationalization and
> localization of documents; and provide best practice techniques for
> developers of DTDs/Schemas that show how to enable
> internationalization of their documents.
> 
>
> They are not ready and it might be overkill, but it seems to me that
> we should monitor this.
>
> He asked also if somebody from the TEI would be interested to join
> this group; we also discussed if the TEI could/should consider to
> enter into some formal relation with the W3C.  I would be interested
> in opinions from the Council members on the desirability of such a
> development.
>
> Sebastian Rahtz  writes:
>
> > Christian Wittern wrote:
> >
> >>What would be the advantage of pulling this into the main P5 source?
> >>I see only added maintainance cost with no real benefit.  You could as
> >>easily pull them out and merge them into the tree on runtime.
> >>
> >>
> > perhaps its matter of semantics; if the main ODD processing
> > software expects to find the various language-specific s
> > in site in the main document, then it does not much matter whether
> > the merge is at runtime or at source. I just want to avoid a "normal"
> > ODD processor from having to know about the language modules.
> >
> >>>dont forget attributes, and vallists, by the way
>
> >>But attributes should be covered within the elementSpec, shouldnt
> >>they.
> >>
> > and the classSpecs.
>
> -- 
>  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 nsmith at email.unc.edu  Mon Jul  4 22:36:03 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Mon, 4 Jul 2005 22:36:03 -0400
Subject: [tei-council] [AIR] action item report: Epigraphical encoding 
References: 
Message-ID: <068201c5810a$49b08b50$6401a8c0@lib.unc.edu>

Christian:

just wanted to add one cent to your report - it happened that I talked to
Hugh Cayless (one of the initial developers of EpiDoc and a really great
guy - he might a wonderful source for you) and he mentioned that there is a
wiki set-up, but not open to the public, at least yet. And as far as i
understand the most active developer at the moment is Gabriel Bodard, at
Kings (?)

n

----- Original Message ----- 
From: "Christian Wittern" 
To: 
Sent: Thursday, June 30, 2005 1:40 AM
Subject: [tei-council] [AIR] action item report: Epigraphical encoding

>
> Dear Council members,
>
> This is a report about my follow up to section 8.4 of the minutes at
> http://www.tei-c.org.uk/Council/tcm17.xml?style=printable
>
> I have been looking around to see what people in the epigraphical
> field been doing.  Elli Mylonas pointed me to a number of ressources,
> among other things the EpiDoc group and a mailing list, both run by
> Tom Elliot.  He responded today, after more than a month, that he will
> be following up soon.
>
> I looked briefly at EpiDoc, which looks like it could use a lot of
> work. On the upside, they came up with Guidelines of their own for
> their user community and some stylesheets to get things going.
> Development seems to be rather slow.   I will work further with them
> and will see if a common base for further development can be found.
> There are some projects, most notably the Aphrodisias project at Kings
> College etc.
>
> 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
>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Jul  5 00:58:18 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 05 Jul 2005 13:58:18 +0900
Subject: [tei-council] [AIR] action item report: Epigraphical encoding
In-Reply-To: <068201c5810a$49b08b50$6401a8c0@lib.unc.edu> (Natasha Smith's
	message of "Mon, 4 Jul 2005 22:36:03 -0400")
References: 
	<068201c5810a$49b08b50$6401a8c0@lib.unc.edu>
Message-ID: 

"Natasha Smith"  writes:

> Christian:
>
> just wanted to add one cent to your report - it happened that I talked to
> Hugh Cayless (one of the initial developers of EpiDoc and a really great
> guy - he might a wonderful source for you) and he mentioned that there is a
> wiki set-up, but not open to the public, at least yet. And as far as i
> understand the most active developer at the moment is Gabriel Bodard, at
> Kings (?)

Natasha, thank you for this information.  I will follow up on this.

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 Jul  5 01:13:45 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 05 Jul 2005 14:13:45 +0900
Subject: [tei-council] some reports in
In-Reply-To: <17095.11802.296394.473670@emt.wwp.brown.edu> (Syd Bauman's
	message of "Sat, 2 Jul 2005 20:15:22 -0400")
References: <17095.11802.296394.473670@emt.wwp.brown.edu>
Message-ID: 

Syd Bauman  writes:

> Julia's review of Chapter 9, base prose for verse, is now available at
> http://www.tei-c.org/Council/ChapterReviews/VE.xml?style=printable.
> BTW, don't blame Julia for it's being a day later than promised. She
> sent it to me & Susan to put up on Thu, it was my confusion that
> caused the delay.

Now that tei-c.org is up again, we can even get it from the US source.

Thanks to Julia for very useful suggestions in improving the chapter.

For the purpose of discussion, I will paste Julia's document in here
and add my comments:

JF>1. Fixes
JF>1.1. Make  legal within 

JF>
JF>Research by both the Women Writers Project and the Menota Project
JF>indicates that there are cases where passages of verse appear directly
JF>within the flow of prose, embedded within a paragraph, and not
JF>enclosed within a quotation. Examples include cases where the text
JF>shifts from verse to prose in mid-sentence (as in Nordic prosimetrum
JF>texts; see ?Document Structure? in The Menota Handbook) or where a
JF>speaker in a fictional context begins to compose poetry orally in the
JF>middle of a speech.

Agreed.  I have stumbled over this one a number of times. This should be fixed.

JF>
JF>1.2. Eliminate numbered 
JF>
JF>On same basis as eliminating numbered 
.

Do we get rid of the latter?  Even if not, I am all in favor of
eliminating enumerated .

JF>2. Expansions
JF>2.1. Add attributes
JF>
JF>The Henrik Ibsen project has extended the TEI to add the following attributes to the a.metrical class:
JF>
JF>    * met and realMet : for identifying the ideal and real metrical scheme for the line or line group
JF>    * rhyme and realRhyme : for identifying the ideal and real rhyme scheme for the line group
JF>    * an and realAn : for identifying ideal and real patterns of
JF>    anacruses (unstressed syllables preceding the first stressed
JF>    syllable in a line) for a line or line group
JF>
JF>
JF>The Ibsen project leaves the original TEI real attribute untouched,
JF>but this new scheme renders it redundant (replacing it with
JF>realMet). Of these three attribute pairs, probably the first two are
JF>most generally useful to the TEI community; we have asked the Ibsen
JF>group to give a more detailed rationale for an and realAn, which seem
JF>to replicate the same kind of information as met and realMet.

We should probably consider this in the context of the discussion of
all the other attributes.

JF>
JF>
JF>The Ibsen project defines these as CDATA attributes...
JF>2.2. Stressed vowels
JF>
JF>David Birnbaum mentioned that in his poetry markup he needs to mark
JF>stressed vowels, in addition to the ordinary metrical information for
JF>the line. He suggests a  element, but has not yet elaborated
JF>on this suggestion. We've requested further information from him on
JF>this point.

I wonder how that would be used.  Would you do something like
here 

JF>
JF>
JF>3. Clarifications and discussion
JF>3.1. Verse and overlap
JF>
JF>Martin Mueller suggested that we add a section to the verse chapter
JF>that explicitly addresses overlap in the context of verse, since the
JF>presence of verse lines heightens the likelihood of routine overlap
JF>problems that also occur elsewhere. At present, overlap is discussed
JF>only as a byproduct of segmentation (e.g. to capture part-lines and
JF>encoding of metrical feet). If it were instead broken out into a
JF>subsection of its own, we could also:
JF>
JF>
JF>    * discuss the fact that verse by its nature is more likely to incur overlap problems;
JF>    * point out a few of the most likely overlap issues (encoding of
JF>    quotations and sentences, but also thematic tagging if that is
JF>    present);
JF>
JF>    * list the most common ways of handling these situations
JF>    (fragmentation of quotations using next and prev; the possibility
JF>    of using part on elements other than ; use of milestone
JF>    elements for things like sentence boundaries
JF>
JF>
JF>For some parts of this we might just point to elsewhere in the
JF>Guidelines, but the pointers should be there so that people are aware
JF>of the issues and their solution.

This looks like a useful addition to the chapter to me.  

>
> My first cut at attributes and datatypes is available at 
> http://www.tei-c.org/Drafts/edw90.xml?style=printable. I'm afraid the
> database of devilish details I had hoped to have ready for you is not
> quite up to snuff. You can see an out-of-date version (link is in the
> paper), but it's just too painful to make the current stuff live
> right now. Hopefully in two or three days.

Thanks Syd!

There is a link to your harddisk in that paper (for the W3C regex),
but the php link now seems to be live now, right.

>
> _______________________________________________
> 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 pwillett at umich.edu  Tue Jul  5 08:12:09 2005
From: pwillett at umich.edu (Perry Willett)
Date: Tue, 5 Jul 2005 08:12:09 -0400
Subject: [tei-council] some reports in
In-Reply-To: 
Message-ID: <000c01c5815a$c776f970$922bd38d@CLUBSODA>

I also agree with the proposal to eliminate numbered lgs, but I don't recall
ever agreeing to give up numbered divs. I would argue strongly in favor of
keeping them.

Perry Willett
University of Michigan
pwillett at umich.edu

-----Original Message-----
JF>
JF>1.2. Eliminate numbered 
JF>
JF>On same basis as eliminating numbered .

Do we get rid of the latter?  Even if not, I am all in favor of
eliminating enumerated .

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jul  5 08:22:07 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 05 Jul 2005 13:22:07 +0100
Subject: [tei-council] some reports in
In-Reply-To: <000c01c5815a$c776f970$922bd38d@CLUBSODA>
References: <000c01c5815a$c776f970$922bd38d@CLUBSODA>
Message-ID: <42CA7B6F.50803@computing-services.oxford.ac.uk>

Perry Willett wrote:

>I also agree with the proposal to eliminate numbered lgs, but I don't recall
>ever agreeing to give up numbered divs. I would argue strongly in favor of
>keeping them.
>  
>

why are numbered divs ok but numbered lgs not?

I too don't recall the subject being discussed formally.

sebastian

From Syd_Bauman at Brown.edu  Tue Jul  5 08:28:37 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 5 Jul 2005 08:28:37 -0400
Subject: [tei-council] some reports in
In-Reply-To: 
References: <17095.11802.296394.473670@emt.wwp.brown.edu>

Message-ID: <17098.31989.406811.774447@emt.wwp.brown.edu>

> There is a link to your harddisk in that paper (for the W3C regex),

Whoa! Thank you. Fixed. (At least on UVA site; I can't sync UK
mirror.)

> but the php link now seems to be live now, right.

Not quite; it is a live, working link, but to old dead data -- well,
not dead, but 2 days out of date, with at least a dozen errors. I
hope to have a fixed version up shortly (measured in hours, not days)
which will be "live", in that if I make any corrections from that
point on I would make them in MySQL, and you'd see the correction
immediately.

From pwillett at umich.edu  Tue Jul  5 08:32:43 2005
From: pwillett at umich.edu (Perry Willett)
Date: Tue, 5 Jul 2005 08:32:43 -0400
Subject: [tei-council] some reports in
In-Reply-To: <42CA7B6F.50803@computing-services.oxford.ac.uk>
Message-ID: <000e01c5815d$a7060b60$922bd38d@CLUBSODA>

I've never encountered a need to nest s. 

Perry

-----Original Message-----
From: Sebastian Rahtz
[mailto:sebastian.rahtz at computing-services.oxford.ac.uk] 
Sent: Tuesday, July 05, 2005 8:22 AM
To: Perry Willett
Cc: 'TEI Council'
Subject: Re: [tei-council] some reports in

Perry Willett wrote:

>I also agree with the proposal to eliminate numbered lgs, but I don't
recall
>ever agreeing to give up numbered divs. I would argue strongly in favor of
>keeping them.
>  
>

why are numbered divs ok but numbered lgs not?

I too don't recall the subject being discussed formally.

sebastian

From Syd_Bauman at Brown.edu  Tue Jul  5 08:34:07 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 5 Jul 2005 08:34:07 -0400
Subject: [tei-council] some reports in
In-Reply-To: <000c01c5815a$c776f970$922bd38d@CLUBSODA>
References: 
	<000c01c5815a$c776f970$922bd38d@CLUBSODA>
Message-ID: <17098.32319.737813.600607@emt.wwp.brown.edu>

> I also agree with the proposal to eliminate numbered lgs, but I
> don't recall ever agreeing to give up numbered divs. I would argue
> strongly in favor of keeping them.

I believe (although I could be mistaken) that Julia meant that the
argument for dropping numbered s is parrallel to the argument for
dropping numbered s, and thus need not be repeated in her paper.
(Rather than that we have already decided to drop numbered s,
which to my knowledge we have discussed briefly but never even
seriously considered, let alone decided).

She should be back from her trip sometime on Wed, so if I'm wrong
she'll hopefully be able to correct me before the conference call.

From nsmith at email.unc.edu  Tue Jul  5 08:44:26 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Tue, 5 Jul 2005 08:44:26 -0400 (Eastern Daylight Time)
Subject: [tei-council] some reports in
In-Reply-To: <000c01c5815a$c776f970$922bd38d@CLUBSODA>
Message-ID: 

> I also agree with the proposal to eliminate numbered lgs, but I don't recall
> ever agreeing to give up numbered divs. I would argue strongly in favor of
> keeping them.

I join Perry on both issues, i.e. in favor of eliminating numbered s
and *keeping* numbered s. I consider it's very important that the
latter was also supported by the "TEI in the Libraries" group that - FYI -
is revived as we speak.

n

> -----Original Message-----
> JF>
> JF>1.2. Eliminate numbered 
> JF>
> JF>On same basis as eliminating numbered .
> 
> Do we get rid of the latter?  Even if not, I am all in favor of
> eliminating enumerated .
> 
> 
> 
> _______________________________________________
> 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  Tue Jul  5 08:43:52 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Tue, 5 Jul 2005 14:43:52 +0200
Subject: [tei-council] some reports in
In-Reply-To: <17098.32319.737813.600607@emt.wwp.brown.edu>
References: 
	<000c01c5815a$c776f970$922bd38d@CLUBSODA>
	<17098.32319.737813.600607@emt.wwp.brown.edu>
Message-ID: 

I would strongly suggest to decouple the two arguments (i.e. numbered 
lgs vs. numbered divs). There are quite a few projects (comprising the 
TEI spec in ODD itself) that are using numbered divs as opposed to very 
few occurances of numbered lgs. As a consequence, I see it an easy 
decision to drop numbered lgs, but (even if I do not like numbered 
divs) would be more coutious in taking a similar decisions for 
divisions.
Laurent

Le 5 juil. 05, ? 14:34, Syd Bauman a ?crit :

>> I also agree with the proposal to eliminate numbered lgs, but I
>> don't recall ever agreeing to give up numbered divs. I would argue
>> strongly in favor of keeping them.
>
> I believe (although I could be mistaken) that Julia meant that the
> argument for dropping numbered s is parrallel to the argument for
> dropping numbered s, and thus need not be repeated in her paper.
> (Rather than that we have already decided to drop numbered s,
> which to my knowledge we have discussed briefly but never even
> seriously considered, let alone decided).
>
> She should be back from her trip sometime on Wed, so if I'm wrong
> she'll hopefully be able to correct me before the conference call.
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jul  5 09:10:23 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 05 Jul 2005 14:10:23 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: 
References: <42C70F92.3080708@computing-services.oxford.ac.uk>	<42C7D60C.1030809@computing-services.oxford.ac.uk>	<42C81719.8010206@computing-services.oxford.ac.uk>	<42C81BA7.3090509@computing-services.oxford.ac.uk>	<42C8692D.2040002@computing-services.oxford.ac.uk>		<42C8D7E2.5080008@computing-services.oxford.ac.uk>

Message-ID: <42CA86BF.9080901@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>
>On Debian, you could at least use symlinks from somewhere in the doc
>substree to all these other places. 
>
symlinks are such a pain for portability, though

>
>
>Wouldnt it be rather
>
>/usr/local/share/tei/xml/schema whatever
>
>on these systems?
>  
>
yes, probably. we only care about what's below "share", whether thats
/usr or /usr/local.

sebastian

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Jul  5 18:44:46 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 06 Jul 2005 07:44:46 +0900
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42C8692D.2040002@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Sun, 03 Jul 2005 23:39:41 +0100")
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
	<42C7D60C.1030809@computing-services.oxford.ac.uk>
	<42C81719.8010206@computing-services.oxford.ac.uk>
	<42C81BA7.3090509@computing-services.oxford.ac.uk>
	<42C8692D.2040002@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

> I have revised my proposal, with the results appended
>
> I have not changed the XSL layout, as it has a fair few ramifications
> for me to clean up.

Now that I have given up my reservations against the following
proposal -- and I have not seen any other objections so far -- I
wonder if we can agree on this structure?  I would like to see it used
in 
 * an archive downloadable from SF
 * a live location on the TEI websites and/or on the SF HTML area
 * included in XML editors like oXygen 
 * etc., etc.
Please think through this and voice any concerns now!

One issue that came to my mind is how to root it on Windows. C;/share/
looks a bit silly, so maybe we want c;/TEI/ for the root of the tree.
This does not matter for oXygen of course, but might be of concern to
generic installations. 

>
> share
> |-- doc
> |   `-- tei
> |       |-- html
> |       |   |-- base
> |       |   |   |-- p4
> |       |   |   |   `-- Figures
> |       |   |   `-- p5
> |       |   `-- exemplars
> |       |       `-- p5
> |       |-- web
> |       |   `-- Query
> |       `-- xml
> |           `-- exemplars
> |               `-- p5
> `-- xml
>     `-- tei
>         |-- odd
>         |   `-- exemplars
>         |       |-- p4
>         |       `-- p5
>         |-- schema
>         |   |-- dtd
>         |   |   |-- p4
>         |   |   `-- p5
>         |   |-- relaxng
>         |   |   |-- p4
>         |   |   `-- p5
>         |   `-- xsd
>         |       `-- p5
>         `-- stylesheet
>             |-- base
>             |   |-- p4
>             |   |   |-- common
>             |   |   |-- fo
>             |   |   |-- html
>             |   |   `-- latex
>             |   `-- p5
>             |       |-- common
>             |       |-- fo
>             |       |-- html
>             |       `-- latex
>             |-- odds
>             |-- slides
>             `-- teic
>
> 44 directories
>
>
> -- 
> 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

-- 
 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jul  5 18:02:50 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 05 Jul 2005 23:02:50 +0100
Subject: [tei-council] directory layout again
Message-ID: <42CB038A.9070603@computing-services.oxford.ac.uk>

After much agonizing, I am still unhappy with this directory layout for
the TEI, and
I want to propose a radical new direction. viz, split TEI P4 ("TEI
Classic") and
TEI P5 ("TEI Low Fat") into entirely separate, parallel, applications.
So, on a Linux system, you
might see

  /usr/share/xml/teiclassic
  /usr/share/xml/tei
  /usr/share/xml/docbook
  /usr/share/xml/xhtml

so there would be no "p4" or "p5" layers anywhere, you would just choose
a tree at the top level to work with. It simplifies lots of things, and
makes it
easier to document. I cannot think of a situation where we mingle P4 and P5.

What do folks think? I know the big problem is that only one thing can
be called "tei",
so either P4 or P5 gets a new name. I believe that P5 should get the
"tei" name, since
it is where we are working, and we have started on our 0.1 release.

-- 
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  Tue Jul  5 21:35:43 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 5 Jul 2005 21:35:43 -0400
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: 
References: <42C70F92.3080708@computing-services.oxford.ac.uk>
	<42C7D60C.1030809@computing-services.oxford.ac.uk>
	<42C81719.8010206@computing-services.oxford.ac.uk>
	<42C81BA7.3090509@computing-services.oxford.ac.uk>
	<42C8692D.2040002@computing-services.oxford.ac.uk>

Message-ID: <17099.13679.488888.552903@emt.wwp.brown.edu>

> Please think through this and voice any concerns now!

I'm thinking, but I probably will not get to post on this until late
tomorrow, at the earliest.

From Syd_Bauman at Brown.edu  Tue Jul  5 21:42:46 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 5 Jul 2005 21:42:46 -0400
Subject: [tei-council] directory layout again
In-Reply-To: <42CB038A.9070603@computing-services.oxford.ac.uk>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>
Message-ID: <17099.14102.247157.507822@emt.wwp.brown.edu>

I thought we'd already expressed this preference, and Mark Johnson
essentially nuked it, pointing out that all the other Debian XML
installations follow the /usr/share/[name]/schema/dtd/[versions]/
kind of pattern (most notably DocBook).

From Syd_Bauman at Brown.edu  Tue Jul  5 22:17:26 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 5 Jul 2005 22:17:26 -0400
Subject: [tei-council] attribute/datatype data updated
Message-ID: <17099.16182.187769.211850@emt.wwp.brown.edu>

The database of TEI attributes and their suggsted datatypes has been
updated. I fixed dozens of errors, but I have this knawing feeling
that I introduced a couple of new ones. :-)

In any case, follow the link to the PHP interface from ED W 90, which
has also been updated a teeny bit (on the UVA server, which seems to
be down again), and is at
  http://www.tei-c.org/Drafts/edw90.xml?style=printable
  http://www.tei-c.org.uk/Drafts/edw90.xml?style=printable

I think it is probably a bit much to ask every Council member to look
at all 541 entries before Fri morning. But every Council member
should certainly read ED W 90 (and feel free to ask questions on or
off list if there are parts you don't understand -- or to suggest
corrections to any explanations that are hard to understand, etc.)
and at least scan the database of attributes. Search for the
attributes you care about. Scan for "?"; sort the list by suggested
declaration and look for weird ones; look through those that are
declared as tei.data.code to see if there are any you think should be
tei.data.key or tei.data.enumerated; etc.

Perhaps later we should set up an actual review process.

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jul  6 00:55:19 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 06 Jul 2005 05:55:19 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <17099.14102.247157.507822@emt.wwp.brown.edu>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>
	<17099.14102.247157.507822@emt.wwp.brown.edu>
Message-ID: <42CB6437.6020502@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>I thought we'd already expressed this preference, and Mark Johnson
>essentially nuked it, pointing out that all the other Debian XML
>installations follow the /usr/share/[name]/schema/dtd/[versions]/
>kind of pattern (most notably DocBook).
>  
>
but on reading the Debian XML policy again, it says clearly
that you can NOT have versions of stylesheets.  so we break
their rules with what I proposed  a few days ago. and our p4/p5 are
not really _versions_ of the stylesheets

We could still
have [name]/schema/dtd/[version], but then it will be /0.1, /0.2 etc
though I'd suggest its not needed,

its possible that I could break up just the stylesheet tree into
top-level "tei" and "teiclassic", I suppose

-- 
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 computing-services.oxford.ac.uk  Wed Jul  6 01:05:23 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 06 Jul 2005 06:05:23 +0100
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: 
References: <42C70F92.3080708@computing-services.oxford.ac.uk>	<42C7D60C.1030809@computing-services.oxford.ac.uk>	<42C81719.8010206@computing-services.oxford.ac.uk>	<42C81BA7.3090509@computing-services.oxford.ac.uk>	<42C8692D.2040002@computing-services.oxford.ac.uk>

Message-ID: <42CB6693.1030704@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>One issue that came to my mind is how to root it on Windows. C;/share/
>looks a bit silly, so maybe we want c;/TEI/ for the root of the tree.
>This does not matter for oXygen of course, but might be of concern to
>generic installations. 
>  
>
I don't know much about Windows conventions, but c:\tei does not
look normal to me. Windows just doesn't create new stuff at the root,
does it?

someone who uses it might like to comment.

-- 
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 Jul  6 07:58:10 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 06 Jul 2005 20:58:10 +0900
Subject: [tei-council] Agenda for TEI Council conference call on Friday
 2005-07-08, 1300 UTC
Message-ID: 

TEI Council Members and Editors:

This is the agenda for the conference call the TEI Council will
hold Friday, July 8th, 2005 at 1300 UTC.

Please read through the following, in advance of the call.  

INSTRUCTIONS for conference call:

Participants will dial in to +1 812 856 3550.

When prompted, enter the code "0920" followed by "#".

Expected members to participate:

Syd Bauman, Alejandro Bia, Lou Burnard, James Cummings, Matthew
Driscoll, Julia Flanders, Sebastian Rahtz, Laurent Romary, Natasha
Smith, John Walsh, Perry Willett, Christian Wittern.

Susan Schreibman excused herself while en-route to Ireland,
Edward Vanhoutte is busy working on his thesis while we talk.

Agenda:

5 items, not more than 10-20 minutes apiece.

-----------------------------------------------------

1) Review of the minutes and action items (10 min)

   Minutes of the meeting are at
	 http://www.tei-c.org/Council/tcm17.html. 

	 To speed up the review of action items, *please report to the
	 council list* before the call! 

	 We will discuss the reports here as necessary.

------------------------------------------------------------

2) Review of WG etc. progress (10 min) : 

  Standoff Markup,  Feature Structures, Physical
  Bibliography, biblItem, IHS

	Same her, please do report to the list!

-----------------------------------------------------

3) P5 progress:  (20 min)

- principles for publication of snapshots etc. of P5
  Status: a proposal from Sebastian and subsequent discussion, we need to come
  to a decision.

- directory layout:  
	Status: several conflicting proposals. Hope we sort some of this out
	before the call.

- I18N infrastructure for translations of gloss and desc, vallists etc
  Status: some discussion, but no proposal yet - need to consider
  aligning with W3C ITS effort (I (CW) hope to have some news on this
  by Thursday JTS)

- on Attributes and Datatypes (EDW90)
	http://www.tei-c.org.uk/Drafts/edw90.xml?style=printable
	Please read through this and comment, preferably to the list.

-----------------------------------------------------

4) Other business  (5 minutes)

   TBA

-----------------------------------------------------

5) Meetings: (5 minutes)

   Next call, members meeting preparations.

-- 

 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From pwillett at umich.edu  Wed Jul  6 08:20:47 2005
From: pwillett at umich.edu (Perry Willett)
Date: Wed, 6 Jul 2005 08:20:47 -0400
Subject: [tei-council] directory layout of a TEI distribution
In-Reply-To: <42CB6693.1030704@computing-services.oxford.ac.uk>
Message-ID: <000301c58225$267b1ad0$922bd38d@CLUBSODA>

I'm no expert here, but I think the Windows convention is to install either
in "c:\Program Files" or "c:\Documents and Settings". Although not a
program, I would think the former is more appropriate. It's no problem to
install at root, however.

Perry

-----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: Wednesday, July 06, 2005 1:05 AM
To: Christian Wittern
Cc: TEI Council
Subject: Re: [tei-council] directory layout of a TEI distribution

Christian Wittern wrote:

>One issue that came to my mind is how to root it on Windows. C;/share/
>looks a bit silly, so maybe we want c;/TEI/ for the root of the tree.
>This does not matter for oXygen of course, but might be of concern to
>generic installations. 
>  
>
I don't know much about Windows conventions, but c:\tei does not
look normal to me. Windows just doesn't create new stuff at the root,
does it?

someone who uses it might like to comment.

-- 
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 mjd at hum.ku.dk  Wed Jul  6 09:02:01 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Wed, 06 Jul 2005 15:02:01 +0200
Subject: [tei-council] some reports in
In-Reply-To: <000e01c5815d$a7060b60$922bd38d@CLUBSODA>
References: <42CA7B6F.50803@computing-services.oxford.ac.uk>
Message-ID: <42CBF269.9756.151EAF5@localhost>

> I've never encountered a need to nest s. 
> 
> Perry

Just to this one point, I nest s all the time, for 
example where a stanza consists of two half-stanzas, as in 
skaldic poetry, or in carols and similar poetry where there 
is a burden or refrain, which is part of, but separate 
from, the verse to which it is attached. I never, on the 
other hand, use numbered s, or numbered s for that 
matter (having been told not to by a certain LB).

MJD

From pwillett at umich.edu  Wed Jul  6 10:33:01 2005
From: pwillett at umich.edu (Perry Willett)
Date: Wed, 6 Jul 2005 10:33:01 -0400
Subject: [tei-council] some reports in
In-Reply-To: <42CBF269.9756.151EAF5@localhost>
Message-ID: <000f01c58237$9fa26780$922bd38d@CLUBSODA>

Thanks, Matthew, I should have added that almost all of my encoding has been
from 19th century sources, which are about as conventional as you can get.

Perry

-----Original Message-----
From: tei-council-bounces at lists.village.Virginia.EDU
[mailto:tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of M. J.
Driscoll
Sent: Wednesday, July 06, 2005 9:02 AM
To: 'TEI Council'
Subject: RE: [tei-council] some reports in

> I've never encountered a need to nest s. 
> 
> Perry

Just to this one point, I nest s all the time, for 
example where a stanza consists of two half-stanzas, as in 
skaldic poetry, or in carols and similar poetry where there 
is a burden or refrain, which is part of, but separate 
from, the verse to which it is attached. I never, on the 
other hand, use numbered s, or numbered s for that 
matter (having been told not to by a certain LB).

MJD
_______________________________________________
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

From Julia_Flanders at Brown.edu  Wed Jul  6 14:59:57 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Wed, 6 Jul 2005 14:59:57 -0400
Subject: [tei-council] some reports in
In-Reply-To: <000e01c5815d$a7060b60$922bd38d@CLUBSODA>
References: <000e01c5815d$a7060b60$922bd38d@CLUBSODA>
Message-ID: 

Does this mean that if you did need to nest s you would want to 
have numbered ones available? I am aware of quite a number of 
projects that do nest  fairly extensively (none of which use 
numbered  ).

At 8:32 AM -0400 7/5/05, Perry Willett wrote:
>I've never encountered a need to nest s.
>
>Perry
>
>
>-----Original Message-----
>From: Sebastian Rahtz
>[mailto:sebastian.rahtz at computing-services.oxford.ac.uk]
>Sent: Tuesday, July 05, 2005 8:22 AM
>To: Perry Willett
>Cc: 'TEI Council'
>Subject: Re: [tei-council] some reports in
>
>Perry Willett wrote:
>
>>I also agree with the proposal to eliminate numbered lgs, but I don't
>recall
>>ever agreeing to give up numbered divs. I would argue strongly in favor of
>>keeping them.
>>
>>
>
>why are numbered divs ok but numbered lgs not?
>
>I too don't recall the subject being discussed formally.
>
>sebastian
>
>
>
>_______________________________________________
>tei-council mailing list
>tei-council at lists.village.Virginia.EDU
>http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

From pwillett at umich.edu  Wed Jul  6 15:33:04 2005
From: pwillett at umich.edu (Perry Willett)
Date: Wed, 6 Jul 2005 15:33:04 -0400
Subject: [tei-council] some reports in
In-Reply-To: 
Message-ID: <004401c58261$8a8c3450$922bd38d@CLUBSODA>

Hmm, well, as I say, I haven't encountered them (to my relief). I guess if
on the witness stand and forced to answer, I would say I wouldn't use
numbered lgs. ("Aha!" exclaims opposing counsel triumphantly.) Still, I
stick to wanting numbered divs. 

Perry (haunted by the hobgoblins of his inconsistency).

-----Original Message-----
From: tei-council-bounces at lists.village.Virginia.EDU
[mailto:tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of Julia
Flanders
Sent: Wednesday, July 06, 2005 3:00 PM
To: tei-council at lists.village.Virginia.EDU
Subject: RE: [tei-council] some reports in

Does this mean that if you did need to nest s you would want to 
have numbered ones available? I am aware of quite a number of 
projects that do nest  fairly extensively (none of which use 
numbered  ).

At 8:32 AM -0400 7/5/05, Perry Willett wrote:
>I've never encountered a need to nest s.
>
>Perry
>
>
>-----Original Message-----
>From: Sebastian Rahtz
>[mailto:sebastian.rahtz at computing-services.oxford.ac.uk]
>Sent: Tuesday, July 05, 2005 8:22 AM
>To: Perry Willett
>Cc: 'TEI Council'
>Subject: Re: [tei-council] some reports in
>
>Perry Willett wrote:
>
>>I also agree with the proposal to eliminate numbered lgs, but I don't
>recall
>>ever agreeing to give up numbered divs. I would argue strongly in favor of
>>keeping them.
>>
>>
>
>why are numbered divs ok but numbered lgs not?
>
>I too don't recall the subject being discussed formally.
>
>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

From lou.burnard at computing-services.oxford.ac.uk  Wed Jul  6 16:55:51 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 06 Jul 2005 21:55:51 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <42CB038A.9070603@computing-services.oxford.ac.uk>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>
Message-ID: <42CC4557.9050501@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:

>So, on a Linux system, you
>might see
>
>  /usr/share/xml/teiclassic
>  /usr/share/xml/tei
>  /usr/share/xml/docbook
>  /usr/share/xml/xhtml
>
>so there would be no "p4" or "p5" layers anywhere, you would just choose
>a tree at the top level to work with. It simplifies lots of things, and
>makes it
>easier to document. I cannot think of a situation where we mingle P4 and P5.
>
>What do folks think? I know the big problem is that only one thing can
>be called "tei",
>so either P4 or P5 gets a new name. I believe that P5 should get the
>"tei" name, since
>it is where we are working, and we have started on our 0.1 release.
>
>  
>

Just for the record, I think this is a brilliant idea.

From James.Cummings at computing-services.oxford.ac.uk  Wed Jul  6 17:33:34 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 06 Jul 2005 22:33:34 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <42CC4557.9050501@computing-services.oxford.ac.uk>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>
	<42CC4557.9050501@computing-services.oxford.ac.uk>
Message-ID: <42CC4E2E.9080003@computing-services.oxford.ac.uk>

Lou Burnard wrote:
> Sebastian Rahtz wrote:
> 
>> So, on a Linux system, you
>> might see
>>
>>  /usr/share/xml/teiclassic
>>  /usr/share/xml/tei
>>  /usr/share/xml/docbook
>>  /usr/share/xml/xhtml
>>
>> so there would be no "p4" or "p5" layers anywhere, you would just choose
>> a tree at the top level to work with. It simplifies lots of things, and
>> makes it
>> easier to document. I cannot think of a situation where we mingle P4 
>> and P5.
>>
>> What do folks think? I know the big problem is that only one thing can
>> be called "tei",
>> so either P4 or P5 gets a new name. I believe that P5 should get the
>> "tei" name, since
>> it is where we are working, and we have started on our 0.1 release.
> 
> Just for the record, I think this is a brilliant idea.

I think it is a good idea... though I must admit some apprehensions 
with the name teiclassic.

-James

From nsmith at email.unc.edu  Wed Jul  6 17:56:34 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Wed, 6 Jul 2005 17:56:34 -0400 (Eastern Daylight Time)
Subject: [tei-council] directory layout again
In-Reply-To: <42CC4E2E.9080003@computing-services.oxford.ac.uk>
Message-ID: 

> >>  /usr/share/xml/teiclassic
> >>  /usr/share/xml/tei
> >>  /usr/share/xml/docbook
> >>  /usr/share/xml/xhtml

i liked this idea for its lucidity. there were many good ideas along the
way, but not once they clashed and contradicted. this one gave a
prospective to look at the structure in a much more clear way - at least
to me. Classic? hmmm, why not leave it as p4? Everybody know what it is,
only if we want to raise it to the rank of living classics...

n

> >> so there would be no "p4" or "p5" layers anywhere, you would just choose
> >> a tree at the top level to work with. It simplifies lots of things, and
> >> makes it
> >> easier to document. I cannot think of a situation where we mingle P4 
> >> and P5.
> >>
> >> What do folks think? I know the big problem is that only one thing can
> >> be called "tei",
> >> so either P4 or P5 gets a new name. I believe that P5 should get the
> >> "tei" name, since
> >> it is where we are working, and we have started on our 0.1 release.
> > 
> > Just for the record, I think this is a brilliant idea.
> 
> I think it is a good idea... though I must admit some apprehensions 
> with the name teiclassic.
> 
> -James
> _______________________________________________
> 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  Wed Jul  6 18:47:01 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 07 Jul 2005 07:47:01 +0900
Subject: [tei-council] directory layout again
In-Reply-To: <42CB038A.9070603@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Tue, 05 Jul 2005 23:02:50 +0100")
References: <42CB038A.9070603@computing-services.oxford.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

>   /usr/share/xml/teiclassic
>   /usr/share/xml/tei
>   /usr/share/xml/docbook
>   /usr/share/xml/xhtml
>

Hmm, what do you do when P6 comes along?  Or do we just continue with
P5 forever?

   /usr/share/xml/teip4
   /usr/share/xml/teip5
   /usr/share/xml/docbook
   /usr/share/xml/xhtml

On systems that allow this, you could then do a symlink from
  /usr/share/xml/tei
to the one you want to call that.

Having said that, I kind of prefer the one-tree-does-it-all solution.

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 Jul  6 18:59:59 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 06 Jul 2005 23:59:59 +0100
Subject: [tei-council] directory layout again
In-Reply-To: 
References: <42CB038A.9070603@computing-services.oxford.ac.uk>

Message-ID: <42CC626F.7010903@computing-services.oxford.ac.uk>

I think the idea is that when P6 comes along, P5 becomes the 
"teiclassic" -- in other words, that the names are kind of symlinks.

Another option would be to rename P5 as "teirenaissance" I suppose...

Christian Wittern wrote:

>Sebastian Rahtz  writes:
>
>  
>
>>  /usr/share/xml/teiclassic
>>  /usr/share/xml/tei
>>  /usr/share/xml/docbook
>>  /usr/share/xml/xhtml
>>
>>    
>>
>
>Hmm, what do you do when P6 comes along?  Or do we just continue with
>P5 forever?
>
>   /usr/share/xml/teip4
>   /usr/share/xml/teip5
>   /usr/share/xml/docbook
>   /usr/share/xml/xhtml
>
>On systems that allow this, you could then do a symlink from
>  /usr/share/xml/tei
>to the one you want to call that.
>
>Having said that, I kind of prefer the one-tree-does-it-all solution.
>
>Christian
>  
>
>  
>

From James.Cummings at computing-services.oxford.ac.uk  Wed Jul  6 19:09:57 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 07 Jul 2005 00:09:57 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <42CC626F.7010903@computing-services.oxford.ac.uk>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>	
	<42CC626F.7010903@computing-services.oxford.ac.uk>
Message-ID: <42CC64C5.7020902@computing-services.oxford.ac.uk>

Lou Burnard wrote:
> I think the idea is that when P6 comes along, P5 becomes the 
> "teiclassic" -- in other words, that the names are kind of symlinks.
> 
> Another option would be to rename P5 as "teirenaissance" I suppose...

I was envisioning that teiclassic (or tei-p4 or whatever) would always 
only just contain TEI P4 (and previous P-versions?) and the from TEI 
P5 onwards the tei package would just stay and get new numerical 
version numbers. So tei 1.5 (or whatever) becomes tei 1.6, 1.6.1, etc. 
  Installing earlier versions of the tei package is easy (as long as 
they remain available).  So P6 never arrives, but the guidelines 
continue to develop.  If in 5 years you want to install the P5 version 
you just install an earlier version of the same package.

Or are we tied permanently to fixed P-Versions?

Just curious,
-James

From lou.burnard at computing-services.oxford.ac.uk  Wed Jul  6 19:21:42 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 07 Jul 2005 00:21:42 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <42CC64C5.7020902@computing-services.oxford.ac.uk>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>		<42CC626F.7010903@computing-services.oxford.ac.uk>
	<42CC64C5.7020902@computing-services.oxford.ac.uk>
Message-ID: <42CC6786.1060708@computing-services.oxford.ac.uk>

Yes! I like this idea *even better* !!

Lou (who neever wants to have to explain what "P" is short for again)

James Cummings wrote:

> Lou Burnard wrote:
>
>> I think the idea is that when P6 comes along, P5 becomes the 
>> "teiclassic" -- in other words, that the names are kind of symlinks.
>>
>> Another option would be to rename P5 as "teirenaissance" I suppose...
>
>
> I was envisioning that teiclassic (or tei-p4 or whatever) would always 
> only just contain TEI P4 (and previous P-versions?) and the from TEI 
> P5 onwards the tei package would just stay and get new numerical 
> version numbers. So tei 1.5 (or whatever) becomes tei 1.6, 1.6.1, etc. 
>  Installing earlier versions of the tei package is easy (as long as 
> they remain available).  So P6 never arrives, but the guidelines 
> continue to develop.  If in 5 years you want to install the P5 version 
> you just install an earlier version of the same package.
>
> Or are we tied permanently to fixed P-Versions?
>
> Just curious,
> -James
> _______________________________________________
> 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 Jul  6 19:32:42 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 07 Jul 2005 00:32:42 +0100
Subject: [tei-council] Oxygen P5 Instructions
In-Reply-To: <42C6AB01.2020400@computing-services.oxford.ac.uk>
References: <1E9CCE26-ADDE-474C-B8A4-7AE5CD7CF707@indiana.edu>
	<42C6AB01.2020400@computing-services.oxford.ac.uk>
Message-ID: <42CC6A1A.4040505@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:

>
>>TML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/
>>oxygenValidationInstructions.html
>>TEI/XML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/
>>oxygenValidationInstructions.xml
>>
>>    
>>
>any reason not to put this on the TEI web site?
>
>
>  
>
I can't think of any, so I have done put it there 
(http://www.tei-c.org/Software/ now links to it). John, plz object if 
you wish to.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jul  6 22:44:26 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 07 Jul 2005 11:44:26 +0900
Subject: [tei-council] directory layout again
In-Reply-To: <42CC64C5.7020902@computing-services.oxford.ac.uk> (James
	Cummings's message of "Thu, 07 Jul 2005 00:09:57 +0100")
References: <42CB038A.9070603@computing-services.oxford.ac.uk>

	<42CC626F.7010903@computing-services.oxford.ac.uk>
	<42CC64C5.7020902@computing-services.oxford.ac.uk>
Message-ID: 

James Cummings  writes:

> I was envisioning that teiclassic (or tei-p4 or whatever) would always
> only just contain TEI P4 (and previous P-versions?) and the from TEI
> P5 onwards the tei package would just stay and get new numerical
> version numbers. So tei 1.5 (or whatever) becomes tei 1.6, 1.6.1,
> etc. Installing earlier versions of the tei package is easy (as long
> as they remain available).  So P6 never arrives, but the guidelines
> continue to develop.  If in 5 years you want to install the P5 version
> you just install an earlier version of the same package.
>
>
That's what I meant when I said "going on with P5 forever". 

Of course, what this burns down to is that we can't introduce changes
that are not backward compatible.

> Or are we tied permanently to fixed P-Versions?

This is more of a marketing issue, I assume.

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  Wed Jul  6 22:48:04 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 07 Jul 2005 11:48:04 +0900
Subject: [tei-council] Oxygen P5 Instructions
In-Reply-To: <42CC6A1A.4040505@computing-services.oxford.ac.uk> (Lou
	Burnard's message of "Thu, 07 Jul 2005 00:32:42 +0100")
References: <1E9CCE26-ADDE-474C-B8A4-7AE5CD7CF707@indiana.edu>
	<42C6AB01.2020400@computing-services.oxford.ac.uk>
	<42CC6A1A.4040505@computing-services.oxford.ac.uk>
Message-ID: 

Lou Burnard  writes:
> Sebastian Rahtz wrote:
>>>TML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/
>>>oxygenValidationInstructions.html
>>>TEI/XML: http://www.dlib.indiana.edu/~jawalsh/tmp/oxygenValidation/
>>>oxygenValidationInstructions.xml
>>any reason not to put this on the TEI web site?
> I can't think of any, so I have done put it there
> (http://www.tei-c.org/Software/ now links to it). John, plz object if
> you wish to.

The "replacement set" you mention in the oXygen paragraph there, is
that using the "old" layout, or is it the one we are discussing? And
did you find a good location to put the "live" version of that
framework, that is, the version the catalog in oXygen will link to?

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  Wed Jul  6 22:52:53 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 07 Jul 2005 11:52:53 +0900
Subject: [tei-council] [AIR] Review of "Default Text Structure" and "Simple
 Analytic Mechanism" not ready:-(
Message-ID: 

Council members,

Still not being able to find the notes I scribbled down during the
long train rides and lonely evenings on the road to Paris, I have to
apologize that my review for the above mentioned chapters is not yet
ready:-(  I will redo it and post to the list as soon as I can find
some time for this, which will be not before the tomorrows call, but
hopefully before the following one.

All the best,

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 Jul  6 23:53:49 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 6 Jul 2005 23:53:49 -0400
Subject: [tei-council] directory layout again
In-Reply-To: 
References: <42CB038A.9070603@computing-services.oxford.ac.uk>

	<42CC626F.7010903@computing-services.oxford.ac.uk>
	<42CC64C5.7020902@computing-services.oxford.ac.uk>

Message-ID: <17100.42829.950864.161741@emt.wwp.brown.edu>

While I don't like explaining what the "P" stands for either, I am
going to have to sit down and study this for awhile to figure out how
it fits into the Debian guidelines before I decide whether I think
it's a good idea or not. Which I hope to try to do before the
conference call, but it's going to be tough.

And I really *hate* the name "teiclassic". If we do end up with this
high-level versioning, let's make it tei4/ and tei5/, eh?

From lou.burnard at computing-services.oxford.ac.uk  Thu Jul  7 04:26:37 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 07 Jul 2005 09:26:37 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <17100.42829.950864.161741@emt.wwp.brown.edu>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>		<42CC626F.7010903@computing-services.oxford.ac.uk>	<42CC64C5.7020902@computing-services.oxford.ac.uk>	
	<17100.42829.950864.161741@emt.wwp.brown.edu>
Message-ID: <42CCE73D.5060802@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>
>And I really *hate* the name "teiclassic". If we do end up with this
>high-level versioning, let's make it tei4/ and tei5/, eh?
>
>_
>

Sorry, but I disagree. We've suffered from years from having a tag 
called tei.2 -- let's make the naming reflect the reality of the 
situation. There is P4 which we have agreed to freeze and to maintain in 
parallel for a few years, and there is the current version of the TEI, 
which is (as it happens) P5. It might become P6 one day, but it *is* 
currently the TEI proposals. If someone asks "what does the TEI say 
about c haracter encoding" the correct answer is what it says in P5, 
possibly with a back reference to what it used to say in P4.  So I think 
that P4 is the "marked case" as linguists say and should have a 
different name. I'm not married to "teiclassic" but it does convey what 
I think we want to say about this other version rather well --despite 
the associations with a well known marketing fiasco!

From James.Cummings at computing-services.oxford.ac.uk  Thu Jul  7 05:14:45 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 07 Jul 2005 10:14:45 +0100
Subject: [tei-council] [AIR] Review of "Default Text Structure" and "Simple
	Analytic Mechanism" not ready:-(
In-Reply-To: 
References: 
Message-ID: <42CCF285.7060605@computing-services.oxford.ac.uk>

Christian Wittern wrote:
> Council members,
> 
> Still not being able to find the notes I scribbled down during the
> long train rides and lonely evenings on the road to Paris, I have to
> apologize that my review for the above mentioned chapters is not yet
> ready:-(  I will redo it and post to the list as soon as I can find
> some time for this, which will be not before the tomorrows call, but
> hopefully before the following one.

On that note, I have a couple actions outstanding from the Paris meeting.

Chapter Reviews:

DR (Drama) -- I've read through it twice and approached people I thought might 
have had problems using it.  I can up with a series of hypothetical "should 
there be a better way of doing X" questions mainly based on the fact that DR is 
meant to be used for any type of performance and not just drama and have 
forwarded them to Perry (whom I'm collaborating with), but we've both been very 
busy so I don't think we'll have any concrete recommendations by tomorrow.

ND (Names & Dates) -- I approached the Ontology SIG in case they had any input 
on this, and while "Feeding back recommendations to P5" is one of the items on 
their agenda, they have not yet come to any conclusions.  I think that one of 
the considerations is Julia and Perry's investigation of @reg on naming 
elements.  Genealogists using XML that I approached (as a subject field using 
names and dates extensively in specific ways) suggested some changes, and some 
seemed to feel that the dating mechanisms could be improved.  (Specifically 
mechanisms for indicating that an event happened notBefore, Before, After, 
notAfter, a particular date.  Or that it definitely happened in a particular 
dateRange but that this was a range only because it was unknown rather than 
actually being a range.  Or the *bizarre* situation of not wanting YearMonth 
datatype but a YearDay: where you know something took place on the 14th of a 
particular year but not what month. (As I said, bizarre, and I think not catered 
for in W3C datatypes?))  In general there *are* ways of indicating these things 
in TEI dates, though some are rather clunky, and these sorts of dates are the 
types which are used in genealogy a lot.   I have yet to come up with any 
concrete proposals, suggestions or thoughts about names and dates, or discuss 
them with Perry.  Mea Culpa.

README:

I'm about half-way through writing a README for the CVS Stylesheets module, and 
thought while I'm at it to do one for the other modules (or one for all CVS 
modules that can create the individual ones).  This isn't a highly contentious 
issue though and so I'll finish before the conference call after this one. Mea 
Culpa.

Apologies for my tardiness with these issues, I apologise for them now so that I 
don't need to waste people's time during the conference call doing so.

-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  Thu Jul  7 06:31:38 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 07 Jul 2005 11:31:38 +0100
Subject: [tei-council] attribute/datatype data updated
In-Reply-To: <17099.16182.187769.211850@emt.wwp.brown.edu>
References: <17099.16182.187769.211850@emt.wwp.brown.edu>
Message-ID: <42CD048A.6030204@computing-services.oxford.ac.uk>

Syd Bauman wrote:
> The database of TEI attributes and their suggsted datatypes has been
> updated. I fixed dozens of errors, but I have this knawing feeling
> that I introduced a couple of new ones. :-)
> 
> In any case, follow the link to the PHP interface from ED W 90, which
> has also been updated a teeny bit (on the UVA server, which seems to
> be down again), and is at
>   http://www.tei-c.org/Drafts/edw90.xml?style=printable
>   http://www.tei-c.org.uk/Drafts/edw90.xml?style=printable
> 
> I think it is probably a bit much to ask every Council member to look
> at all 541 entries before Fri morning. But every Council member
> should certainly read ED W 90 (and feel free to ask questions on or
> off list if there are parts you don't understand -- or to suggest
> corrections to any explanations that are hard to understand, etc.)
> and at least scan the database of attributes. Search for the
> attributes you care about. Scan for "?"; sort the list by suggested
> declaration and look for weird ones; look through those that are
> declared as tei.data.code to see if there are any you think should be
> tei.data.key or tei.data.enumerated; etc.

Why is tei.data.duration set up defaultly not to allow plurals?  Things take 3 
weeks (or longer :-) ) not 3 week.  I think in addition to wk/yr/week/year/month 
there should be wks/yrs/weeks/years/months.  I would abbreviate month as 
mnth/mnths, if I did at all.

Some random thoughts on http://dev.stg.brown.edu/staff/Syd_Bauman/edw90.php :

@calendar = What about Lunar & Solar (as more vague types of astronomical?), 
Gregorian? I believe the Tibetan calendar is different from the Chinese one. I 
would personally like 'Regnal' since many of the dates I've used are in an 
English Regnal calendar.  (I.e. 5 Edward III for the 5th year of the reign of 
Edward III).  'Fiscal' could be another type of calendar, since that fixes each 
month a a specific number of weeks to facilitate economic comparisons.  Maybe 
'Liturgical'...but there are different ones depending on faith.  There are 
others at http://en.wikipedia.org/wiki/List_of_calendars

@character on   Are 'Shaky', 'Thick' and 'Regular' the appropriate 
palaeographic terms?  I realise it has tei.data.token as well, but surely 
something can be 'Thin' but not 'Shaky'?  (Sounds like milkshakes...)

@cols/@columns = I've not looked at this at all, but it just seems strange that 
these are different datatypes.  So I just mention it to remind me to look at it!

@date on  = Why not tei.data.temporalExpression?

@ed on  = point to xml:id on  maybe?

@exact = I think I agree with the comment.

@feature on  = should include tei.data.token ?

@form on  = Should other formats be included? video.MPEG7 audio.MP3? 
Or does this relate only to the physical form?  Also, what about 'webpage'?

@place = Should these include tei.data.token for transcriptions of non-standard 
objects?

@type on  = Would 'data' or some such be a possibility for recordings 
that are of data that is not either audio or video? Not sure if anyone would use it.

@type on  = ugh.  Shouldn't 'acronym' go into the list with title/org/etc. 
since is both the reason for an abbr while also the method?  Why is 
superscription by itself?  Is the list allowing just one of each of these 
values, or can something be suspension and contraction?

@type on  = Should possible values use industry standard abbreviations 
or be human readable: WA - wide angle, HA - high angle, LA - low angle, CU - 
close up, Bird's-Eye View, ECU - extreme close up, LS - long shot, OTS - over 
the shoulder (as in interviews), pan (left-to-right or right-to-left), tilt (up 
and down) zoom (in or out).  These of course can be combined and don't include 
other camera effects and cuts (like 'fade to black', etc.).

@unit on  = 'folio'?

@value on  = why tei.data.pointer?  I must not understand how that works.

@zone = tei.timezone ?

Just things which occurred to me while scanning through,

-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  Thu Jul  7 07:32:50 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 7 Jul 2005 07:32:50 -0400
Subject: [tei-council] Agenda for TEI Council conference call on Friday
	2005-07-08, 1300 UTC
In-Reply-To: 
References: 
Message-ID: <17101.4834.457671.934781@emt.wwp.brown.edu>

> This is the agenda for the conference call the TEI Council will
> hold Friday, July 8th, 2005 at 1300 UTC.

To find out when that is in your timezone, visit

http://www.timeanddate.com/worldclock/personal.html?cities=137,231,105,878,136,195,141,339,69,48,287,538&year=2005&month=7&day=8&hour=13&min=0&sec=0&p1=0

I think that hits everyone. Let me know if there are any timezones
I've missed. :-)

> INSTRUCTIONS for conference call:
> 
> Participants will dial in to +1 812 856 3550.
> 
> When prompted, enter the code "0920" followed by "#".

From Syd_Bauman at Brown.edu  Thu Jul  7 08:00:50 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 7 Jul 2005 08:00:50 -0400
Subject: [tei-council] directory layout again
In-Reply-To: <42CCE73D.5060802@computing-services.oxford.ac.uk>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>

	<42CC626F.7010903@computing-services.oxford.ac.uk>
	<42CC64C5.7020902@computing-services.oxford.ac.uk>

	<17100.42829.950864.161741@emt.wwp.brown.edu>
	<42CCE73D.5060802@computing-services.oxford.ac.uk>
Message-ID: <17101.6514.660395.934356@emt.wwp.brown.edu>

> Sorry, but I disagree. We've suffered from years from having a tag
> called tei.2 -- let's make the naming reflect the reality of the
> situation.

I'm not sure I see that the name of the root element and the name of
the directory that holds the Guidelines/schemas/whatever that deal
with that root element are such that they'd cause the same suffering.

E.g., the language XHTML has both a version 1.0 and a version 1.1 in
separate directories in /usr/share/xml/xhtml/schema/dtd/, but in both
cases the root element is "html".

> There is P4 which we have agreed to freeze and to maintain in
> parallel for a few years, and there is the current version of the
> TEI, which is (as it happens) P5.

While I understand the sentiment, I think it is premature to call
that which will be released as P5 "current".

> It might become P6 one day, but it *is* currently the TEI
> proposals.

I think this, mostly through our sluggishness, is wishful thinking.
After all, that which will eventually be released as P5 still has a
chapter on the structure of its DTDs; still refers to base,
additional, and axillary tagsets all over; still shows users how to
invoke tagsets using DOCTYPE and parameter entity declarations; still
has source data in attributes; does not mention XInclude; still has
chapters on conformance and modification that make no sense anymore;
etc. While I think there are a few things (character set issues,
feature structures, manuscript description, and tagset documentation
jump to mind) where we can point to a chapter of P5 as a reasonable
current recommendation, P5 as a whole cannot, IMHO, enjoy that
privilege.

> So I think that P4 is the "marked case" as linguists say and should
> have a different name. I'm not married to "teiclassic" but it does
> convey what I think we want to say about this other version rather
> well --despite the associations with a well known marketing fiasco!

While this may well be the case in some number of months when P5 does
become the current version, I still don't think naming directories
like this is necessarily a good idea. (Although setting up symlinks
like this might be.) A user's documents that conform TEI P7 still
conform to TEI P7 even after TEI P8 comes out and P7 is considered
obsolete. As a user, I don't want to do a system upgrade and find
that my files are no longer valid and no longer can be properly
processed because TEI changed what they consider current. In some
sense, what's current to me (the user) is what *I'm using*, not what
TEI is recommending.

That said, I realize that such a system if created without symlinks
(or aliases or whatever), in which only the numbered versions are
accessible is a bit unusual. The current version of Emacs is in
"emacs21/"; but "emacs" is symlinked to it. When the installed
version becomes 22, the symlink is updated such that if I do nothing,
I get the new version.

This is not the case with /usr/share/xml/, though, is it? I see
different versions of DocBook, SVG, and XHTML in that directory, but
no symlinks so that there is a static "current" version.

Gotta go ...

From sebastian.rahtz at computing-services.oxford.ac.uk  Thu Jul  7 09:15:41 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Thu, 07 Jul 2005 14:15:41 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <17101.6514.660395.934356@emt.wwp.brown.edu>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>		<42CC626F.7010903@computing-services.oxford.ac.uk>	<42CC64C5.7020902@computing-services.oxford.ac.uk>		<17100.42829.950864.161741@emt.wwp.brown.edu>	<42CCE73D.5060802@computing-services.oxford.ac.uk>
	<17101.6514.660395.934356@emt.wwp.brown.edu>
Message-ID: <42CD2AFD.5020507@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>While I understand the sentiment, I think it is premature to call
>that which will be released as P5 "current".
>  
>
We've released version 0.1.  What more could we do?

>
>After all, that which will eventually be released as P5 still has a
>chapter on the structure of its DTDs; still refers to base,
>additional, and axillary tagsets all over; still shows users how to
>invoke tagsets using DOCTYPE and parameter entity declarations; still
>has source data in attributes; 
>
so the documentation has not caught up. thats not unusual
(albeit not good)

>does not mention XInclude
>
why would it do that, by the way?

>
>  
>

-- 
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  Thu Jul  7 10:18:30 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Thu, 7 Jul 2005 09:18:30 -0500
Subject: [tei-council] directory layout again
In-Reply-To: <42CD2AFD.5020507@computing-services.oxford.ac.uk>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>		<42CC626F.7010903@computing-services.oxford.ac.uk>	<42CC64C5.7020902@computing-services.oxford.ac.uk>		<17100.42829.950864.161741@emt.wwp.brown.edu>	<42CCE73D.5060802@computing-services.oxford.ac.uk>
	<17101.6514.660395.934356@emt.wwp.brown.edu>
	<42CD2AFD.5020507@computing-services.oxford.ac.uk>
Message-ID: <1E2183A6-71CA-4A59-91F9-D0ABC37D54CE@indiana.edu>

> Syd Bauman wrote:
>
>
>> While I understand the sentiment, I think it is premature to call
>> that which will be released as P5 "current".
>>
>>
>>
> We've released version 0.1.  What more could we do?

Typically when something is 0.1, it's not recommended for production  
use, but offered for more daring early implementers.  I think it's  
fair to say that P4 remains the current production version of TEI and  
that P5 is the current development version of TEI.  So Syd's point is  
a good one.  While P5 remains some distance from a 1.0 release, we  
should not recommend P5 as the current production version to the  
community at large.  I wish we were closer to 1.0, and I share in the  
responsibility for us not being there yet, but we're still a ways off.

>
>
>>
>> After all, that which will eventually be released as P5 still has a
>> chapter on the structure of its DTDs; still refers to base,
>> additional, and axillary tagsets all over; still shows users how to
>> invoke tagsets using DOCTYPE and parameter entity declarations; still
>> has source data in attributes;
>>
>>
> so the documentation has not caught up. thats not unusual
> (albeit not good)
>
>
>> does not mention XInclude
>>
>>
> why would it do that, by the way?
>
>
>
>>
>>
>>
>>
>
>
> -- 
> 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  Thu Jul  7 12:56:44 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 07 Jul 2005 17:56:44 +0100
Subject: [tei-council] Brief report on P5 changes since last meeting
Message-ID: <42CD5ECC.8090905@oucs.ox.ac.uk>

The P5 changelog shows the following activities since 1 May 05

1. Revised versions of MS chapter checked in

2. Work on correcting content models for biblStruct and respStmt

3. New  element added (but not yet fully documented)

4. Make  a chunk rather than a phrase

5. Benchmark (test suite) files revised and checked

6. New spec for , including new spanning class, new 
    element, removal of . Made P5 itself conform to new spec, 
for  which, please see http://www.tei-c.org/P5/Guidelines/CO.html#CONOIX

I have also been working on some of the outstanding SF queries, and
fixing errors where they appear, e.g.

- phraseSeq macro now defined explicitly instead of intermediate macro
   (which used sequence instead of alternation for some reason)
- made content model of  same as that of add (specialPara)
- made content model of  same as that of other divtop elements 
(phraseSeq)
- changed content model of  to paraContent and removed its value 
attribute

From nsmith at email.unc.edu  Thu Jul  7 13:01:50 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Thu, 7 Jul 2005 13:01:50 -0400 (Eastern Daylight Time)
Subject: [tei-council] Review of HD/SH (TEIHeader) and CO (Elements Available
 in All TEI Documents)
Message-ID: 

Hello:

Below is a very brief report on our work on:

A. CO (Elements Available in All TEI Documents)

1.	JW and NS went through the whole chapter independently sharing
comments as they progressed first past through CO with notes for suggested changes.
2.	We scheduled a conf call for July 11 (several work-related travels
made it impossible to schedule anything earlier)
3.	Our opinion that the most work (and effort) will go not into
revision of element-by-element (and their attributes) but in restructuring
and logical reorganization of the chapter itself. We think about different
approaches in organizing and listing all the elements:

a.  by model classes (in cases when one element belongs to more than one
class, we can refer to the fist occurence)
b. alpha list of all elements (too long!)
c. both (in one chapter - by classes first and then a running alha list)
d. other suggestions are welcome

4. We plan to submit a report and proposal for the chapter revamp by the
end of August  

B. Header chapters

1.	We worked on updating and refining the header spreadsheet
2.	Finalized the group of catalogers and received their time
commitment
3.	Sent out the excel spreadsheet to the group of catalogers for
their mapping guidance and comments.
4.	Set-up a group conference call for July.

all the best, ns

Natasha (Natalia) Smith
Digitization Librarian
Wilson Library, CB#3990
University of North Carolina at Chapel Hill
Chapel Hill, NC 27514-8890
email: natalia_smith at unc.edu
tel. (919) 962-9590
fax (919) 962-4452
http://docsouth.unc.edu/

From Syd_Bauman at Brown.edu  Thu Jul  7 19:47:24 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 7 Jul 2005 19:47:24 -0400
Subject: [tei-council] attribute/datatype data updated
In-Reply-To: <42CD048A.6030204@computing-services.oxford.ac.uk>
References: <17099.16182.187769.211850@emt.wwp.brown.edu>
	<42CD048A.6030204@computing-services.oxford.ac.uk>
Message-ID: <17101.48908.557175.196308@emt.wwp.brown.edu>

James, thanks so much for the thoughtful feedback!

> Why is tei.data.duration set up defaultly not to allow plurals?
> Things take 3 weeks (or longer :-) ) not 3 week. I think in
> addition to wk/yr/week/year/month there should be
> wks/yrs/weeks/years/months. I would abbreviate month as
> mnth/mnths, if I did at all.

I thought about this for only a few seconds, and thought that the
unit being used is a thing, in the singular, of which there may be
multiples, which cause us to use the plural. More importantly, the
capability to use the plural only makes sense for those which are
derived from abbreviations of English words: year, month, and week.
Everything else is a symbol from Comité International des
Poids et Mesures, and as such is really already plural, and can't be
expressed with an "s" appended. (The speed limit is 100 km/h, not
kms/hr.) 

Should there be plurals for year, month, and week? (I don't think I
care.) Should we bother with abbreviations of those three? (It's
easier for the editors if we don't :-)

> @calendar = What about Lunar & Solar (as more vague types of
> astronomical?), Gregorian? I believe the Tibetan calendar is
> different from the Chinese one. I would personally like 'Regnal'
> since many of the dates I've used are in an English Regnal
> calendar. (I.e. 5 Edward III for the 5th year of the reign of
> Edward III). 'Fiscal' could be another type of calendar, since that
> fixes each month a a specific number of weeks to facilitate
> economic comparisons. Maybe 'Liturgical'...but there are different
> ones depending on faith. There are others at
> http://en.wikipedia.org/wiki/List_of_calendars

All good suggestions, I think. Is there a more definitive list
somewhere that we should use as a basis?

> @character on  Are 'Shaky', 'Thick' and 'Regular' the
> appropriate palaeographic terms? I realise it has tei.data.token as
> well, but surely something can be 'Thin' but not 'Shaky'? (Sounds
> like milkshakes...)

I certainly don't know. I just copied the list from the "suggested
values include" in the tagdoc.

> @cols/@columns = I've not looked at this at all, but it just seems
> strange that these are different datatypes. 

Oh dear. These three are completely screwed up. I'll fix 'em right
after dinner.

> @date on  = Why not tei.data.temporalExpression?

This is what we call in the encoding world an "error". As is obvious
by the additional constraint, it's supposed to be
tei.data.temporalExpression. 

> @ed on  = point to xml:id on  maybe?

Won't work in the general case of having more than one edition
encoded in the same file. There are a lot of ed= attributes that need
to refer to a controlled vocabulary. I think we need to create an
 or some such in the .

> @feature on  = should include tei.data.token ?

I'm inclined to think so, but again, I was just copying what is
currently present in the declaration of that attribute.

> @form on  = Should other formats be included? video.MPEG7
> audio.MP3? Or does this relate only to the physical form? Also,
> what about 'webpage'?

I think only physical form, but to be honest, not only don't I know,
I don't think it has been thought through very thoroughly yet by
anyone. 

> @place = Should these include tei.data.token for transcriptions of
> non-standard objects?

(I presume you mean of , , or .) Same answer as for
feature= of , I think.

> @type on  = ugh. ... Is the list allowing just one of each
> of these values, or can something be suspension and contraction?

I'm really not sure what is the right way to go with this one. I
suspect that in the end, we'll need to use a looser model than the
one I've sketched (the values for which were pretty much copied from
the current declaration, BTW), if for no other reason than ODD won't
be able to support this kind of thing, it least not soon enough for
immediate use.

However, that said, I think it *is* useful to think about the
semantics of type= of , through its syntax, even if we end up
loosening the syntax later.

Here's what I sketched out, with whitespace improved for (human)
readability: 

| list { 
|      ( "suspension" | "contraction" | "brevigraph" | "acronym" | tei.data.token )?,
|      ( "superscription" | tei.data.token )?,
|      ( "title" | "organization" | "geographic" | tei.data.token )?
|      }

This means 0 or 1 from each group, in the order specified. So
  type="suspension superscription title"
  type=""
  type="acronym organization"
are all valid even if you removed the "tei.data.token"s, but
  type="title contraction"
would not be. With the "tei.data.token"s there, the only constraint
is that there be no more than 2 internal sequences of whitespace.
I.e., 
  type="a b c"
is OK, but 
  type="a b c d"
is not.

> Shouldn't 'acronym' go into the list with title/org/etc. since is
> both the reason for an abbr while also the method? 

I have to admit, I hadn't thought of acronym as a reason. (This
from the guy who came up with "consideration, resolution, and
progress". :-)

> Why is superscription by itself?

Seemed to be in a category by itself. But I think the real question
is why is superscription in the list of values at all? Seems like a
detail best left to rend= to me.

> @type on  = Should possible values use industry standard
> abbreviations or be human readable:

Darn good question, to which I don't have an actual answer. But I
think one guideline for us to apply is that brevity is not itself a
goal unless the value is going to appear a lot, in which case it can
become pretty important. (E.g., if  were called , it
wouldn't be much of a loss, because it doesn't generally occur very
often; if  were called , it could get really annoying
really fast.)

> @unit on  = 'folio'?
> 
> @value on  = why tei.data.pointer? I must not understand how that works.

Nope, you understand, you've just stumbled into another error.

> @zone = tei.timezone ?

Yes, personally I think that since there are 2 zone= attributes and
the list of timezones is potentially a pain to maintain, it may make
good sense to give this one its own datatype, 'tei.data.timezone'.

> Just things which occurred to me while scanning through,

I'm glad you scanned! Thanks. I hope to send a repair report in an
hour or so.

From Syd_Bauman at Brown.edu  Thu Jul  7 20:53:33 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 7 Jul 2005 20:53:33 -0400
Subject: [tei-council] attribute/datatype data updated
In-Reply-To: <17101.48908.557175.196308@emt.wwp.brown.edu>
References: <17099.16182.187769.211850@emt.wwp.brown.edu>
	<42CD048A.6030204@computing-services.oxford.ac.uk>
	<17101.48908.557175.196308@emt.wwp.brown.edu>
Message-ID: <17101.52877.519425.496316@emt.wwp.brown.edu>

OK, I've fixed
  columns= of 
  cols= of 
  cols= of 

  date= of 
as James pointed out, and also
  dateCreated= of 
  dateUpdated= of 
  value= of 
  from= of 
  notAfter= of 'tei.datable'
  notBefore= of 'tei.datable'
all of which really looked like a cut-and-paste error, and
  max= of 
  value= of 
  value= of 
  xml:id= of 'tei.global'
  xml:lang= of 'tei.global'
which I can't tell why they were screwed up.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Jul  7 21:35:13 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 08 Jul 2005 10:35:13 +0900
Subject: [tei-council] attribute/datatype data updated
In-Reply-To: <17101.48908.557175.196308@emt.wwp.brown.edu> (Syd Bauman's
	message of "Thu, 7 Jul 2005 19:47:24 -0400")
References: <17099.16182.187769.211850@emt.wwp.brown.edu>
	<42CD048A.6030204@computing-services.oxford.ac.uk>
	<17101.48908.557175.196308@emt.wwp.brown.edu>
Message-ID: 

Syd Bauman  writes:

> James, thanks so much for the thoughtful feedback!
>
>
>> Why is tei.data.duration set up defaultly not to allow plurals?
>> Things take 3 weeks (or longer :-) ) not 3 week. I think in
>> addition to wk/yr/week/year/month there should be
>> wks/yrs/weeks/years/months. I would abbreviate month as
>> mnth/mnths, if I did at all.

How about d (day), w (week), m (month), y (year); these tokens then do
not take plural forms.

> I thought about this for only a few seconds, and thought that the
> unit being used is a thing, in the singular, of which there may be
> multiples, which cause us to use the plural. More importantly, the
> capability to use the plural only makes sense for those which are
> derived from abbreviations of English words: year, month, and week.
> Everything else is a symbol from Comité International des
> Poids et Mesures, and as such is really already plural, and can't be
> expressed with an "s" appended. (The speed limit is 100 km/h, not
> kms/hr.) 
>
> Should there be plurals for year, month, and week? (I don't think I
> care.) Should we bother with abbreviations of those three? (It's
> easier for the editors if we don't :-)

Have you looked at
http://www.w3.org/TR/xpath-functions/#durations-dates-times, which
devotes a whole section to Durations, Dates and Times.  Certainly
worthwhile to stay compatible with that. XPath in turn references ISO
8601, but being from the ISO this is not available on the web, so I
can't check what they say. 

On a related note, in Chinese you have a cycle of 60 days which is
used as a reference (sometimes in paralell) to the year/month system.
There should be a place for this as well, ideally.

>
>
>> @calendar = What about Lunar & Solar (as more vague types of
>> astronomical?), Gregorian? I believe the Tibetan calendar is
>> different from the Chinese one. I would personally like 'Regnal'
>> since many of the dates I've used are in an English Regnal
>> calendar. (I.e. 5 Edward III for the 5th year of the reign of
>> Edward III). 'Fiscal' could be another type of calendar, since that
>> fixes each month a a specific number of weeks to facilitate
>> economic comparisons. Maybe 'Liturgical'...but there are different
>> ones depending on faith. There are others at
>> http://en.wikipedia.org/wiki/List_of_calendars
>
> All good suggestions, I think. Is there a more definitive list
> somewhere that we should use as a basis?

I doubt that you can do with a global list.  

>
>> @ed on  = point to xml:id on  maybe?
>
> Won't work in the general case of having more than one edition
> encoded in the same file. There are a lot of ed= attributes that need
> to refer to a controlled vocabulary. I think we need to create an
>  or some such in the .

Yes, that is true.  I have always wondered where this dangling @ed
points to.

>> @form on  = Should other formats be included? video.MPEG7
>> audio.MP3? Or does this relate only to the physical form? Also,
>> what about 'webpage'?

form does not look like the right thing for these, I would expect
something like mimetype for such things. Might worth be looking at
stuff like METS, since that is where they deal with what is out in the
wild. 

On the whole, it looks like we need to spend a bit more time on this...

All the best,

Christian

-- 
 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From abia at umh.es  Fri Jul  8 05:26:47 2005
From: abia at umh.es (Alejandro Bia)
Date: Fri, 08 Jul 2005 11:26:47 +0200
Subject: [tei-council] Not able to connect to today's call...
Message-ID: <5.2.0.9.0.20050708110335.03b9d488@mussol.umh.es>

Dear council members,

I'm currently ill and away from work (and off-line most of the time).
My health has deteriorated since I came back from Canada three weeks ago.
Apparently, recovering may take long. I hope not.
I'll let you know.

I won't be able to take part of today's conference call.
I'm really sorry.

Alex.-

---------------------------------------------------------
ALEJANDRO BIA-PLATAS
e-mail: abia at umh.es

   Departamento de Estad?stica, Matem?tica e Inform?tica
   Universidad Miguel Hern?ndez
   Edificio Torretamarit
   Avenida de la Universidad s/n, E-03202, Elche, ESPA?A
   http://www.umh.es/
   Tel: +34 966658542
   Fax: +34 966658715
   Tel?fono m?vil: +34 610806427

--------------------------------------------------------- 

From Syd_Bauman at Brown.edu  Fri Jul  8 06:13:17 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 8 Jul 2005 06:13:17 -0400
Subject: [tei-council] Not able to connect to today's call...
In-Reply-To: <5.2.0.9.0.20050708110335.03b9d488@mussol.umh.es>
References: <5.2.0.9.0.20050708110335.03b9d488@mussol.umh.es>
Message-ID: <17102.20925.27541.436899@emt.wwp.brown.edu>

We hope you feel better soon, Alejandro.
Thanks for letting us know.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Jul  8 07:21:25 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 08 Jul 2005 20:21:25 +0900
Subject: [tei-council] Not able to connect to today's call...
In-Reply-To: <5.2.0.9.0.20050708110335.03b9d488@mussol.umh.es> (Alejandro
	Bia's message of "Fri, 08 Jul 2005 11:26:47 +0200")
References: <5.2.0.9.0.20050708110335.03b9d488@mussol.umh.es>
Message-ID: 

Alejandro Bia  writes:

> Dear council members,
>
> I'm currently ill and away from work (and off-line most of the time).
> My health has deteriorated since I came back from Canada three weeks ago.
> Apparently, recovering may take long. I hope not.
> I'll let you know.
>
> I won't be able to take part of today's conference call.
> I'm really sorry.

I am very sorry to hear that, Alejandro.  Hope you will be better
soon.  In the meantime, take good care and relax.

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 computing-services.oxford.ac.uk  Fri Jul  8 07:35:53 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 12:35:53 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <17101.6514.660395.934356@emt.wwp.brown.edu>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>		<42CC626F.7010903@computing-services.oxford.ac.uk>	<42CC64C5.7020902@computing-services.oxford.ac.uk>		<17100.42829.950864.161741@emt.wwp.brown.edu>	<42CCE73D.5060802@computing-services.oxford.ac.uk>
	<17101.6514.660395.934356@emt.wwp.brown.edu>
Message-ID: <42CE6519.2040108@computing-services.oxford.ac.uk>

I hope some of you can look at this in the next 90 minutes. Its my directory
layout for all TEI-related packages, as of today. I believe that all the
material
is now internally consistent. I have not yet submitted to Sourceforge

share/
|-- doc
|   |-- tei-emacs
|   |-- tei-oxygen
|   |-- tei-p4-lite
|   |   `-- doc
|   |-- tei-p4-schema
|   |-- tei-p4-xsl
|   |-- tei-p5-database
|   |-- tei-p5-exemplars
|   |   |-- html
|   |   `-- xml
|   |-- tei-p5-schema
|   |-- tei-p5-source
|   |-- tei-p5-test
|   |-- tei-p5-xsl
|   |   `-- xsltdoc
|   |       |-- common
|   |       |-- fo
|   |       |-- html
|   |       `-- latex
|   |-- tei-roma
|   |-- tei-teaching
`-- xml
    |-- tei
    |   |-- custom
    |   |   |-- odd
    |   |   |-- schema
    |   |   |   |-- dtd
    |   |   |   |-- relaxng
    |   |   |   `-- xsd
    |   |   `-- templates
    |   |-- odd
    |   |   |-- Source
    |   |   |   |-- AB
    |   |   |   |-- AI
    |   |   |   |-- BIB
    |   |   |   |-- CC
    |   |   |   |-- CE
    |   |   |   |-- CF
    |   |   |   |-- CH
    |   |   |   |-- CO
    |   |   |   |-- COL
    |   |   |   |-- DEDICATION
    |   |   |   |-- DI
    |   |   |   |-- DR
    |   |   |   |-- DS
    |   |   |   |-- DT
    |   |   |   |-- FD
    |   |   |   |-- FM1
    |   |   |   |-- FS
    |   |   |   |-- FT
    |   |   |   |-- GD
    |   |   |   |-- HD
    |   |   |   |-- IN
    |   |   |   |-- MD
    |   |   |   |-- MS
    |   |   |   |-- ND
    |   |   |   |-- NH
    |   |   |   |-- PARTIND
    |   |   |   |-- PH
    |   |   |   |-- PREFS
    |   |   |   |-- REFCLA
    |   |   |   |-- REFENT
    |   |   |   |-- REFTAG
    |   |   |   |-- SA
    |   |   |   |-- SG
    |   |   |   |-- SH
    |   |   |   |-- ST
    |   |   |   |-- TC
    |   |   |   |-- TD
    |   |   |   |-- TE
    |   |   |   |-- TS
    |   |   |   |-- VE
    |   |   |   `-- WD
    |   |   `-- Tools
    |   |-- schema
    |   |   |-- dtd
    |   |   |   `-- p4
    |   |   `-- relaxng
    |   |       `-- p4
    |   |-- stylesheet
    |   |   |-- common
    |   |   |-- fo
    |   |   |-- html
    |   |   |-- latex
    |   |   |-- odds
    |   |   `-- slides
    |   `-- xquery
    `-- teip4
        |-- custom
        |   |-- schema
        |   |   |-- dtd
        |   |   `-- relaxng
        |   `-- templates
        |-- schema
        |   `-- dtd
        `-- stylesheet
            |-- common
            |-- fo
            |-- html
            |-- latex
            `-- slides

-- 
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  Fri Jul  8 07:47:53 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 08 Jul 2005 12:47:53 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <42CE6519.2040108@computing-services.oxford.ac.uk>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>		<42CC626F.7010903@computing-services.oxford.ac.uk>	<42CC64C5.7020902@computing-services.oxford.ac.uk>		<17100.42829.950864.161741@emt.wwp.brown.edu>	<42CCE73D.5060802@computing-services.oxford.ac.uk>	<17101.6514.660395.934356@emt.wwp.brown.edu>
	<42CE6519.2040108@computing-services.oxford.ac.uk>
Message-ID: <42CE67E9.4060808@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> I hope some of you can look at this in the next 90 minutes. Its my directory
> layout for all TEI-related packages, as of today. I believe that all the
> material
> is now internally consistent. I have not yet submitted to Sourceforge
> 
> share/
> |-- doc

I like the doc/ tree, looks much cleaner.

> `-- xml
>     |-- tei

>     |   |-- schema
>     |   |   |-- dtd
>     |   |   |   `-- p4
>     |   |   `-- relaxng
>     |   |       `-- p4

Shouldn't that be p5?

-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 computing-services.oxford.ac.uk  Fri Jul  8 07:53:12 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 12:53:12 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <42CE67E9.4060808@computing-services.oxford.ac.uk>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>		<42CC626F.7010903@computing-services.oxford.ac.uk>	<42CC64C5.7020902@computing-services.oxford.ac.uk>		<17100.42829.950864.161741@emt.wwp.brown.edu>	<42CCE73D.5060802@computing-services.oxford.ac.uk>	<17101.6514.660395.934356@emt.wwp.brown.edu>	<42CE6519.2040108@computing-services.oxford.ac.uk>
	<42CE67E9.4060808@computing-services.oxford.ac.uk>
Message-ID: <42CE6928.9040104@computing-services.oxford.ac.uk>

James Cummings wrote:

> 
>
>>     |   |-- schema
>>     |   |   |-- dtd
>>     |   |   |   `-- p4
>>     |   |   `-- relaxng
>>     |   |       `-- p4
>
>
> Shouldn't that be p5?

no. that p4 level was an error.  the files are just in eg 
xml/tei/schema/relaxng

-- 
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 Jul  8 08:45:12 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 8 Jul 2005 08:45:12 -0400
Subject: [tei-council] directory layout again
In-Reply-To: <42CE6519.2040108@computing-services.oxford.ac.uk>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>

	<42CC626F.7010903@computing-services.oxford.ac.uk>
	<42CC64C5.7020902@computing-services.oxford.ac.uk>

	<17100.42829.950864.161741@emt.wwp.brown.edu>
	<42CCE73D.5060802@computing-services.oxford.ac.uk>
	<17101.6514.660395.934356@emt.wwp.brown.edu>
	<42CE6519.2040108@computing-services.oxford.ac.uk>
Message-ID: <17102.30040.108970.269509@emt.wwp.brown.edu>

Sebastian Rahtz writes:

> share/
> |-- doc
> |   |-- tei-emacs
> |   |-- tei-oxygen
> |   |-- tei-p4-lite
> |   |   `-- doc

What goes in share/doc/tei-p4-lite/ vs share/doc/tei-p4-lite/doc/?

> |   |-- tei-p4-schema
> |   |-- tei-p4-xsl
> |   |-- tei-p5-database
> |   |-- tei-p5-exemplars
> |   |   |-- html
> |   |   `-- xml

I think I am completely misunderstanding this. What goes in
tei-p5-exemplars/?

> |   |-- tei-p5-schema

Documentation for the schema? Maybe I'm trying to think too early in
the morning, but what's this?

> |   |-- tei-p5-source

If the source is in ../share/xml/tei/odd/Source/, what's here?

> |   |-- tei-p5-test
> |   |-- tei-p5-xsl
> |   |   `-- xsltdoc
> |   |       |-- common
> |   |       |-- fo
> |   |       |-- html
> |   |       `-- latex
> |   |-- tei-roma
> |   |-- tei-teaching
> `-- xml
>     |-- tei

If we're not going to use ../share/xml/tei/p4/ and
../share/xml/tei/p5/ (which still doesn't follow Debian's desires,
but at least pushes the divide a level deeper), then I think that
this directory, to be parallel to ../share/xml/teip4/ should be named
../share/xml/teip5/. This permits more flexibility in not feeling
tied to backwards compatibility if & when we move to P6. Note that we
could still be backwards compatable, we just would feel less
compelled.

>     |   |-- custom
>     |   |   |-- odd
>     |   |   |-- schema
>     |   |   |   |-- dtd
>     |   |   |   |-- relaxng
>     |   |   |   `-- xsd
>     |   |   `-- templates
>     |   |-- odd
>     |   |   |-- Source
>     |   |   |   |-- AB
>     |	  |   |	  |-- ...
>     |   |   |   `-- WD
>     |   |   `-- Tools
>     |   |-- schema
>     |   |   |-- dtd
>     |   |   |   `-- p4
>     |   |   `-- relaxng
>     |   |       `-- p4

Last time you said this was just TEI P4 Lite, in which case it still
doesn't belong in ../share/xml/tei/schema/, but rather in
../share/xml/teip4/custom/.

>     |   |-- stylesheet
>     |   |   |-- common
>     |   |   |-- fo
>     |   |   |-- html
>     |   |   |-- latex
>     |   |   |-- odds
>     |   |   `-- slides
>     |   `-- xquery
>     `-- teip4
>         |-- custom
>         |   |-- schema
>         |   |   |-- dtd
>         |   |   `-- relaxng
>         |   `-- templates
>         |-- schema
>         |   `-- dtd
>         `-- stylesheet
>             |-- common
>             |-- fo
>             |-- html
>             |-- latex
>             `-- slides

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jul  8 08:57:50 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 13:57:50 +0100
Subject: [tei-council] directory layout again
In-Reply-To: <17102.30040.108970.269509@emt.wwp.brown.edu>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>		<42CC626F.7010903@computing-services.oxford.ac.uk>	<42CC64C5.7020902@computing-services.oxford.ac.uk>		<17100.42829.950864.161741@emt.wwp.brown.edu>	<42CCE73D.5060802@computing-services.oxford.ac.uk>	<17101.6514.660395.934356@emt.wwp.brown.edu>	<42CE6519.2040108@computing-services.oxford.ac.uk>
	<17102.30040.108970.269509@emt.wwp.brown.edu>
Message-ID: <42CE784E.5050703@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>>share/
>>|-- doc
>>|   |-- tei-emacs
>>|   |-- tei-oxygen
>>|   |-- tei-p4-lite
>>|   |   `-- doc
>>    
>>
>
>What goes in share/doc/tei-p4-lite/ vs share/doc/tei-p4-lite/doc/?
>  
>
fair point. looks like an error

>
>  
>
>>|   |-- tei-p4-schema
>>|   |-- tei-p4-xsl
>>|   |-- tei-p5-database
>>|   |-- tei-p5-exemplars
>>|   |   |-- html
>>|   |   `-- xml
>>    
>>
>
>I think I am completely misunderstanding this. What goes in
>tei-p5-exemplars/?
>  
>
documentaton of the "exemplars" (however you interpret that...)

>>|   |-- tei-p5-schema
>>    
>>
>
>Documentation for the schema? Maybe I'm trying to think too early in
>the morning, but what's this?
>  
>
every "package" gets a doc directory. it may just have a changelog

>>|   |-- tei-p5-source
>>    
>>
>
>If the source is in ../share/xml/tei/odd/Source/, what's here?
>  
>
as above

>
>If we're not going to use ../share/xml/tei/p4/ and
>../share/xml/tei/p5/ (which still doesn't follow Debian's desires,
>but at least pushes the divide a level deeper), then I think that
>this directory, to be parallel to ../share/xml/teip4/ should be named
>../share/xml/teip5/. 
>
if Windows had symlinks, I'd agree.....

>
>Last time you said this was just TEI P4 Lite, in which case it still
>doesn't belong in ../share/xml/tei/schema/, but rather in
>../share/xml/teip4/custom/.
>  
>
yes, that was an error

-- 
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 mjd at hum.ku.dk  Fri Jul  8 09:01:17 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Fri, 08 Jul 2005 15:01:17 +0200
Subject: [tei-council] Reviews of ms-chapter
In-Reply-To: <17102.30040.108970.269509@emt.wwp.brown.edu>
References: <42CE6519.2040108@computing-services.oxford.ac.uk>
Message-ID: <42CE953D.10500.1530E57@localhost>

Bedre sent end aldrig, as we say. Some comments on the 
reviews of the msDescription chapter. A much more detailed 
report will follow.

Reviews, varying in their usefulness, are in from:
1. Dorothy (Dot) Porter, working with Ben Withers, 
professor in Art History, University of Kentucky, who is 
producing an electronic edition of BL Claudius B. iv.
2. Elizabeth Solopova at the Bodleian
3. Torsten Schassan of the Herzog August Bibliothek in 
Wolfenb?ttel
4. Jindrich Marek of the National Library of the Czech 
Republic
5. Gautier Poupeau of the Sorbonne

People who promised reviews but have not delivered them 
are:
Daniel O'Donnell, University of Lethbridge
Fotis Jannidis, Darmstadt (who had in fact previously sent 
fairly detailed comments on the first draft of the chapter)

I have also received comments from Consuelo Dutschke, 
Columbia University Library; the currently available draft 
has in fact been amended to take these into account.

On the whole, the reviews point out a lot of small things 
which are in need fixing, many owing to the nature of the 
ODD system (such as statements in the specifications that 
elements have no attributes other than global and inherited 
ones, when according to the surrounding prose in fact they 
do, and descriptions of standard TEI elements or attributes 
which are inappropriate to manuscripts), but nobody's 
pointed out any major problems/lacks. This I suppose is a 
good thing, since it suggests that we've actually got it 
right. Some classic problems turned up, such as the 
(alleged) inflexibility of the system when dealing with 
legacy data. There were also a number of comments which 
were simply wrong (people saying that you couldn't do 
things you perfectly well can), but which indicate that the 
documentation needs to be better.

One problem which was mentioned by several people has to do 
with the change of  to the standard TEI element 
, one result of which is that it is no longer 
possible to use  to indicate the language of the 
manuscript as a whole ( is allowed within 
individual  elements but is not, unlike 
,  and , phrase-level). There 
is, of course, nothing to stop you simply writing "Latin 
with some French" in your <head> element, but for search 
purposes and so on people want to tag these things. One 
solution that occurs to me is to have the relevant 
attributes from <textLang>, viz. langKey and otherLangs, on 
<msContents>; this could even be a class (textLang?). 
Another is to make <textLang> phrase-level. Doing either of 
these would also allow one to encode the languages of the 
manuscript even if one used the <p> option inside 
<msContents>, as requested by ES. The inability to have 
<author> in <head> was also mentioned.

MJD

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jul  8 10:36:04 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 15:36:04 +0100
Subject: [tei-council] face to face re TEI class system
Message-ID: <42CE8F54.3020808@computing-services.oxford.ac.uk>

Can I have a show of hands as to who expects/needs/wants to attend this
devilish face to face to "sort out" the TEI class system?  Lou
and Syd I take as read, and me. Who else?

Can I also confirm that this is in Oxford,
on September 29th and probably 30th 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 sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jul  8 10:43:00 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 15:43:00 +0100
Subject: [tei-council] directory layout
Message-ID: <42CE90F4.90505@computing-services.oxford.ac.uk>

Here is a corrected version. I generated this by making Debian packages
of all
the TEI-related stuff I have, and looking at /usr/share/doc/tei* and
/usr/share/xml/tei*

If you are Linux geek, and install all my packages, you should find this
structure
on your disk. I would expect Mr oXygen to pick up the xml/tei and
xml/teip4 trees, and
strip out "odd" and "xquery" nodes.

My working assumption is that most people are content to fly with this,
and just let Syd and James poke sticks are fragile details

share/
|-- doc
|   |-- tei-emacs
|   |-- tei-oxygen
|   |-- tei-p4-lite
|   |-- tei-p4-schema
|   |-- tei-p4-xsl
|   |-- tei-p5-database
|   |-- tei-p5-doc
|   |   `-- html
|   |-- tei-p5-exemplars
|   |   |-- html
|   |   `-- xml
|   |-- tei-p5-schema
|   |-- tei-p5-source
|   |-- tei-p5-test
|   |-- tei-p5-xsl
|   |   `-- xsltdoc
|   |       |-- common
|   |       |-- fo
|   |       |-- html
|   |       `-- latex
|   |-- tei-roma
|   |-- tei-teaching
|   `-- tei-xsl
`-- xml
    |-- tei
    |   |-- custom
    |   |   |-- odd
    |   |   |-- schema
    |   |   |   |-- dtd
    |   |   |   |-- relaxng
    |   |   |   `-- xsd
    |   |   `-- templates
    |   |-- odd
    |   |   |-- Source
    |   |   |   |-- AB
    |   |   |   |-- AI
    |   |   |   |-- BIB
    |   |   |   |-- CC
    |   |   |   |-- CE
    |   |   |   |-- CF
    |   |   |   |-- CH
    |   |   |   |-- CO
    |   |   |   |-- COL
    |   |   |   |-- DEDICATION
    |   |   |   |-- DI
    |   |   |   |-- DR
    |   |   |   |-- DS
    |   |   |   |-- DT
    |   |   |   |-- FD
    |   |   |   |-- FM1
    |   |   |   |-- FS
    |   |   |   |-- FT
    |   |   |   |-- GD
    |   |   |   |-- HD
    |   |   |   |-- IN
    |   |   |   |-- MD
    |   |   |   |-- MS
    |   |   |   |-- ND
    |   |   |   |-- NH
    |   |   |   |-- PARTIND
    |   |   |   |-- PH
    |   |   |   |-- PREFS
    |   |   |   |-- REFCLA
    |   |   |   |-- REFENT
    |   |   |   |-- REFTAG
    |   |   |   |-- SA
    |   |   |   |-- SG
    |   |   |   |-- SH
    |   |   |   |-- ST
    |   |   |   |-- TC
    |   |   |   |-- TD
    |   |   |   |-- TE
    |   |   |   |-- TS
    |   |   |   |-- VE
    |   |   |   `-- WD
    |   |   `-- Tools
    |   |-- schema
    |   |   |-- dtd
    |   |   `-- relaxng
    |   |-- stylesheet
    |   |   |-- common
    |   |   |-- fo
    |   |   |-- html
    |   |   |-- latex
    |   |   |-- odds
    |   |   `-- slides
    |   `-- xquery
    `-- teip4
        |-- custom
        |   |-- schema
        |   |   |-- dtd
        |   |   `-- relaxng
        |   `-- templates
        |-- schema
        |   `-- dtd
        `-- stylesheet
            |-- common
            |-- fo
            |-- html
            |-- latex
            `-- slides

102 directories

-- 
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  Fri Jul  8 10:44:27 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 08 Jul 2005 15:44:27 +0100
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <42CE8F54.3020808@computing-services.oxford.ac.uk>
References: <42CE8F54.3020808@computing-services.oxford.ac.uk>
Message-ID: <42CE914B.2020400@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> Can I have a show of hands as to who expects/needs/wants to attend this
> devilish face to face to "sort out" the TEI class system?  Lou
> and Syd I take as read, and me. Who else?
> 
> Can I also confirm that this is in Oxford,
> on September 29th and probably 30th too?

If it is taking place in Oxford, then could I attend as well?

-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 computing-services.oxford.ac.uk  Fri Jul  8 10:47:46 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 15:47:46 +0100
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <42CE914B.2020400@computing-services.oxford.ac.uk>
References: <42CE8F54.3020808@computing-services.oxford.ac.uk>
	<42CE914B.2020400@computing-services.oxford.ac.uk>
Message-ID: <42CE9212.8040109@computing-services.oxford.ac.uk>

James Cummings wrote:

>
> If it is taking place in Oxford, then could I attend as well?

if you promise to vote in the same way as 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

From James.Cummings at computing-services.oxford.ac.uk  Fri Jul  8 10:50:25 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 08 Jul 2005 15:50:25 +0100
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <42CE9212.8040109@computing-services.oxford.ac.uk>
References: <42CE8F54.3020808@computing-services.oxford.ac.uk>
	<42CE914B.2020400@computing-services.oxford.ac.uk>
	<42CE9212.8040109@computing-services.oxford.ac.uk>
Message-ID: <42CE92B1.80306@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> James Cummings wrote:
>>If it is taking place in Oxford, then could I attend as well?
> 
> if you promise to vote in the same way as me.

Can you trust my promise?

So what is this meet-o-matic thing we are going to use to schedule the next meeting?

-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  Fri Jul  8 10:49:53 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Fri, 8 Jul 2005 16:49:53 +0200
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <42CE8F54.3020808@computing-services.oxford.ac.uk>
References: <42CE8F54.3020808@computing-services.oxford.ac.uk>
Message-ID: <c7cb1869a27eb3bebf849709d2a89a69@loria.fr>

Dear all,
I take the opportunity of this message to apologize: my shuttle to Lyon 
airport has been stuck in traffic more than one hour and I have not 
been able to attend the conf call as expected.
Concerning the TEI class meeting, I had booked Sept 26-27 for a while 
on my agenda, but 29-30 is definitely not possible for me: is there a 
reason why we change the initial plans?
Best,
Laurent

Le 8 juil. 05, ? 16:36, Sebastian Rahtz a ?crit :

> Can I have a show of hands as to who expects/needs/wants to attend this
> devilish face to face to "sort out" the TEI class system?  Lou
> and Syd I take as read, and me. Who else?
>
> Can I also confirm that this is in Oxford,
> on September 29th and probably 30th 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
>

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jul  8 10:55:47 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 15:55:47 +0100
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <42CE92B1.80306@computing-services.oxford.ac.uk>
References: <42CE8F54.3020808@computing-services.oxford.ac.uk>
	<42CE914B.2020400@computing-services.oxford.ac.uk>
	<42CE9212.8040109@computing-services.oxford.ac.uk>
	<42CE92B1.80306@computing-services.oxford.ac.uk>
Message-ID: <42CE93F3.30607@computing-services.oxford.ac.uk>

>
> Can you trust my promise?

no

>
>
> So what is this meet-o-matic thing we are going to use to schedule the
> next meeting?

suck it and see.  you should have an email 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 computing-services.oxford.ac.uk  Fri Jul  8 10:58:39 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 15:58:39 +0100
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <c7cb1869a27eb3bebf849709d2a89a69@loria.fr>
References: <42CE8F54.3020808@computing-services.oxford.ac.uk>
	<c7cb1869a27eb3bebf849709d2a89a69@loria.fr>
Message-ID: <42CE949F.9020807@computing-services.oxford.ac.uk>

Laurent Romary wrote:

>
> Concerning the TEI class meeting, I had booked Sept 26-27 for a while
> on my agenda, but 29-30 is definitely not possible for me: is there a
> reason why we change the initial plans?

sorry, that was me mishearing something, I thought CW said 29th. 26-27
it is. So far in the holding cell
are James, Sebastian, Laurent, and Syd and Lou being sought by Interpol.
Any more takers?

-- 
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  Fri Jul  8 11:05:04 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 8 Jul 2005 16:05:04 +0100 (BST)
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <c7cb1869a27eb3bebf849709d2a89a69@loria.fr>
References: <42CE8F54.3020808@computing-services.oxford.ac.uk>
	<c7cb1869a27eb3bebf849709d2a89a69@loria.fr>
Message-ID: <20050708150504.8E1ABF4B9@webmail220.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/20050708/74adc334/attachment.ksh 

From sebastian.rahtz at computing-services.oxford.ac.uk  Fri Jul  8 11:15:44 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 08 Jul 2005 16:15:44 +0100
Subject: [tei-council] arranging next meeting
In-Reply-To: <42CE8CAA.3070503@oucs.ox.ac.uk>
References: <42CE8CAA.3070503@oucs.ox.ac.uk>
Message-ID: <42CE98A0.8060100@computing-services.oxford.ac.uk>

check out http://www.meetomatic.com/respond.asp?id=6816IM
if my previous mail has gone astray

-- 
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  Fri Jul  8 11:41:24 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Fri, 8 Jul 2005 10:41:24 -0500
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <42CE949F.9020807@computing-services.oxford.ac.uk>
References: <42CE8F54.3020808@computing-services.oxford.ac.uk>
	<c7cb1869a27eb3bebf849709d2a89a69@loria.fr>
	<42CE949F.9020807@computing-services.oxford.ac.uk>
Message-ID: <C0D504FF-660E-4F58-8FF2-AA3891A581E4@indiana.edu>

Sebastian,

I'm interested in the class system and believe I could make useful  
contributions.  If others agree, I'd like to participate in the  
meeting, though I'm aware there's some concern about keeping the  
group to a manageable size.  My feelings won't be hurt if I can't be  
included.

John
| John A. Walsh, Associate Director for Projects and Services
| Digital Library Program / Indiana University Libraries
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 Fax:812-856-2062 <mailto:jawalsh at indiana.edu>

On Jul 8, 2005, at 9:58 AM, Sebastian Rahtz wrote:

> Laurent Romary wrote:
>
>
>>
>> Concerning the TEI class meeting, I had booked Sept 26-27 for a while
>> on my agenda, but 29-30 is definitely not possible for me: is there a
>> reason why we change the initial plans?
>>
>
> sorry, that was me mishearing something, I thought CW said 29th. 26-27
> it is. So far in the holding cell
> are James, Sebastian, Laurent, and Syd and Lou being sought by  
> Interpol.
> Any more takers?
>
> -- 
> 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 Syd_Bauman at Brown.edu  Fri Jul  8 14:01:27 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 8 Jul 2005 14:01:27 -0400
Subject: [tei-council] data screwed up; apologies
Message-ID: <17102.49015.77029.486849@emt.wwp.brown.edu>

In response to a question from Sebastian I just took a look at the
data for ED W 90, and found that it is really screwed up. I'm not at
all sure what happened (looks like perhaps 1 column of data was
sorted and the others were not?), but I'll have to go back to a
previous version and reload, I think. There are dozens of really
stupid things (like the ones James caught) that I would never have
said. I'm still finishing up the minutes, but if things go well will
try to have this fixed by Monday.

From Syd_Bauman at Brown.edu  Fri Jul  8 17:19:10 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 8 Jul 2005 17:19:10 -0400
Subject: [tei-council] notes from today's conference call
Message-ID: <17102.60878.897985.297771@emt.wwp.brown.edu>

The first draft of notes from today's call are up on the web at 

  http://www.tei-c.org/Council/tcm18.xml?style=printable

but have not been linked to from the Council index page yet (on
purpose). I'm hoping everyone will take a look (particularly search
for your name, your initials, and the string "??") and send any
corrections here within the next few days.

Note that I made a few dates for action items up on my own accord.

From Julia_Flanders at Brown.edu  Fri Jul  8 17:31:00 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Fri, 8 Jul 2005 17:31:00 -0400
Subject: [tei-council] regularizing names
Message-ID: <a06200768bef49ef6ae2c@[128.148.157.102]>

Here's what Perry and I have come up with concerning the 
regularization of names.

We propose, tentatively, that in P5 we handle the regularization of 
names as follows:

Name elements (<name> and the other "primary" name elements including 
<persName>, <placeName>, <orgName>, <geogName>) may carry a reg= 
attribute, which points to a <regName> element which contains 
information on regularization. This element might live in the TEI 
header or in some other convenient place. The datatype for reg= would 
be tei.data.code. The element name (<regName> as against <reg>) is 
chosen to help distinguish the function of this regularization 
structure from other kinds of regularization in the document.

The nested naming elements such as <foreName>, <surname>, etc.--i.e. 
those which cannot occur on their own but must be nested inside a 
primary naming element--would not carry the reg= attribute and cannot 
be regularized independently. We considered a mechanism for doing 
this and if any Council members think it would be a good idea we can 
add this bit.

The <regName> element may either contain a regularized version of the 
name as its content, or it may carry a pointer to an external 
resource (either locally maintained or an authority file external to 
the project, such as Library of Congress Name Authority files). It 
could also do both, and we don't see a need to police this choice 
(e.g. by making these options exclusive).

The <regName> element would carry three attributes:
--authority=  indicates what authority, if any, is being used as the 
source of the regularization, with values such as "NACO", other 
possibilities
--url= (or target=) points to an external resource
--xml:id= allows the element to be pointed to from the naming element 
in the text.

Example:

<regName authority="NACO" xml:id="rn17">Clinton, William J.</regName>
<regName authority="NACO" xml:id="rn18">Aldrin, Edwin Eugene, Jr.</regName>

<!-- above <regName> elements may be somewhere in <teiHeader> or <hyperDiv>,
            and may be part of a new prosopographic element -->
<!-- ... -->
<name reg="#rn17">Bill Clinton</name>
<persName reg="#rn18">Buzz Aldrin</persName>

We are still concerned about how this use of reg= and <regName> will 
fit in with other forms of regularization (e.g. spelling). However, 
since all other uses of reg= will probably now be addressed as child 
elements, the possibility of confusion is diminished.

Comments welcome--

Julia

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Jul  8 18:13:11 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 09 Jul 2005 07:13:11 +0900
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <20050708150504.8E1ABF4B9@webmail220.herald.ox.ac.uk> (Lou
	Burnard's message of "Fri, 8 Jul 2005 16:05:04 +0100 (BST)")
References: <42CE8F54.3020808@computing-services.oxford.ac.uk>
	<c7cb1869a27eb3bebf849709d2a89a69@loria.fr>
	<20050708150504.8E1ABF4B9@webmail220.herald.ox.ac.uk>
Message-ID: <ygf8y0h9caw.fsf@chwpb.local>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> My diary agrees with Laurent that we had originally specified the date as 26/27 as the date. 

I have that in my diary as well and think that is what I said at the
call -- I plan to be there too.

>
> Sorry we missed you Laurent...

Indeed. Scheduling is getting too tight, right?

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 Jul  8 18:16:37 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 09 Jul 2005 07:16:37 +0900
Subject: [tei-council] directory layout
In-Reply-To: <42CE90F4.90505@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Fri, 08 Jul 2005 15:43:00 +0100")
References: <42CE90F4.90505@computing-services.oxford.ac.uk>
Message-ID: <ygf4qb59c56.fsf@chwpb.local>

Sebastian Rahtz <sebastian.rahtz at computing-services.oxford.ac.uk> writes:

> Here is a corrected version. I generated this by making Debian packages
> of all
> the TEI-related stuff I have, and looking at /usr/share/doc/tei* and
> /usr/share/xml/tei*
>
> If you are Linux geek, and install all my packages, you should find this
> structure
> on your disk. I would expect Mr oXygen to pick up the xml/tei and
> xml/teip4 trees, and
> strip out "odd" and "xquery" nodes.

And we should have a copy of this "framework" version somewhere at a
canonical place in the TEI webspace.

Will you hand that tree over George at oXygen?  You need to speed up,
since they are about to release a new version.

> My working assumption is that most people are content to fly with this,
> and just let Syd and James poke sticks are fragile details

Please do so:-)

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 Jul  8 18:36:03 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 09 Jul 2005 07:36:03 +0900
Subject: [tei-council] notes from today's conference call
In-Reply-To: <17102.60878.897985.297771@emt.wwp.brown.edu> (Syd Bauman's
	message of "Fri, 8 Jul 2005 17:19:10 -0400")
References: <17102.60878.897985.297771@emt.wwp.brown.edu>
Message-ID: <ygfwto17woc.fsf@chwpb.local>

Thank yo Syd, as usual speedy and accurate work.  Amazing how you can
do that under these conditions.  I have to apologize for the bad sound
quality on my side (although I think it is more of a compatibility
issue; the Oxford trio, as well as John and Natasha came in with
excellent quality and even Julia was much better audible than you,
Syd) -- I did a quite thorough search for a headset that I could use
with a phone at home in the weeks before the call, but those products
that I tracked down were discontinued. The market does not seem very
big for this kind of stuff.

Syd Bauman <Syd_Bauman at Brown.edu> writes:

> The first draft of notes from today's call are up on the web at 
>
>   http://www.tei-c.org/Council/tcm18.xml?style=printable
>
> but have not been linked to from the Council index page yet (on
> purpose). I'm hoping everyone will take a look (particularly search
> for your name, your initials, and the string "??") and send any
> corrections here within the next few days.

What I said -- not very clearly -- about Tom Elliot and the EpiDoc
people is the following:
* I had informed them of the project in HD and a plan to produce a
  customization for that project, with a focus on how to describe the
  objects
* Tom responded (after 2 months) and said that this sounds interesting.  He
  send me some information about what he and others are doing and said
  that their main aim is more with a "best practice" approach, in other
  words to guide epigraphers with the encoding, rather than with the
  description.  There are, according to him debates about where to put
  these descriptive metadata (header vs. body) and how to do them, so
  any development here would be welcome.  He was also happy seeing the
  TEI move into this direction and would welcome (and collaborate on) a possible
  epDescription chapter in the future.  

>
> Note that I made a few dates for action items up on my own accord.

Great. We should make it a rule that every action has a date.

After the call I realized that we somehow dropped the ball on the
<choice> stuff.  Lou, do you know what the situation is?  We need to
have a proposal on how to deal with choice, since this seems to be one
of the biggest unresolved issues in P5.

All the best and a good weekend to everybody, 

Christian

-- 

 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From Julia_Flanders at brown.edu  Sat Jul  9 13:46:36 2005
From: Julia_Flanders at brown.edu (Julia Flanders)
Date: Sat, 09 Jul 2005 13:46:36 -0400
Subject: [tei-council] regularizing names
In-Reply-To: <1120870078.42cf1ebe6111f@webmail.iu.edu>
References: <a06200768bef49ef6ae2c@[128.148.157.102]>
	<1120870078.42cf1ebe6111f@webmail.iu.edu>
Message-ID: <42D00D7C.3070506@brown.edu>

John, thanks! Just in case it wasn't clear, we do envision having the 
option of pointing to an external file (whether locally maintained or 
maintained somewhere else). Our suggestion was that this pointing happen 
from the <regName> element--in other words, you always point from <name> 
(<persName>, etc.) to <regName>, and then the <regName> either tells you 
what you want to know or points you outward via its url= attribute. It 
could even do both.

I think you're right that this overlaps conceptually with key=, and I 
pondered this a bit yesterday. It seems to me that the distinction 
between key= and reg= is still that key= is a way of taking you to 
information about a person, and reg= is a way of providing (or taking 
you to) information about a name. In the situations Perry is 
envisioning, where name authority records are the source of information 
about the name, they also happen to provide that information by 
providing information about a person. But this is incidental, and might 
not always be the case.

I also think your idea about where <regName> might live seems 
reasonable. I assume that if we do develop a new prosopographic module, 
it will live in <profileDesc> and this could be incorporated thereunto.

Best, Julia

John A. Walsh wrote:

>Julia and Perry,
>
>This seems to me to be a very elegant solution. 
>
>I'm wondering where in the header these <regName> elements should live.  It
>seems that <profileDesc> is the logical place, since it groups together lots of
>other non-bibliographic metadata.  <profileDesc> could include a
><regularization> (or <regularisation>) element that groups together the many
><regName> elements.
>
>And perhaps the guidelines should also discuss the option of pointing to an
>external file dedicated to name regularizations.  For instance, if my project
>consists of hundreds of commentaries on Romantic poetry, I don't need to repeat
><regName authority="LCNAF" id="byron" >Byron, George Gordon Byron,
>Baron</regName> in every document.  Rather, I could do something like this:
>"...the dastardly and poisonous malignity of <persName
>reg="myRegNames.xml#byron">Byron's</persName> most foul and treacherous
>libel...," pointing to a master myRegNames.xml file.  Of course, this latter
>approach has some potential overlap with the functionality of @key, if one
>accepts that the key can be an id in an XML file as well as it could be a id in
>a database.  But then the TEI is all about choices :-), so I don't see this as a
>problem.
>
>John
>  
>

From Syd_Bauman at Brown.edu  Sat Jul  9 13:48:35 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 9 Jul 2005 13:48:35 -0400
Subject: [tei-council] directory layout again
In-Reply-To: <42CE784E.5050703@computing-services.oxford.ac.uk>
References: <42CB038A.9070603@computing-services.oxford.ac.uk>
	<ygfslyrft7e.fsf@chwpb.local>
	<42CC626F.7010903@computing-services.oxford.ac.uk>
	<42CC64C5.7020902@computing-services.oxford.ac.uk>
	<ygfekabfi7p.fsf@chwpb.local>
	<17100.42829.950864.161741@emt.wwp.brown.edu>
	<42CCE73D.5060802@computing-services.oxford.ac.uk>
	<17101.6514.660395.934356@emt.wwp.brown.edu>
	<42CE6519.2040108@computing-services.oxford.ac.uk>
	<17102.30040.108970.269509@emt.wwp.brown.edu>
	<42CE784E.5050703@computing-services.oxford.ac.uk>
Message-ID: <17104.3571.800176.722834@emt.wwp.brown.edu>

Sebastian Rahtz writes:

> every "package" gets a doc directory. it may just have a changelog

Thanks for the explanation. It's obvious, once I poke around a bit,
but to be honest, I'd nevber put 2 and 2 together.

Will look at revised structure now ... (the one you posted Fri, 08
Jul 2005 15:43:00 +0100; speak quickly if it's not the most recent)

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jul  9 14:08:38 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 09 Jul 2005 19:08:38 +0100
Subject: [tei-council] directory layout
In-Reply-To: <ygf4qb59c56.fsf@chwpb.local>
References: <42CE90F4.90505@computing-services.oxford.ac.uk>
	<ygf4qb59c56.fsf@chwpb.local>
Message-ID: <42D012A6.3080400@computing-services.oxford.ac.uk>

>And we should have a copy of this "framework" version somewhere at a
>canonical place in the TEI webspace.
>  
>
yes, my idea is to remove all existing DTDs, schemas, stylesheets,
guidelines
from the web site and use just one copy in this new tree. obviously,
redirects from the
existing locations!

>Will you hand that tree over George at oXygen?  You need to speed up,
>since they are about to release a new version.
>  
>
will do

-- 
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 computing-services.oxford.ac.uk  Sat Jul  9 14:42:51 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 09 Jul 2005 19:42:51 +0100
Subject: [tei-council] regularizing names
In-Reply-To: <42D00D7C.3070506@brown.edu>
References: <a06200768bef49ef6ae2c@[128.148.157.102]>	<1120870078.42cf1ebe6111f@webmail.iu.edu>
	<42D00D7C.3070506@brown.edu>
Message-ID: <42D01AAB.1040704@computing-services.oxford.ac.uk>

if we're fooling around in there, please can slip in <death> to mirror
<birth> without further ado?

-- 
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 computing-services.oxford.ac.uk  Sat Jul  9 17:32:44 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 09 Jul 2005 22:32:44 +0100
Subject: [tei-council] face to face re TEI class system
In-Reply-To: <C0D504FF-660E-4F58-8FF2-AA3891A581E4@indiana.edu>
References: <42CE8F54.3020808@computing-services.oxford.ac.uk>	<c7cb1869a27eb3bebf849709d2a89a69@loria.fr>	<42CE949F.9020807@computing-services.oxford.ac.uk>
	<C0D504FF-660E-4F58-8FF2-AA3891A581E4@indiana.edu>
Message-ID: <42D0427C.5070200@computing-services.oxford.ac.uk>

John A. Walsh wrote:

>
> I'm interested in the class system and believe I could make useful 
> contributions.  If others agree, I'd like to participate in the 
> meeting, though I'm aware there's some concern about keeping the 
> group to a manageable size.  My feelings won't be hurt if I can't be 
> included.

I guess this raises the question of how we're going to structure and run
this meeting. It's
probably fair to say that any group larger than 3 or 4 can't just sit
around the table
and "discuss". Practical suggestions on how to use the available
brainpower, please?

-- 
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 computing-services.oxford.ac.uk  Sat Jul  9 18:34:05 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 09 Jul 2005 23:34:05 +0100
Subject: [tei-council] notes from today's conference call
In-Reply-To: <17102.60878.897985.297771@emt.wwp.brown.edu>
References: <17102.60878.897985.297771@emt.wwp.brown.edu>
Message-ID: <42D050DD.1050306@computing-services.oxford.ac.uk>

on datatypes:

"Concern was expressed over the general concept of permitting TEI
datatypes to further constrain or relax underlying W3C datatypes.
However, the opposite point of view, that it is important not to be
straight-jacketed by a single set of datatypes primarily intended for
business applications, was also expressed."

I am not sure this reflects the discussion. Perhaps

"Concern was expressed over the use of regexp-based extensions to W3C
datatypes, particularly in the duration datatype. There was disagreement
about the general principle of whether or not the TEI should force
itself to stick to strict W3C datatypes, but it was clear that the issue
required more discussion".

but perhaps my rewording is as biased towards my viewpoint as Syd's
wording is biased towards his :-}

-- 
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 computing-services.oxford.ac.uk  Sat Jul  9 18:37:04 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 09 Jul 2005 23:37:04 +0100
Subject: [tei-council] notes from today's conference call
In-Reply-To: <17102.60878.897985.297771@emt.wwp.brown.edu>
References: <17102.60878.897985.297771@emt.wwp.brown.edu>
Message-ID: <42D05190.3090904@computing-services.oxford.ac.uk>

I am not sure this is really correct:

"There were three suggestions on when such releases would occur: a
pre-defined timetable; when significant updates occur or have accrued,
based on the editors' judgement; and at Sebastian's readiness to do so. "

the third proposal was really that a separate Change Release Manager
should make the decision. but maybe
that was not made clear.

-- 
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 Jul  9 21:50:29 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 9 Jul 2005 21:50:29 -0400
Subject: [tei-council] notes from today's conference call
In-Reply-To: <42D050DD.1050306@computing-services.oxford.ac.uk>
References: <17102.60878.897985.297771@emt.wwp.brown.edu>
	<42D050DD.1050306@computing-services.oxford.ac.uk>
Message-ID: <17104.32485.84319.875725@emt.wwp.brown.edu>

Sebastian Rahtz writes:

> "Concern was expressed over the general concept of permitting TEI
> datatypes to further constrain or relax underlying W3C datatypes.
> However, the opposite point of view, that it is important not to be
> straight-jacketed by a single set of datatypes primarily intended
> for business applications, was also expressed."
> 
> I am not sure this reflects the discussion. Perhaps
> 
> "Concern was expressed over the use of regexp-based extensions to
> W3C datatypes, particularly in the duration datatype. There was
> disagreement about the general principle of whether or not the TEI
> should force itself to stick to strict W3C datatypes, but it was
> clear that the issue required more discussion".
> 
> but perhaps my rewording is as biased towards my viewpoint as Syd's
> wording is biased towards his :-}

Oh dear. You're quite right -- if read as including <valList>s my
description of your position makes you sound like a madman. My
apologies.

You did express it as a general concern, and then focused in on the
regexps, particularly on tei.data.duration.[1] Would you prefer we
just focused in on the pattern, perhaps of duration, for the minutes?
In either case, we may as well use the correct terminology:

  Concern was expressed over the use of W3C 'pattern' facets,
  particularly in the datatype 'tei.data.duration'. There was
  disagreement about the general principle of whether or not the TEI
  should force itself to stick to strict W3C datatypes, but it was
  clear that the issue required more discussion.

Would that do?

Note
----
[1] But I was presuming that was merely an example, as there are a
    half-dozen datatypes that are restricted by regexps. On the other
    hand, as mentioned in a previous discussion, I have to admit I
    don't really *like* the pattern I came up with for duration,
    whereas I think I like all the others.

From Syd_Bauman at Brown.edu  Sat Jul  9 21:52:36 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 9 Jul 2005 21:52:36 -0400
Subject: [tei-council] notes from today's conference call
In-Reply-To: <42D05190.3090904@computing-services.oxford.ac.uk>
References: <17102.60878.897985.297771@emt.wwp.brown.edu>
	<42D05190.3090904@computing-services.oxford.ac.uk>
Message-ID: <17104.32612.346281.385810@emt.wwp.brown.edu>

Sebastian Rahtz writes:
> I am not sure this is really correct:
> 
> "There were three suggestions on when such releases would occur: a
> pre-defined timetable; when significant updates occur or have
> accrued, based on the editors' judgement; and at Sebastian's
> readiness to do so. "
> 
> the third proposal was really that a separate Change Release
> Manager should make the decision. but maybe that was not made
> clear.

Certainly wasn't clear to me, but I distinctly heard Christian say
"Sebastian".

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 10 07:14:02 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 10 Jul 2005 12:14:02 +0100
Subject: [tei-council] notes from today's conference call
In-Reply-To: <17104.32485.84319.875725@emt.wwp.brown.edu>
References: <17102.60878.897985.297771@emt.wwp.brown.edu>	<42D050DD.1050306@computing-services.oxford.ac.uk>
	<17104.32485.84319.875725@emt.wwp.brown.edu>
Message-ID: <42D102FA.2090809@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>  Concern was expressed over the use of W3C 'pattern' facets,
>  particularly in the datatype 'tei.data.duration'. There was
>  disagreement about the general principle of whether or not the TEI
>  should force itself to stick to strict W3C datatypes, but it was
>  clear that the issue required more discussion.
>
>Would that do?
>  
>
sure

>[1] But I was presuming that was merely an example, as there are a
>    half-dozen datatypes that are restricted by regexps. On the other
>    hand, as mentioned in a previous discussion, I have to admit I
>    don't really *like* the pattern I came up with for duration,
>    whereas I think I like all the others.
>  
>
I am such an unthinking person, I can only really get to grips
to this by example and implementation, so I propose to do
some experiments by way of comment

-- 
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 Jul 10 08:30:05 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 10 Jul 2005 08:30:05 -0400
Subject: [tei-council] notes from today's conference call
In-Reply-To: <42D102FA.2090809@computing-services.oxford.ac.uk>
References: <17102.60878.897985.297771@emt.wwp.brown.edu>
	<42D050DD.1050306@computing-services.oxford.ac.uk>
	<17104.32485.84319.875725@emt.wwp.brown.edu>
	<42D102FA.2090809@computing-services.oxford.ac.uk>
Message-ID: <17105.5325.371678.71043@emt.wwp.brown.edu>

Note from 2005-07-08 conference call have been updated with both
Christian's and Sebastian's corrections. They are still at 
  http://www.tei-c.org/Council/tcm18.xml?style=printable

From lou.burnard at computing-services.oxford.ac.uk  Sun Jul 10 09:38:44 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 10 Jul 2005 14:38:44 +0100
Subject: [tei-council] notes from today's conference call
In-Reply-To: <42D102FA.2090809@computing-services.oxford.ac.uk>
References: <17102.60878.897985.297771@emt.wwp.brown.edu>	<42D050DD.1050306@computing-services.oxford.ac.uk>	<17104.32485.84319.875725@emt.wwp.brown.edu>
	<42D102FA.2090809@computing-services.oxford.ac.uk>
Message-ID: <42D124E4.7010803@computing-services.oxford.ac.uk>

The action on me, as I understood it at the time was not exactly to

"look at list of attributes that need to be assassinated, report back to 
Council which ones are trivial (e.g., because element is empty and there 
is only 1 such attribute), not difficult, or present real problems that 
might need this approach"

but rather to implement assassination in the trivial cases, only 
reporting back to Council where the victim refused to keel over or might 
have some shred of a defence against it.

However, Council will in any case be informed of all cases by virtue of 
the changelog reports.

Lou

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 10 18:07:07 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 10 Jul 2005 23:07:07 +0100
Subject: [tei-council] meeting technologies
Message-ID: <42D19C0B.7000705@computing-services.oxford.ac.uk>

We had an agenda item last week, missed out because Alex was absent,
about alternative
technologies for virtual council meetings.

I wonder if we can pursue this a little? I spent some time at
a conference last week at which we were encouraged
to experiment with various tools, including instant messaging
and Skype internet telephony. I was surprised to find that
the instant messaging conversations were quite reasonable
(we used IRC, but it could be anything).

Do  you all find the telephony a plausible method of communication?
Would you be interested in an alternate trial of IM?

Another more radical alternative would be video conferencing.
How many of you would be willing to risk 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 wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Jul 10 21:13:54 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 11 Jul 2005 10:13:54 +0900
Subject: [tei-council] notes from today's conference call
In-Reply-To: <17104.32612.346281.385810@emt.wwp.brown.edu> (Syd Bauman's
	message of "Sat, 9 Jul 2005 21:52:36 -0400")
References: <17102.60878.897985.297771@emt.wwp.brown.edu>
	<42D05190.3090904@computing-services.oxford.ac.uk>
	<17104.32612.346281.385810@emt.wwp.brown.edu>
Message-ID: <ygfeka6du0d.fsf@kanji.zinbun.kyoto-u.ac.jp>

Syd Bauman <Syd_Bauman at Brown.edu> writes:

> Sebastian Rahtz writes:
>> I am not sure this is really correct:
>> 
>> "There were three suggestions on when such releases would occur: a
>> pre-defined timetable; when significant updates occur or have
>> accrued, based on the editors' judgement; and at Sebastian's
>> readiness to do so. "
>> 
>> the third proposal was really that a separate Change Release
>> Manager should make the decision. but maybe that was not made
>> clear.
>
> Certainly wasn't clear to me, but I distinctly heard Christian say
> "Sebastian".

Which could be seen as a kind of shorthand to "Change Release
Manager", at least that was my intention.

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  Sun Jul 10 21:23:06 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 11 Jul 2005 10:23:06 +0900
Subject: [tei-council] meeting technologies
In-Reply-To: <42D19C0B.7000705@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Sun, 10 Jul 2005 23:07:07 +0100")
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>
Message-ID: <ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>

Sebastian Rahtz <sebastian.rahtz at computing-services.oxford.ac.uk> writes:

> We had an agenda item last week, missed out because Alex was absent,
> about alternative
> technologies for virtual council meetings.

This came out of a discussion we had in Paris, born out of the
frustration with the current infrastructure.

>
> I wonder if we can pursue this a little? I spent some time at
> a conference last week at which we were encouraged
> to experiment with various tools, including instant messaging
> and Skype internet telephony. I was surprised to find that
> the instant messaging conversations were quite reasonable
> (we used IRC, but it could be anything).

I am very open on this.  I'm not sure, if Skype is up to the task, but
IM (which I used for a grand total of about 30 minutes to day) sounds
promising.  

>
> Do  you all find the telephony a plausible method of communication?
> Would you be interested in an alternate trial of IM?

I am all in favor on this.

>
> Another more radical alternative would be video conferencing.
> How many of you would be willing to risk that?

For Mac users, there is always iChat, don't know about others and
compatibility issues.  

I suggest that we try some of these things in a small group and report
our findings to the list.  

I will volunteer to be part of this and suggest that we collect
another two or three (including sb from the US) and start discuss
things among this group.

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  Sun Jul 10 21:38:38 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 11 Jul 2005 10:38:38 +0900
Subject: [tei-council] regularizing names
In-Reply-To: <42D00D7C.3070506@brown.edu> (Julia Flanders's message of "Sat,
	09 Jul 2005 13:46:36 -0400")
References: <a06200768bef49ef6ae2c@[128.148.157.102]>
	<1120870078.42cf1ebe6111f@webmail.iu.edu> <42D00D7C.3070506@brown.edu>
Message-ID: <ygf64vidsv5.fsf@kanji.zinbun.kyoto-u.ac.jp>

(I have not seen John's post -- did it go to the list?)

Julia Flanders <Julia_Flanders at brown.edu> writes:

> I think you're right that this overlaps conceptually with key=, and I
> pondered this a bit yesterday. It seems to me that the distinction
> between key= and reg= is still that key= is a way of taking you to
> information about a person, and reg= is a way of providing (or taking
> you to) information about a name. In the situations Perry is
> envisioning, where name authority records are the source of
> information about the name, they also happen to provide that
> information by providing information about a person. But this is
> incidental, and might not always be the case.

But in cases where this is the case, it would be bothersome to have to
provide both.  We might need a mechanism that allows some control over
how to handle such cases.

>>And perhaps the guidelines should also discuss the option of pointing to an
>>external file dedicated to name regularizations.  For instance, if my project
>>consists of hundreds of commentaries on Romantic poetry, I don't need to repeat
>><regName authority="LCNAF" id="byron" >Byron, George Gordon Byron,
>>Baron</regName> in every document.  Rather, I could do something like this:
>>"...the dastardly and poisonous malignity of <persName
>>reg="myRegNames.xml#byron">Byron's</persName> most foul and treacherous
>>libel...," pointing to a master myRegNames.xml file.  Of course, this latter
>>approach has some potential overlap with the functionality of @key, if one
>>accepts that the key can be an id in an XML file as well as it could be a id in
>>a database.  But then the TEI is all about choices :-), so I don't see this as a
>>problem.

We do have a similar case (of referencing information from the text to
information in the header) with the socalled Gaiji module, where a list
of character description occurs in the Header, but one might in the
same way want to keep them in a separate file for collections.  There
are two (?) possibilities for this I can think of at the moment, 

* hardcode the reference like in  John's example above:
  <persName>reg="myRegNames.xml#byron">Byron's</persName>

* use bar pointers to the header and dereference from there, probably
  using XInclude:
  <persName>reg="#byron">Byron's</persName>

  and in the header:
  <profileDesc>
    <xi:include href="myRegnames.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
  ...

Of course, this is all up to the encoder, but we might want to include
an example that demonstrates this.

All the best,

Christian

-- 
 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From jawalsh at indiana.edu  Sun Jul 10 21:47:05 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Sun, 10 Jul 2005 20:47:05 -0500
Subject: [tei-council] meeting technologies
In-Reply-To: <ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>
	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>

>
> I suggest that we try some of these things in a small group and report
> our findings to the list.
>
> I will volunteer to be part of this and suggest that we collect
> another two or three (including sb from the US) and start discuss
> things among this group.

I have an iSight (video camera) and various IM accounts (ICQ, AIM,  
Yahoo, iChat), so I'd be happy to be part of the test group.

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

From jawalsh at indiana.edu  Sun Jul 10 21:48:05 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Sun, 10 Jul 2005 20:48:05 -0500
Subject: Fwd: [tei-council] regularizing names
References: <1120870078.42cf1ebe6111f@webmail.iu.edu>
Message-ID: <32F6167B-5D2E-42C3-98D4-C9312EEA3668@indiana.edu>

Here's my previous reply to Julia.  I meant to send it to the list,  
but it only went to Julia.

John
| John A. Walsh, Associate Director for Projects and Services
| Digital Library Program / Indiana University Libraries
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 Fax:812-856-2062 <mailto:jawalsh at indiana.edu>

Begin forwarded message:

> From: "John A. Walsh" <jawalsh at indiana.edu>
> Date: July 8, 2005 7:47:58 PM EST
> To: Julia Flanders <Julia_Flanders at Brown.edu>
> Subject: Re: [tei-council] regularizing names
>
>
> Julia and Perry,
>
> This seems to me to be a very elegant solution.
>
> I'm wondering where in the header these <regName> elements should  
> live.  It
> seems that <profileDesc> is the logical place, since it groups  
> together lots of
> other non-bibliographic metadata.  <profileDesc> could include a
> <regularization> (or <regularisation>) element that groups together  
> the many
> <regName> elements.
>
> And perhaps the guidelines should also discuss the option of  
> pointing to an
> external file dedicated to name regularizations.  For instance, if  
> my project
> consists of hundreds of commentaries on Romantic poetry, I don't  
> need to repeat
> <regName authority="LCNAF" id="byron" >Byron, George Gordon Byron,
> Baron</regName> in every document.  Rather, I could do something  
> like this:
> "...the dastardly and poisonous malignity of <persName
> reg="myRegNames.xml#byron">Byron's</persName> most foul and  
> treacherous
> libel...," pointing to a master myRegNames.xml file.  Of course,  
> this latter
> approach has some potential overlap with the functionality of @key,  
> if one
> accepts that the key can be an id in an XML file as well as it  
> could be a id in
> a database.  But then the TEI is all about choices :-), so I don't  
> see this as a
> problem.
>
> John
> -- 
> | John A. Walsh, Associate Director for Projects and Services
> | Digital Library Program / Indiana University Libraries
> | Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
> | Voice:812-855-8758 Fax:812-856-2062 <mailto:jawalsh at indiana.edu>
>
>
> Quoting Julia Flanders <Julia_Flanders at Brown.edu>:
>
>
>> Here's what Perry and I have come up with concerning the
>> regularization of names.
>>
>> We propose, tentatively, that in P5 we handle the regularization of
>> names as follows:
>>
>> Name elements (<name> and the other "primary" name elements including
>> <persName>, <placeName>, <orgName>, <geogName>) may carry a reg=
>> attribute, which points to a <regName> element which contains
>> information on regularization. This element might live in the TEI
>> header or in some other convenient place. The datatype for reg= would
>> be tei.data.code. The element name (<regName> as against <reg>) is
>> chosen to help distinguish the function of this regularization
>> structure from other kinds of regularization in the document.
>>
>> The nested naming elements such as <foreName>, <surname>, etc.--i.e.
>> those which cannot occur on their own but must be nested inside a
>> primary naming element--would not carry the reg= attribute and cannot
>> be regularized independently. We considered a mechanism for doing
>> this and if any Council members think it would be a good idea we can
>> add this bit.
>>
>> The <regName> element may either contain a regularized version of the
>> name as its content, or it may carry a pointer to an external
>> resource (either locally maintained or an authority file external to
>> the project, such as Library of Congress Name Authority files). It
>> could also do both, and we don't see a need to police this choice
>> (e.g. by making these options exclusive).
>>
>> The <regName> element would carry three attributes:
>> --authority=  indicates what authority, if any, is being used as the
>> source of the regularization, with values such as "NACO", other
>> possibilities
>> --url= (or target=) points to an external resource
>> --xml:id= allows the element to be pointed to from the naming element
>> in the text.
>>
>> Example:
>>
>> <regName authority="NACO" xml:id="rn17">Clinton, William J.</regName>
>> <regName authority="NACO" xml:id="rn18">Aldrin, Edwin Eugene, Jr.</ 
>> regName>
>>
>> <!-- above <regName> elements may be somewhere in <teiHeader> or  
>> <hyperDiv>,
>>             and may be part of a new prosopographic element -->
>> <!-- ... -->
>> <name reg="#rn17">Bill Clinton</name>
>> <persName reg="#rn18">Buzz Aldrin</persName>
>>
>> We are still concerned about how this use of reg= and <regName> will
>> fit in with other forms of regularization (e.g. spelling). However,
>> since all other uses of reg= will probably now be addressed as child
>> elements, the possibility of confusion is diminished.
>>
>> Comments welcome--
>>
>> Julia
>> _______________________________________________
>> 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 Jul 11 03:31:11 2005
From: james.cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Mon, 11 Jul 2005 08:31:11 +0100 (BST)
Subject: [tei-council] Re: Meeting technologies
Message-ID: <20050711073111.D5B1C226CA@webmail218.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/20050711/463443fb/attachment.ksh 

From lou.burnard at computing-services.oxford.ac.uk  Mon Jul 11 16:44:37 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 11 Jul 2005 21:44:37 +0100
Subject: [tei-council] regularizing names
In-Reply-To: <a06200768bef49ef6ae2c@[128.148.157.102]>
References: <a06200768bef49ef6ae2c@[128.148.157.102]>
Message-ID: <42D2DA35.8040007@computing-services.oxford.ac.uk>

The main problem I have with this is that all the examples cited seem to 
be about linking the name to a PERSON not to a NAME, in which case the 
existing key attribute would surely be more appropriate? (That's not to 
say that having a <regName> child within <person> wouldn't be a good 
idea). But the only use for having both a reg attribute and a key 
attribute on a name ought to be for one to regularize the name, and the 
other to regularize the thing-named. In which case, we have to be able 
to support the reg attribute on components of names, e.g.
<name key="JF">
<forename reg="JULIA">Juley</forename>
<surname reg="FLANDERS">Flanderes</surname>
</name>

<person ident="JF">
<regName>
<forename ident="JULIA">Julia</forename>
<surname ident="FLANDERS">Flanders</surname>
</regName>
<!-- other demographic info here -->
</person>

[I've used co-labelling here rather than ID/IDREF but the same principle 
applies]

in haste

Lou
Julia Flanders wrote:

> Here's what Perry and I have come up with concerning the 
> regularization of names.
>
> We propose, tentatively, that in P5 we handle the regularization of 
> names as follows:
>
> Name elements (<name> and the other "primary" name elements including 
> <persName>, <placeName>, <orgName>, <geogName>) may carry a reg= 
> attribute, which points to a <regName> element which contains 
> information on regularization. This element might live in the TEI 
> header or in some other convenient place. The datatype for reg= would 
> be tei.data.code. The element name (<regName> as against <reg>) is 
> chosen to help distinguish the function of this regularization 
> structure from other kinds of regularization in the document.
>
> The nested naming elements such as <foreName>, <surname>, etc.--i.e. 
> those which cannot occur on their own but must be nested inside a 
> primary naming element--would not carry the reg= attribute and cannot 
> be regularized independently. We considered a mechanism for doing this 
> and if any Council members think it would be a good idea we can add 
> this bit.
>
> The <regName> element may either contain a regularized version of the 
> name as its content, or it may carry a pointer to an external resource 
> (either locally maintained or an authority file external to the 
> project, such as Library of Congress Name Authority files). It could 
> also do both, and we don't see a need to police this choice (e.g. by 
> making these options exclusive).
>
> The <regName> element would carry three attributes:
> --authority= indicates what authority, if any, is being used as the 
> source of the regularization, with values such as "NACO", other 
> possibilities
> --url= (or target=) points to an external resource
> --xml:id= allows the element to be pointed to from the naming element 
> in the text.
>
> Example:
>
> <regName authority="NACO" xml:id="rn17">Clinton, William J.</regName>
> <regName authority="NACO" xml:id="rn18">Aldrin, Edwin Eugene, 
> Jr.</regName>
>
> <!-- above <regName> elements may be somewhere in <teiHeader> or 
> <hyperDiv>,
> and may be part of a new prosopographic element -->
> <!-- ... -->
> <name reg="#rn17">Bill Clinton</name>
> <persName reg="#rn18">Buzz Aldrin</persName>
>
> We are still concerned about how this use of reg= and <regName> will 
> fit in with other forms of regularization (e.g. spelling). However, 
> since all other uses of reg= will probably now be addressed as child 
> elements, the possibility of confusion is diminished.
>
> Comments welcome--
>
> Julia
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
>

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jul 12 05:53:57 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 12 Jul 2005 10:53:57 +0100
Subject: [tei-council] release of P5
Message-ID: <42D39335.1050302@computing-services.oxford.ac.uk>

In case anyone is wondering, I have got the material ready for this grand
new release, but I am waiting for confirmation from George Bina that he is
happy with it all in oXygen.  As soon as he says it works for him, I'll
make the release on Sourceforge, and make an announcement on TEI-L

-- 
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 computing-services.oxford.ac.uk  Tue Jul 12 18:49:14 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 12 Jul 2005 23:49:14 +0100
Subject: [tei-council] next meeting
Message-ID: <42D448EA.5010102@computing-services.oxford.ac.uk>

more than half of you have not been to meetomatic to tell me
when you can do the next telco....

-- 
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 nsmith at email.unc.edu  Wed Jul 13 13:47:06 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Wed, 13 Jul 2005 13:47:06 -0400 (Eastern Daylight Time)
Subject: [tei-council] Organization of the CO chapter
In-Reply-To: <42D2DA35.8040007@computing-services.oxford.ac.uk>
Message-ID: <Pine.WNT.4.10.10507131341190.3988-100000@AALCD49.lib.unc.edu>

Dear colleagues:

Per your request, John and I are in the process of reviewing the CO
chapter (Elements Available in all TEI Documents.) As we mentioned in our
short report submitted before the last conference call, quite a challenge
is to decide whether the chapter needs a dramatic reorganization. We would
like to solicit your ideas and would like to sense a level of
dissatisfaction (if any) about the current structure of the CO.  
Thinking more about this, both John and I came up with three possible
solutions (and/or combinations of them):

1.	leave the current organization (with some inevitable tweaking to
bring it up to the conformance with P5). As you know, there are currently
11 sections in the chapter, which is a lot, but not too overwhelming. Plus
sections have a really good prose that would be too bad to loose. 
2.	organize all the elements by model classes 
3.	provide an alphabetical list of all elements (I would like to have
it as an option, but not as the only one, but in addition to the #1 or #2)

What do you think? Any suggestions will be greatly appreciated.

Best, ns

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jul 13 14:12:53 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 13 Jul 2005 19:12:53 +0100
Subject: [tei-council] Organization of the CO chapter
In-Reply-To: <Pine.WNT.4.10.10507131341190.3988-100000@AALCD49.lib.unc.edu>
References: <Pine.WNT.4.10.10507131341190.3988-100000@AALCD49.lib.unc.edu>
Message-ID: <42D559A5.9030401@computing-services.oxford.ac.uk>

Natasha Smith wrote:

>1.	leave the current organization (with some inevitable tweaking to
>bring it up to the conformance with P5). As you know, there are currently
>11 sections in the chapter, which is a lot, but not too overwhelming. Plus
>sections have a really good prose that would be too bad to loose. 
>2.	organize all the elements by model classes 
>3.	provide an alphabetical list of all elements (I would like to have
>it as an option, but not as the only one, but in addition to the #1 or #2)
>
>  
>
#3 can be provided automatically, so there is not much point
rearranging CO to suit.

#2 would depend a lot on a really succesful class reworking. and anyway,
it seems arsy-versy. the chapter should divide up the elements into
interesting groups ("linking", "naming", whatever), and the class system
should assist people to follow it.

personally, I'd cut this chapter down to the inline elements, move "lists"
to the next chapter, and find a new home for verse and drama.

6.10 "reference systems" seems somehow out of place too, can that walk
to chapter 14?

-- 
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 Jul 13 14:27:23 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 13 Jul 2005 14:27:23 -0400
Subject: [tei-council] where is the HOWTO?
Message-ID: <17109.23819.667392.573084@emt.wwp.brown.edu>

"Welcome back, Syd"
Thank you. Sorry for being out-of-touch. Due to a pretty poorly timed
and annoyingly long (6 hrs) power outage in my home town, and a few
other circumstances, I basically haven't read e-mail since Monday. So
if this has been dealt with or answered already, my apologies. Also,
I see that there are several postings to this list since then, which
I will be trying to get to over the next few days.

James -- where is the canonical version of your "HOWTO Build P5" (aka
"CVS ReadMe") document? There is a copy at ../Council/tcw06.xml, but

a) I have a vague recollection that you or Lou moved it elsewhere,
   too?

b) When I load that file, Cocoon has transformed it from what I
   believe is supposed to be TEI P5 into plain text (wrapped in
   <html></html>), rather than lovely styled HTML. I suspect this
   means there is an error in the encoding, at least as far as
   Sebastian's stylesheet is concerned. The only error I notice at
   first glance is an id= that should be an xml:id=, but I don't
   think that would break the stylesheet.

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jul 13 14:32:01 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 13 Jul 2005 19:32:01 +0100
Subject: [tei-council] where is the HOWTO?
In-Reply-To: <17109.23819.667392.573084@emt.wwp.brown.edu>
References: <17109.23819.667392.573084@emt.wwp.brown.edu>
Message-ID: <42D55E21.9010808@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>b) When I load that file, Cocoon has transformed it from what I
>   believe is supposed to be TEI P5 into plain text (wrapped in
>   <html></html>), rather than lovely styled HTML. I suspect this
>   means there is an error in the encoding, at least as far as
>   Sebastian's stylesheet is concerned. The only error I notice at
>   first glance is an id= that should be an xml:id=, but I don't
>   think that would break the stylesheet.
>  
>
the Cocoon setup does TEI P4 only at present if it meets *.xml
(cf discussion on TEI-L).

I could easily have it do TEI P5 as well, but only if someone
specifies a naming scheme for files.

-- 
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 Jul 13 15:00:44 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 13 Jul 2005 20:00:44 +0100 (BST)
Subject: [tei-council] where is the HOWTO?
In-Reply-To: <42D55E21.9010808@computing-services.oxford.ac.uk>
References: <17109.23819.667392.573084@emt.wwp.brown.edu>
	<42D55E21.9010808@computing-services.oxford.ac.uk>
Message-ID: <20050713190044.DE7FF2DE04@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/20050713/ff9779ad/attachment.ksh 

From james.cummings at computing-services.oxford.ac.uk  Wed Jul 13 16:16:10 2005
From: james.cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 13 Jul 2005 21:16:10 +0100 (BST)
Subject: [tei-council] where is the HOWTO?
In-Reply-To: <20050713190044.DE7FF2DE04@webmail217.herald.ox.ac.uk>
References: <17109.23819.667392.573084@emt.wwp.brown.edu>
	<42D55E21.9010808@computing-services.oxford.ac.uk>
	<20050713190044.DE7FF2DE04@webmail217.herald.ox.ac.uk>
Message-ID: <20050713201610.75CF62DE04@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/20050713/43431ad2/attachment.ksh 

From james.cummings at computing-services.oxford.ac.uk  Wed Jul 13 16:16:40 2005
From: james.cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 13 Jul 2005 21:16:40 +0100 (BST)
Subject: [tei-council] where is the HOWTO?
Message-ID: <20050713201640.E889E2DE04@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/20050713/0863ed42/attachment.ksh 

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jul 13 18:49:14 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 14 Jul 2005 07:49:14 +0900
Subject: [tei-council] Ne release of P5
Message-ID: <ygfeka2coet.fsf@kanji.zinbun.kyoto-u.ac.jp>

Council members,

Over at the TEI-L, Sebastian posted the announcement for the new
development release of P5.  All looked very nice, except one line,
which caught my eye --

* new <biblItem> element added

Sebastian, if you look at the minutes from the Paris meeting, you will
see that there is no agreement to add (or now, keep) biblItem.  In
fact, we were supposed to debate how the other bibl s can do what
some people think biblItem is needed for, rather than go with
biblItem. Syd is doing some work do evaluate this, but was not ready
last Friday, thus it got postponed.  

It looks therefore like a PR desaster to me at the moment. We should
post announcements like the current one first to the council list for
review and then go public with them, I think.

The other question is what to do now?  I would propose to post an
additional note that explains that biblItem has been added, but not
been approved, so it might go away anytime.  We might then take the
opportunity to solicit opinions about it as well.

What do the other council members think?

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 Jul 13 19:49:46 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 14 Jul 2005 00:49:46 +0100
Subject: [tei-council] Ne release of P5
In-Reply-To: <ygfeka2coet.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <ygfeka2coet.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <42D5A89A.2000204@computing-services.oxford.ac.uk>

Actually, the note Sebastian posted was written (and signed) by me, so 
it isn't really fair to blame him for its content.

I took the view that, since we do have a new element biblItem in this 
release, it is as well admit to its existence. I don't see that it's a 
PR disaster -- it's the truth of the current situation that we have some 
unsatisfactory work which needs further examination -- quite a lot of it 
in fact, not just this element.

What harm will there be in later saying "biblItem" removed -- if that's 
what we decide to do?

I dont think there's any need to call attention to the fragility of this 
particular element (I'm sure there are plenty of others equally fragile) 
but would be curious to know if other council members feel we should do so.

Lou

Christian Wittern wrote:

>Council members,
>
>Over at the TEI-L, Sebastian posted the announcement for the new
>development release of P5.  All looked very nice, except one line,
>which caught my eye --
>
>* new <biblItem> element added
>
>Sebastian, if you look at the minutes from the Paris meeting, you will
>see that there is no agreement to add (or now, keep) biblItem.  In
>fact, we were supposed to debate how the other bibl s can do what
>some people think biblItem is needed for, rather than go with
>biblItem. Syd is doing some work do evaluate this, but was not ready
>last Friday, thus it got postponed.  
>
>It looks therefore like a PR desaster to me at the moment. We should
>post announcements like the current one first to the council list for
>review and then go public with them, I think.
>
>The other question is what to do now?  I would propose to post an
>additional note that explains that biblItem has been added, but not
>been approved, so it might go away anytime.  We might then take the
>opportunity to solicit opinions about it as well.
>
>What do the other council members think?
>
>All the best,
>
>Christian
>
>
>
>  
>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Jul 13 21:48:28 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 14 Jul 2005 10:48:28 +0900
Subject: [tei-council] Ne release of P5
In-Reply-To: <42D5A89A.2000204@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Thu, 14 Jul 2005 00:49:46 +0100")
References: <ygfeka2coet.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<42D5A89A.2000204@computing-services.oxford.ac.uk>
Message-ID: <ygf8y0acg43.fsf@kanji.zinbun.kyoto-u.ac.jp>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> Actually, the note Sebastian posted was written (and signed) by me, so
> it isn't really fair to blame him for its content.

Sorry, that escaped me. However, I am not blaming him or you, I see
this as one step towards a better procedure to handle this.

> I took the view that, since we do have a new element biblItem in this
> release, it is as well admit to its existence. I don't see that it's a
> PR disaster -- it's the truth of the current situation that we have
> some unsatisfactory work which needs further examination -- quite a
> lot of it in fact, not just this element.
>
> What harm will there be in later saying "biblItem" removed -- if
> that's what we decide to do?

Although P5 is clearly marked as in development, I do think that once
we said publicly "we added <blurb>" the impression the public will get
is that we made a decision and plan to go with that.

Having it sitting in the CVS source without further comment, pending a
decision is something rather different.  biblItem is a special case in
that, as I was told by you, it entered life in P5 as a replacement to
biblStruct, which was a mistake, which caused quite some grief for a
while.  Thinking of it more clearly in Paris, we decided that we
probably do not want biblItem, and rather tweak the other three bibl*
elements.  Given this situation, I think explicitly announcing it as
"newly added" does give a wrong impression. 

>
> I dont think there's any need to call attention to the fragility of
> this particular element (I'm sure there are plenty of others equally
> fragile) but would be curious to know if other council members feel we
> should do so.

There are others, I agree, but the situation with these others is
different from biblItem.

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 computing-services.oxford.ac.uk  Thu Jul 14 04:01:47 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Thu, 14 Jul 2005 09:01:47 +0100
Subject: [tei-council] Ne release of P5
In-Reply-To: <ygfeka2coet.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <ygfeka2coet.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <42D61BEB.7000803@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>It looks therefore like a PR desaster to me at the moment. We should
>post announcements like the current one first to the council list for
>review and then go public with them, I think.
>  
>
agreed, it would probably have been sensible to review the
release note.

>The other question is what to do now?  I would propose to post an
>additional note that explains that biblItem has been added, but not
>been approved, so it might go away anytime. 
>

I agree with Lou that it would be counter-productive
to draw attention to this one element.

When we put out an announcement saying "the set of elements and
attributes is now frozen for 1 year", thats the time to really be sure

sebastian

From pwillett at umich.edu  Thu Jul 14 09:09:02 2005
From: pwillett at umich.edu (Perry Willett)
Date: Thu, 14 Jul 2005 09:09:02 -0400
Subject: [tei-council] Ne release of P5
In-Reply-To: <ygfeka2coet.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <002401c58875$3799e1b0$922bd38d@CLUBSODA>

I think "PR disaster" is a little strong. We should try not to make
premature announcements, but if we say in the future, "after further
research, we decided to drop <biblItem> and recommend x instead," I don't
think people will rise up and call for our heads on a stick. 

Perry

-----Original Message-----
From: tei-council-bounces at lists.village.Virginia.EDU
[mailto:tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of
Christian Wittern
Sent: Wednesday, July 13, 2005 6:49 PM
To: tei-council at lists.village.Virginia.EDU
Subject: [tei-council] Ne release of P5

Council members,

Over at the TEI-L, Sebastian posted the announcement for the new
development release of P5.  All looked very nice, except one line,
which caught my eye --

* new <biblItem> element added

Sebastian, if you look at the minutes from the Paris meeting, you will
see that there is no agreement to add (or now, keep) biblItem.  In
fact, we were supposed to debate how the other bibl s can do what
some people think biblItem is needed for, rather than go with
biblItem. Syd is doing some work do evaluate this, but was not ready
last Friday, thus it got postponed.  

It looks therefore like a PR desaster to me at the moment. We should
post announcements like the current one first to the council list for
review and then go public with them, I think.

The other question is what to do now?  I would propose to post an
additional note that explains that biblItem has been added, but not
been approved, so it might go away anytime.  We might then take the
opportunity to solicit opinions about it as well.

What do the other council members think?

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

From Syd_Bauman at Brown.edu  Thu Jul 14 16:32:55 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 14 Jul 2005 16:32:55 -0400
Subject: [tei-council] meeting technologies
In-Reply-To: <D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>
	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>
Message-ID: <17110.52215.774095.934130@emt.wwp.brown.edu>

SR> Do you all find the telephony a plausible method of
SR> communication? Would you be interested in an alternate trial of
SR> IM?

I would be happy to try telephony. I would be very happy to have some
sort of IM system available to us during the conference call, so that
we can type examples and exact syntax at each other. But I don't
think I like the idea of IM replacing the call, for a variety of
reasons, not the least of which is that I have severe bilateral
wrist tendonitis.

SR> Another more radical alternative would be video conferencing. How
SR> many of you would be willing to risk that?

Not really interested, at least not yet. It doesn't seem like the
advantages of seeing your smiling face outweigh the pain-in-the-neck
factor here.

From Syd_Bauman at Brown.edu  Thu Jul 14 16:52:33 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 14 Jul 2005 16:52:33 -0400
Subject: Fwd: [tei-council] regularizing names
In-Reply-To: <32F6167B-5D2E-42C3-98D4-C9312EEA3668@indiana.edu>
References: <1120870078.42cf1ebe6111f@webmail.iu.edu>
	<32F6167B-5D2E-42C3-98D4-C9312EEA3668@indiana.edu>
Message-ID: <17110.53393.545709.398079@emt.wwp.brown.edu>

JW> And perhaps the guidelines should also discuss the option of
JW> pointing to an external file dedicated to name regularizations.
JW> For instance, if my project consists of hundreds of commentaries
JW> on Romantic poetry, I don't need to repeat <regName
JW> authority="LCNAF" id="byron" >Byron, George Gordon Byron,
JW> Baron</regName> in every document. Rather, I could do something
JW> like this: "...the dastardly and poisonous malignity of <persName
JW> reg="myRegNames.xml#byron">Byron's</persName> most foul and
JW> treacherous libel...," pointing to a master myRegNames.xml file.

One teeny additional point to consider, is that (as currently
concieved) this would require changing the datatype of reg= from
tei.data.code (points internally) to tei.data.key (points anywhere).

Which may mean we should reconsider whether or not reg= should be
tei.data.code.

From Julia_Flanders at Brown.edu  Thu Jul 14 17:38:15 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 14 Jul 2005 17:38:15 -0400
Subject: [tei-council] regularizing names
In-Reply-To: <42D2DA35.8040007@computing-services.oxford.ac.uk>
References: <a06200768bef49ef6ae2c@[128.148.157.102]>
	<42D2DA35.8040007@computing-services.oxford.ac.uk>
Message-ID: <a062007cdbefc841864df@[128.148.157.102]>

Perry and I did discuss the possibility of providing regularization 
of the individual name components; I append our example below.

Your point about the name linking to a PERSON rather than to a NAME 
is an interesting problem. The intention of the examples we gave, and 
their underlying spirit, is that the <regName> element documents a 
name, not a person; it may point onward to a person (i.e. a name 
authority record about a person), but it needn't. However, I can see 
that that pointing inflects the semantics of the <regName> element: 
it can't simply regularize once it points to an authority record.

I guess the question is whether this is a practical problem. In the 
P4 universe, people often use reg= with an implicit semantics of key= 
(in the sense that a given regularization really does refer to a 
person, and may even be used explicitly that way) in cases where they 
have only unique name-person mappings. We regard this as showing want 
of judgment (because they might in future come across another John 
Smith) but not as a tagging error, as long as the value of reg= is 
something like "Smith, John" rather than "jsm0111". In the system 
we're discussing now, is there a disadvantage to using the same 
element for both functions? that is, if you want to regularize the 
name, you can do so; if you want to link to information about a 
person, you can do so. Is it ever unclear which is happening?

If you had a document in which there were many different people named 
John Smith, all spelled and abbreviated in wacky ways, all the 
references might legitimately point to a single <regName> element 
that regularized them all simply as names. If you wanted to use 
<regName> to link these to persons, you would need instead multiple 
<regName> elements with links to person data. Or you could just use 
key= if you didn't want to regularize the names at all.

But I may not be taking sufficient account of the advantages of 
knowing which is meant, programmatically, without having to draw 
inferences based on what kind of information is present.

Here's the example we had come up with for encoding/regularizing name parts:

<regName xml:id="rn17">Clinton, William J.</regName>
<regName xml:id="rn18">
	<regName xml:id="rn18.1">Jones</regName>,
	<regName xml:id="rn18.2">Herbert</regName>
	<regName xml:id="rn18.3">Fizzlebaum</regName></regName>
<!-- above <regName> elements may be somewhere in <teiHeader> or <hyperDiv>,
            and may be part of a new prosopographic element -->
<!-- ... -->
<name reg="#rn17">Bill Clinton</name>
<persName reg="#rn18"><foreName reg="#rn18.1">Herb</foreName> 
<foreName reg="#rn18.3">F.</foreName> <foreName 
reg="#rn18.3">"Fizzy"</foreName> <surname 
reg="#rn18.1">Jones</surname></persName>

Julia

At 9:44 PM +0100 7/11/05, Lou Burnard wrote:
>The main problem I have with this is that all the examples cited 
>seem to be about linking the name to a PERSON not to a NAME, in 
>which case the existing key attribute would surely be more 
>appropriate? (That's not to say that having a <regName> child within 
><person> wouldn't be a good idea). But the only use for having both 
>a reg attribute and a key attribute on a name ought to be for one to 
>regularize the name, and the other to regularize the thing-named. In 
>which case, we have to be able to support the reg attribute on 
>components of names, e.g.
><name key="JF">
><forename reg="JULIA">Juley</forename>
><surname reg="FLANDERS">Flanderes</surname>
></name>
>
><person ident="JF">
><regName>
><forename ident="JULIA">Julia</forename>
><surname ident="FLANDERS">Flanders</surname>
></regName>
><!-- other demographic info here -->
></person>
>
>[I've used co-labelling here rather than ID/IDREF but the same 
>principle applies]
>
>in haste
>
>Lou
>Julia Flanders wrote:
>
>>  Here's what Perry and I have come up with concerning the 
>>regularization of names.
>>
>>  We propose, tentatively, that in P5 we handle the regularization 
>>of names as follows:
>>
>>  Name elements (<name> and the other "primary" name elements 
>>including <persName>, <placeName>, <orgName>, <geogName>) may carry 
>>a reg= attribute, which points to a <regName> element which 
>>contains information on regularization. This element might live in 
>>the TEI header or in some other convenient place. The datatype for 
>>reg= would be tei.data.code. The element name (<regName> as against 
>><reg>) is chosen to help distinguish the function of this 
>>regularization structure from other kinds of regularization in the 
>>document.
>>
>>  The nested naming elements such as <foreName>, <surname>, 
>>etc.--i.e. those which cannot occur on their own but must be nested 
>>inside a primary naming element--would not carry the reg= attribute 
>>and cannot be regularized independently. We considered a mechanism 
>>for doing this and if any Council members think it would be a good 
>>idea we can add this bit.
>>
>>  The <regName> element may either contain a regularized version of 
>>the name as its content, or it may carry a pointer to an external 
>>resource (either locally maintained or an authority file external 
>>to the project, such as Library of Congress Name Authority files). 
>>It could also do both, and we don't see a need to police this 
>>choice (e.g. by making these options exclusive).
>>
>>  The <regName> element would carry three attributes:
>>  --authority= indicates what authority, if any, is being used as 
>>the source of the regularization, with values such as "NACO", other 
>>possibilities
>>  --url= (or target=) points to an external resource
>>  --xml:id= allows the element to be pointed to from the naming 
>>element in the text.
>>
>>  Example:
>>
>>  <regName authority="NACO" xml:id="rn17">Clinton, William J.</regName>
>>  <regName authority="NACO" xml:id="rn18">Aldrin, Edwin Eugene, Jr.</regName>
>>
>>  <!-- above <regName> elements may be somewhere in <teiHeader> or <hyperDiv>,
>>  and may be part of a new prosopographic element -->
>>  <!-- ... -->
>>  <name reg="#rn17">Bill Clinton</name>
>>  <persName reg="#rn18">Buzz Aldrin</persName>
>>
>>  We are still concerned about how this use of reg= and <regName> 
>>will fit in with other forms of regularization (e.g. spelling). 
>>However, since all other uses of reg= will probably now be 
>>addressed as child elements, the possibility of confusion is 
>>diminished.
>>
>>  Comments welcome--
>>
>>  Julia
>>  _______________________________________________
>>  tei-council mailing list
>>  tei-council at lists.village.Virginia.EDU
>>  http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>>

From sschreib at umd.edu  Thu Jul 14 18:32:02 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Thu, 14 Jul 2005 18:32:02 -0400
Subject: [tei-council] meeting technologies
In-Reply-To: <17110.52215.774095.934130@emt.wwp.brown.edu>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>
	<17110.52215.774095.934130@emt.wwp.brown.edu>
Message-ID: <42D6E7E2.2060101@umd.edu>

We switched to IM meetings for teiPublisher because the phone calls were 
too expensive for some of the team. They were far less satisfactory than 
telephone calls, and writing up minutes took forever as one had to wade 
through the entire chat session.

susan

Syd Bauman wrote:

>SR> Do you all find the telephony a plausible method of
>SR> communication? Would you be interested in an alternate trial of
>SR> IM?
>
>I would be happy to try telephony. I would be very happy to have some
>sort of IM system available to us during the conference call, so that
>we can type examples and exact syntax at each other. But I don't
>think I like the idea of IM replacing the call, for a variety of
>reasons, not the least of which is that I have severe bilateral
>wrist tendonitis.
>
>
>SR> Another more radical alternative would be video conferencing. How
>SR> many of you would be willing to risk that?
>
>Not really interested, at least not yet. It doesn't seem like the
>advantages of seeing your smiling face outweigh the pain-in-the-neck
>factor here.
>
>_______________________________________________
>tei-council mailing list
>tei-council at lists.village.Virginia.EDU
>http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>  
>

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742

Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib at umd.edu

From sebastian.rahtz at computing-services.oxford.ac.uk  Thu Jul 14 19:08:48 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 15 Jul 2005 00:08:48 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <42D6E7E2.2060101@umd.edu>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>	<17110.52215.774095.934130@emt.wwp.brown.edu>
	<42D6E7E2.2060101@umd.edu>
Message-ID: <42D6F080.6050603@computing-services.oxford.ac.uk>

Susan Schreibman wrote:

> We switched to IM meetings for teiPublisher because the phone calls
> were too expensive for some of the team. They were far less
> satisfactory than telephone calls, and writing up minutes took forever
> as one had to wade through the entire chat session.
>
so have you switched back to phone?

-- 
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 computing-services.oxford.ac.uk  Thu Jul 14 19:10:11 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Fri, 15 Jul 2005 00:10:11 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <17110.52215.774095.934130@emt.wwp.brown.edu>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>
	<17110.52215.774095.934130@emt.wwp.brown.edu>
Message-ID: <42D6F0D3.1020303@computing-services.oxford.ac.uk>

Syd Bauman wrote:

> But I don't
>think I like the idea of IM replacing the call, for a variety of
>reasons, not the least of which is that I have severe bilateral
>wrist tendonitis.
>  
>
thats a fair point; i suppose we need a hybrid system; Skype
would do the job, probably.

>
>SR> Another more radical alternative would be video conferencing. How
>SR> many of you would be willing to risk that?
>
>Not really interested, at least not yet. It doesn't seem like the
>advantages of seeing your smiling face outweigh the pain-in-the-neck
>factor here.
>  
>
why is it a pain?

-- 
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 Jul 14 20:45:03 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 15 Jul 2005 09:45:03 +0900
Subject: [tei-council] meeting technologies
In-Reply-To: <42D6F0D3.1020303@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Fri, 15 Jul 2005 00:10:11 +0100")
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>
	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>
	<17110.52215.774095.934130@emt.wwp.brown.edu>
	<42D6F0D3.1020303@computing-services.oxford.ac.uk>
Message-ID: <ygfhdewx5gw.fsf@chwpb.local>

Sebastian Rahtz <sebastian.rahtz at computing-services.oxford.ac.uk> writes:

> Syd Bauman wrote:
>
>> But I don't
>>think I like the idea of IM replacing the call, for a variety of
>>reasons, not the least of which is that I have severe bilateral
>>wrist tendonitis.
>>  
>>
> thats a fair point; i suppose we need a hybrid system; Skype
> would do the job, probably.

Do you mean for IM? Their phone conferences allow only 4
participants.  For IM, there surely are other (non-proprietory?)
options?

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 Jul 14 20:48:01 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 15 Jul 2005 09:48:01 +0900
Subject: [tei-council] meeting technologies
In-Reply-To: <42D6E7E2.2060101@umd.edu> (Susan Schreibman's message of "Thu,
	14 Jul 2005 18:32:02 -0400")
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>
	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>
	<17110.52215.774095.934130@emt.wwp.brown.edu>
	<42D6E7E2.2060101@umd.edu>
Message-ID: <ygfd5pkx5by.fsf@chwpb.local>

Susan Schreibman <sschreib at umd.edu> writes:

> We switched to IM meetings for teiPublisher because the phone calls
> were too expensive for some of the team. They were far less
> satisfactory than telephone calls, and writing up minutes took forever
> as one had to wade through the entire chat session.

Thank you, that is the kind of information I thought we could come up
with by testing it in a small group. 

So the one proposal left at the moment would be to use IM in addition
to our conference calls courtesy of Indiana University?

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 Jul 14 20:53:35 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 15 Jul 2005 09:53:35 +0900
Subject: [tei-council] regularizing names
In-Reply-To: <a062007cdbefc841864df@[128.148.157.102]> (Julia Flanders's
	message of "Thu, 14 Jul 2005 17:38:15 -0400")
References: <a06200768bef49ef6ae2c@[128.148.157.102]>
	<42D2DA35.8040007@computing-services.oxford.ac.uk>
	<a062007cdbefc841864df@[128.148.157.102]>
Message-ID: <ygf8y08x52o.fsf@chwpb.local>

Julia Flanders <Julia_Flanders at Brown.edu> writes:

> If you had a document in which there were many different people named
> John Smith, all spelled and abbreviated in wacky ways, all the
> references might legitimately point to a single <regName> element that
> regularized them all simply as names. If you wanted to use <regName>
> to link these to persons, you would need instead multiple <regName>
> elements with links to person data. Or you could just use key= if you
> didn't want to regularize the names at all.

But in this case, there is no real need to link from regName to the
record, you could use key= on name to do that and still get away with
just one regName element in your header.  So maybe the idea of linking
from the regName to the authority file is not really what you want,
after all? 

All the best,

Christian

-- 

 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From sschreib at umd.edu  Fri Jul 15 05:22:29 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Fri, 15 Jul 2005 05:22:29 -0400
Subject: [tei-council] meeting technologies
In-Reply-To: <42D6F080.6050603@computing-services.oxford.ac.uk>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>	<17110.52215.774095.934130@emt.wwp.brown.edu>
	<42D6E7E2.2060101@umd.edu>
	<42D6F080.6050603@computing-services.oxford.ac.uk>
Message-ID: <42D78055.7000403@umd.edu>

no -- we continued with IM, but we are now looking for grant funding, 
and one of the line items will be conference calls

ss

Sebastian Rahtz wrote:

>Susan Schreibman wrote:
>
>  
>
>>We switched to IM meetings for teiPublisher because the phone calls
>>were too expensive for some of the team. They were far less
>>satisfactory than telephone calls, and writing up minutes took forever
>>as one had to wade through the entire chat session.
>>
>>    
>>
>so have you switched back to phone?
>
>
>  
>

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742

Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib at umd.edu

From sschreib at umd.edu  Fri Jul 15 05:32:06 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Fri, 15 Jul 2005 05:32:06 -0400
Subject: [tei-council] meeting technologies
In-Reply-To: <ygfd5pkx5by.fsf@chwpb.local>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>	<17110.52215.774095.934130@emt.wwp.brown.edu>
	<42D6E7E2.2060101@umd.edu> <ygfd5pkx5by.fsf@chwpb.local>
Message-ID: <42D78296.5030904@umd.edu>

On the other hand, it is very expensive for people phoning from outside 
the US for an hour and a half -- that seems to be the real problem. The 
people from Oxford can conference call each other in and then just have 
one international line to the US, which really does save quite a bit.

I'm wondering if there is any way left to reduce the costs somehow to 
others phoning from abroad.

susan

Christian Wittern wrote:

>Susan Schreibman <sschreib at umd.edu> writes:
>
>  
>
>>We switched to IM meetings for teiPublisher because the phone calls
>>were too expensive for some of the team. They were far less
>>satisfactory than telephone calls, and writing up minutes took forever
>>as one had to wade through the entire chat session.
>>    
>>
>
>Thank you, that is the kind of information I thought we could come up
>with by testing it in a small group. 
>
>So the one proposal left at the moment would be to use IM in addition
>to our conference calls courtesy of Indiana University?
>
>All the best,
>
>Christian
>
>  
>

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742

Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib at umd.edu

From Julia_Flanders at Brown.edu  Fri Jul 15 12:35:41 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Fri, 15 Jul 2005 12:35:41 -0400
Subject: [tei-council] meeting technologies
In-Reply-To: <42D78296.5030904@umd.edu>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>
	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>
	<17110.52215.774095.934130@emt.wwp.brown.edu>	<42D6E7E2.2060101@umd.edu>
	<ygfd5pkx5by.fsf@chwpb.local> <42D78296.5030904@umd.edu>
Message-ID: <a062007d9befd95d28ce0@[128.148.157.102]>

I also wonder whether we can quantify those costs more precisely, and 
perhaps subsidize them. Given the cost of things like TEI council 
meetings, adding a few hundred dollars for conference calls would not 
be an unreasonable or unmanageable expense, if that's what it 
amounted to. Can those who paid for the last conference call (or the 
one before that) take a look at the phone bill and report on the cost?

Julia

At 5:32 AM -0400 7/15/05, Susan Schreibman wrote:
>On the other hand, it is very expensive for people phoning from 
>outside the US for an hour and a half -- that seems to be the real 
>problem. The people from Oxford can conference call each other in 
>and then just have one international line to the US, which really 
>does save quite a bit.
>
>I'm wondering if there is any way left to reduce the costs somehow 
>to others phoning from abroad.
>
>susan

From edward.vanhoutte at kantl.be  Fri Jul 15 18:48:56 2005
From: edward.vanhoutte at kantl.be (Edward Vanhoutte)
Date: Sat, 16 Jul 2005 00:48:56 +0200
Subject: [tei-council] meeting technologies
In-Reply-To: <42D78296.5030904@umd.edu>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>	<17110.52215.774095.934130@emt.wwp.brown.edu>	<42D6E7E2.2060101@umd.edu>
	<ygfd5pkx5by.fsf@chwpb.local> <42D78296.5030904@umd.edu>
Message-ID: <42D83D58.2010503@kantl.be>

Conference calls usually cost me about 15-20 EUR which is not too bad.

Edward

Susan Schreibman wrote:

> On the other hand, it is very expensive for people phoning from 
> outside the US for an hour and a half -- that seems to be the real 
> problem. The people from Oxford can conference call each other in and 
> then just have one international line to the US, which really does 
> save quite a bit.
>
> I'm wondering if there is any way left to reduce the costs somehow to 
> others phoning from abroad.
>
> susan
>
>
> Christian Wittern wrote:
>
>> Susan Schreibman <sschreib at umd.edu> writes:
>>
>>  
>>
>>> We switched to IM meetings for teiPublisher because the phone calls
>>> were too expensive for some of the team. They were far less
>>> satisfactory than telephone calls, and writing up minutes took forever
>>> as one had to wade through the entire chat session.
>>>   
>>
>>
>> Thank you, that is the kind of information I thought we could come up
>> with by testing it in a small group.
>> So the one proposal left at the moment would be to use IM in addition
>> to our conference calls courtesy of Indiana University?
>>
>> All the best,
>>
>> Christian
>>
>>  
>>
>

-- 

================
Edward Vanhoutte
Researcher
University of Antwerp
Associate Editor, Literary and Linguistic Computing
University of Antwerp - CDE
Dept. of Literature
Universiteitsplein 1
b-2610 Wilrijk
Belgium

edward dot vanhoutte at kantl dot be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Jul 15 20:32:44 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 16 Jul 2005 09:32:44 +0900
Subject: [tei-council] meeting technologies
In-Reply-To: <42D83D58.2010503@kantl.be> (Edward Vanhoutte's message of
	"Sat, 16 Jul 2005 00:48:56 +0200")
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>
	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>
	<17110.52215.774095.934130@emt.wwp.brown.edu>
	<42D6E7E2.2060101@umd.edu>
	<ygfd5pkx5by.fsf@chwpb.local> <42D78296.5030904@umd.edu>
	<42D83D58.2010503@kantl.be>
Message-ID: <ygfr7dzvbdf.fsf@chwpb.local>

Edward Vanhoutte <edward.vanhoutte at kantl.be> writes:

> Conference calls usually cost me about 15-20 EUR which is not too bad.

When we started doing calls, it was in the area of 5000 Yen (~65 US)
per call, but with the dropping telecom costs, I think I am down to about
the same amount as the one reported by Edward. Still, that would be
in the area of 300 EUR for all participants per call, with 6 calls per
year about 1800 EUR to put in the budget.  

It looks like to us the cost of calls is a minor factor, the technical
quality seems more important to me.  (I am working with Syd offlist
towards an improvement here, since apparently it has to do with
specific equipment).

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 computing-services.oxford.ac.uk  Sun Jul 17 15:43:55 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 17 Jul 2005 20:43:55 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <ygfr7dzvbdf.fsf@chwpb.local>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>	<17110.52215.774095.934130@emt.wwp.brown.edu>	<42D6E7E2.2060101@umd.edu>	<ygfd5pkx5by.fsf@chwpb.local>
	<42D78296.5030904@umd.edu>	<42D83D58.2010503@kantl.be>
	<ygfr7dzvbdf.fsf@chwpb.local>
Message-ID: <42DAB4FB.7070405@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>It looks like to us the cost of calls is a minor factor, the technical
>quality seems more important to me.  
>  
>
Indeed. As it stands, I find the Council calls a) very tiring,
and b) not very satisfying; and quite a lot of that is not
really being able to hear what people are saying. If
its possible to improve that, great.

But still worth experimenting with
having an IRC channel ready on the side.

-- 
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 computing-services.oxford.ac.uk  Sun Jul 17 16:30:32 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 17 Jul 2005 21:30:32 +0100
Subject: [tei-council] the release conundrum
Message-ID: <42DABFE8.2040009@computing-services.oxford.ac.uk>

I have tried to streamline our release offerings. We now have

 a) CVS
 b) a release which consists of:
      - debian and RPM packages
      - SF file releases
      - a duplicate of a Debian release on the TEI web site.
        the existing copies of P4 and P5 DTDs and Guidelines have now been
        removed, and the URLs are now silently redirected to the
"release" tree.
 c) packages for Knoppix and Windows Emacs (not in sync yet)
 d) distribution by oXygen

we are now at release 0.1.10.

My view of the process is as follows:

  1) the editors or their acolytes change CVS as they need to. it is not
guarenteed to "work" at any given time.
  2) when a consensus emerges that something interesting has happened,
or that 6 months has passed,
       the editors will instruct the release manager (currently me) to
prepare all the outputs in b) above
       and release them as close together as possible
 3) the Knoppix and Emacs releases are a project of TEI Oxford which
will follow a timetable of their own
 4) we will all do our best to assist the oXygen people stay in sycn and
be forewarned of important changes
 5) the editors do not need permission from the Council to make minimo
releases (ie 0.1.13), but
     the council will discuss making a minor release (0.2.0), and the
council and board will both
     discuss making a major release (1.0.0)

I would propose now that we plan to make the 0.2.0 release after the
class and attribute changes have been
implemented.

How does that sound?

-- 
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 computing-services.oxford.ac.uk  Sun Jul 17 17:01:15 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 17 Jul 2005 22:01:15 +0100
Subject: [tei-council] manual for P5
Message-ID: <42DAC71B.6020707@computing-services.oxford.ac.uk>

The noisy Bruce D'Arcus complains to me that we don't have any
info on how to use P5 schemas. And he's right. We have edw88, ODD/Manual/
and James' HOWTO, all incomplete and unpublished.

Which hero will step up to the plate and volunteer the two man
days need to collate the 3 docs above and publish the result?

-- 
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  Sun Jul 17 18:02:35 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 17 Jul 2005 23:02:35 +0100
Subject: [tei-council] the release conundrum
In-Reply-To: <42DABFE8.2040009@computing-services.oxford.ac.uk>
References: <42DABFE8.2040009@computing-services.oxford.ac.uk>
Message-ID: <42DAD57B.90304@computing-services.oxford.ac.uk>

This is all fine by me, though just for the record I think I should 
point out that the editors are right out of acolytes.

L

Sebastian Rahtz wrote:

> I have tried to streamline our release offerings. We now have
> 
>  a) CVS
>  b) a release which consists of:
>       - debian and RPM packages
>       - SF file releases
>       - a duplicate of a Debian release on the TEI web site.
>         the existing copies of P4 and P5 DTDs and Guidelines have now been
>         removed, and the URLs are now silently redirected to the
> "release" tree.
>  c) packages for Knoppix and Windows Emacs (not in sync yet)
>  d) distribution by oXygen
> 
> we are now at release 0.1.10.
> 
> My view of the process is as follows:
> 
>   1) the editors or their acolytes change CVS as they need to. it is not
> guarenteed to "work" at any given time.
>   2) when a consensus emerges that something interesting has happened,
> or that 6 months has passed,
>        the editors will instruct the release manager (currently me) to
> prepare all the outputs in b) above
>        and release them as close together as possible
>  3) the Knoppix and Emacs releases are a project of TEI Oxford which
> will follow a timetable of their own
>  4) we will all do our best to assist the oXygen people stay in sycn and
> be forewarned of important changes
>  5) the editors do not need permission from the Council to make minimo
> releases (ie 0.1.13), but
>      the council will discuss making a minor release (0.2.0), and the
> council and board will both
>      discuss making a major release (1.0.0)
> 
> I would propose now that we plan to make the 0.2.0 release after the
> class and attribute changes have been
> implemented.
> 
> How does that sound?
> 

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 17 17:55:33 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 17 Jul 2005 22:55:33 +0100
Subject: [tei-council] the release conundrum
In-Reply-To: <42DAD57B.90304@computing-services.oxford.ac.uk>
References: <42DABFE8.2040009@computing-services.oxford.ac.uk>
	<42DAD57B.90304@computing-services.oxford.ac.uk>
Message-ID: <42DAD3D5.2090302@computing-services.oxford.ac.uk>

Lou Burnard wrote:

> This is all fine by me, though just for the record I think I should
> point out that the editors are right out of acolytes.

I was referring to myself there.
   s/acolytes/hangers on/
or
   s/acolytes/loose cannons/
or
   s/acolytes/rottweilers/

-- 
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 Jul 17 18:23:25 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 17 Jul 2005 18:23:25 -0400
Subject: [tei-council] the release conundrum
In-Reply-To: <42DAD3D5.2090302@computing-services.oxford.ac.uk>
References: <42DABFE8.2040009@computing-services.oxford.ac.uk>
	<42DAD57B.90304@computing-services.oxford.ac.uk>
	<42DAD3D5.2090302@computing-services.oxford.ac.uk>
Message-ID: <17114.55901.307615.819445@emt.wwp.brown.edu>

Sebastian's view of the process (reproduced below) sounds good to me,
too. However, I think 6 months is an enormously long time to wait
between releases. I'm not suggesting we change the process to 3 or 4
months, but rather that if 6 months have gone by and nothing
"interesting" has happened, we need to re-examine either our system
for making things happen or our criteria for what is and isn't
"interesting". :-)  (Personally, I'm betting this won't be a problem
at all.)

I also think it is vitally important, Sebastian, that you write up
the procedure for making a release, so that someone else could be the
release manager without fuss.

LB> This is all fine by me, though just for the record I think I
LB> should point out that the editors are right out of acolytes.

I agree with Lou, and furthermore my ads in the personals for
"acolyte wanted -- no pay, minimal reward" have gone unanswered for
weeks. On the other hand, we need to decide at some point who else,
if anyone, gets R/W access to the CVS tree. E.g., Laurent is working
on both the dictionary and the terminological databases chapter --
should he be doing this directly in CVS? David Durand is working on
the linking chapter -- should he?

---------
I have tried to streamline our release offerings. We now have
 a) CVS
 b) a release which consists of:
    - debian and RPM packages
    - SF file releases
    - a duplicate of a Debian release on the TEI web site. the
      existing copies of P4 and P5 DTDs and Guidelines have now been
      removed, and the URLs are now silently redirected to the
      "release" tree.
 c) packages for Knoppix and Windows Emacs (not in sync yet)
 d) distribution by oXygen

we are now at release 0.1.10.

My view of the process is as follows:

1) the editors or their acolytes change CVS as they need to. it is
   not guarenteed to "work" at any given time.

2) when a consensus emerges that something interesting has happened,
   or that 6 months has passed, the editors will instruct the release
   manager (currently me) to prepare all the outputs in b) above and
   release them as close together as possible

3) the Knoppix and Emacs releases are a project of TEI Oxford which
   will follow a timetable of their own

4) we will all do our best to assist the oXygen people stay in sycn
   and be forewarned of important changes

5) the editors do not need permission from the Council to make minimo
   releases (ie 0.1.13), but the council will discuss making a minor
   release (0.2.0), and the council and board will both discuss
   making a major release (1.0.0)

I would propose now that we plan to make the 0.2.0 release after the
class and attribute changes have been implemented.

How does that sound?

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 17 18:37:38 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 17 Jul 2005 23:37:38 +0100
Subject: [tei-council] the release conundrum
In-Reply-To: <17114.55901.307615.819445@emt.wwp.brown.edu>
References: <42DABFE8.2040009@computing-services.oxford.ac.uk>	<42DAD57B.90304@computing-services.oxford.ac.uk>	<42DAD3D5.2090302@computing-services.oxford.ac.uk>
	<17114.55901.307615.819445@emt.wwp.brown.edu>
Message-ID: <42DADDB2.6050900@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>Sebastian's view of the process (reproduced below) sounds good to me,
>too. However, I think 6 months is an enormously long time to wait
>between releases. 
>
Sure, I agree. after 6 months alarm bells should ring

>I also think it is vitally important, Sebastian, that you write up
>the procedure for making a release, so that someone else could be the
>release manager without fuss.
>  
>
there are two, independent, parts to this:

 a) doing "make dist" on the source, and then releasing the resulting .zip
      files on Sourceforge; the good folks on SF explain all this
 b) making Debian packages, installing them, and then exporting the result
      to the TEI web. trouble is, this means having a working process
      to create Debian packages on a shared machine. Sadly, we don't
      possess a machine running Debian which I can set up to do this.
Currently
      its on my laptop. Thats BAD.  But I don't quite know how to proceed.

in general, I really don't like the fact that we have retreated to
a position in which no-one but me is really familiar with the
the TEI P5 tool chain and its ramifications. the NSF project
was supposed to deliver us from that :-}

>weeks. On the other hand, we need to decide at some point who else,
>if anyone, gets R/W access to the CVS tree. E.g., Laurent is working
>on both the dictionary and the terminological databases chapter --
>should he be doing this directly in CVS? David Durand is working on
>the linking chapter -- should he?
>  
>
I  believe that commit rights to the CVS tree should be given
to any member of a TEI working group who asks for them. The
barrier is getting onto a working group.

I suspect others will want more "control", but I express the above
as a personal preference.

Absolutely yes we want more people checking out the CVS tree,
and familiarizing themselves with the source and how to use it;
and that means trusting them to commit code.

-- 
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 Jul 17 21:19:18 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 18 Jul 2005 10:19:18 +0900
Subject: [tei-council] the release conundrum
In-Reply-To: <42DABFE8.2040009@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Sun, 17 Jul 2005 21:30:32 +0100")
References: <42DABFE8.2040009@computing-services.oxford.ac.uk>
Message-ID: <ygfll44kj1l.fsf@chwpb.local>

Sebastian Rahtz <sebastian.rahtz at computing-services.oxford.ac.uk> writes:

>  5) the editors do not need permission from the Council to make minimo
> releases (ie 0.1.13), but
>      the council will discuss making a minor release (0.2.0), and the
> council and board will both
>      discuss making a major release (1.0.0)
>
> I would propose now that we plan to make the 0.2.0 release after the
> class and attribute changes have been
> implemented.
>
> How does that sound?

This does all make good sense to me.  We should aim at a fresh,
working release for before the Members Meeting, I think (that is,
around Oct 15?), which will hopefully be 0.2.0 according to the plan
above.  

What would be nice to have, as I said before, is a P5 roadmap that
gives milestones and dates.

All the best,

Christian 

(once again working out of my <soCalled>mobile office</soCalled> at
Kansai Airport, waiting for a Taifun-delayed flight... )

-- 

 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From nsmith at email.unc.edu  Sun Jul 17 21:48:09 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Sun, 17 Jul 2005 21:48:09 -0400
Subject: [tei-council] the release conundrum
References: <42DABFE8.2040009@computing-services.oxford.ac.uk>
Message-ID: <00e201c58b3a$c05b7370$27a81798@lib.unc.edu>

Sounds like a very reasonable plan to me.
best, ns

----- Original Message ----- 
From: "Sebastian Rahtz" <sebastian.rahtz at computing-services.oxford.ac.uk>
To: "TEICouncil" <tei-council at lists.village.Virginia.EDU>
Sent: Sunday, July 17, 2005 4:30 PM
Subject: [tei-council] the release conundrum

> I have tried to streamline our release offerings. We now have
>
>  a) CVS
>  b) a release which consists of:
>       - debian and RPM packages
>       - SF file releases
>       - a duplicate of a Debian release on the TEI web site.
>         the existing copies of P4 and P5 DTDs and Guidelines have now been
>         removed, and the URLs are now silently redirected to the
> "release" tree.
>  c) packages for Knoppix and Windows Emacs (not in sync yet)
>  d) distribution by oXygen
>
> we are now at release 0.1.10.
>
> My view of the process is as follows:
>
>   1) the editors or their acolytes change CVS as they need to. it is not
> guarenteed to "work" at any given time.
>   2) when a consensus emerges that something interesting has happened,
> or that 6 months has passed,
>        the editors will instruct the release manager (currently me) to
> prepare all the outputs in b) above
>        and release them as close together as possible
>  3) the Knoppix and Emacs releases are a project of TEI Oxford which
> will follow a timetable of their own
>  4) we will all do our best to assist the oXygen people stay in sycn and
> be forewarned of important changes
>  5) the editors do not need permission from the Council to make minimo
> releases (ie 0.1.13), but
>      the council will discuss making a minor release (0.2.0), and the
> council and board will both
>      discuss making a major release (1.0.0)
>
> I would propose now that we plan to make the 0.2.0 release after the
> class and attribute changes have been
> implemented.
>
> How does that sound?
>
> -- 
> 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 computing-services.oxford.ac.uk  Mon Jul 18 03:17:37 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 18 Jul 2005 08:17:37 +0100
Subject: [tei-council] the release conundrum
In-Reply-To: <ygfll44kj1l.fsf@chwpb.local>
References: <42DABFE8.2040009@computing-services.oxford.ac.uk>
	<ygfll44kj1l.fsf@chwpb.local>
Message-ID: <42DB5791.7060607@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>This does all make good sense to me.  We should aim at a fresh,
>working release for before the Members Meeting, I think (that is,
>around Oct 15?), which will hopefully be 0.2.0 according to the plan
>above.  
>  
>
I agree. I think we should make every effort to meet that
deadline

>What would be nice to have, as I said before, is a P5 roadmap that
>gives milestones and dates.
>  
>
+1

-- 
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 sschreib at umd.edu  Mon Jul 18 05:25:30 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Mon, 18 Jul 2005 05:25:30 -0400
Subject: [tei-council] the release conundrum
In-Reply-To: <42DB5791.7060607@computing-services.oxford.ac.uk>
References: <42DABFE8.2040009@computing-services.oxford.ac.uk>	<ygfll44kj1l.fsf@chwpb.local>
	<42DB5791.7060607@computing-services.oxford.ac.uk>
Message-ID: <42DB758A.3080609@umd.edu>

I agree with so much of what has been said. I think the TEI membership 
would appreciate knowing how things are progressing on P5, and whether 
the types of changes/improvements/ in the last release is worth a 
particular project downloading a new version.

 From a user's perspective, I expect that they would appreciate releases 
less frequently, as been mentioned, every 3-6 months so that they don't 
feel that as soon as they download a new version, another is available. 
Even if nothing much has been changed in a three or four month period, I 
expect the membership would appreciate some sort of update report as to 
what the Council is working on.

I agree totally a new release before the members' meeting would be great.

susan

Sebastian Rahtz wrote:

>Christian Wittern wrote:
>
>  
>
>>This does all make good sense to me.  We should aim at a fresh,
>>working release for before the Members Meeting, I think (that is,
>>around Oct 15?), which will hopefully be 0.2.0 according to the plan
>>above.  
>> 
>>
>>    
>>
>I agree. I think we should make every effort to meet that
>deadline
>
>  
>
>>What would be nice to have, as I said before, is a P5 roadmap that
>>gives milestones and dates.
>> 
>>
>>    
>>
>+1
>
>
>  
>

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742

Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib at umd.edu

From Syd_Bauman at Brown.edu  Mon Jul 18 15:26:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 18 Jul 2005 15:26:11 -0400
Subject: [tei-council] meeting technologies
In-Reply-To: <42DAB4FB.7070405@computing-services.oxford.ac.uk>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>
	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>
	<17110.52215.774095.934130@emt.wwp.brown.edu>
	<42D6E7E2.2060101@umd.edu> <ygfd5pkx5by.fsf@chwpb.local>
	<42D78296.5030904@umd.edu> <42D83D58.2010503@kantl.be>
	<ygfr7dzvbdf.fsf@chwpb.local>
	<42DAB4FB.7070405@computing-services.oxford.ac.uk>
Message-ID: <17116.595.844748.107987@emt.wwp.brown.edu>

SR> why is it [video conferencing] a pain?

Let's start with purchasing hardware and installing software. Now I
have to admit, I haven't priced any of those little webcam cameras
for well over a year, but they were kindof expensive then, and even
now they certainly aren't free. And personally, I'm not sure what
advantage there would be for us.

SR> But still worth experimenting with having an IRC channel ready on
SR> the side.

IRC, ICQ/AIM, Gadu-Gadu, Groupwise, Jabber, Yahoo ... whatever. Yes,
I think trying this is a very good idea.

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jul 20 17:52:02 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 20 Jul 2005 22:52:02 +0100
Subject: [tei-council] trying TEI P5 with oXygen
Message-ID: <42DEC782.8020006@computing-services.oxford.ac.uk>

At first blush, it looks like oXygen 6.1 pays off in its bundling
of TEI P5 experimental. You can do "New from templates", choose
from a range of  example setups, and get stuck into writing TEI P5.

If you haven't tried oXygen yet, and are not averse to closed-source
software, give it a try. cool stuff.

-- 
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 Jul 24 11:34:07 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 24 Jul 2005 11:34:07 -0400
Subject: [tei-council] ED W 90 data usable again
Message-ID: <17123.46319.187178.256317@emt.wwp.brown.edu>

The data table of attributes is now usable again. 

As a reminder, this is the table that is associated with (and pointed
to from) ED W 90. It is a rudimentary PHP interface to a MySQL
database, so that it can be sorted by column.

I hope to post more about this issue in a few weeks (I'm on vacation,
then off to a conference, then teaching a TEI workshop), but in the
meantime Council members should feel free to browse, comment, suggest
improvements, point out errors, etc.

http://www.tei-c.org/Drafts/edw90.xml?style=printable, which points
to
http://dev.stg.brown.edu/staff/Syd_Bauman/edw90.php

From edward.vanhoutte at kantl.be  Tue Jul 26 04:33:44 2005
From: edward.vanhoutte at kantl.be (Edward Vanhoutte)
Date: Tue, 26 Jul 2005 10:33:44 +0200
Subject: [tei-council] multilingualism
Message-ID: <42E5F568.3030509@kantl.be>

The Russian and Korean version of TEI Lite cannot be accessed from 
<http://www.tei-c.org/Lite/>. Who will fix it?

Edward

-- 

================
Edward Vanhoutte
Researcher
University of Antwerp
Associate Editor, Literary and Linguistic Computing
University of Antwerp - CDE
Dept. of Literature
Universiteitsplein 1
b-2610 Wilrijk
Belgium

edward dot vanhoutte at kantl dot be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm

From lou.burnard at computing-services.oxford.ac.uk  Tue Jul 26 04:33:58 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 26 Jul 2005 09:33:58 +0100
Subject: [tei-council] multilingualism
In-Reply-To: <42E5F568.3030509@kantl.be>
References: <42E5F568.3030509@kantl.be>
Message-ID: <42E5F576.2070406@computing-services.oxford.ac.uk>

Edward Vanhoutte wrote:

> The Russian and Korean version of TEI Lite cannot be accessed from 
> <http://www.tei-c.org/Lite/>. Who will fix it?
>
> Edward
>
Whoever gets there first!

The ideal fix should be to process the SGML and RTF formats to something 
the webserver can do something sensible with; the quick fix would be to 
wrap them up in a zip so that cocoon doesnt have kittens when trying to 
serve them forth.

From edward.vanhoutte at kantl.be  Tue Jul 26 04:49:55 2005
From: edward.vanhoutte at kantl.be (Edward Vanhoutte)
Date: Tue, 26 Jul 2005 10:49:55 +0200
Subject: [tei-council] multilingualism
In-Reply-To: <42E5F576.2070406@computing-services.oxford.ac.uk>
References: <42E5F568.3030509@kantl.be>
	<42E5F576.2070406@computing-services.oxford.ac.uk>
Message-ID: <42E5F933.1020801@kantl.be>

Curiously, no German version of the TEI documentation is listed. Does it 
not exist? (which I doubt).

Edward

Lou Burnard wrote:

Lou Burnard wrote:

> Edward Vanhoutte wrote:
>
>> The Russian and Korean version of TEI Lite cannot be accessed from 
>> <http://www.tei-c.org/Lite/>. Who will fix it?
>>
>> Edward
>>
> Whoever gets there first!
>
> The ideal fix should be to process the SGML and RTF formats to 
> something the webserver can do something sensible with; the quick fix 
> would be to wrap them up in a zip so that cocoon doesnt have kittens 
> when trying to serve them forth.
>
>
>

-- 

================
Edward Vanhoutte
Researcher
University of Antwerp
Associate Editor, Literary and Linguistic Computing
University of Antwerp - CDE
Dept. of Literature
Universiteitsplein 1
b-2610 Wilrijk
Belgium

edward dot vanhoutte at kantl dot be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm

From lou.burnard at computing-services.oxford.ac.uk  Tue Jul 26 04:56:13 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 26 Jul 2005 09:56:13 +0100
Subject: [tei-council] multilingualism
In-Reply-To: <42E5F933.1020801@kantl.be>
References: <42E5F568.3030509@kantl.be>	<42E5F576.2070406@computing-services.oxford.ac.uk>
	<42E5F933.1020801@kantl.be>
Message-ID: <42E5FAAD.3070402@computing-services.oxford.ac.uk>

It's not listed because neither of the two versions known to exist has 
been deposited with the TEI website, despite repeated requests to their 
translators!

I  can try again...

Edward Vanhoutte wrote:

> Curiously, no German version of the TEI documentation is listed. Does 
> it not exist? (which I doubt).
>
> Edward
>
> Lou Burnard wrote:
>
> Lou Burnard wrote:
>
>> Edward Vanhoutte wrote:
>>
>>> The Russian and Korean version of TEI Lite cannot be accessed from 
>>> <http://www.tei-c.org/Lite/>. Who will fix it?
>>>
>>> Edward
>>>
>> Whoever gets there first!
>>
>> The ideal fix should be to process the SGML and RTF formats to 
>> something the webserver can do something sensible with; the quick fix 
>> would be to wrap them up in a zip so that cocoon doesnt have kittens 
>> when trying to serve them forth.
>>
>>
>>
>

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Jul 26 05:03:27 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 26 Jul 2005 10:03:27 +0100
Subject: [tei-council] multilingualism
In-Reply-To: <42E5F933.1020801@kantl.be>
References: <42E5F568.3030509@kantl.be>	<42E5F576.2070406@computing-services.oxford.ac.uk>
	<42E5F933.1020801@kantl.be>
Message-ID: <42E5FC5F.3050907@computing-services.oxford.ac.uk>

Edward Vanhoutte wrote:

> Curiously, no German version of the TEI documentation is listed. Does
> it not exist? (which I doubt).
>
Arno Mittelbach made a start last year, but didnt complete it. FWIW.

-- 
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 computing-services.oxford.ac.uk  Tue Jul 26 05:04:44 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 26 Jul 2005 10:04:44 +0100
Subject: [tei-council] multilingualism
In-Reply-To: <42E5F576.2070406@computing-services.oxford.ac.uk>
References: <42E5F568.3030509@kantl.be>
	<42E5F576.2070406@computing-services.oxford.ac.uk>
Message-ID: <42E5FCAC.10901@computing-services.oxford.ac.uk>

Lou Burnard wrote:

> Edward Vanhoutte wrote:
>
>> The Russian and Korean version of TEI Lite cannot be accessed from
>> <http://www.tei-c.org/Lite/>. Who will fix it?
>>
>> Edward
>>
> Whoever gets there first!
>
> The ideal fix should be to process the SGML and RTF formats to
> something the webserver can do something sensible with; the quick fix
> would be to wrap them up in a zip so that cocoon doesnt have kittens
> when trying to serve them forth.
>
no need. Cocoon duly fixed. much less work than zipping.

-- 
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  Tue Jul 26 05:17:27 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 26 Jul 2005 10:17:27 +0100
Subject: [tei-council] multilingualism
In-Reply-To: <42E5FC5F.3050907@computing-services.oxford.ac.uk>
References: <42E5F568.3030509@kantl.be>	<42E5F576.2070406@computing-services.oxford.ac.uk>	<42E5F933.1020801@kantl.be>
	<42E5FC5F.3050907@computing-services.oxford.ac.uk>
Message-ID: <42E5FFA7.1070800@oucs.ox.ac.uk>

Sebastian Rahtz wrote:
> Edward Vanhoutte wrote:
> 
> 
>>Curiously, no German version of the TEI documentation is listed. Does
>>it not exist? (which I doubt).
>>
> 
> Arno Mittelbach made a start last year, but didnt complete it. FWIW.
> 

which makes three....

From James.Cummings at computing-services.oxford.ac.uk  Wed Jul 27 06:54:10 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 27 Jul 2005 11:54:10 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <17116.595.844748.107987@emt.wwp.brown.edu>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>	<17110.52215.774095.934130@emt.wwp.brown.edu>	<42D6E7E2.2060101@umd.edu>
	<ygfd5pkx5by.fsf@chwpb.local>	<42D78296.5030904@umd.edu>
	<42D83D58.2010503@kantl.be>	<ygfr7dzvbdf.fsf@chwpb.local>	<42DAB4FB.7070405@computing-services.oxford.ac.uk>
	<17116.595.844748.107987@emt.wwp.brown.edu>
Message-ID: <42E767D2.2080407@computing-services.oxford.ac.uk>

Syd Bauman wrote:
> SR> But still worth experimenting with having an IRC channel ready on
> SR> the side.
> 
> IRC, ICQ/AIM, Gadu-Gadu, Groupwise, Jabber, Yahoo ... whatever. Yes,
> I think trying this is a very good idea.

I've been sat in #tei-c on irc.freenode.net during work hours (UK) since 
returning from these conferences on Monday, and although people seem to think it 
is a good idea and I mentioned it in a previous email, nary a soul has visited 
me. :-(

(really just a reminder)

-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 computing-services.oxford.ac.uk  Wed Jul 27 07:14:43 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 27 Jul 2005 12:14:43 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <42E767D2.2080407@computing-services.oxford.ac.uk>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>	<17110.52215.774095.934130@emt.wwp.brown.edu>	<42D6E7E2.2060101@umd.edu>
	<ygfd5pkx5by.fsf@chwpb.local>	<42D78296.5030904@umd.edu>
	<42D83D58.2010503@kantl.be>	<ygfr7dzvbdf.fsf@chwpb.local>	<42DAB4FB.7070405@computing-services.oxford.ac.uk>
	<17116.595.844748.107987@emt.wwp.brown.edu>
	<42E767D2.2080407@computing-services.oxford.ac.uk>
Message-ID: <42E76CA3.1020802@computing-services.oxford.ac.uk>

James Cummings wrote:

> I've been sat in #tei-c on irc.freenode.net during work hours (UK) 
> since returning from these conferences on Monday, and although people 
> seem to think it is a good idea and I mentioned it in a previous 
> email, nary a soul has visited me. :-(

I've just lost my Gaim virginity and am frolicking with James, FWIW

sebastian

From James.Cummings at computing-services.oxford.ac.uk  Wed Jul 27 07:19:32 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 27 Jul 2005 12:19:32 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <42E76CA3.1020802@computing-services.oxford.ac.uk>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>	<17110.52215.774095.934130@emt.wwp.brown.edu>	<42D6E7E2.2060101@umd.edu>
	<ygfd5pkx5by.fsf@chwpb.local>	<42D78296.5030904@umd.edu>
	<42D83D58.2010503@kantl.be>	<ygfr7dzvbdf.fsf@chwpb.local>	<42DAB4FB.7070405@computing-services.oxford.ac.uk>
	<17116.595.844748.107987@emt.wwp.brown.edu>
	<42E767D2.2080407@computing-services.oxford.ac.uk>
	<42E76CA3.1020802@computing-services.oxford.ac.uk>
Message-ID: <42E76DC4.2010801@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:

> I've just lost my Gaim virginity and am frolicking with James, FWIW

You do make it sound all sordid...

-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 computing-services.oxford.ac.uk  Wed Jul 27 07:53:31 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 27 Jul 2005 12:53:31 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <42E76DC4.2010801@computing-services.oxford.ac.uk>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>	<17110.52215.774095.934130@emt.wwp.brown.edu>	<42D6E7E2.2060101@umd.edu>
	<ygfd5pkx5by.fsf@chwpb.local>	<42D78296.5030904@umd.edu>
	<42D83D58.2010503@kantl.be>	<ygfr7dzvbdf.fsf@chwpb.local>	<42DAB4FB.7070405@computing-services.oxford.ac.uk>
	<17116.595.844748.107987@emt.wwp.brown.edu>
	<42E767D2.2080407@computing-services.oxford.ac.uk>
	<42E76CA3.1020802@computing-services.oxford.ac.uk>
	<42E76DC4.2010801@computing-services.oxford.ac.uk>
Message-ID: <42E775BB.4080603@computing-services.oxford.ac.uk>

James Cummings wrote:

> Sebastian Rahtz wrote:
>
>> I've just lost my Gaim virginity and am frolicking with James, FWIW
>
>
> You do make it sound all sordid...

I can't stop washing my hands 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 Syd_Bauman at Brown.edu  Wed Jul 27 14:29:20 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 27 Jul 2005 14:29:20 -0400
Subject: [tei-council] meeting technologies
In-Reply-To: <42E767D2.2080407@computing-services.oxford.ac.uk>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>
	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>
	<17110.52215.774095.934130@emt.wwp.brown.edu>
	<42D6E7E2.2060101@umd.edu> <ygfd5pkx5by.fsf@chwpb.local>
	<42D78296.5030904@umd.edu> <42D83D58.2010503@kantl.be>
	<ygfr7dzvbdf.fsf@chwpb.local>
	<42DAB4FB.7070405@computing-services.oxford.ac.uk>
	<17116.595.844748.107987@emt.wwp.brown.edu>
	<42E767D2.2080407@computing-services.oxford.ac.uk>
Message-ID: <17127.53888.306765.835911@emt.wwp.brown.edu>

I was in favor of having in IRC channel open on the side during
conference calls, not for daily discussions.

From sebastian.rahtz at computing-services.oxford.ac.uk  Wed Jul 27 16:16:33 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Wed, 27 Jul 2005 21:16:33 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <17127.53888.306765.835911@emt.wwp.brown.edu>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>	<17110.52215.774095.934130@emt.wwp.brown.edu>	<42D6E7E2.2060101@umd.edu>
	<ygfd5pkx5by.fsf@chwpb.local>	<42D78296.5030904@umd.edu>
	<42D83D58.2010503@kantl.be>	<ygfr7dzvbdf.fsf@chwpb.local>	<42DAB4FB.7070405@computing-services.oxford.ac.uk>	<17116.595.844748.107987@emt.wwp.brown.edu>	<42E767D2.2080407@computing-services.oxford.ac.uk>
	<17127.53888.306765.835911@emt.wwp.brown.edu>
Message-ID: <42E7EBA1.5000806@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>I was in favor of having in IRC channel open on the side during
>conference calls, not for daily discussions.
>  
>

but this was to experiment with now, to decide if its
a good idea for a real meeting.

-- 
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 Jul 27 22:40:29 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 28 Jul 2005 11:40:29 +0900
Subject: [tei-council] meeting technologies
In-Reply-To: <42E7EBA1.5000806@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Wed, 27 Jul 2005 21:16:33 +0100")
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>
	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>
	<17110.52215.774095.934130@emt.wwp.brown.edu>
	<42D6E7E2.2060101@umd.edu>
	<ygfd5pkx5by.fsf@chwpb.local> <42D78296.5030904@umd.edu>
	<42D83D58.2010503@kantl.be> <ygfr7dzvbdf.fsf@chwpb.local>
	<42DAB4FB.7070405@computing-services.oxford.ac.uk>
	<17116.595.844748.107987@emt.wwp.brown.edu>
	<42E767D2.2080407@computing-services.oxford.ac.uk>
	<17127.53888.306765.835911@emt.wwp.brown.edu>
	<42E7EBA1.5000806@computing-services.oxford.ac.uk>
Message-ID: <ygfu0if3b6q.fsf@kanji.zinbun.kyoto-u.ac.jp>

Sebastian Rahtz <sebastian.rahtz at computing-services.oxford.ac.uk> writes:

> Syd Bauman wrote:
>
>>I was in favor of having in IRC channel open on the side during
>>conference calls, not for daily discussions.
>>  
>>
>
> but this was to experiment with now, to decide if its
> a good idea for a real meeting.
>

To make this experimenting more efficient, I would like to suggest to
make an appointment (is this what you call it?) on such a channel and
then go.  As I mentioned before, I have never used IRC before, the
closest I came to Instqnt Messaging is a bit of chatting with my son
using Skype.  So to kick this off, I would need an instruction of how
to do this on a Mac OS X system.  (e.g what software to use, where to
connect etc.)   

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 Jul 28 03:58:11 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 28 Jul 2005 08:58:11 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <ygfu0if3b6q.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>	<17110.52215.774095.934130@emt.wwp.brown.edu>	<42D6E7E2.2060101@umd.edu>	<ygfd5pkx5by.fsf@chwpb.local>
	<42D78296.5030904@umd.edu>	<42D83D58.2010503@kantl.be>
	<ygfr7dzvbdf.fsf@chwpb.local>	<42DAB4FB.7070405@computing-services.oxford.ac.uk>	<17116.595.844748.107987@emt.wwp.brown.edu>	<42E767D2.2080407@computing-services.oxford.ac.uk>	<17127.53888.306765.835911@emt.wwp.brown.edu>	<42E7EBA1.5000806@computing-services.oxford.ac.uk>
	<ygfu0if3b6q.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <42E89013.7040305@computing-services.oxford.ac.uk>

1. Install Firefox (you probably want to do this anyway)

2. Install the chatzilla plugin (you will need to tell Firefox you trust 
hacksrus before it lets you do this, but otherwise this is just a matter 
of finding the right link and clicking on it)

3. Select chatzilla from the Tools menu and fire her up

4. connect to the right channel (to be determined)

I did it yesterday, on this mac ,  in 5 minutes

 Christian Wittern wrote:

>Sebastian Rahtz <sebastian.rahtz at computing-services.oxford.ac.uk> writes:
>
>  
>
>>Syd Bauman wrote:
>>
>>    
>>
>>>I was in favor of having in IRC channel open on the side during
>>>conference calls, not for daily discussions.
>>> 
>>>
>>>      
>>>
>>but this was to experiment with now, to decide if its
>>a good idea for a real meeting.
>>
>>    
>>
>
>To make this experimenting more efficient, I would like to suggest to
>make an appointment (is this what you call it?) on such a channel and
>then go.  As I mentioned before, I have never used IRC before, the
>closest I came to Instqnt Messaging is a bit of chatting with my son
>using Skype.  So to kick this off, I would need an instruction of how
>to do this on a Mac OS X system.  (e.g what software to use, where to
>connect etc.)   
>
>All the best,
>
>Christian
>
>  
>

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Jul 28 19:36:58 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 29 Jul 2005 08:36:58 +0900
Subject: [tei-council] meeting technologies
In-Reply-To: <42E89013.7040305@computing-services.oxford.ac.uk> (Lou
	Burnard's message of "Thu, 28 Jul 2005 08:58:11 +0100")
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>
	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>
	<17110.52215.774095.934130@emt.wwp.brown.edu>
	<42D6E7E2.2060101@umd.edu>
	<ygfd5pkx5by.fsf@chwpb.local> <42D78296.5030904@umd.edu>
	<42D83D58.2010503@kantl.be> <ygfr7dzvbdf.fsf@chwpb.local>
	<42DAB4FB.7070405@computing-services.oxford.ac.uk>
	<17116.595.844748.107987@emt.wwp.brown.edu>
	<42E767D2.2080407@computing-services.oxford.ac.uk>
	<17127.53888.306765.835911@emt.wwp.brown.edu>
	<42E7EBA1.5000806@computing-services.oxford.ac.uk>
	<ygfu0if3b6q.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<42E89013.7040305@computing-services.oxford.ac.uk>
Message-ID: <ygfslxycxk5.fsf@chwpb.local>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> 1. Install Firefox (you probably want to do this anyway)
In place
> 2. Install the chatzilla plugin (you will need to tell Firefox you
>    trust hacksrus before it lets you do this, but otherwise this is
>    just a matter of finding the right link and clicking on it)
>
> 3. Select chatzilla from the Tools menu and fire her up
>
So far so good.

> 4. connect to the right channel (to be determined)
>
Waiting for further instructions on this.

> I did it yesterday, on this mac ,  in 5 minutes

Thanks and welcome to the club:-)

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 Jul 28 19:39:48 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 29 Jul 2005 08:39:48 +0900
Subject: [tei-council] Next conference call
Message-ID: <ygfoe8mcxff.fsf@chwpb.local>

Sebastian, council members,

As you know, Sebastian volunteered to use some webmagic to determine
the date of our next on-wire meeting.  Since some time has elapsed
since then, I wonder if we can hear the results so that preparations
can start.

BTW, I now got a brand new handsfree set and hope that will improve
audability on my side.

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 computing-services.oxford.ac.uk  Fri Jul 29 04:57:11 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 29 Jul 2005 09:57:11 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <ygfslxycxk5.fsf@chwpb.local>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>	<17110.52215.774095.934130@emt.wwp.brown.edu>	<42D6E7E2.2060101@umd.edu>	<ygfd5pkx5by.fsf@chwpb.local>
	<42D78296.5030904@umd.edu>	<42D83D58.2010503@kantl.be>
	<ygfr7dzvbdf.fsf@chwpb.local>	<42DAB4FB.7070405@computing-services.oxford.ac.uk>	<17116.595.844748.107987@emt.wwp.brown.edu>	<42E767D2.2080407@computing-services.oxford.ac.uk>	<17127.53888.306765.835911@emt.wwp.brown.edu>	<42E7EBA1.5000806@computing-services.oxford.ac.uk>	<ygfu0if3b6q.fsf@kanji.zinbun.kyoto-u.ac.jp>	<42E89013.7040305@computing-services.oxford.ac.uk>
	<ygfslxycxk5.fsf@chwpb.local>
Message-ID: <42E9EF67.8030506@computing-services.oxford.ac.uk>

Christian Wittern wrote:
> Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:
> 
> 
>>4. connect to the right channel (to be determined)
>>
> 
> Waiting for further instructions on this.
> 

After having set various preferences in Chatzilla (like your 'Nickname')
Then you can either manually connect by using
/attach irc.freenode.net
/join #tei-c

or you can connect more automatically by using the url
irc://irc.freenode.net/tei-c
as you would a normal url in firefox.
(Which means it can be bookmarked etc. as well.)

I still prefer gaim, but that is because it is multiprotocol.
-- 
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 Jul 30 11:51:09 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 30 Jul 2005 16:51:09 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
Message-ID: <42EBA1ED.7070603@computing-services.oxford.ac.uk>

I'm rather slowly working my way through the proposals in Syd's table of 
attributes in  a more or less random order, picking off the simple cases 
first. I am simply applying the changes proposed where they seem 
non-controversial and/or already agreed to, but this is not always the case!

As the whole document is a bit long to digest, I am going to post a few 
specific queries as they come up, to sound out Council's views:

1. Drop the following attributes on teiHeader:

creator  (Syd proposes using resp instead)
status (this can take values "new" and "updated")

It seems useful to me to distinguish the agency responsible for creation 
of a header from the person who last changed it (which is identifiable 
from the <revisionDesc>)  but maybe not?  I'm less sure about the 
usefulness of STATUS. Anyone use these attributes?

2. Drop the wscale attribute on <alt> and <altGrp> (presumably because 
the  weight attribute  should contain a quantity and a scale as a single 
value -- but this is not explicit in Syd's table)

This seems reasonable in itself. On the other hand <alt> is a pretty 
recondite element which probably needs a lot more thought

3. Drop <xxxSpan> elements in favour of HORSE-style attributes (i.e. 
something like the spanTo attribute added to <index>)

I am basically in favour of this proposal, but it needs more careful and 
detailed articulation

4. drop SIGIL on <witness> in favour of xml:id

This would be consistent with what we have already done for <hand> and 
<handShift>.  But will the users of <witness> be happy having to say 
<witness xml:id="foo"> instead of <witness sigil="foo">?

From sebastian.rahtz at computing-services.oxford.ac.uk  Sat Jul 30 16:57:12 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sat, 30 Jul 2005 21:57:12 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42EBA1ED.7070603@computing-services.oxford.ac.uk>
References: <42EBA1ED.7070603@computing-services.oxford.ac.uk>
Message-ID: <42EBE9A8.8080606@computing-services.oxford.ac.uk>

Lou Burnard wrote:

> 1. Drop the following attributes on teiHeader:
>
> creator  (Syd proposes using resp instead)
> status (this can take values "new" and "updated")
>
> It seems useful to me to distinguish the agency responsible for
> creation of a header from the person who last changed it (which is
> identifiable from the <revisionDesc>)  but maybe not?  I'm less sure
> about the usefulness of STATUS. Anyone use these attributes?

<revisionDesc> applies to the document, not the header, surely? @creator
is the metadata stiuff only.
you might argue that <teiHeader> should be allowed
a child <respStmt> of its own.

any act of creation should generate a <change> in <revisionDesc> anyway,
by the way (and IMHO)

@status seems too limited to be of serious use.

>
> 3. Drop <xxxSpan> elements in favour of HORSE-style attributes (i.e.
> something like the spanTo attribute added to <index>)

>
> I am basically in favour of this proposal, but it needs more careful
> and detailed articulation

if I recall discussions with Lou correctly, my sticking point was that
idea that <del> would sometimes be empty
and sometimes not, which seems bothersome

>
> 4. drop SIGIL on <witness> in favour of xml:id
>
> This would be consistent with what we have already done for <hand> and
> <handShift>.  But will the users of <witness> be happy having to say
> <witness xml:id="foo"> instead of <witness sigil="foo">?

why on earth would they care either way? if you let them have a private
recondite name for an ID attribute, everyone
else will want one 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 Laurent.Romary at loria.fr  Sun Jul 31 04:41:19 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Sun, 31 Jul 2005 10:41:19 +0200
Subject: [tei-council] meeting technologies
In-Reply-To: <42E9EF67.8030506@computing-services.oxford.ac.uk>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>	<17110.52215.774095.934130@emt.wwp.brown.edu>	<42D6E7E2.2060101@umd.edu>	<ygfd5pkx5by.fsf@chwpb.local>
	<42D78296.5030904@umd.edu>	<42D83D58.2010503@kantl.be>
	<ygfr7dzvbdf.fsf@chwpb.local>	<42DAB4FB.7070405@computing-services.oxford.ac.uk>	<17116.595.844748.107987@emt.wwp.brown.edu>	<42E767D2.2080407@computing-services.oxford.ac.uk>	<17127.53888.306765.835911@emt.wwp.brown.edu>	<42E7EBA1.5000806@computing-services.oxford.ac.uk>	<ygfu0if3b6q.fsf@kanji.zinbun.kyoto-u.ac.jp>	<42E89013.7040305@computing-services.oxford.ac.uk>
	<ygfslxycxk5.fsf@chwpb.local>
	<42E9EF67.8030506@computing-services.oxford.ac.uk>
Message-ID: <51160d00da7c5e1b59d0f6b35d5e1fe9@loria.fr>

The thing is intalled on my Mac as well!
Laurent

Le 29 juil. 05, ? 10:57, James Cummings a ?crit :

> Christian Wittern wrote:
>> Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:
>>> 4. connect to the right channel (to be determined)
>>>
>> Waiting for further instructions on this.
>
> After having set various preferences in Chatzilla (like your 
> 'Nickname')
> Then you can either manually connect by using
> /attach irc.freenode.net
> /join #tei-c
>
> or you can connect more automatically by using the url
> irc://irc.freenode.net/tei-c
> as you would a normal url in firefox.
> (Which means it can be bookmarked etc. as well.)
>
> I still prefer gaim, but that is because it is multiprotocol.
> -- 
> 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 sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 31 05:19:17 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 31 Jul 2005 10:19:17 +0100
Subject: [tei-council] meeting technologies
In-Reply-To: <51160d00da7c5e1b59d0f6b35d5e1fe9@loria.fr>
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>	<17110.52215.774095.934130@emt.wwp.brown.edu>	<42D6E7E2.2060101@umd.edu>	<ygfd5pkx5by.fsf@chwpb.local>	<42D78296.5030904@umd.edu>	<42D83D58.2010503@kantl.be>	<ygfr7dzvbdf.fsf@chwpb.local>	<42DAB4FB.7070405@computing-services.oxford.ac.uk>	<17116.595.844748.107987@emt.wwp.brown.edu>	<42E767D2.2080407@computing-services.oxford.ac.uk>	<17127.53888.306765.835911@emt.wwp.brown.edu>	<42E7EBA1.5000806@computing-services.oxford.ac.uk>	<ygfu0if3b6q.fsf@kanji.zinbun.kyoto-u.ac.jp>	<42E89013.7040305@computing-services.oxford.ac.uk>	<ygfslxycxk5.fsf@chwpb.local>	<42E9EF67.8030506@computing-services.oxford.ac.uk>
	<51160d00da7c5e1b59d0f6b35d5e1fe9@loria.fr>
Message-ID: <42EC9795.1090409@computing-services.oxford.ac.uk>

Laurent Romary wrote:

> The thing is intalled on my Mac as well!

so, Christian, where are 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  Sun Jul 31 10:16:47 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 31 Jul 2005 10:16:47 -0400
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42EBE9A8.8080606@computing-services.oxford.ac.uk>
References: <42EBA1ED.7070603@computing-services.oxford.ac.uk>
	<42EBE9A8.8080606@computing-services.oxford.ac.uk>
Message-ID: <17132.56655.667577.878408@emt.wwp.brown.edu>

> <revisionDesc> applies to the document, not the header, surely?

I have often entered <change> elements in a <revisionDesc> that
describe a change to the <teiHeader>. I think of <revisionDesc> as a
revision description of the entire file (<TEI.2>, <teiCorpus2>,
whatever). 

> @creator is the metadata stiuff only. you might argue that
> <teiHeader> should be allowed a child <respStmt> of its own.

Might, but I wouldn't.

> @status seems too limited to be of serious use.

Remember that it (currently) has dateCreated= and dateUpdated= to go
with it. But nonetheless, I agree completely. Even all combined, they
are not really useful, and probably should be dropped.

We might create a mechanism for stating that a particular <change> in
the <revisionDesc> applies to only the <teiHeader>, not the <text>.
(E.g., attribute scope { ( "header" | "text" | "both" ) } or
something like that), but since we're not planning on using
independent headers anymore, I'm not sure there's a significant
advantage to such a scheme.

LB> 3. Drop <xxxSpan> elements in favour of HORSE-style attributes (i.e.
LB> something like the spanTo attribute added to <index>)

LB> I am basically in favour of this proposal, but it needs more careful
LB> and detailed articulation

I agree. If members of Council are interested, you can glean a little
bit more information about HORSE from the slides to my talk at ACH,
which are at
  http://www.tei-c.org/Talks/2005/ACH-ALLC/Bauman.tgz
particularly slides 6, 7, and 8. (There is currently no pointer from
any index page to those slides, as the other talks from that session
are not available yet due to licensing issues I just haven't gotten
around to dealing with.)

> why on earth would they care either way? if you let them have a
> private recondite name for an ID attribute, everyone else will want
> one too.

Really good point. The problem is that "they", the folks who use
<witness>, already have sigil= in P4. So it's not a question of
letting "them" have a special name, it will be viewed more as taking
away the special name currently available.

From James.Cummings at computing-services.oxford.ac.uk  Sun Jul 31 11:02:26 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 31 Jul 2005 16:02:26 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42EBA1ED.7070603@computing-services.oxford.ac.uk>
References: <42EBA1ED.7070603@computing-services.oxford.ac.uk>
Message-ID: <42ECE802.3040006@computing-services.oxford.ac.uk>

Lou Burnard wrote:
> I'm rather slowly working my way through the proposals in Syd's table of 
> attributes in  a more or less random order, picking off the simple cases 
> first. I am simply applying the changes proposed where they seem 
> non-controversial and/or already agreed to, but this is not always the 
> case!
> 
> As the whole document is a bit long to digest, I am going to post a few 
> specific queries as they come up, to sound out Council's views:
> 
> 1. Drop the following attributes on teiHeader:
> 
> creator  (Syd proposes using resp instead)
> status (this can take values "new" and "updated")
> 
> It seems useful to me to distinguish the agency responsible for creation 
> of a header from the person who last changed it (which is identifiable 
> from the <revisionDesc>)  but maybe not?  I'm less sure about the 
> usefulness of STATUS. Anyone use these attributes?

For the record, the OTA uses @type and @date.created but none of the 
others.  I've never noticed anyone using them in other files I've 
looked at....

> 3. Drop <xxxSpan> elements in favour of HORSE-style attributes (i.e. 
> something like the spanTo attribute added to <index>)
> 
> I am basically in favour of this proposal, but it needs more careful and 
> detailed articulation

I'd agree with this (with a more detailed proposal).

> 
> 4. drop SIGIL on <witness> in favour of xml:id
> 
> This would be consistent with what we have already done for <hand> and 
> <handShift>.  But will the users of <witness> be happy having to say 
> <witness xml:id="foo"> instead of <witness sigil="foo">?

My instant reaction to this was that I disagreed.  However, I'm 
willing to be convinced.

My reason for that was I have a vague memory of using
<witness id="OneThing" sigil="AnotherThing"> previously.
My understanding was that the sigil was a nice ID which then I'd
use in my <rdg>'s etc. elsewhere.  So the <rdg> refers
back to the content of the <witness> in a semantic way as expressed by 
the guidelines, but that an id or now xml:id simply locates the 
element.  So a sigil is an xml:id with meaning.  I realise that is 
fairly tenuous.

I think I had previously mis-used them where an id was used for a 
long-form of a sigil and sigil was used for the publicly-viewable 
version.

If we follow this further, does that mean <rdg> becomes
<rdg wit="#MsA #MsB #MsC"> instead of
<rdg wit="MsA MsB MsC"> ?

If that is happening across the board with other attributes which 
function as an ID then I guess it is a good thing.  But I thought I 
should attempt to express my instant (and irrational) first impression.

-James

From sebastian.rahtz at computing-services.oxford.ac.uk  Sun Jul 31 16:27:52 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 31 Jul 2005 21:27:52 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42ECE802.3040006@computing-services.oxford.ac.uk>
References: <42EBA1ED.7070603@computing-services.oxford.ac.uk>
	<42ECE802.3040006@computing-services.oxford.ac.uk>
Message-ID: <42ED3448.8090106@computing-services.oxford.ac.uk>

James Cummings wrote:

>
> If we follow this further, does that mean <rdg> becomes
> <rdg wit="#MsA #MsB #MsC"> instead of
> <rdg wit="MsA MsB MsC"> ?
>
> If that is happening across the board with other attributes which
> function as an ID then I guess it is a good thing.  But I thought I
> should attempt to express my instant (and irrational) first impression.
>
thats the way the cookie crumbles, I am afraid. those # signs are going
to be with
you for ever 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 computing-services.oxford.ac.uk  Sun Jul 31 16:34:08 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Sun, 31 Jul 2005 21:34:08 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <17132.56655.667577.878408@emt.wwp.brown.edu>
References: <42EBA1ED.7070603@computing-services.oxford.ac.uk>	<42EBE9A8.8080606@computing-services.oxford.ac.uk>
	<17132.56655.667577.878408@emt.wwp.brown.edu>
Message-ID: <42ED35C0.6090304@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>><revisionDesc> applies to the document, not the header, surely?
>>    
>>
>
>I have often entered <change> elements in a <revisionDesc> that
>describe a change to the <teiHeader>. I think of <revisionDesc> as a
>revision description of the entire file (<TEI.2>, <teiCorpus2>,
>whatever). 
>  
>
Yes, so do I.

>
>We might create a mechanism for stating that a particular <change> in
>the <revisionDesc> applies to only the <teiHeader>, not the <text>.
>(E.g., attribute scope { ( "header" | "text" | "both" ) } or
>something like that)
>  
>
yrugh. If you must. I find it hard to imagine when one would
make use of it in Real Life (tm).

>Really good point. The problem is that "they", the folks who use
><witness>, already have sigil= in P4. So it's not a question of
>letting "them" have a special name, it will be viewed more as taking
>away the special name currently available.
>
>  
>
Well, P5 never promised to be backward compatible. Lots of people
are going to have to get used to small (but significant to them) changes.

If @sigil *is* a normal ID, there is no argument, it must be @xml:id.
Unless James can argue his case in full court.

-- 
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 Jul 31 18:09:30 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 31 Jul 2005 23:09:30 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42ED35C0.6090304@computing-services.oxford.ac.uk>
References: <42EBA1ED.7070603@computing-services.oxford.ac.uk>	<42EBE9A8.8080606@computing-services.oxford.ac.uk>	<17132.56655.667577.878408@emt.wwp.brown.edu>
	<42ED35C0.6090304@computing-services.oxford.ac.uk>
Message-ID: <42ED4C1A.70503@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
>>Really good point. The problem is that "they", the folks who use
>><witness>, already have sigil= in P4. So it's not a question of
>>letting "them" have a special name, it will be viewed more as taking
>>away the special name currently available.
> If @sigil *is* a normal ID, there is no argument, it must be @xml:id.
> Unless James can argue his case in full court.

Under P4 @sigil is datatype CDATA.  And "indicates the sigil for one 
witness or for one group of witnesses to which readings are assigned 
in a critical apparatus".  Indicating the sigil, to me, doesn't mean 
the same thing as providing an element ID.  Is it possible, for 
example, for a well-known standard sigil to comprise of something 
which doesn't form a proper @xml:id?

The notes to <witness> instead point to one of the uses of @id on this 
as the sigil: "In local encoding schemes, the value of the id 
attribute can be used as the sigil, and the declared value of the wit 
attribute may be changed to IDREF, so as to ensure that only witnesses 
referred to in a <witness> element contained within a <witList> may 
occur in the value of any wit attribute on a reading element within an 
apparatus."  This implies to me that there are also instances where 
one wouldn't want @id to be used as the sigil. Although this 
validation is useful (and what @id is meant for) providing this 
validation is not the point of the @sigil attribute.  It just strikes 
me that the sigil attribute is used to record a sigil, which may, or 
may not, be the same as an @id.

In addition, as Syd says, it seems like P5 (which provides such 
benefits for manuscript encoding) then would be removing the ability 
to record a sigil.  <witness xml:id="MS123"> doesn't mean the
same thing as <witness sigil="123"> or <witness xml:id="MS123" 
sigil="123">.

But I've not really given it any serious thought yet, and as I said, 
I'm willing to be convinced.

-James

From lou.burnard at computing-services.oxford.ac.uk  Sun Jul 31 18:40:00 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 31 Jul 2005 23:40:00 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42ED4C1A.70503@computing-services.oxford.ac.uk>
References: <42EBA1ED.7070603@computing-services.oxford.ac.uk>	<42EBE9A8.8080606@computing-services.oxford.ac.uk>	<17132.56655.667577.878408@emt.wwp.brown.edu>	<42ED35C0.6090304@computing-services.oxford.ac.uk>
	<42ED4C1A.70503@computing-services.oxford.ac.uk>
Message-ID: <42ED5340.9020905@computing-services.oxford.ac.uk>

I agree with Jas that there might be cases where you'd want to use 
something different for a sigil and for an ID. However, (a) it's pretty 
hard to understand what function a "sigil" attribute on <witness> might 
perform which wouldn't be covered by *either* the xml:id attribute *or* 
the n attribute (b) an attribute that then cites the sigil has to be 
*either* a URL *or* NOT.  P4 shilly-shallies on this basic distinction 
all over the place and It Has To Stop.

James Cummings wrote:

> Sebastian Rahtz wrote:
>
>>> Really good point. The problem is that "they", the folks who use
>>> <witness>, already have sigil= in P4. So it's not a question of
>>> letting "them" have a special name, it will be viewed more as taking
>>> away the special name currently available.
>>
>> If @sigil *is* a normal ID, there is no argument, it must be @xml:id.
>> Unless James can argue his case in full court.
>
>
> Under P4 @sigil is datatype CDATA.  And "indicates the sigil for one 
> witness or for one group of witnesses to which readings are assigned 
> in a critical apparatus".  Indicating the sigil, to me, doesn't mean 
> the same thing as providing an element ID.  Is it possible, for 
> example, for a well-known standard sigil to comprise of something 
> which doesn't form a proper @xml:id?
>
> The notes to <witness> instead point to one of the uses of @id on this 
> as the sigil: "In local encoding schemes, the value of the id 
> attribute can be used as the sigil, and the declared value of the wit 
> attribute may be changed to IDREF, so as to ensure that only witnesses 
> referred to in a <witness> element contained within a <witList> may 
> occur in the value of any wit attribute on a reading element within an 
> apparatus."  This implies to me that there are also instances where 
> one wouldn't want @id to be used as the sigil. Although this 
> validation is useful (and what @id is meant for) providing this 
> validation is not the point of the @sigil attribute.  It just strikes 
> me that the sigil attribute is used to record a sigil, which may, or 
> may not, be the same as an @id.
>
> In addition, as Syd says, it seems like P5 (which provides such 
> benefits for manuscript encoding) then would be removing the ability 
> to record a sigil.  <witness xml:id="MS123"> doesn't mean the
> same thing as <witness sigil="123"> or <witness xml:id="MS123" 
> sigil="123">.
>
> But I've not really given it any serious thought yet, and as I said, 
> I'm willing to be convinced.
>
> -James
> _______________________________________________
> 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 Aug  1 00:31:07 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 01 Aug 2005 13:31:07 +0900
Subject: [tei-council] meeting technologies
In-Reply-To: <42EC9795.1090409@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Sun, 31 Jul 2005 10:19:17 +0100")
References: <42D19C0B.7000705@computing-services.oxford.ac.uk>
	<ygfackudtl1.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<D3840523-1E00-43E7-A919-54EDE6495755@indiana.edu>
	<17110.52215.774095.934130@emt.wwp.brown.edu>
	<42D6E7E2.2060101@umd.edu>
	<ygfd5pkx5by.fsf@chwpb.local> <42D78296.5030904@umd.edu>
	<42D83D58.2010503@kantl.be> <ygfr7dzvbdf.fsf@chwpb.local>
	<42DAB4FB.7070405@computing-services.oxford.ac.uk>
	<17116.595.844748.107987@emt.wwp.brown.edu>
	<42E767D2.2080407@computing-services.oxford.ac.uk>
	<17127.53888.306765.835911@emt.wwp.brown.edu>
	<42E7EBA1.5000806@computing-services.oxford.ac.uk>
	<ygfu0if3b6q.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<42E89013.7040305@computing-services.oxford.ac.uk>
	<ygfslxycxk5.fsf@chwpb.local>
	<42E9EF67.8030506@computing-services.oxford.ac.uk>
	<51160d00da7c5e1b59d0f6b35d5e1fe9@loria.fr>
	<42EC9795.1090409@computing-services.oxford.ac.uk>
Message-ID: <ygffytu2s8k.fsf@kanji.zinbun.kyoto-u.ac.jp>

Sebastian Rahtz <sebastian.rahtz at computing-services.oxford.ac.uk> writes:

> Laurent Romary wrote:
>
>> The thing is intalled on my Mac as well!
>
> so, Christian, where are you?
>

I am still here.  Do you think I have to sit there and watch that space,
day and night?

Christian

-- 
 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From sebastian.rahtz at computing-services.oxford.ac.uk  Mon Aug  1 17:53:21 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Mon, 01 Aug 2005 22:53:21 +0100
Subject: [tei-council] Next conference call
In-Reply-To: <ygfoe8mcxff.fsf@chwpb.local>
References: <ygfoe8mcxff.fsf@chwpb.local>
Message-ID: <42EE99D1.6020407@computing-services.oxford.ac.uk>

Friday 9th September is what the Meetomatic oracle declares. of the 7
people who filled in the form,
we'd get 6 on that date. Lets do it then.

-- 
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  Tue Aug  2 18:47:26 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 02 Aug 2005 23:47:26 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42ED35C0.6090304@computing-services.oxford.ac.uk>
References: <42EBA1ED.7070603@computing-services.oxford.ac.uk>	<42EBE9A8.8080606@computing-services.oxford.ac.uk>	<17132.56655.667577.878408@emt.wwp.brown.edu>
	<42ED35C0.6090304@computing-services.oxford.ac.uk>
Message-ID: <42EFF7FE.6030201@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:

>Syd Bauman wrote:
>
>  
>
>>><revisionDesc> applies to the document, not the header, surely?
>>>   
>>>
>>>      
>>>
>>I have often entered <change> elements in a <revisionDesc> that
>>describe a change to the <teiHeader>. I think of <revisionDesc> as a
>>revision description of the entire file (<TEI.2>, <teiCorpus2>,
>>whatever). 
>> 
>>
>>    
>>
>Yes, so do I.
>
>  
>

I have followed this advice, and now removed all attributes from the TEI 
Header (other than type). I have also added the following text to 
chapter HD:

<p>The main purpose of the revision description is to record changes
in the text to which a header is prefixed. However, it is recommended
TEI practice to include entries also for significant changes in the
header itself (other than the revision description itself, of
course). At the very least, an entry should be supplied indicating the
date of creation of the header.</p>

Any objections?

From sebastian.rahtz at computing-services.oxford.ac.uk  Tue Aug  2 18:47:49 2005
From: sebastian.rahtz at computing-services.oxford.ac.uk (Sebastian Rahtz)
Date: Tue, 02 Aug 2005 23:47:49 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42EFF7FE.6030201@computing-services.oxford.ac.uk>
References: <42EBA1ED.7070603@computing-services.oxford.ac.uk>	<42EBE9A8.8080606@computing-services.oxford.ac.uk>	<17132.56655.667577.878408@emt.wwp.brown.edu>
	<42ED35C0.6090304@computing-services.oxford.ac.uk>
	<42EFF7FE.6030201@computing-services.oxford.ac.uk>
Message-ID: <42EFF815.8030005@computing-services.oxford.ac.uk>

Lou Burnard wrote:

>
> <p>The main purpose of the revision description is to record changes
> in the text to which a header is prefixed. However, it is recommended
> TEI practice to include entries also for significant changes in the
> header itself (other than the revision description itself, of
> course). At the very least, an entry should be supplied indicating the
> date of creation of the header.</p>
>
> Any objections?

well, I think the first sentence is sort of asking for trouble. the main
purpose
of the revision description is to record changes to the "document"
(or whatever word you want to use for it) as a whole.

but yes it seems fine.

we just made this fairly formal within OSS Watch, with
a more structured <change> and a controlled vocabulary
for types of change. we'd certainly a <change> if what
we did was record a change in the licence (which is in
<availability>)

-- 
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 mjd at hum.ku.dk  Wed Aug  3 07:04:04 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Wed, 03 Aug 2005 13:04:04 +0200
Subject: [tei-council] Report on review of msDesciption chapter
In-Reply-To: <17116.595.844748.107987@emt.wwp.brown.edu>
References: <42DAB4FB.7070405@computing-services.oxford.ac.uk>
Message-ID: <42F0C0C4.11824.EAC3F9@localhost>

My fellow astronauts,

I should like to draw your collective attention to the fact 
that I have now posted my report on the comments submitted 
to me on the new chapter on manuscript description. It is 
available for your perusal at:
http://www.tei-c.org/Activities/MS/msw04.xml

I should be very grateful to receive comments, especially 
pertaining to the points I list as those on which action 
might be taken (I stress the "might"; if I receive no 
feedback it is unlikely that any action will be taken).

all the best,
Matthew

From lou.burnard at computing-services.oxford.ac.uk  Mon Aug  8 08:16:13 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 08 Aug 2005 13:16:13 +0100
Subject: [tei-council] Re: [Fwd: odd class meeting]
In-Reply-To: <42F74ADE.2080609@oucs.ox.ac.uk>
References: <42F74ADE.2080609@oucs.ox.ac.uk>
Message-ID: <42F74D0D.10507@computing-services.oxford.ac.uk>

Forwarded on behalf of SPQR:

Sebastian Rahtz wrote:

>
>Those of you coming to Oxford on September 26 and 27 might like to think
>of booking travel etc. If I am to book hotel rooms for you, please let
>me know dates. I am assuming I am to book a nice (inasmuch as it can be nice in
>England) dinner on 26th....
>
>  
>
I will bring the now-traditional slugs.

From lou.burnard at computing-services.oxford.ac.uk  Mon Aug  8 11:16:05 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 08 Aug 2005 16:16:05 +0100
Subject: [tei-council] comments on edw90
Message-ID: <42F77735.1000204@oucs.ox.ac.uk>

Here are some (rather belated) comments on some substantive issues 
raised by Syd's paper EDW90.

1. Syd's "Challenges"

1.1 The TYPE attribute.

Sebastian and I have done some testing of the feasibility of doing local 
over-rides as described here. Our conclusions are that this is not 
possible on technical grounds, and probably less good an idea than we 
initially thought in any case. What after all does it mean to say that 
"being typed" is a class? Is there any semantic one can associate with 
that which is *not* immediately over-ridden by the specific typology 
defined locally? (If there is, then maybe that would indicate that some 
class other than "typed" is appropriate).

Our recommendation is that
- the tei.typed class should be removed
- elements bearing a type attribute (and former members of the typed 
class) should be checked to see whether their valLists constitute an 
open or closed list
- for closed list, the datatype will be an alternation of the possible 
values
- for open (or semi) lists, the datatype will be tei.enumerated, i.e. a 
single token not containing whitespace

1.2 Over-riding of attributes

I think we can actually make explicit some of what Syd is describing 
here by using the RelaxNG method of defining facets. So we could for 
example say that a datatype was basically a positive integer, but with 
the added constraint that it has a value less than 43 by a construct such as

      <datatype>
  	<rng:data type="nonNegativeInteger">
  	  <rng:param name="maxInclusive">42</rng:param>
  	</rng:data>
        </datatype>

If (and only if) there is a 1:1 mapping between a TEI datatype and an 
RNHG datatype we could presumably also do

  <datatype>
  	<rng:data>
           <rng:ref name="tei.nonNegativeInteger">
  	  <rng:param name="maxInclusive">42</rng:param>
  	</rng:data>
   </datatype>

but it's not clear what this would mean for TEI datatypes which mapped 
to more than one RNG datatype or an expression

In the general case, however, we think that all datatype definitions 
should be complete and appropriate. In practice, we think the vast 
majority of TEI attributes are already catered for by a very small 
number of datatypes. (of the 500+ attributes listed by Syd, about 400 
are covered by derivations of tei.data.token, tei.data.pointer and 
tei.data.uboolean)

We conclude that

- datatypes should be expressed as <rng:data> expressions
- for commonly occurring cases (see below) we should define a small 
number of macros, which will be named in the way Syd proposes for datatypes
- it should be possible to map all datatypes to W3C basic datatypes, 
possibly with additional constraints

1.3 constraints

The TEI has always proposed additional constraints in remarks, valDesc, 
and descriptive prose. We think we should use the Schematron language to 
express some of these: the primary use case being constraints on 
acceptable GIs as targets for various pointing attributes.

We are not sure where these constraints go in ODD-world, but probably 
not in the <datatype>. We recommend using Schematron for them because 
(a) we know it does the job (b) it is a candidate ISO recommendation.

2. Syd's comments on tokenization

I think anything we can do to reduce the complications consequent on the 
whitespace rules of XML is an unalloyed Good Thing, and propose to be 
even more draconian than Syd suggests. My suggestion is that we allow 
only token, nmtoken, and tei.data.token. While sympathising with the 
motivation for it, I feel that the distinction Syd proposes between 
"tei.data.string" and "tei.data.tokens" will only confuse people. If the 
value of a sequence of tokens is to be interpreted as a single string, 
then it probably shouldn't be an attribute at all. (That said, there's a 
strong case to be made for using "tei.data.tokens" as its name!)

3. Proposed datatypes

These I like:
tei.data.token, tei.data.tokens, tei.data.pointer, tei.data.pointers

Constraining tei.data.token/s further as NMTOKEN/S/NCName/QNAME etc. is 
possible, but I am not sure how many elements would benefit from it

Names I would prefer:
for tei.data.uboolean -> tei.data.truthValue

Names I'm not sure about
tei.data.temporalExpression: how does this map to ISO 8601?
(I assume it doesn't include dateRanges, for example)

tei.data.duration
  We should adopt a consistent policy as to whether quantities like this 
include their units, or whether the units are supplied as a separate 
attribute. I think I prefer the second option, as being more flexible.

tei.data.probability
  Not convinced we need this. There are very few candidates in the EDW90 
table (I find 1, to be exact!)

tei.data.numeric
  I'm now coming round to the view that we also need a tei.data.integer

tei.data.language
  I agree that we need to document exactly what this means somewhere and 
providing a TEI name for it is a good way of doing so.

tei.data.code and tei.data.key

   I have a different understanding of these.

Syd defines tei.data.code as a version of tei.data.pointer, with the 
extra constraint that the target must be in the present document. I am 
not sure what benefit there might be to adding this constraint.

More seriously, however, tei.data.key is defined as its complement, i.e. 
a tei.data.pointer with the constraint that its target must *not* be in 
the current document. I am even less clear what benefit there is in 
that, and find the naming rather confusing, since we are currently using 
"key=" attributes for things which are explicitly not pointers and which 
might even be in the same document (e.g. in TD)

I think we should stick to tei.data.pointer (by all means add 
tei.data.pointer.local, if need be) for the URI case, and keep 
tei.data.code (or key) for use when all we can say of the attribute is 
that its value is a magic token which might get you somewhere in some 
external system, e.g. a database key, but which cannot be validated. It 
might also be useful for cases where an association is made by 
co-reference, as with the ident/key pair in TD, or in whatever variety 
of HORSE we finally decide to back.

That's probably enough to be going on with for the moment...

Lou

From jawalsh at indiana.edu  Tue Aug  9 11:39:12 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Tue, 9 Aug 2005 10:39:12 -0500
Subject: [tei-council] Re: [Fwd: odd class meeting]
In-Reply-To: <42F74D0D.10507@computing-services.oxford.ac.uk>
References: <42F74ADE.2080609@oucs.ox.ac.uk>
	<42F74D0D.10507@computing-services.oxford.ac.uk>
Message-ID: <A4742D50-DBBD-4B21-B951-65A1A72A5F3A@indiana.edu>

Have we decided on the final group for this meeting?

John
| John A. Walsh, Associate Director for Projects and Services
| Digital Library Program / Indiana University Libraries
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 Fax:812-856-2062 <mailto:jawalsh at indiana.edu>

On Aug 8, 2005, at 7:16 AM, Lou Burnard wrote:

> Forwarded on behalf of SPQR:
>
> Sebastian Rahtz wrote:
>
>
>>
>> Those of you coming to Oxford on September 26 and 27 might like to  
>> think
>> of booking travel etc. If I am to book hotel rooms for you, please  
>> let
>> me know dates. I am assuming I am to book a nice (inasmuch as it  
>> can be nice in
>> England) dinner on 26th....
>>
>>
>>
> I will bring the now-traditional slugs.
> _______________________________________________
> 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  Wed Aug 10 21:36:46 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 11 Aug 2005 10:36:46 +0900
Subject: [tei-council] Next conference call
In-Reply-To: <42EE99D1.6020407@computing-services.oxford.ac.uk> (Sebastian
	Rahtz's message of "Mon, 01 Aug 2005 22:53:21 +0100")
References: <ygfoe8mcxff.fsf@chwpb.local>
	<42EE99D1.6020407@computing-services.oxford.ac.uk>
Message-ID: <ygfiryd1cgh.fsf@kanji.zinbun.kyoto-u.ac.jp>

Sebastian Rahtz <sebastian.rahtz at computing-services.oxford.ac.uk> writes:

> Friday 9th September is what the Meetomatic oracle declares. of the 7
> people who filled in the form,
> we'd get 6 on that date. Lets do it then.
>

Then it looks like I was the one who could not make it :-(.  

I will try to make it possible to catch a phone that night, but I will
be very busy the whole week with little time for the preparations of
the meeting.

The next conference call of the TEI council will then be on 2005-09-09
at 1300 UTC.  I hope we can have a dual-media (multimedia?) call,
using the voice phone and IRC chat in parallel.  For those who need
instructions to do IRC, please post your questions here well before
the call.  There is also always the opportunity to meet some of the
Oxford folks at the freenode hangout.

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  Wed Aug 10 21:43:52 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 11 Aug 2005 10:43:52 +0900
Subject: [tei-council] Re: [Fwd: odd class meeting]
In-Reply-To: <42F74D0D.10507@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Mon, 08 Aug 2005 13:16:13 +0100")
References: <42F74ADE.2080609@oucs.ox.ac.uk>
	<42F74D0D.10507@computing-services.oxford.ac.uk>
Message-ID: <ygfek911c4n.fsf@kanji.zinbun.kyoto-u.ac.jp>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> Forwarded on behalf of SPQR:
>
> Sebastian Rahtz wrote:
>
>>
>>Those of you coming to Oxford on September 26 and 27 might like to think
>>of booking travel etc. If I am to book hotel rooms for you, please let
>>me know dates. I am assuming I am to book a nice (inasmuch as it can be nice in
>>England) dinner on 26th....
>>
>>  
>>
> I will bring the now-traditional slugs.

As far as I remember you do not usually have to bring them, they
should be provided for free.

And yes, I would appreciate if Sebastian could book a room for me when
he reemerges online.  I plan to arrive on the 25th and will leave on
the 29th, so that would be 4 nights.

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  Wed Aug 10 21:57:10 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 11 Aug 2005 10:57:10 +0900
Subject: [tei-council] comments on edw90
In-Reply-To: <42F77735.1000204@oucs.ox.ac.uk> (Lou Burnard's message of "Mon,
	08 Aug 2005 16:16:05 +0100")
References: <42F77735.1000204@oucs.ox.ac.uk>
Message-ID: <ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>

Thanks for your comments Lou.  It looks like we are actually moving
forward a lot:-)

I can't claim to understand everything, but it looks good as you
present it.  Just some very small quibbles:

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> Our recommendation is that
> - the tei.typed class should be removed
> - elements bearing a type attribute (and former members of the typed
>   class) should be checked to see whether their valLists constitute an
>   open or closed list
> - for closed list, the datatype will be an alternation of the possible
>   values
> - for open (or semi) lists, the datatype will be tei.enumerated,
>   i.e. a single token not containing whitespace

I assume what this comes down to is that every element in need of it
will get a @type directly without the indirection through the class system.

> We conclude that
>
> - datatypes should be expressed as <rng:data> expressions
> - for commonly occurring cases (see below) we should define a small
>   number of macros, which will be named in the way Syd proposes for
>   datatypes
> - it should be possible to map all datatypes to W3C basic datatypes,
>   possibly with additional constraints

Does this mean that we deviate from the principle to base our stuff on
W3C datatypes?  Or does this mean that we get at them through rng:data?

>
> We are not sure where these constraints go in ODD-world, but probably
> not in the <datatype>. We recommend using Schematron for them because
> (a) we know it does the job (b) it is a candidate ISO recommendation.
>

That is very nice, but do you actually plan to provide the necessary
schematrons to do the validation?

>
> tei.data.language
>   I agree that we need to document exactly what this means somewhere
>   and providing a TEI name for it is a good way of doing so.

Is this something different from xml:lang?  If yes, why do we need it?

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 Aug 11 05:38:07 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 11 Aug 2005 10:38:07 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <42F77735.1000204@oucs.ox.ac.uk>
	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <42FB1C7F.2050400@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>Thanks for your comments Lou.  It looks like we are actually moving
>forward a lot:-)
>
>I can't claim to understand everything, but it looks good as you
>present it.  Just some very small quibbles:
>
>Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:
>
>  
>
>>Our recommendation is that
>>- the tei.typed class should be removed
>>- elements bearing a type attribute (and former members of the typed
>>  class) should be checked to see whether their valLists constitute an
>>  open or closed list
>>- for closed list, the datatype will be an alternation of the possible
>>  values
>>- for open (or semi) lists, the datatype will be tei.enumerated,
>>  i.e. a single token not containing whitespace
>>    
>>
>
>I assume what this comes down to is that every element in need of it
>will get a @type directly without the indirection through the class system.
>
>  
>

That's the proposal in essence.

>>We conclude that
>>
>>- datatypes should be expressed as <rng:data> expressions
>>- for commonly occurring cases (see below) we should define a small
>>  number of macros, which will be named in the way Syd proposes for
>>  datatypes
>>- it should be possible to map all datatypes to W3C basic datatypes,
>>  possibly with additional constraints
>>    
>>
>
>Does this mean that we deviate from the principle to base our stuff on
>W3C datatypes?  Or does this mean that we get at them through rng:data?
>
>  
>
The latter.

>>We are not sure where these constraints go in ODD-world, but probably
>>not in the <datatype>. We recommend using Schematron for them because
>>(a) we know it does the job (b) it is a candidate ISO recommendation.
>>
>>    
>>
>
>That is very nice, but do you actually plan to provide the necessary
>schematrons to do the validation?
>
>  
>

We havent yet decided whether to include  schematron assertions (or 
whatever they are called) in all such cases, but there should be some if 
only to demonstrate the concept.

>>tei.data.language
>>  I agree that we need to document exactly what this means somewhere
>>  and providing a TEI name for it is a good way of doing so.
>>    
>>
>
>Is this something different from xml:lang?  If yes, why do we need it?
>
>
>  
>

Good question. I think the general feeling was that it would be helpful 
to document the use of xml:lang by referring to this datatype, but that 
may be a mistake.

>  
>

From James.Cummings at computing-services.oxford.ac.uk  Thu Aug 11 05:56:22 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 11 Aug 2005 10:56:22 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <42FB1C7F.2050400@computing-services.oxford.ac.uk>
References: <42F77735.1000204@oucs.ox.ac.uk>	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<42FB1C7F.2050400@computing-services.oxford.ac.uk>
Message-ID: <42FB20C6.3040306@computing-services.oxford.ac.uk>

Lou Burnard wrote:
>> Is this something different from xml:lang?  If yes, why do we need it?
> Good question. I think the general feeling was that it would be helpful 
> to document the use of xml:lang by referring to this datatype, but that 
> may be a mistake.

Just to make sure I'm understanding this...would that datatype then be used for 
validation of @xml:lang's format?  It seems strange to me to be using a 
tei.datatype to validate and/or document use of a non-TEI element/attribute. 
Will we be doing the same for xml:id? (or html:object or something?)  I guess I 
want to know why xml:lang is in need of the documentation when it's format is an 
external standard?  I think that is at the root of my unease with this (but, as 
always, I'm willing to be convinced).

In addition, on reflection, I am not as bothered as I would have thought in 
regards to the removal of a tei.typed class.

-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 Aug 11 23:06:24 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 12 Aug 2005 12:06:24 +0900
Subject: [tei-council] comments on edw90
In-Reply-To: <42FB20C6.3040306@computing-services.oxford.ac.uk> (James
	Cummings's message of "Thu, 11 Aug 2005 10:56:22 +0100")
References: <42F77735.1000204@oucs.ox.ac.uk>
	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<42FB1C7F.2050400@computing-services.oxford.ac.uk>
	<42FB20C6.3040306@computing-services.oxford.ac.uk>
Message-ID: <ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>

James Cummings <James.Cummings at computing-services.oxford.ac.uk> writes:

> Lou Burnard wrote:
>>> Is this something different from xml:lang?  If yes, why do we need it?
>> Good question. I think the general feeling was that it would be
>> helpful to document the use of xml:lang by referring to this
>> datatype, but that may be a mistake.
>
> Just to make sure I'm understanding this...would that datatype then be
> used for validation of @xml:lang's format?  It seems strange to me to
> be using a tei.datatype to validate and/or document use of a non-TEI
> element/attribute. 

In fact, the whole point of using xml:lang and xml:id is to get the
run-of-the-mill validation from generic xml parsers.  And they do make
sure that the xml:lang is formated according to the spec, which I know
since I have been bitten by Saxon hundreds of times.  

As to the documentation aspect, I think we agreed that that is what
<language> is for and the magic relationship between its @xml:id value
and the value of @xml:lang on other elements is used to bring them
together (the socalled Nancy-Hack).

All the best,

Christian

-- 
 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From sschreib at umd.edu  Fri Aug 12 07:31:57 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Fri, 12 Aug 2005 07:31:57 -0400
Subject: [tei-council] Next conference call
In-Reply-To: <ygfiryd1cgh.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <ygfoe8mcxff.fsf@chwpb.local>	<42EE99D1.6020407@computing-services.oxford.ac.uk>
	<ygfiryd1cgh.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <42FC88AD.3050406@umd.edu>

Would it make sense then to find another time for the meeting?

susan

Christian Wittern wrote:

>Sebastian Rahtz <sebastian.rahtz at computing-services.oxford.ac.uk> writes:
>
>  
>
>>Friday 9th September is what the Meetomatic oracle declares. of the 7
>>people who filled in the form,
>>we'd get 6 on that date. Lets do it then.
>>
>>    
>>
>
>Then it looks like I was the one who could not make it :-(.  
>
>I will try to make it possible to catch a phone that night, but I will
>be very busy the whole week with little time for the preparations of
>the meeting.
>
>The next conference call of the TEI council will then be on 2005-09-09
>at 1300 UTC.  I hope we can have a dual-media (multimedia?) call,
>using the voice phone and IRC chat in parallel.  For those who need
>instructions to do IRC, please post your questions here well before
>the call.  There is also always the opportunity to meet some of the
>Oxford folks at the freenode hangout.
>
>All the best,
>
>Christian
>
>  
>

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742

Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib at umd.edu

From lou.burnard at computing-services.oxford.ac.uk  Fri Aug 12 07:38:01 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 12 Aug 2005 12:38:01 +0100
Subject: [tei-council] Next conference call
In-Reply-To: <42FC88AD.3050406@umd.edu>
References: <ygfoe8mcxff.fsf@chwpb.local>	<42EE99D1.6020407@computing-services.oxford.ac.uk>	<ygfiryd1cgh.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<42FC88AD.3050406@umd.edu>
Message-ID: <42FC8A19.7000605@oucs.ox.ac.uk>

Either we do that, or we nominate a deputy chair. A conference call 
without a chair/ringmaster is not a very enticing prospect

L

Susan Schreibman wrote:
> Would it make sense then to find another time for the meeting?
> 
> susan
> 
> 
> Christian Wittern wrote:
> 
>> Sebastian Rahtz <sebastian.rahtz at computing-services.oxford.ac.uk> writes:
>>
>>  
>>
>>> Friday 9th September is what the Meetomatic oracle declares. of the 7
>>> people who filled in the form,
>>> we'd get 6 on that date. Lets do it then.
>>>
>>>   
>>
>>
>> Then it looks like I was the one who could not make it :-(. 
>> I will try to make it possible to catch a phone that night, but I will
>> be very busy the whole week with little time for the preparations of
>> the meeting.
>>
>> The next conference call of the TEI council will then be on 2005-09-09
>> at 1300 UTC.  I hope we can have a dual-media (multimedia?) call,
>> using the voice phone and IRC chat in parallel.  For those who need
>> instructions to do IRC, please post your questions here well before
>> the call.  There is also always the opportunity to meet some of the
>> Oxford folks at the freenode hangout.
>>
>> All the best,
>>
>> Christian
>>
>>  
>>
> 

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Aug 14 19:43:57 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 15 Aug 2005 08:43:57 +0900
Subject: [tei-council] Next conference call
In-Reply-To: <42FC8A19.7000605@oucs.ox.ac.uk> (Lou Burnard's message of
	"Fri, 12 Aug 2005 12:38:01 +0100")
References: <ygfoe8mcxff.fsf@chwpb.local>
	<42EE99D1.6020407@computing-services.oxford.ac.uk>
	<ygfiryd1cgh.fsf@kanji.zinbun.kyoto-u.ac.jp> <42FC88AD.3050406@umd.edu>
	<42FC8A19.7000605@oucs.ox.ac.uk>
Message-ID: <ygf1x4wccea.fsf@chwpb.local>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> Either we do that, or we nominate a deputy chair. A conference call
> without a chair/ringmaster is not a very enticing prospect

Well, rather then rescheduling the meeting, I reshuffled some of the
stuff on my agenda for Friday the 9th and am reasonably confident now
that I will be able to attend to the call.  After all, its at 10 pm
local time. 

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 Aug 23 08:47:44 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 23 Aug 2005 13:47:44 +0100
Subject: [tei-council] agenda for class meeting
Message-ID: <430B1AF0.2060204@oucs.ox.ac.uk>

I'd like to hear suggestions, both from attendees and from others, about

 * agenda items for the TEI Class Meeting
 * deliverables you expect from the meeting
 * offers of availability to do work items
 * lists of prerequisite material you want distributed
    in advance.

I am away most of the week before the meeting, so no
last-minute requests, please!

I am also away now for 10 days on holiday again (Lake District, thank 
you for asking, boats and jolly daffodils and things, lots of rain, too 
many tourists, shall I take Proust to read?),
so I'd expect to take action on this again on 4th September.

Sebastian

From Julia_Flanders at brown.edu  Sun Aug 28 15:49:52 2005
From: Julia_Flanders at brown.edu (Julia Flanders)
Date: Sun, 28 Aug 2005 15:49:52 -0400
Subject: [tei-council] from OASIS
Message-ID: <43121560.7080701@brown.edu>

This just came to info at tei-c.org; it seems to be something the Council 
might respond to.

-------- Original Message --------
Subject: 	(tr259)
Date: 	Sun, 28 Aug 2005 12:36:20 -0500 (CDT)
From: 	Dr. Laurence Leff <D-Leff at wiu.edu>
To: 	info at tei-c.org

THIS IS AN ELECTRONIC COPY OF AN ITEM BEING TO SENT TO
YOU IN HARDCOPY FORMAT VIA U. S. MAIL AT THE INSIDE ADDRESS BELOW.
This will insure that you get at least one copy.  More importantly, 
sending electronic copies of conventional communications should
eliminate flaming and other problems that have been documented in regards
to electronic mail.

Stipes 447
Department of Computer Science
Western Illinois University
Macomb, IL 61455

** PAGER: ** 309 367 0787
** Fax: ** 309 298 2302

.AM
Text Encoding Initiative Consortium
Institute for Advanced Technology in the Humanities
319 Alderman Library
P. O. Box 400115
University of Virginia
Charlottesville, Virginia 22904-4115

Dear Sir or Madam:

The OASIS Legal XML Member Section e-Contracts Technical Committee
is choosing
a "host schema" to serve as the basis of the "narrative" part of
contracts.

We are, of course, considering Text Encoding Initiative 
The TC has developed evaluation criteria and evaluated TEI against
these criteria at:
http://www.oasis-open.org/committees/download.php/13508/tei.xml.pdf
http://www.oasis-open.org/committees/download.php/13449/R2.pdf

We would like the TEI Consortium to add to our information
for consideration.  We would extend any host schema to include
markup specific to contracts such as lists of the parties, recitals
and provision for written signatures.  As you
may
know, there was an article in XML Europe 2004 on merging TEI and
Docbook.  On this basis, I conclude that we could extend TEI for
the needs of the legal community dealing with contracts.

Thanks for your interest in our possible extension of your work.

Sincerely yours,

Laurence L. Leff, Ph.D.
Associate Professor of Computer Science
Secretary,
The OASIS Legal XML Member Section e-Contracts Technical Committee

cc: info at tei-c.org

** P. S. ** Earlier, I sent a similar letter to Dr. Sperberg-McQueen.
I did not receive a response.  Perhaps, our letter
or the response was lost in the mail or Dr. Sperberg-McQueen was not the person
to whom to write.

From Syd_Bauman at Brown.edu  Sun Aug 28 16:27:53 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 28 Aug 2005 16:27:53 -0400
Subject: [tei-council] from OASIS
In-Reply-To: <43121560.7080701@brown.edu>
References: <43121560.7080701@brown.edu>
Message-ID: <17170.7753.59514.27256@emt.wwp.brown.edu>

> ** P. S. ** Earlier, I sent a similar letter to Dr.
> Sperberg-McQueen. I did not receive a response. Perhaps, our letter
> or the response was lost in the mail or Dr. Sperberg-McQueen was
> not the person to whom to write.

FYI, Michael forwarded the letter to me, and I did respond.

From Syd_Bauman at Brown.edu  Sun Aug 28 22:30:02 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 28 Aug 2005 22:30:02 -0400
Subject: [tei-council] from OASIS
In-Reply-To: <17170.7753.59514.27256@emt.wwp.brown.edu>
References: <43121560.7080701@brown.edu>
	<17170.7753.59514.27256@emt.wwp.brown.edu>
Message-ID: <17170.29482.680194.485047@emt.wwp.brown.edu>

> FYI, Michael forwarded the letter to me, and I did respond.

Well, I seem to be mis-remembering something here. I can find no
record whatsoever of my having received the forward from MSMcQ nor of
sending a reply to this gentleman. On the other hand, I remember the
question, and I remember starting to write a reply.

As best I can piece together from my uselessly hot brain right now
(while it's only 25 degees C here, the humidity is 90%), Michael told
me about the e-mail he received during a phone conversation earlier
this month. He said he'd forward it to me. I started to write a
reply, but apparently never finished it nor sent it for lack of
details and the e-mail address to which to send it, then failed to
follow up with Michael to actually get it from him.

Since I dropped the ball on this one I will volunteer to take it upon
myself to read and respond to their evaluation documents. This is a
significant task, though, so if anyone wants to take it on or
volunteer to help, speak up.

From lou.burnard at computing-services.oxford.ac.uk  Mon Aug 29 08:53:40 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 29 Aug 2005 13:53:40 +0100
Subject: [tei-council] from OASIS
In-Reply-To: <17170.29482.680194.485047@emt.wwp.brown.edu>
References: <43121560.7080701@brown.edu>	<17170.7753.59514.27256@emt.wwp.brown.edu>
	<17170.29482.680194.485047@emt.wwp.brown.edu>
Message-ID: <43130554.7000400@computing-services.oxford.ac.uk>

I think the appropriate person to respond to this enquiry would be 
Christian, as head of the Council. I am very happy to answer any queries 
they may have about interoperating with TEI. Since they are looking at 
legal materials, it's possible that Nick Finke might also be a good 
person to involve.

I don't think "reading and evaluating" their documents should be given a 
higher priority than editorial work on P5 which continues to be 
distressingly late.

Syd Bauman wrote:

>>FYI, Michael forwarded the letter to me, and I did respond.
>>    
>>
>
>Well, I seem to be mis-remembering something here. I can find no
>record whatsoever of my having received the forward from MSMcQ nor of
>sending a reply to this gentleman. On the other hand, I remember the
>question, and I remember starting to write a reply.
>
>As best I can piece together from my uselessly hot brain right now
>(while it's only 25 degees C here, the humidity is 90%), Michael told
>me about the e-mail he received during a phone conversation earlier
>this month. He said he'd forward it to me. I started to write a
>reply, but apparently never finished it nor sent it for lack of
>details and the e-mail address to which to send it, then failed to
>follow up with Michael to actually get it from him.
>
>Since I dropped the ball on this one I will volunteer to take it upon
>myself to read and respond to their evaluation documents. This is a
>significant task, though, so if anyone wants to take it on or
>volunteer to help, speak up.
>
>_______________________________________________
>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 Aug 29 09:43:45 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 29 Aug 2005 09:43:45 -0400
Subject: [tei-council] from OASIS
In-Reply-To: <43130554.7000400@computing-services.oxford.ac.uk>
References: <43121560.7080701@brown.edu>
	<17170.7753.59514.27256@emt.wwp.brown.edu>
	<17170.29482.680194.485047@emt.wwp.brown.edu>
	<43130554.7000400@computing-services.oxford.ac.uk>
Message-ID: <17171.4369.669728.249280@emt.wwp.brown.edu>

> I think the appropriate person to respond to this enquiry would be
> Christian, as head of the Council. I am very happy to answer any
> queries they may have about interoperating with TEI. Since they are
> looking at legal materials, it's possible that Nick Finke might
> also be a good person to involve.

Yes, I also had thought about consulting Nick. If Christian is
willing, I think that would be great.

> I don't think "reading and evaluating" their documents should be
> given a higher priority than editorial work on P5 which continues
> to be distressingly late.

Have you taken a look at their document? I may be mis-remembering,
but it seemed there were several misconceptions which we would do
well to address.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Aug 29 21:42:35 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 30 Aug 2005 10:42:35 +0900
Subject: [tei-council] from OASIS
In-Reply-To: <43130554.7000400@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Mon, 29 Aug 2005 13:53:40 +0100")
References: <43121560.7080701@brown.edu>
	<17170.7753.59514.27256@emt.wwp.brown.edu>
	<17170.29482.680194.485047@emt.wwp.brown.edu>
	<43130554.7000400@computing-services.oxford.ac.uk>
Message-ID: <ygffyss19pw.fsf@kanji.zinbun.kyoto-u.ac.jp>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> I think the appropriate person to respond to this enquiry would be
> Christian, as head of the Council. I am very happy to answer any
> queries they may have about interoperating with TEI. Since they are
> looking at legal materials, it's possible that Nick Finke might also
> be a good person to involve.

Their documents provides an interesting case study of how the TEI is
perceived from the outside and is as such quite interesting.  At this
moment, I lack the time for working on a detailed reply.  I would
suggest that we (Lou?) contact Nick Finke and see if he is willing to
draft a reply, which we then could discuss and use as a base to send
out as "The Councils Reply", which I am willing to prepair.

>
> I don't think "reading and evaluating" their documents should be given
> a higher priority than editorial work on P5 which continues to be
> distressingly late.
>

Hear, hear.  We are making good process however and will hopefully
continue during the crucial period of the next month.

All the best,

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 Aug 30 12:21:43 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 30 Aug 2005 12:21:43 -0400
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <42EFF815.8030005@computing-services.oxford.ac.uk>
References: <42EBA1ED.7070603@computing-services.oxford.ac.uk>
	<42EBE9A8.8080606@computing-services.oxford.ac.uk>
	<17132.56655.667577.878408@emt.wwp.brown.edu>
	<42ED35C0.6090304@computing-services.oxford.ac.uk>
	<42EFF7FE.6030201@computing-services.oxford.ac.uk>
	<42EFF815.8030005@computing-services.oxford.ac.uk>
Message-ID: <17172.34711.545137.680567@emt.wwp.brown.edu>

> 1. Drop the following attributes on teiHeader: ... I have followed
> this advice, and now removed all attributes from the TEI Header
> (other than type). [i.e., creator=, status=, date.created=,
> date.updated= have been removed]

As no one screamed for a resp= on <teiHeader>, I think this is fine.

> I have also added the following text to chapter HD:

As modified (what's in P5 has been updated per Sebastian's
suggestion), this looks fine to me, too. 

> 2. Drop the wscale attribute on <alt> and <altGrp> (presumably
> because the weight attribute should contain a quantity and a scale
> as a single value -- but this is not explicit in Syd's table)

How embarrassing. The note says "see weight= of <alt>", but there is
no entry for weight= of <alt>, as it's the "weights=" attribute of
<alt>. Besides, there's not much really helpful there, so I'll
explain here, then make a quick update to the database.

wScale= serves no purpose in P4 but to differentiate whether the
values in the weights= attribute range from 0 to 1 or 0 to 100. Even
though a value of "75" is unambiguously 75%, a value between 0 and 1
(inclusive) is ambiguous unless wScale= is specified. Thus,
   <alt wScale="real" weights="0 0.5 1"/>
represents odds of 0 (0%), 0.5 (50%), and 1 (100%), whereas
   <alt wScale="perc" weights="0 0.5 1"/>
represents odds of 0 (0%), 0.005 (0.5%), and 0.01 (1%).

However, the suggested datatype for P5 (tei.datatype.probability)
deliberately permits a percent sign in the value itself to perform
this disambiguation. Thus the first example above would be expressed
as either
   <alt weights="0 0.5 1"/>   or      <alt weights="0% 50% 100%"/>

> This seems reasonable in itself. On the other hand <alt> is a
> pretty recondite element which probably needs a lot more thought

Indeed.

From James.Cummings at computing-services.oxford.ac.uk  Tue Aug 30 12:22:20 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 30 Aug 2005 17:22:20 +0100
Subject: [tei-council] Dates, Ranges, Periods and Durations
Message-ID: <431487BC.3020105@computing-services.oxford.ac.uk>

I've been wondering about the tei.temporalExpr class.
Currently (on the website at least) it provides a @value of "xsd:date | 
xsd:gYear | xsd:gMonth | xsd:gDay | xsd:gYearMonth | xsd:gMonthDay | xsd:time | 
xsd:dateTime" and in prose is decribed as "Any string representing a date in any 
of the standard formats recommended as W3C schema datatypes."

This doesn't seem to include xsd:duraton, and duration is catered for in the XML 
Schema spec. http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#duration

What I'm wondering about is whether we should be including the full scope of ISO 
8601 including especially the use of ranges (or 'Time Intervals') and Durations.

A more readable explanation may be available at 
http://en.wikipedia.org/wiki/ISO_8601#Time_intervals

I don't think we cater fully for the ISO spec at the moment.  If we did this 
would mean that any date @value would be able to express dates, times, intervals 
or ranges of time, durations or periods, etc.  This isn't to say that we 
wouldn't need dateRange as a method of indicating certainty/precision with 
regards to one of the ends of the range.

Maybe some of this is differences between ISO 8601:2004 and ISO 8601:2001?

I guess I was just wondering why we weren't seeming to support Durations, 
Periods, Ranges, in the datatype?  But, knowing me, I've probably just 
misunderstood something.

-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 Aug 30 15:56:50 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 30 Aug 2005 15:56:50 -0400
Subject: [tei-council] Dates, Ranges, Periods and Durations
In-Reply-To: <431487BC.3020105@computing-services.oxford.ac.uk>
References: <431487BC.3020105@computing-services.oxford.ac.uk>
Message-ID: <17172.47618.160836.369233@emt.wwp.brown.edu>

I have argued that (ISO 8601) durations should be permitted as the
value of value= of both <date> and <time> for a long time now, but up
until now I thought I was alone in this desire. This is why the
recommendatino in EDW90 for value= of <date> is
tei.data.temporalExpression, as opposed to 
    tei.data.temporalExpression | tei.data.duration
which might make more sense. However, as currently imagined,
tei.data.duration represents a W3C Schema duration, not an ISO 8601
duration. There are differences other than simple profiling.

> What I'm wondering about is whether we should be including the full
> scope of ISO 8601 including especially the use of ranges (or 'Time
> Intervals') and Durations.

My inclination is that yes, we should. But of course W3C only
supports a subset via their XML Schema (part II) datatypes (not to be
confused with the profile described for discussion puproses in the
W3C Note on the subject). This shouldn't stop us from supporting
other expressions, but should give us mild pause -- software that
supports XSD datatypes will be readily available; software that
supports other valid 8601 expressions may not be as easy to come by. 

> Maybe some of this is differences between ISO 8601:2004 and ISO
> 8601:2001?

I didn't know there was a 2004 version. Thanks for the info.

> I guess I was just wondering why we weren't seeming to support
> Durations, Periods, Ranges, in the datatype? But, knowing me, I've
> probably just misunderstood something.

I think it would be a fine idea. We would need to think pretty
seriously about where to follow 8601 and where to follow W3C. (E.g.,
IIRC, W3C does not permit a range indicated by a solidus between two
expressions, which 8601 does; W3C permits a + or - sign before a
duration, which 8601 does not.)

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Aug 30 21:00:22 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 31 Aug 2005 10:00:22 +0900
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <17172.34711.545137.680567@emt.wwp.brown.edu> (Syd Bauman's
	message of "Tue, 30 Aug 2005 12:21:43 -0400")
References: <42EBA1ED.7070603@computing-services.oxford.ac.uk>
	<42EBE9A8.8080606@computing-services.oxford.ac.uk>
	<17132.56655.667577.878408@emt.wwp.brown.edu>
	<42ED35C0.6090304@computing-services.oxford.ac.uk>
	<42EFF7FE.6030201@computing-services.oxford.ac.uk>
	<42EFF815.8030005@computing-services.oxford.ac.uk>
	<17172.34711.545137.680567@emt.wwp.brown.edu>
Message-ID: <ygfslwqzzrt.fsf@kanji.zinbun.kyoto-u.ac.jp>

Syd Bauman <Syd_Bauman at Brown.edu> writes:

>> 1. Drop the following attributes on teiHeader: ... I have followed
>> this advice, and now removed all attributes from the TEI Header
>> (other than type). [i.e., creator=, status=, date.created=,
>> date.updated= have been removed]

Now thinking of this again, for what purpose would you need @type on
teiHeader?

> As no one screamed for a resp= on <teiHeader>, I think this is fine.

With me too.

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 Aug 31 04:14:17 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 31 Aug 2005 17:14:17 +0900
Subject: [tei-council] Upcoming teleconference Friday 2005-09-09 at 1300 UTC
Message-ID: <ygf1x4azfom.fsf@kanji.zinbun.kyoto-u.ac.jp>

Dear Council members,

As you will remember, our next conference call is scheduled for Friday
of this coming week, a mere 9 days away.  Please catch up with what
you planned to do by that time, have a look at EDW 90, and in general
do the usual preparations that are necessary before such an event.  

If there is something you would like to see on the agenda, please do
write to this list (preferably) or to me privately.   As I mentioned,
I will be very busy all the way up to the conference, but I hope to be
able to process requests as necessary. 

As Sebastian suggested, we would like to have a second communication
channel open via IRC Chat at the time of the conference.  James, are
you taking care of this?  Could you please post instructions on how to
get connected etc. 

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 computing-services.oxford.ac.uk  Wed Aug 31 04:49:35 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 31 Aug 2005 09:49:35 +0100
Subject: [tei-council] Upcoming teleconference Friday 2005-09-09 at 1300
	UTC
In-Reply-To: <ygf1x4azfom.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <ygf1x4azfom.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43156F1F.3050203@computing-services.oxford.ac.uk>

Christian Wittern wrote:
> As Sebastian suggested, we would like to have a second communication
> channel open via IRC Chat at the time of the conference.  James, are
> you taking care of this?  Could you please post instructions on how to
> get connected etc. 

Since there is only one non-council member hanging around occasionally in the 
public TEI Consortium IRC channel, does anyone have any objections to using 
that?  (If so, we can create a #tei-council private channel.)

If there are no objections, you may also be interested in the wiki page I have 
created which contains the information necessary to connect.

http://www.tei-c.org.uk/wiki/index.php/IRC

However, the information on specific clients is limited, so do feel free to add 
more detail!

Basically, in almost any IRC client, set the server to be irc.freenode.net
and the channel to be #tei-c and you should be fine.  In some clients this is 
done through setting up an account in various graphical manners, in others you 
might use /connect serverName or /server serverName and then /join #tei-c 
Alternatively, if you have the Chatzilla extension installed, in the address bar 
of firefox you can use this url: irc://irc.freenode.net/tei-c to connect.  My 
preferred client is gaim because it is multi-protocol (does yahoo, aim/aol, msn, 
jabber, gmail, chat protocols amongst others).

-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 Aug 31 16:49:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 31 Aug 2005 16:49:11 -0400 (EDT)
Subject: [tei-council] comments on edw90
In-Reply-To: <ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <42F77735.1000204@oucs.ox.ac.uk>
	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<42FB1C7F.2050400@computing-services.oxford.ac.uk>
	<42FB20C6.3040306@computing-services.oxford.ac.uk>
	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <200508312049.j7VKnBia028939@cepheus.services.brown.edu>

> Sebastian and I have done some testing of the feasibility of doing
> local over-rides as described here. Our conclusions are that this
> is not possible on technical grounds,

This is quite a shame, as such a capability could provide the means
for significant simplification of the TEI scheme, and much of the work
put into ED W 90 was predicated on this possibility. Such is life.

> Our recommendation is that
> - the tei.typed class should be removed
> - elements bearing a type attribute (and former members of the
>   typed class) should be checked to see whether their valLists
>   constitute an open or closed list
> - for closed list, the datatype will be an alternation of the
>   possible values

I presume you mean "set of permissible values" or some such, not
"datatype". (Up until now we've been using the term "datatype" to
express an abstract grouping of values with similar syntactic
constraints and similar semantics, presumably implemented by some form
of indirection. However, there is the potential for lots of confusion,
because the child of <attDef> which is used to abstractly declare the
attribute type is called <datatype>. This is quite unfortunate a
situation, for which I must take the blame -- Sebastian specifically
asked me if any of the names he chose for these elements were
problematic before he cemented them into our processing chain, and I
missed this obvious thorn.)

> - for open (or semi) lists, the datatype will be tei.enumerated,
>   i.e. a single token not containing whitespace

I'm confused. What then is the difference between tei.data.enumerated
and tei.data.token?

In some ways this may feel like a big step backwards, as it is
essentially the system we were using before Paris. But I think this
works almost as well as the system Council sketched out in Paris. If
a TEI-schema-designer wants to restrict users to the values provided
in an open (or semi) list, all she needs to do is change the type of
<valList> from "open" to "closed". (Hmmm... I just realized that this
is actually currently not true. I think she'd have to copy-and-paste
the entire <valList> from the tagdoc into her ODD, which isn't nearly
as nice. Sebastian, could we arrange the process so that just
specifying, e.g.
          <elementSpec module="core" ident="note" mode="change">
            <attList>
              <attDef ident="place">
                <valList type="closed"/>
              </attDef>
            </attList>
          </elementSpec>
would work? It's not ambiguous that the user is trying to remove all
the possible values, because it makes no sense to have an empty
<valList>, especially if the type is "closed"; of course it also
isn't valid ala the current TD.)

> 1.2 Over-riding of attributes
> 
> I think we can actually make explicit some of what Syd is
> describing here by using the RelaxNG method of defining facets. So
> we could for example say that a datatype was basically a positive
> integer, but with the added constraint that it has a value less
> than 43 by a construct such as
>     <datatype>
>       <rng:data type="nonNegativeInteger">
>         <rng:param name="maxInclusive">42</rng:param>
>       </rng:data>
>     </datatype>

Yes, I think this is doable, but it really only addresses a small
subset of what I think we set forth in Paris to do. (And note that
quite a few of the proposed datatypes make use of this.) In
particular, since the restriction is a facet, we can't use this
feature to have one TEI datatype for numeric representations
(tei.data.numeric), and say "this attribute is one of
tei.data.numeric, but must be a non-negative integer".

> If (and only if) there is a 1:1 mapping between a TEI datatype and
> [a W3C Schema] datatype we could presumably also do
>    <datatype>
>      <rng:data>
>        <rng:ref name="tei.nonNegativeInteger">
>        <rng:param name="maxInclusive">42</rng:param>
>      </rng:data>
>    </datatype>

I tried a quick test, and both nxml-mode and trang objected to such a
schema.

> In the general case, however, we think that all datatype definitions
> should be complete and appropriate. In practice, we think the vast
> majority of TEI attributes are already catered for by a very small
> number of datatypes. (of the 500+ attributes listed by Syd, about
> 400 are covered by derivations of tei.data.token, tei.data.pointer
> and tei.data.uboolean)

I'm not exactly sure what you mean by "derivations" here, but if it's
the adding restrictions to a generic datatype that we can't do, it
means we have a problem for lots of those attributes, no?

> We conclude that
> 
> - datatypes should be expressed as <rng:data> expressions

I'm not sure I see why we want to impose such a restriction. E.g., for
the TEI sex datatype, why would we prefer

     <rng:data>
       <rng:param name="pattern">^\s*(f|m|u|x)\s*$</rng:param>
     </rng:data>

to either

    <rng:choice>
      <rng:value>f</rng:value>
      <rng:value>m</rng:value>
      <rng:value>u</rng:value>
      <rng:value>x</rng:value>
    </rng:choice>

or far better

    <valList type="closed">
      <val>f</val> <desc>female</desc>
      <val>m</val> <desc>male</desc>
      <val>u</val> <desc>unknown or undetermined</desc>
      <val>x</val> <desc>not applicable or indeterminable</desc>
    </valList>

> - for commonly occurring cases (see below) we should define a small 
>   number of macros, which will be named in the way Syd proposes for
>   datatypes

I think I may be confused: for commonly occurring cases of what? In the
previous bullet point did "datatype" mean "the declaration of the
allowed values of a particular attribute" or "an abstract constraint
which can be applied to the allowed values of any given attribute"?

> - it should be possible to map all datatypes to W3C basic datatypes, 
>   possibly with additional constraints

If I understand this correctly, I don't think there's any immediate
problem with it. (I'm presuming that anything that is expressed as a
list of values is something that can be mapped ) I think it is
probably fine as a goal for the current short-term project.

However, as a long-term principle I think it is a very bad idea to tie
TEI to W3C datatypes. While I am far from a computer scientist who has
studied these issues, it's clear that W3C datatypes leave a lot to be
desired. It is quite reasonable to expect that other datatype
libraries will be published (e.g., OASIS DSDL part 5), or that we
would want to create a datatype library ourselves, perhaps using DTLL
if & when it becomes fully worked out.

> The TEI has always proposed additional constraints in remarks,
> valDesc, and descriptive prose. We think we should use the
> Schematron language to express some of these: the primary use case
> being constraints on acceptable GIs as targets for various pointing
> attributes.
> 
> We are not sure where these constraints go in ODD-world, but
> probably not in the <datatype>. We recommend using Schematron for
> them because (a) we know it does the job (b) it is a candidate ISO
> recommendation.

I agree with all of the above. Although I think perhaps we should
avoid features of ISO Schematron that are not available in Schematron
1.x, as processors for the former are hard to come by. (That may
change by the time this becomes an issue, of course.)

> I think anything we can do to reduce the complications consequent on
> the whitespace rules of XML is an unalloyed Good Thing, and propose
> to be even more draconian than Syd suggests.

Hear hear!

> My suggestion is that we allow only token, nmtoken, and
> tei.data.token.

I'm not sure *where* this restriction occurs, since in the next
paragraph you propose we keep "tei.data.tokens".

- token: do you mean "rng:token" or "xsd:token"?

- xsd:NMTOKEN: interesting; where would you want to use it? I have
               found no good use for this datatype for any of the 541
               attributes I looked at. In every case that NMTOKEN is
               currently used, I think we should be using xsd:Name (or
               perhaps xsd:NCName), except for the 1 oddball case of
               unit= on <timeline>, which should be an enumerated list
               or folded into interval=.

> While sympathising with the motivation for it, I feel that the
> distinction Syd proposes between "tei.data.string" and
> "tei.data.tokens" will only confuse people. If the value of a
> sequence of tokens is to be interpreted as a single string, then it
> probably shouldn't be an attribute at all.

Really good point. As I said, I'm very back-and-forth on this issue,
and Lou's argument tips me back. The only attribute that I can think
of that does not fit the "tei.data.tokens" semantic and should remain
an attribute is the value= of <metSym>. And since it's a single
attribute, IMHO it doesn't have to be declared as a "datatype" (i.e.,
with indirection), and even if Council thinks it does, we could just
use tei.data.tokens and live with it. (Remember, the validation would
be exactly the same, it's only that the prose explanation might not
fit perfectly well. Does anyone use this attribute, anyway?)

> These I like:
> tei.data.token, tei.data.tokens, tei.data.pointer, tei.data.pointers

Me too.

> Constraining tei.data.token/s further as NMTOKEN/S/NCName/QNAME etc. is 
> possible, but I am not sure how many elements would benefit from it

Between half a dozen and a dozen attributes, I suspect. Most, if not
all, of which should be xsd:Name. 

> Names I would prefer:
> for tei.data.uboolean -> tei.data.truthValue

I *like* it. Unless there are rousing objections, I'll plan to change
this in EDW90 and the corresponding database later this week.

> Names I'm not sure about
> tei.data.temporalExpression: how does this map to ISO 8601?
> (I assume it doesn't include dateRanges, for example)

Hey, you thought of this name! See separate thread James started for
ISO 8601 alignment discussion.

> tei.data.duration
>   We should adopt a consistent policy as to whether quantities like this 
> include their units, or whether the units are supplied as a separate 
> attribute. I think I prefer the second option, as being more
> flexible.

If we're going to use W3C datatypes, then at least in those cases
where W3C puts the unit in with the quantity (xsd:duration explicitly,
and the various date and time formats implicitly) we'd have to do the
same. 

> tei.data.probability
>   Not convinced we need this. There are very few candidates in the
> EDW90 table (I find 1, to be exact!)

My fault, table had typos. This one is for expressing a range from 0
to 1 (or 0% to 100% or none to all). Currently only 3 attributes make
use of it (scope= of <handNote>, usage= of <language>, weights= of
<alt>). Since (IIRC) Council agreed in Paris that whenever 2 or more
attributes share the same constraint, a datatype should be abstracted
out, I did so. (There was even some discussion that there should be a
datatype even if only 1 attribute has a particular constraint, IIRC.)

> tei.data.numeric
>   I'm now coming round to the view that we also need a
>   tei.data.integer

I'm wondering if the concept of "positive integer or 0" is simple
enough that we don't need to bother creating a TEI datatype for it,
and could just use xsd:nonNegativeInteger directly when needed.

> tei.data.language
>   I agree that we need to document exactly what this means somewhere and 
> providing a TEI name for it is a good way of doing so.

JC> Just to make sure I'm understanding this...would that datatype
JC> then be used for validation of @xml:lang's format? It seems
JC> strange to me to be using a tei.datatype to validate and/or
JC> document use of a non-TEI element/attribute.

I agree with Lou. There are 3 reasons to make a datatype
(tei.data.language) that maps directly to xsd:language.

* It occurs more than twice (I'm not sure this is a compelling
  argument on its own): langKey= & otherLangs= of <textLang>, ident=
  of <language>, mainLang= of <hand>, and xml:lang= of everything.

* Although it maps directly to xsd:language, the explanation of
  xsd:language is both hard to find and hard to read & understand.
  (Quite unlike the explanation of xsd:nonNegativeInteger, which is
  easy to find, and not all that hard to read & understand -- besides,
  it's obvious enough that almost no one bothers.)

* As Christian pointed out, it would be nice to have someplace in the
  reference documentation to plunk the explanation of how xml:lang= is
  related to ident= of <language>.

I will post a reply on tei.data.code and tei.data.key issue separately.

From lou.burnard at computing-services.oxford.ac.uk  Wed Aug 31 17:56:40 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 31 Aug 2005 22:56:40 +0100
Subject: [tei-council] EDW90 proposals (1 of several)
In-Reply-To: <ygfslwqzzrt.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <42EBA1ED.7070603@computing-services.oxford.ac.uk>	<42EBE9A8.8080606@computing-services.oxford.ac.uk>	<17132.56655.667577.878408@emt.wwp.brown.edu>	<42ED35C0.6090304@computing-services.oxford.ac.uk>	<42EFF7FE.6030201@computing-services.oxford.ac.uk>	<42EFF815.8030005@computing-services.oxford.ac.uk>	<17172.34711.545137.680567@emt.wwp.brown.edu>
	<ygfslwqzzrt.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43162798.3020708@computing-services.oxford.ac.uk>

Christian Wittern wrote:

>
>
>Now thinking of this again, for what purpose would you need @type on
>teiHeader?
>  
>

It is used (by many) to distinguish a header attached to a teiCorpus 
from one attached to a text. And you might also need to use it to 
distinguish an "independent" header, now that we have removed the 
concept of auxiliary  tagset.  I agree both of these distinctions could 
be made by other means, but still...

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Aug 31 20:45:22 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 01 Sep 2005 09:45:22 +0900
Subject: [tei-council] Upcoming teleconference Friday 2005-09-09 at 1300
	UTC
In-Reply-To: <43156F1F.3050203@computing-services.oxford.ac.uk> (James
	Cummings's message of "Wed, 31 Aug 2005 09:49:35 +0100")
References: <ygf1x4azfom.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<43156F1F.3050203@computing-services.oxford.ac.uk>
Message-ID: <ygfpsrtwr8d.fsf@kanji.zinbun.kyoto-u.ac.jp>

James Cummings <James.Cummings at computing-services.oxford.ac.uk> writes:

> Christian Wittern wrote:
>> As Sebastian suggested, we would like to have a second communication
>> channel open via IRC Chat at the time of the conference.  James, are
>> you taking care of this?  Could you please post instructions on how to
>> get connected etc. 
>
> Since there is only one non-council member hanging around occasionally
> in the public TEI Consortium IRC channel, does anyone have any
> objections to using that?  (If so, we can create a #tei-council
> private channel.)

I'd prefer to have a dedicated channel for the council.  BTW (showing
my ignorance) is it possible to have a log of the conversation and
post it for example on the Council pages?

>
> Basically, in almost any IRC client, set the server to be irc.freenode.net
> and the channel to be #tei-c and you should be fine.  In some clients
> this is done through setting up an account in various graphical
> manners, in others you might use /connect serverName or /server
> serverName and then /join #tei-c 
> Alternatively, if you have the Chatzilla extension installed, in the
> address bar of firefox you can use this url:
> irc://irc.freenode.net/tei-c to connect.  

Last time I tried this, I realized that I forgot to ask how do
disconnect, so my alter ego was hanging around there until the whole
firefox went belly up...

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  Thu Sep  1 09:32:10 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 1 Sep 2005 09:32:10 -0400 (EDT)
Subject: [tei-council] comments on edw90
In-Reply-To: <ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <42F77735.1000204@oucs.ox.ac.uk>
	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<42FB1C7F.2050400@computing-services.oxford.ac.uk>
	<42FB20C6.3040306@computing-services.oxford.ac.uk>
	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <200509011332.j81DWAtv024950@ursa.services.brown.edu>

> tei.data.code and tei.data.key
> 
>    I have a different understanding of these.
> 
> Syd defines tei.data.code as a version of tei.data.pointer, with the
> extra constraint that the target must be in the present document. I
> am not sure what benefit there might be to adding this constraint.
> 
> More seriously, however, tei.data.key is defined as its complement,
> i.e. a tei.data.pointer with the constraint that its target must
> *not* be in the current document. I am even less clear what benefit
> there is in that, and find the naming rather confusing, since we are
> currently using "key=" attributes for things which are explicitly
> not pointers and which might even be in the same document (e.g. in
> TD)
> 
> I think we should stick to tei.data.pointer (by all means add
> tei.data.pointer.local, if need be) for the URI case, and keep
> tei.data.code (or key) for use when all we can say of the attribute
> is that its value is a magic token which might get you somewhere in
> some external system, e.g. a database key, but which cannot be
> validated. It might also be useful for cases where an association is
> made by co-reference, as with the ident/key pair in TD, or in
> whatever variety of HORSE we finally decide to back.

P4 provided (at least) 3 ways for an attribute to refer to a
controlled vocabulary:

* the value is from a list specified in the DTD (e.g., status= of
  <availability>)

* the value is an IDREF to something (which has an id=) specified in
  the document instance (e.g., who= of <sp> or resp= of <add>)

* the value is a key into some (ostensibly external, but Lou correctly
  points out that, especially in the P5 world, it may well be in the
  document instance) resource (e.g., key= of <name>)

I am not claiming that this is the only or best way to think of these;
but I do think these are useful distinctions. It is my (very
unscientific) observation that users crave the use of IDREF (or its
modern equivalent) as a mechanism for controlling vocabularies. Even
those I would think of as "power users" of TEI are sometimes very
hesitant to change the DTD, and very few want to go to the trouble of
building a database and creating software that actually uses a TEI key
to look things up in it. However, users often really want the
capability to control the values of a particular attribute, and
occasionally even want to say something about what the values mean.

There are problems porting this analysis to the P5 world, though. In
P5, the pointers that replace IDREFs can point anywhere. Even into the
schema, e.g. Furthermore, in P4 the value of key= was just a key. But
in the P5 world, it might make sense for the key= to indicate the
resource as well as the key. E.g., in P4 <name key="929041"> perhaps
could be <name key="http://my.server.org/name-database?929041"> or
some such.

Thus, in EDW90 I suggested three mechanisms for controlling vocabulary.
* tei.data.enumerated, the control is via a closed <valList> in the
  ODD which boils down to a token list in the schema
* tei.data.code (perhaps a bad name), a local pointer (although an
  argument could be made for making this a generic pointer or for
  making it an xsd:Name and using co-reference)
* tei.data.key, for database keys, could be declared as a URI or as an
  xsd:Name, and I don't claim to know which is better

Note that, if I understand correctly, the key= of <attRef>,
<moduleRef>, <specDesc>, and <memberOf> is currently defined as being
a name, and is tied to being one processing chain. I.e., using a URI
here would break things.

As I sit here and think about it, in my pre-breakfast hypoglycemic
state, I am beginning to lean towards leaving tei.data.key an
xsd:Name, and telling users who really want to specify the resource as
well as the key to use xml:base=. E.g. <name key="929041"
xml:base="http:/my.server.org/name-database">. Is that feasible? I
don't claim to have thought this through at all.

One final thought. As mentioned before, in the P5 world as currently
instantiated, a document can't say to which schema it is supposed to
conform. So suppose a project has 2 somewhat similar schemas that
serve different purposes lying around, each of which imposes a closed
value list on the bar= of <foo>, as follows:
   A        B
   ---      -------
   fee      fee
   fi       fi
   fo       fiddlie
   fum      aye
            oh
Now suppose you, the encoder, start working on an instance. Unless
said instance is already valid against A and invalid against B, you
have no way of knowing that "fum" is a legal value but "aye" is not.
Thus I think (or am I worried?) that a validatable method of
constraining values from within the instance will be even more popular
in P5 than in P4. I.e., it would be useful to have
  <definition-of-foo-values>
    <valList>
      <valItem ident="fee">
        <gloss>The file entropy evaluation as reported by blort</gloss>
      </valItem>
      <valItem ident="fi">
        <gloss>The file input, should contain only ASCII characters</gloss>
      </valItem>
      </valItem ident="fo">
   ...
or some such somewhere in the TEI Header.

From jawalsh at indiana.edu  Thu Sep  1 09:49:23 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Thu, 1 Sep 2005 08:49:23 -0500
Subject: [tei-council] Conference Call Details
Message-ID: <D0C17509-A7CB-43F1-B88A-D3FD16329396@indiana.edu>

Hi all,

Please see below for conference call details.  I will be traveling  
during the call and may not be able to call in, though I will do my  
best to attend.  I have been assured by the telecomm folks here at  
Indiana that the call will proceed fine whether or not I, as the  
conference organizer, dial in.

John

You have been invited to participate in a Conference Call on 9/9/2005  
from 7:45:00 AM to 10:15:00 AM Indiana EST. (jawalsh: The actual  
conference time is 1300 - 1500 UTC, but I've reserved the line for 15  
extra minutes before and after).

The Conference Access Information is listed below:

Conf Id:        2174
Date:        9/9/2005
Begin Time:    7:45:00 AM Indiana EST
End Time:    10:15:00 AM Indiana EST

Phone Number:    (812) 856-3600
PIN:        000920#

This email was automatically generated by the  IU UITS Conference  
system. Please do not reply to this message.

For conferencing assistance please call 812-855-4848.

| John A. Walsh, Associate Director for Projects and Services
| Digital Library Program / Indiana University Libraries
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 Fax:812-856-2062 <mailto:jawalsh at indiana.edu>

From lou.burnard at computing-services.oxford.ac.uk  Thu Sep  1 15:35:22 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 01 Sep 2005 20:35:22 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <200509011332.j81DWAtv024950@ursa.services.brown.edu>
References: <42F77735.1000204@oucs.ox.ac.uk>	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>	<42FB1C7F.2050400@computing-services.oxford.ac.uk>	<42FB20C6.3040306@computing-services.oxford.ac.uk>	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<200509011332.j81DWAtv024950@ursa.services.brown.edu>
Message-ID: <431757FA.3010605@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>>tei.data.code and tei.data.key
>>
>>   I have a different understanding of these.
>>
>>Syd defines tei.data.code as a version of tei.data.pointer, with the
>>extra constraint that the target must be in the present document. I
>>am not sure what benefit there might be to adding this constraint.
>>
>>More seriously, however, tei.data.key is defined as its complement,
>>i.e. a tei.data.pointer with the constraint that its target must
>>*not* be in the current document. I am even less clear what benefit
>>there is in that, and find the naming rather confusing, since we are
>>currently using "key=" attributes for things which are explicitly
>>not pointers and which might even be in the same document (e.g. in
>>TD)
>>
>>I think we should stick to tei.data.pointer (by all means add
>>tei.data.pointer.local, if need be) for the URI case, and keep
>>tei.data.code (or key) for use when all we can say of the attribute
>>is that its value is a magic token which might get you somewhere in
>>some external system, e.g. a database key, but which cannot be
>>validated. It might also be useful for cases where an association is
>>made by co-reference, as with the ident/key pair in TD, or in
>>whatever variety of HORSE we finally decide to back.
>>    
>>
>
>P4 provided (at least) 3 ways for an attribute to refer to a
>controlled vocabulary:
>
>* the value is from a list specified in the DTD (e.g., status= of
>  <availability>)
>
>* the value is an IDREF to something (which has an id=) specified in
>  the document instance (e.g., who= of <sp> or resp= of <add>)
>
>* the value is a key into some (ostensibly external, but Lou correctly
>  points out that, especially in the P5 world, it may well be in the
>  document instance) resource (e.g., key= of <name>)
>
>I am not claiming that this is the only or best way to think of these;
>but I do think these are useful distinctions. 
>

I agree.  What are the datatypes which, in P5, should correspond with 
each of these three cases?

>It is my (very
>unscientific) observation that users crave the use of IDREF (or its
>modern equivalent) as a mechanism for controlling vocabularies. Even
>those I would think of as "power users" of TEI are sometimes very
>hesitant to change the DTD, and very few want to go to the trouble of
>building a database and creating software that actually uses a TEI key
>to look things up in it. However, users often really want the
>capability to control the values of a particular attribute, and
>occasionally even want to say something about what the values mean.
>
>There are problems porting this analysis to the P5 world, though. In
>P5, the pointers that replace IDREFs can point anywhere. Even into the
>schema, e.g. Furthermore, in P4 the value of key= was just a key. But
>in the P5 world, it might make sense for the key= to indicate the
>resource as well as the key. E.g., in P4 <name key="929041"> perhaps
>could be <name key="http://my.server.org/name-database?929041"> or
>some such.
>  
>

That depends on what the datatype for "key" is. If it is a URIref, yes. 
If it is just a  xsd:name, then you can't do that without modifying the 
ODD (which of course is no big deal)

>Thus, in EDW90 I suggested three mechanisms for controlling vocabulary.
>* tei.data.enumerated, the control is via a closed <valList> in the
>  ODD which boils down to a token list in the schema
>* tei.data.code (perhaps a bad name), a local pointer (although an
>  argument could be made for making this a generic pointer or for
>  making it an xsd:Name and using co-reference)
>* tei.data.key, for database keys, could be declared as a URI or as an
>  xsd:Name, and I don't claim to know which is better
>  
>

I think we should use a pointer for the second class (URIref) and 
xsd:name for the last.

>Note that, if I understand correctly, the key= of <attRef>,
><moduleRef>, <specDesc>, and <memberOf> is currently defined as being
>a name, and is tied to being one processing chain. I.e., using a URI
>here would break things.
>  
>

Also elsewhere, probably.

>As I sit here and think about it, in my pre-breakfast hypoglycemic
>state, I am beginning to lean towards leaving tei.data.key an
>xsd:Name, and telling users who really want to specify the resource as
>well as the key to use xml:base=. E.g. <name key="929041"
>xml:base="http:/my.server.org/name-database">. Is that feasible? I
>don't claim to have thought this through at all.
>
>  
>
See comment above. I dont think we should add special purpose rules of 
this kind.

>One final thought. As mentioned before, in the P5 world as currently
>instantiated, a document can't say to which schema it is supposed to
>conform. So suppose a project has 2 somewhat similar schemas that
>serve different purposes lying around, each of which imposes a closed
>value list on the bar= of <foo>, as follows:
>   A        B
>   ---      -------
>   fee      fee
>   fi       fi
>   fo       fiddlie
>   fum      aye
>            oh
>Now suppose you, the encoder, start working on an instance. Unless
>said instance is already valid against A and invalid against B, you
>have no way of knowing that "fum" is a legal value but "aye" is not.
>Thus I think (or am I worried?) that a validatable method of
>constraining values from within the instance will be even more popular
>in P5 than in P4. I.e., it would be useful to have
>  <definition-of-foo-values>
>    <valList>
>      <valItem ident="fee">
>        <gloss>The file entropy evaluation as reported by blort</gloss>
>      </valItem>
>      <valItem ident="fi">
>        <gloss>The file input, should contain only ASCII characters</gloss>
>      </valItem>
>      </valItem ident="fo">
>   ...
>or some such somewhere in the TEI Header.
>
>  
>

I dont pretend to understand what you're getting at here,. but in any 
case it seems a bit beyond our current remit.

>_______________________________________________
>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  Thu Sep  1 16:07:01 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 01 Sep 2005 21:07:01 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <200508312049.j7VKnBia028939@cepheus.services.brown.edu>
References: <42F77735.1000204@oucs.ox.ac.uk>	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>	<42FB1C7F.2050400@computing-services.oxford.ac.uk>	<42FB20C6.3040306@computing-services.oxford.ac.uk>	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<200508312049.j7VKnBia028939@cepheus.services.brown.edu>
Message-ID: <43175F65.6010103@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>>Sebastian and I have done some testing of the feasibility of doing
>>local over-rides as described here. Our conclusions are that this
>>is not possible on technical grounds,
>>    
>>
>
>This is quite a shame, as such a capability could provide the means
>for significant simplification of the TEI scheme, and much of the work
>put into ED W 90 was predicated on this possibility. Such is life.
>
>
>  
>

Yes, I agree it's a nuisance. The problem is in the way that ODDs are 
"flattened" during the schema generation phase. Sebastianb and I have 
discussed it at length several times, and I have understood it at least 
once. Dont forget of course that the inability to do a local override 
*only* applies to generation of P5 canonical sources -- a user of the 
system is still at liberty eg to replace an unconstrained list  with a 
constrained one in their application-specific odd.

>>Our recommendation is that
>>- the tei.typed class should be removed
>>- elements bearing a type attribute (and former members of the
>>  typed class) should be checked to see whether their valLists
>>  constitute an open or closed list
>>- for closed list, the datatype will be an alternation of the
>>  possible values
>>    
>>
>
>I presume you mean "set of permissible values" or some such, not
>"datatype". (Up until now we've been using the term "datatype" to
>express an abstract grouping of values with similar syntactic
>constraints and similar semantics, presumably implemented by some form
>of indirection. However, there is the potential for lots of confusion,
>because the child of <attDef> which is used to abstractly declare the
>attribute type is called <datatype>. This is quite unfortunate a
>situation, for which I must take the blame -- Sebastian specifically
>asked me if any of the names he chose for these elements were
>problematic before he cemented them into our processing chain, and I
>missed this obvious thorn.)
>
>  
>
Yes, sorry, I was using the term loosely to mean "what it says is legal 
for this attribute in the DTD/schema"

>>- for open (or semi) lists, the datatype will be tei.enumerated,
>>  i.e. a single token not containing whitespace
>>    
>>
>
>I'm confused. What then is the difference between tei.data.enumerated
>and tei.data.token?
>  
>

No difference for one sense of "datatype", some difference for the 
other! The suggestion is to use tei.data.enumerated for cases where 
there is a <valList>, open or closed. But I am happy to go with 
tei.data.token for open/semi lists as well if this is felt to be clearer.

>In some ways this may feel like a big step backwards, as it is
>essentially the system we were using before Paris. But I think this
>works almost as well as the system Council sketched out in Paris. If
>a TEI-schema-designer wants to restrict users to the values provided
>in an open (or semi) list, all she needs to do is change the type of
><valList> from "open" to "closed". (Hmmm... I just realized that this
>is actually currently not true. I think she'd have to copy-and-paste
>the entire <valList> from the tagdoc into her ODD, which isn't nearly
>as nice. Sebastian, could we arrange the process so that just
>specifying, e.g.
>          <elementSpec module="core" ident="note" mode="change">
>            <attList>
>              <attDef ident="place">
>                <valList type="closed"/>
>              </attDef>
>            </attList>
>          </elementSpec>
>would work? It's not ambiguous that the user is trying to remove all
>the possible values, because it makes no sense to have an empty
><valList>, especially if the type is "closed"; of course it also
>isn't valid ala the current TD.)
>  
>

I would like to hear Sebastian's view on this -- he's back at work next 
week -- but I suspect he will say that this looks like rather recondite 
special-casing. After all, chances are that if you want to close the set 
of values you'll probably want to modify the TEI suggestions anyway.

>
>  
>
>>1.2 Over-riding of attributes
>>
>>I think we can actually make explicit some of what Syd is
>>describing here by using the RelaxNG method of defining facets. So
>>we could for example say that a datatype was basically a positive
>>integer, but with the added constraint that it has a value less
>>than 43 by a construct such as
>>    <datatype>
>>      <rng:data type="nonNegativeInteger">
>>        <rng:param name="maxInclusive">42</rng:param>
>>      </rng:data>
>>    </datatype>
>>    
>>
>
>Yes, I think this is doable, but it really only addresses a small
>subset of what I think we set forth in Paris to do. (And note that
>quite a few of the proposed datatypes make use of this.)
>

Could we see a list of these?

> In
>particular, since the restriction is a facet, we can't use this
>feature to have one TEI datatype for numeric representations
>(tei.data.numeric), and say "this attribute is one of
>tei.data.numeric, but must be a non-negative integer".
>
>
>  
>

>>If (and only if) there is a 1:1 mapping between a TEI datatype and
>>[a W3C Schema] datatype we could presumably also do
>>    
>>
>>   <datatype>
>>     <rng:data>
>>       <rng:ref name="tei.nonNegativeInteger">
>>       <rng:param name="maxInclusive">42</rng:param>
>>     </rng:data>
>>   </datatype>
>>    
>>
>
>I tried a quick test, and both nxml-mode and trang objected to such a
>schema.
>
>
>  
>
>>In the general case, however, we think that all datatype definitions
>>should be complete and appropriate. In practice, we think the vast
>>majority of TEI attributes are already catered for by a very small
>>number of datatypes. (of the 500+ attributes listed by Syd, about
>>400 are covered by derivations of tei.data.token, tei.data.pointer
>>and tei.data.uboolean)
>>    
>>
>
>I'm not exactly sure what you mean by "derivations" here, but if it's
>the adding restrictions to a generic datatype that we can't do, it
>means we have a problem for lots of those attributes, no?
>
>
>  
>

Again, I think we need to look at cases here. Suppose we started by just 
using the simplest (most generic) datatypes wherever possible, how many 
attributes would be seriously discommoded?

>>We conclude that
>>
>>- datatypes should be expressed as <rng:data> expressions
>>    
>>
>
>I'm not sure I see why we want to impose such a restriction. E.g., for
>the TEI sex datatype, why would we prefer
>
>     <rng:data>
>       <rng:param name="pattern">^\s*(f|m|u|x)\s*$</rng:param>
>     </rng:data>
>
>to either
>
>    <rng:choice>
>      <rng:value>f</rng:value>
>      <rng:value>m</rng:value>
>      <rng:value>u</rng:value>
>      <rng:value>x</rng:value>
>    </rng:choice>
>
>or far better
>
>    <valList type="closed">
>      <val>f</val> <desc>female</desc>
>      <val>m</val> <desc>male</desc>
>      <val>u</val> <desc>unknown or undetermined</desc>
>      <val>x</val> <desc>not applicable or indeterminable</desc>
>    </valList>
>
>
>  
>

I dont quite see what you're getting at here. We need to decide whether 
sex is an enumeration of possible values (possibly allowing people to 
use their own values), or a hardwired datatype like date values. My 
vote, fwiw, is for the former, but I'm open to discussion.

>>- for commonly occurring cases (see below) we should define a small 
>>  number of macros, which will be named in the way Syd proposes for
>>  datatypes
>>    
>>
>
>I think I may be confused: for commonly occurring cases of what? In the
>previous bullet point did "datatype" mean "the declaration of the
>allowed values of a particular attribute" or "an abstract constraint
>which can be applied to the allowed values of any given attribute"?
>
>
>  
>

That's OK, I am not sure that I remember which I meant myself. I was 
probably hankering after comprehensible names for certain frequently 
ocuring ranges of v alues.

>>- it should be possible to map all datatypes to W3C basic datatypes, 
>>  possibly with additional constraints
>>    
>>
>
>If I understand this correctly, I don't think there's any immediate
>problem with it. (I'm presuming that anything that is expressed as a
>list of values is something that can be mapped ) I think it is
>probably fine as a goal for the current short-term project.
>
>However, as a long-term principle I think it is a very bad idea to tie
>TEI to W3C datatypes. While I am far from a computer scientist who has
>studied these issues, it's clear that W3C datatypes leave a lot to be
>desired. It is quite reasonable to expect that other datatype
>libraries will be published (e.g., OASIS DSDL part 5), or that we
>would want to create a datatype library ourselves, perhaps using DTLL
>if & when it becomes fully worked out.
>  
>

This is simply reiterating a decision we took at the Council meeting in 
Oxford, if I remember aright.

>
>  
>
>>The TEI has always proposed additional constraints in remarks,
>>valDesc, and descriptive prose. We think we should use the
>>Schematron language to express some of these: the primary use case
>>being constraints on acceptable GIs as targets for various pointing
>>attributes.
>>
>>We are not sure where these constraints go in ODD-world, but
>>probably not in the <datatype>. We recommend using Schematron for
>>them because (a) we know it does the job (b) it is a candidate ISO
>>recommendation.
>>    
>>
>
>I agree with all of the above. Although I think perhaps we should
>avoid features of ISO Schematron that are not available in Schematron
>1.x, as processors for the former are hard to come by. (That may
>change by the time this becomes an issue, of course.)
>
>
>  
>
>>I think anything we can do to reduce the complications consequent on
>>the whitespace rules of XML is an unalloyed Good Thing, and propose
>>to be even more draconian than Syd suggests.
>>    
>>
>
>Hear hear!
>
>
>  
>
>>My suggestion is that we allow only token, nmtoken, and
>>tei.data.token.
>>    
>>
>
>I'm not sure *where* this restriction occurs, since in the next
>paragraph you propose we keep "tei.data.tokens".
>  
>
I mean to include the plural forms, sorry for the carelessness.

>- token: do you mean "rng:token" or "xsd:token"?
>  
>

No idea. Please spell out the difference, and express your preference if 
any.

>- xsd:NMTOKEN: interesting; where would you want to use it? I have
>               found no good use for this datatype for any of the 541
>               attributes I looked at. In every case that NMTOKEN is
>               currently used, I think we should be using xsd:Name (or
>               perhaps xsd:NCName), except for the 1 oddball case of
>               unit= on <timeline>, which should be an enumerated list
>               or folded into interval=.
>
>  
>

I'm happy to stick with NCName

>  
>
>>While sympathising with the motivation for it, I feel that the
>>distinction Syd proposes between "tei.data.string" and
>>"tei.data.tokens" will only confuse people. If the value of a
>>sequence of tokens is to be interpreted as a single string, then it
>>probably shouldn't be an attribute at all.
>>    
>>
>
>Really good point. As I said, I'm very back-and-forth on this issue,
>and Lou's argument tips me back. The only attribute that I can think
>of that does not fit the "tei.data.tokens" semantic and should remain
>an attribute is the value= of <metSym>. And since it's a single
>attribute, IMHO it doesn't have to be declared as a "datatype" (i.e.,
>with indirection), and even if Council thinks it does, we could just
>use tei.data.tokens and live with it. (Remember, the validation would
>be exactly the same, it's only that the prose explanation might not
>fit perfectly well. Does anyone use this attribute, anyway?)
>
>
>  
>
I think it should be tei.data.token -- it can't have white space. It 
should be a single character in fact for any sensible kind of notation.

>>These I like:
>>tei.data.token, tei.data.tokens, tei.data.pointer, tei.data.pointers
>>    
>>
>
>Me too.
>
>
>  
>
>>Constraining tei.data.token/s further as NMTOKEN/S/NCName/QNAME etc. is 
>>possible, but I am not sure how many elements would benefit from it
>>    
>>
>
>Between half a dozen and a dozen attributes, I suspect. Most, if not
>all, of which should be xsd:Name. 
>
>  
>
Then let's go with that.

>  
>
>>Names I would prefer:
>>for tei.data.uboolean -> tei.data.truthValue
>>    
>>
>
>I *like* it. Unless there are rousing objections, I'll plan to change
>this in EDW90 and the corresponding database later this week.
>
>
>  
>
Done?

>>Names I'm not sure about
>>tei.data.temporalExpression: how does this map to ISO 8601?
>>(I assume it doesn't include dateRanges, for example)
>>    
>>
>
>Hey, you thought of this name! See separate thread James started for
>ISO 8601 alignment discussion.
>
>
>  
>

It's not so much the name that worries me as the significance! We need 
some straw person proposals in view of the points James raises.

>>tei.data.duration
>>  We should adopt a consistent policy as to whether quantities like this 
>>include their units, or whether the units are supplied as a separate 
>>attribute. I think I prefer the second option, as being more
>>flexible.
>>    
>>
>
>If we're going to use W3C datatypes, then at least in those cases
>where W3C puts the unit in with the quantity (xsd:duration explicitly,
>and the various date and time formats implicitly) we'd have to do the
>same. 
>
>
>  
>

Yes., but only if we chose to. We could say we will NEVER have 
attributes which combine in their value quantity+unit, or we could say 
we have some which do and some which dont, or we could say all 
quantities have the potential to include units. Again, a list of 
specific cases might help sharpen discussion and reach a decision.

>>tei.data.probability
>>  Not convinced we need this. There are very few candidates in the
>>EDW90 table (I find 1, to be exact!)
>>    
>>
>
>My fault, table had typos. This one is for expressing a range from 0
>to 1 (or 0% to 100% or none to all). Currently only 3 attributes make
>use of it (scope= of <handNote>, usage= of <language>, weights= of
><alt>). Since (IIRC) Council agreed in Paris that whenever 2 or more
>attributes share the same constraint, a datatype should be abstracted
>out, I did so. (There was even some discussion that there should be a
>datatype even if only 1 attribute has a particular constraint, IIRC.)
>
>
>  
>
Well 3 is almost enough to warrant having it.  Presumably if we define 
it as a macro, the user who only wants ever to express probability by 
means of a percentage can say so by redefining the macro.

>>tei.data.numeric
>>  I'm now coming round to the view that we also need a
>>  tei.data.integer
>>    
>>
>
>I'm wondering if the concept of "positive integer or 0" is simple
>enough that we don't need to bother creating a TEI datatype for it,
>and could just use xsd:nonNegativeInteger directly when needed.
>
>
>  
>

Fine by me.

>>tei.data.language
>>  I agree that we need to document exactly what this means somewhere and 
>>providing a TEI name for it is a good way of doing so.
>>    
>>
>
>JC> Just to make sure I'm understanding this...would that datatype
>JC> then be used for validation of @xml:lang's format? It seems
>JC> strange to me to be using a tei.datatype to validate and/or
>JC> document use of a non-TEI element/attribute.
>
>I agree with Lou. There are 3 reasons to make a datatype
>(tei.data.language) that maps directly to xsd:language.
>
>* It occurs more than twice (I'm not sure this is a compelling
>  argument on its own): langKey= & otherLangs= of <textLang>, ident=
>  of <language>, mainLang= of <hand>, and xml:lang= of everything.
>
>* Although it maps directly to xsd:language, the explanation of
>  xsd:language is both hard to find and hard to read & understand.
>  (Quite unlike the explanation of xsd:nonNegativeInteger, which is
>  easy to find, and not all that hard to read & understand -- besides,
>  it's obvious enough that almost no one bothers.)
>
>* As Christian pointed out, it would be nice to have someplace in the
>  reference documentation to plunk the explanation of how xml:lang= is
>  related to ident= of <language>.
>
>
>I will post a reply on tei.data.code and tei.data.key issue separately.
>
>_______________________________________________
>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  Thu Sep  1 20:30:33 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 1 Sep 2005 20:30:33 -0400
Subject: [tei-council] comments on edw90
In-Reply-To: <431757FA.3010605@computing-services.oxford.ac.uk>
References: <42F77735.1000204@oucs.ox.ac.uk>
	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<42FB1C7F.2050400@computing-services.oxford.ac.uk>
	<42FB20C6.3040306@computing-services.oxford.ac.uk>
	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<200509011332.j81DWAtv024950@ursa.services.brown.edu>
	<431757FA.3010605@computing-services.oxford.ac.uk>
Message-ID: <17175.40233.135852.836925@emt.wwp.brown.edu>

> >* the value is from a list specified in the DTD (e.g., status= of
> >  <availability>)
> >
> >* the value is an IDREF to something (which has an id=) specified in
> >  the document instance (e.g., who= of <sp> or resp= of <add>)
> >
> >* the value is a key into some (ostensibly external, but Lou correctly
> >  points out that, especially in the P5 world, it may well be in the
> >  document instance) resource (e.g., key= of <name>)
> > ...
> I agree. What are the datatypes which, in P5, should correspond
> with each of these three cases?

* tei.data.enumerated
* tei.data.code
* tei.data.key

> That depends on what the datatype for "key" is. If it is a URIref,
> yes. If it is just a xsd:name, then you can't do that without
> modifying the ODD (which of course is no big deal)

Yes, that is the question we are currently discussing ... what should
the datatype of tei.data.key be, a URI or a name? Personally, I'm
inclined to stick with name. (I.e., that tei.data.key boil down to
xsd:Name.)

> I think we should use a pointer for the second class
> [tei.data.code] and xsd:name for the last [tei.data.key].

OK. On the proposal to constrain the pointer in tei.data.code to be a
local pointer, do you think it is
a. a bad idea
b. a good idea
c. you're indifferent
d. a bad idea for TEI to enforce it, but the Guidelines should mention
   that a project may wish to add this restriction locally, and
   perhaps even describe how
e. the TEI should enforce it, and the Guidelines should mention that
   a project may which to remove this constraint, and perhaps even
   describe how
f. the Princeton Band

Personally, I am leaning towards (b) or (d). The problem with
permitting a tei.data.code attribute to point outside the current
document is that it opens a bit of a can of worms as to what it
points at. E.g., if new= of <handShift> is supposed to point to a
<hand> inside a //TEI/teiHeader/profileDesc/handList, great. But if
you're putting that <hand> in an external document, what goes inside
the <text> of that external document?

> >Note that, if I understand correctly, the key= of <attRef>,
> ><moduleRef>, <specDesc>, and <memberOf> is currently defined as
> >being a name, and is tied to being one processing chain. I.e.,
> >using a URI here would break things.
> 
> Also elsewhere, probably.

I didn't notice any others, but I didn't look that carefully. Either
way, the point is that if we change tei.data.key into a URI, we need
to separate these attributes out into yet a different datatype.

> See comment above. I dont think we should add special purpose rules
> of this kind.

Which comment above? Doesn't matter. I think I was on drugs when I
suggested it. It's a hack, and as such the TEI should not be
recommending it. Suggestion withdrawn.

> I dont pretend to understand what you're getting at here,. but in
> any case it seems a bit beyond our current remit.

Just that we should not kiss off the concept of tei.data.code, i.e.
of allowing a user to constrain an attribute's value[1], and perhaps
provide some semantics, by making it refer to something in the
current instance (or potentially elsewhere). It's an important idea.

Note
----
[1] And yes, the constraint is *not* enforced by your schema
    validation process, but rather some separate link-checking
    process.

From Syd_Bauman at Brown.edu  Thu Sep  1 23:57:46 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 1 Sep 2005 23:57:46 -0400 (EDT)
Subject: [tei-council] comments on edw90
In-Reply-To: <43175F65.6010103@computing-services.oxford.ac.uk>
References: <42F77735.1000204@oucs.ox.ac.uk>
	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<42FB1C7F.2050400@computing-services.oxford.ac.uk>
	<42FB20C6.3040306@computing-services.oxford.ac.uk>
	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<200508312049.j7VKnBia028939@cepheus.services.brown.edu>
	<43175F65.6010103@computing-services.oxford.ac.uk>
Message-ID: <200509020357.j823vkia003843@cepheus.services.brown.edu>

> >I'm confused. What then is the difference between tei.data.enumerated
> >and tei.data.token?
> No difference for one sense of "datatype", some difference for the
> other! The suggestion is to use tei.data.enumerated for cases where
> there is a <valList>, open or closed. But I am happy to go with
> tei.data.token for open/semi lists as well if this is felt to be
> clearer.

The idea from Paris was that a <valList>, whether closed, open, or
semi, is required for an attribute of type tei.data.token. I still
think that's fine.

> I would like to hear Sebastian's view on this -- he's back at work
> next week -- but I suspect he will say that this looks like rather
> recondite special-casing. After all, chances are that if you want to
> close the set of values you'll probably want to modify the TEI
> suggestions anyway.

While the former may be the case, I really hope we do a good enough
job of choosing values that at least for some attributes users would
be very happy just closing the list.

> Could we see a list of these?

Yes, in EDW90. The following all take advantage of W3C Schema facets
via RelaxNG parameters.
  tei.data.token
  tei.data.temporalExpression
  tei.data.duration
  tei.data.probability
  tei.data.numeric

> Again, I think we need to look at cases here. Suppose we started by
> just using the simplest (most generic) datatypes wherever possible,
> how many attributes would be seriously discommoded?

I've already looked at the cases. All of them. I've made suggestions
based on looking at them. Given that those suggestions were based on
the erroneous presumption that we could have code that would tighten
or loosen constraints of a datatype for a given attribute, quite a few
of them will need to be re-worked.

> I dont quite see what you're getting at here. We need to decide
> whether sex is an enumeration of possible values (possibly allowing
> people to use their own values), or a hardwired datatype like date
> values. My vote, fwiw, is for the former, but I'm open to
> discussion.

Now you've *really* lost me.

* Can people not change a datatype? (After all, it's just implemented
  as a macro.) If not, why not?

* If they can't change a datatype, what difference does it make
  whether the datatype is declared in terms of an <rng:data> or an
  <rng:choice> or a <tei:valList>?

* Why couldn't a hardwired datatype be an enumeration of possible
  values?

I think these two issues (whether an attribute type is abstracted to a
datatype or not, and whether it is expressed as an enumeration type,
some constraint on a string type, some W3C type, or some constrained
W3C type, etc.) are orthogonal.

> This is simply reiterating a decision we took at the Council meeting
> in Oxford, if I remember aright.

If you say so ... but which was the antecedent of "This"?

> >- token: do you mean "rng:token" or "xsd:token"?

> No idea. Please spell out the difference, and express your
> preference if any.

Difference is spelled out in EDW90. Basically xsd:token has one
additional (powerful) feature and one (minor) drawback over rng:token.
The additional feature is that further constraints can be applied via
facets. The drawback is that you must use a RelaxNG processor that
knows about W3C Schema datatypes. But since to process most the rest
of a TEI document, your RelaxNG processor is going to have to know
about W3C Schema datatypes anyway, I have a strong preference for
xsd:token. 

> I'm happy to stick with NCName

OK. If anyone has reason to prefer xsd:Name or xsd:NMTOKEN over
xsd:NCName for those attributes that used to be NMTOKEN (except for
unit= of <timeline>), speak now or forever hold your peace. (Well, at
least keep quiet about it for a few months.)

> I think it should be tei.data.token -- it can't have white space. It
> should be a single character in fact for any sensible kind of
> notation.

My first reaction was that this was unduly harsh, after all, it could
contain white-space in P4. But then I thought about it for a few
moments, and decided that any metrical notation that included
white-space could easily be re-worked without it. As above, if anyone
objects to tei.data.token (i.e., no white-space) for value= of
<metSym> (which was called <symbol> in P4), speak now.

> >Between half a dozen and a dozen attributes, I suspect. Most, if
> >not all, of which should be xsd:Name.
> Then let's go with that.

Errr ... didn't we just decide on xsd:NCName a few paragraphs above?

> >If we're going to use W3C datatypes, then at least in those cases
> >where W3C puts the unit in with the quantity (xsd:duration
> >explicitly, and the various date and time formats implicitly) we'd
> >have to do the same.

> Yes., but only if we chose to. We could say we will NEVER have
> attributes which combine in their value quantity+unit, or we could
> say we have some which do and some which dont, or we could say all
> quantities have the potential to include units. Again, a list of
> specific cases might help sharpen discussion and reach a decision.

Right, but my point was that the choice is inextricably linked to the
use of xsd:duration and xsd:[time-and-date-types]. If we make use of
those (and I can't really see not doing so at this point ... maybe
someday we could write a better datatype library, but it would be an
effort) then we can't choose "NEVER".

> ... Presumably if we define it as a macro, the user who only wants
> ever to express probability by means of a percentage can say so by
> redefining the macro.

My thoughts exactly.

> >I'm wondering if the concept of "positive integer or 0" is simple
> >enough that we don't need to bother creating a TEI datatype for it,
> >and could just use xsd:nonNegativeInteger directly when needed.
> 
> Fine by me.

Sounds good. Once again, if anyone objects ...

FYI, it will probably take me several days to completely update the
table to reflect these various changes (presuming no one objects), as
my wife will be away and I'll be playing Mr. Mom for a while.

From James.Cummings at computing-services.oxford.ac.uk  Sat Sep  3 12:25:33 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sat, 03 Sep 2005 17:25:33 +0100
Subject: [tei-council] Upcoming teleconference Friday 2005-09-09 at 1300
	UTC
In-Reply-To: <ygfpsrtwr8d.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <ygf1x4azfom.fsf@kanji.zinbun.kyoto-u.ac.jp>	<43156F1F.3050203@computing-services.oxford.ac.uk>
	<ygfpsrtwr8d.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <4319CE7D.6040200@computing-services.oxford.ac.uk>

Christian Wittern wrote:
> James Cummings <James.Cummings at computing-services.oxford.ac.uk> writes:
> 
> I'd prefer to have a dedicated channel for the council.

Ok, on the day of the council call I'll set up a password (or 'key') 
protected channel called #tei-council the joining instructions are the 
same and I'd still suggest joining the #tei-c one.  Once there type:
/join #tei-council 2expensive
and in most IRC clients that will get you there.

> BTW (showing
> my ignorance) is it possible to have a log of the conversation and
> post it for example on the Council pages?

Currently the robot I have sat in the public channel logs everything 
for the previous two days (it has a 'today' log and a 'yesterday' log) 
but these are overwritten each day.  However, it won't be on the 
council channel anyways.

But yes, most clients give a method of logging the traffic in a 
channel.  In fact, gaim gives the option of logging in plain text or 
HTML.  (Although it uses XML for most of its files, it doesn't seem to 
log in it unfortunately.)  I will make sure to enable logging on that 
day, and I hope others will as well to make doubly sure.

> Last time I tried this, I realized that I forgot to ask how do
> disconnect, so my alter ego was hanging around there until the whole
> firefox went belly up...

Most clients will respond to:
/quit
and some will pass on a quit message as well:
/quit I'm off to the pub.

I'm not sure the best way to do this in the Chatzilla extension, since 
I don't use it, but it will probably work with that.

In addition, if this happens often through disconenctions etc. another 
method is to register your nickname with NickServ, then if you come 
back and another virtual you is still there you can:
/ghost nickname password
and it will get rid of the other you.

-James

From lou.burnard at computing-services.oxford.ac.uk  Sat Sep  3 16:48:55 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 03 Sep 2005 21:48:55 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <17175.40233.135852.836925@emt.wwp.brown.edu>
References: <42F77735.1000204@oucs.ox.ac.uk>	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>	<42FB1C7F.2050400@computing-services.oxford.ac.uk>	<42FB20C6.3040306@computing-services.oxford.ac.uk>	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>	<200509011332.j81DWAtv024950@ursa.services.brown.edu>	<431757FA.3010605@computing-services.oxford.ac.uk>
	<17175.40233.135852.836925@emt.wwp.brown.edu>
Message-ID: <431A0C37.6010402@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>>>* the value is from a list specified in the DTD (e.g., status= of
>>> <availability>)
>>>
>>>* the value is an IDREF to something (which has an id=) specified in
>>> the document instance (e.g., who= of <sp> or resp= of <add>)
>>>
>>>* the value is a key into some (ostensibly external, but Lou correctly
>>> points out that, especially in the P5 world, it may well be in the
>>> document instance) resource (e.g., key= of <name>)
>>>...
>>>      
>>>
>>I agree. What are the datatypes which, in P5, should correspond
>>with each of these three cases?
>>    
>>
>
>* tei.data.enumerated
>* tei.data.code
>* tei.data.key
>
>  
>
why is the second case not tei.data.pointer ?

>  
>
>>That depends on what the datatype for "key" is. If it is a URIref,
>>yes. If it is just a xsd:name, then you can't do that without
>>modifying the ODD (which of course is no big deal)
>>    
>>
>
>Yes, that is the question we are currently discussing ... what should
>the datatype of tei.data.key be, a URI or a name? Personally, I'm
>inclined to stick with name. (I.e., that tei.data.key boil down to
>xsd:Name.)
>
>
>  
>
I agree.

>>I think we should use a pointer for the second class
>>[tei.data.code] and xsd:name for the last [tei.data.key].
>>    
>>
>
>OK. On the proposal to constrain the pointer in tei.data.code to be a
>local pointer, do you think it is
>a. a bad idea
>b. a good idea
>c. you're indifferent
>d. a bad idea for TEI to enforce it, but the Guidelines should mention
>   that a project may wish to add this restriction locally, and
>   perhaps even describe how
>e. the TEI should enforce it, and the Guidelines should mention that
>   a project may which to remove this constraint, and perhaps even
>   describe how
>f. the Princeton Band
>
>  
>

I think it is a bad idea.

>Personally, I am leaning towards (b) or (d). The problem with
>permitting a tei.data.code attribute to point outside the current
>document is that it opens a bit of a can of worms as to what it
>points at. E.g., if new= of <handShift> is supposed to point to a
><hand> inside a //TEI/teiHeader/profileDesc/handList, great. But if
>you're putting that <hand> in an external document, what goes inside
>the <text> of that external document?
>
>
>  
>
>>>Note that, if I understand correctly, the key= of <attRef>,
>>><moduleRef>, <specDesc>, and <memberOf> is currently defined as
>>>being a name, and is tied to being one processing chain. I.e.,
>>>using a URI here would break things.
>>>      
>>>
>>Also elsewhere, probably.
>>    
>>
>
>I didn't notice any others, but I didn't look that carefully. Either
>way, the point is that if we change tei.data.key into a URI, we need
>to separate these attributes out into yet a different datatype.
>
>  
>
I disagree. It is a name, not a pointer.

From lou.burnard at computing-services.oxford.ac.uk  Sat Sep  3 17:04:13 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 03 Sep 2005 22:04:13 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <200509020357.j823vkia003843@cepheus.services.brown.edu>
References: <42F77735.1000204@oucs.ox.ac.uk>	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>	<42FB1C7F.2050400@computing-services.oxford.ac.uk>	<42FB20C6.3040306@computing-services.oxford.ac.uk>	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>	<200508312049.j7VKnBia028939@cepheus.services.brown.edu>	<43175F65.6010103@computing-services.oxford.ac.uk>
	<200509020357.j823vkia003843@cepheus.services.brown.edu>
Message-ID: <431A0FCD.4010702@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>
>The idea from Paris was that a <valList>, whether closed, open, or
>semi, is required for an attribute of type tei.data.token. I still
>think that's fine.
>
>
>  
>
No, I think the presence of a valList implies that the datatype should 
be tei.data.enumerated, which maps onto either an explicit list of 
alternatives (if the valList is closed) or onto tei.data.token otherwise.

>  
>
>>I dont quite see what you're getting at here. We need to decide
>>whether sex is an enumeration of possible values (possibly allowing
>>people to use their own values), or a hardwired datatype like date
>>values. My vote, fwiw, is for the former, but I'm open to
>>discussion.
>>

...

>>This is simply reiterating a decision we took at the Council meeting
>>in Oxford, if I remember aright.
>>    
>>
>
>If you say so ... but which was the antecedent of "This"?
>
>
>  
>

That datatypes should all be mapped to xsd: datatypes

>>>If we're going to use W3C datatypes, then at least in those cases
>>>where W3C puts the unit in with the quantity (xsd:duration
>>>explicitly, and the various date and time formats implicitly) we'd
>>>have to do the same.
>>>      
>>>
>
>  
>
>>Yes., but only if we chose to. We could say we will NEVER have
>>attributes which combine in their value quantity+unit, or we could
>>say we have some which do and some which dont, or we could say all
>>quantities have the potential to include units. Again, a list of
>>specific cases might help sharpen discussion and reach a decision.
>>    
>>
>
>Right, but my point was that the choice is inextricably linked to the
>use of xsd:duration and xsd:[time-and-date-types]. If we make use of
>those (and I can't really see not doing so at this point ... maybe
>someday we could write a better datatype library, but it would be an
>effort) then we can't choose "NEVER".
>
>  
>

So the choice is really

(1)  use xsd:duration (which includes units) , and thus remove all the 
additional attributes that specify units

(2) use plain old numeric dataype of some sort, and retain the unit 
attribute

Choice (1) is only going to work for durations where we can be confident 
that the xsd units are going to meet TEI needs, obviously. I fear there 
may be fewer of these than anticipated -- probably people will be 
content to use SI units for times, but you can bet someone will always 
want to measure (e.g.) distance in rods poles and perches.

At present the only attributes assigned tei.data.duration are age= and 
dur=  Choice 1 fits fine with the latter, and reasonably well with the 
former, imho. Any others?

From sebastian.rahtz at oucs.ox.ac.uk  Sat Sep  3 16:57:39 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 03 Sep 2005 21:57:39 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <431A0FCD.4010702@computing-services.oxford.ac.uk>
References: <42F77735.1000204@oucs.ox.ac.uk>	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>	<42FB1C7F.2050400@computing-services.oxford.ac.uk>	<42FB20C6.3040306@computing-services.oxford.ac.uk>	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>	<200508312049.j7VKnBia028939@cepheus.services.brown.edu>	<43175F65.6010103@computing-services.oxford.ac.uk>	<200509020357.j823vkia003843@cepheus.services.brown.edu>
	<431A0FCD.4010702@computing-services.oxford.ac.uk>
Message-ID: <431A0E43.6080507@oucs.ox.ac.uk>

Lou Burnard wrote:

>
> So the choice is really
>
> (1)  use xsd:duration (which includes units) , and thus remove all the
> additional attributes that specify units
>
> (2) use plain old numeric dataype of some sort, and retain the unit
> attribute
>
> Choice (1) is only going to work for durations where we can be
> confident that the xsd units are going to meet TEI needs, obviously. I
> fear there may be fewer of these than anticipated -- probably people
> will be content to use SI units for times, but you can bet someone
> will always want to measure (e.g.) distance in rods poles and perches.
>
surely the point of these attributes is exactly to standardize described
text? so when I see "67 rods", I want to,
and should, encode it as <foo distance="32.3m">67 rods</foo>?

choice (1) seems obvious to me, and always has done. I don't think SI
units do the job,
I'll lobby ISO....

-- 
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 Sep  4 10:41:48 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 04 Sep 2005 15:41:48 +0100
Subject: [tei-council] state of classes etc
Message-ID: <431B07AC.60509@oucs.ox.ac.uk>

Lou asked me to regenerate EDW84, which lists
the elements and the classes they belong to, and vice versa.
I took the chance to clean it up a bit and deliver it as
XML, so its now at http://www.tei-c.org.uk/Drafts/edw84.xml
for you to goggle at.

-- 
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 Sep  4 14:59:26 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 4 Sep 2005 14:59:26 -0400
Subject: [tei-council] comments on edw90
In-Reply-To: <431A0C37.6010402@computing-services.oxford.ac.uk>
References: <42F77735.1000204@oucs.ox.ac.uk>
	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<42FB1C7F.2050400@computing-services.oxford.ac.uk>
	<42FB20C6.3040306@computing-services.oxford.ac.uk>
	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<200509011332.j81DWAtv024950@ursa.services.brown.edu>
	<431757FA.3010605@computing-services.oxford.ac.uk>
	<17175.40233.135852.836925@emt.wwp.brown.edu>
	<431A0C37.6010402@computing-services.oxford.ac.uk>
Message-ID: <17179.17422.849196.713371@emt.wwp.brown.edu>

> >* tei.data.enumerated
> >* tei.data.code
> >* tei.data.key
> >
> why is the second case not tei.data.pointer ?

Good question. In part because I was copying this datatype that we
already had. :-) But more to the point, as currently conceived,
tei.data.pointer is a generic URI. tei.data.code, on the other hand,
is a datatype for local constraint of tokens, that happens to use a
pointer to perform that task. That is, it permits the user to
constrain the set of values of an attribute from within the document
instance. So if a user wants to establish a set of roles for the
various participants in a language interaction, she can do this by
encoding the following <roleDef>s (yeah, I know, there's no such
thing) in the <teiHeader>:

  <roleDef xml:id="session-chair"/>
  <roleDef xml:id="speaker"/>
  <roleDef xml:id="questioner"/>

or, better still

  <roleDef xml:id="session-chair">The session chair, repsonsible ...
  <roleDef xml:id="speaker">Paper presenter, not necessarily the
                            author ...
  <roleDef xml:id="questioner">A member of the auidience who asked

Then in the paticipant group, a
  <person role="#speaker">...
can occur, and Schematron can easily check that the value of role= is
one of "#session-chair", "#speaker", or "#questioner". In some other
instance, even in the same project, we might find

  <roleDef xml:id="conference-chair">One of the program committee
                                     co-chairs ... 
  <roleDef xml:id="server">A server who works for the conference 
                            hotel or the catering service they ...
  <roleDef xml:id="diner">Hotel resteraunt patron ...

So just as something like

  <valList type="closed">
    <valItem ident="session-chair">
      <gloss>The session chair, responsible for ... </gloss>
    </valItem>
    <valItem ident="speaker">
      <gloss>Paper presenter, not necessarily the author ...</gloss>
    </valItem>
    <valItem ident="questioner">
      <gloss>A member of the auidience who asked ...</gloss>
    </valItem>
  </valList>

can be used from within the ODD to constrain the values, something
like the fictional <roleDef>s above can be used from within the
instance to constrain the values. The only reason for using a local
URI and xml:id= over an NCName and ident= is that it's more likely
generic software will be helpful in the former case. The only reason
for not using a local URI, IMHO, is to avoid that ugly "#".

If the datatype were a generic URI, Schematron could still validate
that an attribute pointed to a <roleDef>. It might even be able to
still validate that a bare name fragment identifier was used, and
that it matches the xml:id= of a <roleDef>.

> >Yes, that is the question we are currently discussing ... what
> >should the datatype of tei.data.key be, a URI or a name?
> >Personally, I'm inclined to stick with name. (I.e., that
> >tei.data.key boil down to xsd:Name.)
> >
> I agree.

I'm just double-checking that I've understood you correctly. You are
in agreement that tei.data.key should boil down to an xsd:Name (as
opposed to merely agreeing that this is the question we are
discussing). 

> >OK. On the proposal to constrain the pointer in tei.data.code to be a
> >local pointer, ...
> 
> I think it is a bad idea.

I suppose the reason I am shying away from full-blown URIs (i.e.,
prefer local URIs only, or co-reference with ident=) is that doing so
breaks away from the idea that the value of the attribute conveys
meaning itself, and that the pointing or co-referencing may be used
to provide constraint or to provide further information about the
semantics of the value.

Also, permitting any URI opens the can of worms I mentioned last
time.

> >I didn't notice any other [places than <attRef>, <moduleRef>,
> ><specDesc>, and <memberOf> where key= is defined as a name], but I
> >didn't look that carefully. Either way, the point is that if we
> >change tei.data.key into a URI, we need to separate these
> >attributes out into yet a different datatype.
> >
> I disagree. It is a name, not a pointer.

I don't understand with what you are disagreeing. In case there is
some confusion, let me reiterate the point. If we decide that the
datatype tei.data.key is a URI (which Lou is against, Syd is waffling
back & forth about, and about which no one else has issued an
opinion), then the key= attribute of
  <attRef>
  <moduleRef>
  <specDesc>
  <memberOf>
should not be declared using this datatype. (Which would be a bit
weird, as they're named "key".)

From Syd_Bauman at Brown.edu  Mon Sep  5 16:39:57 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 5 Sep 2005 16:39:57 -0400
Subject: [tei-council] EDW90 and data updated
Message-ID: <17180.44317.441377.692208@emt.wwp.brown.edu>

I've made some minor updates to ED W 90 itself (removed
tei.data.string, as Lou's talked me out of it; where I said "I think
X ..." about whitespace, it now just says "X", as I've checked, and I
was right), and significant updates to the database of attributes and
datatypes. Changes include:

* Updated to reflect the changes Lou made to the CVS source based on
  the database (e.g., deleting most attributes of <teiHeader>)

* Changed various xsd:NMTOKEN attrs to be xsd:Name.

* Changed various things that were tei.data.numeric restricted to
  xsd:nonNegativeInteger to just xsd:nonNegativeInteger.

* Fixed a bunch of typos.

* Removed references to tei.data.string.

I have *not* changed tei.data.uboolean to tei.data.truthValue in the
database yet, but hope to get that done in < 24 hrs. Note that the
new version of ED W 90 itself may not be available on the web for a
few hours.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Sep  6 07:45:25 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 06 Sep 2005 20:45:25 +0900
Subject: [tei-council] Draft agenda for Council teleconference on 2005-09-09
	/ 1300 UTC
Message-ID: <ygfoe76pgh6.fsf@chwpb.local>

TEI Council Members and Editors:

This is the agenda for the conference call the TEI Council will
hold Friday, September 9th, 2005 at 1300 UTC.

Please read through the following, in advance of the call.  

INSTRUCTIONS for conference call:

Participants will dial in to +1-812-856-3600

The Conference Access Information is listed below:

Conf Id:        2174
Date:        9/9/2005

PIN:        000920#

Expected members to participate:

Syd Bauman, Alejandro Bia, Lou Burnard, James Cummings, Julia
Flanders, Susan Schreibman, Sebastian Rahtz, Laurent Romary, Natasha
Smith, John Walsh, Perry Willett, Christian Wittern.

Edward Vanhoutte excused himself and is busy working on his thesis while we talk.

Matthew Driscoll will be in Bulgaria, or actually on a bus somewhere
between Sofia and Ohrid, Macedonia.  

In addition to the voice connection, we also expect to communicate via
IRC. Instructions to connect are as follows (quoted from James
Cumming's message):

Basically, in almost any IRC client, set the server to be irc.freenode.net
and the channel to be #tei-c and you should be fine.  In some clients
this is done through setting up an account in various graphical
manners, in others you might use /connect serverName or /server
serverName and then /join #tei-c     [for #tei-council see below] 
Alternatively, if you have the Chatzilla extension installed, in the
address bar of firefox you can use this url:
irc://irc.freenode.net/tei-c to connect.  My preferred client is gaim
because it is multi-protocol (does yahoo, aim/aol, msn, jabber, gmail,
chat protocols amongst others).
...
Ok, on the day of the council call I'll set up a password (or 'key')
protected channel called #tei-council the joining instructions are the
same and I'd still suggest joining the #tei-c one.  Once there type:
/join #tei-council 2expensive
and in most IRC clients that will get you there.

(instructions also at:

http://www.tei-c.org.uk/wiki/index.php/IRC

However, the information on specific clients is limited, so do feel
free to add more detail! )

Agenda:

7 items, ca 5-20 minutes apiece.

-----------------------------------------------------

1) Review of the minutes and action items (10 min)

   Minutes of the meeting are at
	 http://www.tei-c.org/Council/tcm18.html.

	 To speed up the review of action items, *please report to the
	 council list* before the call as far as possible! 

	 We will discuss the reports during the call as necessary.

------------------------------------------------------------

2) Review of WG etc. progress (10 min) : 

-----------------------------------------------------

3) Report about TEI Council/ W3C I18N collaboration (5 Minutes)

	 Sebastian Rahtz

------------------------------------------------------------

4) Report about TEI I18N activity  (5 Minutes)

	Sebastian Rahtz,

  please see also 
	http://users.ox.ac.uk/~rahtz/i18n/demo.html

------------------------------------------------------------

5) P5 progress:  (20 min)

- on Attributes and Datatypes (EDW90)
	http://www.tei-c.org.uk/Drafts/edw90.xml?style=printable
	and various comments on tei-council
- on classes (?)
  http://www.tei-c.org.uk/Drafts/edw84.xml

-----------------------------------------------------

6) Other business  (5 minutes)

   TBA

-----------------------------------------------------

7) Meetings: (5 minutes)

   Next call, members meeting preparations.

-- 

 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 Sep  6 07:52:25 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 06 Sep 2005 12:52:25 +0100
Subject: [tei-council] Draft agenda for Council teleconference on
	2005-09-09 / 1300 UTC
In-Reply-To: <ygfoe76pgh6.fsf@chwpb.local>
References: <ygfoe76pgh6.fsf@chwpb.local>
Message-ID: <431D82F9.2020207@oucs.ox.ac.uk>

Christian Wittern wrote:

>4) Report about TEI I18N activity  (5 Minutes)
>
>	Sebastian Rahtz,
>
>  please see also 
>	http://users.ox.ac.uk/~rahtz/i18n/demo.html
>  
>
actually, better now is http://www.tei-c.org/I18N/demo.xml

sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Tue Sep  6 08:07:17 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 06 Sep 2005 13:07:17 +0100
Subject: [tei-council] Draft agenda for Council teleconference on
	2005-09-09 / 1300 UTC
In-Reply-To: <ygfoe76pgh6.fsf@chwpb.local>
References: <ygfoe76pgh6.fsf@chwpb.local>
Message-ID: <431D8675.6020702@oucs.ox.ac.uk>

Report on Actions from last telco for SR

a) "create new release": duly done (and revised a day or two later) and 
all components updated in Sourceforge, on web site, etc. All being well, 
another release will be made to coincide with the Members Meeting, with 
the expectation that it will include new datatypes.

b) "details of directory layout": it was created, used, shipped etc. 
Syncrosoft duly used it in the oXygen public release, and it appears to 
be stable

memo to Lou and Syd:  read the second para of section 4 of the minutes.

sebastian

From James.Cummings at computing-services.oxford.ac.uk  Tue Sep  6 10:25:06 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 06 Sep 2005 15:25:06 +0100
Subject: [tei-council] Draft agenda for Council teleconference on
	2005-09-09 / 1300 UTC
In-Reply-To: <ygfoe76pgh6.fsf@chwpb.local>
References: <ygfoe76pgh6.fsf@chwpb.local>
Message-ID: <431DA6C2.7080306@computing-services.oxford.ac.uk>

Christian Wittern wrote:
> 	 To speed up the review of action items, *please report to the
> 	 council list* before the call as far as possible! 

One of the action items for me to do was a HOWTO for the Stylesheets CVS module. 
  This has changed into a larger document detailing all the CVS modules and is 
available at:

http://www.tei-c.org/Council/tcw06.xml

Today Syd has suggested some changes which I should have finished by the time of 
the conference call.  However, more suggestions and corrections are desired.  It 
should give you enough information to have you be able to use TEI's CVS.  If it 
doesn't, tell me where.  (Though we don't want to just duplicate information 
available on the sourceforge site or elsewhere on the TEI site.)

-James

From Syd_Bauman at Brown.edu  Thu Sep  8 00:40:16 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 8 Sep 2005 00:40:16 -0400
Subject: [tei-council] Draft agenda for Council teleconference on
	2005-09-09 / 1300 UTC
In-Reply-To: <ygfoe76pgh6.fsf@chwpb.local>
References: <ygfoe76pgh6.fsf@chwpb.local>
Message-ID: <17183.49328.443517.263433@emt.wwp.brown.edu>

>        To speed up the review of action items, *please report to
>        the council list* before the call as far as possible!

| * SR & SB:  Hammer out details of directory layout 

Done.

| * SB: make all resp attributes into pointers. Scheduled for end of
|       August, still planning to do so then.

Done.

| * SB & DD: finish SA discussions of XPointer ... 

>From DD "most of the scheme stuff rewritten", but still have to do
the prose describing XPointer. I'm hoping we can check in at least
the XPointer scheme discussions before the conference call.

| * SB: with DD produce brief report on process for getting XPointer
|       schemes registered

No need. According to Henry Thompson there still is no process for
getting XPointer schemes registered at W3C. We should declare our
intention to register our schemes when the registry becomes "live" by
sending mail to ... Henry, I think, but will have to check on that.

Since some of the underlying presumptions of the setup of datatypes
in EDW90's table have proven to be incorrect, I am planning to spend
time in the immediate future revamping the suggested declarations of
attribute values in the immediate future, rather than switch gears to
the bibliography.

From James.Cummings at computing-services.oxford.ac.uk  Thu Sep  8 06:03:31 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 08 Sep 2005 11:03:31 +0100
Subject: [tei-council] Draft agenda for Council teleconference
	on	2005-09-09 / 1300 UTC
In-Reply-To: <431D82F9.2020207@oucs.ox.ac.uk>
References: <ygfoe76pgh6.fsf@chwpb.local> <431D82F9.2020207@oucs.ox.ac.uk>
Message-ID: <43200C73.9030201@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> actually, better now is http://www.tei-c.org/I18N/demo.xml

Am I missing something or isn't there a hu/hu or in fact any ??/hu ?

Not that I have any need of it personally.

-James

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep  8 06:08:03 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 08 Sep 2005 11:08:03 +0100
Subject: [tei-council] Draft agenda for Council teleconference
	on	2005-09-09 / 1300 UTC
In-Reply-To: <43200C73.9030201@computing-services.oxford.ac.uk>
References: <ygfoe76pgh6.fsf@chwpb.local> <431D82F9.2020207@oucs.ox.ac.uk>
	<43200C73.9030201@computing-services.oxford.ac.uk>
Message-ID: <43200D83.9080409@oucs.ox.ac.uk>

James Cummings wrote:

>
> Am I missing something or isn't there a hu/hu or in fact any ??/hu ?
>
> Not that I have any need of it personally.
>
I can only do hu/hu or ??/hu when a person of hu persuasion translates the
sample file for me...

ditto a large number of other [a-z][a-z]/[a-z][a-z] combinations...

sebastian

From James.Cummings at computing-services.oxford.ac.uk  Thu Sep  8 06:14:35 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 08 Sep 2005 11:14:35 +0100
Subject: [tei-council] Draft agenda for Council
	teleconference	on	2005-09-09 / 1300 UTC
In-Reply-To: <43200D83.9080409@oucs.ox.ac.uk>
References: <ygfoe76pgh6.fsf@chwpb.local>
	<431D82F9.2020207@oucs.ox.ac.uk>	<43200C73.9030201@computing-services.oxford.ac.uk>
	<43200D83.9080409@oucs.ox.ac.uk>
Message-ID: <43200F0B.5090803@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> I can only do hu/hu or ??/hu when a person of hu persuasion translates the
> sample file for me...
> 
> ditto a large number of other [a-z][a-z]/[a-z][a-z] combinations...

I'm confused then, how do you get the en/hu/ es/hu fr/hu without having had a 
person of hu persuasion do some translating?

-James

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep  8 07:01:44 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 08 Sep 2005 12:01:44 +0100
Subject: [tei-council] Draft agenda for Council
	teleconference	on	2005-09-09 / 1300 UTC
In-Reply-To: <43200F0B.5090803@computing-services.oxford.ac.uk>
References: <ygfoe76pgh6.fsf@chwpb.local>
	<431D82F9.2020207@oucs.ox.ac.uk>	<43200C73.9030201@computing-services.oxford.ac.uk>
	<43200D83.9080409@oucs.ox.ac.uk>
	<43200F0B.5090803@computing-services.oxford.ac.uk>
Message-ID: <43201A18.6020207@oucs.ox.ac.uk>

James Cummings wrote:

>
> I'm confused then, how do you get the en/hu/ es/hu fr/hu without 
> having had a person of hu persuasion do some translating?

you have to distinguish between "hu" and "hu". the former is the translation
of a sample .odd file, the later is the translation of the string 
constants in the XSLT
stylesheets. I have the latter for hu, not the former.

is there a language code "wu", so that we could have "wu hu"?

sebastian

From Julia_Flanders at Brown.edu  Thu Sep  8 16:38:56 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 8 Sep 2005 16:38:56 -0400
Subject: [tei-council] report on certainty
In-Reply-To: <ygfoe76pgh6.fsf@chwpb.local>
References: <ygfoe76pgh6.fsf@chwpb.local>
Message-ID: <a0620072bbf4648aff2a9@[128.148.157.102]>

I have to apologize for the lateness and sketchiness of this report.

I had originally thought that in reviewing <certainty> and cert= I 
would find a great deal to change. However, after reviewing the 
discussion on TEI-L concerning certainty mechanisms, it seems as 
though people are generally content with the existing mechanisms. The 
areas of debate seem chiefly to concern how precise to be in 
assigning uncertainty. The approach Lou has been presenting (default 
three-value approach built in, extensible by the user) seems 
sensible; I believe that for most purposes it will not be possible to 
say more than "high|medium|low" and encouraging people to use those 
values is useful.

One interesting distinction was raised by Tim Finney, concerning a 
possible distinction, within the concept of "certainty", between:
--identifying how close one thinks one's encoding/transcription/etc 
is to the actual
--identifying how repeatable or "popular" an encoding is: how likely 
it is to be agreed with (this is what Finney called "precision"  but 
I don't think this is a good term in this context)

This is ingenious, but I don't think it's essential. In practice, 
it's difficult to assess how close an encoding is to being correct, 
except by saying something like "I'm [not | sort of | very] sure...", 
and assessing how repeatable an encoding is would be equally 
difficult.

Concerning the existing <certainty> element:
--the current attributes are reasonable, provide a way to point to 
the range of things one needs to comment on; most people don't 
need/won't be bothered to use these, but for the enthusiast they seem 
adequate based on the feedback we've had
--desc= will need to be a child element (but this is already 
contemplated, right?)
--degree= should use same values as cert= (?) since whatever insight 
we have about appropriate levels of precision will apply equally to 
both.

It would be helpful to add a recommendation of where in the document 
the <certainty> elements should live, and perhaps also to restrict 
where they go. At the moment, they could go anywhere, and I'm not 
sure this is useful. Would it make sense to create a place in the 
header for this kind of metacommentary? This would make it easier to 
contemplate processing the information systematically.

Best wishes, Julia

>1) Review of the minutes and action items (10 min)
>
>    Minutes of the meeting are at
>	 http://www.tei-c.org/Council/tcm18.html.
>
>	 To speed up the review of action items, *please report to the
>	 council list* before the call as far as possible!
>
>	 We will discuss the reports during the call as necessary.

From lou.burnard at computing-services.oxford.ac.uk  Thu Sep  8 16:50:56 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 08 Sep 2005 21:50:56 +0100
Subject: [tei-council] Changes to P5
Message-ID: <4320A430.2070107@computing-services.oxford.ac.uk>

Here is the rather overdue report on changes to TEI P5 carried out since 
the start of July. Many apologies for the delay. I forgot to do it 
before setting off for DRH last week.

The P5 Changelog shows the following significant changes to P5 since
my last report (7 Jul 05)

* Renamed <bob> as <binaryObject> and added some discussion of its
  usage in CO

* Following much debate, a new directory structure was implemented,
  and a complete release (0.1.9) made using it. This was followed
  within a week by another (0.1.10) including Exemplars

* Changed desc attribute (e.g. on gap, join, joingrp) into
  child element; removed hand attribute on hand; change  value
  attribute on span  into content;

* New class "intervention" introduced to regularize use of resp and
  cert attributes

* Removed most attributes from <teiHeader> element

* Added valList elements to several tagdocs

* New class "ascribed" introduced to regularise use of who attribute

* Update MS draft and associated tagdocs following chapter review

* Rename hand at character as writing; rename date at certainty as
  precision; renamed code at type as lang; rename witness at sigil as xml:id

* Tidied up inconsistent use of <code> and <val> across the text of 5

* Changed @resp datatype into a pointer

* Several typos and inconsistencies were identified and fixed.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Sep  8 21:17:59 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 09 Sep 2005 10:17:59 +0900
Subject: [tei-council] Draft agenda for Council teleconference on
	2005-09-09 / 1300 UTC
In-Reply-To: <431DA6C2.7080306@computing-services.oxford.ac.uk> (James
	Cummings's message of "Tue, 06 Sep 2005 15:25:06 +0100")
References: <ygfoe76pgh6.fsf@chwpb.local>
	<431DA6C2.7080306@computing-services.oxford.ac.uk>
Message-ID: <ygfu0gvdooo.fsf@chwpb.local>

James Cummings <James.Cummings at computing-services.oxford.ac.uk> writes:

> Christian Wittern wrote:
>> 	 To speed up the review of action items, *please report to the
>> 	 council list* before the call as far as possible! 
>
> One of the action items for me to do was a HOWTO for the Stylesheets
> CVS module. This has changed into a larger document detailing all the
> CVS modules and is available at:
>
> http://www.tei-c.org/Council/tcw06.xml

Thanks.  I just read through the document, where presumably now
changes requested by Syd are integrated.  I had hoped that it would
describe not just what is there, but also gives the reader advise on
how to arrive at a usable local installation (which seems to be the
purpose of using CVS to me).  This probably means that you would first
have to install the Stylesheets, then P5 and then Roma (?).  I think
it would be nice if you could add a section that walks the reader
through a sample session that installs a usable local P5
environment. (Of course it would be even nicer if this would not be
necessary and you could just say "make install" and the whole shebang
would end up where it wants to be.

>
> Today Syd has suggested some changes which I should have finished by
> the time of the conference call.  However, more suggestions and
> corrections are desired.  It should give you enough information to
> have you be able to use TEI's CVS.  If it doesn't, tell me where.
> (Though we don't want to just duplicate information available on the
> sourceforge site or elsewhere on the TEI site.)

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 Sep  8 22:08:20 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 09 Sep 2005 11:08:20 +0900
Subject: P5 CVS woes (was Re: [tei-council] Draft agenda for Council
	teleconference on 2005-09-09 / 1300 UTC)
In-Reply-To: <431DA6C2.7080306@computing-services.oxford.ac.uk> (James
	Cummings's message of "Tue, 06 Sep 2005 15:25:06 +0100")
References: <ygfoe76pgh6.fsf@chwpb.local>
	<431DA6C2.7080306@computing-services.oxford.ac.uk>
Message-ID: <ygfy867at7v.fsf_-_@chwpb.local>

James Cummings <James.Cummings at computing-services.oxford.ac.uk> writes:

> http://www.tei-c.org/Council/tcw06.xml
>

For the record, I just tried to proceed to get a running P5 on my Mac
OS 10.3 machine, starting with the Stylesheet module, saying 

make install

This fails since the xsltdoc stuff is not there (Sebastian, remember
that I mentioned that before?) Anyhow, I proceeded to download xsltdoc
from http://prdownloads.sourceforge.net/xsltdoc/XSLTdoc_1.1.zip
and installed it locally, adding a symlink to the directory where my
Stylesheets live.  Now I do  "make install" again, this time I get:

chris at chwpb:~/src/tei/Stylesheets % sudo make install
Error on line 101 of file:/Users/chris/src/tei/Stylesheets/xsltdoc/xsl/core.xsl:
  XPTY0004: Required item type of value of variable $sourceRootUriAbs is xs:string; supplied
  value has item type xs:anyURI
Failed to compile stylesheet. 1 error detected.

having seen that it calls saxon, I assume that this might be a problem
with the stylesheets expecting a XSLT 1.0 processor, while my default
saxon is for XSLT 2.0.  I then switch the local saxon to 6.5.4 (or
whatever) and re-run the "make install" command.  This time I get 111
errors, go back to the XSLTDoc page and see that it requires XSLT
2.0. At this time I could go hunting for bugs in XSLTdoc, but since my
purpose is installing P5 I am ready to give up on this...

What it comes down to is that at the moment there seems to be no
(easy?) way to install the CVS Stylesheets (and the other P5 modules)
locally.  We need to solve this and update the document accordingly.

I know, I could just point to the stylesheets on the TEI website, as
James mentions in the document, so I do:

  chris at chwpb:~/src/tei/P5 % XSL=http://www.tei-c.org/stylesheet make -e
Checking you have a running XML tools and Perl before trying to run transform...
xsltproc:/sw/bin/xsltproc
Perl:/usr/bin/perl
xmllint:/sw/bin/xmllint
trang:/Users/chris/bin/trang
jing:/Users/chris/bin/jing
mkdir DTD
rm DTD/*
rm: DTD/*: No such file or directory
make: [dtds] Error 1 (ignored)
# generate the DTDs
xmllint --noent   Source-driver.xml | \
xsltproc --stringparam outputDir DTD --stringparam verbose true http://www.tei-c.org/stylesheet/odds/odd2dtd.xsl -
warning: failed to load external entity "http://www.tei-c.org/stylesheet/odds/odd2dtd.xsl"
cannot parse http://www.tei-c.org/stylesheet/odds/odd2dtd.xsl
make: *** [dtds] Error 4

At which point I am at the end of my wits.

The modules do not seem to be usable without a Debian system at the
moment (of the four I had running here, the last one went out of
service a few weeks ago).

All the best,

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  Thu Sep  8 23:09:15 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 8 Sep 2005 23:09:15 -0400
Subject: [tei-council] comments on edw90
In-Reply-To: <431A0FCD.4010702@computing-services.oxford.ac.uk>
References: <42F77735.1000204@oucs.ox.ac.uk>
	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<42FB1C7F.2050400@computing-services.oxford.ac.uk>
	<42FB20C6.3040306@computing-services.oxford.ac.uk>
	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<200508312049.j7VKnBia028939@cepheus.services.brown.edu>
	<43175F65.6010103@computing-services.oxford.ac.uk>
	<200509020357.j823vkia003843@cepheus.services.brown.edu>
	<431A0FCD.4010702@computing-services.oxford.ac.uk>
Message-ID: <17184.64731.463270.588807@emt.wwp.brown.edu>

My apologies for the delay. Several pieces of e-mail seem to have
gotten swallowed in my Inbox. I'm only going to get to this one
tonight, I'm afraid.

SB>The idea from Paris was that a <valList>, whether closed, open, or
SB>semi, is required for an attribute of type tei.data.token. I still
SB>think that's fine.

LB> No, I think the presence of a valList implies that the datatype
LB> should be tei.data.enumerated, which maps onto either an explicit
LB> list of alternatives (if the valList is closed) or onto
LB> tei.data.token otherwise.

Sorry -- You are right, I had meant "tei.data.enumerated" in that
sentence.

LB> [That datatypes should all be mapped to xsd: datatypes] is simply
LB> reiterating a decision we took at the Council meeting in Oxford,
LB> if I remember aright.

The minutes say only "it was proposed [within META] ... to define
datatypes for attribute values more abstractly, mapping them to W3C
schema datatypes where possible".

LB> So the choice is really
LB> 
LB> (1) use xsd:duration (which includes units) , and thus remove all
LB> the additional attributes that specify units
LB> 
LB> (2) use plain old numeric dataype of some sort, and retain the
LB> unit attribute
LB> 
LB> Choice (1) is only going to work for durations where we can be
LB> confident that the xsd units are going to meet TEI needs,
LB> obviously. I fear there may be fewer of these than anticipated --
LB> probably people will be content to use SI units for times, but
LB> you can bet someone will always want to measure (e.g.) distance
LB> in rods poles and perches.
LB> 
LB> At present the only attributes assigned tei.data.duration are
LB> age= and dur= Choice 1 fits fine with the latter, and reasonably
LB> well with the former, imho. Any others?

SR> surely the point of these attributes is exactly to standardize
SR> described text? so when I see "67 rods", I want to, and should,
SR> encode it as <foo distance="32.3m">67 rods</foo>?

SR> choice (1) seems obvious to me, and always has done. I don't
SR> think SI units do the job, I'll lobby ISO....

I'm not entirely sure I fully understand what Lou's getting at, but I
think I agree with Sebastian. Are we talking just about durations,
here, or about any and all things that have units?

I haven't done an exhaustive search, but the attributes that are
concerned with duration include
* dur= of %tei.timed; & <recording>
* age= of <person>
* interval= & unit= of <timeline> & <when>
and could include 
* value= of the various date & time elements

While I think sticking with a number-and-unit-in-one approach of
xsd:duration probably makes sense for all of these, there are some
problems with using just xsd:duration alone for them.

First, xsd:duration permits negative values, which don't make sense
for age= or interval=/unit=. Second, it is my bet that TEI users in
general are not going to want to express someone's age as, e.g.
"P36Y", but would much rather "36 yr" (and we can argue over details
like "year" vs "yr" vs "years" vs "yrs", white-space or not).

IMHO we are *not* talking about <measure>, where the unit should
almost assuredly be kept separate from the numeric component.

From sebastian.rahtz at oucs.ox.ac.uk  Fri Sep  9 03:53:51 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 09 Sep 2005 08:53:51 +0100
Subject: P5 CVS woes (was Re: [tei-council] Draft agenda for
	Council	teleconference on 2005-09-09 / 1300 UTC)
In-Reply-To: <ygfy867at7v.fsf_-_@chwpb.local>
References: <ygfoe76pgh6.fsf@chwpb.local>	<431DA6C2.7080306@computing-services.oxford.ac.uk>
	<ygfy867at7v.fsf_-_@chwpb.local>
Message-ID: <43213F8F.2050608@oucs.ox.ac.uk>

Christian Wittern wrote:

>
>What it comes down to is that at the moment there seems to be no
>(easy?) way to install the CVS Stylesheets (and the other P5 modules)
>locally.  We need to solve this and update the document accordingly.
>  
>

the correct way to get yourself a P5 local install
is to use the Debian or RPM packages...

but I'll look at this again.

sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Fri Sep  9 03:57:04 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 09 Sep 2005 08:57:04 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <17184.64731.463270.588807@emt.wwp.brown.edu>
References: <42F77735.1000204@oucs.ox.ac.uk>	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>	<42FB1C7F.2050400@computing-services.oxford.ac.uk>	<42FB20C6.3040306@computing-services.oxford.ac.uk>	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>	<200508312049.j7VKnBia028939@cepheus.services.brown.edu>	<43175F65.6010103@computing-services.oxford.ac.uk>	<200509020357.j823vkia003843@cepheus.services.brown.edu>	<431A0FCD.4010702@computing-services.oxford.ac.uk>
	<17184.64731.463270.588807@emt.wwp.brown.edu>
Message-ID: <43214050.8060906@oucs.ox.ac.uk>

Syd Bauman wrote:

> Second, it is my bet that TEI users in
>general are not going to want to express someone's age as, e.g.
>"P36Y", but would much rather "36 yr" (and we can argue over details
>like "year" vs "yr" vs "years" vs "yrs", white-space or not).
>
>  
>
I still say that if you use this attribute, you are committing yourself
to formal standardized notation. If the appropriate body has agreed
on "P36Y", it seems madness to me for text encoding folks to say they
want to withdraw from standardisation efforts, and insist on Western-centric
adhoc uncodified notation.

Sebastian

From jawalsh at indiana.edu  Fri Sep  9 04:20:45 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Fri, 9 Sep 2005 03:20:45 -0500
Subject: P5 CVS woes (was Re: [tei-council] Draft agenda for
	Council	teleconference on 2005-09-09 / 1300 UTC)
In-Reply-To: <43213F8F.2050608@oucs.ox.ac.uk>
References: <ygfoe76pgh6.fsf@chwpb.local>	<431DA6C2.7080306@computing-services.oxford.ac.uk>
	<ygfy867at7v.fsf_-_@chwpb.local> <43213F8F.2050608@oucs.ox.ac.uk>
Message-ID: <FD89CB52-FE66-44A1-B127-A6742358CC3A@indiana.edu>

| John A. Walsh, Associate Director for Projects and Services
| Digital Library Program / Indiana University Libraries
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 Fax:812-856-2062 <mailto:jawalsh at indiana.edu>

On Sep 9, 2005, at 2:53 AM, Sebastian Rahtz wrote:

> Christian Wittern wrote:
>
>
>>
>> What it comes down to is that at the moment there seems to be no
>> (easy?) way to install the CVS Stylesheets (and the other P5 modules)
>> locally.  We need to solve this and update the document accordingly.
>>
>>
>
> the correct way to get yourself a P5 local install
> is to use the Debian or RPM packages...

Certainly installing from source (or CVS) without having to use a  
package should also be a "correct" way to install P5,  no?  Not every  
system supports Debian or RPM packages.

>
> but I'll look at this again.
>
> 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  Fri Sep  9 04:30:13 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 09 Sep 2005 09:30:13 +0100
Subject: P5 CVS woes (was Re: [tei-council] Draft agenda
	for	Council	teleconference on 2005-09-09 / 1300 UTC)
In-Reply-To: <FD89CB52-FE66-44A1-B127-A6742358CC3A@indiana.edu>
References: <ygfoe76pgh6.fsf@chwpb.local>	<431DA6C2.7080306@computing-services.oxford.ac.uk>	<ygfy867at7v.fsf_-_@chwpb.local>
	<43213F8F.2050608@oucs.ox.ac.uk>
	<FD89CB52-FE66-44A1-B127-A6742358CC3A@indiana.edu>
Message-ID: <43214815.7010306@oucs.ox.ac.uk>

John A. Walsh wrote:

>
> Certainly installing from source (or CVS) without having to use a  
> package should also be a "correct" way to install P5,  no?  Not every  
> system supports Debian or RPM packages.
>
only evil ones don't :-}

but you're right, of course; I'll make sure the "install" targets work 
for Stylesheets and P5

sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Fri Sep  9 04:43:09 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 09 Sep 2005 09:43:09 +0100
Subject: P5 CVS woes (was Re: [tei-council] Draft agenda for
	Council	teleconference on 2005-09-09 / 1300 UTC)
In-Reply-To: <ygfy867at7v.fsf_-_@chwpb.local>
References: <ygfoe76pgh6.fsf@chwpb.local>	<431DA6C2.7080306@computing-services.oxford.ac.uk>
	<ygfy867at7v.fsf_-_@chwpb.local>
Message-ID: <43214B1D.9040801@oucs.ox.ac.uk>

Christian Wittern wrote:

>
> starting with the Stylesheet module, saying 
>
>make install
>
>This fails since the xsltdoc stuff is not there 
>
try now. it bypasses that bit if you don't have xsltdoc.

>I know, I could just point to the stylesheets on the TEI website, as
>James mentions in the document, so I do:
>
>  chris at chwpb:~/src/tei/P5 % XSL=http://www.tei-c.org/stylesheet make -e
>  
>
this should be

make XSL=http://www.tei-c.org/release/xml/tei/stylesheet

James, can you check your doc and make sure it uses that example?

sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Fri Sep  9 04:55:55 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 09 Sep 2005 09:55:55 +0100
Subject: [tei-council] Draft agenda for Council teleconference
	on	2005-09-09 / 1300 UTC
In-Reply-To: <ygfu0gvdooo.fsf@chwpb.local>
References: <ygfoe76pgh6.fsf@chwpb.local>	<431DA6C2.7080306@computing-services.oxford.ac.uk>
	<ygfu0gvdooo.fsf@chwpb.local>
Message-ID: <43214E1B.3030904@oucs.ox.ac.uk>

If you update from CVS, I claim that

 (cd Stylesheets; make PREFIX=/tmp/foo install)
 (cd Roma; make PREFIX=/tmp/foo install)
 (cd P5; make PREFIX=/tmp/foo XSL=/tmp/foo2/share/xml/tei/stylesheet 
install)

will behave as expected

Sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Fri Sep  9 05:06:27 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 09 Sep 2005 10:06:27 +0100
Subject: [tei-council] Draft agenda for Council teleconference
	on	2005-09-09 / 1300 UTC
In-Reply-To: <ygfu0gvdooo.fsf@chwpb.local>
References: <ygfoe76pgh6.fsf@chwpb.local>	<431DA6C2.7080306@computing-services.oxford.ac.uk>
	<ygfu0gvdooo.fsf@chwpb.local>
Message-ID: <43215093.3000802@oucs.ox.ac.uk>

Christian Wittern wrote:

>
>(Of course it would be even nicer if this would not be
>necessary and you could just say "make install" and the whole shebang
>would end up where it wants to be.
>  
>
I think there is a stage beyond this which is even more
important, and which isn't complete yet; and that is the
answer to "so I've run 'make install' and the files are all in place;
now how do I make oXygen/xMeTaL/jEdit/Emacs find the
stuff"

sebastian

From abia at umh.es  Fri Sep  9 08:19:16 2005
From: abia at umh.es (Alejandro Bia)
Date: Fri, 09 Sep 2005 14:19:16 +0200
Subject: [tei-council] Unable to attend conference-call
Message-ID: <5.2.0.9.0.20050909141512.03d82658@mussol.umh.es>

Dear all,

Today I have to put an exam at the university at the same time of the call, 
so I will not be able to participate. I'm sorry.

Later, I will send another message with some other matters I need to 
communicate to the Council.

Best wishes,
Alex.-

---------------------------------------------------------
ALEJANDRO BIA-PLATAS
e-mail: abia at umh.es

   Departamento de Estad?stica, Matem?tica e Inform?tica
   Universidad Miguel Hern?ndez
   Edificio Torretamarit
   Avenida de la Universidad s/n, E-03202, Elche, ESPA?A
   http://www.umh.es/
   Tel: +34 966658542
   Fax: +34 966658715
   Tel?fono m?vil: +34 610806427

--------------------------------------------------------- 

From Julia_Flanders at Brown.edu  Fri Sep  9 11:30:07 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Fri, 9 Sep 2005 11:30:07 -0400
Subject: [tei-council] more on certainty
Message-ID: <a06200733bf473d9f5b53@[128.148.157.102]>

Here are some more specific assessments of the certainty= and exact= 
attributes on <date> and <dateStruct>, in the context of the cert= 
attribute. It didn't take 3 hours, so I'm still good to go on the 
verse chapter :-)

1. The state of play
In P4 we have the following provisions:
<date certainty=""> with suggested values "approx | before | after"; 
intended to capture "degree of precision"
<dateStruct exact=""> with suggested values "approx | before | 
after"; intended to capture "degree of precision"
For P5 so far Lou has changed the certainty= attribute on <date> to precision=.

Here are the things I think one can say in general about dates:
precision: how many decimal places
accuracy: how "true" or "correct"
certainty: our state of mind about truth or correctness
and also more specific date-like things, such as Gabriel Bodard's 
suggested "notBefore", "notAfter", which seem to me to be potentially 
useful specifications under the general heading of precision. (That 
is, they are a way of adding, slightly, to the precision of a date.)

2. Is precision useful on dates? yes, I think it is.
If so, how to encode it?
--both certainty= on <date> and exact= on <dateStruct> could be 
changed to precision= (already begun)
--but if the values for these attributes are intended to indicate 
"degree of precision", the suggested values from P4 are not good for 
this. It also seems to me that one can determine how precise a date 
is by looking at the value= attribute, which clearly shows whether a 
date is stated to the century, year, month, day, etc. So I would 
propose that the precision= attribute may be redundant; if someone 
wants to indicate how precise a date is, they should do so by using 
the value= attribute with a properly ISO formatted date.
--the impulse behind the P4 suggested values is reflected more 
successfully in Gabriel Bodard's suggestion that we add the 
attributes notBefore= and notAfter=. His additional proposal that the 
exact= attribute be used to indicate whether either or both of these 
is exact seems unnecessary: this kind of "exactness" seems to me to 
be more a statement about our level of knowledge than about the date 
itself; see below on certainty.

2. Is accuracy useful on dates? I think this is more difficult to say.
--dates that are transcribed may be transcribed accurately or 
inaccurately, but if the latter surely the encoder would not know (or 
else they'd fix it)
--dates that are supplied, i.e. those that originate with the 
encoder/project, may (in theory) be known to be accurate or 
inaccurate, but the latter case is a little bizarre to imagine.
--need to distinguish between inaccuracies (a person--e.g. an 
author--has a wrong idea) and errors (the text has a wrong value), 
but it's hard to know which is which. For instance, if you see the 
sentence

	The American Civil War ended in 1850

is it useful to say that the date is inaccurate? or would you be more 
likely to use <sic>?

3. Is certainty useful on dates? I think probably so, but there are 
several things about which one might be certain:
--in data which is being generated rather than transcribed, one may 
not be certain about whether a date is correct or not, and one might 
wish to indicate this fact. For instance, in transcribing interview 
data, one might have reason to doubt the correctness of all the dates 
of interviews conducted by Person X, who is known to have been 
suffering mental problems at the time and wasn't keeping good notes. 
The dates as recorded might be very precise, but also very uncertain.
--one might also wish to express uncertainty about the level of 
precision recorded.
--I don't see that it is useful to express certainty (i.e. a state of 
mind) concerning the exactness (i.e. the precision) of a date. One 
expresses the precision using the mechanism given above; one can say 
a date is notBefore a certain date (which itself can be expressed 
with whatever level of precision is appropriate). But expressing, 
additionally, ideas about whether the precision of that notBefore 
value is correct is just way too meta for me.

I'm leaving out here forms of uncertainty which affect the *reading* 
or *transcription* of the date, which would fall under <unclear>, etc.

If so, how to encode it?
--for the first case above, I'd say that a cert= attribute on <date> 
and <dateStruct> might be useful.
--for the second case, <certainty> seems to be the more appropriate element.

4. Summary
--consider whether precision= is really necessary: does it add to the 
information available in value=, or does it make that information 
available in a more tractable form?
--add notBefore= and notAfter= to <date> and <dateStruct>
--consider adding cert= to <date> and <dateStruct>
--don't try to capture level of accuracy in dates?

I hope this is useful.

best wishes, Julia

From James.Cummings at computing-services.oxford.ac.uk  Fri Sep  9 12:55:00 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 09 Sep 2005 17:55:00 +0100
Subject: [tei-council] Re: tcw06.xml
In-Reply-To: <ygfu0gvdooo.fsf@chwpb.local>
References: <ygfoe76pgh6.fsf@chwpb.local>	<431DA6C2.7080306@computing-services.oxford.ac.uk>
	<ygfu0gvdooo.fsf@chwpb.local>
Message-ID: <4321BE64.3060000@computing-services.oxford.ac.uk>

Christian Wittern wrote:
>I think
> it would be nice if you could add a section that walks the reader
> through a sample session that installs a usable local P5
> environment. (Of course it would be even nicer if this would not be
> necessary and you could just say "make install" and the whole shebang
> would end up where it wants to be.

I have added an example installation from scratch of Stylesheets, P5 and Roma 
modules.  I tested the steps on my own machine (but doing it to /tmp/tei )

See http://www.tei-c.org/Council/tcw06.xml

-James

From Syd_Bauman at Brown.edu  Fri Sep  9 16:43:12 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 9 Sep 2005 16:43:12 -0400
Subject: [tei-council] first crack at notes from this morning's call
Message-ID: <17185.62432.449625.228190@emt.wwp.brown.edu>

Notes are at
  http://www.tei-c.org/Council/tcm19.xml?style=printable

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Sep  9 19:18:47 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 10 Sep 2005 08:18:47 +0900
Subject: [tei-council] Re: tcw06.xml
In-Reply-To: <4321BE64.3060000@computing-services.oxford.ac.uk> (James
	Cummings's message of "Fri, 09 Sep 2005 17:55:00 +0100")
References: <ygfoe76pgh6.fsf@chwpb.local>
	<431DA6C2.7080306@computing-services.oxford.ac.uk>
	<ygfu0gvdooo.fsf@chwpb.local>
	<4321BE64.3060000@computing-services.oxford.ac.uk>
Message-ID: <ygfll25j0dk.fsf@chwpb.local>

James Cummings <James.Cummings at computing-services.oxford.ac.uk> writes:

> I have added an example installation from scratch of Stylesheets, P5
> and Roma modules.  I tested the steps on my own machine (but doing it
> to /tmp/tei )
>
> See http://www.tei-c.org/Council/tcw06.xml

Thanks. Following your exact instructions, on the last leg I get this:
<code>

perl -p -i -e 's/\(\%schemapattern;\)\?/%schemapattern;/' DTD/tagdocs.dtd
perl -p -i -e 's/\)\*\(/\)\*,\(/' DTD/textstructure.dtd
(cd DTD; ln -s tei.dtd tei2.dtd)
roma "--localsource=Source-driver.xml" --nodtd --noxsd --xsl=/tmp/tei/share/xml/tei/stylesheet/ --teiserver=http://tei.oucs.ox.ac.uk/Query/ p5odds.odd .
WARNING: Unrecognized option '--localsource=Source-driver.xml' ignored
For usage syntax issue /Users/chris/bin/roma --help
========= 2005-09-10 08:06:26 Roma starts, info:
Test for software: xmllint, xsltproc, trang, and perl
/sw/bin/xmllint
/sw/bin/xsltproc
/Users/chris/bin/trang
/usr/bin/perl
TEI database server: http://tei.oucs.ox.ac.uk/Query/
TEI stylesheet tree: /tmp/tei/share/xml/tei/stylesheet/

ERROR: stylesheet location /tmp/tei/share/xml/tei/stylesheet/ is not accessible.
This was a fatal error. 2005-09-10 08:06:27.N
make: *** [oddschema] Error 1

</code>

This is a bit odd (pardon the pun), since the stuff sits there under
/tmp/tei and just waits to be used:

  /tmp/tei/share/xml/tei/stylesheet:
  total used in directory 60 available 2647112
  drwxr-xr-x   12 root     staff         408 Sep 10 08:02 .
  drwxr-xr-x    3 root     wheel         102 Sep 10 08:02 ..
  drwxr-xr-x    9 root     staff         306 Sep 10 08:02 common
  drwxr-xr-x   15 root     staff         510 Sep 10 08:02 fo
  drwxr-xr-x   14 root     staff         476 Sep 10 08:02 html
  -rw-r--r--    1 root     staff       29941 Sep 10 08:02 i18n.xml
  drwxr-xr-x   14 root     staff         476 Sep 10 08:02 latex
  drwxr-xr-x   17 root     staff         578 Sep 10 08:02 odds
  drwxr-xr-x    4 root     staff         136 Sep 10 08:02 slides
  -rw-r--r--    1 root     staff        8306 Sep 10 08:02 tei.css
  -rw-r--r--    1 root     staff       10167 Sep 10 08:02 teic.css
  -rw-r--r--    1 root     staff        3370 Sep 10 08:02 teislides.css

Well, I think Sebastian will need to look on this once more.  

But anyhow, except for this little glitch, I am now able to get a
working P5 on my Mac OS powerbook following these instructions. Heureka!

However, the non-obvious pre-requisites (Saxon, perl, trang, jing,
xmllint) are not mentioned in the doc -- it would be convenient to
point people to the relevant locations.  

And before we announce this to TEI-L, it would be good if some brave
soul could try this out on a Windows machine...

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 Sep  9 19:28:26 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 10 Sep 2005 08:28:26 +0900
Subject: [tei-council] first crack at notes from this morning's call
In-Reply-To: <17185.62432.449625.228190@emt.wwp.brown.edu> (Syd Bauman's
	message of "Fri, 9 Sep 2005 16:43:12 -0400")
References: <17185.62432.449625.228190@emt.wwp.brown.edu>
Message-ID: <ygfhdctizxh.fsf@chwpb.local>

Syd Bauman <Syd_Bauman at Brown.edu> writes:

> Notes are at
>   http://www.tei-c.org/Council/tcm19.xml?style=printable

Thanks, that was quick.  

I forgot what I pointed out in the first section, so you might just
delete that part.  The deadline for that item seems a bit pessimistic
-- I would say at least those attending the class meeting should be
able to have a spinning P5 on their harddrive -- how about 2005-09-18?

The call yesterday came after a unusually long and busy week here, and
I appreciate your patience with my slightly unfocussed chairing.
Thank you all for your contributions and efforts.

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 Sep  9 19:57:44 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 10 Sep 2005 08:57:44 +0900
Subject: [tei-council] Re: tcw06.xml
In-Reply-To: <ygfll25j0dk.fsf@chwpb.local> (Christian Wittern's message of
	"Sat, 10 Sep 2005 08:18:47 +0900")
References: <ygfoe76pgh6.fsf@chwpb.local>
	<431DA6C2.7080306@computing-services.oxford.ac.uk>
	<ygfu0gvdooo.fsf@chwpb.local>
	<4321BE64.3060000@computing-services.oxford.ac.uk>
	<ygfll25j0dk.fsf@chwpb.local>
Message-ID: <ygfd5nhiykn.fsf@chwpb.local>

Christian Wittern <wittern at kanji.zinbun.kyoto-u.ac.jp> writes:

> roma "--localsource=Source-driver.xml" --nodtd --noxsd --xsl=/tmp/tei/share/xml/tei/stylesheet/ --teiserver=http://tei.oucs.ox.ac.uk/Query/ p5odds.odd .
> WARNING: Unrecognized option '--localsource=Source-driver.xml' ignored
> For usage syntax issue /Users/chris/bin/roma --help

(Slowly waking up) Looking at this more carefully, I see that it is
calling an old version of roma which happens to be on the path.  It
will probably be a good idea to explicitly use the roma that had been
installed in the previous step in $PREFIX/bin.  Again, this is an
issue with the software, not the documentation.  

This time it seems to run through without glitch. 

All the best and a nice weekend to everybody,

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 Sep 10 06:03:16 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 10 Sep 2005 11:03:16 +0100
Subject: [tei-council] Re: tcw06.xml
In-Reply-To: <ygfd5nhiykn.fsf@chwpb.local>
References: <ygfoe76pgh6.fsf@chwpb.local>	<431DA6C2.7080306@computing-services.oxford.ac.uk>	<ygfu0gvdooo.fsf@chwpb.local>	<4321BE64.3060000@computing-services.oxford.ac.uk>	<ygfll25j0dk.fsf@chwpb.local>
	<ygfd5nhiykn.fsf@chwpb.local>
Message-ID: <4322AF64.3000209@oucs.ox.ac.uk>

Christian Wittern wrote:

>
>calling an old version of roma which happens to be on the path.  It
>will probably be a good idea to explicitly use the roma that had been
>installed in the previous step in $PREFIX/bin.  Again, this is an
>issue with the software, not the documentation.  
>
>  
>
I'll change the P5/Exemplars/Makefile to call $PREFIX/bin/roma

-- 
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 Sep 10 06:08:50 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 10 Sep 2005 11:08:50 +0100
Subject: [tei-council] Re: tcw06.xml
In-Reply-To: <ygfll25j0dk.fsf@chwpb.local>
References: <ygfoe76pgh6.fsf@chwpb.local>	<431DA6C2.7080306@computing-services.oxford.ac.uk>	<ygfu0gvdooo.fsf@chwpb.local>	<4321BE64.3060000@computing-services.oxford.ac.uk>
	<ygfll25j0dk.fsf@chwpb.local>
Message-ID: <4322B0B2.6030708@oucs.ox.ac.uk>

Christian Wittern wrote:

>However, the non-obvious pre-requisites (Saxon, perl, trang, jing,
>xmllint) are not mentioned in the doc -- it would be convenient to
>point people to the relevant locations.  
>  
>
James, I guess this in your ball court.

Note that  saxon is not a prerequisite for most people,
since they won't have xsltdoc

>And before we announce this to TEI-L, it would be good if some brave
>soul could try this out on a Windows machine...
>  
>
I don't think its conceivable it will work. It is designed
to work in a Unix environment, and I don't have any idea
at all what may be needed to make the scripts work under Windows.

The schemas, xsl, etc would normally be installed from "compiled" form
anyway, and have no OS-dependencies. The "roma" script is written
in the shell language; it _could_be rewritten in Perl or Ruby or something
which might run under Windoze, but how many Windows people know
the existence of a command-line? Ideally, someone would rewrite it as pretty
GUI thang in Java, which would be quite easy. I don't have the skills
myself,
sadly.

-- 
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 Sep 10 14:12:04 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 10 Sep 2005 19:12:04 +0100
Subject: [tei-council] datatype issues (part 1)
Message-ID: <432321F4.2070405@computing-services.oxford.ac.uk>

Working through the datatype definitions, I have so far identified the 
following issues. Comments and corrections on these would be much 
appreciated, especially if it comes in the next few days.

1. <specDesc ident="tei.data.xxxx"/> will extract the <desc> from the 
referenced macroSpec. It would be nice also to be able to extract the 
<content> or <stringVal> part for display.

2. The definition of <macroSpec> allows it to contain multiple <content> 
or <stringVal> children. Why?

3. tei.data.certainty is defined as either an enumeration ("high", 
"low", "medium", "unknown")  or a reference to tei.data.probability, 
which is a real value between 0,1 or an integer between 0,100. I wonder 
if it wouldn't be less confusing to restrict the values for 
tei.data.certainty to the literal only, since any attribute for which we 
to allow either kind of value can do so by giving an alternation of 
datatypes (I think)

 4. tei.datatype.language is isomorphic with xsd:language: do we need it?

5. tei.data.regexp is used only  in two rather obscure places: do we 
need it? If we do, is the reference to appx. F of the xsd spec really 
the canonical place to define what sort of regexp we mean ?

6. tei.data.sex defines four alphabetic values (m f x u) which 
correspond to ISO 5218 numeric codes 1 2 0 and 9. Should we not rather 
use the ISO codes?

7. Furthermore, where (as with sex) the datatype is a closed 
enumeration, it makes sense to represent this in the macrospec as a 
<rng:choice> containing several <rng:value>s. But there is currently no 
scope to  provide a gloss for what each value means, since <valList> is 
not allowed within <macrospec>.

8. In earlier discussion I had proposed that tei.data.token should 
differ from rng:token in that the former should not permit included 
whitespace.  Thinking about this again, I think I might have been wrong: 
it might be less confusing to use <rng:token> directly wherever we want 
a "tei.data.token", thus allowing people to use XML whitespace 
normalization in attribute values in the same way as they can in 
content. If we do define tei.data.token as proposed (i.e. as an 
xsd:token with a facet saying that whitespace is not allowed), we should 
really give it a different name, or expect to spend the rest of eternity 
explaining why our usage differs from W3C and RNG's (ok, we were there 
first, but still). Same applies, mutatis mutandis, to tei.data.tokens: 
it might indeed be simpler to define that as xsd:token rather than as a 
list of our weird tei.data.tokens. On the other hand....

That's something to be going on with. I'm going to have a cup of tea AND 
A BISCUIT now.

Lou

From sebastian.rahtz at oucs.ox.ac.uk  Sat Sep 10 14:11:38 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 10 Sep 2005 19:11:38 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432321F4.2070405@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
Message-ID: <432321DA.3060703@oucs.ox.ac.uk>

Lou Burnard wrote:

> 1. <specDesc ident="tei.data.xxxx"/> will extract the <desc> from the
> referenced macroSpec. It would be nice also to be able to extract the
> <content> or <stringVal> part for display.

a detail.

>
> 2. The definition of <macroSpec> allows it to contain multiple
> <content> or <stringVal> children. Why?
>
an oversight? hard to conceive of a reason...

> 3. tei.data.certainty is defined as either an enumeration ("high",
> "low", "medium", "unknown")  or a reference to tei.data.probability,
> which is a real value between 0,1 or an integer between 0,100. I
> wonder if it wouldn't be less confusing to restrict the values for
> tei.data.certainty to the literal only, since any attribute for which
> we to allow either kind of value can do so by giving an alternation of
> datatypes (I think)

absolutely.  much clearer

>
> 4. tei.datatype.language is isomorphic with xsd:language: do we need it?

that applies to other cases, surely? for elegance, yes.

>
> 5. tei.data.regexp is used only  in two rather obscure places: do we
> need it? If we do, is the reference to appx. F of the xsd spec really
> the canonical place to define what sort of regexp we mean ?

pass. but sounds dumpable.

>
> 6. tei.data.sex defines four alphabetic values (m f x u) which
> correspond to ISO 5218 numeric codes 1 2 0 and 9. Should we not rather
> use the ISO codes?

it would be consistent of me to say "yes", so I will say "yes".  tho
pragmatically its a pain

>
> 7. Furthermore, where (as with sex) the datatype is a closed
> enumeration, it makes sense to represent this in the macrospec as a
> <rng:choice> containing several <rng:value>s. But there is currently
> no scope to  provide a gloss for what each value means, since
> <valList> is not allowed within <macrospec>.

allow valList within <macroSpec>, then.  important that it be glossable
- especially for that sex example!

>
> That's something to be going on with. I'm going to have a cup of tea
> AND A BISCUIT now.
>
i can smell the baked potatoes.

-- 
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  Sat Sep 10 22:29:27 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 11 Sep 2005 11:29:27 +0900
Subject: [tei-council] Re: tcw06.xml
In-Reply-To: <4322B0B2.6030708@oucs.ox.ac.uk> (Sebastian Rahtz's message of
	"Sat, 10 Sep 2005 11:08:50 +0100")
References: <ygfoe76pgh6.fsf@chwpb.local>
	<431DA6C2.7080306@computing-services.oxford.ac.uk>
	<ygfu0gvdooo.fsf@chwpb.local>
	<4321BE64.3060000@computing-services.oxford.ac.uk>
	<ygfll25j0dk.fsf@chwpb.local> <4322B0B2.6030708@oucs.ox.ac.uk>
Message-ID: <ygf3bocgwvs.fsf@chwpb.local>

Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> writes:

> Christian Wittern wrote:
>
>>However, the non-obvious pre-requisites (Saxon, perl, trang, jing,
>>xmllint) are not mentioned in the doc -- it would be convenient to
>>point people to the relevant locations.  
>>  
>>
> James, I guess this in your ball court.
>
> Note that  saxon is not a prerequisite for most people,
> since they won't have xsltdoc

Right, but then you need xsltproc, which is in the same package as
xmllint I guess.

>>And before we announce this to TEI-L, it would be good if some brave
>>soul could try this out on a Windows machine...
>>  
>>
> I don't think its conceivable it will work. It is designed
> to work in a Unix environment, and I don't have any idea
> at all what may be needed to make the scripts work under Windows.

Fine, so the way for Windows users to follow the TEI development would
be to stick to SF releases and submit the ODD files they produce to
the Roma webservice.  That sounds fair enough, but maybe we should
mention that in the CVS howto as well. 

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  Sat Sep 10 22:41:15 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 11 Sep 2005 11:41:15 +0900
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432321F4.2070405@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Sat, 10 Sep 2005 19:12:04 +0100")
References: <432321F4.2070405@computing-services.oxford.ac.uk>
Message-ID: <ygfy864fhro.fsf@chwpb.local>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> Working through the datatype definitions, I have so far identified the
> following issues. Comments and corrections on these would be much
> appreciated, especially if it comes in the next few days.
>
> 1. <specDesc ident="tei.data.xxxx"/> will extract the <desc> from the
>    referenced macroSpec. It would be nice also to be able to extract
>    the <content> or <stringVal> part for display.

In that case maybe <getTarget type="content|stringVal|desc" ident=""/>
would do the trick.

> 2. The definition of <macroSpec> allows it to contain multiple
>    <content> or <stringVal> children. Why?
>
> 3. tei.data.certainty is defined as either an enumeration ("high",
>    "low", "medium", "unknown")  or a reference to
>    tei.data.probability, which is a real value between 0,1 or an
>    integer between 0,100. I wonder if it wouldn't be less confusing to
>    restrict the values for tei.data.certainty to the literal only,
>    since any attribute for which we to allow either kind of value can
>    do so by giving an alternation of datatypes (I think)

This sounds reasonable to me.

>  4. tei.datatype.language is isomorphic with xsd:language: do we
>  need it?

I have asked this before.  We have to think how this fits in with
@xml:lang and <language>. 

> 5. tei.data.regexp is used only  in two rather obscure places: do we
>    need it? If we do, is the reference to appx. F of the xsd spec
>    really the canonical place to define what sort of regexp we mean
>    ?
>
> 6. tei.data.sex defines four alphabetic values (m f x u) which
>    correspond to ISO 5218 numeric codes 1 2 0 and 9. Should we not
>    rather use the ISO codes?

Hmm.  This raises the general question of how far we want to go in
pulling in the relevant standards and keeping our descriptions in
synch. Also, I would rather have some layer of human-readability here,
which could then under the hood be mapped to the relevant codes. mfxu
is just so much more intuitive than 1209.  The same issue came also up
with durations, P35Y vs. 35yrs.  At some point, we planned to have the
tei.* stuff provide this layer -- is this what Syd is the underlying
assumption that turned out to be not workable?  In that case, we have
to rethink the whole strategy, I am afraid. 

> 7. Furthermore, where (as with sex) the datatype is a closed
>    enumeration, it makes sense to represent this in the macrospec as a
>    <rng:choice> containing several <rng:value>s. But there is
>    currently no scope to  provide a gloss for what each value means,
>    since <valList> is not allowed within <macrospec>.

Maybe that should be changed then?  

>
> 8. In earlier discussion I had proposed that tei.data.token should
>    differ from rng:token in that the former should not permit included
>    whitespace.  Thinking about this again, I think I might have been
>    wrong: it might be less confusing to use <rng:token> directly
>    wherever we want a "tei.data.token", thus allowing people to use
>    XML whitespace normalization in attribute values in the same way as
>    they can in content. If we do define tei.data.token as proposed
>    (i.e. as an xsd:token with a facet saying that whitespace is not
>    allowed), we should really give it a different name, or expect to
>    spend the rest of eternity explaining why our usage differs from
>    W3C and RNG's (ok, we were there first, but still). Same applies,
>    mutatis mutandis, to tei.data.tokens: it might indeed be simpler to
>    define that as xsd:token rather than as a list of our weird
>    tei.data.tokens. On the other hand....

Yeah.  a token is a token is a token.  We won't be able to change
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 James.Cummings at computing-services.oxford.ac.uk  Sun Sep 11 06:28:28 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 11 Sep 2005 11:28:28 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <ygfy864fhro.fsf@chwpb.local>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
	<ygfy864fhro.fsf@chwpb.local>
Message-ID: <432406CC.8030106@computing-services.oxford.ac.uk>

Christian Wittern wrote:
>>6. tei.data.sex defines four alphabetic values (m f x u) which
>>   correspond to ISO 5218 numeric codes 1 2 0 and 9. Should we not
>>   rather use the ISO codes?
> 
> Hmm.  This raises the general question of how far we want to go in
> pulling in the relevant standards and keeping our descriptions in
> synch. Also, I would rather have some layer of human-readability here,
> which could then under the hood be mapped to the relevant codes. mfxu
> is just so much more intuitive than 1209.  The same issue came also up
> with durations, P35Y vs. 35yrs.  At some point, we planned to have the
> tei.* stuff provide this layer -- is this what Syd is the underlying
> assumption that turned out to be not workable?  In that case, we have
> to rethink the whole strategy, I am afraid. 

I was worried about this as well.  I like the idea of following the 
ISO standard, but 0 1 2 or 9 isn't very human readable to me.  (I'm 
assuming by the way that we are talking about ISO5218:2004 not 
5218:1977, does anyone know what the differences might be?)  Is there 
any benefit in allowing both or having one mapped to the other? Or, as 
Christian asks, is this what proved unworkable?

Trying to find out more about hte 2004 version, I discovered the UK 
government's recommended use of ISO 5218:2004 in their data standards 
catalogue.  I see that this version hasn't added values for 
transgendered individuals etc. as I thought it might have.  (They 
simply seem to suggest recording sex at registration and current sex.) 
http://www.govtalk.gov.uk/gdsc/html/frames/PersonGenderCurrent-2-0-Release.htm 

Is there a way to have someone put 'm' and it be understood in the 
schema as iso 5218's '1'?  (Or put 35yrs and it be understood as P35Y 
?)  Or does this just defeat the point of standards...

-James

From lou.burnard at computing-services.oxford.ac.uk  Sun Sep 11 07:58:50 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 11 Sep 2005 12:58:50 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432406CC.8030106@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
	<ygfy864fhro.fsf@chwpb.local>
	<432406CC.8030106@computing-services.oxford.ac.uk>
Message-ID: <43241BFA.9010703@computing-services.oxford.ac.uk>

Warning: this post contains unintended innuendos. Oooo mrs.

James Cummings wrote:

>
>
> Is there a way to have someone put 'm' and it be understood in the 
> schema as iso 5218's '1'?  (Or put 35yrs and it be understood as P35Y 
> ?)  Or does this just defeat the point of standards...
>
Yes, it defeats the point of the exercise. Think dates. You can say 
<date>wibble</date> if you like, but  once you say <date 
value="xxxx">wibble</date> your value MUST conform to what the relevant 
standard says it should be.

Similarly, with the (one or two) places where sex rears its head **as a 
coded attribute value**.  It's supposed to be a normalised value: ISO 
has normalized in this particular way. If you really want to retain the 
ability to say sex="some-arbitrary-code-i-just-invented" that's a 
different attribute. We could have both sex and ISOsex I suppose, but 
maybe that's going too far.

Look at it another way. I have a very fine tool which knows how to 
process ISO sex values when it sees them, iff they are expressed in a 
conformant way. I will not be best pleased if it now has to recognise 
some arbitrary other set of values as well: in fact, I probably won't 
bother at all. It's worth my while as a developer to fit in with ISO's 
whims: I don't know whether or not the TEI is that important yet. 

My argument is that iff we are going to go to the trouble of normalising 
attribute values, and there is a pre-existing international norm, then 
we really have to have much better reasons not to follow it than to say 
"it's not intuitive". Says who? If you're arabic or chinese, why is "m" 
more intuitive than "1"? (or "u" than "0")?

We could have much the same argument about whether we should replace the 
required values of the xsd "boolean" datatype ((which are "true" and 
"false") with "0" and "1" or "yes" and "no" ...

Lou

p.s. you could in your ODD application redefine tei.data.sex as a 
different set of values, of course, tho I think you're making life 
difficult for others if you do

From Syd_Bauman at Brown.edu  Sun Sep 11 10:06:56 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 11 Sep 2005 10:06:56 -0400
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432321F4.2070405@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
Message-ID: <17188.14848.10373.576601@emt.wwp.brown.edu>

> 1. <specDesc ident="tei.data.xxxx"/> will extract the <desc> from
> the referenced macroSpec. It would be nice also to be able to
> extract the <content> or <stringVal> part for display.

Yes, it would.

> 2. The definition of <macroSpec> allows it to contain multiple
> <content> or <stringVal> children. Why?

I can't come up with a good reason off the top of my head.

> 3. tei.data.certainty is defined as either an enumeration ("high",
> "low", "medium", "unknown") or a reference to tei.data.probability,
> which is a real value between 0,1 or an integer between 0,100. I
> wonder if it wouldn't be less confusing to restrict the values for
> tei.data.certainty to the literal only, since any attribute for
> which we to allow either kind of value can do so by giving an
> alternation of datatypes (I think)

I don't see that it is less confusing, but it may have the advantage
of making it easier on the user who wants to modify his ODDs so that
certainty is expressed only as one or the other. It makes no
difference to the constraint expressed in the end, so seems like a
fine idea to me.

>  4. tei.datatype.language is isomorphic with xsd:language: do we
>  need it?

We've discussed this at least twice in the past, and have concluded
that while tei.data.language is not entirely necessary, it would be a
good place to put information about how one uses xsd:language in TEI
-- that it is co-referenced with ident= of <language> (optionally if
it starts with "i-", 2 letters, or 3 letters, required if it starts
with "x-"). Otherwise this information won't show up in the reference
documentation at all except perhaps in the tagdoc for <language>
itself. 

> 5. tei.data.regexp is used only in two rather obscure places: do we
> need it? 

I don't think we need it, although again, it may be a useful place to
put an explanation. 

> If we do, is the reference to appx. F of the xsd spec really the
> canonical place to define what sort of regexp we mean ?

Are you asking
* whether we want to use W3C XSD regular expressions or would we do
  better to use some other regular expression language, or
* whether appendix F is the canonical place to refer to W3C XSD
  regular expressions?

I think the answer is "yes" to the former, but could be convinced
otherwise. The answer is a definitive "I don't know" to the latter.
(Especially since in the draft of XSD 1.1 it is in appendix H, not
F.) If we agree that this is the regexp language we want to use, I
will chase down the proper canonical reference to it (I'm presuming
there is one ... oh dear).

> 6. tei.data.sex defines four alphabetic values (m f x u) which
> correspond to ISO 5218 numeric codes 1 2 0 and 9. Should we not
> rather use the ISO codes?

Ooohhh ... really good question. Better conformance to external
standards, or more human-readable values? Tough choice in this case.
Part of me really wants to just use
  "not known" | "male" | "female" | "not specified"
and avoid the question.

> 7. Furthermore, where (as with sex) the datatype is a closed
> enumeration, it makes sense to represent this in the macrospec as a
> <rng:choice> containing several <rng:value>s. But there is
> currently no scope to provide a gloss for what each value means,
> since <valList> is not allowed within <macrospec>.

Errr... I'm not sure I internalized that bit of information (that
<valList> is not permitted within <macroSpec>) when I thought about
these. I know META has been disbanded, but this really seems like an
issue that should be looked at and quite possibly changed. <valList>s
are really the right thing for the job, here.

> 8. In earlier discussion I had proposed that tei.data.token should
> differ from rng:token in that the former should not permit included
> whitespace. Thinking about this again, I think I might have been
> wrong: it might be less confusing to use <rng:token> directly
> wherever we want a "tei.data.token", thus allowing people to use
> XML whitespace normalization in attribute values in the same way as
> they can in content.

There is no XML whitespace normalization of any content in TEI, yet,
is there? When we're done straightening out the classes and stuff,
there may be one or two obscure places where it is useful.

> If we do define tei.data.token as proposed (i.e. as an xsd:token
> with a facet saying that whitespace is not allowed), we should
> really give it a different name, or expect to spend the rest of
> eternity explaining why our usage differs from W3C and RNG's (ok,
> we were there first, but still).

I think a "no internal whitespace" restriction is a really good thing
to have[1]. But I think you are absolutely right, we should change
the name. It's not our fault that W3C and RelaxNG deliberately use
the term "token" in a manner that is counter-intuitive to end users
(although perhaps makes sense to those writing validators).
Nonetheless, if we use the same term in the more normal way, we are
dooming users to even more confusion. Problem is, it's hard to come
up with an alternative. How about tei.data.term?

> Same applies, mutatis mutandis, to tei.data.tokens: it might indeed
> be simpler to define that as xsd:token rather than as a list of our
> weird tei.data.tokens. On the other hand....

I don't think it matters much. I think it is useful to have the
parallelism between tei.data.pointer(s) and tei.data.token(s), and
whatever others may come up. But since they'll provide the same
constraint, it's not very important.

Note
----
[1] Note that I said "internal". Important detail: because W3C Schema
    regular expressions are implicitly anchored,
       <foo type="
       bar"/>
    is not permitted using current definition of tei.data.token.
    Since
      <foo type=
       "bar"/>
    is, of course, permitted, I don't see this as a problem at all,
    and even think it makes thinking about the attribute easier. ("No
    whitespace" vs "no whitespace, except leading and trailing which
    will get trimmed off before comparison for validation") I think
    the restriction on no internal whitespace is important; I think
    the restriction on leading & trailing is a nicety worth having.

From Laurent.Romary at loria.fr  Sun Sep 11 11:36:30 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Sun, 11 Sep 2005 17:36:30 +0200
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <17188.14848.10373.576601@emt.wwp.brown.edu>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
	<17188.14848.10373.576601@emt.wwp.brown.edu>
Message-ID: <432c6d11beae57e26e676af90eb58055@loria.fr>

Le 11 sept. 05, ? 16:06, Syd Bauman a ?crit :

>
>> 6. tei.data.sex defines four alphabetic values (m f x u) which
>> correspond to ISO 5218 numeric codes 1 2 0 and 9. Should we not
>> rather use the ISO codes?
>>

There is also the possibility that we keep the TEI values for our users 
and use <equiv> to mark the link with ISO values.
Laurent

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep 11 15:27:12 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 11 Sep 2005 20:27:12 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432c6d11beae57e26e676af90eb58055@loria.fr>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>
	<432c6d11beae57e26e676af90eb58055@loria.fr>
Message-ID: <43248510.70009@oucs.ox.ac.uk>

Laurent Romary wrote:

>
> There is also the possibility that we keep the TEI values for our
> users and use <equiv> to mark the link with ISO values.
> Laurent
>
Why set the TEI up as a standards-making body in areas
for which standards already exist? As Lou said, the point
of @sex is to produce a standardized form, not something
that is readable for humans.

-- 
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 Sep 11 16:19:59 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 11 Sep 2005 21:19:59 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432406CC.8030106@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<ygfy864fhro.fsf@chwpb.local>
	<432406CC.8030106@computing-services.oxford.ac.uk>
Message-ID: <4324916F.1070001@oucs.ox.ac.uk>

James Cummings wrote:

>
> Is there a way to have someone put 'm' and it be understood in the
> schema as iso 5218's '1'?  (Or put 35yrs and it be understood as P35Y
> ?)  Or does this just defeat the point of standards...

if you want to make an editing schema which accepts "m" and "f", and
then run a transformation to
canonical form, feel free....

you can't have your cake and eat 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 Sep 11 16:21:18 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 11 Sep 2005 21:21:18 +0100
Subject: [tei-council] Re: tcw06.xml
In-Reply-To: <ygf3bocgwvs.fsf@chwpb.local>
References: <ygfoe76pgh6.fsf@chwpb.local>	<431DA6C2.7080306@computing-services.oxford.ac.uk>	<ygfu0gvdooo.fsf@chwpb.local>	<4321BE64.3060000@computing-services.oxford.ac.uk>	<ygfll25j0dk.fsf@chwpb.local>
	<4322B0B2.6030708@oucs.ox.ac.uk> <ygf3bocgwvs.fsf@chwpb.local>
Message-ID: <432491BE.3060906@oucs.ox.ac.uk>

>Fine, so the way for Windows users to follow the TEI development would
>be to stick to SF releases and submit the ODD files they produce to
>the Roma webservice. 
>
I don't have a better answer, I am afraid

-- 
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 Sep 11 16:25:02 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 11 Sep 2005 21:25:02 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <ygfy864fhro.fsf@chwpb.local>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
	<ygfy864fhro.fsf@chwpb.local>
Message-ID: <4324929E.9000501@oucs.ox.ac.uk>

Christian Wittern wrote:

>
>Also, I would rather have some layer of human-readability here,
>which could then under the hood be mapped to the relevant codes. mfxu
>is just so much more intuitive than 1209.  The same issue came also up
>with durations, P35Y vs. 35yrs.  At some point, we planned to have the
>tei.* stuff provide this layer -- is this what Syd is the underlying
>assumption that turned out to be not workable?  In that case, we have
>to rethink the whole strategy, I am afraid. 
>  
>
The thing that Syd wanted, which Lou and I claim is unworkable,
is to have separate enumerated lists for each element which
shares a global attribute. So no, this isn't it.

You phrase "under the hood be mapped to the relevant codes"
sounds nice, but there is no hood under which this can happen!
If you want your archival XML to have ISO values for sex, but your
editors seem "mfu", then you have to use an alternate authoring DTD,
and impose a transformation in your workflow.

-- 
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 Sep 11 16:26:33 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 11 Sep 2005 21:26:33 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43241BFA.9010703@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<ygfy864fhro.fsf@chwpb.local>	<432406CC.8030106@computing-services.oxford.ac.uk>
	<43241BFA.9010703@computing-services.oxford.ac.uk>
Message-ID: <432492F9.8020801@oucs.ox.ac.uk>

Lou Burnard wrote:

>
> My argument is that iff we are going to go to the trouble of
> normalising attribute values, and there is a pre-existing
> international norm, then we really have to have much better reasons
> not to follow it than to say "it's not intuitive".

my sentiments exactly.....

-- 
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 Sep 11 16:33:48 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 11 Sep 2005 21:33:48 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432492F9.8020801@oucs.ox.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<ygfy864fhro.fsf@chwpb.local>	<432406CC.8030106@computing-services.oxford.ac.uk>	<43241BFA.9010703@computing-services.oxford.ac.uk>
	<432492F9.8020801@oucs.ox.ac.uk>
Message-ID: <432494AC.2090605@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> Lou Burnard wrote:
> 
> 
>>My argument is that iff we are going to go to the trouble of
>>normalising attribute values, and there is a pre-existing
>>international norm, then we really have to have much better reasons
>>not to follow it than to say "it's not intuitive".
> 
> my sentiments exactly.....

Yup.  I'm convinced.  Ok, so we have sex="1" and value="P36Y"?  I 
don't mind having a local modification have male/female/unknown and 
transform it to 1/2/0 if I ever encounter it as a problem.  The 
benefit of having attribute values being international standards does 
seem to outweigh any other benefit of knowing at a glance what that 
value means.  I'm assuming that when slightly cryptic ISO standards 
like this are use for attribute values that there will be a 
(simplified) discussion of it in the guidelines and perhaps a pointer 
to further information on it?

-James

From lou.burnard at computing-services.oxford.ac.uk  Sun Sep 11 19:22:26 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 12 Sep 2005 00:22:26 +0100
Subject: [tei-council] datatypes
Message-ID: <4324BC32.2070906@computing-services.oxford.ac.uk>

A *very preliminary* list of datatypes and their declarations, bearing 
at least some resemblance to the way they will eventually appear in the 
revised chapter ST is now available at http://www.tei-c.org/Drafts/DTYPES/

Please note that I am still fiddling with the ODDs from which this HTML 
is generated and don't intend to check them into source forge until 
we're able to generate plausible DTD and RNG declarations from them. 
Also please note that I haven't yet acted on the suggestions made in 
response to yesterday's discussion on the list -- so keep those comments 
coming in...

Lou

From pwillett at umich.edu  Sun Sep 11 21:15:18 2005
From: pwillett at umich.edu (Perry Willett)
Date: Sun, 11 Sep 2005 21:15:18 -0400 (EDT)
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <432494AC.2090605@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
	<ygfy864fhro.fsf@chwpb.local>
	<432406CC.8030106@computing-services.oxford.ac.uk>
	<43241BFA.9010703@computing-services.oxford.ac.uk>
	<432492F9.8020801@oucs.ox.ac.uk>
	<432494AC.2090605@computing-services.oxford.ac.uk>
Message-ID: <Pine.LNX.4.63.0509112113350.24140@arkanoid.gpcc.itd.umich.edu>

I'm all for following the ISO standards on this too. People
will get used to the values fairly quickly as they use them.

Perry Willett
University of Michigan
pwillett at umich.edu

On Sun, 11 Sep 2005, James Cummings wrote:

> Sebastian Rahtz wrote:
>> Lou Burnard wrote:
>> 
>> 
>>> My argument is that iff we are going to go to the trouble of
>>> normalising attribute values, and there is a pre-existing
>>> international norm, then we really have to have much better reasons
>>> not to follow it than to say "it's not intuitive".
>> 
>> my sentiments exactly.....
>
> Yup.  I'm convinced.  Ok, so we have sex="1" and value="P36Y"?  I don't mind 
> having a local modification have male/female/unknown and transform it to 
> 1/2/0 if I ever encounter it as a problem.  The benefit of having attribute 
> values being international standards does seem to outweigh any other benefit 
> of knowing at a glance what that value means.  I'm assuming that when 
> slightly cryptic ISO standards like this are use for attribute values that 
> there will be a (simplified) discussion of it in the guidelines and perhaps a 
> pointer to further information on it?
>
> -James
> _______________________________________________
> 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  Sun Sep 11 22:55:59 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 11 Sep 2005 22:55:59 -0400
Subject: [tei-council] first crack at notes from this morning's call
In-Reply-To: <ygfhdctizxh.fsf@chwpb.local>
References: <17185.62432.449625.228190@emt.wwp.brown.edu>
	<ygfhdctizxh.fsf@chwpb.local>
Message-ID: <17188.60991.259112.162452@emt.wwp.brown.edu>

> I forgot what I pointed out in the first section, so you might just
> delete that part. The deadline for that item seems a bit
> pessimistic -- I would say at least those attending the class
> meeting should be able to have a spinning P5 on their harddrive --
> how about 2005-09-18?

done.

From Laurent.Romary at loria.fr  Mon Sep 12 01:09:31 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Mon, 12 Sep 2005 07:09:31 +0200
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43248510.70009@oucs.ox.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>
	<432c6d11beae57e26e676af90eb58055@loria.fr>
	<43248510.70009@oucs.ox.ac.uk>
Message-ID: <6c37a181af58aacf8ef886c861d7c02a@loria.fr>

There are cases where we act as an interface towards communities which 
may not like to manipulate formats like numbers for sex. If our users 
are not deeply used tu m, f etc. then of course we can just move to ISO 
codes.

Le 11 sept. 05, ? 21:27, Sebastian Rahtz a ?crit :

> Laurent Romary wrote:
>
>>
>> There is also the possibility that we keep the TEI values for our
>> users and use <equiv> to mark the link with ISO values.
>> Laurent
>>
> Why set the TEI up as a standards-making body in areas
> for which standards already exist? As Lou said, the point
> of @sex is to produce a standardized form, not something
> that is readable for humans.
>
>
>
> -- 
> 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 Sep 12 14:28:51 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 12 Sep 2005 14:28:51 -0400
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <6c37a181af58aacf8ef886c861d7c02a@loria.fr>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
	<17188.14848.10373.576601@emt.wwp.brown.edu>
	<432c6d11beae57e26e676af90eb58055@loria.fr>
	<43248510.70009@oucs.ox.ac.uk>
	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>
Message-ID: <17189.51427.518938.47525@emt.wwp.brown.edu>

For the record, I'm leaning towards ISO numeric codes for sex=.

However, the argument in favor of more memorable codes is quite a
strong one.

LB> Yes, it defeats the point of the exercise. Think dates. You can
LB> say <date>wibble</date> if you like, but once you say <date
LB> value="xxxx">wibble</date> your value MUST conform to what the
LB> relevant standard says it should be.

Yes indeed, which is possibly a bit of a problem for some TEI
users, as they may well be interested in calendars other than the
Gregorian, which is all that ISO 8601 purports to represent.
(However, lots of people think it's OK to use it for proleptic
Gregorian, too.)

LB> Similarly, with the (one or two) places where sex rears its head
LB> **as a coded attribute value**. It's supposed to be a normalised
LB> value: ISO has normalized in this particular way. If you really
LB> want to retain the ability to say sex="some-arbitrary-code-i-
LB> just-invented" that's a different attribute. We could have both
LB> sex and ISOsex I suppose, but maybe that's going too far.

This seems like circular reasoning. The reason sex= is supposed to be
a normalized value is because the TEI has decided it would be a
useful thing. If TEI (i.e., us, right here, right now) decide that it
is not so useful to normalize against ISO 5218, that's fine. We can
normalize against our own definitions of "m", "f", "u", and "x"
(although some might call that 'regularization', since the
definition, although external to the instance, is not external to the
TEI).

I'm not aware that anybody has recommended arbitrary codes get made
up by the user.

LB> My argument is that iff we are going to go to the trouble of
LB> normalising attribute values, and there is a pre-existing
LB> international norm, then we really have to have much better
LB> reasons not to follow it than to say "it's not intuitive".

I'm inclined to agree. "It's not intuitive" is probably not a
sufficient argument on its own.

LB> Says who? If you're arabic or chinese, why is "m" more intuitive
LB> than "1"? (or "u" than "0")?

That's not really fair, in that if you're Arabic or Chinese you'll
either be dealing with an equally non-intuitive element name (e.g.
"person") and attribute name (i.e. "sex"), or you will have
internationalized your schema, including these values.

LB> We could have much the same argument about whether we should
LB> replace the required values of the xsd "boolean" datatype ((which
LB> are "true" and "false") with "0" and "1" or "yes" and "no" ...

Well, yes, but there the XSD values are just as intuitive, so there's
really no argument at all. (And actually, since xsd:boolean takes the
lexical values "true", "false", "1", and "0", if I were to do
anything to change it I'd probably want to restrict it so only one
pair of opposites was permitted.)

LB> p.s. you could in your ODD application redefine tei.data.sex as a
LB> different set of values, of course, ...

Absolutely. Which makes me think this isn't really all that
important.

JC> I'm assuming that when slightly cryptic ISO standards like this
JC> are use for attribute values that there will be a (simplified)
JC> discussion of it in the guidelines and perhaps a pointer to
JC> further information on it?

I think that's a requirement.

SR> If you want your archival XML to have ISO values for sex, but
SR> your editors seem "mfu", then you have to use an alternate
SR> authoring DTD, and impose a transformation in your workflow.

In many many cases this is going to be a really good idea, for lots
of less sexy reasons than this one.

SB> Part of me really wants to just use
SB>   "not known" | "male" | "female" | "not specified"
SB> and avoid the question.

BTW, those are the values that 0, 1, 2, and 9 map to in 5218. I.e.,
use the entire normalized value, not the look-up code to it.

LR> There is also the possibility that we keep the TEI values for our
LR> users and use <equiv> to mark the link with ISO values.

SR> Why set the TEI up as a standards-making body in areas for which
SR> standards already exist? As Lou said, the point of @sex is to
SR> produce a standardized form, not something that is readable for
SR> humans.

That seems like it might be a bit of a slippery slope. I mean, one
of the main selling points of XML is that it is human readable. If a
user wanted to store this information in a manner she could never
directly read, she could use a proprietary database instead.
(Although I readily admit that in this particular case the values
aren't really not human readable, rather they just require the user
to take an extra step to ascertain meaning; a step they might have to
take in cases of "u" and "x", anyway.)

LR> There are cases where we act as an interface towards communities
LR> which may not like to manipulate formats like numbers for sex.

Right.

From James.Cummings at computing-services.oxford.ac.uk  Mon Sep 12 14:43:52 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Mon, 12 Sep 2005 19:43:52 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <17189.51427.518938.47525@emt.wwp.brown.edu>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>
	<17189.51427.518938.47525@emt.wwp.brown.edu>
Message-ID: <4325CC68.1050400@computing-services.oxford.ac.uk>

Syd Bauman wrote:
> LB> Yes, it defeats the point of the exercise. Think dates. You can
> LB> say <date>wibble</date> if you like, but once you say <date
> LB> value="xxxx">wibble</date> your value MUST conform to what the
> LB> relevant standard says it should be.
> 
> Yes indeed, which is possibly a bit of a problem for some TEI
> users, as they may well be interested in calendars other than the
> Gregorian, which is all that ISO 8601 purports to represent.
> (However, lots of people think it's OK to use it for proleptic
> Gregorian, too.)

Has anyone come up with a standard which represents any possible time, 
duration, periods, in all known calendars? Or is there a time/date 
standard that is in any way better ISO 8601?

One of the other differences I notice with ISO8601 and your patterns 
is that tei.duration current copes with things at a smaller 
granularity than 1 second and ISO 8601 doesn't.

-James

From Syd_Bauman at Brown.edu  Mon Sep 12 14:55:50 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 12 Sep 2005 14:55:50 -0400
Subject: [tei-council] datatypes
In-Reply-To: <4324BC32.2070906@computing-services.oxford.ac.uk>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
Message-ID: <17189.53046.97139.966870@emt.wwp.brown.edu>

> A *very preliminary* list of datatypes and their declarations,
> bearing at least some resemblance to the way they will eventually
> appear in the revised chapter ST is now available at
> http://www.tei-c.org/Drafts/DTYPES/
> 
> Please note that I am still fiddling with the ODDs from which this
> HTML is generated and don't intend to check them into source forge
> until we're able to generate plausible DTD and RNG declarations
> from them. Also please note that I haven't yet acted on the
> suggestions made in response to yesterday's discussion on the list
> -- so keep those comments coming in...

I don't suppose you want to put these ODDs somewhere I can edit them?
The workflow of my changing EDW 90, and your copying stuff from there
to these ODDs seems a bit silly.

From sebastian.rahtz at oucs.ox.ac.uk  Mon Sep 12 15:21:21 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 12 Sep 2005 20:21:21 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <17189.51427.518938.47525@emt.wwp.brown.edu>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>
	<17189.51427.518938.47525@emt.wwp.brown.edu>
Message-ID: <4325D531.6070308@oucs.ox.ac.uk>

Syd Bauman wrote:

>LB> Says who? If you're arabic or chinese, why is "m" more intuitive
>LB> than "1"? (or "u" than "0")?
>
>That's not really fair, in that if you're Arabic or Chinese you'll
>either be dealing with an equally non-intuitive element name (e.g.
>"person") and attribute name (i.e. "sex"), or you will have
>internationalized your schema, including these values.
>  
>
you can internationalize the attribute name and description
to help the Arabic encoder, and easily get back to canonical TEI,
with no lossiness. If you start monkeying with allowed values,
your task immediately becomes noticeably harder (in this case,
not _that_ hard, but no longer commodity).

>SR> If you want your archival XML to have ISO values for sex, but
>SR> your editors seem "mfu", then you have to use an alternate
>SR> authoring DTD, and impose a transformation in your workflow.
>
>In many many cases this is going to be a really good idea, for lots
>of less sexy reasons than this one.
>  
>
hopefully, the talk by self and G Bina in Sofia will discuss
this sort of thing

>That seems like it might be a bit of a slippery slope. I mean, one
>of the main selling points of XML is that it is human readable.
>
hmm. the thing about XML is that its text, and so
easily read by any application, including "cat".
That's as far as I would go. Can anyone claim <respStmt>
is "human-readable", in that sense that "sex='m'" is "readable"?

-- 
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 Sep 12 17:55:52 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 12 Sep 2005 22:55:52 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <17189.51427.518938.47525@emt.wwp.brown.edu>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>
	<17189.51427.518938.47525@emt.wwp.brown.edu>
Message-ID: <4325F968.6090002@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>For the record, I'm leaning towards ISO numeric codes for sex=.
>  
>
OK, so far the consensus appears to be to grin and bear it and go with 
ISO codes. I will give it another 24 hours, and then change the tagdoc 
accordingly.

At the same time and for much the same reasons, I'm proposing to change 
the definition for tei.data.duration to be equivalent to xsd:duration 
only. I can't see any reason not to go with the ISO defined way of 
indicating duration. The only reason not to would be if you wanted to 
use an attribute defined as tei.data.duration to record durations in 
other units (e.g. microseconds, or centuries). Even assuming  anyone 
came up with a convincing use case the way to do that would be to define 
a different attribute, I think.

From lou.burnard at computing-services.oxford.ac.uk  Tue Sep 13 05:49:19 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 13 Sep 2005 10:49:19 +0100
Subject: [tei-council] datatype issues (part 1) continued,,,
In-Reply-To: <17188.14848.10373.576601@emt.wwp.brown.edu>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
	<17188.14848.10373.576601@emt.wwp.brown.edu>
Message-ID: <4326A09F.1000808@oucs.ox.ac.uk>

Syd Bauman wrote:

>>5. tei.data.regexp is used only in two rather obscure places: do we
>>need it? 
> 
> 
> I don't think we need it, although again, it may be a useful place to
> put an explanation. 
> 

I propose to change this to tei.data.formula which maps to xsd:token

The only places it is used at present is for attributes like metDecl 
which have as their value a string of gobbledegook in some special 
syntax defined by the TEI. This seems a useful category of information. 
Calling it regexp suggests to me that it is a (Unix style) regular 
expression, which it isn't necessarily -- though obviously one could 
define a reg exp that matched any such formula!

Whether or not an attribute the value of which *was* a Unix regular 
expression should use this datatype is a bridge I would prefer to cross 
when we actually have such an attribute. I would have thought it would 
be much better as content anyway.

> 
>>8. In earlier discussion I had proposed that tei.data.token should
>>differ from rng:token in that the former should not permit included
>>whitespace. Thinking about this again, I think I might have been
>>wrong: it might be less confusing to use <rng:token> directly
>>wherever we want a "tei.data.token", thus allowing people to use
>>XML whitespace normalization in attribute values in the same way as
>>they can in content.
> 
> 
> There is no XML whitespace normalization of any content in TEI, yet,
> is there? When we're done straightening out the classes and stuff,
> there may be one or two obscure places where it is useful.
> 
> 
>>If we do define tei.data.token as proposed (i.e. as an xsd:token
>>with a facet saying that whitespace is not allowed), we should
>>really give it a different name, or expect to spend the rest of
>>eternity explaining why our usage differs from W3C and RNG's (ok,
>>we were there first, but still).
> 
> 
> I think a "no internal whitespace" restriction is a really good thing
> to have[1]. But I think you are absolutely right, we should change
> the name. It's not our fault that W3C and RelaxNG deliberately use
> the term "token" in a manner that is counter-intuitive to end users
> (although perhaps makes sense to those writing validators).
> Nonetheless, if we use the same term in the more normal way, we are
> dooming users to even more confusion. Problem is, it's hard to come
> up with an alternative. How about tei.data.term?
> 

Not bad, but we do use "term" rather a lot in slightly different ways 
elsewhere in the Guidelines, and, crucially, in my book a "term" is 
taken from a human language not an artificial one. So my proposal is now

1. rename tei.data.token as tei.data.ident, mapping it to NMTOKEN.
2. tei.data.tokens is a list of tei.data.ident
3. tei.data.enumerated is a ref to a tei.data.ident
4. tei.data.key is mapped to NCName

I hesitated a long time over NMTOKEN and NCName. The former allows 
hyphens but not underscore; the latter allows underscore but not hyphen. 
Syd's proposed pattern allows either and also comma. I am open to 
persuasion that both tei.data.key and tei.data.ident should have the 
same mapping; less to defining something which is not either NMTOKEN or 
NCName.

The distinction between tei.data.key and tei.data.ident is that the 
latter need not actually map onto anything anywhere, it's just a name.
So in order of ascending tightness of constraint, we have

tei.data.enumerated : the value is defined by a valList (type=closed)
tei.data.code : the value is defined by a pointer to something which 
must exist
tei.data.key : the value is defined by an enumeration elsewhere e.g. a 
database key
tei.data.ident : the value is a name or identifier of some kind but not 
necessarily enumerated or enumeratable

Does that make sense?

From sebastian.rahtz at oucs.ox.ac.uk  Tue Sep 13 07:02:15 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 13 Sep 2005 12:02:15 +0100
Subject: [tei-council] datatype issues (part 1) continued,,,
In-Reply-To: <4326A09F.1000808@oucs.ox.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>
	<4326A09F.1000808@oucs.ox.ac.uk>
Message-ID: <4326B1B7.7030008@oucs.ox.ac.uk>

Lou Burnard wrote:

>
> I propose to change this to tei.data.formula which maps to xsd:token

not sure I like the word "formula". that seems too precise to me.
tei.data. notation?

>
> Not bad, but we do use "term" rather a lot in slightly different ways 
> elsewhere in the Guidelines, and, crucially, in my book a "term" is 
> taken from a human language not an artificial one. So my proposal is now
>
> 1. rename tei.data.token as tei.data.ident, mapping it to NMTOKEN.
> 2. tei.data.tokens is a list of tei.data.ident
> 3. tei.data.enumerated is a ref to a tei.data.ident
> 4. tei.data.key is mapped to NCName

"ident" or "name"? and tei.data.enumerated is probably a ref to xsd:token

>
> tei.data.enumerated : the value is defined by a valList (type=closed)

only sometimes. this is still messy

> tei.data.code : the value is defined by a pointer to something which 
> must exist

ok

> tei.data.key : the value is defined by an enumeration elsewhere e.g. a 
> database key

ok

> tei.data.ident : the value is a name or identifier of some kind but 
> not necessarily enumerated or enumeratable

ok

but tei.data.key is not an NMtoken but a simple string

sebastian

From lou.burnard at computing-services.oxford.ac.uk  Tue Sep 13 10:10:35 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 13 Sep 2005 15:10:35 +0100
Subject: [tei-council] And now for something completely different
Message-ID: <4326DDDB.4050805@oucs.ox.ac.uk>

This note is NOT about datatypes.

A colleague is developing a RNG specification for a linguistic 
application, and wants to embed within it the TEI-ISO module. From his 
point of view, the best way to do this is to write his own schema and to 
reference the module in which <fvLib>, <fs> etc. are defined.

His question is: what URL should he use to reference the current draft 
for the RNG or RNC schema generated forthis module?

I told him to download the whole of the latest release from SF and link 
to a local copy, while we sort this question out....

From sebastian.rahtz at oucs.ox.ac.uk  Wed Sep 14 07:35:37 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 14 Sep 2005 12:35:37 +0100
Subject: [tei-council] And now for something completely different
In-Reply-To: <4326DDDB.4050805@oucs.ox.ac.uk>
References: <4326DDDB.4050805@oucs.ox.ac.uk>
Message-ID: <43280B09.5040506@oucs.ox.ac.uk>

Lou Burnard wrote:

>
> His question is: what URL should he use to reference the current draft 
> for the RNG or RNC schema generated forthis module?

http://www.tei-c.org/release/xml/tei/schema/relaxng/iso-fs.rng

sebastian

From lou.burnard at computing-services.oxford.ac.uk  Wed Sep 14 17:40:33 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 14 Sep 2005 22:40:33 +0100
Subject: [tei-council] Datatypes, part 2
Message-ID: <432898D1.7000602@computing-services.oxford.ac.uk>

I have now updated the draft ODDs defining datatypes and regenerated the 
HTML draft describing them. This draft, which will eventually appear as 
a subsection of the new ST, still has a lot of holes (in particular 
there are no examples) but it is intended to be a fairly quick and 
complete overview of the new datatype system to which we hope to move 
shortly.  I've made several changes on the basis of comments made so far 
on this list: please respond quickly if you think it is still seriously 
wrong, as the next step will be to start allocating existing attributes 
to the new datatypes, a lengthy and pernickety task which we don't want 
to do more than once! While waiting for your comments, I will be 
drafting a little test file to check that validators do actually 
validate these datatypes in the way the books say they should...

Lou

From lou.burnard at computing-services.oxford.ac.uk  Wed Sep 14 17:44:27 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 14 Sep 2005 22:44:27 +0100
Subject: [tei-council] datatypes part 2 contd
Message-ID: <432899BB.1090900@computing-services.oxford.ac.uk>

p.s.

For those with short memories or full mailboxes, that HTML draft is at 
http://www.tei-c.org/Drafts/DTYPES/

The tagdocs have been checked into  cvs under the P5/Source/ST tree -- 
but not yet the prose.

From lou.burnard at computing-services.oxford.ac.uk  Thu Sep 15 16:50:41 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 15 Sep 2005 21:50:41 +0100
Subject: [tei-council] tei.data.blah
Message-ID: <4329DEA1.2050903@computing-services.oxford.ac.uk>

I have just noticed that using tei.data.blah as the name for the 
datatype "blah", as recommended in edw90,  gives a tiny opporunity for 
confusion if we keep the convention that "tei.blah" is the name for the 
*class* "blah".... especially as we have a class called "data"!

Just thought I'd mention it....

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep 15 17:02:38 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 15 Sep 2005 22:02:38 +0100
Subject: [tei-council] tei.data.blah
In-Reply-To: <4329DEA1.2050903@computing-services.oxford.ac.uk>
References: <4329DEA1.2050903@computing-services.oxford.ac.uk>
Message-ID: <4329E16E.4060106@oucs.ox.ac.uk>

Lou Burnard wrote:

> I have just noticed that using tei.data.blah as the name for the
> datatype "blah", as recommended in edw90,  gives a tiny opporunity for
> confusion if we keep the convention that "tei.blah" is the name for
> the *class* "blah".... especially as we have a class called "data"!
>
> Just thought I'd mention it....
>
so call them macro.data.blah

-- 
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 Sep 15 19:36:49 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 15 Sep 2005 19:36:49 -0400
Subject: [tei-council] back; update
Message-ID: <17194.1425.544565.770039@emt.wwp.brown.edu>

Whoooeee! Been out of touch for a bit there, sorry. I had to perform
a complete system change of my desktop system at work since I last
posted.[1] In the interim I have been slowly but steadily re-working
the attributes. I expect to be finished sometime over the weekend,
and will post then.

Notes
-----
[1] Sebastian might be pleased to hear the new one is an Intel-based
    Debian system, as opposed to a PPC based Debian system.[2]
    However, we had worked out all the differences -- I had been
    building P5 on that system with no trouble for some time.
[2] But don't worry, James, my laptop still has a PPC based Debian
    system on which to test your HOWTOs. :-)

From lou.burnard at computing-services.oxford.ac.uk  Sat Sep 17 19:14:27 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 18 Sep 2005 00:14:27 +0100
Subject: [tei-council] Datatypes.... continued
Message-ID: <432CA353.9000105@computing-services.oxford.ac.uk>

I haven't heard any squawks of protest, so assuming people are 
reasonably happy with the datatypes so far proposed, I've now checked  
through the list in Syd's table for discrepancies, or things I've 
overlooked. The executive summary is that I think we need just one new 
datatype "tei.data.count", which I will add to the list. Otherwise, 
we're ready to move to implementation, assuming none of the following 
tidyup is controversial.

1. add at place 
   addSpan at place
   metDecl at type    
           -->  tei.data.enumerated

2. tei.pointerGroup at domains  
          -->  tei.data.pointers

3. schemaSpec at start
    specDesc at atts   
         --> tei.data.names

4. date at precision
       --> tei.data.certainty

5. tei.datable at dateAttrib
       --> tei.data.enumerated

6. locus at scheme
       --> tei.data.name

7. fragmentPattern at pat
      --> tei.data.notation

8. schemaSpec at namespace
    elementSpec at ns (why isnt it "namespace" btw?)
       --> these could be xsd:uri as proposed, or tei.data.pointer, but 
maybe since they have to be
             real namespace names (i.e. "#foo" won't do) maybe shd be 
their own datatype?

9.   tei.declarable at default
     tei.identifiable at predeclare
     metSym at terminal
     numeric at trunc
     binary at value                  
        --> are all xsd:boolean (so "unknown" not allowed) ; could just 
be tei.data.truthValue with extra rule

10.  timeline at interval
       when at interval   
       --> tei.data.numeric | -1  (or think of a better way of doing the -1)

11. several attributes with proposed  datypes of "xsd:NCName" -> 
tei.data.name

12. several attributes with proposed datatypes of "xsd:nonNegativeInteger"
   --> there are enough of these that I propose a new datatype 
"tei.data.count"

13. sense at level -> tei.data.count

From Syd_Bauman at Brown.edu  Sun Sep 18 00:03:38 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 18 Sep 2005 00:03:38 -0400
Subject: [tei-council] attribute table for ED W 90 updated
Message-ID: <17196.59162.642012.88366@emt.wwp.brown.edu>

I've now finished the second pass through the table of attributes
that goes with ED W 90. The direct link to the PHP interface to it is
http://dev.stg.brown.edu/staff/Syd_Bauman/edw90.php. 

At some point Council needs to go through this list and suggest
changes, fill gaps, say "go ahead", etc. I'm not sure exactly when
this should be done, since it's obvious from Lou's DTYPES list that
we need to do quite a bit more work on datatypes first. I'll try to
get to those tonight, but more likely tomorrow.

From Syd_Bauman at Brown.edu  Sun Sep 18 01:16:51 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 18 Sep 2005 01:16:51 -0400
Subject: [tei-council] datatypes
In-Reply-To: <4324BC32.2070906@computing-services.oxford.ac.uk>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
Message-ID: <17196.63555.177746.535394@emt.wwp.brown.edu>

Not surprisingly, my disagreements with this proposed list of
datatypes fall mostly in the places where it differs from those
recommended in EDW90 (as I said I was going to modify it on the
conference call, but haven't bothered since Lou in essence moved the
declarations to DTYPES).

* tei.data.probability: Hmmm... this might work. It is a bit
  confusing. The problem is that, because the recommendation in
  DTYPES has removed the percent sign, there is no way to distinguish
  "1" meaning 100% from "1" meaning 1%. However, we could write a
  prose rule that required users who want to use "1" to mean 100%
  write it as "1.0" (which, because the percentages are declared as
  integers, and the check is done on the lexical space, not the value
  space, could not be a percentage). This seems somewhat fragile to
  me, so I still think the original idea (requiring a percent sign
  for percentages) is better, but this one is not implausible.
  Note also that the EDW90 pattern permits fractions of a percentage,
  whereas the DTYPES pattern does not. I'm perfectly happy either
  way. (There is no current application of this datatype where
  fractional percentages would make any sense at all; one can imagine
  that it might be used for something else for which more precision
  would be appropriate, though.) In either case, having now done the
  calculation to figure out how tiny a number can fit into an
  xsd:float (~1.4e-45), I am convinced we should change xsd:double
  to xsd:float.

* tei.data.numeric: the change removes support for a constituency
  that we already now about: those who need to enter floating point
  numbers. Furthermore, I still claim it makes sense to permit
  percentages. (One could argue, though, that the percentages should
  be limited to 8 characters maximum (effectively limiting them to 3
  or 4 decimal places of precision), so that any tei.data.numeric
  value could fit into 64 bits.)

Well, I've gotten through group 1, numeric. I hope to tackle the
others tomorrow.

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep 18 02:16:11 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 18 Sep 2005 07:16:11 +0100
Subject: [tei-council] datatypes
In-Reply-To: <17196.63555.177746.535394@emt.wwp.brown.edu>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17196.63555.177746.535394@emt.wwp.brown.edu>
Message-ID: <432D062B.1020908@oucs.ox.ac.uk>

Syd Bauman wrote:

>* tei.data.numeric: the change removes support for a constituency
>  that we already now about: those who need to enter floating point
>  numbers.
>
I thought we went through this on TEI-L, and someone like
M Beddows showed that the W3C datatypes did do everything
needed?

> Furthermore, I still claim it makes sense to permit
>  percentages
>
at first blush, I think a percentage is like a dimension,
not a numeric (width=23cm, width=88%). mixing
it in with numeric seems pretty weird. I may well be wrong.

> (One could argue, though, that the percentages should
>  be limited to 8 characters maximum (effectively limiting them to 3
>  or 4 decimal places of precision), so that any tei.data.numeric
>  value could fit into 64 bits.)
>  
>
haven't we gone beyond worrying about number of bits
we use 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 lou.burnard at computing-services.oxford.ac.uk  Sun Sep 18 07:24:27 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 18 Sep 2005 12:24:27 +0100
Subject: [tei-council] attribute table for ED W 90 updated
In-Reply-To: <17196.59162.642012.88366@emt.wwp.brown.edu>
References: <17196.59162.642012.88366@emt.wwp.brown.edu>
Message-ID: <432D4E6B.3040905@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>I've now finished the second pass through the table of attributes
>that goes with ED W 90. The direct link to the PHP interface to it is
>http://dev.stg.brown.edu/staff/Syd_Bauman/edw90.php. 
>
>At some point Council needs to go through this list and suggest
>changes, fill gaps, say "go ahead", etc. 
>

Indeed yes. The message I posted last night summarized the outstanding 
issues, as I see them at least.

>I'm not sure exactly when
>this should be done, since it's obvious from Lou's DTYPES list that
>we need to do quite a bit more work on datatypes first. I'll try to
>get to those tonight, but more likely tomorrow,
>  
>

I am not quite sure what Syd means by "Lou's DTYPES list" and I am 
completely in the dark as to why he thinks there is "quite a bit more 
work" to be done! The list of datatypes I circulated last weekend, with 
the one (or possibly two) extensions I suggested yesterday, seems to me 
a workable basis for progress, and is almost entirely compatible with 
the proposals in Syd's edw90 table -- indeed, it is based on same.

We really have to get this long overdue and not very difficult exercise 
out of the way before moving on to the class system, which is a much 
more challenging prospect....

>_______________________________________________
>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 Sep 18 07:55:07 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 18 Sep 2005 12:55:07 +0100
Subject: [tei-council] datatypes -- syd's comments
In-Reply-To: <17196.63555.177746.535394@emt.wwp.brown.edu>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17196.63555.177746.535394@emt.wwp.brown.edu>
Message-ID: <432D559B.9040205@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>* tei.data.probability: Hmmm... this might work. It is a bit
>  confusing. The problem is that, because the recommendation in
>  DTYPES has removed the percent sign, there is no way to distinguish
>  "1" meaning 100% from "1" meaning 1%. 
>
Ah! good point. But what is your recommendation?
(a) decide whether probability shd be expressed as a number between 0 
and 1 or as a number between 0 and 100 and then enforce one of them (if 
so, which?)
(b) allow both as alternatives, but require that the latter (1 to 100) 
is always followed by a percent sign
(c) leave things as proposed but note the constraint that numbers 
between 0 and 1 must be expressed including a decimal point.

Being a lazy person, I have a slight preference for (c) though it's hard 
to care very much about this:  the total number of attributes affected 
in the current version of edw90 table is one (1)

>* tei.data.numeric: the change removes support for a constituency
>  that we already now about: those who need to enter floating point
>  numbers. Furthermore, I still claim it makes sense to permit
>  percentages. (One could argue, though, that the percentages should
>  be limited to 8 characters maximum (effectively limiting them to 3
>  or 4 decimal places of precision), so that any tei.data.numeric
>  value could fit into 64 bits.)
>  
>
I don't completely understand this comment since tei.data.numeric maps 
to xsd:decimal which does support floating point numbers.  I assume what 
you mean is that such numbers can't be represented using the 
mantis+exponent (aka "scientific") notation. So it will permit 
"1.23456789" but not  "2e0.134"

Again, I find very few real use cases in the edw90 table -- in fact the 
only case where I suppose it might be plausible to permit the scientific 
notation is the value attribute on <numeric> and <num>

I can't see any use case where you might want to supply a percentage so 
I am not very enthusiastic about that either. Would tei.data.probability 
suit them?

From Syd_Bauman at Brown.edu  Sun Sep 18 11:15:56 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 18 Sep 2005 11:15:56 -0400
Subject: on spec grp 2,
	datatypes normalized (was "Re: [tei-council] datatypes")
In-Reply-To: <4324BC32.2070906@computing-services.oxford.ac.uk>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
Message-ID: <17197.33964.284995.434431@emt.wwp.brown.edu>

It seems to make sense to divide these comments up along with the
clever groupings Lou has used. Thus this one is

On Specification group 2: Datatypes: normalised
-- ------------- ----- -- ---------- ----------

* tei.data.temporal (I like the name better than the previous clumsy
  "temporalExpression"): the change removes the capability to express
  a time without seconds. The change also brings the datatype closer
  in line with being "normalized" to W3C Schema part 2, in the sense
  that the only component whose value space is not a date or time has
  been removed.

  However, as is often the case, I don't think the datatypes
  described in W3C Schema part 2 would do a particularly good job of
  modeling or representing humanities data. (Remember, they were
  written by corporations for corporations.) One might even go so far
  as to say W3C is a bit dyslexic in the area of dates and times. I
  concede that I may have missed or be misunderstanding some
  pertinent detail thereof; and I am going to resist the urge to bash
  W3C date & time datatypes in general, and will try to stick to the
  detailed issue at hand. However, so that no one gets the wrong
  idea, I will note that as much as I can pick holes in W3C
  representations, they've done a better job than I would have done
  at first crack, and have what I think is a very good examination of
  how dates, times, and durations are compared and thus sorted.

  The problem at hand boils down to the W3C conception of a time:
  "time represents an instant of time ..." (3.2.8). Thus, to the W3C,
  "09:07:51" is just a less precise description of some instant,
  which would be more precisely described as "09:07:51.209831". But
  in the humanities, I submit, we often need to encode times less
  precisely than to the instant, or even the second. Requiring
  seconds (or even thousands thereof) when you're logging incoming
  support phone calls or web hits makes sense. But requiring them for
  "They had all frozen at the same time, on a snowy night, seven
  years before, and after that it was always ten minutes to five in
  the castle" or "Six in the evening" is problematic. "16:50" says
  something different than "16:50:00" just as "that building is 14.2
  meters high" is different than "that building is 14200 millimeters
  high". The former time denotes a minute (the 1,011th minute of the
  day), the latter time denotes a second (the 60,601st second of the
  day). The latter height implies one used a ruler with millimeter
  markings; the former does not.

  Rather than suggest TEI should require precision to the second, I'm
  actually surprised that someone hasn't suggested, for consistency
  at least, that TEI should permit precision only to the hour. (After
  all, pending this discussion we permit precision to the year,
  month, day, minute, and second.)

  All that said, if we do go with the EDW90 recommendation of
  permitting times to the minute, the prose should note that it is
  possible that some processors might not be able to properly compare
  or sort them. (Unlikely, though, as the W3C algorithm for doing so
  applies to times without seconds as well as with; see 3.2.7.4.)

* tei.data.duration: The change removes the capability to express a
  duration in a more common syntax, sticking only with the W3C syntax
  that uses the 8601 "format with time-unit designators". Here the
  difference, as far as I know, is only syntax. My reasoning for
  recommending we allow more readable syntax is that I think many, if
  not most, applications within the TEI world would be using these
  sorts of values more for regularization than for normalization.
  Admittedly, the W3C datatype performs both functions, if almost
  unreadably. (Why couldn't they have recommended 8601 alternate
  syntax?)

  So I still prefer
     xsd:duration | xsd:token { pattern =
     "[0-9]+(\.[0-9]+)? (year|month|week|d|h|min|s|ms|μs" }
  (Note that is *not* the same as the one in EDW90; this one is,
  IMHO, much better, and conforms to NIST recommendations (which use
  SI wherever possible); however, it does not permit expression of a
  negative duration.) But again, unlike xsd:duration where the
  semantics are actually different, in this case it is only syntax,
  so I don't care very much. I just think TEI users are going to be
  much happier encoding <person age="3 month"> than <person
  age="P3M"> and <event dur="13 ms"> than <event dur="PT0.013S">.

* tei.data.sex: We've already hashed this through, and it's only
  syntax, so again, I don't care much. But I am not sure this one
  meets "Syd's rule". I think for many TEI applications "u", "m",
  "f", and "x" (or "not known", "male", "female", "not specified")
  will be demonstrably significantly better -- the humans will be
  able to proofread the texts.

From lou.burnard at computing-services.oxford.ac.uk  Sun Sep 18 13:42:49 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 18 Sep 2005 18:42:49 +0100
Subject: on spec grp 2,
	datatypes normalized (was "Re: [tei-council] datatypes")
In-Reply-To: <17197.33964.284995.434431@emt.wwp.brown.edu>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17197.33964.284995.434431@emt.wwp.brown.edu>
Message-ID: <432DA719.1010607@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>It seems to make sense to divide these comments up along with the
>clever groupings Lou has used. Thus this one is
>
>On Specification group 2: Datatypes: normalised
>-- ------------- ----- -- ---------- ----------
>
>* tei.data.temporal (I like the name better than the previous clumsy
>  "temporalExpression"): the change removes the capability to express
>  a time without seconds. The change also brings the datatype closer
>  in line with being "normalized" to W3C Schema part 2, in the sense
>  that the only component whose value space is not a date or time has
>  been removed.
>  
>

This is indeed the case, and reflects a conscious decision to use 
attribute values here as elsewhere to represent a normalized value, 
which might indeed be represented in a more nuanced way within the 
content of the element or by linking elsewhere.
....

>
>  Rather than suggest TEI should require precision to the second, I'm
>  actually surprised that someone hasn't suggested, for consistency
>  at least, that TEI should permit precision only to the hour. (After
>  all, pending this discussion we permit precision to the year,
>  month, day, minute, and second.)
>
>  
>
I don't get it. If you want to give a value precise to only a year, 
month etc. you  can do so using the approved designation, surely? "1900" 
doesnt mean any particular time in 1900, it just means 1900. Similarly, 
1900-12 means some time in December 1900. And so on.

>  All that said, if we do go with the EDW90 recommendation of
>  permitting times to the minute, the prose should note that it is
>  possible that some processors might not be able to properly compare
>  or sort them. (Unlikely, though, as the W3C algorithm for doing so
>  applies to times without seconds as well as with; see 3.2.7.4.)
>
>  
>
Surely, the point of using this format is precisely that as many 
processors as possible will do the right thing with them. Can you give 
some examples of processors which do not behave correctly when handling 
ISO 8601 format values? And is there any reason to believe they would 
make a better fist of handling an arbitrary TEI-invented format instead?

Similar considerations apply to the other two cases you mention. In the 
case of duration and sex, we are talking about an encoded value for an 
attribute, and it makes much better sense to use an ISO- or W3C- 
recommended encoded value than to make one up.  "Readability" of syntax 
is a very subjective question which in my view should be given 
correspondingly less weight. Obviously in any real application the 
actual values stored in the attribute won't be visible to the end-user 
anyway: they will be translated into something more friendly.

From Syd_Bauman at Brown.edu  Sun Sep 18 13:26:13 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 18 Sep 2005 13:26:13 -0400
Subject: on spec grp 3, notations & ptrs (was "Re: [tei-council] datatypes")
In-Reply-To: <4324BC32.2070906@computing-services.oxford.ac.uk>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
Message-ID: <17197.41781.746732.957067@emt.wwp.brown.edu>

Specification group 3: Datatypes: notations and pointers
------------- ----- -- ---------- --------- --- --------

* tei.data.notation: I don't know what this datatype is for or what
  semantics it carries at all. I'm suspicious that I'd like it if I
  did know what you had in mind -- but rather than have us guess,
  perhaps you'd tell us what it's for, and what attributes should be
  assigned this datatype?

  On the other hand, no matter what it's for, why use rng:token
  instead of xsd:token? For that matter, why use either of those
  instead of tei.data.tokens? (Answer: because in this list, there is
  no tei.data.token(s) -- what happened to them?)

From lou.burnard at computing-services.oxford.ac.uk  Sun Sep 18 14:50:23 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 18 Sep 2005 19:50:23 +0100
Subject: on spec grp 3,
	notations & ptrs (was "Re: [tei-council] datatypes")
In-Reply-To: <17197.41781.746732.957067@emt.wwp.brown.edu>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17197.41781.746732.957067@emt.wwp.brown.edu>
Message-ID: <432DB6EF.2020302@computing-services.oxford.ac.uk>

Mea culpa -- I forgot to update the website at 
http://www.tei-c.org/Drafts/DTYPES/ as well as checking the changes into 
CVS.

Have now done so. Mind you, the Virginia site seems to be down again...

Syd Bauman wrote:

>Specification group 3: Datatypes: notations and pointers
>------------- ----- -- ---------- --------- --- --------
>
>* tei.data.notation: I don't know what this datatype is for or what
>  semantics it carries at all. I'm suspicious that I'd like it if I
>  did know what you had in mind -- but rather than have us guess,
>  perhaps you'd tell us what it's for, and what attributes should be
>  assigned this datatype?
>
>  On the other hand, no matter what it's for, why use rng:token
>  instead of xsd:token? For that matter, why use either of those
>  instead of tei.data.tokens? (Answer: because in this list, there is
>  no tei.data.token(s) -- what happened to them?)
>
>_______________________________________________
>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  Sun Sep 18 23:30:50 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 18 Sep 2005 23:30:50 -0400
Subject: on spec grp 4, coded values (was "Re: [tei-council] datatypes")
In-Reply-To: <4324BC32.2070906@computing-services.oxford.ac.uk>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
Message-ID: <17198.12522.68260.573944@emt.wwp.brown.edu>

[Note: despite the In-Reply-To field, this commentary is based on the
 new version Lou just put out at
 http://www.tei-c.org.uk/Drafts/DTYPES/ (the main site is down).]

On Specification group 4: Datatypes: coded values
-- ------------- ----- -- ---------- ----- ------

* tei.data.code: the change permits any pointer; the recommendation
  in ED W 90 is for local pointers only. We've talked about this
  somewhat over the past few weeks or so, but IIRC, no one has said
  anything on this issue except Lou and Syd. Lou has said (at least
  twice) that he thinks it should be a generic pointer, but has not
  expressed why.

  I think there are several good reasons to restrict these kinds of
  references to local pointers.

  - It mimics what P4 had.

  - It provides a system (as did ID/IDREF) where the attribute value
    itself may be used as a code for a useful semantic distinction
    (thus the name). E.g., new= and old= of <handShift> -- the real
    details are provided by the <hand> to which they point, but
    mnemonic values like "#Scribe1brown" and "#Scribe2red" can convey
    a lot of meaning by themselves, or at least be easy for humans to
    associate with the appropriate <hand>.

  - By changing the values of the xml:id= attributes of the elements
    pointed at (e.g., <hand>), the encoder gets to create the
    vocabulary used.

  - People want to know where things point. (Or go -- some of the
    bigger complaints about P4 are about places where it says that
    something should be documented "in the TEI header" without saying
    where in the TEI header.)

    If we stick to local pointers, we can define the place or places
    (likely in the TEI header) to where each tei.data.code attribute
    is supposed to point, document it accordingly, and perhaps write
    a Schematron rule to verify that it does so.

    If we permit any pointer, documentation where these things point
    becomes somewhat harder. E.g., if the new= of <handShift> points
    to an external file, does it still need to point at a <tei:hand>?
    Presumably so. But unless the external file is another encoded
    document that happened to be written by the same scribes, it is
    likely to be just a project repository for <hand> elements. What
    goes in the <text> element of that document? We also need to
    rewrite the prose so that it is clear that the <hand> in one TEI
    document may well be documenting the handwriting in another.

  In either case (whether tei.data.code is declared as a pointer or a
  local pointer), a user could easily switch to the other by
  modifying her customization ODD file. I think it will provide a
  more coherent system (and be easier for us to boot) if we provide a
  local pointer mechanism; users who change it to general pointers
  will know up front they are making an extension that may change
  some of the semantics of some bits of the Guidelines.

* tei.data.enumerated: the change permits whitespace in the values.
  I'm not sure about this. For consistency with tei.data.name and
  tei.data.code (as proposed in ED W 90), I think whitespace should
  not be permitted. Especially in cases of "open" valLists,
  disallowing whitespace would help users understand that the value
  should be a code, not a paragraph. On the other hand, is there any
  really strong reason to insist on things like 
    <lg type="couplet-alexandrine"> 
  instead of
    <lg type="Alexandrine couplet">?
  Even if we use token w/o the restriction, for consistency it should
  probably be xsd:token.

* tei.data.key: the change is from 'xsd:token' to 'rng:string'. I
  think it should be left as 'xsd:token' just for consistency. There
  is no difference in validation at all (since there are no
  enumerated values).

* tei.data.name: the change is from any string that does not contain
  whitespace (but may include, e.g., punctuation marks, currency
  symbols, math symbols, etc.) to an XML NMTOKEN. I am not sure why
  we'd want to exclude the non-letter, non-digit characters (other
  than .-_:, which are permitted in NMTOKEN). Why shouldn't the
  Tibetan Paluta character be allowed?

* tei.data.names: the change is from multiple occurrences of
  whitespace-delimited tokens to only one. Despite your claim, Lou,
  this really must be an error. I bet you meant 
     tei.data.names = list { tei.data.name+ }

* tei.data.name(s): the change is from the name "token(s)" to
  "name(s)". I dunno. Feels very much like out of the frying pan into
  the fire. While "token" is confusing because W3C mis-named their
  datatype, "name" is confusing because in fact these values are most
  likely not proper nouns at all, and have nothing to do with the
  <name> element, the 'names' class, or the 'naming' class.
  How about
  - term
  - sign
  - TOKEN
  - character-sequence
  - character-sequence-sans-whitespace
  - charSeq
  - noWScharSeq
  - datum ('data' for plural)
  - the Latin or French word for "token"
  Oh dear. I'm almost ready to live with the confusion over "token".

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Sep 19 07:12:01 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 19 Sep 2005 20:12:01 +0900
Subject: [tei-council] Re: on spec grp 4, coded values
In-Reply-To: <17198.12522.68260.573944@emt.wwp.brown.edu> (Syd Bauman's
	message of "Sun, 18 Sep 2005 23:30:50 -0400")
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17198.12522.68260.573944@emt.wwp.brown.edu>
Message-ID: <ygfek7lfh1a.fsf@chwpb.local>

Syd Bauman <Syd_Bauman at Brown.edu> writes:

> [Note: despite the In-Reply-To field, this commentary is based on the
>  new version Lou just put out at
>  http://www.tei-c.org.uk/Drafts/DTYPES/ (the main site is down).]
>
> On Specification group 4: Datatypes: coded values
> -- ------------- ----- -- ---------- ----- ------
>
> * tei.data.code: the change permits any pointer; the recommendation
>   in ED W 90 is for local pointers only. We've talked about this
>   somewhat over the past few weeks or so, but IIRC, no one has said
>   anything on this issue except Lou and Syd. Lou has said (at least
>   twice) that he thinks it should be a generic pointer, but has not
>   expressed why.
>
>   I think there are several good reasons to restrict these kinds of
>   references to local pointers.

I assume you are talking about pointers to the current document in the
ID/IDREF tradition.

I think I understand your argument, but I have to warn you that I
think the notion of local gets somehow blurred when you start to have
things like xinclude and even more if you put your stuff into XML
databases -- the latter introduce even more complications with the
notion of collections, which are not the current docuemnt, but also
not really not local.

So I am not really convinced the argument local vs remote gets you
anywhere in the real world, except maybe that it makes the validation
a lot easier if you want to enforce only #pointers.

As you see, I am back in circulation and hope to take up some other
issues as well.

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 Sep 19 07:14:21 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 19 Sep 2005 20:14:21 +0900
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <432CA353.9000105@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Sun, 18 Sep 2005 00:14:27 +0100")
References: <432CA353.9000105@computing-services.oxford.ac.uk>
Message-ID: <ygfaci9fgxe.fsf@chwpb.local>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> I haven't heard any squawks of protest, so assuming people are
> reasonably happy with the datatypes so far proposed, I've now checked
> through the list in Syd's table for discrepancies, or things I've
> overlooked. The executive summary is that I think we need just one new
> datatype "tei.data.count", which I will add to the list. Otherwise,
> we're ready to move to implementation, assuming none of the following
> tidyup is controversial.

I have been terribly busy the last two weeks and did not find the time
necessary to dig into the datatypes arcanea, but I see you sorted it
out more or less now and it looks pretty fine to me at the moment.

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 Sep 19 07:23:18 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 19 Sep 2005 20:23:18 +0900
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <432DA719.1010607@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Sun, 18 Sep 2005 18:42:49 +0100")
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17197.33964.284995.434431@emt.wwp.brown.edu>
	<432DA719.1010607@computing-services.oxford.ac.uk>
Message-ID: <ygfek7lcndl.fsf@chwpb.local>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

>>On Specification group 2: Datatypes: normalised
>>-- ------------- ----- -- ---------- ----------
>>
>>* tei.data.temporal (I like the name better than the previous clumsy
>>  "temporalExpression"): the change removes the capability to express
>>  a time without seconds. The change also brings the datatype closer
>>  in line with being "normalized" to W3C Schema part 2, in the sense
>>  that the only component whose value space is not a date or time has
>>  been removed.
>>  
>>
>
> This is indeed the case, and reflects a conscious decision to use
> attribute values here as elsewhere to represent a normalized value,
> which might indeed be represented in a more nuanced way within the
> content of the element or by linking elsewhere.
> ....
>
>>
>>  Rather than suggest TEI should require precision to the second, I'm
>>  actually surprised that someone hasn't suggested, for consistency
>>  at least, that TEI should permit precision only to the hour. (After
>>  all, pending this discussion we permit precision to the year,
>>  month, day, minute, and second.)
>>
>>  
>>
> I don't get it. If you want to give a value precise to only a year,
> month etc. you  can do so using the approved designation, surely?
> "1900" doesnt mean any particular time in 1900, it just means
> 1900. Similarly, 1900-12 means some time in December 1900. And so
> on.

It is a timespan, put not a point in time.  This problem raises its
head regularily when trying to express a Chinese year in ISO, which
should then be rendered as 1900-02-17 to 1901-01-29.  Any idea how
this could be expressed on @value for date?

> Similar considerations apply to the other two cases you mention. In
> the case of duration and sex, we are talking about an encoded value
> for an attribute, and it makes much better sense to use an ISO- or
> W3C- 
> recommended encoded value than to make one up.  "Readability" of
> syntax is a very subjective question which in my view should be given
> correspondingly less weight. Obviously in any real application the
> actual values stored in the attribute won't be visible to the end-user
> anyway: they will be translated into something more friendly.

Well, I grudgingly agree to this now, we probably do the best to
long-term maintability if we stick with these unwieldy ISO things --
they will hopefully stay around for a while.

Alll 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 Sep 19 07:26:31 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 19 Sep 2005 20:26:31 +0900
Subject: [tei-council] Problem with Roma or ODD
Message-ID: <ygfaci9cn88.fsf@chwpb.local>

Given the following ODD fragment,

			<elementSpec ident="app" mode="change" module="textcrit">
			 <attList>
				 <attDef ident="resp" usage="opt">
					 <desc>Agency responsible for this apparatus entry (usually as given in the text)</desc>
					 <datatype><rng:text/></datatype>
				 </attDef>
			 </attList>
			</elementSpec>

I do not see the change materialize in the generated validators.  Is
this a problem with Roma, or with my understanding of the ODDs? What I
want to achieve is adding a @resp to <app>.

BTW, the CVS Howto seems now workable to me, thanks James.  I wonder
if anybody else tried to use it in Schema production recently?

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  Mon Sep 19 07:31:33 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 19 Sep 2005 12:31:33 +0100
Subject: [tei-council] Problem with Roma or ODD
In-Reply-To: <ygfaci9cn88.fsf@chwpb.local>
References: <ygfaci9cn88.fsf@chwpb.local>
Message-ID: <432EA195.8070109@oucs.ox.ac.uk>

Christian Wittern wrote:

>Given the following ODD fragment,
>
>			<elementSpec ident="app" mode="change" module="textcrit">
>			 <attList>
>				 <attDef ident="resp" usage="opt">
>					 <desc>Agency responsible for this apparatus entry (usually as given in the text)</desc>
>					 <datatype><rng:text/></datatype>
>				 </attDef>
>			 </attList>
>			</elementSpec>
>
>
>I do not see the change materialize in the generated validators.  Is
>this a problem with Roma, or with my understanding of the ODDs? What I
>want to achieve is adding a @resp to <app>.
>  
>
you need "mode='add'" on the <attDef>

you might argue about defaults of @mode, but in the
implementation now, you need to be specific.

greetings from Sophia Antipolis.

-- 
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  Mon Sep 19 07:47:22 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Mon, 19 Sep 2005 13:47:22 +0200
Subject: [tei-council] Problem with Roma or ODD
In-Reply-To: <ygfaci9cn88.fsf@chwpb.local>
References: <ygfaci9cn88.fsf@chwpb.local>
Message-ID: <744a9e6bd9b7cd326ea4105f79dee3e5@loria.fr>

Dear Christian,
I guess you put the answer in your own message: you want to add @resp 
to add. You need to add a mode="add"  to attDef. (Seb, Lou, etc.: am I 
right?)
Best,
Laurent
Le 19 sept. 05, ? 13:26, Christian Wittern a ?crit :

>
>
> Given the following ODD fragment,
>
> 			<elementSpec ident="app" mode="change" module="textcrit">
> 			 <attList>
> 				 <attDef ident="resp" usage="opt">
> 					 <desc>Agency responsible for this apparatus entry (usually as 
> given in the text)</desc>
> 					 <datatype><rng:text/></datatype>
> 				 </attDef>
> 			 </attList>
> 			</elementSpec>
>
>
> I do not see the change materialize in the generated validators.  Is
> this a problem with Roma, or with my understanding of the ODDs? What I
> want to achieve is adding a @resp to <app>.
>
> BTW, the CVS Howto seems now workable to me, thanks James.  I wonder
> if anybody else tried to use it in Schema production recently?
>
> 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
>

From sebastian.rahtz at oucs.ox.ac.uk  Mon Sep 19 07:54:30 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 19 Sep 2005 12:54:30 +0100
Subject: [tei-council] datatypes -- syd's comments
In-Reply-To: <432D559B.9040205@computing-services.oxford.ac.uk>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>	<17196.63555.177746.535394@emt.wwp.brown.edu>
	<432D559B.9040205@computing-services.oxford.ac.uk>
Message-ID: <432EA6F6.5060806@oucs.ox.ac.uk>

Lou Burnard wrote:

>
>>  DTYPES has removed the percent sign, there is no way to distinguish
>>  "1" meaning 100% from "1" meaning 1%.
>
> Ah! good point. But what is your recommendation?
> (a) decide whether probability shd be expressed as a number between 0
> and 1 or as a number between 0 and 100 and then enforce one of them
> (if so, which?)
> (b) allow both as alternatives, but require that the latter (1 to 100)
> is always followed by a percent sign
> (c) leave things as proposed but note the constraint that numbers
> between 0 and 1 must be expressed including a decimal point.
>
> Being a lazy person, I have a slight preference for (c) though it's
> hard to care very much about this:  the total number of attributes
> affected in the current version of edw90 table is one (1)

why dont we just zap that one :-}

> I don't completely understand this comment since tei.data.numeric maps
> to xsd:decimal which does support floating point numbers.  I assume
> what you mean is that such numbers can't be represented using the
> mantis+exponent (aka "scientific") notation. So it will permit
> "1.23456789" but not  "2e0.134"
>
|if you use xsd:float then
"-1E4, 1267.43233E12, 12.78e-2, 12| |, -0, 0| and |INF| are all legal
literals for *float*"
(http://www.w3.org/TR/xmlschema-2/#float), so
why is decimal preferred to float?

-- 
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 Sep 19 08:32:59 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 19 Sep 2005 13:32:59 +0100
Subject: [tei-council] naming languages
Message-ID: <432EAFFB.4080602@oucs.ox.ac.uk>

oh look, this fun

http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt

-- 
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 Sep 19 10:43:46 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 19 Sep 2005 16:43:46 +0200
Subject: on spec grp 4, coded values (was "Re: [tei-council] datatypes")
In-Reply-To: <17198.12522.68260.573944@emt.wwp.brown.edu>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17198.12522.68260.573944@emt.wwp.brown.edu>
Message-ID: <432ECEA2.30508@oucs.ox.ac.uk>

Syd Bauman wrote:
> [Note: despite the In-Reply-To field, this commentary is based on the
>  new version Lou just put out at
>  http://www.tei-c.org.uk/Drafts/DTYPES/ (the main site is down).]
> 
> On Specification group 4: Datatypes: coded values
> -- ------------- ----- -- ---------- ----- ------
> 
> * tei.data.code: the change permits any pointer; the recommendation
>   in ED W 90 is for local pointers only. We've talked about this
>   somewhat over the past few weeks or so, but IIRC, no one has said
>   anything on this issue except Lou and Syd. Lou has said (at least
>   twice) that he thinks it should be a generic pointer, but has not
>   expressed why.

It seems to me self-evident that once we changed from using IDREF to 
URIref, which we did long ago, the distinction between "local" and 
"generic" pointer became meaningless.

> 
>   I think there are several good reasons to restrict these kinds of
>   references to local pointers.
> 
>   - It mimics what P4 had.
> 

Not a good reason.

>   - It provides a system (as did ID/IDREF) where the attribute value
>     itself may be used as a code for a useful semantic distinction
>     (thus the name). E.g., new= and old= of <handShift> -- the real
>     details are provided by the <hand> to which they point, but
>     mnemonic values like "#Scribe1brown" and "#Scribe2red" can convey
>     a lot of meaning by themselves, or at least be easy for humans to
>     associate with the appropriate <hand>.
> 

You can still do that if you choose to.

>   - By changing the values of the xml:id= attributes of the elements
>     pointed at (e.g., <hand>), the encoder gets to create the
>     vocabulary used.

You can still do that too.

> 
>   - People want to know where things point. (Or go -- some of the
>     bigger complaints about P4 are about places where it says that
>     something should be documented "in the TEI header" without saying
>     where in the TEI header.)
> 

True, but irrelevant.

>     If we stick to local pointers, we can define the place or places
>     (likely in the TEI header) to where each tei.data.code attribute
>     is supposed to point, document it accordingly, and perhaps write
>     a Schematron rule to verify that it does so.
> 

We can specify the target element type, and maybe we should do so in 
some cases, but I don't see any advantage at all to trying to specify 
"where" the element instance is. It's all out there in cyberspace, man!

>     If we permit any pointer, documentation where these things point
>     becomes somewhat harder. E.g., if the new= of <handShift> points
>     to an external file, does it still need to point at a <tei:hand>?

Yes, obviously.

>     Presumably so. But unless the external file is another encoded
>     document that happened to be written by the same scribes, it is
>     likely to be just a project repository for <hand> elements. What
>     goes in the <text> element of that document? We also need to
>     rewrite the prose so that it is clear that the <hand> in one TEI
>     document may well be documenting the handwriting in another.
> 

The thing that handshift points to must be a <hand> element. It doesn't 
matter where that <hand> element is located, or what else is in the 
document containing it.

>   In either case (whether tei.data.code is declared as a pointer or a
>   local pointer), a user could easily switch to the other by
>   modifying her customization ODD file. I think it will provide a
>   more coherent system (and be easier for us to boot) if we provide a
>   local pointer mechanism; users who change it to general pointers
>   will know up front they are making an extension that may change
>   some of the semantics of some bits of the Guidelines.
> 

I don't know of any way of defining a local pointer, other than to say 
that the URL reference must begin with a # -- in which case you break 
things for the obsessive person who includes the full URL even when the 
pointer is to somewhere in the current document.

> * tei.data.enumerated: the change permits whitespace in the values.
>   I'm not sure about this. For consistency with tei.data.name and
>   tei.data.code (as proposed in ED W 90), I think whitespace should
>   not be permitted. Especially in cases of "open" valLists,
>   disallowing whitespace would help users understand that the value
>   should be a code, not a paragraph. On the other hand, is there any
>   really strong reason to insist on things like 
>     <lg type="couplet-alexandrine"> 
>   instead of
>     <lg type="Alexandrine couplet">?
>   Even if we use token w/o the restriction, for consistency it should
>   probably be xsd:token.

I am open minded (or open-minded) on this question. I finally came down 
on the side of allowing *normalised* whitespace within the value because 
(a) there are quite a few real life examples in P4
(b) i assumed that whoever defined xsd:token that way was probably not a 
complete idiot.

There are quite a few things which are linguistically single tokens but 
which include a space, all right?

> * tei.data.key: the change is from 'xsd:token' to 'rng:string'. I
>   think it should be left as 'xsd:token' just for consistency. There
>   is no difference in validation at all (since there are no
>   enumerated values).

There is all the difference in the world. key is *explicitly* defined as 
something that is to be validated externally and over which the TEI 
should therefore place no (additional) syntactic constraints. We cannot 
possibly second guess what syntactic constraints every database system 
in the world might impose, ergo our only choice is to not impose any at all.

> 
> * tei.data.name: the change is from any string that does not contain
>   whitespace (but may include, e.g., punctuation marks, currency
>   symbols, math symbols, etc.) to an XML NMTOKEN. I am not sure why
>   we'd want to exclude the non-letter, non-digit characters (other
>   than .-_:, which are permitted in NMTOKEN). Why shouldn't the
>   Tibetan Paluta character be allowed?

I assume the latter is not a serious suggestion. I thought the reason 
was fairly obviously to do with ease of (XML) processing.

> 
> * tei.data.names: the change is from multiple occurrences of
>   whitespace-delimited tokens to only one. Despite your claim, Lou,
>   this really must be an error. I bet you meant 
>      tei.data.names = list { tei.data.name+ }
> 

Yes, sorry. It is right in CVS...

> * tei.data.name(s): the change is from the name "token(s)" to
>   "name(s)". I dunno. Feels very much like out of the frying pan into
>   the fire. While "token" is confusing because W3C mis-named their
>   datatype, "name" is confusing because in fact these values are most
>   likely not proper nouns at all, and have nothing to do with the
>   <name> element, the 'names' class, or the 'naming' class.
>   How about
>   - term
>   - sign
>   - TOKEN
>   - character-sequence
>   - character-sequence-sans-whitespace
>   - charSeq
>   - noWScharSeq
>   - datum ('data' for plural)
>   - the Latin or French word for "token"
>   Oh dear. I'm almost ready to live with the confusion over "token".
> 

We did discuss this a a bit on the list and nobody came up with a better 
suggestion. I think using "token" would really be asking for confusion 
-- precisely because we do mean something different from a datatype 
which the W3C calls "token" -- whether it's in caps or not. I also 
considered "ident" and "label". The key thing about it, surely though, 
is that it is a way of naming something, even if it's not a proper name?

We can iron this one out maybe later. At least we agree on what it is, 
and until someone comes up with a better token, let's call it a name!

From Syd_Bauman at Brown.edu  Mon Sep 19 14:22:08 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 19 Sep 2005 14:22:08 -0400
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <4325CC68.1050400@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
	<17188.14848.10373.576601@emt.wwp.brown.edu>
	<432c6d11beae57e26e676af90eb58055@loria.fr>
	<43248510.70009@oucs.ox.ac.uk>
	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>
	<17189.51427.518938.47525@emt.wwp.brown.edu>
	<4325CC68.1050400@computing-services.oxford.ac.uk>
Message-ID: <17199.464.243621.414963@emt.wwp.brown.edu>

> Has anyone come up with a standard which represents any possible
> time, duration, periods, in all known calendars? Or is there a
> time/date standard that is in any way better ISO 8601?

There are several profiles (i.e., subsets) of 8601 which are arguably
superior. (They have rules like don't permit basic, only extended,
formats where both are available; don't permit "24" in the hour
field, etc.)

> One of the other differences I notice with ISO8601 and your
> patterns is that tei.duration current copes with things at a
> smaller granularity than 1 second and ISO 8601 doesn't.

What makes you think one can't express fractions of a second in ISO
8601 durations? I am quite positive you can in the alternate format
(e.g., PT00:00:00,110 for 110 ms), and thus presumed you could in the
format with time-unit designators.

(BTW, 8601 permits fractions of other units, as well; so "half an
hour" could be PT00,5.)

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Sep 19 18:45:16 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 20 Sep 2005 07:45:16 +0900
Subject: [tei-council] Problem with Roma or ODD
In-Reply-To: <432EA195.8070109@oucs.ox.ac.uk> (Sebastian Rahtz's message of
	"Mon, 19 Sep 2005 12:31:33 +0100")
References: <ygfaci9cn88.fsf@chwpb.local> <432EA195.8070109@oucs.ox.ac.uk>
Message-ID: <ygfzmq8brsz.fsf@chwpb.local>

Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> writes:

> Christian Wittern wrote:
>
>>Given the following ODD fragment,
>>
>>			<elementSpec ident="app" mode="change" module="textcrit">
>>			 <attList>
>>				 <attDef ident="resp" usage="opt">
>>					 <desc>Agency responsible for this apparatus entry (usually as given in the text)</desc>
>>					 <datatype><rng:text/></datatype>
>>				 </attDef>
>>			 </attList>
>>			</elementSpec>
>>
>>
>>I do not see the change materialize in the generated validators.  Is
>>this a problem with Roma, or with my understanding of the ODDs? What I
>>want to achieve is adding a @resp to <app>.
>>  
>>
> you need "mode='add'" on the <attDef>
>

Thanks. Arrrgh.  If you say so.  How about putting an example of this in the
ODD Manual?  

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 Sep 20 00:20:20 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 00:20:20 -0400
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <432DA719.1010607@computing-services.oxford.ac.uk>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17197.33964.284995.434431@emt.wwp.brown.edu>
	<432DA719.1010607@computing-services.oxford.ac.uk>
Message-ID: <17199.36356.769861.682886@emt.wwp.brown.edu>

> This is indeed the case, and reflects a conscious decision to use
> attribute values here as elsewhere to represent a normalized value,
> which might indeed be represented in a more nuanced way within the
> content of the element or by linking elsewhere.

While I agree with the general principle, "13:30" is not more nuanced
than "13:30:00"; but it is different, and needs to be representable.

> I don't get it. If you want to give a value precise to only a year,
> month etc. you can do so using the approved designation, surely?
> "1900" doesnt mean any particular time in 1900, it just means 1900.
> Similarly, 1900-12 means some time in December 1900. And so on.

Exactly! Using W3C datatypes you can give a date/time value precise
to the
* year
* month
* day
* second
but *not* to the hour or minute. This is what requires repair.

> Surely, the point of using this format is precisely that as many
> processors as possible will do the right thing with them.

Yes, but not at the expense of not being able to represent humanities
data. Besides, keep in mind that (at least for RelaxNG) all a datatype
does is, given a certain string, say "yes, this is" or "no, this is
not" a valid instance of me. It doesn't return a normalized or
regularized or canonical value or anything like that.

> Can you give some examples of processors which do not behave
> correctly when handling ISO 8601 format values? And is there any
> reason to believe they would make a better fist of handling an
> arbitrary TEI-invented format instead?

The format I'm recommending is *not* arbitrary and is *not*
TEI-invented; it *is* ISO 8601.

> Similar considerations apply to the other two cases you mention. In
> the case of duration and sex, we are talking about an encoded value
> for an attribute, and it makes much better sense to use an ISO- or
> W3C- recommended encoded value than to make one up.

[On duration; ignoring sex, where it seems we're agreed on ISO's 0, 1,
2, 9:]
Again, it's only syntax, so I'm not claiming it is very important, but
I'd like to set the record straight. I did not make up the syntax I am
suggesting. It comes from NIST which takes most of it from SI. I
daresay the Bureau International des Poids et Mesures and even the
(US) National Institute of Standards and Technology has been doing
this standardization of units stuff for a lot longer than either ISO
or W3C, and they do a significantly better job.

From sebastian.rahtz at oucs.ox.ac.uk  Tue Sep 20 05:32:06 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 20 Sep 2005 10:32:06 +0100
Subject: [tei-council] Problem with Roma or ODD
In-Reply-To: <ygfzmq8brsz.fsf@chwpb.local>
References: <ygfaci9cn88.fsf@chwpb.local> <432EA195.8070109@oucs.ox.ac.uk>
	<ygfzmq8brsz.fsf@chwpb.local>
Message-ID: <432FD716.30702@oucs.ox.ac.uk>

Christian Wittern wrote:

>Thanks. Arrrgh.  If you say so.
>
you have to distinguish between authoring a module and
authoring an extension schema.

>  How about putting an example of this in the
>ODD Manual?  
>  
>
surely there is one???

-- 
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  Tue Sep 20 10:23:43 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 10:23:43 -0400
Subject: [tei-council] datatype issues (part 1) continued,,,
In-Reply-To: <4326A09F.1000808@oucs.ox.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
	<17188.14848.10373.576601@emt.wwp.brown.edu>
	<4326A09F.1000808@oucs.ox.ac.uk>
Message-ID: <17200.7023.583257.963017@emt.wwp.brown.edu>

> The only places [tei.data.regexp] is used at present is for
> attributes like metDecl which have as their value a string of
> gobbledegook in some special syntax defined by the TEI.

Huh?? Even in P3 the pattern= attribute of <metDecl> was defined as a
regular expression. In P3 and P4 the regular expression language used
was that created by the TEI for its extended pointer syntax. In P5 we
have made the move to using the W3C regular expression language
instead. I think using a regexp here is and was a good idea,
switching to W3C regexps is a good move, and this attribute should
most certainly remain as is.

> This [string of gobbledegook in some special syntax defined by the
> TEI] seems a useful category of information.

If there are any such attributes, then yes, I agree, it's a useful
category. But don't put pattern= of <metDecl> in it, it doesn't
belong there.

Since we use regexps as an attributes' type very rarely (only 2 or 3
occurrences, I think), I don't really care whether we abstract them
into a datatype or not, although it may be a useful place to explain
it.

> I hesitated a long time over NMTOKEN and NCName. The former allows
> hyphens but not underscore; the latter allows underscore but not
> hyphen.

This is simply untrue. xsd:NMTOKEN maps to an XML NMTOKEN; xsd:NCName
maps to an XML Namespaces NCName, which maps to an XML name except
that colon is not allowed. Both allow hyphen, both allow underscore.
xsd:NCName does not permit the string to *start* with a digit or
punctuation character other than underscore.

> Syd's proposed pattern

Credit where credit is due: it was your proposal, Lou.

> allows [hyphen or underscore] and also comma.

And also semicolon, circled plus sign, curly braces, the Euro
symbol, the copyright symbol, etc.

> I am open to persuasion that both tei.data.key and tei.data.ident
> should have the same mapping; less to defining something which is
> not either NMTOKEN or NCName.

In P4 most of these things were CDATA. I think making them a single
token (normal sense of the word) is a really good idea -- if we could
do so in P4 we should (we can't). I even think forbidding some kinds
of non-whitespace characters would be a really good idea (e.g.,
control characters, PUA characters, etc. See [1] for list). However,
I'm not really sure of the advantage of telling people who would like
to have things like "damaged/deliberate" and "damaged/accidental" as
their values for reason= of <gap> that they cannot, just because W3C
says that names of elements etc. can't have a slash. 

> So in order of ascending tightness of constraint, we have
> 
> tei.data.enumerated : the value is defined by a valList (type=closed)
> tei.data.code : the value is defined by a pointer to something which 
>                 must exist
> tei.data.key : the value is defined by an enumeration elsewhere e.g. a 
>                database key
> tei.data.ident : the value is a name or identifier of some kind but not 
>                  necessarily enumerated or enumeratable

Where in your scheme to <valList>s of type= "open" and "semi" fit?
I.e., are they still assigned the datatype tei.data.enumerated?

Note
----
[1] A first cut at Unicode categories that should and should not be
    permitted in tei.data.[token,ident,name,term]. I am not a Unicode
    expert, nor have I taken the time to examine each category
    carefully, nor to see into what categories the characters
    permitted in xsd:NMTOKEN fall.

    Abbr.  Description                    Should be OK?
    -----  -----------                    ------ -- ---
    Lu     Letter, Uppercase              yes
    Ll     Letter, Lowercase              yes
    Lt     Letter, Titlecase              yes
    Lm     Letter, Modifier               yes?
    Lo     Letter, Other                  yes
    Mn     Mark, Nonspacing               ?
    Mc     Mark, Spacing Combining        ?
    Me     Mark, Enclosing                ?
    Nd     Number, Decimal Digit          yes
    Nl     Number, Letter                 yes
    No     Number, Other                  yes
    Pc     Punctuation, Connector         yes
    Pd     Punctuation, Dash              yes
    Ps     Punctuation, Open              yes
    Pe     Punctuation, Close             yes
    Pi     Punctuation, Initial quote     yes
    Pf     Punctuation, Final quote       yes
    Po     Punctuation, Other             yes
    Sm     Symbol, Math                   yes
    Sc     Symbol, Currency               yes
    Sk     Symbol, Modifier               yes
    So     Symbol, Other                  yes
    Zs     Separator, Space               NO
    Zl     Separator, Line                NO
    Zp     Separator, Paragraph           NO
    Cc     Other, Control                 NO
    Cf     Other, Format                  NO
    Cs     Other, Surrogate               NO
    Co     Other, Private Use             NO
    Cn     Other, Not Assigned            NO

From Syd_Bauman at Brown.edu  Tue Sep 20 12:20:28 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 12:20:28 -0400
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <432CA353.9000105@computing-services.oxford.ac.uk>
References: <432CA353.9000105@computing-services.oxford.ac.uk>
Message-ID: <17200.14028.790906.531915@emt.wwp.brown.edu>

> 1. add at place 
>    addSpan at place
>            -->  tei.data.enumerated

What do you propose the value list be? The list{} method proposed
permits things like "opposite top left" (which is also permitted in
P4). 

>    metDecl at type    
>            -->  tei.data.enumerated

Again, we need to account for the fact that more than 1 "value" is
permitted. Thus the value list would have to account for the various
combinations. Luckily, since there are only 3 of 'em, in this case
it's not hard:
  met
  real
  rhyme
  met;real
  met;rhyme
  real;rhyme
  met;real;rhyme
(In EDW90 I just copied what P4 says to do: "One or more of the three
attribute names met, real, or rhyme, separated by whitespace", thus
   list { ("met" | "real" | "rhyme")+ }
Both P4 and EDW90 permit silly combinations like "met real met
real".)

> 2. tei.pointerGroup at domains  
>           -->  tei.data.pointers

I don't really see it as a plus to permit values that the prose says
are invalid just to say we used a datatype directly. The EDW90
recommendation matches the prose perfectly. (It is
  list { tei.data.pointer, tei.data.pointers }
.)

On the other hand, if everyone really thinks it is extremely
important to use an abstract TEI datatype instead of a perfectly
reasonable combination of 'em like the above, I suppose we could move
the "must be 2 or more" check into a Schematron rule. Seems like the
lesser of two evils, at least.

> 3. schemaSpec at start
>     specDesc at atts   
>          --> tei.data.names

Again, why use a lax constraint when the proper one is readily
available just to say you used a datatype? There are three possible
declarations for tei.data.names on the table, and only one of them
actually constrain this attribute properly:
* list { xsd:NCName+ }  ->  does not permit "musicML:note", but since 
                            there is an ns= attribute, I'm betting
                            that's considered a good thing, right
                            Sebastian?
* list { xsd:NMTOKEN+ }  ->  permits "--notAllowed"
* list { xsd:token { pattern="\S+" } }  ->  permits "${notAllowed}"

If we decide tei.data.names should boil down to something other than
the first, then I think we should just use the proper constraint
without a TEI datatype and not fret it.

> 4. date at precision
>        --> tei.data.certainty

I think this is a really bad idea. First off, <date> should probably
not have a precision= attribute. The precision should be expressed in
the value=. Furthermore, while I suppose vague terms like "high",
"medium", and "low" are occasionally applied to the precision, it is
much more common, and far more useful, to express the unit to which a
measurement is precise. So if we really wanted to separate precision
from the value=, we would want precision= of date to have values like
"century", "decade", "year", "month", "week", and "day".

> 5. tei.datable at dateAttrib
>        --> tei.data.enumerated

Yes, that's what is recommended: tei.enumerated with a value list of
"datable" | "dated" | "unknown".

> 6. locus at scheme
>        --> tei.data.name

I presume that's because you don't want to argue with Matthew and
David over the possible values? :-) Seriously, I don't currently
really understood the purpose of this attribute. <locus> describes a
location in the current manuscript, which (supposedly) has only one
foliation scheme which should be described in //supportDesc/foliation
(of which only 0 or 1 are permitted, right?). So what does scheme=
buy us?

> 7. fragmentPattern at pat
>       --> tei.data.notation

As above, if "tei.data.notation" is for "notations TEI made up", this
doesn't belong.

> 
> 8. schemaSpec at namespace
>     elementSpec at ns (why isnt it "namespace" btw?)
>        --> these could be xsd:uri as proposed, or tei.data.pointer, but 
> maybe since they have to be
>              real namespace names (i.e. "#foo" won't do) maybe shd be 
> their own datatype?

Yes, all our ns= and namespace= attributes need to be brought into
alignment. I don't care which.

However, as I read the spec, "#foo" is a perfectly valid namespace.
Stupid perhaps, but valid.

> 9.   tei.declarable at default
>      tei.identifiable at predeclare
>      metSym at terminal
>      numeric at trunc
>      binary at value                  
>         --> are all xsd:boolean (so "unknown" not allowed) ; could just 
> be tei.data.truthValue with extra rule

Could be. And at one point in the history of that EDW90 table, they
were. But a week or two ago we agreed to go directly with
xsd:boolean. 

> 10.  timeline at interval
>        when at interval   
>        --> tei.data.numeric | -1  (or think of a better way of
>            doing the -1)

a) We'd go back to needing unit= (I'm not saying this is so horrible,
   just want to make sure everyone understands the implications) and
   violate the policy of using W3C Schema datatypes where applicable.

b) All of the proposed declarations of tei.data.numeric already
   permit -1.

c) This permits all other negative numbers, which P4 explicitly
   disallows. 

d) If you meant 'tei.data.count', it won't do as fractions may be
   needed. 

e) Now that I think about it, the pattern EDW90 recommends has a
   problem, too: it permits "-0.5".

Thus, I am now leaning towards
   xsd:long { minInclusive = "0" }  |  xsd:token "unknown"

> 11. several attributes with proposed  datypes of "xsd:NCName" -> 
>     tei.data.name

Again, only if we agree tei.data.name -> xsd:NCName, of which I've
yet to be convinced.

> 12. several attributes with proposed datatypes of
>     "xsd:nonNegativeInteger" --> there are enough of these that I
>     propose a new datatype "tei.data.count"

Fine with me, although I'm not sure what it gains for us.

> 13. sense at level -> tei.data.count

Fine.
(Just so everyone understands, the only real difference between
  xsd:unsignedShort
and
  tei.data.count -> xsd:nonNegativeIngeger
is that the software engineer designing an application that reads a
TEI-encoded dictionary knows that in the former case whenever she
comes across a level= of <sense> she need only set aside 16 bits to
hold the value; with the latter she gets no such assurances. The
other difference, that xsd:unsignedShort has a maximum value of
65,535, isn't a practical problem.)

From Syd_Bauman at Brown.edu  Tue Sep 20 13:16:53 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 13:16:53 -0400
Subject: [tei-council] naming languages
In-Reply-To: <432EAFFB.4080602@oucs.ox.ac.uk>
References: <432EAFFB.4080602@oucs.ox.ac.uk>
Message-ID: <17200.17413.755118.837616@emt.wwp.brown.edu>

> oh look, this fun
> http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt

This, I believe, is a draft of the (much anticipated?) successor to
RFC 3066. xml:lang= is already defined as "3066 or its successor",
but IIRC there are sections of CH that will need to be updated when
this becomes a real RFC.

Alejandro mentioned in Paris that 2-letter initial subcodes are
preferred to 3-letter. I don't know if CH has been updated to reflect
that yet. However, I just quickly checked this new draft, and it
seems that when a 2-letter code is availalbe, it *must* be used, as
the 3-letter version will not be in the IANA registry.

From lou.burnard at computing-services.oxford.ac.uk  Tue Sep 20 13:19:25 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 20 Sep 2005 18:19:25 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <17199.464.243621.414963@emt.wwp.brown.edu>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>	<17189.51427.518938.47525@emt.wwp.brown.edu>	<4325CC68.1050400@computing-services.oxford.ac.uk>
	<17199.464.243621.414963@emt.wwp.brown.edu>
Message-ID: <4330449D.1070605@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>>Has anyone come up with a standard which represents any possible
>>time, duration, periods, in all known calendars? Or is there a
>>time/date standard that is in any way better ISO 8601?
>>    
>>
>
>There are several profiles (i.e., subsets) of 8601 which are arguably
>superior. (They have rules like don't permit basic, only extended,
>formats where both are available; don't permit "24" in the hour
>field, etc.)
>
>  
>

Thanks for the clarification, and apologies for my careless usage. Let's 
see if I;ve understood the position correctly.
(1) ISO 8601 defines a large  number of different formats for 
representing temporal expressions
(2) W3C has defined a subset of these for which named w3c datatypes exist
(3) the edw90 proposal for tei.data.temporal is to allow a combination 
of (some of or all?) the w3c datatypes plus a couple of others which Syd 
proposes we should allow for as well by means of a pattern

If that's correct, the only issue we have to argue about is whether or 
not the 'extras' are desirable enough to outweigh the possible 
inconvenience of supporting formats which off-the-shelf w3c-focussed 
implementations may not recognise.

I don't have a strong view on this: we could maybe distinguish 
tei.data.temporal and tei.data.temporal.extended if others do -- the 
distinction being that the former keeps to our original goal of mapping 
cleanly to w3c datatypes.

From lou.burnard at computing-services.oxford.ac.uk  Tue Sep 20 13:26:04 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 20 Sep 2005 18:26:04 +0100
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <17199.36356.769861.682886@emt.wwp.brown.edu>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>	<17197.33964.284995.434431@emt.wwp.brown.edu>	<432DA719.1010607@computing-services.oxford.ac.uk>
	<17199.36356.769861.682886@emt.wwp.brown.edu>
Message-ID: <4330462C.5050607@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>Again, it's only syntax, so I'm not claiming it is very important, but
>I'd like to set the record straight. I did not make up the syntax I am
>suggesting. It comes from NIST which takes most of it from SI. I
>daresay the Bureau International des Poids et Mesures and even the
>(US) National Institute of Standards and Technology has been doing
>this standardization of units stuff for a lot longer than either ISO
>or W3C, and they do a significantly better job.
>
Well, I may be wrong on this as much else, but I wasn't aware that 
either of the venerable bodies you mention had much of a say in the 
world of computer representations of datatypes.

From lou.burnard at computing-services.oxford.ac.uk  Tue Sep 20 13:52:33 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 20 Sep 2005 18:52:33 +0100
Subject: [tei-council] datatype issues (part 1) continued,,,
In-Reply-To: <17200.7023.583257.963017@emt.wwp.brown.edu>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<4326A09F.1000808@oucs.ox.ac.uk>
	<17200.7023.583257.963017@emt.wwp.brown.edu>
Message-ID: <43304C61.4010808@computing-services.oxford.ac.uk>

  Syd Bauman wrote:

>>The only places [tei.data.regexp] is used at present is for
>>attributes like metDecl which have as their value a string of
>>gobbledegook in some special syntax defined by the TEI.
>>    
>>
>
>Huh?? Even in P3 the pattern= attribute of <metDecl> was defined as a
>regular expression. In P3 and P4 the regular expression language used
>was that created by the TEI for its extended pointer syntax. In P5 we
>have made the move to using the W3C regular expression language
>instead. I think using a regexp here is and was a good idea,
>switching to W3C regexps is a good move, and this attribute should
>most certainly remain as is.
>
>
>  
>
OK, I am perfectly happy to restrict the kind of gobbledegook permitted 
for this datatype to a W3C-defined regular expression. That ought to fit 
with most kinds of gobbledegook we can come up with!

Is everyone happy with "regexp" as the name for it? how about 
"tei.data.pattern" ?

....

>  
>
>>I hesitated a long time over NMTOKEN and NCName. The former allows
>>hyphens but not underscore; the latter allows underscore but not
>>hyphen.
>>    
>>
>
>This is simply untrue. xsd:NMTOKEN maps to an XML NMTOKEN; xsd:NCName
>maps to an XML Namespaces NCName, which maps to an XML name except
>that colon is not allowed. Both allow hyphen, both allow underscore.
>xsd:NCName does not permit the string to *start* with a digit or
>punctuation character other than underscore.
>
>  
>
....

>  
>
>>I am open to persuasion that both tei.data.key and tei.data.ident
>>should have the same mapping; less to defining something which is
>>not either NMTOKEN or NCName.
>>    
>>
>
>In P4 most of these things were CDATA. I think making them a single
>token (normal sense of the word) is a really good idea -- if we could
>do so in P4 we should (we can't). I even think forbidding some kinds
>of non-whitespace characters would be a really good idea (e.g.,
>control characters, PUA characters, etc. See [1] for list). However,
>I'm not really sure of the advantage of telling people who would like
>to have things like "damaged/deliberate" and "damaged/accidental" as
>their values for reason= of <gap> that they cannot, just because W3C
>says that names of elements etc. can't have a slash. 
>
>  
>

This is really a tricky problem. It's kind of like the discussion about 
temporal expressions -- because the W3C datatypes don't exactly fit in 
with feelings about what a "name/ident/term" ought to be, it's tempting 
to invent our own definition as an alternative.

We can probably distinguish cases where the name *must* conform to W3C 
rules about identifiers -- if it's the name of an element it obviously 
has to follow constraint on what an XML name can be. If however it's a 
name we've made up this is less obviously the case, and the only 
constraint we'd probably want to put on it is that it shouldnt contain 
white space (else we can't have tei.data.names). But do we really want 
two kinds of tei.data.name?

>  
>
>>So in order of ascending tightness of constraint, we have
>>
>>tei.data.enumerated : the value is defined by a valList (type=closed)
>>tei.data.code : the value is defined by a pointer to something which 
>>                must exist
>>tei.data.key : the value is defined by an enumeration elsewhere e.g. a 
>>               database key
>>tei.data.ident : the value is a name or identifier of some kind but not 
>>                 necessarily enumerated or enumeratable
>>    
>>
>
>Where in your scheme to <valList>s of type= "open" and "semi" fit?
>I.e., are they still assigned the datatype tei.data.enumerated?
>  
>

My proposal is yes, they still have tei.data.enumerated.

>[1] A first cut at Unicode categories that should and should not be
>    permitted in tei.data.[token,ident,name,term]. 
>

Useful table. If we decide to invent our own kind of name, then it will 
be eminently sensible to base it on Unicode character categories.

From Syd_Bauman at Brown.edu  Tue Sep 20 14:10:31 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 14:10:31 -0400
Subject: [tei-council] datatypes -- syd's comments
In-Reply-To: <432D559B.9040205@computing-services.oxford.ac.uk>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17196.63555.177746.535394@emt.wwp.brown.edu>
	<432D559B.9040205@computing-services.oxford.ac.uk>
Message-ID: <17200.20631.233369.37067@emt.wwp.brown.edu>

> Ah! good point. But what is your recommendation?
> (a) decide whether probability shd be expressed as a number between 0 
> and 1 or as a number between 0 and 100 and then enforce one of them (if 
> so, which?)
> (b) allow both as alternatives, but require that the latter (1 to 100) 
> is always followed by a percent sign
> (c) leave things as proposed but note the constraint that numbers 
> between 0 and 1 must be expressed including a decimal point.
> 
> Being a lazy person, I have a slight preference for (c) though it's hard 
> to care very much about this:  the total number of attributes affected 
> in the current version of edw90 table is one (1)

Which one do you have in mind? I count six (6). In any case, I agree
it's not all that important, but have a strong preference for (b).

> I don't completely understand this comment since tei.data.numeric
> maps to xsd:decimal which does support floating point numbers. I
> assume what you mean is that such numbers can't be represented
> using the mantis+exponent (aka "scientific") notation. So it will
> permit "1.23456789" but not "2e0.134"

You are absolutely correct, I meant scientific notation.

> Again, I find very few real use cases in the edw90 table -- in fact
> the only case where I suppose it might be plausible to permit the
> scientific notation is the value attribute on <numeric> and <num>

But we know that there are users who need, or at least want, to be
able to use scientific notation. Especially since there is a W3C
datatype ready-made that supports it, I can see no reason to tell
them they can't use scientific notation.

> I can't see any use case where you might want to supply a
> percentage so I am not very enthusiastic about that either.

To me a percentage is just another way of representing a floating
point number. 145% is the same as 1.45, but some users will be
happier with the former. Not a bid deal in either case, I don't
think. 

> Would tei.data.probability suit them?

I don't understand the quetsion.

From Julia_Flanders at Brown.edu  Tue Sep 20 14:15:23 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Tue, 20 Sep 2005 14:15:23 -0400
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <4330449D.1070605@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
	<17188.14848.10373.576601@emt.wwp.brown.edu>
	<432c6d11beae57e26e676af90eb58055@loria.fr>
	<43248510.70009@oucs.ox.ac.uk>
	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>
	<17189.51427.518938.47525@emt.wwp.brown.edu>
	<4325CC68.1050400@computing-services.oxford.ac.uk>
	<17199.464.243621.414963@emt.wwp.brown.edu>
	<4330449D.1070605@computing-services.oxford.ac.uk>
Message-ID: <a0620070abf55fdfc4623@[128.148.157.102]>

It certainly seems to me that the TEI community is likely to need a 
representation of time that doesn't require misleading levels of 
precision. If I'm transcribing a journal whose entries include the 
time of day, I don't want to be forced to represent those times as 
accurate to the second. Am I right in guessing that this is an 
"extra"?

The option of an extended tei.data.temporal might be a good way to do this.

>Thanks for the clarification, and apologies for my careless usage. 
>Let's see if I;ve understood the position correctly.
>(1) ISO 8601 defines a large  number of different formats for 
>representing temporal expressions
>(2) W3C has defined a subset of these for which named w3c datatypes exist
>(3) the edw90 proposal for tei.data.temporal is to allow a 
>combination of (some of or all?) the w3c datatypes plus a couple of 
>others which Syd proposes we should allow for as well by means of a 
>pattern
>
>If that's correct, the only issue we have to argue about is whether 
>or not the 'extras' are desirable enough to outweigh the possible 
>inconvenience of supporting formats which off-the-shelf w3c-focussed 
>implementations may not recognise.
>
>I don't have a strong view on this: we could maybe distinguish 
>tei.data.temporal and tei.data.temporal.extended if others do -- the 
>distinction being that the former keeps to our original goal of 
>mapping cleanly to w3c datatypes.
>
>_______________________________________________
>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  Tue Sep 20 14:13:41 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 20 Sep 2005 19:13:41 +0100
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <17200.14028.790906.531915@emt.wwp.brown.edu>
References: <432CA353.9000105@computing-services.oxford.ac.uk>
	<17200.14028.790906.531915@emt.wwp.brown.edu>
Message-ID: <43305155.6090705@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>>1. add at place 
>>   addSpan at place
>>           -->  tei.data.enumerated
>>    
>>
>
>What do you propose the value list be? The list{} method proposed
>permits things like "opposite top left" (which is also permitted in
>P4). 
>
>  
>
I have no particular proposal. Any list I came up with only be advisory 
anyway.

>>   metDecl at type    
>>           -->  tei.data.enumerated
>>    
>>
>
>Again, we need to account for the fact that more than 1 "value" is
>permitted. Thus the value list would have to account for the various
>combinations. Luckily, since there are only 3 of 'em, in this case
>it's not hard:
>  met
>  real
>  rhyme
>  met;real
>  met;rhyme
>  real;rhyme
>  met;real;rhyme
>(In EDW90 I just copied what P4 says to do: "One or more of the three
>attribute names met, real, or rhyme, separated by whitespace", thus
>   list { ("met" | "real" | "rhyme")+ }
>Both P4 and EDW90 permit silly combinations like "met real met
>real".)
>
>  
>

so here;s a case where an enumeration is both possible and desirable. good!

>  
>
>>2. tei.pointerGroup at domains  
>>          -->  tei.data.pointers
>>    
>>
>
>I don't really see it as a plus to permit values that the prose says
>are invalid just to say we used a datatype directly. The EDW90
>recommendation matches the prose perfectly. (It is
>  list { tei.data.pointer, tei.data.pointers }
>.)
>
>  
>
>On the other hand, if everyone really thinks it is extremely
>important to use an abstract TEI datatype instead of a perfectly
>reasonable combination of 'em like the above, I suppose we could move
>the "must be 2 or more" check into a Schematron rule. Seems like the
>lesser of two evils, at least.
>
>  
>
Actually, I wonder if it might not be better to rethink this attribute 
into two?

> 
>  
>
>>3. schemaSpec at start
>>    specDesc at atts   
>>         --> tei.data.names
>>    
>>
>
>Again, why use a lax constraint when the proper one is readily
>available just to say you used a datatype? There are three possible
>declarations for tei.data.names on the table, and only one of them
>actually constrain this attribute properly:
>* list { xsd:NCName+ }  ->  does not permit "musicML:note", but since 
>                            there is an ns= attribute, I'm betting
>                            that's considered a good thing, right
>                            Sebastian?
>* list { xsd:NMTOKEN+ }  ->  permits "--notAllowed"
>* list { xsd:token { pattern="\S+" } }  ->  permits "${notAllowed}"
>
>If we decide tei.data.names should boil down to something other than
>the first, then I think we should just use the proper constraint
>without a TEI datatype and not fret it.
>
>  
>
Is this another instance of the particular problem that we;re using 
"name" sometimes to mean a NMTOKEN and sometimes not?

>>4. date at precision
>>       --> tei.data.certainty
>>    
>>
>
>I think this is a really bad idea. First off, <date> should probably
>not have a precision= attribute. The precision should be expressed in
>the value=. Furthermore, while I suppose vague terms like "high",
>"medium", and "low" are occasionally applied to the precision, it is
>much more common, and far more useful, to express the unit to which a
>measurement is precise. So if we really wanted to separate precision
>from the value=, we would want precision= of date to have values like
>"century", "decade", "year", "month", "week", and "day".
>
>  
>

I can't remember who suggested having "precision" as an explicit 
attribute on date. It does seem to overlap with the value attribute.  
Unless anyone wants to fight to the death for it, I propose we remove it.

>  
>
>>5. tei.datable at dateAttrib
>>       --> tei.data.enumerated
>>    
>>
>
>Yes, that's what is recommended: tei.enumerated with a value list of
>"datable" | "dated" | "unknown".
>
>  
>

OK

>  
>
>>6. locus at scheme
>>       --> tei.data.name
>>    
>>
>
>I presume that's because you don't want to argue with Matthew and
>David over the possible values? :-) Seriously, I don't currently
>really understood the purpose of this attribute. <locus> describes a
>location in the current manuscript, which (supposedly) has only one
>foliation scheme which should be described in //supportDesc/foliation
>(of which only 0 or 1 are permitted, right?). So what does scheme=
>buy us?
>
>  
>

Matthew? what is this attribute for? I'm too tired to remember...

>  
>
>>7. fragmentPattern at pat
>>      --> tei.data.notation
>>    
>>
>
>As above, if "tei.data.notation" is for "notations TEI made up", this
>doesn't belong.
>
>  
>

See other note.

>>8. schemaSpec at namespace
>>    elementSpec at ns (why isnt it "namespace" btw?)
>>       --> these could be xsd:uri as proposed, or tei.data.pointer, but 
>>maybe since they have to be
>>             real namespace names (i.e. "#foo" won't do) maybe shd be 
>>their own datatype?
>>    
>>
>
>Yes, all our ns= and namespace= attributes need to be brought into
>alignment. I don't care which.
>
>However, as I read the spec, "#foo" is a perfectly valid namespace.
>Stupid perhaps, but valid.
>
>  
>

OK, that solves that one.

>  
>
>>9.   tei.declarable at default
>>     tei.identifiable at predeclare
>>     metSym at terminal
>>     numeric at trunc
>>     binary at value                  
>>        --> are all xsd:boolean (so "unknown" not allowed) ; could just 
>>be tei.data.truthValue with extra rule
>>    
>>
>
>Could be. And at one point in the history of that EDW90 table, they
>were. But a week or two ago we agreed to go directly with
>xsd:boolean. 
>
>  
>

So we either have to have a pair of datatypes, one permitting "unknown" 
and one not, or we have to have an additional rule to exclude "unknown" 
in cases where it makes no sense, like these.

>  
>
>>10.  timeline at interval
>>       when at interval   
>>       --> tei.data.numeric | -1  (or think of a better way of
>>           doing the -1)
>>    
>>
>
>a) We'd go back to needing unit= (I'm not saying this is so horrible,
>   just want to make sure everyone understands the implications) and
>   violate the policy of using W3C Schema datatypes where applicable.
>
>b) All of the proposed declarations of tei.data.numeric already
>   permit -1.
>
>c) This permits all other negative numbers, which P4 explicitly
>   disallows. 
>
>d) If you meant 'tei.data.count', it won't do as fractions may be
>   needed. 
>
>e) Now that I think about it, the pattern EDW90 recommends has a
>   problem, too: it permits "-0.5".
>
>Thus, I am now leaning towards
>   xsd:long { minInclusive = "0" }  |  xsd:token "unknown"
>
>  
>

where did the "unknown" come from?  I think it shd remain 
tei.data.numeric, but with the constraint that it can't be smaller than -1

>  
>
>>11. several attributes with proposed  datypes of "xsd:NCName" -> 
>>    tei.data.name
>>    
>>
>
>Again, only if we agree tei.data.name -> xsd:NCName, of which I've
>yet to be convinced.
>
>  
>

see discussion elsewhere

>  
>
>>12. several attributes with proposed datatypes of
>>    "xsd:nonNegativeInteger" --> there are enough of these that I
>>    propose a new datatype "tei.data.count"
>>    
>>
>
>Fine with me, although I'm not sure what it gains for us.
>
>  
>

It gives us a meaningful TEI datatype.

>  
>
>>13. sense at level -> tei.data.count
>>    
>>
>
>Fine.
>(Just so everyone understands, the only real difference between
>  xsd:unsignedShort
>and
>  tei.data.count -> xsd:nonNegativeIngeger
>is that the software engineer designing an application that reads a
>TEI-encoded dictionary knows that in the former case whenever she
>comes across a level= of <sense> she need only set aside 16 bits to
>hold the value; with the latter she gets no such assurances. The
>other difference, that xsd:unsignedShort has a maximum value of
>65,535, isn't a practical problem.)
>
>_______________________________________________
>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  Tue Sep 20 17:41:39 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 21 Sep 2005 06:41:39 +0900
Subject: [tei-council] naming languages
In-Reply-To: <17200.17413.755118.837616@emt.wwp.brown.edu> (Syd Bauman's
	message of "Tue, 20 Sep 2005 13:16:53 -0400")
References: <432EAFFB.4080602@oucs.ox.ac.uk>
	<17200.17413.755118.837616@emt.wwp.brown.edu>
Message-ID: <ygfvf0v1koc.fsf@kanji.zinbun.kyoto-u.ac.jp>

Syd Bauman <Syd_Bauman at Brown.edu> writes:

>> oh look, this fun
>> http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-12.txt
>
> This, I believe, is a draft of the (much anticipated?) successor to
> RFC 3066. xml:lang= is already defined as "3066 or its successor",
> but IIRC there are sections of CH that will need to be updated when
> this becomes a real RFC.

Actually, this is the 12th version of a document that has been
discussed for years now.  We will have to see if they finish before P5
goes to press.

>
> Alejandro mentioned in Paris that 2-letter initial subcodes are
> preferred to 3-letter. I don't know if CH has been updated to reflect
> that yet. However, I just quickly checked this new draft, and it
> seems that when a 2-letter code is availalbe, it *must* be used, as
> the 3-letter version will not be in the IANA registry.

The draft of Chapter 4 is based on an earlier version, but so far I
have not seen anything that contradicts what we 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 Syd_Bauman at Brown.edu  Tue Sep 20 18:32:25 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 18:32:25 -0400
Subject: [tei-council] datatypes -- syd's comments
In-Reply-To: <432D559B.9040205@computing-services.oxford.ac.uk>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17196.63555.177746.535394@emt.wwp.brown.edu>
	<432D559B.9040205@computing-services.oxford.ac.uk>
Message-ID: <17200.36345.425511.930904@emt.wwp.brown.edu>

Lou wrote:
> ... tei.data.numeric maps to xsd:decimal which does support
> floating point numbers.

Right, you have instantiated tei.data.numeric as xsd:decimal, quite
in opposition to the recommendation, which was to use xsd:long |
xsd:double. I don't recall anyone presenting any argument as to why
xsd:decimal should be preferred. Not only does it not support
scientific notation, I believe it is harder for vendors to implement.
Did I miss something? (Always a possibility :-)

Arguments favoring xsd:decimal over xsd:double could be made (e.g.,
based on the approximation required of xsd:double), and I'd be happy
to entertain them. But as of now, I don't see why you made this
change.

---------

For those still wrapping their minds around these datatypes, I've
copied the following explanations from Eric van der Vlists book[1].

xsd:decimal --
    This datatype represents decimal numbers. The number of digits
    can be arbitrarily long (the datatype doesn't impose any
    restrictions), ... Leading and
    trailing zeros aren't considered significant and may be trimmed.
    The decimal separator is always a dot (.), and a leading sign (+
    or -) may be used, but any characters other than the 10 digits
    zero through nine are forbidden, including whitespace inside the
    value. ...

xsd:long --
    Contains an integer between -9223372036854775808 and
    9223372036854775807; i.e., the values that can be stored in a
    64-bit word.

xsd:double --
    ... represents IEEE ... double (64 bits) precision
    floating-point types. These store the values in the form of a
    mantissa and an exponent of a power of 2 (m x 2^e), allowing a large
    scale of numbers in a storage that has a fixed length.
    Fortunately, the lexical space doesn't require powers of 2 (in
    fact, it doesn't accept powers of 2), but instead uses a
    traditional scientific notation based on integer powers of 10.
    Because the value spaces (powers of 2) don't exactly match the
    values from the lexical space (powers of 10), the recommendation
    specifies that the closest value is taken. The consequence of
    this approximate matching is that float datatypes are the domain
    of approximation; most of the float values can't be considered
    exact and are approximate.
    These datatypes accept several special values: positive zero (0),
    negative zero (-0) (which is less than positive 0 but greater
    than any negative value); infinity (INF), which is greater than
    any value; negative infinity (-INF), which is less than any
    value; and "not a number" (NaN).

Note
----
[1] http://books.xmlschemata.org/relaxng/relax-CHP-8-SECT-1.html

From Syd_Bauman at Brown.edu  Tue Sep 20 18:38:53 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 18:38:53 -0400
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <4330449D.1070605@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
	<17188.14848.10373.576601@emt.wwp.brown.edu>
	<432c6d11beae57e26e676af90eb58055@loria.fr>
	<43248510.70009@oucs.ox.ac.uk>
	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>
	<17189.51427.518938.47525@emt.wwp.brown.edu>
	<4325CC68.1050400@computing-services.oxford.ac.uk>
	<17199.464.243621.414963@emt.wwp.brown.edu>
	<4330449D.1070605@computing-services.oxford.ac.uk>
Message-ID: <17200.36733.850364.960368@emt.wwp.brown.edu>

Lou Burnard writes:
> Thanks for the clarification, and apologies for my careless usage. Let's 
> see if I;ve understood the position correctly.
> (1) ISO 8601 defines a large  number of different formats for 
> representing temporal expressions
> (2) W3C has defined a subset of these for which named w3c datatypes exist
> (3) the edw90 proposal for tei.data.temporal is to allow a combination 
> of (some of or all?) the w3c datatypes plus a couple of others which Syd 
> proposes we should allow for as well by means of a pattern

Yes! That's it in a nutshell. (EDW90 does propose all the W3C
temporal types save duration be included; it only proposes the
addition of "time precise to the minute", but we may wish to add
"time precise to the hour" as well; I have not (yet) thought about
adding dateTime values (as opposed to time values) that are precise
to the hour or minute.)

One clarification, one caveat:

* Reminder to others that Lou's use of "pattern" in (3) is that of
  'W3C pattern facet', not a RelaxNG pattern. (The whole thing is a
  RelaxNG pattern.)

* In truth, there are quite a few other differences between W3C dates
  & times and ISO 8601 representations, which I didn't think we
  should concern ourselves with. Others may disagree, though. The
  list is at http://www.w3.org/TR/xmlschema-2/#deviantformats.

> If that's correct, the only issue we have to argue about is whether
> or not the 'extras' are desirable enough to outweigh the possible
> inconvenience of supporting formats which off-the-shelf
> w3c-focussed implementations may not recognise.

Since

a) I've yet to see any example of software that does something
   useful with "13:14:54" but barfs on "13:15", and
b) users aren't *required* to be imprecise

I think the extras are well worth it.

> I don't have a strong view on this: we could maybe distinguish
> tei.data.temporal and tei.data.temporal.extended if others do --
> the distinction being that the former keeps to our original goal of
> mapping cleanly to w3c datatypes.

A bit of a side-note: to me the proposed
   xsd:date | xsd:time | ... | xsd:token { pattern = "[whatever]" }
*is* mapping directly to W3C datatypes. (I had not contemplated this
"cleanly" business before :-) That is, nothing more than an average
RelaxNG validator that knows the W3C datatype library (e.g., jing,
xmllint) is needed to validate it.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Sep 20 20:47:25 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 21 Sep 2005 09:47:25 +0900
Subject: [tei-council] Problem with Roma or ODD
In-Reply-To: <432FD716.30702@oucs.ox.ac.uk> (Sebastian Rahtz's message of "Tue,
	20 Sep 2005 10:32:06 +0100")
References: <ygfaci9cn88.fsf@chwpb.local> <432EA195.8070109@oucs.ox.ac.uk>
	<ygfzmq8brsz.fsf@chwpb.local> <432FD716.30702@oucs.ox.ac.uk>
Message-ID: <ygfr7bj1c2q.fsf@kanji.zinbun.kyoto-u.ac.jp>

Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> writes:

> Christian Wittern wrote:
>
>>Thanks. Arrrgh.  If you say so.
>>
> you have to distinguish between authoring a module and
> authoring an extension schema.

Well, I thought it was obvious from the context.  I say, I want to
change <app>.  I then throw in a new @resp.  Since there is no existing
@resp, it seemed obvious to me that the change consists of adding this
new attribute.  Maybe I got too used to languages that attempt to
magically "do the right thing"...

>
>>  How about putting an example of this in the
>>ODD Manual?  
>>  
>>
> surely there is one???
>
There is an example that changes <div> to use a closed valList for
@type and one that removes attributes from the linking module.  Both
do make extensive use of the @mode attribute, so maybe that should be
enough to alert the reader to the fact that this might be necessary in
the case I was attempting.  However, I wonder that if it is really
necessary, would'nt it be helpful if the Schema would say so and allow
a parser to indicate the problem?

All the best,

Christian

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

-- 
 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 Sep 20 22:42:36 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Sep 2005 22:42:36 -0400
Subject: [tei-council] datatype issues (part 1) continued,,,
In-Reply-To: <43304C61.4010808@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
	<17188.14848.10373.576601@emt.wwp.brown.edu>
	<4326A09F.1000808@oucs.ox.ac.uk>
	<17200.7023.583257.963017@emt.wwp.brown.edu>
	<43304C61.4010808@computing-services.oxford.ac.uk>
Message-ID: <17200.51356.633809.345060@emt.wwp.brown.edu>

> OK, I am perfectly happy to restrict the kind of gobbledegook permitted 
> for this datatype to a W3C-defined regular expression. That ought to fit 
> with most kinds of gobbledegook we can come up with!

Indeed, we can enjoy years of spewing gobbledegook (and validating
it) to our hearts' content.

> Is everyone happy with "regexp" as the name for it? how about
> "tei.data.pattern" ?

I don't think I care. On the one hand, I think tei.data.pattern is
less annoying as a name, but on the other the word "pattern" is
getting quite overloaded these days.

> We can probably distinguish cases where the name *must* conform to
> W3C rules about identifiers -- if it's the name of an element it
> obviously has to follow constraint on what an XML name can be. If
> however it's a name we've made up this is less obviously the case,
> and the only constraint we'd probably want to put on it is that it
> shouldnt contain white space (else we can't have tei.data.names).
> But do we really want two kinds of tei.data.name?

We've already done this. Those that *must* confrom to W3C rules about
identifiers are listed in the table as having xsd:Name as their
proposed type; those that don't are listed as having tei.data.token
as their proposed type.

> My proposal is yes, they [open & semi valLists] still have
> tei.data.enumerated.

Check. Seems to make sense. Note, though, that my earlier proposal to
use e.g. "met;real" as type= of <metDecl> won't work, as ";" is not a
permissible character in an xsd:Name, and all of the values in a
<valList> must be xsd:Names, as they are expressed in the ODD as the
ident= of <valItem>. (I'm concerned that if we changed ident= of
<valList> to be tei.data.[token,term,name] and thus allow bizarre
characters, Sebastian might go postal and spray the entire Council
with blue paint.)

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Sep 21 01:32:34 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 21 Sep 2005 14:32:34 +0900
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <17200.36733.850364.960368@emt.wwp.brown.edu> (Syd Bauman's
	message of "Tue, 20 Sep 2005 18:38:53 -0400")
References: <432321F4.2070405@computing-services.oxford.ac.uk>
	<17188.14848.10373.576601@emt.wwp.brown.edu>
	<432c6d11beae57e26e676af90eb58055@loria.fr>
	<43248510.70009@oucs.ox.ac.uk>
	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>
	<17189.51427.518938.47525@emt.wwp.brown.edu>
	<4325CC68.1050400@computing-services.oxford.ac.uk>
	<17199.464.243621.414963@emt.wwp.brown.edu>
	<4330449D.1070605@computing-services.oxford.ac.uk>
	<17200.36733.850364.960368@emt.wwp.brown.edu>
Message-ID: <ygfll1r0yvh.fsf@kanji.zinbun.kyoto-u.ac.jp>

Syd Bauman <Syd_Bauman at Brown.edu> writes:

>
>> If that's correct, the only issue we have to argue about is whether
>> or not the 'extras' are desirable enough to outweigh the possible
>> inconvenience of supporting formats which off-the-shelf
>> w3c-focussed implementations may not recognise.
>
> Since
>
> a) I've yet to see any example of software that does something
>    useful with "13:14:54" but barfs on "13:15", and
> b) users aren't *required* to be imprecise
>
> I think the extras are well worth it.

I second that.  The requirement to give the @CREATEDATE up to the
seconds in METS regularily drives me crazy (I wonder who manages to
create such a record in just one second anyway).  It would be good to
save TEI users that headache.

>
> A bit of a side-note: to me the proposed
>    xsd:date | xsd:time | ... | xsd:token { pattern = "[whatever]" }
> *is* mapping directly to W3C datatypes. (I had not contemplated this
> "cleanly" business before :-) That is, nothing more than an average
> RelaxNG validator that knows the W3C datatype library (e.g., jing,
> xmllint) is needed to validate it.

This looks useful:-)

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  Wed Sep 21 04:23:51 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 21 Sep 2005 09:23:51 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <17200.36733.850364.960368@emt.wwp.brown.edu>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>	<17189.51427.518938.47525@emt.wwp.brown.edu>	<4325CC68.1050400@computing-services.oxford.ac.uk>	<17199.464.243621.414963@emt.wwp.brown.edu>	<4330449D.1070605@computing-services.oxford.ac.uk>
	<17200.36733.850364.960368@emt.wwp.brown.edu>
Message-ID: <43311897.3020303@computing-services.oxford.ac.uk>

Syd Bauman wrote:
> Yes! That's it in a nutshell. (EDW90 does propose all the W3C
> temporal types save duration be included; 

What was the reasoning for not including duration again?
> Since
> 
> a) I've yet to see any example of software that does something
>    useful with "13:14:54" but barfs on "13:15", and
> b) users aren't *required* to be imprecise
> 
> I think the extras are well worth it.

Let me just confirm this because my head must be off in the clouds, does ISO 
8601:2004 say that in order to have a valid time it has to be complete to the 
second?  I've not read the full ISO text (because like other ISO things it seems 
to cost money) so I've been relying on other people's explanations of it. 
However, the wikipedia article (which as we know might be completely wrong) says:

"It is also acceptable to omit elements to reduce precision. hh:mm, hhmm, and hh 
are all used."

This seems to indicate that you can say 13:15 or 13, etc.

Further, it even allows fractional notation:

"Fractions may also be used with all three of the time elements. These are 
indicated by using the decimal point (either a comma or dot). A fraction may 
only refer to the most precise component of a time representation -- that is, if 
you are indicated 14 hours, 30 and one half minutes, you do not include a 
seconds figure. You represent it as 14:30.5 or 1430.5. (You may replace the "." 
with a "," depending on the local custom.)"

Now, is the problem with the W3C Schema datatypes and the way they implement the 
ISO standard? I know there are some variations, but it seems like a pretty major 
one to insist on 13:14:54 instead of just 13:15.

Just want to make sure I'm understanding where the problem lies.

-James

From sebastian.rahtz at oucs.ox.ac.uk  Wed Sep 21 04:50:47 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 21 Sep 2005 09:50:47 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43311897.3020303@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>	<17189.51427.518938.47525@emt.wwp.brown.edu>	<4325CC68.1050400@computing-services.oxford.ac.uk>	<17199.464.243621.414963@emt.wwp.brown.edu>	<4330449D.1070605@computing-services.oxford.ac.uk>	<17200.36733.850364.960368@emt.wwp.brown.edu>
	<43311897.3020303@computing-services.oxford.ac.uk>
Message-ID: <43311EE7.8050100@oucs.ox.ac.uk>

James Cummings wrote:

>
> "It is also acceptable to omit elements to reduce precision. hh:mm,
> hhmm, and hh are all used."
>
> This seems to indicate that you can say 13:15 or 13, etc.
>
>
unfortunately, the W3C removed that flexibility

"The ?lexical space?
<http://www.w3.org/TR/xmlschema-2/#dt-lexical-space> of *dateTime*
consists of finite-length sequences of characters of the form: |'-'?
yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?|"

ISO 8601 has what we want, but it isn't implemented in the
schema-processing tools.

Pragmatically, whats the point of setting up datatypes and then immediately
have them knocked back down to unimplemented?

-- 
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 Sep 21 04:53:47 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 21 Sep 2005 09:53:47 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43311897.3020303@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>	<17189.51427.518938.47525@emt.wwp.brown.edu>	<4325CC68.1050400@computing-services.oxford.ac.uk>	<17199.464.243621.414963@emt.wwp.brown.edu>	<4330449D.1070605@computing-services.oxford.ac.uk>	<17200.36733.850364.960368@emt.wwp.brown.edu>
	<43311897.3020303@computing-services.oxford.ac.uk>
Message-ID: <43311F9B.8050407@oucs.ox.ac.uk>

<q>
[ISO 8601] <http://www.w3.org/TR/xmlschema-2/#ISO8601> supports a
variety of "truncated" formats in which some of the characters on the
left of specific formats, for example, the century, can be omitted.
Truncated formats are, in general, not permitted for the datatypes
defined in this specification </q>

-- 
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  Wed Sep 21 05:02:54 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 21 Sep 2005 10:02:54 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43311EE7.8050100@oucs.ox.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>	<17189.51427.518938.47525@emt.wwp.brown.edu>	<4325CC68.1050400@computing-services.oxford.ac.uk>	<17199.464.243621.414963@emt.wwp.brown.edu>	<4330449D.1070605@computing-services.oxford.ac.uk>	<17200.36733.850364.960368@emt.wwp.brown.edu>	<43311897.3020303@computing-services.oxford.ac.uk>
	<43311EE7.8050100@oucs.ox.ac.uk>
Message-ID: <433121BE.7050302@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
>>This seems to indicate that you can say 13:15 or 13, etc.
> unfortunately, the W3C removed that flexibility
> 
> "The ?lexical space?
> <http://www.w3.org/TR/xmlschema-2/#dt-lexical-space> of *dateTime*
> consists of finite-length sequences of characters of the form: |'-'?
> yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?|"
> 
> ISO 8601 has what we want, but it isn't implemented in the
> schema-processing tools.
> 
> Pragmatically, whats the point of setting up datatypes and then immediately
> have them knocked back down to unimplemented?

I see, I thought it might be the W3C who had removed the flexibility.
Is what we are suggesting then adding the ability to use 13:15?  Is there a way 
to still make this compatible with the W3 datatype?  (i.e. saying that if it 
only has one colon then it is really got :00 on the end.)  Or is this something 
that should be done in a processing stage?

Sorry for the naive questions, just trying to make sure I understand.

-James

From James.Cummings at computing-services.oxford.ac.uk  Wed Sep 21 05:08:51 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 21 Sep 2005 10:08:51 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43311F9B.8050407@oucs.ox.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>	<17189.51427.518938.47525@emt.wwp.brown.edu>	<4325CC68.1050400@computing-services.oxford.ac.uk>	<17199.464.243621.414963@emt.wwp.brown.edu>	<4330449D.1070605@computing-services.oxford.ac.uk>	<17200.36733.850364.960368@emt.wwp.brown.edu>	<43311897.3020303@computing-services.oxford.ac.uk>
	<43311F9B.8050407@oucs.ox.ac.uk>
Message-ID: <43312323.7070107@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> <q>
> [ISO 8601] <http://www.w3.org/TR/xmlschema-2/#ISO8601> supports a
> variety of "truncated" formats in which some of the characters on the
> left of specific formats, for example, the century, can be omitted.
> Truncated formats are, in general, not permitted for the datatypes
> defined in this specification </q>

Yes the bit that confused me was:

<q> Right truncated formats are also, in general, not permitted for the 
datatypes defined in this specification with the following exceptions: 
right-truncated representations of dateTime are used as lexical representations 
for date, gMonth, gYear.</q>

It seems silly to allow it for date, gMonth, and gYear, but not for time.  I 
understand there is a minor benefit in implementations, but the same type of 
logic has to exist for processing right-truncated date as time, so don't see 
that it is much of a saving.  *shrug* Oh well, I'm sure more able brains than 
mine have thought this through...

I'm still not convinced that xsd:duration should be excluded.

Apologies,

-James

From sebastian.rahtz at oucs.ox.ac.uk  Wed Sep 21 05:25:05 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 21 Sep 2005 10:25:05 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43312323.7070107@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>	<17189.51427.518938.47525@emt.wwp.brown.edu>	<4325CC68.1050400@computing-services.oxford.ac.uk>	<17199.464.243621.414963@emt.wwp.brown.edu>	<4330449D.1070605@computing-services.oxford.ac.uk>	<17200.36733.850364.960368@emt.wwp.brown.edu>	<43311897.3020303@computing-services.oxford.ac.uk>
	<43311F9B.8050407@oucs.ox.ac.uk>
	<43312323.7070107@computing-services.oxford.ac.uk>
Message-ID: <433126F1.4060102@oucs.ox.ac.uk>

James Cummings wrote:

>
> <q> Right truncated formats are also, in general, not permitted for
> the datatypes defined in this specification with the following
> exceptions: right-truncated representations of dateTime are used as
> lexical representations for date, gMonth, gYear.</q>
>
> It seems silly to allow it for date, gMonth, and gYear, but not for
> time.  I understand there is a minor benefit in implementations, but
> the same type of logic has to exist for processing right-truncated
> date as time, so don't see that it is much of a saving.  *shrug* Oh
> well, I'm sure more able brains than mine have thought this through...

I just shouted at two W3C folks about this and they shrugged their
shoulders and said "well you should see the problems timezones cause" :-}

-- 
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 Sep 21 06:36:26 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 21 Sep 2005 11:36:26 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <433121BE.7050302@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>	<17189.51427.518938.47525@emt.wwp.brown.edu>	<4325CC68.1050400@computing-services.oxford.ac.uk>	<17199.464.243621.414963@emt.wwp.brown.edu>	<4330449D.1070605@computing-services.oxford.ac.uk>	<17200.36733.850364.960368@emt.wwp.brown.edu>	<43311897.3020303@computing-services.oxford.ac.uk>
	<43311EE7.8050100@oucs.ox.ac.uk>
	<433121BE.7050302@computing-services.oxford.ac.uk>
Message-ID: <433137AA.6000600@oucs.ox.ac.uk>

James Cummings wrote:

>
> Is what we are suggesting then adding the ability to use 13:15?  Is
> there a way to still make this compatible with the W3 datatype?

you can say "xsd:dateTime | AComplexRegexp" if you want.

me, I would just swallow my objections and say "lets use XSD datatypes
and lobby them to improve it".
I see little point in saying "we want full ISO 8601 but we'll just
reduce it to CDATA for validation purposes".
babies, bathwater, etc.

> (i.e. saying that if it only has one colon then it is really got :00
> on the end.)

cant be done in a schema

>   Or is this something that should be done in a processing stage?

processing is another matter, this is about validation only

-- 
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 Sep 21 07:50:51 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 21 Sep 2005 13:50:51 +0200
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <433126F1.4060102@oucs.ox.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>	<17189.51427.518938.47525@emt.wwp.brown.edu>	<4325CC68.1050400@computing-services.oxford.ac.uk>	<17199.464.243621.414963@emt.wwp.brown.edu>	<4330449D.1070605@computing-services.oxford.ac.uk>	<17200.36733.850364.960368@emt.wwp.brown.edu>	<43311897.3020303@computing-services.oxford.ac.uk>	<43311F9B.8050407@oucs.ox.ac.uk>	<43312323.7070107@computing-services.oxford.ac.uk>
	<433126F1.4060102@oucs.ox.ac.uk>
Message-ID: <4331491B.7090106@oucs.ox.ac.uk>

The trouble with right truncation, then, is that you have to know the 
time zone before you know how to interpret the time? and the timezone 
indicator is the rightmost part being truncated?

Duh! they should have put the time zone indicator FIRST!

Sebastian Rahtz wrote:
> James Cummings wrote:
> 
> 
>><q> Right truncated formats are also, in general, not permitted for
>>the datatypes defined in this specification with the following
>>exceptions: right-truncated representations of dateTime are used as
>>lexical representations for date, gMonth, gYear.</q>
>>
>>It seems silly to allow it for date, gMonth, and gYear, but not for
>>time.  I understand there is a minor benefit in implementations, but
>>the same type of logic has to exist for processing right-truncated
>>date as time, so don't see that it is much of a saving.  *shrug* Oh
>>well, I'm sure more able brains than mine have thought this through...
> 
> 
> I just shouted at two W3C folks about this and they shrugged their
> shoulders and said "well you should see the problems timezones cause" :-}
> 
> 
> 

From sebastian.rahtz at oucs.ox.ac.uk  Wed Sep 21 08:02:22 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 21 Sep 2005 13:02:22 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <4331491B.7090106@oucs.ox.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>	<17189.51427.518938.47525@emt.wwp.brown.edu>	<4325CC68.1050400@computing-services.oxford.ac.uk>	<17199.464.243621.414963@emt.wwp.brown.edu>	<4330449D.1070605@computing-services.oxford.ac.uk>	<17200.36733.850364.960368@emt.wwp.brown.edu>	<43311897.3020303@computing-services.oxford.ac.uk>	<43311F9B.8050407@oucs.ox.ac.uk>	<43312323.7070107@computing-services.oxford.ac.uk>
	<433126F1.4060102@oucs.ox.ac.uk> <4331491B.7090106@oucs.ox.ac.uk>
Message-ID: <43314BCE.2070308@oucs.ox.ac.uk>

Lou Burnard wrote:

> The trouble with right truncation, then, is that you have to know the
> time zone before you know how to interpret the time? and the timezone
> indicator is the rightmost part being truncated?

not sure about that. I was not implying TZ was the *reason* for
disallowing truncation.

>
> Duh! they should have put the time zone indicator FIRST!

TZ was probably an afterthought and the implementation followed 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 Syd_Bauman at Brown.edu  Wed Sep 21 11:15:59 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 21 Sep 2005 11:15:59 -0400
Subject: [tei-council] tei.data.blah
In-Reply-To: <4329E16E.4060106@oucs.ox.ac.uk>
References: <4329DEA1.2050903@computing-services.oxford.ac.uk>
	<4329E16E.4060106@oucs.ox.ac.uk>
Message-ID: <17201.31023.728951.417524@emt.wwp.brown.edu>

> so call them macro.data.blah

Either is fine with me.

From sebastian.rahtz at oucs.ox.ac.uk  Wed Sep 21 11:41:04 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 21 Sep 2005 16:41:04 +0100
Subject: [tei-council] tei.data.blah
In-Reply-To: <17201.31023.728951.417524@emt.wwp.brown.edu>
References: <4329DEA1.2050903@computing-services.oxford.ac.uk>	<4329E16E.4060106@oucs.ox.ac.uk>
	<17201.31023.728951.417524@emt.wwp.brown.edu>
Message-ID: <43317F10.90700@oucs.ox.ac.uk>

Syd Bauman wrote:

>>so call them macro.data.blah
>>    
>>
>
>Either is fine with me.
>  
>
we could resolve this next week in the class meeting. I'd quite
like to spend 30 minutes then writing down the final naming rules
once and for all. Including names of modules, about which I am
not very happy :-}

-- 
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 Sep 21 14:37:16 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 21 Sep 2005 14:37:16 -0400
Subject: [tei-council] datatypes
In-Reply-To: <432D062B.1020908@oucs.ox.ac.uk>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17196.63555.177746.535394@emt.wwp.brown.edu>
	<432D062B.1020908@oucs.ox.ac.uk>
Message-ID: <17201.43100.255234.25151@emt.wwp.brown.edu>

> >* tei.data.numeric: the change removes support for a constituency
> >  that we already now about: those who need to enter floating point
> >  numbers.
> >
> I thought we went through this on TEI-L, and someone like
> M Beddows showed that the W3C datatypes did do everything
> needed?

Well, yes, there are W3C datatypes for everything we need (or close
enough): xsd:long will handle any integer up to an enormous size, and
xsd:double will handle most any fraction and supports scientific
notation (thus supporting numbers that are larger than can be
represented with xsd:long). But these aren't what's in the tagdoc.
xsd:decimal is. 

> > Furthermore, I still claim it makes sense to permit
> >  percentages
> >
> at first blush, I think a percentage is like a dimension,
> not a numeric (width=23cm, width=88%). mixing
> it in with numeric seems pretty weird. I may well be wrong.

That is exactly the same as (width=23cm, width=0.88). In the first
case, you have a quantity ("23") and a unit ("cm"). In the second
case you have a quantity ("88%" or "0.88", same thing) and no unit.
88% of what? In the world of web widths, the implied unit is usually
"the width of the window".

> > (One could argue, though, that the percentages should be limited
> > to 8 characters maximum (effectively limiting them to 3 or 4
> > decimal places of precision), so that any tei.data.numeric value
> > could fit into 64 bits.)
> >
> haven't we gone beyond worrying about number of bits
> we use up?

I'm not sure it's worth the bother, but if I understand correctly
most common math subroutine libraries have trouble with > 64 bit
numbers (which is why xsd:long and xsd:double are 64 bit!). There
exist fancy math libraries for handling things like infinite
precision base-10 numbers (i.e., xsd:decimal or unlimited-digit
percentages). However, my understanding is that they are not as
readily available, not available in some languages, and not easy to
install & use on all systems. I don't know. The only one I've ever
tried to install & use took me about 4 minutes. (Can't remember its
name though ...)

From lou.burnard at computing-services.oxford.ac.uk  Wed Sep 21 18:50:52 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 21 Sep 2005 23:50:52 +0100
Subject: [tei-council] Datatype : roundup
Message-ID: <4331E3CC.6020908@computing-services.oxford.ac.uk>

Rather than repeat with comment all the last few days messages, here is 
my take on where I think we now are.

1. No-one has dissented from the basic objective of providing tei 
datatypes which together cover the full range of current requirements as 
identified in Syd's edw90 table. There has been debate chiefly where the 
requirements identified there don't map tidily on to existing W3C 
datatypes.

2. Here are my proposals for resolving the currently debated issues:

a. tei.data.notation : renamed as tei.data.pattern and explicitly tied 
to regular  expression syntax [some debate is needed on how we define 
this: syd's original proposal suggested we should support only the W3C 
rather restricted version of regexps, i.e. the pattern has to be 
"anchored". Is that OK, or are we supporting apache-style 
perl-compatible regexps? or just the original syntax built into grep 
(but not egrep)?]

b. split the currently defined tei.data.name into two: tei.data.ident 
and tei.data.name  -- the former is used for those cases where the name 
concerned *must* be an XML-compatible name and maps to xsd:Name ; the 
latter for names of any kind excluding spaces (mapping to NMTOKEN?)

c. add a pattern to the list of alternatives proposed for 
tei.data.temporal which  supports  right-truncated times (just don't say 
i didnt tell you it'll all end in tears)

d. define  tei.data.probability as a value between 0 and 1 only

e. define tei.data. numeric as double, rather than decimal

I've now changed all the definitions accordingly, added a little bit 
more explication, and regenerated the HTML preview pages at 
http://www.tei-c.org/Drafts/DTYPES/

I am sure Council members are anxious to move on from this rather 
tedious subject to the exciting challenges of rethinking the class 
system, but it would be REALLY HELPFUL if they could give this latest 
iteration a quick read through and comment as to whether or not they think

-- the list of datatypes proposed is adequate to our needs (as 
summarized in edw90)
-- the definitions for them proposed are reasonably comprehensible and 
adequate

We could then move on...

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Sep 21 21:00:50 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 22 Sep 2005 10:00:50 +0900
Subject: [tei-council] Datatype : roundup
In-Reply-To: <4331E3CC.6020908@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Wed, 21 Sep 2005 23:50:52 +0100")
References: <4331E3CC.6020908@computing-services.oxford.ac.uk>
Message-ID: <ygfpsr1ykzh.fsf@kanji.zinbun.kyoto-u.ac.jp>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> Rather than repeat with comment all the last few days messages, here
> is my take on where I think we now are.
>
> 1. No-one has dissented from the basic objective of providing tei
>    datatypes which together cover the full range of current
>    requirements as identified in Syd's edw90 table. There has been
>    debate chiefly where the requirements identified there don't map
>    tidily on to existing W3C datatypes.
>
> 2. Here are my proposals for resolving the currently debated issues:
>
> a. tei.data.notation : renamed as tei.data.pattern and explicitly tied
> to regular  expression syntax [some debate is needed on how we define
> this: syd's original proposal suggested we should support only the W3C
> rather restricted version of regexps, i.e. the pattern has to be
> "anchored". Is that OK, or are we supporting apache-style
> perl-compatible regexps? or just the original syntax built into grep
> (but not egrep)?]

Why on earth has nobody yet tought of standardizing regexes?  You
surely to not have to worry about truncated timezones there...

However, thinking of implementation in validators, it probably it the
only viable option to go with the W3C.

>
> b. split the currently defined tei.data.name into two: tei.data.ident
> and tei.data.name  -- the former is used for those cases where the
> name concerned *must* be an XML-compatible name and maps to xsd:Name ;
> the latter for names of any kind excluding spaces (mapping to
> NMTOKEN?)
>
> c. add a pattern to the list of alternatives proposed for
> tei.data.temporal which  supports  right-truncated times (just don't
> say i didnt tell you it'll all end in tears)

Please, please do so!!

> d. define  tei.data.probability as a value between 0 and 1 only

+1

>
> -- the list of datatypes proposed is adequate to our needs (as
>    summarized in edw90)
> -- the definitions for them proposed are reasonably comprehensible and
>    adequate
>

I see you folded this already into "The Guidelines", but probably
something went wrong during the conversion, there are things like
attributes on <> and some quotes also seem amiss.

Apart from that and apart from the fact that this is like looking at a
list of words and then asking "Is this all you will ever need to talk
to each other", it seems sufficient to this tired brain.

All the best,

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  Thu Sep 22 01:58:21 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 22 Sep 2005 01:58:21 -0400
Subject: [tei-council] Datatype : roundup
In-Reply-To: <4331E3CC.6020908@computing-services.oxford.ac.uk>
References: <4331E3CC.6020908@computing-services.oxford.ac.uk>
Message-ID: <17202.18429.528819.465597@emt.wwp.brown.edu>

Thank you for the succinct summary, Lou. I'm going to address it
quickly now, but can't really give it thorough treatment.

> 1. No-one has dissented from the basic objective of providing tei
> datatypes which together cover the full range of current
> requirements as identified in Syd's edw90 table.

I'm not 100% sure on what you mean by this. I thought we had agreed
*not* to have a TEI datatype for xsd:boolean. I also thought it might
be worth not bothering with the indirection for xsd:nonNegativeInteger
and xsd:Name. At the moment I don't care very much, but I think some
users really get fed up with indirection, and when it's almost
completely pointless ...

> a. tei.data.notation : renamed as tei.data.pattern and explicitly
> tied to regular expression syntax

Sounds good to me.

> [some debate is needed on how we define this: syd's original
> proposal suggested we should support only the W3C rather restricted
> version of regexps, i.e. the pattern has to be "anchored". Is that
> OK, or are we supporting apache-style perl-compatible regexps? or
> just the original syntax built into grep (but not egrep)?]

We initially went with W3C some 2 or 3 years ago using the (perhaps
flawed) logic that it was a regular expression language that any XML
software would have to know in order to support the W3C Schema
"pattern" facet anyway. And although they are anchored, I think the
characterization of them as "restricted" is very misleading. The W3C
regular expression language is basically the Perl language with quite
a few useful extensions like
  \i == matches any char that's legal as an initial char in an
        xsd:Name  
  \c == matches any char that's legal in an xsd:Name
  \p{Po} == matches any char from the PUA

> b. split the currently defined tei.data.name into two:
> tei.data.ident and tei.data.name -- the former is used for those
> cases where the name concerned *must* be an XML-compatible name and
> maps to xsd:Name ; the latter for names of any kind excluding
> spaces (mapping to NMTOKEN?)

I like tei.data.ident (although again, it's not clear to me that
abstracting to a TEI datatype gains us much -- I guess the schema
extender who knows ahead of time she will never want to use colonized
names or names > 31 chars long could re-declare it as
  xsd:NCName { maxLength = "31" }
so I'll take that back; I'm all in favor.)

As for tei.data.name:
* the name is really bad; I'd prefer to live with the confusion of
  tei.data.token. (Remember, the string "xsd:token" will only appear
  a few times in all of P5; in the declarations of at most half a
  dozen datatypes.)
* I think we should probably be more permissive than NMTOKEN.

> c. add a pattern to the list of alternatives proposed for
> tei.data.temporal which supports right-truncated times (just don't
> say i didnt tell you it'll all end in tears)

OK, I won't say that. But what do you think could happen to make it
end in tears?

> d. define  tei.data.probability as a value between 0 and 1 only

I really don't see why not permit percentages. Users had the choice
in P4, when we couldn't even validate it. Now we can.

> e. define tei.data. numeric as double, rather than decimal

Oh dear. This is the painful one. I was almost hoping to not have to
tackle this. "Tackle what?" you ask. If I understand correctly, Lou
is now proposing to declare that all TEI numbers be an xsd:double
rather than the proposed xsd:double | xsd:long.

What's the difference? Since xsd:double can represent a *much* larger
number range than xsd:long, why would anyone care? Because it doesn't
represent it exactly. In order to gain its incredible range, the trade
off is precision. When I wrote EDW90 I had no idea how precise an
xsd:double is (it's not easy to find out), but I knew it was less
than the 19 digits you can get for integers from xsd:long. I figured
it's not hard for an application to tell the difference (if it has a
dot or a letter e, it's an xsd:double, otherwise it's an xsd:long),
so why not just use 'em both?

But (Lou seems to be asking) do we really need the xsd:long? I've
just spent some time delving into this, and it seems that an
xsd:double can represent numbers with up to ~16 significant
digits.[1] So my addition of xsd:long to our datatype seems to only
support those users who wish to precisely indicate integers between
1e16 (10,000,000,000,000,000) and 1e19 (10,000,000,000,000,000,000).
That is to say, if you wanted to record the combined gross domestic
product of the EU and USA to the penny, you *might* need an xsd:long
to do so. If you don't mind representing it in euros or dollars, an
xsd:double will do. (I have never seen a representation of GDP that
could not be expressed in a 32-bit floating point number, e.g.
$5.625e13 is the CIA estimate for 2004.)

The executive summary is that 
* I now think xsd:double alone will do
* Someone should check my math on this, it is quite complicated stuff 
* If someone has a use-case where we'd want to represent a 16-digit
  or greater integer precisely (i.e., to the 1s place), we should
  reconsider xsd:long. (Yes, a credit card number along with the
  security code on the back is 19 digits long, but it's not really a
  number, it's a string that just happens to be composed of only
  digits.)

Note
----
[1]
http://cch.loria.fr/documentation/IEEE754/numerical_comp_guide/ncg_math.doc.html#555

From lou.burnard at computing-services.oxford.ac.uk  Thu Sep 22 05:19:11 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 22 Sep 2005 10:19:11 +0100
Subject: [tei-council] Datatype : roundup
In-Reply-To: <17202.18429.528819.465597@emt.wwp.brown.edu>
References: <4331E3CC.6020908@computing-services.oxford.ac.uk>
	<17202.18429.528819.465597@emt.wwp.brown.edu>
Message-ID: <4332770F.9020209@computing-services.oxford.ac.uk>

Syd Bauman wrote:
> Thank you for the succinct summary, Lou. I'm going to address it
> quickly now, but can't really give it thorough treatment.
> 
> 
> 
>>1. No-one has dissented from the basic objective of providing tei
>>datatypes which together cover the full range of current
>>requirements as identified in Syd's edw90 table.
> 
> 
> I'm not 100% sure on what you mean by this. I thought we had agreed
> *not* to have a TEI datatype for xsd:boolean. I also thought it might
> be worth not bothering with the indirection for xsd:nonNegativeInteger
> and xsd:Name. At the moment I don't care very much, but I think some
> users really get fed up with indirection, and when it's almost
> completely pointless ...

It is not complettely pointless. It provide us with a space in which to 
define TEI-specific semantics in addition to the basic datatyping. So we 
can say not just this is a number, but this is a number which is used to 
count something.

> 
> 
> 
>>[some debate is needed on how we define this: syd's original
>>proposal suggested we should support only the W3C rather restricted
>>version of regexps, i.e. the pattern has to be "anchored". Is that
>>OK, or are we supporting apache-style perl-compatible regexps? or
>>just the original syntax built into grep (but not egrep)?]
> 
> 
> We initially went with W3C some 2 or 3 years ago using the (perhaps
> flawed) logic that it was a regular expression language that any XML
> software would have to know in order to support the W3C Schema
> "pattern" facet anyway.

I am not sure who the "we" in that sentence is -- possibly the SO work 
group?

And although they are anchored, I think the
> characterization of them as "restricted" is very misleading.

Well, as one who has done a lot of programming in various 
pattern-matching languages, I think the characterization is not VERY 
misleading. But it hardly matters... I am quite happy for us to stick 
with the W3C regexp language if others agree, for the good pragmatic 
reason given above, provided that we make explicit what its shortcomings 
are.

  The W3C
> regular expression language is basically the Perl language with quite
> a few useful extensions like
>   \i == matches any char that's legal as an initial char in an
>         xsd:Name  
>   \c == matches any char that's legal in an xsd:Name
>   \p{Po} == matches any char from the PUA

Aaargh, so it's not even a clean subset!

> 
> 
> so I'll take that back; I'm all in favor.)
> 
Good

> As for tei.data.name:
> * the name is really bad; I'd prefer to live with the confusion of
>   tei.data.token. (Remember, the string "xsd:token" will only appear
>   a few times in all of P5; in the declarations of at most half a
>   dozen datatypes.)

That's irrelevant to the issue here: we want people to use the TEI name 
and not be confused when they talk to others about it. No-one has yet 
proposed a better name than name.

> * I think we should probably be more permissive than NMTOKEN.
> 

We can tweak the definition if you like, but I don't understand why you 
would want to.

> 
> 
>>c. add a pattern to the list of alternatives proposed for
>>tei.data.temporal which supports right-truncated times (just don't
>>say i didnt tell you it'll all end in tears)
> 
> 
> OK, I won't say that. But what do you think could happen to make it
> end in tears?
> 
> 
(a) difficulties in implementation
(b) confusion caused by lack of timezone information

> 
>>d. define  tei.data.probability as a value between 0 and 1 only
> 
> 
> I really don't see why not permit percentages. Users had the choice
> in P4, when we couldn't even validate it. Now we can.
> 
> 

simplicity, clarity, precision...

> 
>>e. define tei.data. numeric as double, rather than decimal
>

I think this is a mistake, actually. Decimal was a better choice, since 
it can represent any number, real or integer, no matter how big. It 
means you can;t use scientific notation, which someone folks on TEI-L 
suddenly woke up and asked for. I now think maybe we should have a 
different datatype for that.

Credit card numbers, by the way, are tei.data.ident, clearly.

> 
> Oh dear. This is the painful one. I was almost hoping to not have to
> tackle this. "Tackle what?" you ask. If I understand correctly, Lou
> is now proposing to declare that all TEI numbers be an xsd:double
> rather than the proposed xsd:double | xsd:long.
> 
> What's the difference? Since xsd:double can represent a *much* larger
> number range than xsd:long, why would anyone care? Because it doesn't
> represent it exactly. In order to gain its incredible range, the trade
> off is precision. When I wrote EDW90 I had no idea how precise an
> xsd:double is (it's not easy to find out), but I knew it was less
> than the 19 digits you can get for integers from xsd:long. I figured
> it's not hard for an application to tell the difference (if it has a
> dot or a letter e, it's an xsd:double, otherwise it's an xsd:long),
> so why not just use 'em both?
> 
> But (Lou seems to be asking) do we really need the xsd:long? I've
> just spent some time delving into this, and it seems that an
> xsd:double can represent numbers with up to ~16 significant
> digits.[1] So my addition of xsd:long to our datatype seems to only
> support those users who wish to precisely indicate integers between
> 1e16 (10,000,000,000,000,000) and 1e19 (10,000,000,000,000,000,000).
> That is to say, if you wanted to record the combined gross domestic
> product of the EU and USA to the penny, you *might* need an xsd:long
> to do so. If you don't mind representing it in euros or dollars, an
> xsd:double will do. (I have never seen a representation of GDP that
> could not be expressed in a 32-bit floating point number, e.g.
> $5.625e13 is the CIA estimate for 2004.)
> 
> The executive summary is that 
> * I now think xsd:double alone will do
> * Someone should check my math on this, it is quite complicated stuff 
> * If someone has a use-case where we'd want to represent a 16-digit
>   or greater integer precisely (i.e., to the 1s place), we should
>   reconsider xsd:long. (Yes, a credit card number along with the
>   security code on the back is 19 digits long, but it's not really a
>   number, it's a string that just happens to be composed of only
>   digits.)
> 
> Note
> ----
> [1]
> http://cch.loria.fr/documentation/IEEE754/numerical_comp_guide/ncg_math.doc.html#555
> 
> _______________________________________________
> 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 Sep 22 06:16:49 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 22 Sep 2005 11:16:49 +0100
Subject: [tei-council] Datatype : roundup
In-Reply-To: <4332770F.9020209@computing-services.oxford.ac.uk>
References: <4331E3CC.6020908@computing-services.oxford.ac.uk>	<17202.18429.528819.465597@emt.wwp.brown.edu>
	<4332770F.9020209@computing-services.oxford.ac.uk>
Message-ID: <43328491.2030105@computing-services.oxford.ac.uk>

Lou Burnard wrote:
>>> [some debate is needed on how we define this: syd's original
>>> proposal suggested we should support only the W3C rather restricted
>>> version of regexps, i.e. the pattern has to be "anchored". Is that
>>> OK, or are we supporting apache-style perl-compatible regexps? or
>>> just the original syntax built into grep (but not egrep)?]
>>
>> We initially went with W3C some 2 or 3 years ago using the (perhaps
>> flawed) logic that it was a regular expression language that any XML
>> software would have to know in order to support the W3C Schema
>> "pattern" facet anyway.
> 
> Well, as one who has done a lot of programming in various 
> pattern-matching languages, I think the characterization is not VERY 
> misleading. But it hardly matters... I am quite happy for us to stick 
> with the W3C regexp language if others agree, for the good pragmatic 
> reason given above, provided that we make explicit what its shortcomings 
> are.

I don't know the differences between the various regexp standards out there, but 
on the face of it sounds like a good idea to stick to W3C in this regard.  A 
quick trawl round the  XSLT2 spec shows that its regex's seem to be (as one 
would expect) based on the XPath2, which bases them on those in W3C Schema.  So 
that at least looks like some consistency, and I didn't notice any big warning 
signs, but someone correct me if I'm wrong.

>>> c. add a pattern to the list of alternatives proposed for
>>> tei.data.temporal which supports right-truncated times (just don't
>>> say i didnt tell you it'll all end in tears)
>> OK, I won't say that. But what do you think could happen to make it
>> end in tears?
> (a) difficulties in implementation
> (b) confusion caused by lack of timezone information

Is there any sensible way to add timezone information to right-truncated times?

Although it bothers me, I think in the end I'd be willing to add :00 for seconds 
to any time recorded, if I were indeed recording times.

-James

From Syd_Bauman at Brown.edu  Thu Sep 22 06:35:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 22 Sep 2005 06:35:11 -0400
Subject: [tei-council] Datatype : roundup
In-Reply-To: <4332770F.9020209@computing-services.oxford.ac.uk>
References: <4331E3CC.6020908@computing-services.oxford.ac.uk>
	<17202.18429.528819.465597@emt.wwp.brown.edu>
	<4332770F.9020209@computing-services.oxford.ac.uk>
Message-ID: <17202.35039.694032.99577@emt.wwp.brown.edu>

> I am not sure who the "we" in that sentence is -- possibly the SO
> work group?

Yup, sorry; I should have been more explicit. SO decided on the W3C
regular expression language, and Council approved.

> Well, as one who has done a lot of programming in various
> pattern-matching languages, I think the characterization is not
> VERY misleading. But it hardly matters... I am quite happy for us
> to stick with the W3C regexp language if others agree, for the good
> pragmatic reason given above, provided that we make explicit what
> its shortcomings are.

What shortcomings do you have in mind? (Implicit anchoring, while a
difference, can hardly be called a shortcoming.)

> Aaargh, so it's not even a clean subset!

It is not a subset at all (at least, not of any language I'm aware
of).

> > As for tei.data.name:
> > * the name is really bad; I'd prefer to live with the confusion of
> >   tei.data.token. (Remember, the string "xsd:token" will only appear
> >   a few times in all of P5; in the declarations of at most half a
> >   dozen datatypes.)
> 
> That's irrelevant to the issue here: we want people to use the TEI
> name and not be confused when they talk to others about it. No-one
> has yet proposed a better name than name.

I disagree; I think *you* proposed a better name than 'name', when
you proposed 'token'. The latter is mildly confusing due to W3C's
misuse; the former is outright misleading. The attributes of this
type (type=, subtype=; to= & from= of <locus>; scope= of <handNote>,
etc.) don't really have names as their values in any sense of the
word.

> > * I think we should probably be more permissive than NMTOKEN.
> 
> We can tweak the definition if you like, but I don't understand why
> you would want to.

Because I don't think we should be limiting users to letters, digits,
dot, hyphen, underscore, and colon for the values of these
attributes, e.g. cref=, extent=, reason=, where= of <move>, real=,
met=, rhyme=. Although for some it does make sense (name= of <equiv>,
included= of <witness>); perhaps these should be moved to
tei.data.ident?

> (a) difficulties in implementation

Why is it so much harder to implement? I haven't completely worked
through the algorithms for comparison of dateTimes and addition of
duration to dateTime, but neither seems to depend on precision to the
second. Did I miss something?

> (b) confusion caused by lack of timezone information

Good point. We should make timezone information possible on
right-truncated times, of course.

> > I really don't see why not permit percentages. Users had the
> > choice in P4, when we couldn't even validate it. Now we can.
> > 
> simplicity, clarity, precision...

While I suppose it is simpler for software writers to have 1 system
rather than 2, there is nothing more clear nor more precise about
"0.824" than "82.4%". While I have some sympathy with the idea of
reducing choices for users, this is one place where I think users
like the choice.

> I think this is a mistake, actually. Decimal was a better choice,
> since it can represent any number, real or integer, no matter how
> big. It means you can;t use scientific notation, which someone
> folks on TEI-L suddenly woke up and asked for. 

So you think we have more users who really want to represent numbers
with greater than 16 (decimal) digits of precision than users who
want to represent numbers in scientific notation? As I had hoped my
example would demonstrate, that much precision is not something we
humans generally deal with.

> I now think maybe we should have a different datatype for
> [scientific notation].

If we split scientific notation out to a different datatype, won't we
need a disjunction of the two datatypes in most if not all instances
anyway? And the disjunction (whether of two separate TEI datatypes or
of two xsd: datatypes inside a TEI datatype) might be a bit confusing
for implementers. But it shouldn't be impossible to deal with (could
always just assume that if it's not in scientific notation, it is an
xsd:decimal).

> Credit card numbers, by the way, are tei.data.ident, clearly.

I thought you wanted tei.data.ident to be xsd:Name -- credit card
numbers start with a digit, and thus are invalid xsd:Names. They'd be
fine as tei.data.[name|token], but once again the name "name" doesn't
make sense. (Alternative one could insist that they start with a "V"
or "M" or whatever :-)

From Syd_Bauman at Brown.edu  Thu Sep 22 07:08:21 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 22 Sep 2005 07:08:21 -0400
Subject: [tei-council] Datatype : roundup
In-Reply-To: <43328491.2030105@computing-services.oxford.ac.uk>
References: <4331E3CC.6020908@computing-services.oxford.ac.uk>
	<17202.18429.528819.465597@emt.wwp.brown.edu>
	<4332770F.9020209@computing-services.oxford.ac.uk>
	<43328491.2030105@computing-services.oxford.ac.uk>
Message-ID: <17202.37029.381447.317880@emt.wwp.brown.edu>

> Is there any sensible way to add timezone information to
> right-truncated times?

Yes, although it's no longer trivial. The regexp in the following
schema 
* does not permit the "military" timezone designators except for "Z",
  because that's what W3C does
* requires minutes in the non-"Z" time zone designators, because W3C
  does
* does permit minutes other than "00" and "30" in the minutes field
  of time zone designators, even though none exist, because that's what
  W3C does (I'm of half a mind to fix this oversight of theirs)
* does permit time zones greater than 14, because it's a royal pain
  to limit 'em, and W3C's own syntax doesn't (although semantically
  it's still an error, I think) -- I mostly copied the regexp from
  the W3C spec
* does not permit the hour to be "24", because that's a really
  really bad idea (one of 8601:2000's greatest failings, and the
  proof that it was written by committee)

--------- begin tim.rnc ---------
# test 'tim', a right-truncated 'time' :-)
start = element tests { test+ }
test = element test {
   attribute tim { xsd:token { pattern =
      "([01][0-9]|2[0-3])(:[0-5][0-9])?(((\+|-)[01][0-9]:[0-5][0-9])|Z)?"
   }
   }
}
--------- end tim.rnc ---------

--------- begin tim.xml ---------
<?xml version="1.0" encoding="UTF-8" ?>
<!-- should be valid -->
<tests>
  <test tim="10:32-04:00"/>
  <test tim="11+05:00"/>
  <test tim="12:34Z"/>
  <test tim="13Z"/>
</tests>
--------- end tim.xml ---------

--------- begin TIM.xml ---------
<?xml version="1.0" encoding="UTF-8" ?>
<!-- each attribute value should be invalid -->
<tests>
  <test tim="10:32-04"/>
  <test tim="11+98:00"/>
  <test tim="12:34J"/>
  <test tim="13K"/>
  <test tim="145"/>
  <test tim="15:16:17"/> <!-- valid against xsd:time -->
  <test tim="16:61+00:00"/>    <!-- no leap minutes! -->
  <test tim="17:98"/>
  <test tim="24:00"/>
  <test tim="32:00Z"/>
</tests>
--------- end TIM.xml ---------

From lou.burnard at computing-services.oxford.ac.uk  Thu Sep 22 09:35:06 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 22 Sep 2005 14:35:06 +0100
Subject: [tei-council] Datatype : roundup
In-Reply-To: <17202.35039.694032.99577@emt.wwp.brown.edu>
References: <4331E3CC.6020908@computing-services.oxford.ac.uk>	<17202.18429.528819.465597@emt.wwp.brown.edu>	<4332770F.9020209@computing-services.oxford.ac.uk>
	<17202.35039.694032.99577@emt.wwp.brown.edu>
Message-ID: <4332B30A.4060700@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>>>As for tei.data.name:
>>>* the name is really bad; I'd prefer to live with the confusion of
>>>  tei.data.token. (Remember, the string "xsd:token" will only appear
>>>  a few times in all of P5; in the declarations of at most half a
>>>  dozen datatypes.)
>>>      
>>>
>>That's irrelevant to the issue here: we want people to use the TEI
>>name and not be confused when they talk to others about it. No-one
>>has yet proposed a better name than name.
>>    
>>
>
>I disagree; I think *you* proposed a better name than 'name', when
>you proposed 'token'. The latter is mildly confusing due to W3C's
>misuse; the former is outright misleading. The attributes of this
>type (type=, subtype=; to= & from= of <locus>; scope= of <handNote>,
>etc.) don't really have names as their values in any sense of the
>word.
>  
>

Which attributes get which datatype is a moveable feast, of course. But 
I stand by the assertion that no-one has yet proposed a better name for 
this one. Token is not acceptable because of the confusion already noted.

>  
>
>>>* I think we should probably be more permissive than NMTOKEN.
>>>      
>>>
>>We can tweak the definition if you like, but I don't understand why
>>you would want to.
>>    
>>
>
>Because I don't think we should be limiting users to letters, digits,
>dot, hyphen, underscore, and colon for the values of these
>attributes, e.g. cref=, extent=, reason=, where= of <move>, real=,
>met=, rhyme=. Although for some it does make sense (name= of <equiv>,
>included= of <witness>); perhaps these should be moved to
>tei.data.ident?
>
>  
>

My proposal is to offer a range of choices: name, ident, enumerated. I 
have yet to see any argument for a fourth category, so that's progress. 
I still think that NMTOKEN is a good choice as representation for the 
first of these: yes, we are constraining people not to include weird 
punctuation characters in  their names. Why is that a bad idea? We are 
also getting some sensible validation for free!

>
>  
>
>>>I really don't see why not permit percentages. Users had the
>>>choice in P4, when we couldn't even validate it. Now we can.
>>>
>>>      
>>>
>>simplicity, clarity, precision...
>>    
>>
>
>While I suppose it is simpler for software writers to have 1 system
>rather than 2, there is nothing more clear nor more precise about
>"0.824" than "82.4%". While I have some sympathy with the idea of
>reducing choices for users, this is one place where I think users
>like the choice.
>  
>

I see no evidence for this asserttion at all. Since both representations 
mean exactly the same thing, and are exactly inter-convertible, I think 
it just looks silly not to come down on one side of the fence or the 
other. 

>
>  
>
>>I think this is a mistake, actually. Decimal was a better choice,
>>since it can represent any number, real or integer, no matter how
>>big. It means you can;t use scientific notation, which someone
>>folks on TEI-L suddenly woke up and asked for. 
>>    
>>
>
>So you think we have more users who really want to represent numbers
>with greater than 16 (decimal) digits of precision than users who
>want to represent numbers in scientific notation? As I had hoped my
>example would demonstrate, that much precision is not something we
>humans generally deal with.
>
>  
>

No, I think that if there are 10 people in the world who want to use a 
numeric datatype, 8 of them might  want to use what one might call 
unscientific notation, and 9.9 of them will want to represent values 
representable to an accuracy less than 8 decimal digits!

>>I now think maybe we should have a different datatype for
>>[scientific notation].
>>    
>>
>
>If we split scientific notation out to a different datatype, won't we
>need a disjunction of the two datatypes in most if not all instances
>anyway? And the disjunction (whether of two separate TEI datatypes or
>of two xsd: datatypes inside a TEI datatype) might be a bit confusing
>for implementers. But it shouldn't be impossible to deal with (could
>always just assume that if it's not in scientific notation, it is an
>xsd:decimal).
>  
>

I dont think that sort of "assumption" is something an XML validator can 
do, is it?  But we could certainly say the numeric datatype maps onto 
xsd:decimal|xsd:float if that would make you happy. 

>
>  
>
>>Credit card numbers, by the way, are tei.data.ident, clearly.
>>    
>>
>
>I thought you wanted tei.data.ident to be xsd:Name -- credit card
>numbers start with a digit, and thus are invalid xsd:Names. They'd be
>fine as tei.data.[name|token], but once again the name "name" doesn't
>make sense. (Alternative one could insist that they start with a "V"
>or "M" or whatever :-)
>

Ah yes, good point.

From sebastian.rahtz at oucs.ox.ac.uk  Thu Sep 22 06:27:00 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 11:27:00 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <a0620070abf55fdfc4623@[128.148.157.102]>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>	<17189.51427.518938.47525@emt.wwp.brown.edu>	<4325CC68.1050400@computing-services.oxford.ac.uk>	<17199.464.243621.414963@emt.wwp.brown.edu>	<4330449D.1070605@computing-services.oxford.ac.uk>
	<a0620070abf55fdfc4623@[128.148.157.102]>
Message-ID: <433286F4.4050107@oucs.ox.ac.uk>

On dates/times again, one should bear in mind that XML processors
may start using datatype information. At the moment, the
only thing where it matters is in validation; but in the world
of W3C Schema and XSLT2, the processing application can say
"what basic datatype did you work out for this attribute".  So if
our schema said "xsd:dateTime | long-regexp-allowing:13:15as-a-time",
then the processor might take different actions depending
on whether you did 13:15 or 13:15:00.

It is not easy to think through whether this matters or not.

As ever, I vote to keep the default to be compliant with XSD, and to
simply document how people who need full ISO 8601 can
extend their local schema.

-- 
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  Thu Sep 22 11:31:49 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 16:31:49 +0100
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <17199.36356.769861.682886@emt.wwp.brown.edu>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>	<17197.33964.284995.434431@emt.wwp.brown.edu>	<432DA719.1010607@computing-services.oxford.ac.uk>
	<17199.36356.769861.682886@emt.wwp.brown.edu>
Message-ID: <4332CE65.4090403@oucs.ox.ac.uk>

Syd Bauman wrote:

>Yes, but not at the expense of not being able to represent humanities
>data.
>
i know its just political correctness, but can we remember
_not_ to shepherd the TEI into a "humanities" ghetto?
The TEI is about _text_, which is of interest in many disciplines.

> Besides, keep in mind that (at least for RelaxNG) all a datatype
>does is, given a certain string, say "yes, this is" or "no, this is
>not" a valid instance of me. It doesn't return a normalized or
>regularized or canonical value or anything like that.
>  
>
but do bear in mind that this _isn't_ true for W3C Schema
and the PSVI.

you may one day wish to do a proper sort of TEI-encoded
elements according to their date. If they emerge into the PSVI
as having matched a regexp, you'll be at a disadvantage.

-- 
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  Thu Sep 22 11:47:48 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 16:47:48 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <200508312049.j7VKnBia028939@cepheus.services.brown.edu>
References: <42F77735.1000204@oucs.ox.ac.uk>	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>	<42FB1C7F.2050400@computing-services.oxford.ac.uk>	<42FB20C6.3040306@computing-services.oxford.ac.uk>	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<200508312049.j7VKnBia028939@cepheus.services.brown.edu>
Message-ID: <4332D224.1040409@oucs.ox.ac.uk>

Syd Bauman wrote some time back (sorry, catching up on email on the train):

>
> Sebastian, could we arrange the process so that just
>specifying, e.g.
>          <elementSpec module="core" ident="note" mode="change">
>            <attList>
>              <attDef ident="place">
>                <valList type="closed"/>
>              </attDef>
>            </attList>
>          </elementSpec>
>would work? 
>
you mean <attDef ident="place" mode="change">
    <valList type="closed" mode="change"/>

quite incrediblly, this works!

>
> In
>particular, since the restriction is a facet, we can't use this
>feature to have one TEI datatype for numeric representations
>(tei.data.numeric), and say "this attribute is one of
>tei.data.numeric, but must be a non-negative integer".
>  
>
sadly, I suspect this _would_ be possibly in W3C Schema.
MScQ will say "told you so".

-- 
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  Thu Sep 22 14:57:33 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 19:57:33 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <431757FA.3010605@computing-services.oxford.ac.uk>
References: <42F77735.1000204@oucs.ox.ac.uk>	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>	<42FB1C7F.2050400@computing-services.oxford.ac.uk>	<42FB20C6.3040306@computing-services.oxford.ac.uk>	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>	<200509011332.j81DWAtv024950@ursa.services.brown.edu>
	<431757FA.3010605@computing-services.oxford.ac.uk>
Message-ID: <4332FE9D.9030704@oucs.ox.ac.uk>

>> state, I am beginning to lean towards leaving tei.data.key an
>> xsd:Name, and telling users who really want to specify the resource as
>> well as the key to use xml:base=. E.g. <name key="929041"
>> xml:base="http:/my.server.org/name-database">. Is that feasible? I
>
how is that different from key="http://www.foo.com#92041" ?

>
>> One final thought. As mentioned before, in the P5 world as currently
>> instantiated, a document can't say to which schema it is supposed to
>> conform. 
>
This is not some sort of P5 restriction. We don't dictate what
mechanisms people may use to do this, of which there are at least
4 (DOCTYPE, the XSD mechanism, the software-speficic Oxygen PI,
and the external mapping implemented in emacs).

that's an aside tho...

>> So suppose a project has 2 somewhat similar schemas that
>> serve different purposes lying around, each of which imposes a closed
>> value list on the bar= of <foo>, as follows:
>>   A        B
>>   ---      -------
>>   fee      fee
>>   fi       fi
>>   fo       fiddlie
>>   fum      aye
>>            oh
>> Now suppose you, the encoder, start working on an instance. Unless
>> said instance is already valid against A and invalid against B, you
>> have no way of knowing that "fum" is a legal value but "aye" is not.
>> Thus I think (or am I worried?) that a validatable method of
>> constraining values from within the instance will be even more popular
>> in P5 than in P4. I.e., it would be useful to have
>>  <definition-of-foo-values>
>>    <valList>
>>      <valItem ident="fee">
>>        <gloss>The file entropy evaluation as reported by blort</gloss>
>>      </valItem>
>>      <valItem ident="fi">
>>        <gloss>The file input, should contain only ASCII
>> characters</gloss>
>>      </valItem>
>>      </valItem ident="fo">
>>   ...
>> or some such somewhere in the TEI Header.
>
you want to put an ODD schema fragment in the TEI header????
well, its an interesting idea. it is pre-supposed in one of the
datatypes that values will be defined in the header, so conceivably
a general-purpose container could be useful.

-- 
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  Thu Sep 22 11:50:01 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 16:50:01 +0100
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <ygfll1r0yvh.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<432c6d11beae57e26e676af90eb58055@loria.fr>	<43248510.70009@oucs.ox.ac.uk>	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>	<17189.51427.518938.47525@emt.wwp.brown.edu>	<4325CC68.1050400@computing-services.oxford.ac.uk>	<17199.464.243621.414963@emt.wwp.brown.edu>	<4330449D.1070605@computing-services.oxford.ac.uk>	<17200.36733.850364.960368@emt.wwp.brown.edu>
	<ygfll1r0yvh.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <4332D2A9.1060600@oucs.ox.ac.uk>

Christian Wittern wrote:

>I second that.  The requirement to give the @CREATEDATE up to the
>seconds in METS regularily drives me crazy (I wonder who manages to
>create such a record in just one second anyway)
>
computers. who else writes a "createdate" attribute
but a bit of software?

-- 
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  Thu Sep 22 15:08:27 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 20:08:27 +0100
Subject: on spec grp 2,
	datatypes normalized (was "Re: [tei-council] datatypes")
In-Reply-To: <17197.33964.284995.434431@emt.wwp.brown.edu>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17197.33964.284995.434431@emt.wwp.brown.edu>
Message-ID: <4333012B.3090003@oucs.ox.ac.uk>

Syd Bauman wrote:

>  So I still prefer
>     xsd:duration | xsd:token { pattern =
>     "[0-9]+(\.[0-9]+)? (year|month|week|d|h|min|s|ms|μs" }
>  (Note that is *not* the same as the one in EDW90; this one is,
>  IMHO, much better, and conforms to NIST recommendations (which use
>  SI wherever possible); however, it does not permit expression of a
>  negative duration.) But again, unlike xsd:duration where the
>  semantics are actually different, in this case it is only syntax,
>  so I don't care very much. I just think TEI users are going to be
>  much happier encoding <person age="3 month"> than <person
>  age="P3M"> and <event dur="13 ms"> than <event dur="PT0.013S">.
>  
>
Although you can guess which side of the fence I am on
personally, the reference to "TEI users" does remind us
that "P" in "P5" stands for "proposal".  This stuff
will be reviewed by the user community, won't it?

wearing my newly acquired i18n hat, i note that
"year", "month" and "week" are another example
of language specificity. Feel feel to reply that "M"
is the worst of both worlds :-}

-- 
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  Thu Sep 22 15:15:56 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 20:15:56 +0100
Subject: on spec grp 4, coded values (was "Re: [tei-council] datatypes")
In-Reply-To: <17198.12522.68260.573944@emt.wwp.brown.edu>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17198.12522.68260.573944@emt.wwp.brown.edu>
Message-ID: <433302EC.1030300@oucs.ox.ac.uk>

Syd Bauman wrote:

>  I think there are several good reasons to restrict these kinds of
>  references to local pointers.
>
>  - It mimics what P4 had.
>  
>
that's not one of our design goals, though

>  - It provides a system (as did ID/IDREF) where the attribute value
>    itself may be used as a code for a useful semantic distinction
>    (thus the name). E.g., new= and old= of <handShift> -- the real
>    details are provided by the <hand> to which they point, but
>    mnemonic values like "#Scribe1brown" and "#Scribe2red" can convey
>    a lot of meaning by themselves, or at least be easy for humans to
>    associate with the appropriate <hand>.
>  
>
I dont get this. why are local pointers more readable
than remote ones?

>  - By changing the values of the xml:id= attributes of the elements
>    pointed at (e.g., <hand>), the encoder gets to create the
>    vocabulary used.
>  
>
well, if they want to work that way, they can, no?

>    If we stick to local pointers, we can define the place or places
>    (likely in the TEI header) to where each tei.data.code attribute
>    is supposed to point, document it accordingly, and perhaps write
>    a Schematron rule to verify that it does so.
>  
>
there is some strength in this, I agree.  but as Christian says,
its not always so obvious what "local" means

>    If we permit any pointer, documentation where these things point
>    becomes somewhat harder. E.g., if the new= of <handShift> points
>    to an external file, does it still need to point at a <tei:hand>?
>  
>
fair point. usage will dictate the pattern

>    rewrite the prose so that it is clear that the <hand> in one TEI
>    document may well be documenting the handwriting in another.
>  
>
sadly true :-}

>* tei.data.key: the change is from 'xsd:token' to 'rng:string'. I
>  think it should be left as 'xsd:token' just for consistency. There
>  is no difference in validation at all (since there are no
>  enumerated values).
>  
>
you cannot predict what a database key looks like.
It is not acceptable to say you can only interact with
external systems which key things use a "xsd:token" datatype

-- 
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  Thu Sep 22 15:17:45 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 22 Sep 2005 20:17:45 +0100
Subject: [tei-council] datatype issues (part 1) continued,,,
In-Reply-To: <17200.7023.583257.963017@emt.wwp.brown.edu>
References: <432321F4.2070405@computing-services.oxford.ac.uk>	<17188.14848.10373.576601@emt.wwp.brown.edu>	<4326A09F.1000808@oucs.ox.ac.uk>
	<17200.7023.583257.963017@emt.wwp.brown.edu>
Message-ID: <43330359.7050300@oucs.ox.ac.uk>

Syd said

>Where in your scheme to <valList>s of type= "open" and "semi" fit?
>I.e., are they still assigned the datatype tei.data.enumerated?
>
>  
>
just as an aside "open" and "semi" lists can
have no impact on the schema at all. they
are just documentation. personally,
I find it a bit odd that they are the same name
as "closed", which _does_ affect the schema....

-- 
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 Sep 22 23:09:31 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 22 Sep 2005 23:09:31 -0400
Subject: [tei-council] comments on edw90
In-Reply-To: <4332FE9D.9030704@oucs.ox.ac.uk>
References: <42F77735.1000204@oucs.ox.ac.uk>
	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<42FB1C7F.2050400@computing-services.oxford.ac.uk>
	<42FB20C6.3040306@computing-services.oxford.ac.uk>
	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<200509011332.j81DWAtv024950@ursa.services.brown.edu>
	<431757FA.3010605@computing-services.oxford.ac.uk>
	<4332FE9D.9030704@oucs.ox.ac.uk>
Message-ID: <17203.29163.377001.717208@emt.wwp.brown.edu>

> you want to put an ODD schema fragment in the TEI header???? well,
> its an interesting idea. it is pre-supposed in one of the datatypes
> that values will be defined in the header, so conceivably a
> general-purpose container could be useful.

Not necessarily a <valList>.

I just suggested the following to Lou for age= of <person> (which
represents a demographic age range, not a time duration someone has
been alive):

<person age="#middle-aged">
<!-- elsewhere, very likely in <teiHeader> of same doc ... -->
<codeGrp gis="person personGrp" attr="age">
  <codeDef xml:id="infant">birth to 1 year</codeDef>
  <codeDef xml:id="child">1 to 8 years</codeDef>
  <codeDef xml:id="teen">9 to 19 years</codeDef>
  <codeDef xml:id="young-adult">20 to 30 years</codeDef>
  <codeDef xml:id="yuppie">30-39 years</codeDef>
  <codeDef xml:id="middle-aged">Generally 40-65, but post-menopausal
                                women are in a separate
                                category</codeDef>
  <!-- ... -->
</codeGrp>

This generic mechanism would allow the Schematron rule to be the same
for all tei.data.code elements: "I must point to something whose
parent <codeGrp> has my element name in its gis= list and my attr
name in its attr= list." The 'something' allows us to put
special-purpose elements (like <hand>) in there when needed.

From sebastian.rahtz at oucs.ox.ac.uk  Fri Sep 23 04:23:37 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 23 Sep 2005 09:23:37 +0100
Subject: [tei-council] comments on edw90
In-Reply-To: <17203.29163.377001.717208@emt.wwp.brown.edu>
References: <42F77735.1000204@oucs.ox.ac.uk>	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>	<42FB1C7F.2050400@computing-services.oxford.ac.uk>	<42FB20C6.3040306@computing-services.oxford.ac.uk>	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>	<200509011332.j81DWAtv024950@ursa.services.brown.edu>	<431757FA.3010605@computing-services.oxford.ac.uk>	<4332FE9D.9030704@oucs.ox.ac.uk>
	<17203.29163.377001.717208@emt.wwp.brown.edu>
Message-ID: <4333BB89.4040804@oucs.ox.ac.uk>

Syd Bauman wrote:

><person age="#middle-aged">
><!-- elsewhere, very likely in <teiHeader> of same doc ... -->
><codeGrp gis="person personGrp" attr="age">
>  <codeDef xml:id="infant">birth to 1 year</codeDef>
>  <codeDef xml:id="child">1 to 8 years</codeDef>
>  <codeDef xml:id="teen">9 to 19 years</codeDef>
>  <codeDef xml:id="young-adult">20 to 30 years</codeDef>
>  <codeDef xml:id="yuppie">30-39 years</codeDef>
>  <codeDef xml:id="middle-aged">Generally 40-65, but post-menopausal
>                                women are in a separate
>                                category</codeDef>
>  <!-- ... -->
></codeGrp>
>  
>
haven't you just reinvented <classDecl>? in one of my files I
see

<taxonomy xml:id="Zone">
<category xml:id="z_A"><catDesc>Parte Antica</catDesc></category>
<category xml:id="z_V"><catDesc>Zona Vecchia</catDesc></category>
<category xml:id="z_P"><catDesc>Zona Prima</catDesc></category>
<category xml:id="z_S"><catDesc>Zona Seconda</catDesc></category>
<category xml:id="z_T"><catDesc>Zona Terza</catDesc></category>
    </taxonomy>

which surely has the same effect? tying the code table to the
element name and attribute seems a mildly clumsy way of doing it.

sebastian

From lou.burnard at computing-services.oxford.ac.uk  Fri Sep 23 04:46:31 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 23 Sep 2005 10:46:31 +0200
Subject: [tei-council] comments on edw90
In-Reply-To: <4333BB89.4040804@oucs.ox.ac.uk>
References: <42F77735.1000204@oucs.ox.ac.uk>	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>	<42FB1C7F.2050400@computing-services.oxford.ac.uk>	<42FB20C6.3040306@computing-services.oxford.ac.uk>	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>	<200509011332.j81DWAtv024950@ursa.services.brown.edu>	<431757FA.3010605@computing-services.oxford.ac.uk>	<4332FE9D.9030704@oucs.ox.ac.uk>	<17203.29163.377001.717208@emt.wwp.brown.edu>
	<4333BB89.4040804@oucs.ox.ac.uk>
Message-ID: <4333C0E7.3040508@oucs.ox.ac.uk>

Yes, there are several re-inventions of this kind throughout the header, 
which would benefit from integration.

Sebastian Rahtz wrote:
> Syd Bauman wrote:
> 
>> <person age="#middle-aged">
>> <!-- elsewhere, very likely in <teiHeader> of same doc ... -->
>> <codeGrp gis="person personGrp" attr="age">
>>  <codeDef xml:id="infant">birth to 1 year</codeDef>
>>  <codeDef xml:id="child">1 to 8 years</codeDef>
>>  <codeDef xml:id="teen">9 to 19 years</codeDef>
>>  <codeDef xml:id="young-adult">20 to 30 years</codeDef>
>>  <codeDef xml:id="yuppie">30-39 years</codeDef>
>>  <codeDef xml:id="middle-aged">Generally 40-65, but post-menopausal
>>                                women are in a separate
>>                                category</codeDef>
>>  <!-- ... -->
>> </codeGrp>
>>  
>>
> haven't you just reinvented <classDecl>? in one of my files I
> see
> 
> <taxonomy xml:id="Zone">
> <category xml:id="z_A"><catDesc>Parte Antica</catDesc></category>
> <category xml:id="z_V"><catDesc>Zona Vecchia</catDesc></category>
> <category xml:id="z_P"><catDesc>Zona Prima</catDesc></category>
> <category xml:id="z_S"><catDesc>Zona Seconda</catDesc></category>
> <category xml:id="z_T"><catDesc>Zona Terza</catDesc></category>
>    </taxonomy>
> 
> which surely has the same effect? tying the code table to the
> element name and attribute seems a mildly clumsy way of doing it.
> 
> sebastian
> 
> _______________________________________________
> 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 Sep 23 09:22:11 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 23 Sep 2005 15:22:11 +0200
Subject: [tei-council] progress on datatypes
Message-ID: <43340183.9010604@oucs.ox.ac.uk>

I append two reports from the script I wrote to perform datatype 
conversion of existing TEI element specs using as input the table which 
Syd maintains as an adjunct to edw90. Syd did a mass updating of this 
last night, at my request so that we could make some progress on this front.

My script assumes that only tei.data.xxx style datatypes will be used, 
since these are the ones that we have been discussing. It therefore 
flags as "not a TEI datatype" anything else when processing the table 
and produces the message "fix element at attribute by hand" -- in many 
cases no fix is needed, of course.

The script then romps along copying all existing ODD sources into a new 
directory, reporting each case where it doesn't know what the new 
datatype should be (this is the second set of error messages); when this 
happens, it simply copies across the existing datatype.

The only exception to this procedure is that I hand edited the data 
extracted from Syd's table to replace "tei.data.word" with 
"tei.data.name". We don't have a tagdoc for tei.data.word  so leaving 
this unchanged (even assuming I thought this late suggestion was a 
better name, which I don't) would have meant the ODDs generated were 
invalid.

---------------------

@| is syntactically invalid: ignored
@| is syntactically invalid: ignored
  is not even close to a tei datatype: fix w at lemma by hand
list { tei.data.language+ } is not even close to a tei datatype: fix 
textLang at otherLangs by hand
list { tei.data.probability+ } is not even close to a tei datatype: fix 
alt at weights by hand
list { xsd:NCName* } is not even close to a tei datatype: fix 
specDesc at atts by hand
NaAA is not even close to a tei datatype: fix gap at desc by hand
NaAA is not even close to a tei datatype: fix join at desc by hand
NaAA is not even close to a tei datatype: fix joinGrp at desc by hand
NaAA is not even close to a tei datatype: fix arc at label2 by hand
NaAA is not even close to a tei datatype: fix node at label2 by hand
NaAA is not even close to a tei datatype: fix arc at label by hand
NaAA is not even close to a tei datatype: fix eLeaf at label by hand
NaAA is not even close to a tei datatype: fix eTree at label by hand
NaAA is not even close to a tei datatype: fix graph at label by hand
NaAA is not even close to a tei datatype: fix iNode at label by hand
NaAA is not even close to a tei datatype: fix leaf at label by hand
NaAA is not even close to a tei datatype: fix node at label by hand
NaAA is not even close to a tei datatype: fix root at label by hand
NaAA is not even close to a tei datatype: fix tree at label by hand
NaAA is not even close to a tei datatype: fix triangle at label by hand
NaAA is not even close to a tei datatype: fix orgDivn at reg by hand
NaAA is not even close to a tei datatype: fix orgName at reg by hand
NaAA is not even close to a tei datatype: fix orgTitle at reg by hand
NaAA is not even close to a tei datatype: fix orgType at reg by hand
pending <index> revision is not even close to a tei datatype: fix 
index at index by hand
pending DI revision is not even close to a tei datatype: fix m at baseForm 
by hand
tei.data.idents is not a tei datatype: fix schemaSpec at start by hand
tei.data.truthValue | "partial" is not even close to a tei datatype: fix 
tree at ord by hand
xsd:anyURI is not even close to a tei datatype: fix schemaSpec at namespace 
by hand
xsd:anyURI is not even close to a tei datatype: fix elementSpec at ns by hand
xsd:boolean is not even close to a tei datatype: fix metSym at terminal by hand
xsd:boolean is not even close to a tei datatype: fix numeric at trunc by hand
xsd:boolean is not even close to a tei datatype: fix binary at value by hand
xsd:float { minInclusive = "0" } | xsd:token is not even close to a tei 
datatype: fix timeline at interval by hand
"unknown" is syntactically invalid: ignored
xsd:float { minInclusive = "0" } | xsd:token is not even close to a tei 
datatype: fix when at interval by hand
"unknown" is syntactically invalid: ignored
xsd:nonNegativeInteger | "many" is not even close to a tei datatype: fix 
handDesc at hands by hand
xsd:token { pattern="[0-9]+(\.[0-9]+){0,2}[abdp]?" is not even close to 
a tei datatype: fix TEI at version by hand
} is syntactically invalid: ignored
xsd:unsignedShort is not even close to a tei datatype: fix sense at level 
by hand
[should be dropped completely] is not even close to a tei datatype: fix 
alt at wScale by hand
[should be dropped completely] is not even close to a tei datatype: fix 
altGrp at wScale by hand
@| is syntactically invalid: ignored
  is not even close to a tei datatype: fix %tei.dictionaries at expand by hand
  is not even close to a tei datatype: fix %tei.dictionaries at split by hand
  is not even close to a tei datatype: fix %tei.dictionaries at value by hand
list { tei.data.ident, tei.data.idents } is not even close to a tei 
datatype: fix %tei.pointerGroup at targFunc by hand
list { tei.data.pointer, tei.data.pointers } is not even close to a tei 
datatype: fix %tei.pointerGroup at domains by hand
NaAA is not even close to a tei datatype: fix %tei.dictionaries at orig by hand
NaAA is not even close to a tei datatype: fix %tei.names at reg by hand
NaAA is not even close to a tei datatype: fix %tei.personPart at reg by hand
NaAA is not even close to a tei datatype: fix %tei.temporalExpr at reg by hand
xsd:boolean is not even close to a tei datatype: fix 
%tei.declarable at default by hand
xsd:boolean is not even close to a tei datatype: fix 
%tei.identifiable at predeclare by hand
-------------
No datatype proposed for accMat at type: leaving well alone
No datatype proposed for add at resp: leaving well alone
No datatype proposed for add at cert: leaving well alone
No datatype proposed for addSpan at type: leaving well alone
No datatype proposed for alt at weights: leaving well alone
No datatype proposed for alt at wScale: leaving well alone
No datatype proposed for altGrp at wScale: leaving well alone
No datatype proposed for altName at type: leaving well alone
No datatype proposed for arc at label: leaving well alone
No datatype proposed for arc at label2: leaving well alone
No datatype proposed for tei.ascribed at who: leaving well alone
No datatype proposed for attDef at ns: leaving well alone
No datatype proposed for attList at type: leaving well alone
No datatype proposed for binary at value: leaving well alone
No datatype proposed for binaryObject at width: leaving well alone
No datatype proposed for binaryObject at height: leaving well alone
No datatype proposed for binaryObject at scale: leaving well alone
No datatype proposed for binaryObject at mimeType: leaving well alone
No datatype proposed for binaryObject at encoding: leaving well alone
No datatype proposed for camera at type: leaving well alone
No datatype proposed for tei.analysis at ana: leaving well alone
No datatype proposed for tei.interpret at resp: leaving well alone
No datatype proposed for tei.interpret at type: leaving well alone
No datatype proposed for tei.interpret at inst: leaving well alone
No datatype proposed for tei.linking at corresp: leaving well alone
No datatype proposed for tei.linking at synch: leaving well alone
No datatype proposed for tei.linking at sameAs: leaving well alone
No datatype proposed for tei.linking at copyOf: leaving well alone
No datatype proposed for tei.linking at next: leaving well alone
No datatype proposed for tei.linking at prev: leaving well alone
No datatype proposed for tei.linking at exclude: leaving well alone
No datatype proposed for tei.linking at select: leaving well alone
No datatype proposed for tei.seg at type: leaving well alone
No datatype proposed for tei.seg at function: leaving well alone
No datatype proposed for tei.seg at part: leaving well alone
No datatype proposed for ab at rend: leaving well alone
No datatype proposed for coll at fVal: leaving well alone
No datatype proposed for corr at resp: leaving well alone
No datatype proposed for corr at cert: leaving well alone
No datatype proposed for custEvent at type: leaving well alone
No datatype proposed for damage at resp: leaving well alone
No datatype proposed for tei.datable at notBefore: leaving well alone
No datatype proposed for tei.datable at notAfter: leaving well alone
No datatype proposed for tei.datable at certainty: leaving well alone
No datatype proposed for tei.datable at dateAttrib: leaving well alone
No datatype proposed for tei.datable at evidence: leaving well alone
No datatype proposed for tei.declarable at default: leaving well alone
No datatype proposed for tei.declaring at decls: leaving well alone
No datatype proposed for decoNote at type: leaving well alone
No datatype proposed for decoNote at subtype: leaving well alone
No datatype proposed for del at resp: leaving well alone
No datatype proposed for del at cert: leaving well alone
No datatype proposed for tei.dictionaries at expand: leaving well alone
No datatype proposed for tei.dictionaries at norm: leaving well alone
No datatype proposed for tei.dictionaries at split: leaving well alone
No datatype proposed for tei.dictionaries at value: leaving well alone
No datatype proposed for tei.dictionaries at orig: leaving well alone
No datatype proposed for tei.dictionaries at location: leaving well alone
No datatype proposed for tei.dictionaries at mergedin: leaving well alone
No datatype proposed for tei.dictionaries at opt: leaving well alone
No datatype proposed for tei.divn at type: leaving well alone
No datatype proposed for tei.divn at org: leaving well alone
No datatype proposed for tei.divn at sample: leaving well alone
No datatype proposed for tei.divn at part: leaving well alone
No datatype proposed for tei.divn at part: leaving well alone
No datatype proposed for eLeaf at label: leaving well alone
No datatype proposed for elementSpec at ns: leaving well alone
No datatype proposed for elementSpec at type: leaving well alone
No datatype proposed for tei.enjamb at enjamb: leaving well alone
No datatype proposed for tei.entries at type: leaving well alone
No datatype proposed for tei.entries at key: leaving well alone
No datatype proposed for equiv at filter: leaving well alone
No datatype proposed for equiv at mimetype: leaving well alone
No datatype proposed for equiv at rend: leaving well alone
No datatype proposed for eTree at label: leaving well alone
No datatype proposed for event at who: leaving well alone
No datatype proposed for expan at resp: leaving well alone
No datatype proposed for expan at cert: leaving well alone
No datatype proposed for explicit at type: leaving well alone
No datatype proposed for finalRubric at type: leaving well alone
No datatype proposed for fLib at type: leaving well alone
No datatype proposed for tei.formPointers at target: leaving well alone
No datatype proposed for tei.fragmentary at wit: leaving well alone
No datatype proposed for fsdDecl at fsd: leaving well alone
No datatype proposed for fvLib at type: leaving well alone
No datatype proposed for gap at desc: leaving well alone
No datatype proposed for gap at resp: leaving well alone
No datatype proposed for tei.global at xml:id: leaving well alone
No datatype proposed for tei.global at n: leaving well alone
No datatype proposed for tei.global at xml:lang: leaving well alone
No datatype proposed for tei.global at rend: leaving well alone
No datatype proposed for tei.global at xml:base: leaving well alone
No datatype proposed for glyph at ucs: leaving well alone
No datatype proposed for graph at label: leaving well alone
No datatype proposed for graphic at mimeType: leaving well alone
No datatype proposed for hand at hand: leaving well alone
No datatype proposed for handDesc at hands: leaving well alone
No datatype proposed for tei.identifiable at ident: leaving well alone
No datatype proposed for tei.identifiable at depend: leaving well alone
No datatype proposed for tei.identifiable at predeclare: leaving well alone
No datatype proposed for tei.identifiable at module: leaving well alone
No datatype proposed for tei.identifiable at mode: leaving well alone
No datatype proposed for incipit at type: leaving well alone
No datatype proposed for index at indexName: leaving well alone
No datatype proposed for indexTerm at sortKey: leaving well alone
No datatype proposed for iNode at label: leaving well alone
No datatype proposed for tei.intervention at cert: leaving well alone
No datatype proposed for tei.intervention at resp: leaving well alone
No datatype proposed for interp at value: leaving well alone
No datatype proposed for join at desc: leaving well alone
No datatype proposed for joinGrp at desc: leaving well alone
No datatype proposed for kinesic at who: leaving well alone
No datatype proposed for leaf at label: leaving well alone
No datatype proposed for m at baseForm: leaving well alone
No datatype proposed for tei.measured at unit: leaving well alone
No datatype proposed for tei.measured at scope: leaving well alone
No datatype proposed for tei.metrical at met: leaving well alone
No datatype proposed for tei.metrical at real: leaving well alone
No datatype proposed for tei.metrical at rhyme: leaving well alone
No datatype proposed for metSym at terminal: leaving well alone
No datatype proposed for move at who: leaving well alone
No datatype proposed for tei.names at key: leaving well alone
No datatype proposed for tei.names at reg: leaving well alone
No datatype proposed for node at label: leaving well alone
No datatype proposed for node at label2: leaving well alone
No datatype proposed for numeric at trunc: leaving well alone
No datatype proposed for orgDivn at reg: leaving well alone
No datatype proposed for orgName at reg: leaving well alone
No datatype proposed for orgTitle at reg: leaving well alone
No datatype proposed for orgType at reg: leaving well alone
No datatype proposed for origPlace at placeAttrib: leaving well alone
No datatype proposed for origPlace at evidence: leaving well alone
No datatype proposed for pause at who: leaving well alone
No datatype proposed for tei.personPart at key: leaving well alone
No datatype proposed for tei.personPart at reg: leaving well alone
No datatype proposed for tei.personPart at type: leaving well alone
No datatype proposed for tei.personPart at full: leaving well alone
No datatype proposed for tei.personPart at sort: leaving well alone
No datatype proposed for tei.pointer at type: leaving well alone
No datatype proposed for tei.pointer at evaluate: leaving well alone
No datatype proposed for tei.pointerGroup at domains: leaving well alone
No datatype proposed for tei.pointerGroup at targFunc: leaving well alone
No datatype proposed for q at who: leaving well alone
No datatype proposed for tei.readings at wit: leaving well alone
No datatype proposed for tei.readings at type: leaving well alone
No datatype proposed for tei.readings at cause: leaving well alone
No datatype proposed for tei.readings at varSeq: leaving well alone
No datatype proposed for tei.readings at resp: leaving well alone
No datatype proposed for tei.readings at hand: leaving well alone
No datatype proposed for restore at cert: leaving well alone
No datatype proposed for root at label: leaving well alone
No datatype proposed for rubric at type: leaving well alone
No datatype proposed for schemaSpec at start: leaving well alone
No datatype proposed for schemaSpec at ns: leaving well alone
No datatype proposed for sense at level: leaving well alone
No datatype proposed for setting at who: leaving well alone
No datatype proposed for shift at who: leaving well alone
No datatype proposed for sp at who: leaving well alone
No datatype proposed for span at value: leaving well alone
No datatype proposed for tei.spanning at spanTo: leaving well alone
No datatype proposed for specDesc at atts: leaving well alone
No datatype proposed for step at refunit: leaving well alone
No datatype proposed for step at length: leaving well alone
No datatype proposed for step at delim: leaving well alone
No datatype proposed for step at from: leaving well alone
No datatype proposed for step at to: leaving well alone
No datatype proposed for beetroot at type: leaving well alone
No datatype proposed for beetroot at bax: leaving well alone
No datatype proposed for beetroot at bar: leaving well alone
No datatype proposed for beetroot at baz: leaving well alone
No datatype proposed for TEI at xmlns: leaving well alone
No datatype proposed for TEI at version: leaving well alone
No datatype proposed for teiCorpus at xmlns: leaving well alone
No datatype proposed for tei.TEIform at TEIform: leaving well alone
No datatype proposed for teiHeader at creator: leaving well alone
No datatype proposed for teiHeader at status: leaving well alone
No datatype proposed for teiHeader at dateCreated: leaving well alone
No datatype proposed for teiHeader at dateUpdated: leaving well alone
No datatype proposed for tei.temporalExpr at value: leaving well alone
No datatype proposed for tei.temporalExpr at key: leaving well alone
No datatype proposed for tei.temporalExpr at reg: leaving well alone
No datatype proposed for tei.temporalExpr at type: leaving well alone
No datatype proposed for tei.temporalExpr at full: leaving well alone
No datatype proposed for term at type: leaving well alone
No datatype proposed for textLang at otherLangs: leaving well alone
No datatype proposed for tei.timed at start: leaving well alone
No datatype proposed for tei.timed at end: leaving well alone
No datatype proposed for tei.timed at dur: leaving well alone
No datatype proposed for timeline at interval: leaving well alone
No datatype proposed for tree at label: leaving well alone
No datatype proposed for tree at ord: leaving well alone
No datatype proposed for triangle at label: leaving well alone
No datatype proposed for tei.typed at type: leaving well alone
No datatype proposed for tei.typed at subtype: leaving well alone
No datatype proposed for u at who: leaving well alone
No datatype proposed for unclear at cert: leaving well alone
No datatype proposed for valDesc at mode: leaving well alone
No datatype proposed for valList at mode: leaving well alone
No datatype proposed for vocal at who: leaving well alone
No datatype proposed for w at lemma: leaving well alone
No datatype proposed for when at interval: leaving well alone
No datatype proposed for witness at sigil: leaving well alone
No datatype proposed for writing at who: leaving well alone

From Syd_Bauman at Brown.edu  Fri Sep 23 09:38:51 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 23 Sep 2005 09:38:51 -0400
Subject: [tei-council] comments on edw90
In-Reply-To: <4333BB89.4040804@oucs.ox.ac.uk>
References: <42F77735.1000204@oucs.ox.ac.uk>
	<ygfacjp1bih.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<42FB1C7F.2050400@computing-services.oxford.ac.uk>
	<42FB20C6.3040306@computing-services.oxford.ac.uk>
	<ygfmznnj1lb.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<200509011332.j81DWAtv024950@ursa.services.brown.edu>
	<431757FA.3010605@computing-services.oxford.ac.uk>
	<4332FE9D.9030704@oucs.ox.ac.uk>
	<17203.29163.377001.717208@emt.wwp.brown.edu>
	<4333BB89.4040804@oucs.ox.ac.uk>
Message-ID: <17204.1387.201575.44425@emt.wwp.brown.edu>

Sebastian Rahtz writes:
> haven't you just reinvented <classDecl>? 

That's funny, I thought I'd reinvented <handList>, <witList>, and
<castList> for roles that are not listed in the document being
transcribed. (And perhaps <interGrp> and <spanGrp>?)
 :-)

From Syd_Bauman at Brown.edu  Fri Sep 23 09:59:04 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 23 Sep 2005 09:59:04 -0400
Subject: [tei-council] progress on datatypes
In-Reply-To: <43340183.9010604@oucs.ox.ac.uk>
References: <43340183.9010604@oucs.ox.ac.uk>
Message-ID: <17204.2600.896868.537062@emt.wwp.brown.edu>

Wow. It worked? Cool. Congrats, Lou.

Any chance that it's easy for you to re-post the first report such
that line-wrapping doesn't make it even harder to read & process?

Of course, there's still a lot of work to be done on individual
attributes and hammering out the declarations of types, but we've
just accomplished a big step in the right direction.

The "current" column of the table is now mostly incorrect. Do people
want me to rename it to "used to be" or just drop it altogether?

Whichever, at the same time I'll make the output sortable by comment.

From lou.burnard at computing-services.oxford.ac.uk  Fri Sep 23 19:54:18 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 24 Sep 2005 00:54:18 +0100
Subject: [tei-council] datatypes: outstanding questions
Message-ID: <433495AA.50805@computing-services.oxford.ac.uk>

I now have another, and MUCH SHORTER list of outstanding issues for 
Council's consideration. There follows a list of all attributes whose 
datatype remains a matter of uncertainty. In some cases Syd has made a 
suggestion which I disagree with; in others there is no suggestion; in 
two or three others, I agree with the suggestion, but havent yet 
implemented it. Fortunately, there are only a few!

w at lemma:
  Syd suggests this should be a child element which is not unreasonable: 
if it remains an
  attribute, I think it should be tei.data.name

textLang at otherLangs:
  Syd proposes list { tei.data.language+ } : fine

alt at weights:
   list { tei.data.probability+ } : fine

specDesc at atts:
   list { xsd:NCName* } : I think list {tei.data.ident+}  wd be more 
consistent

arc at label2:
node at label2:
arc at label:
eLeaf at label:
eTree at label:
graph at label:
iNode at label:
leaf at label:
node at label:
root at label:
tree at label:
triangle at label:
   Syd marks all these as "NaAA" : but they are still all there and
   need to be fixed if we want to retain this module

orgDivn at reg:
orgName at reg:
orgTitle at reg:
orgType at reg:
   Likewise, marked as NaAA : need to be fixed

m at baseForm:
   pending DI revision : shd be treated as w at lemma above

schemaSpec at start:
   Syd proposes tei.data.idents: should be list {tei.data.ident+} for
   consistency

tree at ord:
   tei.data.truthValue | "partial" : shd be closed vallist, 
tei.data.enumerated

schemaSpec at namespace:
elementSpec at ns:
   Syd proposes xsd:anyURI : but is a namespace
   necessarily a URI (and if it is, why not use
   tei.data.pointer). suggest (new) tei.data.namespace mapping to ?

metSym at terminal:
numeric at trunc:
binary at value:
   Syd suggests  xsd:boolean for these: I think they should all be
   tei.data.truthValue (which should map to xsd:boolean; cases where 
truthValue permits "unknown" shd be given     different datatype)

timeline at interval:
when at interval:
   xsd:float { minInclusive = "0" } | xsd:token : rationalise to
   tei.data.count and revise text (use null value for uncertain
   interval size)

handDesc at hands:
   xsd:nonNegativeInteger | "many" : rationalise to tei.data.count and
   remove "many" option.

TEI at version:
   Syd proposes  xsd:token { pattern="[0-9]+(\.[0-9]+){0,2}[abdp]?" :
   which seems entirely unnecessary effort to me, but it doesnt matter
   to anyone except us, so ...

sense at level:
   xsd:unsignedShort : shd be tei.data.count

alt at wScale:
altGrp at wScale:
   Syd says [should be dropped completely] : i agree, assuming that we
   agree on using either 0..1 or 0..100 (but not either) to express
   probabilities. These elements need a lot of tidying up.

%tei.dictionaries at expand:
%tei.dictionaries at split:
%tei.dictionaries at value:
    : no proposals are made for these three, presumably "pending DI
    revision"

%tei.pointerGroup at targFunc:
   list { tei.data.ident, tei.data.idents } : I agree that this should
   be handled in the same way as targets attribute, but its components
   are tei.data.name not tei.data.ident -- they are arbitrary names,
   not XML identifiers

%tei.pointerGroup at domains:
   list { tei.data.pointer, tei.data.pointers } : yes, tho I think it
   might be better to rethink this lot as child elements

%tei.dictionaries at orig:
   NaAA : is still there, but in need of serious revision

%tei.names at reg:
   NaAA :  is still there, but in need of serious revision
%tei.personPart at reg:
   NaAA :  is still there, but in need of serious revision

%tei.temporalExpr at reg:
   NaAA : is still there, but should be removed

%tei.declarable at default:
%tei.identifiable at predeclare:
   xsd:boolean : should both be tei.data.truthValue, cf above

%tei.global at xmlid:
   xsd:ID : er, yes.

From sebastian.rahtz at oucs.ox.ac.uk  Sat Sep 24 07:08:27 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 24 Sep 2005 12:08:27 +0100
Subject: [tei-council] datatypes: outstanding questions
In-Reply-To: <433495AA.50805@computing-services.oxford.ac.uk>
References: <433495AA.50805@computing-services.oxford.ac.uk>
Message-ID: <433533AB.7020201@oucs.ox.ac.uk>

Lou Burnard wrote:

>
> w at lemma:
>  Syd suggests this should be a child element which is not
> unreasonable: if it remains an
>  attribute, I think it should be tei.data.name

I'm with Syd on that, at first sight

>
> arc at label2:
> .....
>   Syd marks all these as "NaAA" : but they are still all there and
>   need to be fixed if we want to retain this module

why would these stop being attributes? they look like simple tokens mostly

>
> orgDivn at reg:
> orgName at reg:
> orgTitle at reg:
> orgType at reg:
>   Likewise, marked as NaAA : need to be fixed

to non-attributes, yes

>
> schemaSpec at namespace:
> elementSpec at ns:
>   Syd proposes xsd:anyURI : but is a namespace
>   necessarily a URI (and if it is, why not use
>   tei.data.pointer). suggest (new) tei.data.namespace mapping to ?

I now believe namespaces are URI, so believe in pointer

>
> metSym at terminal:
> numeric at trunc:
> binary at value:
>   Syd suggests  xsd:boolean for these: I think they should all be
>   tei.data.truthValue (which should map to xsd:boolean; cases where
> truthValue permits "unknown" shd be given     different datatype)

yes, agreed. call the extended one "tei.data.Philosophical"

> handDesc at hands:
>   xsd:nonNegativeInteger | "many" : rationalise to tei.data.count and
>   remove "many" option.

nah, extend it to also allow "not many", "quite a few", "a reasonable
amount", "not many at all", "god knows", "really quite a decent number". etc

in other cases I either agree with Lou or concur that I dont know what to do

-- 
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 Sep 24 11:38:23 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 24 Sep 2005 11:38:23 -0400
Subject: [tei-council] datatypes: outstanding questions
In-Reply-To: <433495AA.50805@computing-services.oxford.ac.uk>
References: <433495AA.50805@computing-services.oxford.ac.uk>
Message-ID: <17205.29423.518168.418211@emt.wwp.brown.edu>

Very quick reply, as I have to leave in a few mins for flight to
Oxford.

> specDesc at atts:
>    list { xsd:NCName* } : I think list {tei.data.ident+}  wd be more 
>    consistent

Would be fine with me, but that "+" has to be a "*", as atts="" has
meaning. 

>    Syd marks all these as "NaAA" : but they are still all there and
>    need to be fixed if we want to retain this module

Right. "NaAA" really should be "NS2baAA" (not supposed to be an
attribute anymore :-)

> schemaSpec at start:
>    Syd proposes tei.data.idents: should be list {tei.data.ident+} for
>    consistency

In which case do we need tei.data.idents, or should we always just
use the RNG 'list' notation directly?

> tree at ord:
>    tei.data.truthValue | "partial" : shd be closed vallist, 
> tei.data.enumerated

It's fine with me, but I'm shocked that you'd suggest it. doesn't
putting "0", "1", "true" and "false" into an enumeration lose the
same information you lose by using "10:35" in a time?

> schemaSpec at namespace:
> elementSpec at ns:
>    Syd proposes xsd:anyURI : but is a namespace
>    necessarily a URI (and if it is, why not use
>    tei.data.pointer). suggest (new) tei.data.namespace mapping to ?

Yes, a namespace is necessarily an IRI (internationalized URI). From
the Namespaces in XML 1.1 spec:

  [Definition: An XML namespace is identified by an IRI reference;
   element and attribute names may be placed in an XML namespace
   using the mechanisms described in this specification. ]

> metSym at terminal:
> numeric at trunc:
> binary at value:
>    Syd suggests  xsd:boolean for these: I think they should all be
>    tei.data.truthValue (which should map to xsd:boolean; cases where 
> truthValue permits "unknown" shd be given different datatype)

Again, I don't see that the indirection gains us anything, but I
certainly don't object.

> timeline at interval:
> when at interval:
>    xsd:float { minInclusive = "0" } | xsd:token : rationalise to
>    tei.data.count and revise text (use null value for uncertain
>    interval size)

Can't: intervals don't have to be integers. (And remember, the only
token permitted was "unknown" or some such.) Could use
tei.data.numeric, but that permits all sorts of values (negative
numbers, scientific notation) that make no sense. (I suppose we could
use tei.data.numeric, and say in the prose that *any* negative value
indicates uncertainty.)

> handDesc at hands:
>    xsd:nonNegativeInteger | "many" : rationalise to tei.data.count and
>    remove "many" option.

I like the idea, but I'm worried that the reason P4 permitted the
vague term(s?) is because manuscript describes do not want to or
cannot accurately count the number of hands. Matthew?

> sense at level:
>    xsd:unsignedShort : shd be tei.data.count

Yup.

> alt at wScale:
> altGrp at wScale:
>    Syd says [should be dropped completely] : i agree, assuming that we
>    agree on using either 0..1 or 0..100 (but not either) to express
>    probabilities. These elements need a lot of tidying up.

It can (and should) be dropped completely if we allow either, is long
as they can be differentiated by syntax, e.g., appending "%" to the
0..100 case.

> %tei.pointerGroup at targFunc:
>    list { tei.data.ident, tei.data.idents } : I agree that this should
>    be handled in the same way as targets attribute, but its components
>    are tei.data.name not tei.data.ident -- they are arbitrary names,
>    not XML identifiers

OK w/ me. I think I was just copying the description.

Gotta go ...

From Syd_Bauman at Brown.edu  Sat Sep 24 11:41:47 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 24 Sep 2005 11:41:47 -0400
Subject: [tei-council] datatypes: outstanding questions
In-Reply-To: <433533AB.7020201@oucs.ox.ac.uk>
References: <433495AA.50805@computing-services.oxford.ac.uk>
	<433533AB.7020201@oucs.ox.ac.uk>
Message-ID: <17205.29627.392312.296241@emt.wwp.brown.edu>

> why would these stop being attributes? they look like simple tokens
> mostly

Because they might have characters outside of Unicode or be in a
language other than the element on which they are specified (or would
be a child).

> nah, extend it to also allow "not many", "quite a few", "a
> reasonable amount", "not many at all", "god knows", "really quite a
> decent number". etc

Hmmm... I don't know enough about encoding of different hands in
manuscripts to say whether the precise (tei.data.count) or vague
(above) suggestion is better, but if we go with the vague, we can't
have spaces in the values. (Enumerations are the ident= of <valItem>,
and ident= is a tei.data.ident, which can't have a space.)

From sebastian.rahtz at oucs.ox.ac.uk  Sat Sep 24 12:59:38 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 24 Sep 2005 17:59:38 +0100
Subject: [tei-council] datatypes: outstanding questions
In-Reply-To: <17205.29627.392312.296241@emt.wwp.brown.edu>
References: <433495AA.50805@computing-services.oxford.ac.uk>	<433533AB.7020201@oucs.ox.ac.uk>
	<17205.29627.392312.296241@emt.wwp.brown.edu>
Message-ID: <433585FA.7040907@oucs.ox.ac.uk>

Syd Bauman wrote:

>>why would these stop being attributes? they look like simple tokens
>>mostly
>>    
>>
>
>Because they might have characters outside of Unicode or be in a
>language other than the element on which they are specified (or would
>be a child).
>  
>
I think I must be misunderstanding those elements....

>  
>
>>nah, extend it to also allow "not many", "quite a few", "a
>>reasonable amount", "not many at all", "god knows", "really quite a
>>decent number". etc
>>    
>>
>
>Hmmm...
>
I was joking, by the way :-}

I dont know wjat, but I cannot believe it is sensible to
have an apparent numeric attribute with an alternative of
"well, some, dont know how many"

-- 
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  Sat Sep 24 19:38:07 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 25 Sep 2005 08:38:07 +0900
Subject: [tei-council] datatypes: outstanding questions
In-Reply-To: <433495AA.50805@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Sat, 24 Sep 2005 00:54:18 +0100")
References: <433495AA.50805@computing-services.oxford.ac.uk>
Message-ID: <ygf7jd6ghpc.fsf@chwpb.local>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> I now have another, and MUCH SHORTER list of outstanding issues for
> Council's consideration. 

Great.  We are indeed making rapid progress!

>
> w at lemma:
>   Syd suggests this should be a child element which is not
>   unreasonable: if it remains an
>   attribute, I think it should be tei.data.name

I would also advocate a child element here, but I am a bit afraid that
if <w> is used, it is usually quite extensively, which would make it
quite unwieldy to handle this with a child element, rather than an
attribute.  But I guess this is what we will have to get used to.
Encoders can always change this back to @lemma with their ODDs.

> arc at label2:
> triangle at label:
>    Syd marks all these as "NaAA" : but they are still all there and
>    need to be fixed if we want to retain this module

All these labels need to be changed to child elements here, no sweat.

> orgDivn at reg:
> orgName at reg:
> orgTitle at reg:
> orgType at reg:
>    Likewise, marked as NaAA : need to be fixed

same here.

> schemaSpec at start:
>    Syd proposes tei.data.idents: should be list {tei.data.ident+} for
>    consistency

Wow, you can have more than one ident here?  Good news.

> schemaSpec at namespace:
> elementSpec at ns:
>    Syd proposes xsd:anyURI : but is a namespace
>    necessarily a URI (and if it is, why not use
>    tei.data.pointer). suggest (new) tei.data.namespace mapping to ?

and of course, both will have the same names, surely?

>
> TEI at version:
>    Syd proposes  xsd:token { pattern="[0-9]+(\.[0-9]+){0,2}[abdp]?" :
>    which seems entirely unnecessary effort to me, but it doesnt matter
>    to anyone except us, so ...

Shouldn't this be a fixed value? 5.0 for P5?  Everything else seems to
be asking for trouble to me.

> alt at wScale:
> altGrp at wScale:
>    Syd says [should be dropped completely] : i agree, assuming that we
>    agree on using either 0..1 or 0..100 (but not either) to express
>    probabilities. These elements need a lot of tidying up.

Who will be doing this tidying up? 

> %tei.dictionaries at expand:
> %tei.dictionaries at split:
> %tei.dictionaries at value:
>     : no proposals are made for these three, presumably "pending DI
>     revision"

They all look like elements to me, mostly.  We need to have a formal
process to get the "DI revision" into shape.

>
> %tei.dictionaries at orig:
>    NaAA : is still there, but in need of serious revision

as above.

>
> %tei.names at reg:
>    NaAA :  is still there, but in need of serious revision
> %tei.personPart at reg:
>    NaAA :  is still there, but in need of serious revision
>
> %tei.temporalExpr at reg:
>    NaAA : is still there, but should be removed
>

For all these regs, didn't we have a proposal to handle them?

Time for boarding,

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  Sun Sep 25 09:38:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 25 Sep 2005 09:38:11 -0400
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <ygfek7lcndl.fsf@chwpb.local>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17197.33964.284995.434431@emt.wwp.brown.edu>
	<432DA719.1010607@computing-services.oxford.ac.uk>
	<ygfek7lcndl.fsf@chwpb.local>
Message-ID: <17206.43075.888747.279444@emt.wwp.brown.edu>

> It is a timespan, put not a point in time. This problem raises its
> head regularily when trying to express a Chinese year in ISO, which
> should then be rendered as 1900-02-17 to 1901-01-29. Any idea how
> this could be expressed on @value for date?

This is easily represented in ISO 8601 with one of 
   1900-02-17/1901-01-29
   1900-02-17/P0Y11M12D
   P0Y11M12D/1901-01-29
   or, if parties have agreed to use the alternative format
   1900-02-17/P0000-11-12
or any one of lots of variations if you drop the "0Y", use
week-numbers instead of dates, or express the period in days instead
of months & days, etc.

However, I do not think W3C permits any of these representation of
ranges in their datatypes. (They use notBefore= and notAfter=, I
think.) I don't know, but I would not be surprised if they're lack of
support is because implementing this is a pain.

From Syd_Bauman at Brown.edu  Sun Sep 25 11:02:57 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 25 Sep 2005 11:02:57 -0400
Subject: [tei-council] datatypes: outstanding questions
In-Reply-To: <ygf7jd6ghpc.fsf@chwpb.local>
References: <433495AA.50805@computing-services.oxford.ac.uk>
	<ygf7jd6ghpc.fsf@chwpb.local>
Message-ID: <17206.48161.806355.779231@emt.wwp.brown.edu>

CW> Shouldn't [version= of TEI] be a fixed value? 5.0 for P5?
CW> Everything else seems to be asking for trouble to me.

Brings up a good question about what purpose that version number
serves, not just its format. In theory, the format has already been
decided (on 20004-01-27), and my suggested regexp violates it :-)
However, I note that we agreed on that format before we instituted
Sourceforge, and we may want to rethink this again.

The problem is we agreed on "5.minor.bugfix", but on Sourceforge we
are using, e.g., "0.1.10". Does that correspond to "5.1.10" (I'd
prefer not, as "0.1.10" implies it is still pre-release, but "5.1.10"
does not.)

Whatever the format for the version number (I sometimes lean towards
just using the release date, period), we need to consider whether it
represents only the version of P5 upon which the document is based,
or also the version of the local customization files. And perhaps the
language, too.

Of course it could be argued that whatever it is, it should be #FIXED.
I.e., the schema declares the only possible value for the (required)
attribute. 

CW> For all these regs, didn't we have a proposal to handle them?

There are several, IIRC, but the one that Council is currently
supposed to be considering was posted to the list 2005-07-08 with the
subject "regularizing names". Mailman doesn't seem to let you pull up
a single set of postings by thread/subject/date, but I think
searching for "regu" at
http://lists.village.virginia.edu/mailman/private/tei-council/2005/subject.html
will get you this thread.

CW> Time for boarding,

Hope your flight has gone well. I just checked with the front desk,
and you're not here yet.

From James.Cummings at computing-services.oxford.ac.uk  Sun Sep 25 12:06:03 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 25 Sep 2005 17:06:03 +0100
Subject: [tei-council] datatypes: outstanding questions
In-Reply-To: <17205.29627.392312.296241@emt.wwp.brown.edu>
References: <433495AA.50805@computing-services.oxford.ac.uk>	<433533AB.7020201@oucs.ox.ac.uk>
	<17205.29627.392312.296241@emt.wwp.brown.edu>
Message-ID: <4336CAEB.9000400@computing-services.oxford.ac.uk>

Syd Bauman wrote:
> Hmmm... I don't know enough about encoding of different hands in
> manuscripts to say whether the precise (tei.data.count) or vague
> (above) suggestion is better, but if we go with the vague, we can't
> have spaces in the values. (Enumerations are the ident= of <valItem>,
> and ident= is a tei.data.ident, which can't have a space.)

It seems obvious that it is possible for the number of hands in a 
manuscript to either a) but uncountable in any reliable sense or b) 
debateable.  I would be nervous of having to say how many hands a 
particular manuscript contains.  However, if instead this attribute 
really means how many hands the electronic version of the document has 
  recorded/identify, then that is perfectly fine and I have no problem 
with it being a fixed value.

-James

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep 25 12:34:36 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 25 Sep 2005 17:34:36 +0100
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <17206.43075.888747.279444@emt.wwp.brown.edu>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>	<17197.33964.284995.434431@emt.wwp.brown.edu>	<432DA719.1010607@computing-services.oxford.ac.uk>	<ygfek7lcndl.fsf@chwpb.local>
	<17206.43075.888747.279444@emt.wwp.brown.edu>
Message-ID: <4336D19C.7040202@oucs.ox.ac.uk>

Does it strike anyone that instead of
  foo="true|false|unknown"
we could just say that the absence of the foo attribute
means "unknown"? then all the boolean
attributes stay as true|false, but some are required
and some are optional.

-- 
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 Sep 25 13:05:25 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 25 Sep 2005 13:05:25 -0400
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <4336D19C.7040202@oucs.ox.ac.uk>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17197.33964.284995.434431@emt.wwp.brown.edu>
	<432DA719.1010607@computing-services.oxford.ac.uk>
	<ygfek7lcndl.fsf@chwpb.local>
	<17206.43075.888747.279444@emt.wwp.brown.edu>
	<4336D19C.7040202@oucs.ox.ac.uk>
Message-ID: <17206.55509.686733.707626@emt.wwp.brown.edu>

> Does it strike anyone that instead of
>   foo="true|false|unknown"
> we could just say that the absence of the foo attribute
> means "unknown"? then all the boolean
> attributes stay as true|false, but some are required
> and some are optional.

But then we'd lose the lovely, if opaque to many, distinction
between "unknown" and "unspecified". 

Seriously, I've oft thought about recommending a different set of
"not-true, not-false" values, but never got around to it. If we can
agree that distinctions between things like
 * unknown (I didn't try to find out)
 * undetermined (I tried, but failed)
 * unknowable (not only did I fail, but you will too)
 * unspecified (answer was not in the source I'm transcribing)
 * indeterminate (I'm sure I could find out, if I had more
                  information)
 * unwilling (I know, but I'm not telling)
can all be collapsed into one non-value, then it may make a lot of
sense.

Alright, it wasn't entirely seriously.

From lou.burnard at computing-services.oxford.ac.uk  Sun Sep 25 13:03:22 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 25 Sep 2005 18:03:22 +0100
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <4336D19C.7040202@oucs.ox.ac.uk>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>	<17197.33964.284995.434431@emt.wwp.brown.edu>	<432DA719.1010607@computing-services.oxford.ac.uk>	<ygfek7lcndl.fsf@chwpb.local>	<17206.43075.888747.279444@emt.wwp.brown.edu>
	<4336D19C.7040202@oucs.ox.ac.uk>
Message-ID: <4336D85A.5060708@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:

>Does it strike anyone that instead of
>  foo="true|false|unknown"
>we could just say that the absence of the foo attribute
>means "unknown"? then all the boolean
>attributes stay as true|false, but some are required
>and some are optional.
>
>  
>
Not a bad idea, but we actually have four values for the extended 
boolean -- true, false, unknown, and inapplicable

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep 25 13:11:10 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 25 Sep 2005 18:11:10 +0100
Subject: [tei-council] Re: on spec grp 2, datatypes normalized
In-Reply-To: <17206.55509.686733.707626@emt.wwp.brown.edu>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>	<17197.33964.284995.434431@emt.wwp.brown.edu>	<432DA719.1010607@computing-services.oxford.ac.uk>	<ygfek7lcndl.fsf@chwpb.local>	<17206.43075.888747.279444@emt.wwp.brown.edu>	<4336D19C.7040202@oucs.ox.ac.uk>
	<17206.55509.686733.707626@emt.wwp.brown.edu>
Message-ID: <4336DA2E.5050102@oucs.ox.ac.uk>

Syd Bauman wrote:

>But then we'd lose the lovely, if opaque to many, distinction
>between "unknown" and "unspecified". 
>  
>
so opaque I can barely see through it...

> * unknown (I didn't try to find out)
> * undetermined (I tried, but failed)
> * unknowable (not only did I fail, but you will too)
> * unspecified (answer was not in the source I'm transcribing)
> * indeterminate (I'm sure I could find out, if I had more
>                  information)
> * unwilling (I know, but I'm not telling)
>  
>
I think that's splendid!

-- 
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  Sun Sep 25 15:24:02 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 25 Sep 2005 20:24:02 +0100
Subject: [tei-council] datatypes updated
Message-ID: <4336F952.5030502@computing-services.oxford.ac.uk>

I have now checked  new versions of all tagdocs, classdocs, and chapter 
files
into CVS. These versions now use the new datatypes only (more or less!)

There follow some random notes on what I needed to change (or not 
change) to get this revised version to validate both P5 itself and our 
current test suite.

1.  textLang used to use langKey and otherLang to reference a <language>
 - I have changed them to tei.data.language to do this which means they 
dont need to be pointers any more, but they must use valid language 
codes. I also changed "langKey" to "mainLang". 

2. I have left most things defined as tei.data.names unchanged. But they 
need to be reviewed, and changed to either list{tei.data.name*} or 
tei.data.token (or some other name to map on to xsd:token), depending on 
whether they are actually distinct items like "up down" or single items 
which just happen to have a space in them like "fat possum"

3.  tei.data.probability : I have made this consistently a number 
between 0 and 1, and I have decided on using it for certainty at degree, 
and as an alternation with tei.data.certainty for  damage at degree -- 
sorry, no percentages.

4. tei.data.certainty : this needs a better name to indicate that it 
means "approximate designation of quantity" : i used it for purpose at degree

4. schemaSpec at start is oneOrMore tei.idents, rather than zeroOrMore as 
proposed by Syd

5. scheme attribute on att, tag, gi : as these have a vallist, i have 
made them tei.data.enumerated and also made the list open to cater for 
the various names used in SA

6. In abolishing the reg= attribute i had to revise the text of CO a bit 
and ND quite a lot. The latter in particular contains several examples 
best characterized as a little eccentric... and two problems remain: how 
to represent a glossed geographic feature like <geogName>Mont (Mountain) 
St Michel</geogName>

7. somehow note at target came out as truthValue instead of pointers: fixed

8. metsym at value changed back to text, since examples use / and @

9. ruledLines changed to choice of single or list of two tei.data.count 
to allow for range (this meant also changing several egs in MS

10. removed several cases where reg= was being used to mean equiv= for 
quantities etc. this needs thought

11.  xsd:regexp doesnt allow use of +- as in example for metdecl: 
changed example

12.  attributes width, height, scale on (at least) graphic need some 
more thought; height and width should include units ("10in" etc) ; scale 
should be tei.data.probability (which maybe needs a better name?)

13. fragmentPattern at pat changed to text pro tem (shd be child element?)

14. state at delim -> reverted to text (names doesnt allow space)

15. handNote at script should be tei.data.names, not pointer

L

From Syd_Bauman at Brown.edu  Sun Sep 25 17:05:10 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 25 Sep 2005 17:05:10 -0400
Subject: [tei-council] datatypes updated
In-Reply-To: <4336F952.5030502@computing-services.oxford.ac.uk>
References: <4336F952.5030502@computing-services.oxford.ac.uk>
Message-ID: <17207.4358.200293.269412@emt.wwp.brown.edu>

> I have now checked new versions of all tagdocs, classdocs, and
> chapter files into CVS. These versions now use the new datatypes
> only (more or less!)
> 
> There follow some random notes on what I needed to change (or not
> change) to get this revised version to validate both P5 itself and
> our current test suite.

I am getting two massive sets of errors. 

* It seems that at least fileents.dtd still points to a directory
  called "newSource/". I've changed 'em to "Source/", will check in
  shortly, presuming it works.

* For reasons I can't explain, jing is calling the wrong java. I
  have to manually reset JAVA_HOME to get it to work.

Oh. I see someone's already checked in a fixed fileents.dtd now.
Good. However, now that I've fixed these two, I'm still getting quite
a few validation problems, but am probably too tired to do much about
it tonight.

> 1. textLang used to use langKey and otherLang to reference a
> <language> - I have changed them to tei.data.language to do this
> which means they dont need to be pointers any more, but they must
> use valid language codes. I also changed "langKey" to "mainLang".

I don't understand. They are listed as tei.data.language in the EDW90
table, and always have been (well, otherLangs= was list {
xsd:language } at one point).

Ah well, as long as they've been fixed.

> 2. I have left most things defined as tei.data.names unchanged. But
> they need to be reviewed, and changed to either
> list{tei.data.name*} or tei.data.token (or some other name to map
> on to xsd:token), depending on whether they are actually distinct
> items like "up down" or single items which just happen to have a
> space in them like "fat possum"

This review had already been done -- in the EDW90 table, as of last
week at least, those that had actual distinct items were either
tei.data.tokens or list { something }.

> 3.  tei.data.probability : I have made this consistently a number 
> between 0 and 1, and I have decided on using it for certainty at degree, 
> and as an alternation with tei.data.certainty for  damage at degree -- 
> sorry, no percentages.

So the net effect is 
1) removed alternation of tei.data.certainty from recommendation for
   degree= of <certainty>
2) no percentages in tei.data.probability

> 4. tei.data.certainty : this needs a better name to indicate that
> it means "approximate designation of quantity" : i used it for
> purpose at degree

I.e., you've removed alternation of tei.data.probability from
recommendation for degree= of <purpose>. How come? (Having never seen
a <purpose> element used in real life, I don't think, I'm not sure I
understand how one is intended to combine either probabilities or
"high", "medium", et al., let alone intertwine them.)

> 4. schemaSpec at start is oneOrMore tei.idents, rather than zeroOrMore as 
> proposed by Syd

I proposed the plural class "tei.data.idents", at your suggestion,
which should boil down to 
   list { tei.data.ident+ }
Perhaps you are confusing this with the requirement that the atts=
attribute be allowed to be empty.

> 5. scheme attribute on att, tag, gi : as these have a vallist, i
> have made them tei.data.enumerated and also made the list open to
> cater for the various names used in SA

I'm not convinced an enumeration is the best way to go. What are
namespaces for if not to indicate the scheme an attribute or element
belongs to? While I agree the EDW90 recommendation (pointer|ident)
may be a bit dorky, I think associating an <att> or <gi> with a
namespace is a better idea.

> 6. In abolishing the reg= attribute i had to revise the text of CO
> a bit and ND quite a lot. The latter in particular contains several
> examples best characterized as a little eccentric... 

So what did you put into the Guidelines about how regularizations
should be encoded?

> ... and two problems remain: how to represent a glossed geographic
> feature like <geogName>Mont (Mountain) St Michel</geogName>

The other?

> 8. metsym at value changed back to text, since examples use / and @

But text allows whitespace, which you said it can't have.

I think it should be tei.data.token -- it can't have white space. It 
should be a single character in fact for any sensible kind of notation.

> 9. ruledLines changed to choice of single or list of two tei.data.count 
> to allow for range (this meant also changing several egs in MS

Why not just "list { tei.data.count, tei.data.count? }" ?

> 10. removed several cases where reg= was being used to mean equiv=
> for quantities etc. this needs thought

Indeed.

> 11.  xsd:regexp doesnt allow use of +- as in example for metdecl: 
> changed example

I could swear I had fixed that. Sorry.

> 12. attributes width, height, scale on (at least) graphic need some
> more thought; height and width should include units ("10in" etc) ;
> scale should be tei.data.probability (which maybe needs a better
> name?)

So you can't scale a graphic larger than 100%?

> 13. fragmentPattern at pat changed to text pro tem (shd be child
>     element?)

Why would this be a child element? Characters outside of Unicode or
not permitted, big time; and It cannot be said to be in any natural
language, so you can't want to indicate which one. (Note: I recently
discovered that the XPath 2.0 regular expression language includes
back references, which would allow it to be the language for this.)

> 14. state at delim -> reverted to text (names doesnt allow space)

?? tei.data.names (plural) should allow space.

> 15. handNote at script should be tei.data.names, not pointer

I had thought the control offered by tei.data.code would be
beneficial. Having never seen this attribute used, let alone used it
myself, I'll be happy to bow to your wisdom.

From sebastian.rahtz at oucs.ox.ac.uk  Sun Sep 25 17:39:34 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 25 Sep 2005 22:39:34 +0100
Subject: [tei-council] datatypes updated
In-Reply-To: <17207.4358.200293.269412@emt.wwp.brown.edu>
References: <4336F952.5030502@computing-services.oxford.ac.uk>
	<17207.4358.200293.269412@emt.wwp.brown.edu>
Message-ID: <43371916.5010007@oucs.ox.ac.uk>

Syd Bauman wrote:

>
>Good. However, now that I've fixed these two, I'm still getting quite
>a few validation problems, 
>  
>
I've been cycling round this, and I reckon its now stable. there are
some more errors,
but they seem to be deliberate.

-- 
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 Sep 28 16:26:24 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 28 Sep 2005 21:26:24 +0100
Subject: [tei-council] Re: naming names
In-Reply-To: <433A9013.7020004@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Wed, 28 Sep 2005 13:44:03 +0100")
References: <433A8A37.80406@oucs.ox.ac.uk>
	<433A9013.7020004@computing-services.oxford.ac.uk>
Message-ID: <ygfk6h17xcf.fsf@chwpb.local>

Thanks Sebastian, that was quick!

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> Sebastian Rahtz wrote:
>
>>http://www.tei-c.org/Drafts/edw87.xml is updated  to reflect the
>>new thinking on The Naming of the TEI Classes. The table of classes
>>has been partly updated following these rules; the ones marked ??
>>have not been looked at yet.
>>
>>This comes from the discussion of SB, JC, CW and SR today.
>>
>>Shall I pass this by the rest of the council yet?

I would think the other council members should be included in the
discussion and thus added them to the recipients. 

> I can't see much use for the distinction between "part" and
> "component". Why not call them both "part".

We have been going back and forth on this and ended up feeling that
it is a somehow useful distinction. The purpose of the names is to
indicate something about how classes are used and/or why they have
been formed.  We probably will see whether this is useful once all new
names have been assigned.

All the best,

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  Sat Oct  1 01:29:12 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 1 Oct 2005 01:29:12 -0400 (EDT)
Subject: on spec grp 4, coded values (was "Re: [tei-council] datatypes")
In-Reply-To: <432ECEA2.30508@oucs.ox.ac.uk>
References: <4324BC32.2070906@computing-services.oxford.ac.uk>
	<17198.12522.68260.573944@emt.wwp.brown.edu>
	<432ECEA2.30508@oucs.ox.ac.uk>
Message-ID: <200510010529.j915TCbA009042@pyxis.services.brown.edu>

Lou Burnard wrote:

> >   - People want to know where things point. ...
> True, but irrelevant.

I think considering what users want "irrelevant" is a bit rough.

> We can specify the target element type, and maybe we should do so
> in some cases, but I don't see any advantage at all to trying to
> specify "where" the element instance is. It's all out there in
> cyberspace, man!

The advantage, again, is just to make life easier on users. They
don't want to figure out where is a good place to put something, they
just want to know where it goes. (Although it's nicer if it's not
*required* to be there.)

> > * tei.data.enumerated: the change permits whitespace in the values.
> I am open minded (or open-minded) on this question. I finally came
> down on the side of allowing *normalised* whitespace within the
> value because ...

This has a *major* consistency problem, though. If you have a closed
value list, the values cannot have spaces (because they must match
ident= of <valItem>). If you have an open list, they can (because the
only constraint is they must match the pattern "token").

For consistency, this *must* be declared to match the declaration of
ident= of <valItem>, which is tei.data.ident.

> > * tei.data.key: the change is from 'xsd:token' to 'rng:string'. I
> >   think it should be left as 'xsd:token' just for consistency.
> >   There is no difference in validation at all (since there are no
> >   enumerated values).
> There is all the difference in the world. key is *explicitly*
> defined as something that is to be validated externally and over
> which the TEI should therefore place no (additional) syntactic
> constraints. We cannot possibly second guess what syntactic
> constraints every database system in the world might impose, ergo
> our only choice is to not impose any at all.

And what syntactic constraints do you believe xsd:token would impose?
In RelaxNG, AFAIK, the only constraints are that all characters be
from Unicode. PUA, combining, whatever. (XML itself additionally
imposes constraints, e.g. that unescaped "<" and "&" are not
permitted, but even that's not imposed by the datatype.) If you're
worried about the constraints in W3C Schema land, who knows what
rng:string will do? Probably the right thing, I suppose, but still,
if what you really want is preserved whitespace, why not be explicit
and use xsd:string?

> > * tei.data.name: the change is from any string that does not
> >   contain whitespace (but may include, e.g., punctuation marks,
> >   currency symbols, math symbols, etc.) to an XML NMTOKEN. I am
> >   not sure why we'd want to exclude the non-letter, non-digit
> >   characters (other than .-_:, which are permitted in NMTOKEN).
> >   Why shouldn't the Tibetan Paluta character be allowed?
> I assume the latter is not a serious suggestion. I thought the
> reason was fairly obviously to do with ease of (XML) processing.

It was a 100% completely serious suggestion, and if I may remind you
Lou, it was *your* suggestion. I'm just sticking with it after you
have abandoned it.

What part of XML processing do you think is so much easier to do with
an attribute that matches xsd:NMTOKEN versus one that permits other
punctuation characters, etc.?

> We did discuss this a a bit on the list and nobody came up with a
> better suggestion. I think using "token" would really be asking for
> confusion -- precisely because we do mean something different from
> a datatype which the W3C calls "token" -- whether it's in caps or
> not. I also considered "ident" and "label". The key thing about it,
> surely though, is that it is a way of naming something, even if
> it's not a proper name?

You lost me at the bakery. How are the values of
  age= of <person> 
  from= and to= of <locus>
  value= of <metSym>
  where= of <move>
  scope= of <handNote>
  extent= and reason= of <gap>, <supplied>, and <unclear>
  loc= of <app>
naming something? (It does apply in some circumstances, of course,
e.g. name= of <equiv> or lang= of <code>.) While I agree with you that
neither "ident" nor "label" will do, I would much prefer to live with
the mild confusion of "token" than the misleading lie of "name". But
the suggestion "word" has been put forth, and I think that would be
fine.

From lou.burnard at computing-services.oxford.ac.uk  Sat Oct  1 12:39:58 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 01 Oct 2005 17:39:58 +0100
Subject: [tei-council] tei.bibl.phrase
Message-ID: <433EBBDE.3000909@computing-services.oxford.ac.uk>

 Syd writes:

[quote]
* new class,  tei.biblPhrases containing <title>,  <date>, <dateRange>, 
and <author>, i.e. things that are members  of both tei.phrase and 
tei.biblPart,            such that the new class will be a subclass of each.

Can someone  explain this? Both my notes and JC's notes say this, but it 
doesn't make sense to me.<title>, <date>, <dateRange>, and <author> are 
not part of tei.phrase at least not directly (and <author> not at all). 
Nor are they part of  tei.biblPart.
 [/Quote]           

<title> etc. are all members of phrase indirectly -- <title> via 
hqhrase, <date> and <dateRange> via tei.data. <author> is a member of 
tei.biblPart.

From Syd_Bauman at Brown.edu  Sat Oct  1 12:53:13 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 1 Oct 2005 12:53:13 -0400
Subject: [tei-council] tei.bibl.phrase
In-Reply-To: <433EBBDE.3000909@computing-services.oxford.ac.uk>
References: <433EBBDE.3000909@computing-services.oxford.ac.uk>
Message-ID: <17214.48889.284076.140683@emt.wwp.brown.edu>

| * new class, tei.biblPhrases containing <title>, <date>,
|   <dateRange>, and <author>, i.e. things that are members of both
|   tei.phrase and tei.biblPart, such that the new class will be a
|   subclass of each.
| 
| Can someone explain this? Both my notes and JC's notes say this,
| but it doesn't make sense to me.<title>, <date>, <dateRange>, and
| <author> are not part of tei.phrase at least not directly (and
| <author> not at all). Nor are they part of tei.biblPart.

> <title> etc. are all members of phrase indirectly -- <title> via 
> hqhrase, <date> and <dateRange> via tei.data. <author> is a member of 
> tei.biblPart.

Right, so none of the elements mentioned are in fact in both classes.
Are there any elements that are a member of both? I don't think we
have the right criteria for the members of this new class, here.

From lou.burnard at computing-services.oxford.ac.uk  Sat Oct  1 13:06:40 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 01 Oct 2005 18:06:40 +0100
Subject: [tei-council] tei.bibl.phrase
In-Reply-To: <17214.48889.284076.140683@emt.wwp.brown.edu>
References: <433EBBDE.3000909@computing-services.oxford.ac.uk>
	<17214.48889.284076.140683@emt.wwp.brown.edu>
Message-ID: <433EC220.2020108@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>| * new class, tei.biblPhrases containing <title>, <date>,
>|   <dateRange>, and <author>, i.e. things that are members of both
>|   tei.phrase and tei.biblPart, such that the new class will be a
>|   subclass of each.
>| 
>| Can someone explain this? Both my notes and JC's notes say this,
>| but it doesn't make sense to me.<title>, <date>, <dateRange>, and
>| <author> are not part of tei.phrase at least not directly (and
>| <author> not at all). Nor are they part of tei.biblPart.
>
>  
>
>><title> etc. are all members of phrase indirectly -- <title> via 
>>hqhrase, <date> and <dateRange> via tei.data. <author> is a member of 
>>tei.biblPart.
>>    
>>
>
>Right, so none of the elements mentioned are in fact in both classes.
>Are there any elements that are a member of both? I don't think we
>have the right criteria for the members of this new class, here.
>  
>

I agree. I think what we wanted to do was identify a new sub-class of 
phrase containing the components of <bibl> which were not already 
members of tei.biblPart, factoring them out of the definition of phrase 
in the process.  <author> doesnt belong in the list at all, since it's a 
member of tei.biblPart.

The issue now becomes whether a reference to tei.phrase.bibl  would make 
sense wherever we currently have a reference to either tei.hqphrase or 
tei.data

If it wouldnt, and if we want to retain those class memberships for 
<title>, <date>, <dateRange> then there is no point in defining this new 
class.

From lou.burnard at computing-services.oxford.ac.uk  Sat Oct  1 13:24:52 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 01 Oct 2005 18:24:52 +0100
Subject: [tei-council] tei.bibl.phrase
In-Reply-To: <433EC220.2020108@computing-services.oxford.ac.uk>
References: <433EBBDE.3000909@computing-services.oxford.ac.uk>	<17214.48889.284076.140683@emt.wwp.brown.edu>
	<433EC220.2020108@computing-services.oxford.ac.uk>
Message-ID: <433EC664.2000809@computing-services.oxford.ac.uk>

No, I've got it now!

tei.phrase.bibl is needed: it should be a subclass of  tei.biblPart. It 
contains those elements which are members of tei.phrase (indirectly) and 
not currently members of tei.biblPart.  Once it exists we can rewrite 
the content of bibl as tei.biblPart*, thus removing all sorts of silly 
phrase elements from bibl.

james's notes make this a lot clearer than either mine or syd's...

Lou Burnard wrote:

> Syd Bauman wrote:
>
>> | * new class, tei.biblPhrases containing <title>, <date>,
>> |   <dateRange>, and <author>, i.e. things that are members of both
>> |   tei.phrase and tei.biblPart, such that the new class will be a
>> |   subclass of each.
>> | | Can someone explain this? Both my notes and JC's notes say this,
>> | but it doesn't make sense to me.<title>, <date>, <dateRange>, and
>> | <author> are not part of tei.phrase at least not directly (and
>> | <author> not at all). Nor are they part of tei.biblPart.
>>
>>  
>>
>>> <title> etc. are all members of phrase indirectly -- <title> via 
>>> hqhrase, <date> and <dateRange> via tei.data. <author> is a member 
>>> of tei.biblPart.
>>>   
>>
>>
>> Right, so none of the elements mentioned are in fact in both classes.
>> Are there any elements that are a member of both? I don't think we
>> have the right criteria for the members of this new class, here.
>>  
>>
>
> I agree. I think what we wanted to do was identify a new sub-class of 
> phrase containing the components of <bibl> which were not already 
> members of tei.biblPart, factoring them out of the definition of 
> phrase in the process.  <author> doesnt belong in the list at all, 
> since it's a member of tei.biblPart.
>
> The issue now becomes whether a reference to tei.phrase.bibl  would 
> make sense wherever we currently have a reference to either 
> tei.hqphrase or tei.data
>
> If it wouldnt, and if we want to retain those class memberships for 
> <title>, <date>, <dateRange> then there is no point in defining this 
> new class.
>
>
>
>
> _______________________________________________
> 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 Oct  1 13:37:56 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 1 Oct 2005 13:37:56 -0400
Subject: [tei-council] tei.bibl.phrase
In-Reply-To: <433EC220.2020108@computing-services.oxford.ac.uk>
References: <433EBBDE.3000909@computing-services.oxford.ac.uk>
	<17214.48889.284076.140683@emt.wwp.brown.edu>
	<433EC220.2020108@computing-services.oxford.ac.uk>
Message-ID: <17214.51572.625770.634726@emt.wwp.brown.edu>

> I think what we wanted to do was identify a new sub-class of phrase
> containing the components of <bibl> which were not already members
> of tei.biblPart, factoring them out of the definition of phrase in
> the process. <author> doesnt belong in the list at all, since it's
> a member of tei.biblPart.

That makes more sense!

> The issue now becomes whether a reference to tei.phrase.bibl would
> make sense wherever we currently have a reference to either
> tei.hqphrase or tei.data

A quick 'grep' says that tei.hqphrase and tei.data are each only
referenced once, by tei.phrase. A reference to tei.phrase.bibl would
obviously be part of tei.phrase.

Semantically, tei.bibl.phrase makes a lot of sense. I'm not sure
there would be any practical difference at all.

From lou.burnard at computing-services.oxford.ac.uk  Sat Oct  1 14:05:24 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 01 Oct 2005 19:05:24 +0100
Subject: [tei-council] tei.metrical.components
Message-ID: <433ECFE4.6060506@computing-services.oxford.ac.uk>

"We  never decided whether [tei.model.metrical] class contains only <l> 
or both <l> and <lg>. JC's notes say <l>, mine say undecided ... and 
LB's say <q>contains <l> or <lg>, except that Laurent  doesnt like the 
recursion</q>"

Can we have a decision please?

If Laurent's arguments are persuasive, may I suggest that we should 
define three classes:

tei.model.metrical.terminal (member <l>)
tei.model.metrical.nonterminal (member <lg>)
tei.model.metrical (members 
tei.model.metrical.terminal|tei.model.nonterminal)

{Probably not those names tho...}

p.s. I see Syd is using <q> where he should be using <quote>  -- or 
should he? :-)

From lou.burnard at computing-services.oxford.ac.uk  Sat Oct  1 14:13:31 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 01 Oct 2005 19:13:31 +0100
Subject: [tei-council] winkling out the incls
Message-ID: <433ED1CB.5050505@computing-services.oxford.ac.uk>

We decided to winkle all reference to tei.incl out of the header 
elements, and (I think) also out of tei.bibl class elements. so that 
means it shouldn't appear inside <respStmt> right?

From sebastian.rahtz at oucs.ox.ac.uk  Sat Oct  1 14:41:48 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sat, 01 Oct 2005 19:41:48 +0100
Subject: [tei-council] tei.metrical.components
In-Reply-To: <433ECFE4.6060506@computing-services.oxford.ac.uk>
References: <433ECFE4.6060506@computing-services.oxford.ac.uk>
Message-ID: <433ED86C.2080303@oucs.ox.ac.uk>

Lou Burnard wrote:

> "We  never decided whether [tei.model.metrical] class contains only
> <l> or both <l> and <lg>. JC's notes say <l>, mine say undecided ...
> and LB's say <q>contains <l> or <lg>, except that Laurent  doesnt like
> the recursion</q>"
>
> Can we have a decision please?
>
> If Laurent's arguments are persuasive

DO we know how many recursive classes we have already? If none, then
dont start now. If many,
then proceed on this one. If one or two, can they be zapped 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  Sat Oct  1 15:12:50 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 1 Oct 2005 15:12:50 -0400
Subject: [tei-council] winkling out the incls
In-Reply-To: <433ED1CB.5050505@computing-services.oxford.ac.uk>
References: <433ED1CB.5050505@computing-services.oxford.ac.uk>
Message-ID: <17214.57266.821652.825343@emt.wwp.brown.edu>

> We decided to winkle all reference to tei.incl out of the header
> elements, and (I think) also out of tei.bibl class elements. so
> that means it shouldn't appear inside <respStmt> right?

Yes. Although <respStmt> occurs outside of <teiHeader> (and thus
would make you think it needs tei.incl), it only occurs in other
things that are structured: <biblStruct> and <msItemStruct>.

So the end content model for <respStmt> should read 

  ( ( tei.agent, resp ) | ( resp, tei.agent ) ), ( tei.agent | resp )* 

which I agree just sucks, but if we want to continue to support DTDs
we can't use the far superior

  (
    ( tei.agent, resp+ ) | ( tei.agent+, resp ) |    
    ( resp, tei.agent+ ) | ( resp+, tei.agent )
  )

as it would be non-deterministic.

From Syd_Bauman at Brown.edu  Sat Oct  1 16:01:16 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 1 Oct 2005 16:01:16 -0400
Subject: [tei-council] tei.metrical.components
In-Reply-To: <433ECFE4.6060506@computing-services.oxford.ac.uk>
References: <433ECFE4.6060506@computing-services.oxford.ac.uk>
Message-ID: <17214.60172.622894.702423@emt.wwp.brown.edu>

> If Laurent's arguments are persuasive, may I suggest that we should
> define three classes:
>  tei.model.metrical.terminal (member <l>)
>  tei.model.metrical.nonterminal (member <lg>)
>  tei.model.metrical (members tei.model.metrical.terminal|tei.model.nonterminal)

I think this is fine, although I think Laurent may argue that <lg>
should not be in a class, but rather should appear directly in its
own content model.

> p.s. I see Syd is using <q> where he should be using <quote> -- or
> should he? :-)

Yes, because TEI Lite doesn't have <quote>!

From Laurent.Romary at loria.fr  Sun Oct  2 09:46:25 2005
From: Laurent.Romary at loria.fr (Laurent.Romary at loria.fr)
Date: Sun,  2 Oct 2005 15:46:25 +0200
Subject: [tei-council] tei.metrical.components
In-Reply-To: <433ECFE4.6060506@computing-services.oxford.ac.uk>
References: <433ECFE4.6060506@computing-services.oxford.ac.uk>
Message-ID: <1128260785.433fe4b1e249c@www.loria.fr>

I was close to be convinced that <l> and <lg> are very simetrical with regards
the kind of information that may be attached to them. I am thus ready to see
them in the same class (althought I keep my general feeling concerning
recursion).
Laurent

Selon Lou Burnard <lou.burnard at computing-services.oxford.ac.uk>:

> "We  never decided whether [tei.model.metrical] class contains only <l>
> or both <l> and <lg>. JC's notes say <l>, mine say undecided ... and
> LB's say <q>contains <l> or <lg>, except that Laurent  doesnt like the
> recursion</q>"
>
> Can we have a decision please?
>
> If Laurent's arguments are persuasive, may I suggest that we should
> define three classes:
>
> tei.model.metrical.terminal (member <l>)
> tei.model.metrical.nonterminal (member <lg>)
> tei.model.metrical (members
> tei.model.metrical.terminal|tei.model.nonterminal)
>
> {Probably not those names tho...}
>
> p.s. I see Syd is using <q> where he should be using <quote>  -- or
> should he? :-)
>
>
>
> _______________________________________________
> 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  Sun Oct  2 09:47:16 2005
From: Laurent.Romary at loria.fr (Laurent.Romary at loria.fr)
Date: Sun,  2 Oct 2005 15:47:16 +0200
Subject: [tei-council] winkling out the incls
In-Reply-To: <433ED1CB.5050505@computing-services.oxford.ac.uk>
References: <433ED1CB.5050505@computing-services.oxford.ac.uk>
Message-ID: <1128260836.433fe4e4c10f0@www.loria.fr>

I agree with this!
Laurent

Selon Lou Burnard <lou.burnard at computing-services.oxford.ac.uk>:

> We decided to winkle all reference to tei.incl out of the header
> elements, and (I think) also out of tei.bibl class elements. so that
> means it shouldn't appear inside <respStmt> right?
>
>
> _______________________________________________
> 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  Sun Oct  2 16:56:58 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 2 Oct 2005 16:56:58 -0400 (EDT)
Subject: [tei-council] processing TEI times
Message-ID: <200510022056.j92KuweE024880@pyxis.services.brown.edu>

2005-09-22T11:27+01, Sebastian said:
> On dates/times again, one should bear in mind that XML processors
> may start using datatype information. At the moment, the only thing
> where it matters is in validation; but in the world of W3C Schema
> and XSLT2, the processing application can say "what basic datatype
> did you work out for this attribute". So if our schema said
> "xsd:dateTime | long-regexp-allowing:13:15as-a-time", then the
> processor might take different actions depending on whether you did
> 13:15 or 13:15:00.
> It is not easy to think through whether this matters or not.

2005-09-22T16:31+01, Sebastian said:
> you may one day wish to do a proper sort of TEI-encoded elements
> according to their date. If they emerge into the PSVI as having
> matched a regexp, you'll be at a disadvantage.

I've decided that I (partially) agree with Sebastian. I still believe
whole heartedly that it is incredibly important to be able to record
times that are less precise than to the second, and I still believe
that permitting the value= attribute to directly reflect this reduced
precision is the right way to do this. However, after poking around a
bit I've concluded that it *is* quite possible, if not likely, that
users will run up against software that handles times precise to the
second just fine, but barfs on less precise times.

Thus, I've written a stylesheet for converting a TEI P5 document with
<time> and <date> elements that have reduced precision times on value=
to a similar document with (falsely) precise times. Actually, I've
written two: one for XSLT 1.0 and one for XSLT 2.0 processors. These
stylesheets can be found on the TEI wiki:
  http://www.tei-c.org/wiki/index.php/InsertFalsePrecision1.xsl
  http://www.tei-c.org/wiki/index.php/InsertFalsePrecision2.xsl

Lastly, I've updated the pattern in tei.data.temporal to accept times
precise to only the hour, and imprecise times that also have dates.
Furthermore I've updated the pattern to allow only W3C-legal timezone
designators.

Because the pattern has gotten quite unwieldy, I've also written a
tiny test schema and test file for it. The test schema includes
annotations to explain the sub-patterns. They can be found at
   http://www.tei-c.org/Council/test_time_pattern.rng
   http://www.tei-c.org/Council/test_time_pattern.rnc
   http://www.tei-c.org/Council/test_time_pattern.xml
In order to make it easier for a Council member to read the
annotations, I've put them up separately at 
   http://bauman.zapto.org/~syd/ttpe.html

From sebastian.rahtz at oucs.ox.ac.uk  Sun Oct  2 18:23:50 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 02 Oct 2005 23:23:50 +0100
Subject: [tei-council] processing TEI times
In-Reply-To: <200510022056.j92KuweE024880@pyxis.services.brown.edu>
References: <200510022056.j92KuweE024880@pyxis.services.brown.edu>
Message-ID: <43405DF6.5020902@oucs.ox.ac.uk>

good god!

     <rng:data type="token">
        <rng:param
name="pattern">(-?\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01
])T)?([01][0-9]|2[0-3])(:[0-5][0-9])?(Z|[+\-]((0[0-9]|1[0-3]):[0-5][0-9]|14:00))?
</rng:param>
      </rng:data>

Really, I don't think this is wise. Define a separate datatype
for "isodateformat", and let people change to that if they want.
Add an extra attribute called "@isodate" or something.
But adding "oh and practically anything else" at the end of a list of
datatypes from an external source just does not seem right.

What do others think?

-- 
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 Oct  2 18:35:52 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 2 Oct 2005 18:35:52 -0400
Subject: [tei-council] processing TEI times
In-Reply-To: <43405DF6.5020902@oucs.ox.ac.uk>
References: <200510022056.j92KuweE024880@pyxis.services.brown.edu>
	<43405DF6.5020902@oucs.ox.ac.uk>
Message-ID: <17216.24776.606950.737362@emt.wwp.brown.edu>

> Really, I don't think this is wise. Define a separate datatype for
> "isodateformat", and let people change to that if they want. Add an
> extra attribute called "@isodate" or something. But adding "oh and
> practically anything else" at the end of a list of datatypes from
> an external source just does not seem right.

What do you mean "practically anything else"? It permits almost
nothing else, except the same things that xsd:dateTime and xsd:time
permit, with a precision truncated to hours or seconds.

From Syd_Bauman at Brown.edu  Sun Oct  2 18:43:21 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 2 Oct 2005 18:43:21 -0400
Subject: [tei-council] processing TEI times
In-Reply-To: <17216.24776.606950.737362@emt.wwp.brown.edu>
References: <200510022056.j92KuweE024880@pyxis.services.brown.edu>
	<43405DF6.5020902@oucs.ox.ac.uk>
	<17216.24776.606950.737362@emt.wwp.brown.edu>
Message-ID: <17216.25225.744175.738706@emt.wwp.brown.edu>

[Sorry, hit "send" too soon :-]

In fact, the reason the pattern looks so complicated is precisely to
address what I thought was your previous concern of "practically
anything else". The pattern originally proposed was more permissive
than W3C in a variety of ways (e.g., permitting "+15:00" as a time
zone designator) that this pattern deliberately avoids.

In fact, this pattern is a teeny bit more restrictive than the W3C,
in that it forbids an hour of "24" (which W3C allows, but not in a
canonical representation).

From Syd_Bauman at Brown.edu  Sun Oct  2 19:25:36 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 2 Oct 2005 19:25:36 -0400
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <43305155.6090705@computing-services.oxford.ac.uk>
References: <432CA353.9000105@computing-services.oxford.ac.uk>
	<17200.14028.790906.531915@emt.wwp.brown.edu>
	<43305155.6090705@computing-services.oxford.ac.uk>
Message-ID: <17216.27760.643405.50247@emt.wwp.brown.edu>

Lou Burnard writes:

> >>1. add at place 
> >>   addSpan at place
> >>           -->  tei.data.enumerated
> >What do you propose the value list be? The list{} method proposed
> >permits things like "opposite top left" (which is also permitted in
> >P4). 
> I have no particular proposal. Any list I came up with only be
> advisory anyway.

The point I was trying to make is that if we want to mimic the P4
recommendations we will find it very hard to use tei.data.enumerated.
If we don't want to mimic the syntax P4 used, fine, but it will be
awfully hard to come up with a system that permits the various
combinations P4 allowed. I'll wonder aloud if it would be difficult
to add the capability to <valList> to permit one or more, rather than
just one, from the list.

> > [ met/real/rhyme list for type= of <metDecl> ]
> so here;s a case where an enumeration is both possible and
> desirable. good!

Yes, but it doesn't scale well at all.

> >>2. tei.pointerGroup at domains  
> >>          -->  tei.data.pointers
> >I don't really see it as a plus to permit values that the prose says
> >are invalid just to say we used a datatype directly. The EDW90
> >recommendation matches the prose perfectly. (It is
> >  list { tei.data.pointer, tei.data.pointers }
> >.)
> >On the other hand, ... [could use Schematron]
> Actually, I wonder if it might not be better to rethink this
> attribute into two?

I don't follow you. I really don't like how this attribute and its
cousins targType= and targets= work, so I'm all ears if you have a
different recommendation.

> >>3. schemaSpec at start
> >>    specDesc at atts   
> >>         --> tei.data.names
> >Again, why use a lax constraint when the proper one is readily
> >available just to say you used a datatype? ...
> Is this another instance of the particular problem that we;re using
> "name" sometimes to mean a NMTOKEN and sometimes not?

I don't see how. And I don't think I've ever used "name" to mean
NMTOKEN (or NCName or Name, for that matter).

> >>4. date at precision
> >>       --> tei.data.certainty
> > ...
> I can't remember who suggested having "precision" as an explicit
> attribute on date. It does seem to overlap with the value
> attribute. Unless anyone wants to fight to the death for it, I
> propose we remove it.

Fight to the death? I wouldn't even trade a stale slice of bread for
it. Until someone sits down and really thinks through representations
of precision, accuracy, and certainty, I think we should nuke it.

> >>9.   tei.declarable at default
> >>     tei.identifiable at predeclare
> >>     metSym at terminal
> >>     numeric at trunc
> >>     binary at value                  
> >>        --> are all xsd:boolean (so "unknown" not allowed) ;
> >>could just be tei.data.truthValue with extra rule
> >
> >Could be. And at one point in the history of that EDW90 table,
> >they were. But a week or two ago we agreed to go directly with
> >xsd:boolean.
> 
> So we either have to have a pair of datatypes, one permitting
> "unknown" and one not, or we have to have an additional rule to
> exclude "unknown" in cases where it makes no sense, like these.

Or we could use "tei.data.truthValue" for attribute values for which
"true", "false", and "unknown" all make sense, and "xsd:boolean"
directly for the above, where only "true" and "false" make sense. As
was pointed out before, if you need TEI prose to explain what 'true'
and 'false' mean, you probably shouldn't be encoding texts anyway.

> >>10.  timeline at interval
> >>       when at interval   
> >>       --> tei.data.numeric | -1  (or think of a better way of
> >>           doing the -1)
> >
> >a) We'd go back to needing unit= (I'm not saying this is so horrible,
> >   just want to make sure everyone understands the implications) ...
> > ...
> >Thus, I am now leaning towards
> >   xsd:long { minInclusive = "0" }  |  xsd:token "unknown"
> 
> where did the "unknown" come from? I think it shd remain
> tei.data.numeric, but with the constraint that it can't be smaller
> than -1

My apologies, I thought it was clear. In P4 an interval is either
a) a positive number which, when combined with the value of units=,
   gives you the interval; or
b) the special value '0' meaning that all the intervals are evenly
   spaced, but the size of the intervals is not known; or
c) the special value -1 indicating uncertainty about all the
   intervals in the timeline
My proposal above was intended to use "unknown" instead of "-1"; why
use a funny coded numerical value? It might make perfect sense to use
another keyword for (b), and use "minExclusive" instead of
"minInclusive". Yes, that would be better, if we could just come up
with a good keyword.

I'm not sure we can actually constrain a TEI datatype as you
suggested, but if we can and do use 
   tei.data.numeric { minInclusive = "-1" }
we end up permitting all sorts of values *between* -1 and 0 for which
we have no definition. (Many a good elisp program would solve this by
just using tei.data.numeric, mapping "0" to (b), and any negative
value at all to (c).)

From sebastian.rahtz at oucs.ox.ac.uk  Mon Oct  3 04:17:06 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 03 Oct 2005 09:17:06 +0100
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <17216.27760.643405.50247@emt.wwp.brown.edu>
References: <432CA353.9000105@computing-services.oxford.ac.uk>	<17200.14028.790906.531915@emt.wwp.brown.edu>	<43305155.6090705@computing-services.oxford.ac.uk>
	<17216.27760.643405.50247@emt.wwp.brown.edu>
Message-ID: <4340E902.7030104@oucs.ox.ac.uk>

Syd Bauman wrote:

>If we don't want to mimic the syntax P4 used, fine, but it will be
>awfully hard to come up with a system that permits the various
>combinations P4 allowed. I'll wonder aloud if it would be difficult
>to add the capability to <valList> to permit one or more, rather than
>just one, from the list.
>  
>
how could this work in DTD-land? does it even work in Relax? Obviously,
if you know the target notation, making valList do it is easy....

sebastian

From Syd_Bauman at Brown.edu  Mon Oct  3 09:36:10 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 3 Oct 2005 09:36:10 -0400
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <4340E902.7030104@oucs.ox.ac.uk>
References: <432CA353.9000105@computing-services.oxford.ac.uk>
	<17200.14028.790906.531915@emt.wwp.brown.edu>
	<43305155.6090705@computing-services.oxford.ac.uk>
	<17216.27760.643405.50247@emt.wwp.brown.edu>
	<4340E902.7030104@oucs.ox.ac.uk>
Message-ID: <17217.13258.681138.587896@emt.wwp.brown.edu>

> >If we don't want to mimic the syntax P4 used, fine, but it will be
> >awfully hard to come up with a system that permits the various
> >combinations P4 allowed. I'll wonder aloud if it would be
> >difficult to add the capability to <valList> to permit one or
> >more, rather than just one, from the list.
> >
> how could this work in DTD-land? does it even work in Relax?
> Obviously, if you know the target notation, making valList do it is
> easy....

It would not work in DTD-land; never has, never will. As for RelaxNG,
I don't quite understand the question. I know I can write RelaxNG
patterns that do this:

  attribute place { list { ( "inline" | "supralinear" | "infralinear" |
                           "left" | "right" | "top" | "bottom" |
                           "opposite" | "verso" | "middle" | "center"
                           | "margin" )+ }} # or whatever the list of
                                            # values is

but whether we can translate a <valList> into such a pattern or not
... well, I don't see why not, really, but I leave that to your
expertise.

At one point in EDW90 I recommended a somewhat more complex pattern
(list of lists, essentially) that provides additional useful
constraint, but for which it would be even harder to build a
general-purpose mechanism, and is probably not worth it.

From sebastian.rahtz at oucs.ox.ac.uk  Mon Oct  3 10:51:44 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 03 Oct 2005 15:51:44 +0100
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <17217.13258.681138.587896@emt.wwp.brown.edu>
References: <432CA353.9000105@computing-services.oxford.ac.uk>	<17200.14028.790906.531915@emt.wwp.brown.edu>	<43305155.6090705@computing-services.oxford.ac.uk>	<17216.27760.643405.50247@emt.wwp.brown.edu>	<4340E902.7030104@oucs.ox.ac.uk>
	<17217.13258.681138.587896@emt.wwp.brown.edu>
Message-ID: <43414580.2080008@oucs.ox.ac.uk>

Syd Bauman wrote:

>It would not work in DTD-land; never has, never will. 
>
I thought one of our baselines was compatibility with DTD
so far as possible? what would your code degrade into?

>As for RelaxNG,
>I don't quite understand the question. I know I can write RelaxNG
>patterns that do this:
>
>  attribute place { list { ( "inline" | "supralinear" | "infralinear" |
>                           "left" | "right" | "top" | "bottom" |
>                           "opposite" | "verso" | "middle" | "center"
>                           | "margin" )+ }} # or whatever the list of
>                                            # values is
>  
>
really? I didn't realize. Fine, that's easy to create from a valList
if it is so instantiated. You'd have to change the syntax of valList,
obviously.

-- 
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 Oct  3 11:55:16 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 3 Oct 2005 11:55:16 -0400
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <43414580.2080008@oucs.ox.ac.uk>
References: <432CA353.9000105@computing-services.oxford.ac.uk>
	<17200.14028.790906.531915@emt.wwp.brown.edu>
	<43305155.6090705@computing-services.oxford.ac.uk>
	<17216.27760.643405.50247@emt.wwp.brown.edu>
	<4340E902.7030104@oucs.ox.ac.uk>
	<17217.13258.681138.587896@emt.wwp.brown.edu>
	<43414580.2080008@oucs.ox.ac.uk>
Message-ID: <17217.21604.334994.269032@emt.wwp.brown.edu>

> I thought one of our baselines was compatibility with DTD so far as
> possible? 

Compatibility, yes; equivalent level of constraint, no. We have
always understood that there are constraints modern schema languages
can provide that DTDs can't. E.g., DTDs cannot express dates, times,
numbers, etc., yet we use them to constrain our attribute values.

> what would your code degrade into?

CDATA, just as we had in P4.

The much harder question is how will your odd2dtd process recognize
this as something it cannot translate to DTD-language, and thus needs
to spit out as CDATA? To that I have no good answer. (How does it do
this with, say, tei.data.temporal?)

> really? I didn't realize. Fine, that's easy to create from a
> valList if it is so instantiated. You'd have to change the syntax
> of valList, obviously.

So we'd need something like <valList quantity="oneOrMore"> or
<valList org="list"> or some such?

From sebastian.rahtz at oucs.ox.ac.uk  Mon Oct  3 12:34:12 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 03 Oct 2005 17:34:12 +0100
Subject: [tei-council] Datatypes.... continued
In-Reply-To: <17217.21604.334994.269032@emt.wwp.brown.edu>
References: <432CA353.9000105@computing-services.oxford.ac.uk>	<17200.14028.790906.531915@emt.wwp.brown.edu>	<43305155.6090705@computing-services.oxford.ac.uk>	<17216.27760.643405.50247@emt.wwp.brown.edu>	<4340E902.7030104@oucs.ox.ac.uk>	<17217.13258.681138.587896@emt.wwp.brown.edu>	<43414580.2080008@oucs.ox.ac.uk>
	<17217.21604.334994.269032@emt.wwp.brown.edu>
Message-ID: <43415D84.5090005@oucs.ox.ac.uk>

Syd Bauman wrote:

>
>>what would your code degrade into?
>>    
>>
>
>CDATA, just as we had in P4.
>  
>
ah yes, of course...

>
>The much harder question is how will your odd2dtd process recognize
>this as something it cannot translate to DTD-language, and thus needs
>to spit out as CDATA? To that I have no good answer. (How does it do
>this with, say, tei.data.temporal?)
>  
>
it just translates more or less everything to CDATA :-}

>So we'd need something like <valList quantity="oneOrMore"> or
><valList org="list"> or some such?
>
>  
>
indeed.

-- 
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 Oct  3 16:21:24 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 03 Oct 2005 21:21:24 +0100
Subject: [tei-council] TEI relaxng schemas, pattern names
Message-ID: <434192C4.5040308@oucs.ox.ac.uk>

Those of you who read our relaxng schemas for fun will know that
they are full of patterns like:

 div = element div {div.content,div.attributes}
 div.content =  p+

Although the _element_ <div> is in a namespace, and protected
from conflict, the _pattern_ "div" is global. If you merge the TEI
with another language, and that too defines a pattern "div", it's
an error.

To get around this, I have done some experimental
work on the processing
and found that I can insert eg "_TEI_" in front of each
pattern, so that the above would be:

 _TEI_div = element div {div.content,div.attributes}
 div.content =  _TEI_p+

Question: should I make this standard
for our output? It means the schemas are less legible,
but makes them more portable.

-- 
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 Oct  3 20:44:03 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 04 Oct 2005 09:44:03 +0900
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <434192C4.5040308@oucs.ox.ac.uk> (Sebastian Rahtz's message of
	"Mon, 03 Oct 2005 21:21:24 +0100")
References: <434192C4.5040308@oucs.ox.ac.uk>
Message-ID: <ygfu0fyaz70.fsf@kanji.zinbun.kyoto-u.ac.jp>

Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> writes:

>  _TEI_div = element div {div.content,div.attributes}
>  div.content =  _TEI_p+
>
> Question: should I make this standard
> for our output? It means the schemas are less legible,
> but makes them more portable.

I am strongly in favor of this, since, as I understand it will solve
the problem of intermixing with foreign schemas (e.g. MODS)!?

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  Mon Oct  3 21:21:38 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 3 Oct 2005 21:21:38 -0400
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <434192C4.5040308@oucs.ox.ac.uk>
References: <434192C4.5040308@oucs.ox.ac.uk>
Message-ID: <17217.55586.238520.297390@emt.wwp.brown.edu>

>  _TEI_div = element div {div.content,div.attributes}
>  div.content =  _TEI_p+

Wouldn't that really have to be

  _TEI_div = element div { _TEI_div.content, _TEI_div.attributes }
  _TEI_div.content =  _TEI_p+

(Actually, isn't "div" already a reserved pattern in RelaxNG, like
"start" or "element"?)

> Question: should I make this standard for our output? It means the
> schemas are less legible, but makes them more portable.

I think I'm mildly in favor. I'm not sure it's really all that
important, and (as someone who does read the schemas quite a bit) I
can see it being annoying, but other than that it can't hurt, and it
really might help someone at some point down the road quite a bit.

However, I think it a good idea that the "_TEI_" (or whatever)
prefixes *not* show up in the snippets in the Guidelines.

From sebastian.rahtz at oucs.ox.ac.uk  Tue Oct  4 04:13:46 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 04 Oct 2005 09:13:46 +0100
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <17217.55586.238520.297390@emt.wwp.brown.edu>
References: <434192C4.5040308@oucs.ox.ac.uk>
	<17217.55586.238520.297390@emt.wwp.brown.edu>
Message-ID: <434239BA.5070500@oucs.ox.ac.uk>

Syd Bauman wrote:

>> _TEI_div = element div {div.content,div.attributes}
>> div.content =  _TEI_p+
>>    
>>
>
>Wouldn't that really have to be
>
>  _TEI_div = element div { _TEI_div.content, _TEI_div.attributes }
>  _TEI_div.content =  _TEI_p+
>
>(Actually, isn't "div" already a reserved pattern in RelaxNG, like
>"start" or "element"?)
>  
>
I thought about that. Maybe I'll implement it too.

>However, I think it a good idea that the "_TEI_" (or whatever)
>prefixes *not* show up in the snippets in the Guidelines.
>  
>

absolutely!

I have it as an XSLT parameter, so documentation runs will
set it to blank.
sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Tue Oct  4 04:17:34 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 04 Oct 2005 09:17:34 +0100
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <ygfu0fyaz70.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <434192C4.5040308@oucs.ox.ac.uk>
	<ygfu0fyaz70.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43423A9E.9000109@oucs.ox.ac.uk>

Christian Wittern wrote:

>
>I am strongly in favor of this, since, as I understand it will solve
>the problem of intermixing with foreign schemas (e.g. MODS)!?
>
>  
>
can you remind me of the details of this, so that
I can test it?

sebastian

From Syd_Bauman at Brown.edu  Tue Oct  4 08:13:56 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 4 Oct 2005 08:13:56 -0400
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <434239BA.5070500@oucs.ox.ac.uk>
References: <434192C4.5040308@oucs.ox.ac.uk>
	<17217.55586.238520.297390@emt.wwp.brown.edu>
	<434239BA.5070500@oucs.ox.ac.uk>
Message-ID: <17218.29188.119435.76587@emt.wwp.brown.edu>

> I have it as an XSLT parameter, so documentation runs will set it
> to blank. 

Oooh ... I think I like that. It means that in my local system, I can
set it to blank too, and not have to see those ugly prefixes. On the
other hand, are there any downsides to encouraging inconsistency in
the pattern names between different users (or even between different
customizations for the same user)?

From sebastian.rahtz at oucs.ox.ac.uk  Tue Oct  4 08:23:55 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 04 Oct 2005 13:23:55 +0100
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <17218.29188.119435.76587@emt.wwp.brown.edu>
References: <434192C4.5040308@oucs.ox.ac.uk>	<17217.55586.238520.297390@emt.wwp.brown.edu>	<434239BA.5070500@oucs.ox.ac.uk>
	<17218.29188.119435.76587@emt.wwp.brown.edu>
Message-ID: <4342745B.2060501@oucs.ox.ac.uk>

Syd Bauman wrote:

>>I have it as an XSLT parameter, so documentation runs will set it
>>to blank. 
>>    
>>
>
>Oooh ... I think I like that. It means that in my local system, I can
>set it to blank too, and not have to see those ugly prefixes. On the
>other hand, are there any downsides to encouraging inconsistency in
>the pattern names between different users (or even between different
>customizations for the same user)?
>
>  
>
I share the concern. But I don't have an answer...

sebastian

From Syd_Bauman at Brown.edu  Tue Oct  4 13:14:16 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 4 Oct 2005 13:14:16 -0400
Subject: [tei-council] datatype issues (part 1)
In-Reply-To: <43311897.3020303@computing-services.oxford.ac.uk>
References: <432321F4.2070405@computing-services.oxford.ac.uk>
	<17188.14848.10373.576601@emt.wwp.brown.edu>
	<432c6d11beae57e26e676af90eb58055@loria.fr>
	<43248510.70009@oucs.ox.ac.uk>
	<6c37a181af58aacf8ef886c861d7c02a@loria.fr>
	<17189.51427.518938.47525@emt.wwp.brown.edu>
	<4325CC68.1050400@computing-services.oxford.ac.uk>
	<17199.464.243621.414963@emt.wwp.brown.edu>
	<4330449D.1070605@computing-services.oxford.ac.uk>
	<17200.36733.850364.960368@emt.wwp.brown.edu>
	<43311897.3020303@computing-services.oxford.ac.uk>
Message-ID: <17218.47208.150812.839364@emt.wwp.brown.edu>

> > Yes! That's it in a nutshell. (EDW90 does propose all the W3C
> > temporal types save duration be included;
> What was the reasoning for not including duration again?

I don't know that there was any good reasoning. We need to think out 
  <date>, <time>
  <dateRange>, <timeRange>
  <dateStruct>, <timeStruct>
and the various other uses of tei.data.temporal. It certainly
wouldn't make sense to use a duration on, e.g., from= and to= of
<dateRange>. 

> Let me just confirm this because my head must be off in the clouds,
> does ISO 8601:2004 say that in order to have a valid time it has to
> be complete to the second? ... wikipedia ... says:
> "It is also acceptable to omit elements to reduce precision. hh:mm,
> hhmm, and hh are all used."
> ...
> Now, is the problem with the W3C Schema datatypes and the way they
> implement the ISO standard? I know there are some variations, but
> it seems like a pretty major one to insist on 13:14:54 instead of
> just 13:15.

Yes, you have it right, and I think this question has already been
answered, but thought it worth repeating: ISO 8601 permits both hh:mm
and hh, and also hh,hh (fractions of an hour) & hh:mm,mm (fractions
of a minute). W3C does not permit any of these. I don't think the
fractional hours or minutes are that important, but others may
disagree.

From Syd_Bauman at Brown.edu  Tue Oct  4 15:08:31 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 4 Oct 2005 15:08:31 -0400
Subject: [tei-council] tei.data.blah
In-Reply-To: <43317F10.90700@oucs.ox.ac.uk>
References: <4329DEA1.2050903@computing-services.oxford.ac.uk>
	<4329E16E.4060106@oucs.ox.ac.uk>
	<17201.31023.728951.417524@emt.wwp.brown.edu>
	<43317F10.90700@oucs.ox.ac.uk>
Message-ID: <17218.54063.210430.625047@emt.wwp.brown.edu>

LB> I have just noticed that using tei.data.blah as the name for the
LB> datatype "blah", as recommended in edw90, gives a tiny opporunity
LB> for confusion if we keep the convention that "tei.blah" is the
LB> name for the *class* "blah".... especially as we have a class
LB> called "data"!

SR> so call them macro.data.blah

SB> Either is fine with me.

SR> we could resolve this next week in the class meeting. ...

Errr... we didn't. Given the new naming conventions we did hammer out,
though, do we still need to worry about this? "tei.blah" is slated to
become "tei.model.blah" or perhaps "tei.att.blah", so we've no
worries, right?

From sebastian.rahtz at oucs.ox.ac.uk  Tue Oct  4 15:38:10 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 04 Oct 2005 20:38:10 +0100
Subject: [tei-council] tei.data.blah
In-Reply-To: <17218.54063.210430.625047@emt.wwp.brown.edu>
References: <4329DEA1.2050903@computing-services.oxford.ac.uk>	<4329E16E.4060106@oucs.ox.ac.uk>	<17201.31023.728951.417524@emt.wwp.brown.edu>	<43317F10.90700@oucs.ox.ac.uk>
	<17218.54063.210430.625047@emt.wwp.brown.edu>
Message-ID: <4342DA22.7090302@oucs.ox.ac.uk>

Syd Bauman wrote:

>SR> we could resolve this next week in the class meeting. ...
>
>Errr... we didn't. Given the new naming conventions we did hammer out,
>though, do we still need to worry about this? "tei.blah" is slated to
>become "tei.model.blah" or perhaps "tei.att.blah", so we've no
>worries, right?
>  
>

the pattern tei.date.XXX seems to fit in with our changes,
so I think we leave well alone.

Although I think we should drop the "tei." prefix passim
now. The argument for introducing it (sharing with other
schemata) is proved not to work, and I have introduced
a new method which works better (the optional $patternPrefix)

-- 
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  Tue Oct  4 18:04:51 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 4 Oct 2005 18:04:51 -0400
Subject: [tei-council] tei.data.blah
In-Reply-To: <4342DA22.7090302@oucs.ox.ac.uk>
References: <4329DEA1.2050903@computing-services.oxford.ac.uk>
	<4329E16E.4060106@oucs.ox.ac.uk>
	<17201.31023.728951.417524@emt.wwp.brown.edu>
	<43317F10.90700@oucs.ox.ac.uk>
	<17218.54063.210430.625047@emt.wwp.brown.edu>
	<4342DA22.7090302@oucs.ox.ac.uk>
Message-ID: <17218.64643.109967.995797@emt.wwp.brown.edu>

> Although I think we should drop the "tei." prefix passim now. The
> argument for introducing it (sharing with other schemata) is proved
> not to work, and I have introduced a new method which works better
> (the optional $patternPrefix)

I think I'm in favor.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Oct  4 22:23:55 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 05 Oct 2005 11:23:55 +0900
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <43423A9E.9000109@oucs.ox.ac.uk> (Sebastian Rahtz's message of
	"Tue, 04 Oct 2005 09:17:34 +0100")
References: <434192C4.5040308@oucs.ox.ac.uk>
	<ygfu0fyaz70.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<43423A9E.9000109@oucs.ox.ac.uk>
Message-ID: <ygfachobt1g.fsf@kanji.zinbun.kyoto-u.ac.jp>

Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> writes:

> Christian Wittern wrote:
>
>>
>>I am strongly in favor of this, since, as I understand it will solve
>>the problem of intermixing with foreign schemas (e.g. MODS)!?
>>
>>  
>>
> can you remind me of the details of this, so that
> I can test it?

I had a customization which replaces (if I remember correctly) the
content of biblStruct with a MODS record.  The problem arises, because
some names defined in MODS (e.g. "name") clash with TEI names.  Do you
need the files again, or is this good enough?

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 Oct  4 22:31:29 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 05 Oct 2005 11:31:29 +0900
Subject: [tei-council] Council class meeting notes
Message-ID: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>

Dear Council members,

As you will be aware, some volunteers from among us (Syd, John, Laurent,
Lou, Sebastian, James and myself) met in Oxford at the end of
September to discuss a complete overhaul on classes.  We spent two
full days and then some of us another morning on this, discussing some
general principles and then trying to apply them to some modules. The
notes from this meeting are now at
http://www.tei-c.org/Council/tcm20.xml?style=printable . I would like
to encourage all Council members to look at this document and
familiarize themselve with the content of this document.  One open
question that needs addressing urgently is the issue of how classes
are to be named -- we discussed this and the discussion is reflected
in http://www.tei-c.org/Drafts/edw87.xml?style=printable, but no
decision, not even a coherent proposal has been reached.

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 sebastian.rahtz at oucs.ox.ac.uk  Wed Oct  5 04:17:57 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 05 Oct 2005 09:17:57 +0100
Subject: [tei-council] TEI relaxng schemas, pattern names
In-Reply-To: <ygfachobt1g.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <434192C4.5040308@oucs.ox.ac.uk>	<ygfu0fyaz70.fsf@kanji.zinbun.kyoto-u.ac.jp>	<43423A9E.9000109@oucs.ox.ac.uk>
	<ygfachobt1g.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43438C35.1060401@oucs.ox.ac.uk>

Christian Wittern wrote:

>I had a customization which replaces (if I remember correctly) the
>content of biblStruct with a MODS record.  The problem arises, because
>some names defined in MODS (e.g. "name") clash with TEI names.  Do you
>need the files again, or is this good enough?
>  
>
I have found the MODS schema you sent me. I'll see if I can make it fly

-- 
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 Oct  5 13:28:45 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 05 Oct 2005 18:28:45 +0100
Subject: The Naming of Classes [was Re: [tei-council] Council class meeting
	notes]
In-Reply-To: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43440D4D.9040207@oucs.ox.ac.uk>

Christian Wittern wrote:
>  One open
> question that needs addressing urgently is the issue of how classes
> are to be named -- we discussed this and the discussion is reflected
> in http://www.tei-c.org/Drafts/edw87.xml?style=printable, but no
> decision, not even a coherent proposal has been reached.
>

As a step towards this, I have now written a substantial revision of the 
original edw87, after discussion with Sebastian and James (they however 
bear responsibility only for not having been able to persuade me not to)

To facilitate comparison, I have left the original version of edw87 
unchanged, though it does form the basis of my revision. The rewrite is 
available from http://www.tei-c.org/Drafts/edw87a.xml

Comments welcomed-- especially if you think the underlying principles 
listed at the start of the rewrite are seriously flawed or 
incomprehensible. The details of the names themselves are less serious 
-- but if you don't like them, proposals for a better alternative add 
great weight to your objection.

Note that the list doesn't yet include any of the new classes proposed 
in tcm20.

Lou

From sebastian.rahtz at oucs.ox.ac.uk  Wed Oct  5 15:43:16 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 05 Oct 2005 20:43:16 +0100
Subject: [tei-council] edw87a
Message-ID: <43442CD4.9040105@oucs.ox.ac.uk>

As I have said to Lou many times over the past few days, my only
problem with this scheme is that one man's Like is another man's Part.
So if I had made that table, it is quite likely that I'd have made
different decisions on some of the cases.  But I think the advantages
outweigh the disadvantages, in making it clear to the reader what
thoughts went through the mind of the Namer.  So I'm happy to commend
the thing, and suggest that it be Made So.

I think it's worth stressing that Lou's edw87a is actually following
the same train of thought as SB/SR/CW/JC last week did when they
compiled edw87.  So its not a choice between them, really; a finished
table in edw87 would have had the same problems as edw87a

-- 
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 Julia_Flanders at Brown.edu  Wed Oct  5 17:25:29 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Wed, 5 Oct 2005 17:25:29 -0400
Subject: [tei-council] I18N proposal for review
Message-ID: <a06200727bf69f4a2ad4c@[128.148.157.102]>

Sebastian, Veronika, and I have completed a pretty-much-final draft 
of the I18N proposal to ALLC, which is now up at the TEI web site and 
ready for review at http://www.tei-c.org/I18N/

Please take a look and let us know of any urgent suggested changes or 
additions. We'll submit it to ALLC within a week.

Best wishes, Julia

From Syd_Bauman at Brown.edu  Wed Oct  5 21:28:12 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 5 Oct 2005 21:28:12 -0400
Subject: The Naming of Classes [was Re: [tei-council] Council class meeting
	notes]
In-Reply-To: <43440D4D.9040207@oucs.ox.ac.uk>
References: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<43440D4D.9040207@oucs.ox.ac.uk>
Message-ID: <17220.32172.734583.802478@emt.wwp.brown.edu>

I haven't yet read this carefully, but on quick glance EDW87a looks
OK to me. A few nit-picks jump to mind (I'd prefer "-like" or
"Siblings" to "Like"; the prose describing subclasses is twisted;
EDW79 and EDW86 are no longer good places to look for lists of
attribute names currently in use), but mostly we need to merge in the
new classes and address some details.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Wed Oct  5 23:40:16 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 06 Oct 2005 12:40:16 +0900
Subject: [tei-council] I18N proposal for review
In-Reply-To: <a06200727bf69f4a2ad4c@[128.148.157.102]> (Julia Flanders's
	message of "Wed, 5 Oct 2005 17:25:29 -0400")
References: <a06200727bf69f4a2ad4c@[128.148.157.102]>
Message-ID: <ygfirwbb9en.fsf@kanji.zinbun.kyoto-u.ac.jp>

Julia Flanders <Julia_Flanders at Brown.edu> writes:

> Sebastian, Veronika, and I have completed a pretty-much-final draft of
> the I18N proposal to ALLC, which is now up at the TEI web site and
> ready for review at http://www.tei-c.org/I18N/
>
> Please take a look and let us know of any urgent suggested changes or
> additions. We'll submit it to ALLC within a week.

I have read through this and can only say this is very good, solid work.
Needless to say that I am especially happy with the list of proposed
translations:-)  I really hope that the work can proceed as envisioned.

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 Oct  6 00:52:58 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 06 Oct 2005 13:52:58 +0900
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <43440D4D.9040207@oucs.ox.ac.uk> (Lou Burnard's message of "Wed,
	05 Oct 2005 18:28:45 +0100")
References: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<43440D4D.9040207@oucs.ox.ac.uk>
Message-ID: <ygfmzln8cwl.fsf@kanji.zinbun.kyoto-u.ac.jp>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> To facilitate comparison, I have left the original version of edw87
> unchanged, though it does form the basis of my revision. The rewrite
> is available from http://www.tei-c.org/Drafts/edw87a.xml
>
> Comments welcomed-- especially if you think the underlying principles
> listed at the start of the rewrite are seriously flawed or
> incomprehensible. The details of the names themselves are less serious
> -- but if you don't like them, proposals for a better alternative add
> great weight to your objection.
>

I don't have really serious objections anymore, although two points
strike me as unfortunate:  

For model classes that are populated from modules (like the
*dictionary* stuff), this can not anymore be guessed from the name.
Since in practice the knowledge were something comes from is needed to
write customizations, it would be useful to see this reflected
somewhat in the naming.

*Part and *Like are not really clearly distinguishable. And *Like
really sounds a bit silly.  In what way is chunk pLike? If siblings
are the criterium, pSiblings would maybe make more sense?

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 Oct  6 04:48:19 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 06 Oct 2005 09:48:19 +0100
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <ygfmzln8cwl.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>	<43440D4D.9040207@oucs.ox.ac.uk>
	<ygfmzln8cwl.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <4344E4D3.1000504@oucs.ox.ac.uk>

Christian Wittern wrote:

>
>*Part and *Like are not really clearly distinguishable. And *Like
>really sounds a bit silly.  In what way is chunk pLike? If siblings
>are the criterium, pSiblings would maybe make more sense?
>
>  
>
"Siblings" does not really seem right to be. That implies shared parentage.
a <list> is "Like" a <p> in sort of places it appears, ie at a block level.

I agree, the word "Like" may not be perfect. But I don't see an obvious 
alternative

sebastian

From Syd_Bauman at Brown.edu  Thu Oct  6 10:57:38 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 6 Oct 2005 10:57:38 -0400
Subject: [tei-council] Datatype : roundup
In-Reply-To: <4332B30A.4060700@computing-services.oxford.ac.uk>
References: <4331E3CC.6020908@computing-services.oxford.ac.uk>
	<17202.18429.528819.465597@emt.wwp.brown.edu>
	<4332770F.9020209@computing-services.oxford.ac.uk>
	<17202.35039.694032.99577@emt.wwp.brown.edu>
	<4332B30A.4060700@computing-services.oxford.ac.uk>
Message-ID: <17221.15202.193503.39940@emt.wwp.brown.edu>

SB> I really don't see why not permit percentages. Users had the
SB> choice in P4, when we couldn't even validate it. Now we can.

LB> simplicity, clarity, precision...

SB> While I suppose it is simpler for software writers to have 1
SB> system rather than 2, there is nothing more clear nor more
SB> precise about "0.824" than "82.4%". While I have some sympathy
SB> with the idea of reducing choices for users, this is one place
SB> where I think users like the choice.

LB> I see no evidence for this asserttion at all. Since both
LB> representations mean exactly the same thing, and are exactly
LB> inter-convertible, I think it just looks silly not to come down
LB> on one side of the fence or the other.

If we ask a random sampling of 50-200 TEI users whether they'd prefer
to always use decimal representation (whether xsd:decimal or
xsd:double) like "0.824" or always use percentages like "8.24%", I'll
buy you a beer if > 0.80 of them all agree on one or the other.

LB> I think this is a mistake, actually. Decimal was a better choice,
LB> since it can represent any number, real or integer, no matter how
LB> big. It means you can;t use scientific notation, which someone
LB> folks on TEI-L suddenly woke up and asked for.

SB> So you think we have more users who really want to represent
SB> numbers with greater than 16 (decimal) digits of precision than
SB> users who want to represent numbers in scientific notation? As I
SB> had hoped my example would demonstrate, that much precision is
SB> not something we humans generally deal with.

LB> No, I think that if there are 10 people in the world who want to
LB> use a numeric datatype, 8 of them might want to use what one
LB> might call unscientific notation, and 9.9 of them will want to
LB> represent values representable to an accuracy less than 8 decimal
LB> digits!

That seems like a pretty strong argument in favor of using
xsd:double! If 20% of people in the world want to use scientific
notation, but only 1% want > 8 places of precision, let alone > 16
places of precision, we should most certainly use xsd:double, not
xsd:decimal. I'd much prefer to tell the far less than 1% that they
can't represent their *huge* numbers precisely than to tell the 20%
they can't represent their numbers with scientific notation.

My point is this: even in the hard sciences, representation of any
number to > 16 digits of precision is almost unheard of.
Representation of numbers that are extremely unwieldy using decimal
notation (which is, after all, why scientific notation was invented)
is quite common.

* the speed of light is defined by CGPM to only 9 digits of
  precision, according to Wikipedia. Most of us would probably prefer
    <measure quantity="3e8" unit="cm/s">C</measure>
  to
    <measure quantity="300000000" unit="m/s">C</measure>
  or the more precise
    <measure quantity="299792458" unit="m/s">C</measure>
  or
    <measure quantity="1.08e9" unit="km/h">C</measure>
  to
    <measure quantity="1080000000" unit="km/h">C</measure>
  or the more precise
    <measure quantity="1079252849" unit="kn/h">C</measure>
  but any of these is perfectly OK if quantity is an xsd:double.

* Avogadro's number is usually described as roughly 6.022e23. Can you
  imagine needing to express this as <num
  value="602214199000000000000000">? Kind of defeats the purpose,
  especially when there's really no solid agreement on what the
  number *is* past that first "1".

* If I understand correctly, the computers NASA used to send men to
  the moon had "double precision" capability, but these instructions
  used two 16-bit registers, i.e., roughly the same precision as
  today's xsd:int and xsd:float.

BTW, the one obvious reason to want to use xsd:decimal (whether we
use xsd:double alone as I'm now advocating, or xsd:double|xsd:long,
which I'd be perfectly happy with, too) are encoding books of
mathematical tables and tables of physical constants and the like.

I just skimmed through my copy of CRC Standard Mathematical Tables,
and found
 - tens, perhaps hundreds of pages of things to 5 & 6 places
 - a few pages of things to 8 places
 - one large multi-page table to 9 places (compound interest --
   I wonder what that tells us! :-)
 - one entry (the number of seconds per radian) to 11 places
 - only 3 tables that would require > 16 digits precision:
   sums of reciprocal powers, Bernoulli numbers, and Euler numbers.
   (Anyone remember what those things are? I sure don't :-)

LB> I now think maybe we should have a different datatype for
LB> [scientific notation].

SB> If we split scientific notation out to a different datatype, won't we
SB> need a disjunction of the two datatypes in most if not all instances
SB> anyway? And the disjunction (whether of two separate TEI datatypes or
SB> of two xsd: datatypes inside a TEI datatype) might be a bit confusing
SB> for implementers. But it shouldn't be impossible to deal with (could
SB> always just assume that if it's not in scientific notation, it is an
SB> xsd:decimal).

LB> I dont think that sort of "assumption" is something an XML
LB> validator can do, is it? 

True, but the validator doesn't have to do any such thing. It just
has to say "yes, this thing is a valid xsd:decimal OR a valid
xsd:double". Other processes will have to actually figure out what
the value *means*, e.g. to sort by it, or generate a scaled value of
it for use in an SVG or whatever.

LB> But we could certainly say the numeric datatype maps onto
LB> xsd:decimal|xsd:float if that would make you happy.

[I presume you mean "xsd:double" -- we haven't considered xsd:float,
and I see no reason why we should.]

I think the worst that could happen in this case is some developers
curse us for having been so cavalier with their time and effort.
Fine, let's go with 
   data.numeric = xsd:decimal | xsd:double

From lou.burnard at computing-services.oxford.ac.uk  Thu Oct  6 13:19:42 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 06 Oct 2005 18:19:42 +0100
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <ygfmzln8cwl.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>	<43440D4D.9040207@oucs.ox.ac.uk>
	<ygfmzln8cwl.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43455CAE.9050706@oucs.ox.ac.uk>

Christian Wittern wrote:

> 
> For model classes that are populated from modules (like the
> *dictionary* stuff), this can not anymore be guessed from the name.
> Since in practice the knowledge were something comes from is needed to
> write customizations, it would be useful to see this reflected
> somewhat in the naming.

I agree with this objective: I tried to do this to some extent by using 
"entry" as the prototype name, since one always talks about dictionary 
entries. But I agree that more attention is needed here. The dictionary 
chapter is the one which uses classes most heavily at present, and I 
need to study the way it does so a bit more carefully.

> 
> *Part and *Like are not really clearly distinguishable. And *Like
> really sounds a bit silly.  In what way is chunk pLike? If siblings
> are the criterium, pSiblings would maybe make more sense?
> 

I am sorry if the two are not distinguishable, since the distinction is 
really rather critical! "chunk" is "pLike" in the sense that its members 
are "like" ps -- they occur at the same hierarchic level as p  and they 
are semantically associated. I agree that this is a bit of a stretch for 
  "chunk" though, since the members of that class really have nothing in 
common except for their hierarchic position. I hope you agree that the 
distinction works better with e.g. bibLike and bibPart.

I didn't choose "sibling" because it seemed to me that many xLike class 
members would have siblings which were *not* xLike. For example hiLike 
things are not really dateLike, but they are both siblings (and both 
"pPart"s!). But I've no quarrel with changing "like" to "sib". (It would 
get rid of my all time favourite which no-one has yet commented 
on/noticed i.e. "model.uLike" )

As Sebastian points out, deciding  whether something is "xLike" or 
"yPart" for a given x which is a member of y is likely often to be a 
rather subjective decision. The TEI is full of rather subjective 
decisions about how things should be named, and I'm very happy to review 
particular cases, or -- if the cases turn out to be rather numerous -- 
to rethink the whole exercise. But what alternative proposals do we have?

> All the best,
> 
> Christian
> 
> 

From James.Cummings at computing-services.oxford.ac.uk  Thu Oct  6 13:22:51 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Thu, 06 Oct 2005 18:22:51 +0100
Subject: [tei-council] I18N proposal for review
In-Reply-To: <ygfirwbb9en.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <a06200727bf69f4a2ad4c@[128.148.157.102]>
	<ygfirwbb9en.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43455D6B.70002@computing-services.oxford.ac.uk>

Christian Wittern wrote:
> Julia Flanders <Julia_Flanders at Brown.edu> writes:
> 
> 
>>Sebastian, Veronika, and I have completed a pretty-much-final draft of
>>the I18N proposal to ALLC, which is now up at the TEI web site and
>>ready for review at http://www.tei-c.org/I18N/
> I have read through this and can only say this is very good, solid work.
> Needless to say that I am especially happy with the list of proposed
> translations:-)  I really hope that the work can proceed as envisioned.

I too have only had a quick look at it so far, but would echo 
Christian's comments.  I'm quite happy with the proposed languages, 
and  congratulate Sebastian, Veronika and Julia on a job well done. 
(I'll read it through more carefully soon and see if I can come up 
with any pedantic nit-picks. ;-) )

-James

From nsmith at email.unc.edu  Thu Oct  6 13:32:51 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Thu, 6 Oct 2005 13:32:51 -0400 (Eastern Daylight Time)
Subject: [tei-council] I18N proposal for review
In-Reply-To: <a06200727bf69f4a2ad4c@[128.148.157.102]>
Message-ID: <Pine.WNT.4.10.10510061326160.3848-100000@AALCD49.lib.unc.edu>

Julia, Sebastian, and Veronika:

You did a remarkable job with clearly describing quite a complex project.
Ambitious, but looks very doable. I have a slight concern about proposed
deadlines, but it might be fine if you already have people lined up and
planning to work within a tight schedule.

Again, great work and all the best, ns   

all the best, ns

On Wed, 5 Oct 2005, Julia Flanders wrote:

> Sebastian, Veronika, and I have completed a pretty-much-final draft 
> of the I18N proposal to ALLC, which is now up at the TEI web site and 
> ready for review at http://www.tei-c.org/I18N/
> 
> Please take a look and let us know of any urgent suggested changes or 
> additions. We'll submit it to ALLC within a week.
> 
> Best wishes, Julia
> _______________________________________________
> 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  Sat Oct  8 07:01:26 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 08 Oct 2005 12:01:26 +0100
Subject: The Naming of Classes [was Re: [tei-council] Council class meeting
	notes]
In-Reply-To: <17220.32172.734583.802478@emt.wwp.brown.edu>
References: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>	<43440D4D.9040207@oucs.ox.ac.uk>
	<17220.32172.734583.802478@emt.wwp.brown.edu>
Message-ID: <4347A706.9010606@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>I haven't yet read this carefully, but on quick glance EDW87a looks
>OK to me.
>

Good!

> A few nit-picks jump to mind (I'd prefer "-like" or
>"Siblings" to "Like"
>
I think introducing a hyphen into the world of TEI naming 
meta-characters really would be inconsistent., and "Sibling" is both too 
long and (I think) misleading -- see my reply to Christian yesterday.

>; the prose describing subclasses is twisted;
>  
>
Please make a suggestion for untwisting it.

>EDW79 and EDW86 are no longer good places to look for lists of
>attribute names currently in use),
>

Yes, I just took that text unchanged.

> but mostly we need to merge in the
>new classes and address some details.
>  
>

Also a check that all existing class names are actually covered (I found 
one or two missing).

From Syd_Bauman at Brown.edu  Sat Oct  8 07:48:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 8 Oct 2005 07:48:11 -0400
Subject: The Naming of Classes [was Re: [tei-council] Council class meeting
	notes]
In-Reply-To: <4347A706.9010606@computing-services.oxford.ac.uk>
References: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<43440D4D.9040207@oucs.ox.ac.uk>
	<17220.32172.734583.802478@emt.wwp.brown.edu>
	<4347A706.9010606@computing-services.oxford.ac.uk>
Message-ID: <17223.45563.392188.708157@emt.wwp.brown.edu>

> I think introducing a hyphen into the world of TEI naming
> meta-characters really would be inconsistent., and "Sibling" is
> both too long and (I think) misleading -- see my reply to Christian
> yesterday.

I was figuring we'd introduce these hyphens in a consistent way. But
your reply to Christian yesterday convinced me that "Sibling" is even
less desirable than "Like" (or "-like").

> Please make a suggestion for untwisting it.

<item>If the class members are all children of the element after
which the class is named, then the first suffix should be
<code>Part</code>; if the class members are all siblings of the
element after which the class is named, then the first suffix should
be <code>Like</code>.</item>

From lou.burnard at computing-services.oxford.ac.uk  Sat Oct  8 08:35:32 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 08 Oct 2005 13:35:32 +0100
Subject: The Naming of Classes [was Re: [tei-council] Council class meeting
	notes]
In-Reply-To: <17223.45563.392188.708157@emt.wwp.brown.edu>
References: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>	<43440D4D.9040207@oucs.ox.ac.uk>	<17220.32172.734583.802478@emt.wwp.brown.edu>	<4347A706.9010606@computing-services.oxford.ac.uk>
	<17223.45563.392188.708157@emt.wwp.brown.edu>
Message-ID: <4347BD14.7050308@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>>I think introducing a hyphen into the world of TEI naming
>>meta-characters really would be inconsistent., and "Sibling" is
>>both too long and (I think) misleading -- see my reply to Christian
>>yesterday.
>>    
>>
>
>I was figuring we'd introduce these hyphens in a consistent way. But
>your reply to Christian yesterday convinced me that "Sibling" is even
>less desirable than "Like" (or "-like").
>
>
>  
>

I don't doubt that it would be consistent, but it seems mad to have 
camelCasing AND dots AND hyphens to do token separation in different 
circumstances

>>Please make a suggestion for untwisting it.
>>    
>>
>
><item>If the class members are all children of the element after
>which the class is named, then the first suffix should be
><code>Part</code>; if the class members are all siblings of the
>element after which the class is named, then the first suffix should
>be <code>Like</code>.</item>
>
>  
>

This is OK, but misses the point that "like" things are not only 
siblings -- they are also semantically related. And there are siblings 
which are not like.

>_______________________________________________
>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 Oct  8 22:23:31 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 8 Oct 2005 22:23:31 -0400
Subject: [tei-council] gaiji in PCDATA, or <g> in text
Message-ID: <17224.32547.11372.38752@emt.wwp.brown.edu>

While we were in Oxford, Lou, Sebastian, and I finally hammered out a
plan for allowing <g> in places where text is allowed. Sebastian gets
the credit for the scheme, I think. 

* A new class, 'tei.gLike' which has only 1 member, <g>
* A new macro, 'macro.xtext' which is declared 
  macro.xtext = (text | tei.gLike)*
* Wherever <g> is desired, use reference macro.xtext instead of
  rng:text.

Sebastian recently implimented the system, and today I went through
various occurences and set them to either macro.xtext or rng:text.
Here is the list of the current settings, with some comments.

<altIdent>         allow <g>
<formulaNotations> doesn't matter, not used; should be nuked
<formula>          text only -- modern formulas don't contain gaijis
<charName>         text only -- must follow Unicode convention, which does not include gaijis
<glyphName>        text only -- must follow Unicode convention, which does not include gaijis
<localName>        allow <g>
<value>            allow <g>
<string>           allow <g>
<day>              allow <g>
<geog>             allow <g>
<hour>             allow <g>
<minute>           allow <g>
<month>            allow <g>
<second>           allow <g>
<week>             allow <g>
<year>             allow <g>
<schemapattern>    text only
<att>              CHANGED to tei.data.ident to match prose definition
<code>             text only
<defaultVal>       text only (should be tei.data.names?)
<eg>               text only
<egXML>            text only
<ident>            text only
<memberOf>         allow <g>
<stringVal>        text only, should be nuked
<val>              text only
<altName>          allow <g>
<collection>       allow <g> (should be macro.phraseSeq, no?)
<depth>            allow <g>
<height>           allow <g>
<institution>      allow <g> (should be macro.phraseSeq, no?)
<locus>            allow <g> (maybe should be text only?)
<origDate>         text only
<origPlace>        allow <g> (should be macro.phraseSeq, no?)
<repository>       allow <g> (should be macro.phraseSeq, no?)
<width>            allow <g>
<unicodeName>      text only -- must be a Unicode name, and they don't have gaijis

Speak up if you think any of these have been incorrectly instituted.
It would also be useful if people would express opinions on the
"should be" coments.

From sebastian.rahtz at oucs.ox.ac.uk  Sun Oct  9 07:38:48 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 09 Oct 2005 12:38:48 +0100
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <17224.32547.11372.38752@emt.wwp.brown.edu>
References: <17224.32547.11372.38752@emt.wwp.brown.edu>
Message-ID: <43490148.30805@oucs.ox.ac.uk>

Syd Bauman wrote:

>* A new class, 'tei.gLike' which has only 1 member, <g>
>* A new macro, 'macro.xtext' which is declared 
>  macro.xtext = (text | tei.gLike)*
>* Wherever <g> is desired, use reference macro.xtext instead of
>  rng:text.
>  
>
with the caveat that the macro does not work in all situations
(because of DTD weird things), so sometimes "text | tei.gLike" is needed
by hand

><institution>      allow <g> (should be macro.phraseSeq, no?)
><locus>            allow <g> (maybe should be text only?)
><origPlace>        allow <g> (should be macro.phraseSeq, no?)
><repository>       allow <g> (should be macro.phraseSeq, no?)
>  
>
hard to disagree with your conclusion about these

><origDate>         text only
>  
>
sure about that?

I am very glad you cleared up after my initial "bull in a china job"
canter through the "text", Syd.  This cheers me 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 Syd_Bauman at Brown.edu  Sun Oct  9 08:51:34 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 9 Oct 2005 08:51:34 -0400
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <43490148.30805@oucs.ox.ac.uk>
References: <17224.32547.11372.38752@emt.wwp.brown.edu>
	<43490148.30805@oucs.ox.ac.uk>
Message-ID: <17225.4694.495053.134292@emt.wwp.brown.edu>

Sebastian says:

> with the caveat that the macro does not work in all situations
> (because of DTD weird things), so sometimes "text | tei.gLike" is
> needed by hand

Oh dear. I didn't look for "text | tei.gLike", only for
"macro.xtext". Will try to check that later today. (At some point you
should explain this DTD-generation problem to me.)

> ><origDate>         text only
> sure about that?

Pretty sure, although I'm happy to have the MS group over-rule me if
needed. <origDate>, if I understand correctly, is used as a place for
a modern philologist, librarian, or other manuscript describer to put
in the date he thinks is the date of the manuscript's origin, and
would never be used to transcribe a date written in a manuscript. I
could be wrong, though, and if someone wants to argue that such a
manuscript describer should have the capability to record the date in
Elvish (a language not covered by Unicode) ...

> I am very glad you cleared up after my initial "bull in a china
> job" canter through the "text", Syd. This cheers me up.

My pleasure, but don't break out the champagne until I'm done with
"text | tei.gLike". (Although first glance says there are very few
that should be reverted to "text" only.)

From Syd_Bauman at Brown.edu  Sun Oct  9 09:57:22 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 9 Oct 2005 09:57:22 -0400
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <43490148.30805@oucs.ox.ac.uk>
References: <17224.32547.11372.38752@emt.wwp.brown.edu>
	<43490148.30805@oucs.ox.ac.uk>
Message-ID: <17225.8642.532044.78348@emt.wwp.brown.edu>

> with the caveat that the macro does not work in all situations
> (because of DTD weird things), so sometimes "text | tei.gLike" is
> needed by hand

OK, I've taken a quick glance at all of these (list appended), and
none of them are obvious candidates for excluding <g>, so I've left
them all as permitting <g>. 

A few questions arise:

<gramGrp>: why does this element have text at all? The content should
           probably be something like
           tei.Incl*, tei.gramInfo, ( tei.gramInfo | tei.Incl )*
           no?

<re>: If character data is allowed, then <g> should be allowed. But
      why does this element permit PCDATA at all? I thought it was
      roughly analagous to <entry>, which does not.

<pVar>: the "Note:" information (<remarks>) does not match the
        content model; which is correct?

From Laurent.Romary at loria.fr  Sun Oct  9 11:22:27 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Sun, 9 Oct 2005 17:22:27 +0200
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <17225.8642.532044.78348@emt.wwp.brown.edu>
References: <17224.32547.11372.38752@emt.wwp.brown.edu>
	<43490148.30805@oucs.ox.ac.uk>
	<17225.8642.532044.78348@emt.wwp.brown.edu>
Message-ID: <C85FA63F-2FFE-42CF-AE0F-7CB6852F28CD@loria.fr>

Le 9 oct. 05 ? 15:57, Syd Bauman a ?crit :

>> with the caveat that the macro does not work in all situations
>> (because of DTD weird things), so sometimes "text | tei.gLike" is
>> needed by hand
>>
>
> OK, I've taken a quick glance at all of these (list appended), and
> none of them are obvious candidates for excluding <g>, so I've left
> them all as permitting <g>.
>
> A few questions arise:
>
> <gramGrp>: why does this element have text at all? The content should
>            probably be something like
>            tei.Incl*, tei.gramInfo, ( tei.gramInfo | tei.Incl )*
>            no?

This is because you may use this element to tag semi-structured  
grammatical information where you may have text ('labels' or other  
comments) interspersed with actual elements like <pos>, <gen>, <num>  
etc.

>
> <re>: If character data is allowed, then <g> should be allowed. But
>       why does this element permit PCDATA at all? I thought it was
>       roughly analagous to <entry>, which does not.

M?me cause, m?me effet. <re> is used to describe entry-like objects  
within a real entry (e.g. compounds). Such information is sometimes  
less structured then a real entry and may thus require that data be  
there in complement to the usual stuff (<gramGrp>, <form>, <sense>,  
etc.). Note also that we can have <dicScrap> (yark) and entryFree) as  
alternates to <entry> whereas there is only one <re>.

>
> <pVar>: the "Note:" information (<remarks>) does not match the
>         content model; which is correct?

It is even more weird that oVar is more consistent. My advice: change  
<remarks> to mirror oVar.
Best,
Laurent

From Syd_Bauman at Brown.edu  Sun Oct  9 16:17:59 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 9 Oct 2005 16:17:59 -0400
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <C85FA63F-2FFE-42CF-AE0F-7CB6852F28CD@loria.fr>
References: <17224.32547.11372.38752@emt.wwp.brown.edu>
	<43490148.30805@oucs.ox.ac.uk>
	<17225.8642.532044.78348@emt.wwp.brown.edu>
	<C85FA63F-2FFE-42CF-AE0F-7CB6852F28CD@loria.fr>
Message-ID: <17225.31479.770205.474099@emt.wwp.brown.edu>

Laurent --
  Thanks for the explanations.

> It is even more weird that oVar is more consistent. My advice:
> change <remarks> to mirror oVar.

Done; except, of course it says "<pRef>", not "<oRef>" :-)

Thanks!

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Oct  9 18:53:08 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 10 Oct 2005 07:53:08 +0900
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <4347BD14.7050308@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Sat, 08 Oct 2005 13:35:32 +0100")
References: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<43440D4D.9040207@oucs.ox.ac.uk>
	<17220.32172.734583.802478@emt.wwp.brown.edu>
	<4347A706.9010606@computing-services.oxford.ac.uk>
	<17223.45563.392188.708157@emt.wwp.brown.edu>
	<4347BD14.7050308@computing-services.oxford.ac.uk>
Message-ID: <ygfmzli2tgr.fsf@chwpb.local>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

>><item>If the class members are all children of the element after
>>which the class is named, then the first suffix should be
>><code>Part</code>; if the class members are all siblings of the
>>element after which the class is named, then the first suffix should
>>be <code>Like</code>.</item>
>
> This is OK, but misses the point that "like" things are not only
> siblings -- they are also semantically related. And there are siblings
> which are not like.

Which is exactly what caused my confusion. How about 

... if the class members all occur on the same hierarchical level as
the siblings of the element after which the class is named, then the
first suffix should be <code>Like</code>.

for the second half of the sentence?

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  Sun Oct  9 19:00:47 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 10 Oct 2005 08:00:47 +0900
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <17224.32547.11372.38752@emt.wwp.brown.edu> (Syd Bauman's message
	of "Sat, 8 Oct 2005 22:23:31 -0400")
References: <17224.32547.11372.38752@emt.wwp.brown.edu>
Message-ID: <ygfirw62t40.fsf@chwpb.local>

Syd Bauman <Syd_Bauman at Brown.edu> writes:

> <localName>        allow <g>

As I said elsewhere, this is "text only" in my book.  Since it is a
modern, locally defined name made up by the project, there is no
reason to insist on using <g>, which would only complicate matters in
this "meta" situation.

> <eg>               text only
> <egXML>            text only

Why would these be text only?  I would "allow <g>" here

> <depth>            allow <g>
> <height>           allow <g>
> <width>            allow <g>

Hard to see why you would need a <g> here, but surely not impossible:-)

All the best,

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  Mon Oct 10 07:30:58 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 10 Oct 2005 07:30:58 -0400
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <ygfirw62t40.fsf@chwpb.local>
References: <17224.32547.11372.38752@emt.wwp.brown.edu>
	<ygfirw62t40.fsf@chwpb.local>
Message-ID: <17226.20722.398892.214901@emt.wwp.brown.edu>

Christian Wittern writes:

> > <localName>        allow <g>
> 
> As I said elsewhere, this is "text only" in my book. Since it is a
> modern, locally defined name made up by the project, there is no
> reason to insist on using <g>, which would only complicate matters
> in this "meta" situation.

OK. I've just reverted this from 'macro.xtext' to 'rng:text'.

> > <eg>               text only
> > <egXML>            text only
> 
> Why would these be text only?  I would "allow <g>" here

Because these are examples of XML encoding or other computer
documents. At lest for <egXML>, where the contents are defined to be
well-formed XML, it definitionally cannot have a character outside of
Unicode in it, so cannot need to have such a character encoded with
<g>. (You may want to give an example of <g>, but this is handled,
like any other example element, by using an element from a different
namespace, e.g. "http://www.tei-c.org/ns/Examples")

I suppose if someone wants to use <eg> to show an example of RTF or
some even more bizarre language, there might be some character in use
that is not actually a Unicode character? 

From Syd_Bauman at Brown.edu  Mon Oct 10 07:36:41 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 10 Oct 2005 07:36:41 -0400
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <4347BD14.7050308@computing-services.oxford.ac.uk>
References: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<43440D4D.9040207@oucs.ox.ac.uk>
	<17220.32172.734583.802478@emt.wwp.brown.edu>
	<4347A706.9010606@computing-services.oxford.ac.uk>
	<17223.45563.392188.708157@emt.wwp.brown.edu>
	<4347BD14.7050308@computing-services.oxford.ac.uk>
Message-ID: <17226.21065.536247.918252@emt.wwp.brown.edu>

> I don't doubt that it would be consistent, but it seems mad to have
> camelCasing AND dots AND hyphens to do token separation in
> different circumstances

I see the point, but I'm thinking of "p-like" as a single hyphenated
word.

From lou.burnard at computing-services.oxford.ac.uk  Mon Oct 10 08:55:57 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 10 Oct 2005 13:55:57 +0100
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <17226.21065.536247.918252@emt.wwp.brown.edu>
References: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>	<43440D4D.9040207@oucs.ox.ac.uk>	<17220.32172.734583.802478@emt.wwp.brown.edu>	<4347A706.9010606@computing-services.oxford.ac.uk>	<17223.45563.392188.708157@emt.wwp.brown.edu>	<4347BD14.7050308@computing-services.oxford.ac.uk>
	<17226.21065.536247.918252@emt.wwp.brown.edu>
Message-ID: <434A64DD.1010608@oucs.ox.ac.uk>

There seems to have been little dissent from the proposals of edw87a, 
which Council was asked to comment on a week or so ago.

I've therefore now implemented the renamings for all existing classes as 
defined in edw87a (which maybe should replace the existing edw87 to 
avoid confusion). I have also tested that we can still generate valid 
schemas, and run the test suite. This is quite a big job and there may 
well be a bit of mopping up to do in the next day or two. But I think we 
now at least have a basically consistent and defensible naming system in 
place, on top of which we can start implementing (and extending) the 
ideas discussed at the classes meeting (see tcm20 and edw92)

Sebastian and I hope to use this is a basis for a new candidate release 
of P5 to be available in time for the members meeting. We'll announce 
that at the start of next week, all being well.

One major outstanding task is completion of the datatype changes, on 
which Syd has been beavering away over the last few days, so I am 
optimistic that this can be completed on the same timescale.

At the moment, the new version is in CVS, but to make everything work 
you also need to update your ODD stylesheet package to the latest 
version (using Debian it's easy!).

Excelsior!

Lou

Syd Bauman wrote:
>>I don't doubt that it would be consistent, but it seems mad to have
>>camelCasing AND dots AND hyphens to do token separation in
>>different circumstances
> 
> 
> I see the point, but I'm thinking of "p-like" as a single hyphenated
> word.
> 
> _______________________________________________
> 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 Oct 10 08:55:51 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 10 Oct 2005 13:55:51 +0100
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <434A64DD.1010608@oucs.ox.ac.uk>
References: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>	<43440D4D.9040207@oucs.ox.ac.uk>	<17220.32172.734583.802478@emt.wwp.brown.edu>	<4347A706.9010606@computing-services.oxford.ac.uk>	<17223.45563.392188.708157@emt.wwp.brown.edu>	<4347BD14.7050308@computing-services.oxford.ac.uk>	<17226.21065.536247.918252@emt.wwp.brown.edu>
	<434A64DD.1010608@oucs.ox.ac.uk>
Message-ID: <434A64D7.2060705@oucs.ox.ac.uk>

Lou Burnard wrote:

>
> Sebastian and I hope to use this is a basis for a new candidate
> release of P5 to be available in time for the members meeting. We'll
> announce that at the start of next week, all being well.
>
To clarify, a "release" means new releases on Sourceforge, new Debian
packages, updated Roma, and new
public Knoppix release. All being well, those can all happen more or
less simultaneously.

-- 
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 Oct 10 18:33:28 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 11 Oct 2005 07:33:28 +0900
Subject: [tei-council] gaiji in PCDATA, or <g> in text
In-Reply-To: <17226.20722.398892.214901@emt.wwp.brown.edu> (Syd Bauman's
	message of "Mon, 10 Oct 2005 07:30:58 -0400")
References: <17224.32547.11372.38752@emt.wwp.brown.edu>
	<ygfirw62t40.fsf@chwpb.local>
	<17226.20722.398892.214901@emt.wwp.brown.edu>
Message-ID: <ygfoe5x0zpj.fsf@chwpb.local>

Syd Bauman <Syd_Bauman at Brown.edu> writes:

> Christian Wittern writes:
>> > <eg>               text only
>> > <egXML>            text only
>> 
>> Why would these be text only?  I would "allow <g>" here
>
> Because these are examples of XML encoding or other computer
> documents. At lest for <egXML>, where the contents are defined to be
> well-formed XML, it definitionally cannot have a character outside of
> Unicode in it, so cannot need to have such a character encoded with
> <g>. 

I am afraid you are confusing two levels of different encoding here.
<g> is a means to encode arbitrary characters in XML using XML
methods.  The characters are defined to be possibly outside of Unicode
by their semantics on the markup level -- the character encdoing of
course contains only legal Unicode characters in any case.

> (You may want to give an example of <g>, but this is handled,
> like any other example element, by using an element from a different
> namespace, e.g. "http://www.tei-c.org/ns/Examples")
>
I see.

> I suppose if someone wants to use <eg> to show an example of RTF or
> some even more bizarre language, there might be some character in use
> that is not actually a Unicode character? 
>

Most surely not, but that is a bit OT:-)

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 Oct 10 18:34:22 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 11 Oct 2005 07:34:22 +0900
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <434A64DD.1010608@oucs.ox.ac.uk> (Lou Burnard's message of "Mon,
	10 Oct 2005 13:55:57 +0100")
References: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<43440D4D.9040207@oucs.ox.ac.uk>
	<17220.32172.734583.802478@emt.wwp.brown.edu>
	<4347A706.9010606@computing-services.oxford.ac.uk>
	<17223.45563.392188.708157@emt.wwp.brown.edu>
	<4347BD14.7050308@computing-services.oxford.ac.uk>
	<17226.21065.536247.918252@emt.wwp.brown.edu>
	<434A64DD.1010608@oucs.ox.ac.uk>
Message-ID: <ygfk6gl0zo1.fsf@chwpb.local>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> Sebastian and I hope to use this is a basis for a new candidate
> release of P5 to be available in time for the members meeting. We'll
> announce that at the start of next week, all being well.

Hurray, so good luck and I hope everything goes well!

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  Mon Oct 10 18:36:49 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 10 Oct 2005 18:36:49 -0400
Subject: [tei-council] for Council to consider: new datatype
Message-ID: <17226.60673.459030.600149@emt.wwp.brown.edu>

After a huddle over the weekend among me, Sebastian, and Lou, we've
created yet another datatype. This one is specifically designed for
the height= and width= attributes of <graphic> and <binaryObject> The
declaration is 

data.htmlDimension =
  xsd:token {
    pattern =
      "[\-+]?\d+(\.\d+)?(cm|mm|in|pt|pc|px|em|ex|gd|rem|vw|vh|vm)"
  }

That pattern is specifically designed to allow values to map directly
to XSLFO or CSS3 values. It is a little more restrictive, in that it
requires that the numeric portion neither start nor end with a
decimal point (i.e., if there is a decimal point, there must be at
least one digit on either side). It is a little less restrictive than
XSLFO in that it permits some units that CSS3 uses but XSLFO does
not.

I think this is a fine and dandy datatype, but the more I think of
it, the more I think the name leaves a lot to be desired. Any
suggestions? Anyone object to it entirely or to its definition?

P.S. I plan to post a similar missive about <respStmt> in a day or
     two. I *really* want Council members to think about this stuff
     and respond.

From sebastian.rahtz at oucs.ox.ac.uk  Mon Oct 10 18:38:49 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 10 Oct 2005 23:38:49 +0100
Subject: [tei-council] for Council to consider: new datatype
In-Reply-To: <17226.60673.459030.600149@emt.wwp.brown.edu>
References: <17226.60673.459030.600149@emt.wwp.brown.edu>
Message-ID: <434AED79.902@oucs.ox.ac.uk>

data.webMeasure?

sebastian

From lou.burnard at computing-services.oxford.ac.uk  Mon Oct 10 19:12:10 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 11 Oct 2005 00:12:10 +0100
Subject: [tei-council] for Council to consider: new datatype
In-Reply-To: <17226.60673.459030.600149@emt.wwp.brown.edu>
References: <17226.60673.459030.600149@emt.wwp.brown.edu>
Message-ID: <434AF54A.5090209@computing-services.oxford.ac.uk>

Fine by me, but
(a) why restrict it to web measurements? there might well be other 
attributes for which we'd want to specify number+units  in a single value.
(b) some of these units look a bit exotic to me : isn't a "rem" a unit 
of exposure to radiation? couldnt find it in css3 anyway

how about data.measure?

"dimension" suggests the axis along which the measurement is made to me, 
not the actual measurement.

Syd Bauman wrote:

> After a huddle over the weekend among me, Sebastian, and Lou, we've
> created yet another datatype. This one is specifically designed for
> the height= and width= attributes of <graphic> and <binaryObject> The
> declaration is 
> 
> data.htmlDimension =
>   xsd:token {
>     pattern =
>       "[\-+]?\d+(\.\d+)?(cm|mm|in|pt|pc|px|em|ex|gd|rem|vw|vh|vm)"
>   }
> 
> That pattern is specifically designed to allow values to map directly
> to XSLFO or CSS3 values. It is a little more restrictive, in that it
> requires that the numeric portion neither start nor end with a
> decimal point (i.e., if there is a decimal point, there must be at
> least one digit on either side). It is a little less restrictive than
> XSLFO in that it permits some units that CSS3 uses but XSLFO does
> not.
> 
> I think this is a fine and dandy datatype, but the more I think of
> it, the more I think the name leaves a lot to be desired. Any
> suggestions? Anyone object to it entirely or to its definition?
> 
> 
> P.S. I plan to post a similar missive about <respStmt> in a day or
>      two. I *really* want Council members to think about this stuff
>      and respond.
> 
> 
> _______________________________________________
> 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 Oct 10 20:05:55 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 10 Oct 2005 20:05:55 -0400
Subject: [tei-council] for Council to consider: new datatype
In-Reply-To: <434AF54A.5090209@computing-services.oxford.ac.uk>
References: <17226.60673.459030.600149@emt.wwp.brown.edu>
	<434AF54A.5090209@computing-services.oxford.ac.uk>
Message-ID: <17227.483.795229.606225@emt.wwp.brown.edu>

SR> data.webMeasure?

I like that a lot better. Of course, XSLFO may well be used for
printed pages. But 'data.outputMeasurement' seems kinda clunky.

LB> (a) why restrict it to web measurements? there might well be
LB>     other attributes for which we'd want to specify number+units 
LB>     in a single value.

Darn good question. The difficulty is that if we use it for other
things, we need to include all sorts of units, some that won't make
any sense for a given attribute. So either we make up a separate
datatype for each set of units a set of attributes wants, or we live
with a system that permits ridiculous values like
  <graphic height="1.1m" width="76kg"/>
  <person height="256px" weight="3em"/>
  <when interval="14.7mg"/>
Personally, I would much prefer a few extra datatypes. (There can't
be that many needed, can there?

> (b) some of these units look a bit exotic to me : isn't a "rem" a
>     unit of exposure to radiation? couldnt find it in css3 anyway

I think they're outright weird. Got 'em straight from 
http://www.w3.org/TR/2005/WD-css3-values-20050726/#numbers0, where
"rem" is listed as "the font size of the root element".

> "dimension" suggests the axis along which the measurement is made
> to me, not the actual measurement.

I think you're right, "measurement" is better. If we go with one
datatype fits all, then "data.measurement" makes sense. If we go with
different datatypes for different kinds of measurement, then things
like "data.lengthMeasurement" and "data.massMeasurement" or
"data.measurement.typesetting" and "data.measurement.length" and
"data.measurement.mass" might make sense. (We don't really have any
mass ones, I don't think; just using that as an example.)

From Syd_Bauman at Brown.edu  Mon Oct 10 21:46:42 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 10 Oct 2005 21:46:42 -0400
Subject: [tei-council] Re: The Naming of Classes
In-Reply-To: <434A64DD.1010608@oucs.ox.ac.uk>
References: <ygf64scbsou.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<43440D4D.9040207@oucs.ox.ac.uk>
	<17220.32172.734583.802478@emt.wwp.brown.edu>
	<4347A706.9010606@computing-services.oxford.ac.uk>
	<17223.45563.392188.708157@emt.wwp.brown.edu>
	<4347BD14.7050308@computing-services.oxford.ac.uk>
	<17226.21065.536247.918252@emt.wwp.brown.edu>
	<434A64DD.1010608@oucs.ox.ac.uk>
Message-ID: <17227.6530.638047.398404@emt.wwp.brown.edu>

> One major outstanding task is completion of the datatype changes,
> on which Syd has been beavering away over the last few days, so I
> am optimistic that this can be completed on the same timescale.

~45 down, ~30 to go.

From James.Cummings at computing-services.oxford.ac.uk  Tue Oct 11 07:37:12 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 11 Oct 2005 12:37:12 +0100
Subject: [tei-council] for Council to consider: new datatype
In-Reply-To: <17227.483.795229.606225@emt.wwp.brown.edu>
References: <17226.60673.459030.600149@emt.wwp.brown.edu>	<434AF54A.5090209@computing-services.oxford.ac.uk>
	<17227.483.795229.606225@emt.wwp.brown.edu>
Message-ID: <434BA3E8.1010903@computing-services.oxford.ac.uk>

Syd Bauman wrote:
>   <graphic height="1.1m" width="76kg"/>
>   <person height="256px" weight="3em"/>

Doesn't CSS3 (and earlier) allow for percentage widths and heights as well?
Your datatype didn't seem to cope with this.  100%, 30%, etc.

-James

From Julia_Flanders at Brown.edu  Tue Oct 11 17:48:42 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Tue, 11 Oct 2005 17:48:42 -0400
Subject: [tei-council] submitted I18N proposal
Message-ID: <a06200741bf71e3467645@[128.148.157.102]>

I'm happy to report that the I18N proposal has been submitted to 
Harold Short of the ALLC. I'll keep you all informed on any 
information I receive. Thanks to all who helped with this, and in 
particular to Sebastian and Veronika who did the bulk of the hard 
work.

Best wishes, Julia

From Syd_Bauman at Brown.edu  Tue Oct 11 22:34:40 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 11 Oct 2005 22:34:40 -0400
Subject: [tei-council] quick note on some attr updates
Message-ID: <17228.30272.674133.223894@emt.wwp.brown.edu>

While fixing rng:text attributes I have also
* deleted key= of att.personal
* deleted key= of att.datePart
* updated value= of att.datePart to refer to data.temporal; still
  also allows data.duration
* created special content models for interval= of <timeline> and
  <whem> 

G'night.

From Julia_Flanders at Brown.edu  Wed Oct 12 10:45:37 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Wed, 12 Oct 2005 10:45:37 -0400
Subject: [tei-council] for Council to consider: new datatype
In-Reply-To: <17227.483.795229.606225@emt.wwp.brown.edu>
References: <17226.60673.459030.600149@emt.wwp.brown.edu>
	<434AF54A.5090209@computing-services.oxford.ac.uk>
	<17227.483.795229.606225@emt.wwp.brown.edu>
Message-ID: <a0620074dbf72d0e527d3@[128.148.157.102]>

I think "output" or "display" is the right sort of term. And having a 
set of these (potentially to include other things like typesetting or 
gemstones) as subclasses of the general "measurement" category seems 
like an interesting idea.

--Julia

At 8:05 PM -0400 10/10/05, Syd Bauman wrote:
>SR> data.webMeasure?
>
>I like that a lot better. Of course, XSLFO may well be used for
>printed pages. But 'data.outputMeasurement' seems kinda clunky.
>
>
>LB> (a) why restrict it to web measurements? there might well be
>LB>     other attributes for which we'd want to specify number+units
>LB>     in a single value.
>
>Darn good question. The difficulty is that if we use it for other
>things, we need to include all sorts of units, some that won't make
>any sense for a given attribute. So either we make up a separate
>datatype for each set of units a set of attributes wants, or we live
>with a system that permits ridiculous values like
>   <graphic height="1.1m" width="76kg"/>
>   <person height="256px" weight="3em"/>
>   <when interval="14.7mg"/>
>Personally, I would much prefer a few extra datatypes. (There can't
>be that many needed, can there?
>
>
>>  (b) some of these units look a bit exotic to me : isn't a "rem" a
>>      unit of exposure to radiation? couldnt find it in css3 anyway
>
>I think they're outright weird. Got 'em straight from
>http://www.w3.org/TR/2005/WD-css3-values-20050726/#numbers0, where
>"rem" is listed as "the font size of the root element".
>
>
>>  "dimension" suggests the axis along which the measurement is made
>>  to me, not the actual measurement.
>
>I think you're right, "measurement" is better. If we go with one
>datatype fits all, then "data.measurement" makes sense. If we go with
>different datatypes for different kinds of measurement, then things
>like "data.lengthMeasurement" and "data.massMeasurement" or
>"data.measurement.typesetting" and "data.measurement.length" and
>"data.measurement.mass" might make sense. (We don't really have any
>mass ones, I don't think; just using that as an example.)
>
>_______________________________________________
>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  Sun Oct 16 07:33:16 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 16 Oct 2005 12:33:16 +0100
Subject: [tei-council] foreName
Message-ID: <43523A7C.50402@oucs.ox.ac.uk>

can anyone think of a reason why we have <surname> and <foreName>?
that is, why is it not <forename>? If no-one can suggest a strong
argument, I propose to rename <foreName> to <forename>

-- 
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 Oct 16 07:47:20 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 16 Oct 2005 12:47:20 +0100
Subject: [tei-council] dateable elements
Message-ID: <43523DC8.3020509@oucs.ox.ac.uk>

The classes "att.datePart" (in the namesdates module) and dateable
and the (misname) "model.pPart.datable" (in the MS module) have two
much in common.

The pPart.datable class offers

   <attDef ident="notBefore" usage="opt">
    <attDef ident="notAfter" usage="opt">
    <attDef ident="certainty" usage="opt">
    <attDef ident="dateAttrib" usage="opt">
    <attDef ident="evidence" usage="opt">

whole the datePart class offers

   <attDef ident="value" usage="opt">
    <attDef ident="type" usage="opt">
    <attDef ident="full" usage="opt">

It looks to me as if we need a class in the core which has  all the
attributes
of the 2 classes.

Does anyone disagree?

-- 
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 Oct 16 11:45:34 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 16 Oct 2005 11:45:34 -0400
Subject: [tei-council] foreName
In-Reply-To: <43523A7C.50402@oucs.ox.ac.uk>
References: <43523A7C.50402@oucs.ox.ac.uk>
Message-ID: <17234.30110.781725.912679@emt.wwp.brown.edu>

> can anyone think of a reason why we have <surname> and <foreName>?
> that is, why is it not <forename>? If no-one can suggest a strong
> argument, I propose to rename <foreName> to <forename>

I'm embarrassed to admit that for a while I thought there was no word
"forename" only because TEI used "foreName" not "forename". I would
guess it's a mistake, but would like to hear what the reasoning was
(if any) at the time. Anyone know who was on the Subcommittee on
Names, Dates,and Measures?

From lou.burnard at computing-services.oxford.ac.uk  Sun Oct 16 12:19:27 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 16 Oct 2005 17:19:27 +0100
Subject: [tei-council] foreName
In-Reply-To: <17234.30110.781725.912679@emt.wwp.brown.edu>
References: <43523A7C.50402@oucs.ox.ac.uk>
	<17234.30110.781725.912679@emt.wwp.brown.edu>
Message-ID: <43527D8F.4070308@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>>can anyone think of a reason why we have <surname> and <foreName>?
>>that is, why is it not <forename>? If no-one can suggest a strong
>>argument, I propose to rename <foreName> to <forename>
> 
> 
> I'm embarrassed to admit that for a while I thought there was no word
> "forename" only because TEI used "foreName" not "forename". I would
> guess it's a mistake, but would like to hear what the reasoning was
> (if any) at the time. 

It is a mistake. A corrigible error.

Anyone know who was on the Subcommittee on
> Names, Dates,and Measures?
> 
> 

I know, but I aint telling.

From Syd_Bauman at Brown.edu  Sun Oct 16 13:16:22 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 16 Oct 2005 13:16:22 -0400
Subject: [tei-council] foreName
In-Reply-To: <43527D8F.4070308@computing-services.oxford.ac.uk>
References: <43523A7C.50402@oucs.ox.ac.uk>
	<17234.30110.781725.912679@emt.wwp.brown.edu>
	<43527D8F.4070308@computing-services.oxford.ac.uk>
Message-ID: <17234.35558.2985.498836@emt.wwp.brown.edu>

SR> I propose to rename <foreName> to <forename>

LB> It is a mistake. A corrigible error.

That means we should change it in P4 then, too, eh?

From sebastian.rahtz at oucs.ox.ac.uk  Sun Oct 16 13:20:48 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 16 Oct 2005 18:20:48 +0100
Subject: [tei-council] foreName
In-Reply-To: <17234.35558.2985.498836@emt.wwp.brown.edu>
References: <43523A7C.50402@oucs.ox.ac.uk>	<17234.30110.781725.912679@emt.wwp.brown.edu>	<43527D8F.4070308@computing-services.oxford.ac.uk>
	<17234.35558.2985.498836@emt.wwp.brown.edu>
Message-ID: <43528BF0.9040303@oucs.ox.ac.uk>

Syd Bauman wrote:

>SR> I propose to rename <foreName> to <forename>
>
>LB> It is a mistake. A corrigible error.
>
>That means we should change it in P4 then, too, eh?
>
>  
>

scary.....

-- 
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 Oct 16 14:39:48 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 16 Oct 2005 14:39:48 -0400
Subject: [tei-council] for Council to consider: new datatype
In-Reply-To: <434BA3E8.1010903@computing-services.oxford.ac.uk>
References: <17226.60673.459030.600149@emt.wwp.brown.edu>
	<434AF54A.5090209@computing-services.oxford.ac.uk>
	<17227.483.795229.606225@emt.wwp.brown.edu>
	<434BA3E8.1010903@computing-services.oxford.ac.uk>
Message-ID: <17234.40564.803622.707387@emt.wwp.brown.edu>

James Cummings writes:
> Doesn't CSS3 (and earlier) allow for percentage widths and heights
> as well? Your datatype didn't seem to cope with this. 100%, 30%,
> etc.

Absolutely, they do. Does anyone think we should not add it, i.e. use 

data.outputMeasurement =
  xsd:token {
    pattern =
      "[\-+]?\d+(\.\d+)?(%|cm|mm|in|pt|pc|px|em|ex|gd|rem|vw|vh|vm)"
  }

?

From Syd_Bauman at Brown.edu  Sun Oct 16 17:44:01 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 16 Oct 2005 17:44:01 -0400
Subject: [tei-council] report on rng:text attribute sweep
Message-ID: <17234.51617.851672.284870@emt.wwp.brown.edu>

Here's the list of changes made in my recent sweep to root out the
remaining rng:text attributes. 
* Names of classes are delimited by "%" and ";" even though they are
  no longer expressed as parameter entities, just because I don't have
  a better way to make them stand out.
* Names of elements, attributes, and classes are as they were at the
  time; some of them have changed since.

--------- altered ---------
indexName=   of <index>               -> data.ident
width=       of <binaryObject>        -> data.htmlDimension /* also of <graphic> */
height=      of <binaryObject>        -> data.htmlDimension /* also of <graphic> */
scale=       of <binaryObject>        -> data.numeric
type=        of %att.entryLike;       -> data.enumerated
level=       of <sense>               -> data.numeric [1]
type=        of <form>                -> data.enumerated
extent=      of <orth>                -> data.enumerated
extent=      of <pron>                -> data.enumerated
type=        of <gram>                -> data.enumerated
type=        of <itype>               -> data.enumerated; also changed GI to <iType>
type=        of <colloc>              -> data.name /* EDW90 says enumerated [2] */
type=        of <usg>                 -> data.enumerated
type=        of <lbl>                 -> data.name /* EDW90 says enumerated [2] */
type=        of <re>                  -> data.name /* EDW90 says enumerated [2] */
type=        of <oRef>                -> data.enumerated
type=        of <oVar>                -> data.enumerated
placeAttrib= of <origPlace>           -> data.enumerated
evidence=    of <origPlace>           -> data.enumerated
unit=        of %att.measured;        -> data.enumerated
scope=       of %att.measured;        -> data.enumerated
certainty=   of %model.pPart.datable; -> data.enumerated
dateAttrib=  of %model.pPart.datable; -> data.enumerated
evidence=    of %model.pPart.datable; -> data.enumerated
notAfter=    of %model.pPart.datable; -> data.temporal
notBefore=   of %model.pPart.datable; -> data.temporal
interval=    of <when>                -> specialized; also interval= of <timeline> [3]
type=        of %att.pointing;        -> data.name  /* EDW90 says enumerated [2] */
lemma=       of <w>                   -> data.name  /* must become element, eh? */
baseForm=    of <m>                   -> data.name  /* must become element, eh? */
type=        of %att.textCritical;    -> data.enumerated
cause=       of %att.textCritical;    -> data.enumerated
key=         of %att.personal;        -> DELETED
key=         of %att.datePart;        -> DELETED [4]
type=        of %att.datePart;        -> data.name
mode=        of %att.identified;      -> data.enumerated
mode=        of <valDesc>             -> data.enumerated
mode=        of <valList>             -> data.enumerated
key=         of <attRef>              -> data.ident
type=        of <schemaSpec>          -> data.name /* EDW90 says enumerated [2] */
ns=          of <schemaSpec>          -> data.namespace /* also ns= of <attDef> & <elementSpec> */

--------- stet ---------
n=           of %att.global; /* data.names problematic */
rend=        of %att.global;
key=         of %att.naming;
pat=         of <fragmentPattern> /* now replacementPattern= of <cRefPattern> */
delim=       of <state>
value=       of <metSym>
mimetype=    of <equiv>
sortKey=     of <term>
mimeType=    of <graphic>
mimeType=    of <binaryObject>
encoding=    of <binaryObject>
key=         of %att.entryLike; -- changed to sortKey=
expand=      of %att.lexicographic;  /* must become element, eh? */
norm=        of %att.lexicographic;  /* must become element, eh? */
split=       of %att.lexicographic;  /* must become element, eh? */
value=       of %att.lexicographic;  /* must become element, eh? */
orig=        of %att.lexicographic;  /* must become element, eh? */
reg=         of <orgName> /* needs to be handled by different mechanism */
reg=         of <orgTitle>/* needs to be handled by different mechanism */
reg=         of <orgType> /* needs to be handled by different mechanism */
reg=         of <orgDivn> /* needs to be handled by different mechanism */
label=       of <graph>   /* slated to become child somehow; data.names problematic */
label=       of <node>    /* slated to become child somehow; data.names problematic */
label2=      of <node>    /* slated to become child somehow; data.names problematic */
label=       of <arc>     /* slated to become child somehow; data.names problematic */
label2=      of <arc>     /* slated to become child somehow; data.names problematic */
label=       of <tree>    /* slated to become child somehow; data.names problematic */
label=       of <root>    /* slated to become child somehow; data.names problematic */
label=       of <iNode>   /* slated to become child somehow; data.names problematic */
label=       of <leaf>    /* slated to become child somehow; data.names problematic */
label=       of <eTree>   /* slated to become child somehow; data.names problematic */
label=       of <triangle>/* slated to become child somehow; data.names problematic */
label=       of <eLeaf>   /* slated to become child somehow; data.names problematic */

Notes
-----
[1] I still think this is a bad idea. The data.numeric type permits
    negative values, fractions, and numbers way outside the bounds of
    possibility here. xsd:unsignedByte is much closer to what we want
    (and is a straight W3C type, to boot): an integer between 0 and
    255 (inclusive). Could also use xsd:nonNegativeInteger {
    maxInclusive="whatever-number-we-agree-on" }

[2] The problem here is that we have not yet really hammered down the
    relationship between the use of the data.enumerated type and the
    existence of a <valList>. It has been suggested (I think by
    several different people, myself & Lou included) that the
    relationship should be iff -- i.e., if there is a <valList>, then
    datatype must be data.enumerated; if the datatype is
    data.enumerated, then there must be a <valList>. This system has
    its appeal, but also has problems (which I hope to address
    later). For these attributes, I have recommended in EDW90 that
    the type be data.enumerated, but no one has come up with a
    suggested value list. Thus I have made the datatype data.name
    instead, at least for now. In retrospect, probably should have
    been data.ident, but I'm hoping we come up with value lists
    instead, anyway.

[3] The attribute type is essentially that which I suggested on this
    list almost a month ago (2005-09-20), and which I think Lou
    doesn't like. But no one has suggested anything better. It is
    currently 
       xsd:float { minExclusive = "0" } | "unknown"
    for <when>, and
       xsd:float { minExclusive = "0" } | "regular" | "irregular"
    for <timeline>. This mimics P4 pretty well. I, for one, would be
    happy if we came up with a better method altogether.

[4] Also fixed value= which had been a choice of lots of xsd, and is
    now data.temporal

From sebastian.rahtz at oucs.ox.ac.uk  Tue Oct 18 05:03:36 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 18 Oct 2005 10:03:36 +0100
Subject: [tei-council] dateable elements
In-Reply-To: <4354B6EB.8030900@oucs.ox.ac.uk>
References: <43523DC8.3020509@oucs.ox.ac.uk> <4354B6EB.8030900@oucs.ox.ac.uk>
Message-ID: <4354BA68.8070601@oucs.ox.ac.uk>

James Cummings wrote (privately, but I am sure he wont mind me posting):

>Not as long as the attributes don't go missing. :-)  But really I think that the
>date/time stuff needs to be sat down and looked at again overall.  I don't mind
>us using the funny W3C implementation of iso8601, but think we should make sure
>we are now being consistent throughout all our date/time representations.
>  
>
It seems to me that the case for a genuine new work group to look
at times, dates, places, names, and people is now clear.

How can we acquire a work group leader, or should we just
ask for volunteers?

-- 
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  Tue Oct 18 05:06:57 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 18 Oct 2005 10:06:57 +0100
Subject: [tei-council] dateable elements
In-Reply-To: <4354BA68.8070601@oucs.ox.ac.uk>
References: <43523DC8.3020509@oucs.ox.ac.uk> <4354B6EB.8030900@oucs.ox.ac.uk>
	<4354BA68.8070601@oucs.ox.ac.uk>
Message-ID: <4354BB31.9050205@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> James Cummings wrote (privately, but I am sure he wont mind me posting):

Indeed, posting it privately was in fact an error.

> It seems to me that the case for a genuine new work group to look
> at times, dates, places, names, and people is now clear.
> 
> How can we acquire a work group leader, or should we just
> ask for volunteers?

I'm happy to volunteer to be part of such a group, but do not want to lead it.

-James

From lou.burnard at computing-services.oxford.ac.uk  Tue Oct 18 05:33:21 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 18 Oct 2005 10:33:21 +0100
Subject: [tei-council] Re: 'token' classes
In-Reply-To: <BF73B058-749A-48EF-8E23-942F054E2C85@loria.fr>
References: <200510170247.j9H2lc20018933@pyxis.services.brown.edu>	<4353C406.9040809@oucs.ox.ac.uk>	<17235.55628.147721.610665@emt.wwp.brown.edu>	<4353DA50.6060303@oucs.ox.ac.uk>	<ygf4q7f6acj.fsf@kanji.zinbun.kyoto-u.ac.jp>	<435427A8.9060603@oucs.ox.ac.uk>
	<17236.12940.860584.793970@emt.wwp.brown.edu>
	<4354B54C.1080404@oucs.ox.ac.uk>
	<BF73B058-749A-48EF-8E23-942F054E2C85@loria.fr>
Message-ID: <4354C161.7030005@computing-services.oxford.ac.uk>

Yes, precisely. I am hoping to draft a revision of the section of 
chapter ST concerned to address this point a little more firmly later on 
today.

  Laurent Romary wrote:

> I also agree with this option, but I would suggest to tackle it from  a 
> more semantic point of view (instead of pure syntactic constraint  of 
> having white spaces or not in the type attribute).
> 
> What we want (maybe...) is to consider that the type attribute  contains 
> a code or identifier (not necessarily in the sense of xml)  that is 
> related to a predefined classification of a given object. We  should 
> state that strongly somewhere so that it gives encoders the  instruction 
> to actually +think+ of the general picture in which a  given value for 
> type will be considered. Typically, the possible  types of division in a 
> corpus (<div>) the various grammatical  features he wants to use in a 
> dictionary (<gram>) etc.
> 
> Laurent
> 
> Le 18 oct. 05 ? 10:41, James Cummings a ?crit :
> 
>> Syd Bauman wrote:
>>
>>>> I think we can proceed with two datatypes (Syd's data.name(s) and
>>>> data.token(s), for the sake of argument) and add a third one later
>>>> after review?
>>>>
>>>
>>>
>>> I think that's a good idea. If users all over the world scream for
>>> the capability to put spaces into their type= attributes, we can
>>> rethink this. If you & Christian are the only two, you know how to
>>> customize TEI yourselves ... :-)
>>>
>>> I think Lou will be vindicated, and most no one will really think
>>> it's horrible to say "collar,dog" as opposed to "dog collar".
>>>
>>
>> Just to say that I think having no spaces in type attributes (or  only 
>> having
>> spaces in similar attributes when they are real separate tokens (or  
>> whatever))
>> is a good idea.  I am happy to be convinced otherwise, but it seems  a 
>> perfectly
>> reasonable restriction which will stop people doing <div type="The  
>> chapter where
>> she gets killed"> or something silly.
>>
>> -J
>> -- 
>> 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 Oct 18 05:39:59 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 18 Oct 2005 10:39:59 +0100
Subject: [tei-council] [Fwd: Re: 'token' classes]
Message-ID: <4354C2EF.6040301@computing-services.oxford.ac.uk>

-------- Original Message --------
Subject: Re: 'token' classes
Date: Tue, 18 Oct 2005 10:38:09 +0100
From: Lou Burnard <lou.burnard at computing-services.oxford.ac.uk>
To: Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk>
References: <200510170247.j9H2lc20018933 at pyxis.services.brown.edu> 
<4353C406.9040809 at oucs.ox.ac.uk> 
<17235.55628.147721.610665 at emt.wwp.brown.edu> 
<4353DA50.6060303 at oucs.ox.ac.uk> 
<ygf4q7f6acj.fsf at kanji.zinbun.kyoto-u.ac.jp> 
<435427A8.9060603 at oucs.ox.ac.uk> 
<17236.12940.860584.793970 at emt.wwp.brown.edu> 
<4354B54C.1080404 at oucs.ox.ac.uk> 
<BF73B058-749A-48EF-8E23-942F054E2C85 at loria.fr> 
<4354BD4E.4030408 at oucs.ox.ac.uk>

Sebastian Rahtz wrote:

> Laurent Romary wrote:
> 
> 
>>What we want (maybe...) is to consider that the type attribute 
>>contains a code or identifier (not necessarily in the sense of xml) 
>>that is related to a predefined classification of a given object. We 
>>should state that strongly somewhere so that it gives encoders the 
>>instruction to actually +think+ of the general picture in which a 
>>given value for type will be considered. Typically, the possible 
>>types of division in a corpus (<div>) the various grammatical 
>>features he wants to use in a dictionary (<gram>) etc.
>>
> 
> This is fine, but why do you consider that a code or identier has no
> spaces? my identifer is "Sebastian Rahtz", not some
> artificial construction like "Sebastian_Rahtz".
> 
> 

Au contraire, your name may well be "Sebastian Rahtz" (and tagged as
such by <name>) but your identification is precisely likely to be an
artificial construction of some kind. Suince it's artificial we can
plausibbly make up rules about whether or not it has spaces.

That said, I think this discussion gas led to me finally understanding
why W3C use the word "token" the way they do == and seeing it as not
implausible.

From Laurent.Romary at loria.fr  Tue Oct 18 05:22:47 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Tue, 18 Oct 2005 11:22:47 +0200
Subject: [tei-council] dateable elements
In-Reply-To: <4354BB31.9050205@computing-services.oxford.ac.uk>
References: <43523DC8.3020509@oucs.ox.ac.uk> <4354B6EB.8030900@oucs.ox.ac.uk>
	<4354BA68.8070601@oucs.ox.ac.uk>
	<4354BB31.9050205@computing-services.oxford.ac.uk>
Message-ID: <4F7A2484-0252-48FC-9E45-1F326B711251@loria.fr>

I would also like to contribute, but would be an awful leader in the  
current context...
Laurent

Le 18 oct. 05 ? 11:06, James Cummings a ?crit :

> Sebastian Rahtz wrote:
>
>> James Cummings wrote (privately, but I am sure he wont mind me  
>> posting):
>>
>
> Indeed, posting it privately was in fact an error.
>
>
>> It seems to me that the case for a genuine new work group to look
>> at times, dates, places, names, and people is now clear.
>>
>> How can we acquire a work group leader, or should we just
>> ask for volunteers?
>>
>
> I'm happy to volunteer to be part of such a group, but do not want  
> to lead it.
>
> -James
> _______________________________________________
> 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  Tue Oct 18 05:30:34 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Tue, 18 Oct 2005 11:30:34 +0200
Subject: [tei-council] [Fwd: Re: 'token' classes]
In-Reply-To: <4354C2EF.6040301@computing-services.oxford.ac.uk>
References: <4354C2EF.6040301@computing-services.oxford.ac.uk>
Message-ID: <E82FF6A2-F71E-4075-85ED-BBFBD4BAD346@loria.fr>

As usual, Lou expresses my view better than I do myself...
I agree,
Laurent

Le 18 oct. 05 ? 11:39, Lou Burnard a ?crit :

>
>
> -------- Original Message --------
> Subject: Re: 'token' classes
> Date: Tue, 18 Oct 2005 10:38:09 +0100
> From: Lou Burnard <lou.burnard at computing-services.oxford.ac.uk>
> To: Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk>
> References: <200510170247.j9H2lc20018933 at pyxis.services.brown.edu>  
> <4353C406.9040809 at oucs.ox.ac.uk>  
> <17235.55628.147721.610665 at emt.wwp.brown.edu>  
> <4353DA50.6060303 at oucs.ox.ac.uk>  
> <ygf4q7f6acj.fsf at kanji.zinbun.kyoto-u.ac.jp>  
> <435427A8.9060603 at oucs.ox.ac.uk>  
> <17236.12940.860584.793970 at emt.wwp.brown.edu> <4354B54C. 
> 1080404 at oucs.ox.ac.uk>  
> <BF73B058-749A-48EF-8E23-942F054E2C85 at loria.fr> <4354BD4E. 
> 4030408 at oucs.ox.ac.uk>
>
> Sebastian Rahtz wrote:
>
>
>> Laurent Romary wrote:
>>
>>> What we want (maybe...) is to consider that the type attribute  
>>> contains a code or identifier (not necessarily in the sense of  
>>> xml) that is related to a predefined classification of a given  
>>> object. We should state that strongly somewhere so that it gives  
>>> encoders the instruction to actually +think+ of the general  
>>> picture in which a given value for type will be considered.  
>>> Typically, the possible types of division in a corpus (<div>) the  
>>> various grammatical features he wants to use in a dictionary  
>>> (<gram>) etc.
>>>
>>>
>> This is fine, but why do you consider that a code or identier has no
>> spaces? my identifer is "Sebastian Rahtz", not some
>> artificial construction like "Sebastian_Rahtz".
>>
>
> Au contraire, your name may well be "Sebastian Rahtz" (and tagged as
> such by <name>) but your identification is precisely likely to be an
> artificial construction of some kind. Suince it's artificial we can
> plausibbly make up rules about whether or not it has spaces.
>
> That said, I think this discussion gas led to me finally understanding
> why W3C use the word "token" the way they do == and seeing it as not
> implausible.
>
>
>
>
> _______________________________________________
> 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  Tue Oct 18 20:00:23 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 19 Oct 2005 09:00:23 +0900
Subject: [tei-council] dateable elements
In-Reply-To: <4F7A2484-0252-48FC-9E45-1F326B711251@loria.fr> (Laurent Romary's
	message of "Tue, 18 Oct 2005 11:22:47 +0200")
References: <43523DC8.3020509@oucs.ox.ac.uk> <4354B6EB.8030900@oucs.ox.ac.uk>
	<4354BA68.8070601@oucs.ox.ac.uk>
	<4354BB31.9050205@computing-services.oxford.ac.uk>
	<4F7A2484-0252-48FC-9E45-1F326B711251@loria.fr>
Message-ID: <ygfmzl68jfs.fsf@chwpb.local>

>>> It seems to me that the case for a genuine new work group to look
>>> at times, dates, places, names, and people is now clear.
>>>
>>> How can we acquire a work group leader, or should we just
>>> ask for volunteers?

We will probably need to think whether this would be an ad-hoc task
force to look at these issues on a rather tight schedule, or whether
we want a full-blown WG that might look at the prosopography stuff as
well and takes its time (most likely 2-3 years?) to come up with
recommendations.

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 Oct 19 03:06:06 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 19 Oct 2005 16:06:06 +0900
Subject: [tei-council] TEI Council report to MM 2005
Message-ID: <ygf7jcaq941.fsf@chwpb.local>

Dear Council members,

I have drafted a report to the members meeting.  It is now available
at
http://www.kanji.zinbun.kyoto-u.ac.jp/~wittern/tei/mm05councilreport.html
for your review.  Please look at this and report anything that you
feel is missing or weird here.  I would like to finalize this Friday
and hand it over to Lou for publication on the Website, so please give
me your comments now.

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  Wed Oct 19 05:04:10 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Oct 2005 10:04:10 +0100
Subject: [tei-council] dateable elements
In-Reply-To: <ygfmzl68jfs.fsf@chwpb.local>
References: <43523DC8.3020509@oucs.ox.ac.uk>
	<4354B6EB.8030900@oucs.ox.ac.uk>	<4354BA68.8070601@oucs.ox.ac.uk>	<4354BB31.9050205@computing-services.oxford.ac.uk>	<4F7A2484-0252-48FC-9E45-1F326B711251@loria.fr>
	<ygfmzl68jfs.fsf@chwpb.local>
Message-ID: <43560C0A.5080509@oucs.ox.ac.uk>

Christian Wittern wrote:

>We will probably need to think whether this would be an ad-hoc task
>force to look at these issues on a rather tight schedule
>
I am inclined to think we ought to do _something_ soon

> or whether
>we want a full-blown WG that might look at the prosopography stuff as
>well and takes its time (most likely 2-3 years?) to come up with
>recommendations.
>  
>
this is the internet age now, of course; so we can compress that
to one year.....

-- 
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 Oct 19 06:26:13 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Oct 2005 11:26:13 +0100
Subject: [tei-council] TEI Council report to MM 2005
In-Reply-To: <ygf7jcaq941.fsf@chwpb.local>
References: <ygf7jcaq941.fsf@chwpb.local>
Message-ID: <43561F45.2030706@oucs.ox.ac.uk>

looks convincing enough

I am not sure we want people reading or commenting on EDW90 any more,
though?
thats now of historical interest, I'd say

and "Nice" is not spelt "Nizza" :-}

-- 
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 Oct 19 18:30:05 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 20 Oct 2005 07:30:05 +0900
Subject: [tei-council] TEI Council report to MM 2005
In-Reply-To: <43561F45.2030706@oucs.ox.ac.uk> (Sebastian Rahtz's message of
	"Wed, 19 Oct 2005 11:26:13 +0100")
References: <ygf7jcaq941.fsf@chwpb.local> <43561F45.2030706@oucs.ox.ac.uk>
Message-ID: <ygfwtk9jg2a.fsf@chwpb.local>

Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> writes:

> looks convincing enough
>
> I am not sure we want people reading or commenting on EDW90 any more,
> though?
> thats now of historical interest, I'd say

Well, the report is supposed to reflect the history.  As to the
commenting, if somebody wants to look there and has something useful
to say, I would like to hear it.

>
> and "Nice" is not spelt "Nizza" :-}
>
Oops, thank you. 

I updated the document to reflect both comments.

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 Oct 19 18:33:49 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Thu, 20 Oct 2005 07:33:49 +0900
Subject: [tei-council] dateable elements
In-Reply-To: <43560C0A.5080509@oucs.ox.ac.uk> (Sebastian Rahtz's message of
	"Wed, 19 Oct 2005 10:04:10 +0100")
References: <43523DC8.3020509@oucs.ox.ac.uk> <4354B6EB.8030900@oucs.ox.ac.uk>
	<4354BA68.8070601@oucs.ox.ac.uk>
	<4354BB31.9050205@computing-services.oxford.ac.uk>
	<4F7A2484-0252-48FC-9E45-1F326B711251@loria.fr>
	<ygfmzl68jfs.fsf@chwpb.local> <43560C0A.5080509@oucs.ox.ac.uk>
Message-ID: <ygfsluxjfw2.fsf@chwpb.local>

Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> writes:

> Christian Wittern wrote:
>
>>We will probably need to think whether this would be an ad-hoc task
>>force to look at these issues on a rather tight schedule
>>
> I am inclined to think we ought to do _something_ soon
>
>> or whether
>>we want a full-blown WG that might look at the prosopography stuff as
>>well and takes its time (most likely 2-3 years?) to come up with
>>recommendations.
>>  
>>
> this is the internet age now, of course; so we can compress that
> to one year.....

Hear, hear.  I wonder if one year is soon enough though?

For quick action, I would like to ask for somebody to volunteer to act
as chair for this from our midst with the mandate to collect further
input from where she thinks suitable.

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  Wed Oct 19 18:33:36 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Oct 2005 23:33:36 +0100
Subject: [tei-council] TEI Council report to MM 2005
In-Reply-To: <ygfwtk9jg2a.fsf@chwpb.local>
References: <ygf7jcaq941.fsf@chwpb.local> <43561F45.2030706@oucs.ox.ac.uk>
	<ygfwtk9jg2a.fsf@chwpb.local>
Message-ID: <4356C9C0.4080704@oucs.ox.ac.uk>

Christian Wittern wrote:

>Well, the report is supposed to reflect the history.  As to the
>commenting, if somebody wants to look there and has something useful
>to say, I would like to hear it.
>  
>
yes, of course. I just wondered about so actively referring them
to the report on which the work was based, rather than the
work itself.

-- 
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 Oct 19 18:37:06 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Oct 2005 23:37:06 +0100
Subject: [tei-council] dateable elements
In-Reply-To: <ygfsluxjfw2.fsf@chwpb.local>
References: <43523DC8.3020509@oucs.ox.ac.uk>
	<4354B6EB.8030900@oucs.ox.ac.uk>	<4354BA68.8070601@oucs.ox.ac.uk>	<4354BB31.9050205@computing-services.oxford.ac.uk>	<4F7A2484-0252-48FC-9E45-1F326B711251@loria.fr>	<ygfmzl68jfs.fsf@chwpb.local>
	<43560C0A.5080509@oucs.ox.ac.uk> <ygfsluxjfw2.fsf@chwpb.local>
Message-ID: <4356CA92.6010809@oucs.ox.ac.uk>

Christian Wittern wrote:

>For quick action, I would like to ask for somebody to volunteer to act
>as chair for this from our midst with the mandate to collect further
>input from where she thinks suitable.
>  
>
If somebody would give me a job where I was paid
to work on the TEI, I'd be delighted to do this.
Anyone here got a vacancy? (no, really, I need
a change).

-- 
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 Oct 19 18:48:02 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 19 Oct 2005 23:48:02 +0100
Subject: [tei-council] P5 version 0.2.1
Message-ID: <4356CD22.4090403@oucs.ox.ac.uk>

I am unilaterally declaring 0.2.1 to be frozen.

I have to burn CDs for the members meeting tomorrow,
so this is as late as I can leave it. I propose to give all attendees
a TEI Knoppix with the current state of affairs.

I probably won't get the packages etc onto Sourceforge
until the weekend, so there is technically still time to find
disasters, for those who want to give me a hard time.

What, no testing phase, you say? No, no testing phase :-}
You'll have to trust that Syd and Lou have run "make test"
a few million times.

-- 
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 Oct 20 09:57:12 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 20 Oct 2005 09:57:12 -0400
Subject: [tei-council] sex confession
Message-ID: <17239.41528.319553.941346@emt.wwp.brown.edu>

Last night I got a few datatype fixes into P5 just before Sebastian
went off to make the released version and press CDs for the Members'
Meeting. Of those half a dozen or so fixes, I goofed one: sex= of
<personGrp>. I not only didn't I fix it, I made it worse.

It had a <valList> that didn't match the datatype. I have no idea
what kind of drugs I was on, but in my haste rather than do the right
thing (simply delete the <valList>), I changed the <valList> to more
closely match the datatype. So now, instead of matching sex= of
<person>, the sex= attribute of <personGrp> is idiotic. Ignore it.
It will be fixed in CVS by this time tomorrow.

However, it did raise an important issue about this particular
datatype.

Problem
-------
We agreed to use ISO 5218 codes for the value of sex= of <person> and
<personGrp>:
    * 0 = not known,
    * 1 = male,
    * 2 = female,
    * 9 = not specified.
However, <personGrp> (at least as P4 conceives it) requires an
additional value: "mixed" -- the group contains people of different
sexes.

Solutions
---------
Some possible solutions are:
1. Add a new numeric code, say "7", that means "mixed", to data.sex.
2. Use
     attribute sex { data.sex | "mixed" }
   for sex= of <personGrp>
3. Change the datatype so that the values are "not known", "male",
   "female", and "not specified", and then use #2.
4. Remove "mixed" from the possible values of sex= of <personGrp> and
   either
   a) say "you can't say that -- tough", or
   b) say "if sex= is *not* specified, it is presumed to be mixed"
5. Remove sex= from <personGrp> entirely -- if you want to know,
   check the children[1]

At the moment I am leaning towards #2, at least until those who work
on our "prosopography" work on the issue. With this solution the
datatype still maps cleanly to ISO, and it is very clear which values
of sex= of <personGrp> are from ISO (numeric codes) and which are
made up by TEI (contain letters).

Note
----
[1] The following fragment of XSLT 1.1 does the job iff there are
    only male and female children. One could obviously extend this to
    cover the "not known" and "not specified" cases as well.

  <xsl:template match="personGrp">
    <xsl:variable name="sex">
      <xsl:choose>
        <xsl:when test="count(./person[@sex='1']) = 0 and count(./person[@sex='2']) > 0">
          <xsl:text>all female</xsl:text>
        </xsl:when>
        <xsl:when test="count(./person[@sex='1']) > 0 and count(./person[@sex='2']) = 0">
          <xsl:text>all male</xsl:text>
        </xsl:when>
        <xsl:when test="count(./person[@sex='1']) > 0 and count(./person[@sex='2']) > 0">
          <xsl:text>mixed company</xsl:text>
        </xsl:when>
      </xsl:choose>
    </xsl:variable>
    <xsl:message>
      personGrp # <xsl:value-of select="@n"/> is <xsl:value-of select="$sex"/>.
    </xsl:message>
  </xsl:template>

   Of course, one could go a lot further:

        <xsl:when test="count(./person[@sex='1']) > 0.6 * count(./person)">
          <xsl:text>mostly male</xsl:text>
        </xsl:when>
        <xsl:when test="count(./person[@sex='2']) > 0.6 * count(./person)">
          <xsl:text>mostly female</xsl:text>
        </xsl:when>

   (BTW, I'm not claiming this is *good* XSLT code, just proof of
   concept.)

From Julia_Flanders at Brown.edu  Thu Oct 20 10:17:13 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 20 Oct 2005 10:17:13 -0400
Subject: [tei-council] TEI Council report to MM 2005
In-Reply-To: <ygf7jcaq941.fsf@chwpb.local>
References: <ygf7jcaq941.fsf@chwpb.local>
Message-ID: <a06200741bf7d57113fa0@[128.148.157.102]>

Christian, it looks good to me. I like your house renovation metaphor 
(though as anyone who has been through a house renovation knows, it's 
one that projects an unending future of renovations :-) or maybe they 
do these things better in Germany!

best wishes, Julia

>Dear Council members,
>
>I have drafted a report to the members meeting.  It is now available
>at
>http://www.kanji.zinbun.kyoto-u.ac.jp/~wittern/tei/mm05councilreport.html
>for your review.  Please look at this and report anything that you
>feel is missing or weird here.  I would like to finalize this Friday
>and hand it over to Lou for publication on the Website, so please give
>me your comments now.
>
>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

From sebastian.rahtz at oucs.ox.ac.uk  Thu Oct 20 11:16:17 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 20 Oct 2005 16:16:17 +0100
Subject: [tei-council] sex confession
In-Reply-To: <17239.41528.319553.941346@emt.wwp.brown.edu>
References: <17239.41528.319553.941346@emt.wwp.brown.edu>
Message-ID: <4357B4C1.4080208@oucs.ox.ac.uk>

Syd Bauman wrote:

>Solutions
>---------
>Some possible solutions are:
>1. Add a new numeric code, say "7", that means "mixed", to data.sex.
>2. Use
>     attribute sex { data.sex | "mixed" }
>   for sex= of <personGrp>
>3. Change the datatype so that the values are "not known", "male",
>   "female", and "not specified", and then use #2.
>4. Remove "mixed" from the possible values of sex= of <personGrp> and
>   either
>   a) say "you can't say that -- tough", or
>   b) say "if sex= is *not* specified, it is presumed to be mixed"
>5. Remove sex= from <personGrp> entirely -- if you want to know,
>   check the children[1]
>  
>
My preference is for 4, followed by 5,  followed by 2.

-- 
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  Thu Oct 20 11:22:58 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 20 Oct 2005 16:22:58 +0100
Subject: [tei-council] sex confession
In-Reply-To: <4357B4C1.4080208@oucs.ox.ac.uk>
References: <17239.41528.319553.941346@emt.wwp.brown.edu>
	<4357B4C1.4080208@oucs.ox.ac.uk>
Message-ID: <4357B652.8010101@oucs.ox.ac.uk>

On the positive side, it's a good test to see if you have a real 0.2.1
TEI installed - just look
at <personGrp> and check you see the anomaly. If you do, you have the
version
of P5 which was current from 2200 GMT yesterday to 0900 GMT today (when
I froze things).

Gosh, making a new release of the TEI files everywhere they ought to be
is an exhausting process.

sebastian

From Julia_Flanders at Brown.edu  Thu Oct 20 11:24:24 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 20 Oct 2005 11:24:24 -0400
Subject: [tei-council] sex confession
In-Reply-To: <17239.41528.319553.941346@emt.wwp.brown.edu>
References: <17239.41528.319553.941346@emt.wwp.brown.edu>
Message-ID: <a06200747bf7d655296f8@[128.148.157.102]>

Solution 2 sounds reasonable to me. I like the fact that it makes a 
clear distinction between the ISO codes and the value which is not a 
member thereof.

Julia

>Problem
>-------
>We agreed to use ISO 5218 codes for the value of sex= of <person> and
><personGrp>:
>     * 0 = not known,
>     * 1 = male,
>     * 2 = female,
>     * 9 = not specified.
>However, <personGrp> (at least as P4 conceives it) requires an
>additional value: "mixed" -- the group contains people of different
>sexes.
>
>Solutions
>---------
>Some possible solutions are:
>1. Add a new numeric code, say "7", that means "mixed", to data.sex.
>2. Use
>      attribute sex { data.sex | "mixed" }
>    for sex= of <personGrp>
>3. Change the datatype so that the values are "not known", "male",
>    "female", and "not specified", and then use #2.
>4. Remove "mixed" from the possible values of sex= of <personGrp> and
>    either
>    a) say "you can't say that -- tough", or
>    b) say "if sex= is *not* specified, it is presumed to be mixed"
>5. Remove sex= from <personGrp> entirely -- if you want to know,
>    check the children[1]
>
>At the moment I am leaning towards #2, at least until those who work
>on our "prosopography" work on the issue. With this solution the
>datatype still maps cleanly to ISO, and it is very clear which values
>of sex= of <personGrp> are from ISO (numeric codes) and which are
>made up by TEI (contain letters).
>
>
>Note
>----
>[1] The following fragment of XSLT 1.1 does the job iff there are
>     only male and female children. One could obviously extend this to
>     cover the "not known" and "not specified" cases as well.
>
>   <xsl:template match="personGrp">
>     <xsl:variable name="sex">
>       <xsl:choose>
>         <xsl:when test="count(./person[@sex='1']) = 0 and 
>count(./person[@sex='2']) > 0">
>           <xsl:text>all female</xsl:text>
>         </xsl:when>
>         <xsl:when test="count(./person[@sex='1']) > 0 and 
>count(./person[@sex='2']) = 0">
>           <xsl:text>all male</xsl:text>
>         </xsl:when>
>         <xsl:when test="count(./person[@sex='1']) > 0 and 
>count(./person[@sex='2']) > 0">
>           <xsl:text>mixed company</xsl:text>
>         </xsl:when>
>       </xsl:choose>
>     </xsl:variable>
>     <xsl:message>
>       personGrp # <xsl:value-of select="@n"/> is <xsl:value-of 
>select="$sex"/>.
>     </xsl:message>
>   </xsl:template>
>
>    Of course, one could go a lot further:
>
>         <xsl:when test="count(./person[@sex='1']) > 0.6 * count(./person)">
>           <xsl:text>mostly male</xsl:text>
>         </xsl:when>
>         <xsl:when test="count(./person[@sex='2']) > 0.6 * count(./person)">
>           <xsl:text>mostly female</xsl:text>
>         </xsl:when>
>
>    (BTW, I'm not claiming this is *good* XSLT code, just proof of
>    concept.)
>
>_______________________________________________
>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 Oct 20 18:38:36 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 21 Oct 2005 07:38:36 +0900
Subject: [tei-council] TEI Council report to MM 2005
In-Reply-To: <4357F422.6050204@umd.edu> (Susan Schreibman's message of "Thu,
	20 Oct 2005 15:46:42 -0400")
References: <ygf7jcaq941.fsf@chwpb.local> <4357F422.6050204@umd.edu>
Message-ID: <ygf64rr24r7.fsf@kanji.zinbun.kyoto-u.ac.jp>

Susan Schreibman <sschreib at umd.edu> writes:

> Hi Christian -- this report looks terrific. I wondered if it were
> possible to include a link to the mapping done by John and Natasha?

In fact I wondered about that as well.  In some minutes there is an
action item to put a link to this on the Activities page, but as far
as I can see this has never happened.  

John, Natasha -- can you give me a URL for this file? Preferrable on
the tei-c.org domain;-)

>
> I just wanted to tell you that I won't make the members meeting this
> year. I've just too many obligations with this new job. I hate to miss
> it, as it is the first one I'm not attending

Sorry to hear that.  I am sure it will be a memorable occasion.

Christian

-- 
 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From nsmith at email.unc.edu  Fri Oct 21 09:16:16 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Fri, 21 Oct 2005 09:16:16 -0400 (Eastern Daylight Time)
Subject: [tei-council] TEI Council report to MM 2005
In-Reply-To: <ygf64rr24r7.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <Pine.WNT.4.10.10510210913280.2912-100000@AALCD49.lib.unc.edu>

Christian:

It does look great. Your metaphor's so poetic and mentioning of Tubingen
brought wonderful memories - thank you!

I have rather nitpicking suggestions:

1.	"While in the past development took place mainly in workgroups
charged by the Council, this year the Council took on more and more tasks
by itself and did not charge any new workgroups this year." A bit
awkwardly stated and please delete one of two "this year"s mentioned in
the sentence.
2.	"one face to face meeting" - I think it should be  "face-to-face."
I leave it to native speakers...
3.	dubbed the "class meeting" - either needs a second comma after the
closing quotation or needs mdashes on both sides
4.	'the Council focussed" - should be "focused"; similarily - should
be similarly; fomat - change to format; metioned to mentioned; Liasion -
Liaison;  jon - join; 

As to the mapping, "an attempt to map metadata standards to the elements
in the TEIHeader" is still in the phase of "attempt". I hope that we can
finally move ahead with it once all of us(I mean catalogers and us) at the
same in the same place. John?

best, ns

On Fri, 21 Oct 2005, Christian Wittern wrote:

> Susan Schreibman <sschreib at umd.edu> writes:
> 
> > Hi Christian -- this report looks terrific. I wondered if it were
> > possible to include a link to the mapping done by John and Natasha?
> 
> In fact I wondered about that as well.  In some minutes there is an
> action item to put a link to this on the Activities page, but as far
> as I can see this has never happened.  
> 
> John, Natasha -- can you give me a URL for this file? Preferrable on
> the tei-c.org domain;-)
> 
> >
> > I just wanted to tell you that I won't make the members meeting this
> > year. I've just too many obligations with this new job. I hate to miss
> > it, as it is the first one I'm not attending
> 
> Sorry to hear that.  I am sure it will be a memorable occasion.
> 
> 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 Syd_Bauman at Brown.edu  Sat Oct 22 20:24:13 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 22 Oct 2005 20:24:13 -0400
Subject: [tei-council] sex confession
In-Reply-To: <a06200747bf7d655296f8@[128.148.157.102]>
References: <17239.41528.319553.941346@emt.wwp.brown.edu>
	<a06200747bf7d655296f8@[128.148.157.102]>
Message-ID: <17242.55341.820563.529333@emt.wwp.brown.edu>

> > 1. Add a new numeric code, say "7", that means "mixed", to data.sex.
> > 2. Use
> >      attribute sex { data.sex | "mixed" }
> >    for sex= of <personGrp>
> > 3. Change the datatype so that the values are "not known", "male",
> >    "female", and "not specified", and then use #2.
> > 4. Remove "mixed" from the possible values of sex= of <personGrp> and
> >    either
> >    a) say "you can't say that -- tough", or
> >    b) say "if sex= is *not* specified, it is presumed to be mixed"
> > 5. Remove sex= from <personGrp> entirely -- if you want to know,
> >    check the children[1]

JF> Solution 2 sounds reasonable to me. I like the fact that it makes
JF> a clear distinction between the ISO codes and the value which is
JF> not a member thereof.

SR> My preference is for 4, followed by 5,  followed by 2.

I think 1 is a bad idea, as it's confusing, and what do we do when
ISO updates their standard and uses the number we picked?

I like 3, but have already been outvoted on that.

4a and 5 turn out to have a major problem -- a <personGrp> element
does not group a bunch of <person> elements, but rather just
describes the group. Thus it *needs* to be able to say "mixed", and I
can well imagine people wanting even more precision than that. (E.g.,
to be able to specify exact counts, or rough percentages, of each
sex.)

So I think we are down to 2 or 4b. For the moment I've checked in a
version that uses 2. Those who want to argue for 4b or a system that
allows more flexibility and precision should speak up now (and thus
be drafted for the <soCalled>prosopography</soCalled> WG! :-)

From lou.burnard at computing-services.oxford.ac.uk  Sun Oct 23 05:31:07 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sun, 23 Oct 2005 10:31:07 +0100
Subject: [tei-council] sex confession
In-Reply-To: <17242.55341.820563.529333@emt.wwp.brown.edu>
References: <17239.41528.319553.941346@emt.wwp.brown.edu>	<a06200747bf7d655296f8@[128.148.157.102]>
	<17242.55341.820563.529333@emt.wwp.brown.edu>
Message-ID: <435B585B.4010404@computing-services.oxford.ac.uk>

Sorry, I havent contributed to this discussion yet, being busy in Nancy 
(on which more anon), but just for the record my recommendation is for  4.b

Syd Bauman wrote:

>>>1. Add a new numeric code, say "7", that means "mixed", to data.sex.
>>>2. Use
>>>     attribute sex { data.sex | "mixed" }
>>>   for sex= of <personGrp>
>>>3. Change the datatype so that the values are "not known", "male",
>>>   "female", and "not specified", and then use #2.
>>>4. Remove "mixed" from the possible values of sex= of <personGrp> and
>>>   either
>>>   a) say "you can't say that -- tough", or
>>>   b) say "if sex= is *not* specified, it is presumed to be mixed"
>>>5. Remove sex= from <personGrp> entirely -- if you want to know,
>>>   check the children[1]
> 
> 
> JF> Solution 2 sounds reasonable to me. I like the fact that it makes
> JF> a clear distinction between the ISO codes and the value which is
> JF> not a member thereof.
> 
> SR> My preference is for 4, followed by 5,  followed by 2.
> 
> 
> I think 1 is a bad idea, as it's confusing, and what do we do when
> ISO updates their standard and uses the number we picked?
> 
> I like 3, but have already been outvoted on that.
> 
> 4a and 5 turn out to have a major problem -- a <personGrp> element
> does not group a bunch of <person> elements, but rather just
> describes the group. Thus it *needs* to be able to say "mixed", and I
> can well imagine people wanting even more precision than that. (E.g.,
> to be able to specify exact counts, or rough percentages, of each
> sex.)
> 
> So I think we are down to 2 or 4b. For the moment I've checked in a
> version that uses 2. Those who want to argue for 4b or a system that
> allows more flexibility and precision should speak up now (and thus
> be drafted for the <soCalled>prosopography</soCalled> WG! :-)
> 
> _______________________________________________
> 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  Sun Oct 23 18:48:33 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 24 Oct 2005 07:48:33 +0900
Subject: [tei-council] sex confession
In-Reply-To: <435B585B.4010404@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Sun, 23 Oct 2005 10:31:07 +0100")
References: <17239.41528.319553.941346@emt.wwp.brown.edu>
	<a06200747bf7d655296f8@[128.148.157.102]>
	<17242.55341.820563.529333@emt.wwp.brown.edu>
	<435B585B.4010404@computing-services.oxford.ac.uk>
Message-ID: <ygfd5lvx326.fsf@kanji.zinbun.kyoto-u.ac.jp>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> Sorry, I havent contributed to this discussion yet, being busy in
> Nancy (on which more anon), but just for the record my recommendation
> is for  4.b
>
> Syd Bauman wrote:
>
>>>>1. Add a new numeric code, say "7", that means "mixed", to data.sex.
>>>>2. Use
>>>>     attribute sex { data.sex | "mixed" }
>>>>   for sex= of <personGrp>
>>>>3. Change the datatype so that the values are "not known", "male",
>>>>   "female", and "not specified", and then use #2.
>>>>4. Remove "mixed" from the possible values of sex= of <personGrp> and
>>>>   either
>>>>   a) say "you can't say that -- tough", or
>>>>   b) say "if sex= is *not* specified, it is presumed to be mixed"
>>>>5. Remove sex= from <personGrp> entirely -- if you want to know,
>>>>   check the children[1]

I am with 2 here -- I think is is always a good idea to make things
explicit and not to rely on some implicit, tacit assumption.

Christian

-- 
 Christian Wittern 
 Institute for Research in Humanities, Kyoto University
 47 Higashiogura-cho, Kitashirakawa, Sakyo-ku, Kyoto 606-8265, JAPAN

From nsmith at email.unc.edu  Mon Oct 24 10:23:10 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Mon, 24 Oct 2005 10:23:10 -0400 (Eastern Daylight Time)
Subject: [tei-council] sex confession
In-Reply-To: <17242.55341.820563.529333@emt.wwp.brown.edu>
Message-ID: <Pine.WNT.4.10.10510241022390.2012-100000@AALCD49.lib.unc.edu>

Reread all the arguments - my vote goes to 2. n

On Sat, 22 Oct 2005, Syd Bauman wrote:

> > > 1. Add a new numeric code, say "7", that means "mixed", to data.sex.
> > > 2. Use
> > >      attribute sex { data.sex | "mixed" }
> > >    for sex= of <personGrp>
> > > 3. Change the datatype so that the values are "not known", "male",
> > >    "female", and "not specified", and then use #2.
> > > 4. Remove "mixed" from the possible values of sex= of <personGrp> and
> > >    either
> > >    a) say "you can't say that -- tough", or
> > >    b) say "if sex= is *not* specified, it is presumed to be mixed"
> > > 5. Remove sex= from <personGrp> entirely -- if you want to know,
> > >    check the children[1]
> 
> JF> Solution 2 sounds reasonable to me. I like the fact that it makes
> JF> a clear distinction between the ISO codes and the value which is
> JF> not a member thereof.
> 
> SR> My preference is for 4, followed by 5,  followed by 2.
> 
> 
> I think 1 is a bad idea, as it's confusing, and what do we do when
> ISO updates their standard and uses the number we picked?
> 
> I like 3, but have already been outvoted on that.
> 
> 4a and 5 turn out to have a major problem -- a <personGrp> element
> does not group a bunch of <person> elements, but rather just
> describes the group. Thus it *needs* to be able to say "mixed", and I
> can well imagine people wanting even more precision than that. (E.g.,
> to be able to specify exact counts, or rough percentages, of each
> sex.)
> 
> So I think we are down to 2 or 4b. For the moment I've checked in a
> version that uses 2. Those who want to argue for 4b or a system that
> allows more flexibility and precision should speak up now (and thus
> be drafted for the <soCalled>prosopography</soCalled> WG! :-)
> 
> _______________________________________________
> 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 Nov  1 09:24:10 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 01 Nov 2005 14:24:10 +0000
Subject: [tei-council] [Fwd: Meeting: TEI Council telcon]
Message-ID: <43677A8A.2020604@oucs.ox.ac.uk>

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.asp?id=B64ABH

PROPOSED MEETING DATES:

Monday 28th November
Tuesday 29th November
Wednesday 30th November
Thursday 1st December
Friday 9th December
Monday 12th December
Tuesday 13th December
Wednesday 14th December
Thursday 15th December
Friday 16th December

-- 
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  Tue Nov  1 12:43:49 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 01 Nov 2005 17:43:49 +0000
Subject: [tei-council] datatypes again: make data.key a URI
Message-ID: <4367A955.10605@oucs.ox.ac.uk>

[Aaargh you cry, not again]

Proposal: make data.key map on to xsd:anyURI instead of xsd:string

Rationale:   At present data.key is for "things like database keys" 
i.e. arbitrary strings which are not XML names (like ident), and not 
necessarily pointers (like #ident). A key is a magic string of some sort 
which an external system uses to access some additional information 
associated with the magic string.

I put it to you, mlud, that this *is* effectively a URI. It is hard to 
imagine any likely scenario in which a database system wouldn't provide 
a URI-encoded way of accessing its contents in this day and age.

Use case:  all naming elements (<rs>, <name> etc.) have a key attribute 
defined as data.key. You *might* want to say <rs key="wibble">Mr 
Bennet</rs> and leave it at that, but it seems at least as likely that 
you will somewhere have a <person xml:id="wibble"> element (not 
necessarily in the same document, but that doesnt matter any more) and 
want to point to it.

Choices: we could allow for both key= and uri= and say you really ought 
to choose one or the other but not both. we could allow for them as 
alternatives. we could choose just one. My vote is for the last, and for 
URI.

We have made the transition from ID/IDREF to xml:id/anyURI more or less 
consistently throughout P5. I say now is the time to recognise that 
anyURI is a better way of meeting the ends for which "key" was 
originally conceived.

Any objections?

From James.Cummings at computing-services.oxford.ac.uk  Tue Nov  1 12:51:35 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 01 Nov 2005 19:51:35 +0200
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367A955.10605@oucs.ox.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>
Message-ID: <4367AB27.5030107@computing-services.oxford.ac.uk>

Lou Burnard wrote:
> Rationale:   At present data.key is for "things like database keys" i.e. 
> arbitrary strings which are not XML names (like ident), and not 
> necessarily pointers (like #ident). A key is a magic string of some sort 
> which an external system uses to access some additional information 
> associated with the magic string.
> I put it to you, mlud, that this *is* effectively a URI. It is hard to 
> imagine any likely scenario in which a database system wouldn't provide 
> a URI-encoded way of accessing its contents in this day and age.
> 

What if my key has characters not allowed by URI's (I've not checked 
what the restrictions on that since I'm still in Sofia).

> Use case:  all naming elements (<rs>, <name> etc.) have a key attribute 
> defined as data.key. You *might* want to say <rs key="wibble">Mr 
> Bennet</rs> and leave it at that, but it seems at least as likely that 
> you will somewhere have a <person xml:id="wibble"> element (not 
> necessarily in the same document, but that doesnt matter any more) and 
> want to point to it.
> 
> Choices: we could allow for both key= and uri= and say you really ought 
> to choose one or the other but not both. we could allow for them as 
> alternatives. we could choose just one. My vote is for the last, and for 
> URI.

What if I want to give the <person> element a key to my database but I 
want to also give it an xml:id for other purposes?

> Any objections?

I'm not necessarily objecting, just want it explained to me more. 
What do we lose if we are only able to have key or xml:id on an element.

-James

From sebastian.rahtz at oucs.ox.ac.uk  Tue Nov  1 13:23:49 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 01 Nov 2005 18:23:49 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367AB27.5030107@computing-services.oxford.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>
	<4367AB27.5030107@computing-services.oxford.ac.uk>
Message-ID: <4367B2B5.7070105@oucs.ox.ac.uk>

James Cummings wrote:

>
>
> What if my key has characters not allowed by URI's (I've not checked
> what the restrictions on that since I'm still in Sofia).
>
you can use encoding in URIs if needed, eg for spaces

>
> What if I want to give the <person> element a key to my database but I
> want to also give it an xml:id for other purposes?

eh? thats not the same issue. Lou is talking about <rs>, not <person>

-- 
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 Nov  1 13:28:12 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 01 Nov 2005 18:28:12 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367A955.10605@oucs.ox.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>
Message-ID: <4367B3BC.3010500@oucs.ox.ac.uk>

So long as you keep the data.key clearly defined for this purpose,
people can
always change its datatype if their resource is not URI-addressable.

as a local example, Lou, "rahtz" is a key into our LDAP, but is that
addressable
as  a URI?

-- 
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  Tue Nov  1 13:34:46 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 01 Nov 2005 20:34:46 +0200
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367B2B5.7070105@oucs.ox.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>
	<4367AB27.5030107@computing-services.oxford.ac.uk>
	<4367B2B5.7070105@oucs.ox.ac.uk>
Message-ID: <4367B546.704@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> James Cummings wrote:
> 
> 
>>
>>What if my key has characters not allowed by URI's (I've not checked
>>what the restrictions on that since I'm still in Sofia).
>>
> 
> you can use encoding in URIs if needed, eg for spaces

ok.  I'm easily convinced by that.

>>What if I want to give the <person> element a key to my database but I
>>want to also give it an xml:id for other purposes?
> eh? thats not the same issue. Lou is talking about <rs>, not <person>

erm yeah. typo, blame it on being in a Sofia pub.  I meant <rs 
key="#databaseKey" xml:id="someDocumentIDScheme">foo</rs>

Isn't it at all likely that I'll want to apply both rather than have 
to choose between them?

-James

From sebastian.rahtz at oucs.ox.ac.uk  Tue Nov  1 13:42:50 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 01 Nov 2005 18:42:50 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367B546.704@computing-services.oxford.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>
	<4367AB27.5030107@computing-services.oxford.ac.uk>
	<4367B2B5.7070105@oucs.ox.ac.uk>
	<4367B546.704@computing-services.oxford.ac.uk>
Message-ID: <4367B72A.5020004@oucs.ox.ac.uk>

James Cummings wrote:

>
> erm yeah. typo, blame it on being in a Sofia pub.  I meant <rs
> key="#databaseKey" xml:id="someDocumentIDScheme">foo</rs>
>
> Isn't it at all likely that I'll want to apply both rather than have
> to choose between them?
>
what you're doing here is a grotesque abuse of xml:id! in your example
"someDocumentIDScheme" identifies this <rs>, not the "foo" thing.

the lamb and spinach patties with "potatoes on skin" were good for me,
if you have not ordered yet

-- 
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  Tue Nov  1 13:55:07 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 01 Nov 2005 20:55:07 +0200
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367B72A.5020004@oucs.ox.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>
	<4367AB27.5030107@computing-services.oxford.ac.uk>
	<4367B2B5.7070105@oucs.ox.ac.uk>
	<4367B546.704@computing-services.oxford.ac.uk>
	<4367B72A.5020004@oucs.ox.ac.uk>
Message-ID: <4367BA0B.9060700@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
>>Isn't it at all likely that I'll want to apply both rather than have
>>to choose between them?
> 
> what you're doing here is a grotesque abuse of xml:id! in your example
> "someDocumentIDScheme" identifies this <rs>, not the "foo" thing.

Ok... I must be being dense, I was assuming it was identifying the 
<rs> element, not the 'foo'.... can't I have a database key attached 
to something where I also want to have an ID of some sort on the 
element?  Aren't these two completely different things?

> the lamb and spinach patties with "potatoes on skin" were good for me,
> if you have not ordered yet

Already eaten.  Yesterday MattZ got a lovely StPatrick's Day style hat 
because we had two Murphys.

-James

From lou.burnard at computing-services.oxford.ac.uk  Tue Nov  1 14:42:55 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 01 Nov 2005 19:42:55 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367BA0B.9060700@computing-services.oxford.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>	<4367AB27.5030107@computing-services.oxford.ac.uk>	<4367B2B5.7070105@oucs.ox.ac.uk>	<4367B546.704@computing-services.oxford.ac.uk>	<4367B72A.5020004@oucs.ox.ac.uk>
	<4367BA0B.9060700@computing-services.oxford.ac.uk>
Message-ID: <4367C53F.9020101@computing-services.oxford.ac.uk>

James Cummings wrote:
> Sebastian Rahtz wrote:
> 
>>> Isn't it at all likely that I'll want to apply both rather than have
>>> to choose between them?
>>
>>
>> what you're doing here is a grotesque abuse of xml:id! in your example
>> "someDocumentIDScheme" identifies this <rs>, not the "foo" thing.
> 
> 
> Ok... I must be being dense, I was assuming it was identifying the <rs> 
> element, not the 'foo'.... can't I have a database key attached to 
> something where I also want to have an ID of some sort on the element?  
> Aren't these two completely different things?
> 

This makes no sense. Have another murphys.

The <rs> can have an xml:id if you like. The <person> can too.
The purpose of the KEY attribute however is to say what <person> 
corresponds to this <rs>. It can do that by pointing to the <person>s 
ID, or by Some Other Means.

From James.Cummings at computing-services.oxford.ac.uk  Tue Nov  1 14:32:24 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 01 Nov 2005 21:32:24 +0200
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367C53F.9020101@computing-services.oxford.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>	<4367AB27.5030107@computing-services.oxford.ac.uk>	<4367B2B5.7070105@oucs.ox.ac.uk>	<4367B546.704@computing-services.oxford.ac.uk>	<4367B72A.5020004@oucs.ox.ac.uk>
	<4367BA0B.9060700@computing-services.oxford.ac.uk>
	<4367C53F.9020101@computing-services.oxford.ac.uk>
Message-ID: <4367C2C8.6090906@computing-services.oxford.ac.uk>

Lou Burnard wrote:
>> Ok... I must be being dense, I was assuming it was identifying the 
>> <rs> element, not the 'foo'.... can't I have a database key attached 
>> to something where I also want to have an ID of some sort on the 
>> element?  Aren't these two completely different things?
> 
> This makes no sense. Have another murphys.

*James orders another Murphys

> The <rs> can have an xml:id if you like. The <person> can too.
> The purpose of the KEY attribute however is to say what <person> 
> corresponds to this <rs>. It can do that by pointing to the <person>s 
> ID, or by Some Other Means.

Ah I think I am understanding my misunderstanding now.  *sip Murphys*
You said:

 >Choices: we could allow for both key= and uri= and say you really
 >ought to choose one or the other but not both. we could allow for
 >them as alternatives. we could choose just one. My vote is for the
 >last, and for URI.

I misread uri= and xml:id because the preceding example involving the 
person.  I thought you were saying a choice of xml:id or key.... *doh* 
  I agree then: just make @key a URI and if someone wants to change it 
they can.

*sigh*

I really should have a thunderbird extension which asks 'are you in a 
pub?' if my IP address has changed from the last time I've answered 
and then if I say yes, just postpone the message instead of sending them.

*Sigh*

-James

From lou.burnard at computing-services.oxford.ac.uk  Tue Nov  1 14:54:23 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 01 Nov 2005 19:54:23 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367AB27.5030107@computing-services.oxford.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>
	<4367AB27.5030107@computing-services.oxford.ac.uk>
Message-ID: <4367C7EF.2000806@computing-services.oxford.ac.uk>

James Cummings wrote:

> 
>> Use case:  all naming elements (<rs>, <name> etc.) have a key 
>> attribute defined as data.key. You *might* want to say <rs 
>> key="wibble">Mr Bennet</rs> and leave it at that, but it seems at 
>> least as likely that you will somewhere have a <person 
>> xml:id="wibble"> element (not necessarily in the same document, but 
>> that doesnt matter any more) and want to point to it.
>>
...
> 
> What if I want to give the <person> element a key to my database but I 
> want to also give it an xml:id for other purposes?
> 

Sorry, I think I now see what I have failed to explain. It's not that 
you have to choose between <rs key="xxx"> and <person xml:id="xxx">. The 
  assumption is that you might want to have both and to link them 
together. At present, if you say <rs key="xxx"> and you want to link 
that to your <person xml:id="yyy"> you either have to use a different 
attribute, since key= doesnt act as a uri, or redefine the datraype for 
key, which is what I am proposing.

> I'm not necessarily objecting, just want it explained to me more. What 
> do we lose if we are only able to have key or xml:id on an element.
> 

hope this is a bit clearer now, and apologies for excessive elision

> -James
> 
> 

From Julia_Flanders at Brown.edu  Thu Nov  3 11:55:20 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 3 Nov 2005 11:55:20 -0500
Subject: [tei-council] stepping down
Message-ID: <a06200715bf8ff0b51117@[128.148.157.102]>

As some of you may already know, at the TEI board meeting a few days 
ago I stepped down as TEI chair and Matthew Zimmerman agreed to serve 
as the new chair. So I will henceforth no longer be a member of the 
TEI council. I've asked Daniel Pitti to remove me from the list and 
add Matt in my place.

I will be happy to follow up on any loose ends of tasks that I began 
(e.g. if there are further issues with name  regularization or 
certainty, etc.) and would also be happy to help with chapter 
reviewing and other work if needed; just let me know.

best wishes, Julia

From Julia_Flanders at Brown.edu  Thu Nov  3 11:57:28 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 3 Nov 2005 11:57:28 -0500
Subject: [tei-council] conference call
Message-ID: <a06200717bf8ff1e05742@[128.148.157.102]>

I'm forwarding Matt  Z. the details Sebastian posted concerning the 
conference call.

best, Julia

From pwillett at umich.edu  Thu Nov  3 12:03:24 2005
From: pwillett at umich.edu (Perry Willett)
Date: Thu, 3 Nov 2005 12:03:24 -0500
Subject: [tei-council] members meeting report?
In-Reply-To: <a06200715bf8ff0b51117@[128.148.157.102]>
Message-ID: <002401c5e098$83909a70$922bd38d@CLUBSODA>

For we unhappy few who didn't attend the members meeting, could we hear the
election results? Anything else to report? Thanks,

Perry

From Julia_Flanders at Brown.edu  Thu Nov  3 12:07:01 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 3 Nov 2005 12:07:01 -0500
Subject: [tei-council] members meeting report?
In-Reply-To: <002401c5e098$83909a70$922bd38d@CLUBSODA>
References: <002401c5e098$83909a70$922bd38d@CLUBSODA>
Message-ID: <a06200719bf8ff414db71@[128.148.157.102]>

Yes, a report will be posted to TEI-L very soon. ...

>For we unhappy few who didn't attend the members meeting, could we hear the
>election results? Anything else to report? Thanks,
>
>Perry
>
>
>
>_______________________________________________
>tei-council mailing list
>tei-council at lists.village.Virginia.EDU
>http://lists.village.Virginia.EDU/mailman/listinfo/tei-council

From Julia_Flanders at Brown.edu  Thu Nov  3 14:41:24 2005
From: Julia_Flanders at Brown.edu (Julia Flanders)
Date: Thu, 3 Nov 2005 14:41:24 -0500
Subject: [tei-council] TEI election results
Message-ID: <a06200735bf90176f24ae@[128.148.157.102]>

Here are the results of the recent TEI elections:

Elected to the TEI Council for a term beginning January 1, 2006 and 
ending December 31, 2007:

David Birnbaum
Matthew Driscoll
Dot Porter
Laurent Romary
Conal Tuohy
Christian Wittern

Elected to the TEI Board (same term):

Daniel O'Donnell
John Unsworth

I've written to all of the candidates to let them know the outcome, 
and have sent Daniel Pitti and Chris Ruotolo the requisite 
information so that the listservs and web site can be updated 
appropriately.

Best wishes, Julia

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Nov  4 03:23:55 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 04 Nov 2005 09:23:55 +0100
Subject: [tei-council] stepping down
In-Reply-To: <a06200715bf8ff0b51117@[128.148.157.102]> (Julia Flanders's
	message of "Thu, 3 Nov 2005 11:55:20 -0500")
References: <a06200715bf8ff0b51117@[128.148.157.102]>
Message-ID: <ygf8xw4x1lw.fsf@chwpb.local>

Dear Julia,

I would like to take this opportunity to thank you for the support and
energy you put in supporting the work of the council.  I am sure there
will be future opportunities to count on your help.

All the best,

Christian

Julia Flanders <Julia_Flanders at Brown.edu> writes:

> As some of you may already know, at the TEI board meeting a few days
> ago I stepped down as TEI chair and Matthew Zimmerman agreed to serve
> as the new chair. So I will henceforth no longer be a member of the
> TEI council. I've asked Daniel Pitti to remove me from the list and
> add Matt in my place.
>
> I will be happy to follow up on any loose ends of tasks that I began
> (e.g. if there are further issues with name  regularization or
> certainty, etc.) and would also be happy to help with chapter
> reviewing and other work if needed; just let me know.
>
> best wishes, Julia
> _______________________________________________
> 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 sschreib at umd.edu  Fri Nov  4 08:44:00 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Fri, 04 Nov 2005 08:44:00 -0500
Subject: [tei-council] stepping down
In-Reply-To: <ygf8xw4x1lw.fsf@chwpb.local>
References: <a06200715bf8ff0b51117@[128.148.157.102]>
	<ygf8xw4x1lw.fsf@chwpb.local>
Message-ID: <436B65A0.3050807@umd.edu>

I  wholeheartedly second Christian's thanks --

susan

Christian Wittern wrote:

>Dear Julia,
>
>I would like to take this opportunity to thank you for the support and
>energy you put in supporting the work of the council.  I am sure there
>will be future opportunities to count on your help.
>
>All the best,
>
>Christian
>
>Julia Flanders <Julia_Flanders at Brown.edu> writes:
>
>  
>
>>As some of you may already know, at the TEI board meeting a few days
>>ago I stepped down as TEI chair and Matthew Zimmerman agreed to serve
>>as the new chair. So I will henceforth no longer be a member of the
>>TEI council. I've asked Daniel Pitti to remove me from the list and
>>add Matt in my place.
>>
>>I will be happy to follow up on any loose ends of tasks that I began
>>(e.g. if there are further issues with name  regularization or
>>certainty, etc.) and would also be happy to help with chapter
>>reviewing and other work if needed; just let me know.
>>
>>best wishes, Julia
>>_______________________________________________
>>tei-council mailing list
>>tei-council at lists.village.Virginia.EDU
>>http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>    
>>
>
>  
>

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742

Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib at umd.edu

From Syd_Bauman at Brown.edu  Fri Nov  4 19:44:29 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 4 Nov 2005 19:44:29 -0500
Subject: [tei-council] our time zones
Message-ID: <17260.109.848683.361390@emt.wwp.brown.edu>

A personalized world clock for Board and Council. Please let me know
of any errors or omissions.

http://www.timeanddate.com/worldclock/custom.html?cities=55,64,105,878,136,195,538,264

Calgary - Dan O'Donell
Indianapolis - John Walsh
Chicago - John Unsworth
Providence - Syd Bauman, David Birnbaum, Julia Flanders, Daniel
             Pitti, Dot Porter, Susan Schreibman, Natasha Smith,
             Perry Willett, Matt Zimmerman, (and Patrick Durusau,
             yes?)
London - Lou Burnard, James Cummings, John Lavagnino, Sebastian Rahtz
Paris - Alejandro Bia, Matthew Driscoll, Veronika Lux, Laurent Romary
Kyoto - Christian Wittern
Wellington - Conal Tuohy

From sebastian.rahtz at oucs.ox.ac.uk  Sun Nov  6 08:15:17 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 06 Nov 2005 13:15:17 +0000
Subject: [tei-council] next meeting
Message-ID: <436E01E5.4040203@oucs.ox.ac.uk>

A weak response so far to Meetomatic. Can some more of you

visit http://www.meetomatic.com/respond.asp?id=B64ABH, please?

-- 
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 mz34 at nyu.edu  Sun Nov  6 23:54:15 2005
From: mz34 at nyu.edu (Matthew Zimmerman)
Date: Sun, 6 Nov 2005 23:54:15 -0500
Subject: [tei-council] Greetings
In-Reply-To: <a06200715bf8ff0b51117@[128.148.157.102]>
References: <a06200715bf8ff0b51117@[128.148.157.102]>
Message-ID: <0717CEEE-F6F3-4AC0-848E-2B8C85126867@nyu.edu>

Hello all,

I think everyone on the council knows me but I just wanted to say an  
official hello as now I will be participating on the council in my  
role as Board chair.

Look forward to the upcoming conference call.

Matt Zimmerman

From sebastian.rahtz at oucs.ox.ac.uk  Mon Nov  7 04:03:59 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 07 Nov 2005 09:03:59 +0000
Subject: [tei-council] telcon:@ December 16th
Message-ID: <436F187F.8020902@oucs.ox.ac.uk>

Meetomatic haf spoken. We should meet on December 16th by phone
at 1200 GMT (that is what we agreed?).

Sorry, Matthew, you are the loser on this. But the second alternative
was to lose Christian, and that seemed like a bad idea.

Sebastian

From mjd at hum.ku.dk  Mon Nov  7 04:14:28 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Mon, 07 Nov 2005 10:14:28 +0100
Subject: [tei-council] telcon:@ December 16th
In-Reply-To: <436F187F.8020902@oucs.ox.ac.uk>
Message-ID: <436F2904.27978.696022@localhost>

On the 16th I'll be in Amsterdam (at a conference). Oh well. I'm sure you'll 
manage somehow without me.

MJD

> Meetomatic haf spoken. We should meet on December 16th by phone
> at 1200 GMT (that is what we agreed?).
> 
> Sorry, Matthew, you are the loser on this. But the second alternative
> was to lose Christian, and that seemed like a bad idea.
> 
> Sebastian
> _______________________________________________
> 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 Nov  7 14:40:14 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 7 Nov 2005 14:40:14 -0500
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <4367C7EF.2000806@computing-services.oxford.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>
	<4367AB27.5030107@computing-services.oxford.ac.uk>
	<4367C7EF.2000806@computing-services.oxford.ac.uk>
Message-ID: <17263.44446.140281.141825@emt.wwp.brown.edu>

I think I'd prefer to leave it a string, but this may require more
thought. My current reasoning is as follows.

If the datatype is xsd:string, it is very easy (both technically and
politically) for someone to restrict it to only URIs.

If the datatype is xsd:anyURI, it is easy technically, but possibly
quite difficult politically to expand it to include something that is
not a URI. (And Sebastian's LDAP example is a good one, as is my key
into my EMS Personnel database, which is not available via a URI.)

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Nov  7 19:42:21 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 08 Nov 2005 09:42:21 +0900
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <17263.44446.140281.141825@emt.wwp.brown.edu> (Syd Bauman's
	message of "Mon, 7 Nov 2005 14:40:14 -0500")
References: <4367A955.10605@oucs.ox.ac.uk>
	<4367AB27.5030107@computing-services.oxford.ac.uk>
	<4367C7EF.2000806@computing-services.oxford.ac.uk>
	<17263.44446.140281.141825@emt.wwp.brown.edu>
Message-ID: <ygfwtjkvuky.fsf@chwpb.local>

Syd Bauman <Syd_Bauman at Brown.edu> writes:

> I think I'd prefer to leave it a string, but this may require more
> thought. My current reasoning is as follows.

+1 from me.  

I might construct URI's from @key in my application, but
I would not want them to start their life as such. @key is a string in
my world and I would prefer it to stay such.

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 Nov  7 19:45:08 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 08 Nov 2005 09:45:08 +0900
Subject: [tei-council] telcon:@ December 16th
In-Reply-To: <436F187F.8020902@oucs.ox.ac.uk> (Sebastian Rahtz's message of
	"Mon, 07 Nov 2005 09:03:59 +0000")
References: <436F187F.8020902@oucs.ox.ac.uk>
Message-ID: <ygfslu8vugb.fsf@chwpb.local>

Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> writes:

> Meetomatic haf spoken. We should meet on December 16th by phone
> at 1200 GMT (that is what we agreed?).
>
> Sorry, Matthew, you are the loser on this. But the second alternative
> was to lose Christian, and that seemed like a bad idea.

Thanks for finding out and thanks for not kicking me off.  Yes, we are
supposed to meet at 1200 GMT this time.  We should try to make it not
longer than one hour.

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  Tue Nov  8 05:12:58 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 08 Nov 2005 10:12:58 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <ygfwtjkvuky.fsf@chwpb.local>
References: <4367A955.10605@oucs.ox.ac.uk>	<4367AB27.5030107@computing-services.oxford.ac.uk>	<4367C7EF.2000806@computing-services.oxford.ac.uk>	<17263.44446.140281.141825@emt.wwp.brown.edu>
	<ygfwtjkvuky.fsf@chwpb.local>
Message-ID: <43707A2A.7060302@oucs.ox.ac.uk>

Christian Wittern wrote:
> Syd Bauman <Syd_Bauman at Brown.edu> writes:
> 
> 
>>I think I'd prefer to leave it a string, but this may require more
>>thought. My current reasoning is as follows.
> 
> 
> 
> +1 from me.  
> 
> I might construct URI's from @key in my application, but
> I would not want them to start their life as such. @key is a string in
> my world and I would prefer it to stay such.
> 
> Christian
> 

My reason for making this change is that I want to enable people to do 
things like

<person xml:id="foo">....</person>

<name key="#foo">Mr Phoo</name>

and get some validation. This seems to be highly desirable, especially 
when we have a proper personography in place, and I suspect it will 
become the typical case. After all, it is possible to make almost 
anything into a URL.

To support additionally your requirement for "key" explicitly to point 
to something external and non XML we could do one of the following

-- use another attribute -- but then people have to choose which and we 
risk ambiguity if one points at one thing and the other at another

-- add explicit rules about how a URL is to be constructed from the key 
value, either in P5 or in the document instance

What I don't know for sure is what in principle it means to say
<name key="foo"> where foo is defined as a URL -- it's not a validation 
error, so it may be that we can just say that if the value is like this 
it is an application dependent string just like the old key thing was.

From sebastian.rahtz at oucs.ox.ac.uk  Tue Nov  8 06:08:12 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 08 Nov 2005 11:08:12 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <43707A2A.7060302@oucs.ox.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>	<4367AB27.5030107@computing-services.oxford.ac.uk>	<4367C7EF.2000806@computing-services.oxford.ac.uk>	<17263.44446.140281.141825@emt.wwp.brown.edu>	<ygfwtjkvuky.fsf@chwpb.local>
	<43707A2A.7060302@oucs.ox.ac.uk>
Message-ID: <4370871C.8050501@oucs.ox.ac.uk>

Lou Burnard wrote:

>
> My reason for making this change is that I want to enable people to do
> things like
>
> <person xml:id="foo">....</person>
>
> <name key="#foo">Mr Phoo</name>
>
> and get some validation. 

Hmm.  Who do you think is going to validate this for you? the schema
won't. There are no
link checkers for TEI docs.

I tend towards the mutually exclusive attribute scenario. We use
this somewhere already, I believe.

-- 
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 Nov  8 06:33:41 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 08 Nov 2005 11:33:41 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <43708B63.7000504@oucs.ox.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>	<4367AB27.5030107@computing-services.oxford.ac.uk>	<4367C7EF.2000806@computing-services.oxford.ac.uk>	<17263.44446.140281.141825@emt.wwp.brown.edu>	<ygfwtjkvuky.fsf@chwpb.local>
	<43707A2A.7060302@oucs.ox.ac.uk> <4370871C.8050501@oucs.ox.ac.uk>
	<43708B63.7000504@oucs.ox.ac.uk>
Message-ID: <43708D15.6010500@oucs.ox.ac.uk>

Lou Burnard wrote:

>
> I expect an additional stylesheet to do this for me of course. It's
> utter rubbish to say that there are no link checkers for TEI docs. We
> already use this mechanism all over the place, e.g. to check that
> cross refs  in P5 are valid.

We do, yes, but we don't export that to the punters, or have a mechanism
how they
might run it

>>
>> I tend towards the mutually exclusive attribute scenario. We use
>> this somewhere already, I believe.
>>
>
> That's a possibility I hadn't considered. Anyone else like it?

of course, I may be dreaming about the idea that this is possible!

-- 
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  Tue Nov  8 07:19:59 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 8 Nov 2005 07:19:59 -0500
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <43707A2A.7060302@oucs.ox.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>
	<4367AB27.5030107@computing-services.oxford.ac.uk>
	<4367C7EF.2000806@computing-services.oxford.ac.uk>
	<17263.44446.140281.141825@emt.wwp.brown.edu>
	<ygfwtjkvuky.fsf@chwpb.local> <43707A2A.7060302@oucs.ox.ac.uk>
Message-ID: <17264.38895.855177.462433@emt.wwp.brown.edu>

> <person xml:id="foo">....</person>
> <name key="#foo">Mr Phoo</name>

A quite reasonable desire. But if data.key is declared as xsd:anyURI,
what is the difference between data.key and data.code?

Also, URIs can be a pretty messy way of accessing data, even when it
is available on the web. E.g., the US Library of Congress name
authority records seem to be available on the web. However,

  <name key="000058144">Paul Simon</name>

seems much more robust than

  <name key="http://aleph2.libnet.ac.il/F/MLEYHY17VCMSJLLV4MSBNUPRP2PGRN8L916VGRP7IR4QU8TTXF-23761?func=full-set-set&set_number=055717&set_entry=000001&format=001">Paul
  Simon</name>

> My reason for making this change is that I want to enable people to do 
> things like
> 
> <person xml:id="foo">....</person>
> 
> <name key="#foo">Mr Phoo</name>
> 
> and get some validation. 

BTW, how does one write a simple link-checker for things like this in
Schematron? Anyone know? (You can't use <xsl:key>, I don't think; can
you?) 

> To support additionally your requirement for "key" explicitly to point 
> to something external and non XML we could do one of the following
> 
> -- use another attribute -- but then people have to choose which
>    and we risk ambiguity if one points at one thing and the other 
>    at another

Although we could make the attributes mutually exclusive -- ODD
supports that.

> -- add explicit rules about how a URL is to be constructed from the key 
>    value, either in P5 or in the document instance

I don't understand what you might be getting at, here.

> What I don't know for sure is what in principle it means to say
> <name key="foo"> where foo is defined as a URL -- it's not a
> validation error, so it may be that we can just say that if the
> value is like this it is an application dependent string just like
> the old key thing was.

It means the "rel_path" portion of a URI with value "foo", usually
interpreted by systems to be the file in the same directory with name
"foo".

From sebastian.rahtz at oucs.ox.ac.uk  Tue Nov  8 07:39:41 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 08 Nov 2005 12:39:41 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <17264.38895.855177.462433@emt.wwp.brown.edu>
References: <4367A955.10605@oucs.ox.ac.uk>	<4367AB27.5030107@computing-services.oxford.ac.uk>	<4367C7EF.2000806@computing-services.oxford.ac.uk>	<17263.44446.140281.141825@emt.wwp.brown.edu>	<ygfwtjkvuky.fsf@chwpb.local>
	<43707A2A.7060302@oucs.ox.ac.uk>
	<17264.38895.855177.462433@emt.wwp.brown.edu>
Message-ID: <43709C8D.6010109@oucs.ox.ac.uk>

Syd Bauman wrote:

>><person xml:id="foo">....</person>
>>
>><name key="#foo">Mr Phoo</name>
>>
>>and get some validation. 
>>    
>>
>
>BTW, how does one write a simple link-checker for things like this in
>Schematron? Anyone know? (You can't use <xsl:key>, I don't think; can
>you?) 
>  
>
you can check *this* case, but to be useful you also have to check
<name key="people.xml#foo">, 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

From Syd_Bauman at Brown.edu  Tue Nov  8 07:55:39 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 8 Nov 2005 07:55:39 -0500
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <43709C8D.6010109@oucs.ox.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>
	<4367AB27.5030107@computing-services.oxford.ac.uk>
	<4367C7EF.2000806@computing-services.oxford.ac.uk>
	<17263.44446.140281.141825@emt.wwp.brown.edu>
	<ygfwtjkvuky.fsf@chwpb.local> <43707A2A.7060302@oucs.ox.ac.uk>
	<17264.38895.855177.462433@emt.wwp.brown.edu>
	<43709C8D.6010109@oucs.ox.ac.uk>
Message-ID: <17264.41035.655726.129590@emt.wwp.brown.edu>

Sebastian is quite right, I meant the general case.

> you can check *this* case, but to be useful you also have to check
> <name key="people.xml#foo">, remember

Even this case could be handled by parsing on "#" and using
document() and id(), I think. But I want to be able to validate at
least
  <name key="http://my.names.org/namesFile.xml#foo">
if not
  <name key="http://my.names.org/namesFile.xml?query=foo">
and all sorts of other URIs as well.

From sebastian.rahtz at oucs.ox.ac.uk  Tue Nov  8 08:38:14 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 08 Nov 2005 13:38:14 +0000
Subject: [tei-council] datatypes again: make data.key a URI
In-Reply-To: <17264.41035.655726.129590@emt.wwp.brown.edu>
References: <4367A955.10605@oucs.ox.ac.uk>	<4367AB27.5030107@computing-services.oxford.ac.uk>	<4367C7EF.2000806@computing-services.oxford.ac.uk>	<17263.44446.140281.141825@emt.wwp.brown.edu>	<ygfwtjkvuky.fsf@chwpb.local>
	<43707A2A.7060302@oucs.ox.ac.uk>	<17264.38895.855177.462433@emt.wwp.brown.edu>	<43709C8D.6010109@oucs.ox.ac.uk>
	<17264.41035.655726.129590@emt.wwp.brown.edu>
Message-ID: <4370AA46.7060607@oucs.ox.ac.uk>

Syd Bauman wrote

> But I want to be able to validate at
>least
>  <name key="http://my.names.org/namesFile.xml#foo">
>if not
>  <name key="http://my.names.org/namesFile.xml?query=foo">
>and all sorts of other URIs as well.
>
>  
>
that's what I meant when I said to Lou that we have no general-purpose
link checker
for TEI documents, I now realize. If it was HTML, you'd just ask the W3C
checker to hoover
it 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 lou.burnard at computing-services.oxford.ac.uk  Tue Nov  8 16:21:37 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 08 Nov 2005 21:21:37 +0000
Subject: [tei-council] versificatory matters
Message-ID: <437116E1.9010209@computing-services.oxford.ac.uk>

I believe we have decided to abolish the numbered variants on <lg> 
provided by the chapter for verse (<lg1>, <lg2> etc.) in P5 but I can't 
find any written record of this eminently sensible decision. Before I 
set to  wielding my editing axe on this topic (treated somewhat skimpily 
but not insubstantially in chapter VE), does anyone wish to put in a 
last minute plea for a reprieve?

While thinking about verse, I would also like to sneak in a new element 
which should have been there all along: <rhyme>. This will be a phrase 
level element used to delimit the rhyming word/s of a line. It will have 
an attribute LABEL  to identify which bit of  the rhyme scheme (e.g. the 
a or b) this rhyming word instantiates and possibly TYPE to indicate 
what sort of a rhyme this is (e.g. full, partial, etc)

<l>Come now you men of wives <rhyme label="b">intellectual</rhyme></l>
<l>Confess, have they not <rhyme label="b" type="awful">hen-pecked you 
all</rhyme>?</l>

(Byron: Don Juan, from memory)

p.s. I claim no originality for this idea, having nicked it from Wendell 
Piez's charming sonnet site, 
http://sonneteer.xmlshoestring.com/sonneteer/index.xml

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Nov  8 20:34:42 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 09 Nov 2005 10:34:42 +0900
Subject: Personography discussion (was: Re: [tei-council] datatypes again:
	make data.key a URI)
In-Reply-To: <17264.41035.655726.129590@emt.wwp.brown.edu> (Syd Bauman's
	message of "Tue, 8 Nov 2005 07:55:39 -0500")
References: <4367A955.10605@oucs.ox.ac.uk>
	<4367AB27.5030107@computing-services.oxford.ac.uk>
	<4367C7EF.2000806@computing-services.oxford.ac.uk>
	<17263.44446.140281.141825@emt.wwp.brown.edu>
	<ygfwtjkvuky.fsf@chwpb.local> <43707A2A.7060302@oucs.ox.ac.uk>
	<17264.38895.855177.462433@emt.wwp.brown.edu>
	<43709C8D.6010109@oucs.ox.ac.uk>
	<17264.41035.655726.129590@emt.wwp.brown.edu>
Message-ID: <ygf1x1qhadp.fsf_-_@kanji.zinbun.kyoto-u.ac.jp>

Syd Bauman <Syd_Bauman at Brown.edu> writes:

>> <name key="people.xml#foo">, remember
>
> Even this case could be handled by parsing on "#" and using
> document() and id(), I think. But I want to be able to validate at
> least
>   <name key="http://my.names.org/namesFile.xml#foo">
> if not
>   <name key="http://my.names.org/namesFile.xml?query=foo">
> and all sorts of other URIs as well.

And this is were I think it really gets silly.  Who wants to have to
put full-blown URIs at every name occurrence?  It seems to me, we
should at least have a mechanism to put everything except the query
string somewhere in the header and let @key just provide the query
string or #anchor.  Such a mechanism would also be useful for other
cases, for example in @ref at <g>.

For what its worth, I think now that we should defer a decision on
this to the general personography discussion.  On that topic, Lou
agreed to provide a draft working paper that could serve as a base for
the discussion at a face-to-face meeting by the end of the year.  Are
there other suggestions on how to proceed on this item?  

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 Nov  8 20:42:36 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 09 Nov 2005 10:42:36 +0900
Subject: [tei-council] versificatory matters
In-Reply-To: <437116E1.9010209@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Tue, 08 Nov 2005 21:21:37 +0000")
References: <437116E1.9010209@computing-services.oxford.ac.uk>
Message-ID: <ygfwtjifvg3.fsf@kanji.zinbun.kyoto-u.ac.jp>

Lou Burnard <lou.burnard at computing-services.oxford.ac.uk> writes:

> I believe we have decided to abolish the numbered variants on <lg>
> provided by the chapter for verse (<lg1>, <lg2> etc.) in P5 but I
> can't find any written record of this eminently sensible
> decision. 

I think it is at
http://www.tei-c.org.uk/Council/tcm17.xml?style=printable in item 7.7,
second paragraph.

> Before I set to  wielding my editing axe on this topic
> (treated somewhat skimpily but not insubstantially in chapter VE),
> does anyone wish to put in a last minute plea for a reprieve?

Not here, I have never used one and have seen them gone long ago. 

>
> While thinking about verse, I would also like to sneak in a new
> element which should have been there all along: <rhyme>. This will be
> a phrase level element used to delimit the rhyming word/s of a
> line. It will have an attribute LABEL  to identify which bit of  the
> rhyme scheme (e.g. the a or b) this rhyming word instantiates and
> possibly TYPE to indicate what sort of a rhyme this is (e.g. full,
> partial, etc)

I like the idea. Does this mean the <rhyme> is valid outside <l> as well?
BTW, some of my recent ODDs oddly did not allow nested <lg>s. While
you are at it, could you please check if that is a bug in P5? 

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 Nov  8 20:46:47 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 8 Nov 2005 20:46:47 -0500
Subject: Personography discussion (was: Re: [tei-council] datatypes again:
	make data.key a URI)
In-Reply-To: <ygf1x1qhadp.fsf_-_@kanji.zinbun.kyoto-u.ac.jp>
References: <4367A955.10605@oucs.ox.ac.uk>
	<4367AB27.5030107@computing-services.oxford.ac.uk>
	<4367C7EF.2000806@computing-services.oxford.ac.uk>
	<17263.44446.140281.141825@emt.wwp.brown.edu>
	<ygfwtjkvuky.fsf@chwpb.local> <43707A2A.7060302@oucs.ox.ac.uk>
	<17264.38895.855177.462433@emt.wwp.brown.edu>
	<43709C8D.6010109@oucs.ox.ac.uk>
	<17264.41035.655726.129590@emt.wwp.brown.edu>
	<ygf1x1qhadp.fsf_-_@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <17265.21767.161741.827152@emt.wwp.brown.edu>

> It seems to me, we should at least have a mechanism to put
> everything except the query string somewhere in the header and let
> @key just provide the query string or #anchor. Such a mechanism
> would also be useful for other cases, for example in @ref at <g>.

Indeed. We already have the mechanism, but currently it is a
special-purpose mechanism for canonical references. We may want to
consider expanding it, but that's potentially a big discussion ...

From mjd at hum.ku.dk  Wed Nov  9 02:53:40 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Wed, 09 Nov 2005 08:53:40 +0100
Subject: [tei-council] versificatory matters
In-Reply-To: <437116E1.9010209@computing-services.oxford.ac.uk>
Message-ID: <4371B914.31481.1FA1E6@localhost>

This could presumably also be used for alliteration ("stave-rhyme"), a 
prominent feature of Germanic verse, incl. Old and Middle English, could it 
not?

<line><rhyme type="allit">Hige</ryhme> sceal þe <rhyme 
type="allit">heardra</rhyme> <caesura/> <rhyme type="allit">heorte</rhyme> 
þe cenre</line>
<line><rhyme type="allit">mod</rhyme> sceal þe <rhyme 
type="allit">mare</rhyme> <caesura/> þe ure <rhyme 
type="allit">mægen</rhyme> lytlað</line>

[from The Battle of Maldon]

Now if we just had a good way of dealing with kennings.

MJD

> While thinking about verse, I would also like to sneak in a new element 
> which should have been there all along: <rhyme>. This will be a phrase 
> level element used to delimit the rhyming word/s of a line. It will have 
> an attribute LABEL  to identify which bit of  the rhyme scheme (e.g. the 
> a or b) this rhyming word instantiates and possibly TYPE to indicate 
> what sort of a rhyme this is (e.g. full, partial, etc)
> 
> <l>Come now you men of wives <rhyme label="b">intellectual</rhyme></l>
> <l>Confess, have they not <rhyme label="b" type="awful">hen-pecked you 
> all</rhyme>?</l>
> 
> (Byron: Don Juan, from memory)
> 
> p.s. I claim no originality for this idea, having nicked it from Wendell 
> Piez's charming sonnet site, 
> http://sonneteer.xmlshoestring.com/sonneteer/index.xml
> 
> 
> _______________________________________________
> 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  Wed Nov  9 03:38:29 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Wed, 09 Nov 2005 09:38:29 +0100
Subject: [tei-council] versificatory matters
In-Reply-To: <437116E1.9010209@computing-services.oxford.ac.uk>
Message-ID: <4371C395.16501.48A692@localhost>

By the way, it's:

But - Oh! ye lords of ladies intellectual, 
Inform us truly, have they not hen-peck'd you all?
(Don Juan, Canto I, stanza 22)

Only one of many truly awful rhymes in that poem.

MJD

> 
> <l>Come now you men of wives <rhyme label="b">intellectual</rhyme></l>
> <l>Confess, have they not <rhyme label="b" type="awful">hen-pecked you 
> all</rhyme>?</l>
> 
> (Byron: Don Juan, from memory)

From mjd at hum.ku.dk  Wed Nov  9 06:45:26 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Wed, 09 Nov 2005 12:45:26 +0100
Subject: [tei-council] Kennings
Message-ID: <4371EF66.348.F3D032@localhost>

Since I brought up the subject perhaps I should explain a bit more about what I 
mean concerning kennings.

Kennings are metaphorical compounds extensively used in early Germanic poetry, 
like hronrade, lit. "whale-road", meaning "sea", in line 10 of Beowulf.

Like so many other things, kennings really came into their own in Icelandic 
literature, first in skaldic poetry, subsequently in r?mur or metrical 
romances.

Take a simple kenning for a woman, seima-Gn?, consisting of the the genitive 
plural of seimur ("gold") plus the name of the goddess Gn?. I've been marking 
this up using <seg>, as in the following example:

<seg type="kenning">
<seg function="determinant">seima</seg>
<seg function="base">Gná</seg>
</seg>

The Sydney-based skaldic poetry project has, I know, introduced specialised 
elements for these things, so their markup of this same kenning would be:

<kenning referent="woman">
<det>seima</det>
<bw>Gná</bw>
</kenning>

A better (and more general) solution could certainly be found, however. And 
besides, this only really works if the parts of the kenning are next to each 
other and don't overlap with other kennings (as they frequently do in skaldic 
poetry).

Any ideas?

Matthew

From James.Cummings at computing-services.oxford.ac.uk  Wed Nov  9 07:07:20 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 09 Nov 2005 12:07:20 +0000
Subject: [tei-council] versificatory matters
In-Reply-To: <4371B914.31481.1FA1E6@localhost>
References: <4371B914.31481.1FA1E6@localhost>
Message-ID: <4371E678.9040104@computing-services.oxford.ac.uk>

M. J. Driscoll wrote:
> This could presumably also be used for alliteration ("stave-rhyme"), a 
> prominent feature of Germanic verse, incl. Old and Middle English, could it 
> not?
> 
> <line><rhyme type="allit">Hige</ryhme> sceal þe <rhyme 
> type="allit">heardra</rhyme> <caesura/> <rhyme type="allit">heorte</rhyme> 
> þe cenre</line>
> <line><rhyme type="allit">mod</rhyme> sceal þe <rhyme 
> type="allit">mare</rhyme> <caesura/> þe ure <rhyme 
> type="allit">mægen</rhyme> lytlað</line>
> 
> [from The Battle of Maldon]
> 
> Now if we just had a good way of dealing with kennings.

I've been reading the various suggestions for the <rhyme> element with interest.
One of my concerns is that as soon as we simply depart from indicating a general
rhyme scheme on the <lg> is that we enter into the realm of possibly marking up
all sorts of complicated rhetorical tropes and schemes.  Fair enough, for it to
be envisioned as a simple <rhyme label="a">, and I have no problem with the
'a'-ness of that being determined by its ancestral <lg>.  In fact, in recently
producing some word indexes and tables of rhyme-words, etc. from some medieval
psalters for a project, I could have used just this structure rather than the
cobbled together <seg>s that I did.

My worry is that people won't just limit it to simple straightforward rhymes in
the modern concept, but other rhetorical structures (such as Matthew's
alliteration example) which become increasingly complex or interlinear.  The
reason this worries me is there are some rhetorical structures out there that
seem quite complicated and that this might find itself being co-opted for lots
of other (ab)uses.  I'm happy to agree that having <rhyme> is a good thing, but
perhaps if we are going to add it, we should maybe look again at marking all
sorts of other rhetorical structures to see if there are some more general
elements.  These can, I think, generally be done with existing TEI elements but
if there is a more general solution which works for rhymes and as well as other
similar things, then that would seem like a good idea.

Just my initial thoughts, this time at least not from a pub in Sofia.

-James

From Laurent.Romary at loria.fr  Wed Nov  9 08:26:37 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Wed, 9 Nov 2005 14:26:37 +0100
Subject: Personography discussion (was: Re: [tei-council] datatypes again:
	make data.key a URI)
In-Reply-To: <ygf1x1qhadp.fsf_-_@kanji.zinbun.kyoto-u.ac.jp>
References: <4367A955.10605@oucs.ox.ac.uk>
	<4367AB27.5030107@computing-services.oxford.ac.uk>
	<4367C7EF.2000806@computing-services.oxford.ac.uk>
	<17263.44446.140281.141825@emt.wwp.brown.edu>
	<ygfwtjkvuky.fsf@chwpb.local> <43707A2A.7060302@oucs.ox.ac.uk>
	<17264.38895.855177.462433@emt.wwp.brown.edu>
	<43709C8D.6010109@oucs.ox.ac.uk>
	<17264.41035.655726.129590@emt.wwp.brown.edu>
	<ygf1x1qhadp.fsf_-_@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <159AD302-CBF6-4CDA-8B56-B013B325B2D9@loria.fr>

Hi,
Am I being stupid or is it just the purpose of the W3C xml:base  
attribute? We could integrate it into P5, couldn't we?
Best,
Laurent

Le 9 nov. 05 ? 02:34, Christian Wittern a ?crit :

> Syd Bauman <Syd_Bauman at Brown.edu> writes:
>
>
>>> <name key="people.xml#foo">, remember
>>>
>>
>> Even this case could be handled by parsing on "#" and using
>> document() and id(), I think. But I want to be able to validate at
>> least
>>   <name key="http://my.names.org/namesFile.xml#foo">
>> if not
>>   <name key="http://my.names.org/namesFile.xml?query=foo">
>> and all sorts of other URIs as well.
>>
>
> And this is were I think it really gets silly.  Who wants to have to
> put full-blown URIs at every name occurrence?  It seems to me, we
> should at least have a mechanism to put everything except the query
> string somewhere in the header and let @key just provide the query
> string or #anchor.  Such a mechanism would also be useful for other
> cases, for example in @ref at <g>.
>
> For what its worth, I think now that we should defer a decision on
> this to the general personography discussion.  On that topic, Lou
> agreed to provide a draft working paper that could serve as a base for
> the discussion at a face-to-face meeting by the end of the year.  Are
> there other suggestions on how to proceed on this item?
>
> 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
>
>

From sebastian.rahtz at oucs.ox.ac.uk  Wed Nov  9 08:35:27 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 09 Nov 2005 13:35:27 +0000
Subject: [tei-council] Re: Personography discussion
In-Reply-To: <159AD302-CBF6-4CDA-8B56-B013B325B2D9@loria.fr>
References: <4367A955.10605@oucs.ox.ac.uk>	<4367AB27.5030107@computing-services.oxford.ac.uk>	<4367C7EF.2000806@computing-services.oxford.ac.uk>	<17263.44446.140281.141825@emt.wwp.brown.edu>	<ygfwtjkvuky.fsf@chwpb.local>
	<43707A2A.7060302@oucs.ox.ac.uk>	<17264.38895.855177.462433@emt.wwp.brown.edu>	<43709C8D.6010109@oucs.ox.ac.uk>	<17264.41035.655726.129590@emt.wwp.brown.edu>	<ygf1x1qhadp.fsf_-_@kanji.zinbun.kyoto-u.ac.jp>
	<159AD302-CBF6-4CDA-8B56-B013B325B2D9@loria.fr>
Message-ID: <4371FB1F.7060802@oucs.ox.ac.uk>

Laurent Romary wrote:

> Hi,
> Am I being stupid or is it just the purpose of the W3C xml:base 
> attribute? We could integrate it into P5, couldn't we?

xml:base would typically apply to links in the  whole document. these
person links are
just one small section.

of course, Christian can always use #foo to point to a section in the
header which points
to a further URL if desired.

but I agree with Christian's conclusion that decision on this should be
delayed and form
part of the agenda for a personography meeting. Apropos of which, I will
be working from
January for a short time each week on a TEI version of a name-related
project, and I'd really like
it if we could  make this a big focus of work in 2006 Q1. It does not
seem beyond the bounds
of possibility to get all the work done in time to review at  a council
meeting in May.

-- 
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  Wed Nov  9 09:08:03 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 09 Nov 2005 14:08:03 +0000
Subject: [tei-council] Re: Personography discussion
In-Reply-To: <4371FB1F.7060802@oucs.ox.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>	<4367AB27.5030107@computing-services.oxford.ac.uk>	<4367C7EF.2000806@computing-services.oxford.ac.uk>	<17263.44446.140281.141825@emt.wwp.brown.edu>	<ygfwtjkvuky.fsf@chwpb.local>	<43707A2A.7060302@oucs.ox.ac.uk>	<17264.38895.855177.462433@emt.wwp.brown.edu>	<43709C8D.6010109@oucs.ox.ac.uk>	<17264.41035.655726.129590@emt.wwp.brown.edu>	<ygf1x1qhadp.fsf_-_@kanji.zinbun.kyoto-u.ac.jp>	<159AD302-CBF6-4CDA-8B56-B013B325B2D9@loria.fr>
	<4371FB1F.7060802@oucs.ox.ac.uk>
Message-ID: <437202C3.7030204@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> of course, Christian can always use #foo to point to a section in the
> header which points
> to a further URL if desired.

I like that method generally for other things, but you don't necessarily
want to do that with @key do you?  Wouldn't that necessitate sections in
the header for every @key? Or all of them being the same?

> but I agree with Christian's conclusion that decision on this should be
> delayed and form
> part of the agenda for a personography meeting. Apropos of which, I will
> be working from
> January for a short time each week on a TEI version of a name-related
> project, and I'd really like
> it if we could  make this a big focus of work in 2006 Q1. It does not
> seem beyond the bounds
> of possibility to get all the work done in time to review at  a council
> meeting in May.

Have we settled on who/where/when of this personography meeting?

-James

From sebastian.rahtz at oucs.ox.ac.uk  Wed Nov  9 09:14:53 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 09 Nov 2005 14:14:53 +0000
Subject: [tei-council] Re: Personography discussion
In-Reply-To: <437202C3.7030204@computing-services.oxford.ac.uk>
References: <4367A955.10605@oucs.ox.ac.uk>	<4367AB27.5030107@computing-services.oxford.ac.uk>	<4367C7EF.2000806@computing-services.oxford.ac.uk>	<17263.44446.140281.141825@emt.wwp.brown.edu>	<ygfwtjkvuky.fsf@chwpb.local>	<43707A2A.7060302@oucs.ox.ac.uk>	<17264.38895.855177.462433@emt.wwp.brown.edu>	<43709C8D.6010109@oucs.ox.ac.uk>	<17264.41035.655726.129590@emt.wwp.brown.edu>	<ygf1x1qhadp.fsf_-_@kanji.zinbun.kyoto-u.ac.jp>	<159AD302-CBF6-4CDA-8B56-B013B325B2D9@loria.fr>	<4371FB1F.7060802@oucs.ox.ac.uk>
	<437202C3.7030204@computing-services.oxford.ac.uk>
Message-ID: <4372045D.8090400@oucs.ox.ac.uk>

James Cummings wrote:

>I like that method generally for other things, but you don't necessarily
>want to do that with @key do you?  Wouldn't that necessitate sections in
>the header for every @key? Or all of them being the same?
>  
>
I may be talking rubbish. needs  a whiteboard and a cup of tea to sort
out what I mean

>Have we settled on who/where/when of this personography meeting?
>  
>
none of the above, SFAIK

my default assumptions are

 - 6-8 people, half from here, half external experts
 - London
 - 1st week of February

which members of the Council would expect to be at such a meeting? and who
has suggestions for external folk? I'll correlate, if desired.

-- 
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 Nov  9 09:22:23 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Wed, 9 Nov 2005 09:22:23 -0500
Subject: Personography discussion (was: Re: [tei-council] datatypes again:
	make data.key a URI)
In-Reply-To: <159AD302-CBF6-4CDA-8B56-B013B325B2D9@loria.fr>
References: <4367A955.10605@oucs.ox.ac.uk>
	<4367AB27.5030107@computing-services.oxford.ac.uk>
	<4367C7EF.2000806@computing-services.oxford.ac.uk>
	<17263.44446.140281.141825@emt.wwp.brown.edu>
	<ygfwtjkvuky.fsf@chwpb.local> <43707A2A.7060302@oucs.ox.ac.uk>
	<17264.38895.855177.462433@emt.wwp.brown.edu>
	<43709C8D.6010109@oucs.ox.ac.uk>
	<17264.41035.655726.129590@emt.wwp.brown.edu>
	<ygf1x1qhadp.fsf_-_@kanji.zinbun.kyoto-u.ac.jp>
	<159AD302-CBF6-4CDA-8B56-B013B325B2D9@loria.fr>
Message-ID: <17266.1567.236846.500723@emt.wwp.brown.edu>

> Am I being stupid or is it just the purpose of the W3C xml:base
> attribute? We could integrate it into P5, couldn't we? 

Well, xml:base= is somewhat helpful, but doesn't really solve the
problem, as it applies to *all* pointer attributes.

  <p xml:base="long://initial.url.path/here/">
    I would like to say that <name key="#LR">Laurent</name> is
    a great guy. Proof can be found
    <ref target="worse://super.long.url/path/here.xml">here</ref>
  </p>

What we'd really like is a way of saying "this is the base URI for
all key= attributes, but not others".

From James.Cummings at computing-services.oxford.ac.uk  Wed Nov  9 09:47:32 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Wed, 09 Nov 2005 14:47:32 +0000
Subject: [tei-council] Re: Personography discussion
In-Reply-To: <17266.1567.236846.500723@emt.wwp.brown.edu>
References: <4367A955.10605@oucs.ox.ac.uk>	<4367AB27.5030107@computing-services.oxford.ac.uk>	<4367C7EF.2000806@computing-services.oxford.ac.uk>	<17263.44446.140281.141825@emt.wwp.brown.edu>	<ygfwtjkvuky.fsf@chwpb.local>
	<43707A2A.7060302@oucs.ox.ac.uk>	<17264.38895.855177.462433@emt.wwp.brown.edu>	<43709C8D.6010109@oucs.ox.ac.uk>	<17264.41035.655726.129590@emt.wwp.brown.edu>	<ygf1x1qhadp.fsf_-_@kanji.zinbun.kyoto-u.ac.jp>	<159AD302-CBF6-4CDA-8B56-B013B325B2D9@loria.fr>
	<17266.1567.236846.500723@emt.wwp.brown.edu>
Message-ID: <43720C04.2020505@computing-services.oxford.ac.uk>

Syd Bauman wrote:
>>Am I being stupid or is it just the purpose of the W3C xml:base
>>attribute? We could integrate it into P5, couldn't we? 
> 
> 
> Well, xml:base= is somewhat helpful, but doesn't really solve the
> problem, as it applies to *all* pointer attributes.
> 
>   <p xml:base="long://initial.url.path/here/">
>     I would like to say that <name key="#LR">Laurent</name> is
>     a great guy. Proof can be found
>     <ref target="worse://super.long.url/path/here.xml">here</ref>
>   </p>
> 
> What we'd really like is a way of saying "this is the base URI for
> all key= attributes, but not others".

Is the only way to have all key attributes _be understood to_ point to a
specific place in the header, and that place have an xml:base ?  Would that
actually work?  (And then how does one do this if we want to have keys in
multiple external sources?, etc.)

Is there a RelaxNG way to validate such a thing?

I agree that this definitely needs more thought.  However, if a general solution
is found, it could apply to a lot more than the personographies, couldn't it?

-James

From sebastian.rahtz at oucs.ox.ac.uk  Wed Nov  9 11:44:20 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 09 Nov 2005 16:44:20 +0000
Subject: [tei-council] personography task force
Message-ID: <43722764.7040505@oucs.ox.ac.uk>

some of you are sending me names and volunteering to discuss
personography. It is already
clear that there are at least 8 people on the council alone who want to
take part.

There are 3 ways to proceed:

 a) make it a council subset meeting
 b) elect a leader who will invite his/her best shots and sorry, being
on the council doesn't guarentee you a seat
 c) invite all and sundry (ie TEI-L) to make a pitch as to why they
should take part, and pick the
    8 candidates who make the most convincing case (to be judged by
Christian)

views?

-- 
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 Nov 10 23:09:36 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 11 Nov 2005 13:09:36 +0900
Subject: [tei-council] personography task force
In-Reply-To: <43722764.7040505@oucs.ox.ac.uk> (Sebastian Rahtz's message of
	"Wed, 09 Nov 2005 16:44:20 +0000")
References: <43722764.7040505@oucs.ox.ac.uk>
Message-ID: <ygfek5nu8ov.fsf@chwpb.local>

Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> writes:

> some of you are sending me names and volunteering to discuss
> personography. It is already
> clear that there are at least 8 people on the council alone who want to
> take part.

This seems to be a hot topic at the moment.

> There are 3 ways to proceed:
>
>  a) make it a council subset meeting
>  b) elect a leader who will invite his/her best shots and sorry, being
> on the council doesn't guarentee you a seat
>  c) invite all and sundry (ie TEI-L) to make a pitch as to why they
> should take part, and pick the
>     8 candidates who make the most convincing case (to be judged by
> Christian)
>
> views?

Well, the more I think of it the less I like to hurry this through.  I
would propose a two-layered approach:

1) For the things that need immediate fix in P5 (e.g. datatypes et.al)
   Lou promised to write a position paper by the end of the year.
   This could serve as a base for decisions in a tight time-frame. 
   personography per se would be out of scope for this.

2) We encourage all those interested in this to immediately start
   experimenting by creating extensions that do what people want to do
   with these persons.  It would also sensible to form a SIG and encourage
   communication there.  After a while (6, 12 months?) we look
   at the output of this group and decide whether to charge a more
   formal work group or let the SIG continue or have a one-off,
   focused meeting on a defined range of topics to iron out some open
   points.

This could be seen as a testbed for future development in the TEI -
more community based, less relying on an inner circle of all-round
experts.  I think it is also a Good Thing (tm) to do standardization
based on existing implementation and praxis, rather than out-of-the-blue.

comments? views?

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 Nov 11 04:48:19 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 11 Nov 2005 09:48:19 +0000
Subject: [tei-council] personography task force
In-Reply-To: <ygfek5nu8ov.fsf@chwpb.local>
References: <43722764.7040505@oucs.ox.ac.uk> <ygfek5nu8ov.fsf@chwpb.local>
Message-ID: <437468E3.5010009@oucs.ox.ac.uk>

Christian Wittern wrote:

>Well, the more I think of it the less I like to hurry this through. 
>
My reaction is opposite, curiously. The more I think of it
the more I want it looked at now :-}

>1) For the things that need immediate fix in P5 (e.g. datatypes et.al)
>   Lou promised to write a position paper by the end of the year.
>   This could serve as a base for decisions in a tight time-frame. 
>   personography per se would be out of scope for this.
>  
>
That depends on the scope of what Lou proposes to write
about. Just datatypes is not enough. I don't think we should
persist for another year with anomalies like half the personography
elements being in corpus, for example, and the lack of a death

>2) We encourage all those interested in this to immediately start
>   experimenting by creating extensions that do what people want to do
>   with these persons.  It would also sensible to form a SIG and encourage
>   communication there. 
>
It's not practical to unilaterally form a SIG. Without leadership,
nothing happens; if there is a leader, we can ask them to form a WG

>This could be seen as a testbed for future development in the TEI -
>more community based, less relying on an inner circle of all-round
>experts.  I think it is also a Good Thing (tm) to do standardization
>based on existing implementation and praxis, rather than out-of-the-blue.
>  
>
In some ways, yes. The standardization process should
be based on existing practice, and on a broad input, not
experts dictating future directions. But that's how the TEI
_does_ work: we charter a group, appoint a leader, let current
practitioner parties join, and moderate it with the elected council.

My view is that names/dates/places is an extremely widely practised thing
already, and we can see plenty of examples already, some based on the 
TEI like
those inscriptionists in Sofia, some very loosely related, like DDI, and 
some
new inventions like HEML. We don't need more experimentation, now _is_
the time for the TEI to crystallize practice - I think we are now at the 
stage
you propose for 12 months from now.

Sebastian

From lou.burnard at computing-services.oxford.ac.uk  Fri Nov 11 05:17:11 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 11 Nov 2005 10:17:11 +0000
Subject: [tei-council] personography task force
In-Reply-To: <437468E3.5010009@oucs.ox.ac.uk>
References: <43722764.7040505@oucs.ox.ac.uk> <ygfek5nu8ov.fsf@chwpb.local>
	<437468E3.5010009@oucs.ox.ac.uk>
Message-ID: <43746FA7.9020909@computing-services.oxford.ac.uk>

Just to clarify on my current commitments...

1. Classes

In Bulgaria, Syd and I agreed to divide the task of implementing the 
Oxford decisions between us. I have done my half, and Syd (witness 
recent email) has started on his. We hope to have the whole lot done by 
the end of November.

2. Structure chapter (ST)

I want to make a serious attempt at defining a new organization for this 
chapter. Every time a change is made to the class system, this chapter 
has to be edited, which is one reason why I have been putting the job 
off, but it remains, I think, more urgent than anything else. I will 
work on that during December.

3. Personography rationalization.

I have already done some minor spadework on this, in revising the parts 
of CO which talk about names. I would like to build on this revision, 
with the aim of producing a new section synthesizing what is currently 
treated in ND and in CC, for the Council to review in January. Let me 
stress that my intention is not to revisit the whole question of 
personal identity, but simply to synthesize what is already present in 
different parts of the Guidelines into an accessible and useful set of 
recommendations.

Lou

Sebastian Rahtz wrote:

>> 1) For the things that need immediate fix in P5 (e.g. datatypes et.al)
>>   Lou promised to write a position paper by the end of the year.
>>   This could serve as a base for decisions in a tight time-frame.   
>> personography per se would be out of scope for this.
>>  
>>
> That depends on the scope of what Lou proposes to write
> about. Just datatypes is not enough. I don't think we should
> persist for another year with anomalies like half the personography
> elements being in corpus, for example, and the lack of a death
> 
>

From James.Cummings at computing-services.oxford.ac.uk  Fri Nov 11 06:30:11 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Fri, 11 Nov 2005 11:30:11 +0000 (GMT)
Subject: [tei-council] photos
Message-ID: <20051111113012.4058422677@webmail219.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/20051111/76870aa9/attachment.ksh 

From sebastian.rahtz at oucs.ox.ac.uk  Sun Nov 13 06:56:21 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 13 Nov 2005 11:56:21 +0000
Subject: [tei-council] @TEIform
Message-ID: <437729E5.80808@oucs.ox.ac.uk>

As you all know, any TEI schema or DTD has an attribute "TEIform" for
every element.
It contains the name of the element, and is there to help you
reconstruct documents
where the element name has changed.

We now know how to do this better by reference back to the ODD source,
which also covers attribute names.

Hands up all those who would be willing to quietly drop this dinosaur
artefact?

-- 
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 Nov 13 07:03:51 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 13 Nov 2005 12:03:51 +0000
Subject: [tei-council] numbered divs
Message-ID: <43772BA7.9010202@oucs.ox.ac.uk>

You'll recall the growing movement to kill the numbered <divN> elements.
Some suggest that they be made optional, in their own module.

Experimenting with this makes me realize that it cannot easily work,
because of the way we construct content models. We say (simplified):
(
    div
    (div | global)*
|
    div1
    (div1 | global)*
)

ie if you start with <div>, you cannot lurch off  into <div1>

If  we now delete div1, we get
(
    div
    (div | global)*
|
    (global)*
)

which is ambiguous in DTDs (and W3C schemas, I think)

Of course, you should say  I should detect this in the ODD processing,
and zap the extra "| (global)*", but
thats not at all easy.

if we said
(
    div | div1
    ( div | div1 | global)*
)

the problem would go away, at the cost of allowing the absurdity of

 <div1>
 </div1>
 <div>
 </div>

does anyone feel that the looseness of this is unacceptable?

-- 
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 Nov 13 07:24:04 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 13 Nov 2005 07:24:04 -0500
Subject: [tei-council] @TEIform
In-Reply-To: <437729E5.80808@oucs.ox.ac.uk>
References: <437729E5.80808@oucs.ox.ac.uk>
Message-ID: <17271.12388.679670.972562@emt.wwp.brown.edu>

> Hands up all those who would be willing to quietly drop this
> dinosaur artefact?

As one who has had trouble seeing what value TEIform= brings to the
TEI scheme since late 2003 or some such, I'm all in favor of dropping
this attribute with a loud "thud".

From Syd_Bauman at Brown.edu  Sun Nov 13 07:26:44 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 13 Nov 2005 07:26:44 -0500
Subject: [tei-council] @TEIform
In-Reply-To: <17271.12388.679670.972562@emt.wwp.brown.edu>
References: <437729E5.80808@oucs.ox.ac.uk>
	<17271.12388.679670.972562@emt.wwp.brown.edu>
Message-ID: <17271.12548.977221.416176@emt.wwp.brown.edu>

> As one who has had trouble seeing what value TEIform= brings to the
> TEI scheme ...

I should have been more specific -- "to the TEI P5 scheme".

Obviously shouldn't remove TEIform= from P4.  :-)

From Syd_Bauman at Brown.edu  Sun Nov 13 07:40:04 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 13 Nov 2005 07:40:04 -0500
Subject: [tei-council] numbered divs
In-Reply-To: <43772BA7.9010202@oucs.ox.ac.uk>
References: <43772BA7.9010202@oucs.ox.ac.uk>
Message-ID: <17271.13348.990964.718256@emt.wwp.brown.edu>

> does anyone feel that the looseness of this is unacceptable?

Yes, completely.

On the other hand, you voiced in earlier mail (not to the list) the
thought of further constraining this back to "only numbered OR only
un-numbered" with a Schematron rule. This may not be so terrible,
depending on what our end position is on the use of Schematron.

The general problem is that dropping all members of a class may make
some content models ambiguous in DTD (and maybe W3C) land.

I think it is important to seriously investigate the dummy-element
insertion idea, which could solve this general problem, not just this
instance. This is the idea that whenever the odd2dtd processor comes
across an empty class, it populates that class with one element
<dummy-do-not-use>. In DTDs this element wouldn't even be declared
(and thus, regular DTD validation should flag an occurrence of it as
an error in an instance). In any case (RelaxNG, DTD, W3C Schema), a
very simple additional Schematron rule would flag all
<dummy-do-not-use> elements as errors (following is untested
off-the-top-of-my-head):

  <s:pattern name="No dummy elements permitted">
    <s:rule context="tei:dummy-do-not-use">
      <s:report test="tei:dummy-do-not-use">
        The <dummy-do-not-use> element should never be used. For the technical
        explanation of why this element exists see XXXX.
      </s:report>
    </s:rule>
  </s:pattern>

From sschreib at umd.edu  Sun Nov 13 08:11:09 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Sun, 13 Nov 2005 08:11:09 -0500
Subject: [tei-council] @TEIform
In-Reply-To: <437729E5.80808@oucs.ox.ac.uk>
References: <437729E5.80808@oucs.ox.ac.uk>
Message-ID: <43773B6D.5080204@umd.edu>

I've always wondered why it was there and never used it -- I'd be in 
favor of dropping it

susan

Sebastian Rahtz wrote:

>As you all know, any TEI schema or DTD has an attribute "TEIform" for
>every element.
>It contains the name of the element, and is there to help you
>reconstruct documents
>where the element name has changed.
>
>We now know how to do this better by reference back to the ODD source,
>which also covers attribute names.
>
>Hands up all those who would be willing to quietly drop this dinosaur
>artefact?
>
>  
>

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742

Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib at umd.edu

From Laurent.Romary at loria.fr  Sun Nov 13 09:44:48 2005
From: Laurent.Romary at loria.fr (Laurent.Romary at loria.fr)
Date: Sun, 13 Nov 2005 15:44:48 +0100
Subject: [tei-council] @TEIform
In-Reply-To: <437729E5.80808@oucs.ox.ac.uk>
References: <437729E5.80808@oucs.ox.ac.uk>
Message-ID: <1131893088.43775160b8212@www.loria.fr>

Yes! Please drop it!
Laurent

Selon Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk>:

> As you all know, any TEI schema or DTD has an attribute "TEIform" for
> every element.
> It contains the name of the element, and is there to help you
> reconstruct documents
> where the element name has changed.
>
> We now know how to do this better by reference back to the ODD source,
> which also covers attribute names.
>
> Hands up all those who would be willing to quietly drop this dinosaur
> artefact?
>
> --
> 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 James.Cummings at computing-services.oxford.ac.uk  Sun Nov 13 10:03:23 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 13 Nov 2005 15:03:23 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <1131893088.43775160b8212@www.loria.fr>
References: <437729E5.80808@oucs.ox.ac.uk>
	<1131893088.43775160b8212@www.loria.fr>
Message-ID: <437755BB.50401@computing-services.oxford.ac.uk>

>Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk>:
>>We now know how to do this better by reference back to the ODD source,
>>which also covers attribute names.
>>Hands up all those who would be willing to quietly drop this dinosaur
>>artefact?

First, let me say that my gut instinct is to drop it.  Second, by way 
of playing Devil's Advocate, let me ask why it was there in the first 
place?

My assumption has always been that in document instances which 
conformed to an extended DTD where TEI elements had been renamed, a 
processed version of the document might exist out of context from its 
DTD.  (Since it is the processing of the document in conjunction with 
the DTD which provides the attribute.)  So once a document instance is 
moved somewhere else from it's DTD, that I have a <chapter> element 
which is really just a type of <div> becomes problematised because I 
have not documented that it is just a <div type="chapter">.  However, 
if I have a @TEIform, then the processed/expanded document, even in 
absence of its DTD will have @TEIform="div", thus providing some 
perhaps crucial information to someone happening upon the document 
years later.

What I'm wondering about the reference-back-to-ODD-source method is 
that it depends upon the existence of another file (much like, you can 
argue, the unprocessed file does to its DTD).  I'm more than happy to 
drop @TEIform, because it has never been any actual use to me, 
however, I am wary about just zapping it without being sure that we're 
providing as reliable a mechanism since Lou and others must surely 
have thought it a good idea at some point.  Well, that is the best I 
can do as a Devil's advocate I think.

So explain to me again how the reference back to the ODD source works? 
  I'm of course in favour of that as a mechanism since it also covers 
attribute names.

-James

From jawalsh at indiana.edu  Sun Nov 13 10:52:55 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Sun, 13 Nov 2005 10:52:55 -0500
Subject: [tei-council] @TEIform
In-Reply-To: <437755BB.50401@computing-services.oxford.ac.uk>
References: <437729E5.80808@oucs.ox.ac.uk>
	<1131893088.43775160b8212@www.loria.fr>
	<437755BB.50401@computing-services.oxford.ac.uk>
Message-ID: <56C36E44-BB65-483F-A9BB-23111CA4E4C5@indiana.edu>

Hi all,

I'm in agreement with James.  I'd like to hear a bit more about the  
"reference-back-to-ODD-source method" before agreeing to drop  
TEIform.  For something like my Comic Book Markup Language, a TEI  
extension set that is more of a radical departure from vanilla TEI  
than the norm, the TEIform element can be useful for tracing one's  
way back to the original TEI elements.

John
--
| John A. Walsh
| Associate Director for Projects and Services, Digital Library Program
| Associate Librarian, University Libraries
| Adjunct Associate Professor, Department of English
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 Fax:812-856-2062 <mailto:jawalsh at indiana.edu>

On Nov 13, 2005, at 10:03 AM, James Cummings wrote:

>> Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk>:
>>> We now know how to do this better by reference back to the ODD  
>>> source,
>>> which also covers attribute names.
>>> Hands up all those who would be willing to quietly drop this  
>>> dinosaur
>>> artefact?
>
>
> First, let me say that my gut instinct is to drop it.  Second, by  
> way of playing Devil's Advocate, let me ask why it was there in the  
> first place?
>
> My assumption has always been that in document instances which  
> conformed to an extended DTD where TEI elements had been renamed, a  
> processed version of the document might exist out of context from  
> its DTD.  (Since it is the processing of the document in  
> conjunction with the DTD which provides the attribute.)  So once a  
> document instance is moved somewhere else from it's DTD, that I  
> have a <chapter> element which is really just a type of <div>  
> becomes problematised because I have not documented that it is just  
> a <div type="chapter">.  However, if I have a @TEIform, then the  
> processed/expanded document, even in absence of its DTD will have  
> @TEIform="div", thus providing some perhaps crucial information to  
> someone happening upon the document years later.
>
> What I'm wondering about the reference-back-to-ODD-source method is  
> that it depends upon the existence of another file (much like, you  
> can argue, the unprocessed file does to its DTD).  I'm more than  
> happy to drop @TEIform, because it has never been any actual use to  
> me, however, I am wary about just zapping it without being sure  
> that we're providing as reliable a mechanism since Lou and others  
> must surely have thought it a good idea at some point.  Well, that  
> is the best I can do as a Devil's advocate I think.
>
> So explain to me again how the reference back to the ODD source  
> works?  I'm of course in favour of that as a mechanism since it  
> also covers attribute names.
>
> -James
> _______________________________________________
> 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  Sun Nov 13 11:18:40 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 13 Nov 2005 16:18:40 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <437755BB.50401@computing-services.oxford.ac.uk>
References: <437729E5.80808@oucs.ox.ac.uk>	<1131893088.43775160b8212@www.loria.fr>
	<437755BB.50401@computing-services.oxford.ac.uk>
Message-ID: <43776760.8060201@oucs.ox.ac.uk>

James Cummings wrote:

>
> My assumption has always been that in document instances which
> conformed to an extended DTD where TEI elements had been renamed, a
> processed version of the document might exist out of context from its
> DTD.  (Since it is the processing of the document in conjunction with
> the DTD which provides the attribute.)  So once a document instance is
> moved somewhere else from it's DTD, that I have a <chapter> element
> which is really just a type of <div> becomes problematised because I
> have not documented that it is just a <div type="chapter">.  However,
> if I have a @TEIform, then the processed/expanded document, even in
> absence of its DTD will have @TEIform="div", thus providing some
> perhaps crucial information to someone happening upon the document
> years later.

This is all true _only_ if you have taken your source document with its
DTD, and run it through some sort
of normalization process.  The TEIform attribute of your <chapter> is
provided only by the DTD, not
in the instance (does anyone use TEIform manually?). I suggest that the
using the "normalized" form of
document, with all implied attributes inserted, is not
remotely common working practice.
If you keep the DTD around, then things are OK.

In P5 world, you have to track two support files, the original ODD file,
and the generated schema file; the downside is
that you may use the schema file every day, but the ODD only once in a
blue moon, so you may get confused.

>
> So explain to me again how the reference back to the ODD source works?
>  I'm of course in favour of that as a mechanism since it also covers
> attribute names.

I find <chapter>. I read the ODD source to see if if
"elementSpec/altltIdent[.='chapter']" exists.
If so, I grab ../@ident, and rename my <chapter> to whatever that is.

easy, no?

of course, a variant ODD processor might generate you a custom XSL
script or the like to do the job
straight off.

-- 
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 Nov 13 11:31:55 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 13 Nov 2005 16:31:55 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <43776760.8060201@oucs.ox.ac.uk>
References: <437729E5.80808@oucs.ox.ac.uk>	<1131893088.43775160b8212@www.loria.fr>
	<437755BB.50401@computing-services.oxford.ac.uk>
	<43776760.8060201@oucs.ox.ac.uk>
Message-ID: <43776A7B.6010904@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> This is all true _only_ if you have taken your source document with its
> DTD, and run it through some sort
> of normalization process.  The TEIform attribute of your <chapter> is
> provided only by the DTD, not
> in the instance (does anyone use TEIform manually?). I suggest that the
> using the "normalized" form of
> document, with all implied attributes inserted, is not
> remotely common working practice.

I agree, that is why I was careful to say processed/expanded instance 
document.  I know of no one who uses TEIform manually.  And yes, I 
don't think most people use a normalized document with all those expanded.

> If you keep the DTD around, then things are OK.

Yes, though after initial creation/validation there are many who 
misplace their DTDs.

> In P5 world, you have to track two support files, the original ODD file,
> and the generated schema file; the downside is
> that you may use the schema file every day, but the ODD only once in a
> blue moon, so you may get confused.

This is what makes me wary.  While I can picture people keeping their 
schemas around (as much as I can picture them keeping their DTDs 
around), once the schema is created, I find it very likely that people 
will mistakenly misplace their ODD sources.  But I suppose we just 
have to remind people that ODD is part of their project documentation 
of how they differ from TEI.

> I find <chapter>. I read the ODD source to see if if
> "elementSpec/altltIdent[.='chapter']" exists.
> If so, I grab ../@ident, and rename my <chapter> to whatever that is.
> 
> easy, no?

Yes, perhaps not as easy as just looking at the @TEIform ... but still 
fairly straightforward if I have the ODD source.

> of course, a variant ODD processor might generate you a custom XSL
> script or the like to do the job
> straight off.

Do you have an XSL already which does this for simple syntactic sugar 
renamings?

-James

From sebastian.rahtz at oucs.ox.ac.uk  Sun Nov 13 11:33:40 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 13 Nov 2005 16:33:40 +0000
Subject: [tei-council] numbered divs
In-Reply-To: <17271.13348.990964.718256@emt.wwp.brown.edu>
References: <43772BA7.9010202@oucs.ox.ac.uk>
	<17271.13348.990964.718256@emt.wwp.brown.edu>
Message-ID: <43776AE4.2020701@oucs.ox.ac.uk>

Syd Bauman wrote:

>On the other hand, you voiced in earlier mail (not to the list) the
>thought of further constraining this back to "only numbered OR only
>un-numbered" with a Schematron rule. This may not be so terrible,
>depending on what our end position is on the use of Schematron.
>  
>
it's the thin end of the wedge, of course; how do we decide
what constraints to delegate? of course, this

>
>The general problem is that dropping all members of a class may make
>some content models ambiguous in DTD (and maybe W3C) land.
>
>I think it is important to seriously investigate the dummy-element
>insertion idea, which could solve this general problem, not just this
>instance. This is the idea that whenever the odd2dtd processor comes
>across an empty class, it populates that class with one element
><dummy-do-not-use>. 
>
Its an interesting idea. The flaw in practice is that the simplification
of smoothing out things to clean up after element removal is done
before odd2dtd kicks in. So it would need a another reimplementation
of the ODD processing, paralleling the scale of work I did in April.
Marginally easier, perhaps, to attempt to locate the ambiguous bits
in the odd2 processing.

Wouldn't your dummy element be offered all the time by the
editor as a possible choice?

-- 
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 Nov 13 11:37:27 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 13 Nov 2005 16:37:27 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <43776A7B.6010904@computing-services.oxford.ac.uk>
References: <437729E5.80808@oucs.ox.ac.uk>	<1131893088.43775160b8212@www.loria.fr>	<437755BB.50401@computing-services.oxford.ac.uk>	<43776760.8060201@oucs.ox.ac.uk>
	<43776A7B.6010904@computing-services.oxford.ac.uk>
Message-ID: <43776BC7.60407@oucs.ox.ac.uk>

James Cummings wrote:

> While I can picture people keeping their schemas around (as much as I
> can picture them keeping their DTDs around), once the schema is
> created, I find it very likely that people will mistakenly misplace
> their ODD sources.  But I suppose we just have to remind people that
> ODD is part of their project documentation of how they differ from TEI.

if they use ODD properly, they'll have their documentation in there too.

>> of course, a variant ODD processor might generate you a custom XSL
>> script or the like to do the job
>> straight off.
>
>
> Do you have an XSL already which does this for simple syntactic sugar
> renamings?
>
I showed something like it to you in my talk in Sofia :-}

-- 
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 Nov 13 22:41:13 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 14 Nov 2005 12:41:13 +0900
Subject: [tei-council] @TEIform
In-Reply-To: <43776A7B.6010904@computing-services.oxford.ac.uk> (James
	Cummings's message of "Sun, 13 Nov 2005 16:31:55 +0000")
References: <437729E5.80808@oucs.ox.ac.uk>
	<1131893088.43775160b8212@www.loria.fr>
	<437755BB.50401@computing-services.oxford.ac.uk>
	<43776760.8060201@oucs.ox.ac.uk>
	<43776A7B.6010904@computing-services.oxford.ac.uk>
Message-ID: <ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>

James Cummings <James.Cummings at computing-services.oxford.ac.uk> writes:

>
> This is what makes me wary.  While I can picture people keeping their
> schemas around (as much as I can picture them keeping their DTDs
> around), once the schema is created, I find it very likely that people
> will mistakenly misplace their ODD sources.  But I suppose we just
> have to remind people that ODD is part of their project documentation
> of how they differ from TEI.

We have discussed at some point if/how an instance document should
mention its ODD source, but I don't think we have come to a
conclusion.  I would be uncomfortable dropping @TEIform (to which I do
not object)without at least this mechanism in place.

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  Mon Nov 14 03:26:50 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Mon, 14 Nov 2005 08:26:50 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <437729E5.80808@oucs.ox.ac.uk>	<1131893088.43775160b8212@www.loria.fr>	<437755BB.50401@computing-services.oxford.ac.uk>	<43776760.8060201@oucs.ox.ac.uk>	<43776A7B.6010904@computing-services.oxford.ac.uk>
	<ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <43784A4A.4080208@computing-services.oxford.ac.uk>

Christian Wittern wrote:
> James Cummings <James.Cummings at computing-services.oxford.ac.uk> writes:
> 
> 
>>This is what makes me wary.  While I can picture people keeping their
>>schemas around (as much as I can picture them keeping their DTDs
>>around), once the schema is created, I find it very likely that people
>>will mistakenly misplace their ODD sources.  But I suppose we just
>>have to remind people that ODD is part of their project documentation
>>of how they differ from TEI.
> 
> 
> We have discussed at some point if/how an instance document should
> mention its ODD source, but I don't think we have come to a
> conclusion.  I would be uncomfortable dropping @TEIform (to which I do
> not object)without at least this mechanism in place.

Having a place in the teiHeader to refer to an ODD...or even embed it 
(or this that too horribly recursive?) seems reasonable.  Perhaps a 
URI attribute in tagsDecl?  Would such a thing point just to the ODD 
source or to generated schemas as well?

-James

From sebastian.rahtz at oucs.ox.ac.uk  Mon Nov 14 04:06:20 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 14 Nov 2005 09:06:20 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>
References: <437729E5.80808@oucs.ox.ac.uk>	<1131893088.43775160b8212@www.loria.fr>	<437755BB.50401@computing-services.oxford.ac.uk>	<43776760.8060201@oucs.ox.ac.uk>	<43776A7B.6010904@computing-services.oxford.ac.uk>
	<ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>
Message-ID: <4378538C.4050801@oucs.ox.ac.uk>

Christian Wittern wrote:

>We have discussed at some point if/how an instance document should
>mention its ODD source, but I don't think we have come to a
>conclusion.  I would be uncomfortable dropping @TEIform (to which I do
>not object)without at least this mechanism in place.
>  
>
Since a DOCTYPE is not mandated (or even used, by some
applications), the status quo is that there is no default
link from an instance to a DTD (which is
where the @TEIform is).....

sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Mon Nov 14 04:19:56 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 14 Nov 2005 09:19:56 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <43784A4A.4080208@computing-services.oxford.ac.uk>
References: <437729E5.80808@oucs.ox.ac.uk>	<1131893088.43775160b8212@www.loria.fr>	<437755BB.50401@computing-services.oxford.ac.uk>	<43776760.8060201@oucs.ox.ac.uk>	<43776A7B.6010904@computing-services.oxford.ac.uk>	<ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<43784A4A.4080208@computing-services.oxford.ac.uk>
Message-ID: <437856BC.70803@oucs.ox.ac.uk>

James Cummings wrote:

> Having a place in the teiHeader to refer to an ODD...or even embed it 
> (or this that too horribly recursive?) 

sounds expensive...

> seems reasonable.  Perhaps a URI attribute in tagsDecl?  Would such a 
> thing point just to the ODD source or to generated schemas as well?

oh gosh you'll start up Syd's thread again. Mind you, I don't object to 
adding a URI hook
linking to an ODD somewhere in the header.

But let's recall James Clark's belief (strongly supported in some circles)
that an instance may have several schemata against which it may or may not
be valid. There is no one right answer. So it goes against this argument
to associate an instance with just one {XSD,RNG,DTD}.

However, an ODD does some more work. In this case it defines
relationships between used element names and TEI ur-element
names. In some ideal world, we would extract just that info
and put it in the header - and how would we keep it up to date
and accurate, etc? If we use <equiv> in the manner I suggested in Sofia,
we need external data sources to do the translation anyway.

We worry that a document may become separated from its metadata,
or the metadata lost. And? A binary program separated from its source
happens too. Its bad. But you cannot legislate against it.

We have already accepted that the I18N work presupposes the
ability to translate from an instance which has translated names;
this needs an ODD, since @TEIform does not help with attributes.

In the new world where DTDs no  longer reign supreme,
attributes with default values, like @TEIform, are an anachronistic
pain in the neck. They arent there when you might like them, if you
use schema processing, and they pop up when you don't want them
(when an editor shows you a list of attributes).

sebastian

From lou.burnard at computing-services.oxford.ac.uk  Mon Nov 14 04:56:36 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Mon, 14 Nov 2005 09:56:36 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <437856BC.70803@oucs.ox.ac.uk>
References: <437729E5.80808@oucs.ox.ac.uk>	<1131893088.43775160b8212@www.loria.fr>	<437755BB.50401@computing-services.oxford.ac.uk>	<43776760.8060201@oucs.ox.ac.uk>	<43776A7B.6010904@computing-services.oxford.ac.uk>	<ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>	<43784A4A.4080208@computing-services.oxford.ac.uk>
	<437856BC.70803@oucs.ox.ac.uk>
Message-ID: <43785F54.2060800@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:

> James Cummings wrote:
>
>> Having a place in the teiHeader to refer to an ODD...or even embed it 
>> (or this that too horribly recursive?) 
>
>
> sounds expensive...
>
>> seems reasonable.  Perhaps a URI attribute in tagsDecl?  Would such a 
>> thing point just to the ODD source or to generated schemas as well?
>
>
> oh gosh you'll start up Syd's thread again. Mind you, I don't object 
> to adding a URI hook
> linking to an ODD somewhere in the header.

This sounds useful to me. And not expensive!

>
> But let's recall James Clark's belief (strongly supported in some 
> circles)
> that an instance may have several schemata against which it may or may 
> not
> be valid. There is no one right answer. So it goes against this argument
> to associate an instance with just one {XSD,RNG,DTD}.
>

Not so sure I am persuaded by this argument. I can think of cases where 
it makes quite a bit of sense to say that a given instance *was* 
validated against a specific schema instance (or , in our case, a given 
ODD).  There is also the problem that not all schema languages support 
the same constraints of course.

> However, an ODD does some more work. In this case it defines
> relationships between used element names and TEI ur-element
> names. In some ideal world, we would extract just that info
> and put it in the header

we do that already, even in our current sublunary world. namely viz 
tagsdecl.
Hmm, we could conceivably add an attribute to that giving the canonical 
name for each element used?

> - and how would we keep it up to date
> and accurate, etc? If we use <equiv> in the manner I suggested in Sofia,
> we need external data sources to do the translation anyway.
>

Maybe its the content of the equiv element which needs to go into the 
header, rather than a pointer to the ODD itself?

> We worry that a document may become separated from its metadata,
> or the metadata lost. And? A binary program separated from its source
> happens too. Its bad. But you cannot legislate against it.
>

Not a good argument. Many binaries contain (often in excurciating 
detail) lots of information about when they were last compiled and 
against what.

> We have already accepted that the I18N work presupposes the
> ability to translate from an instance which has translated names;
> this needs an ODD, since @TEIform does not help with attributes.
>

This on the other hand is  very good argument

> In the new world where DTDs no  longer reign supreme,
> attributes with default values, like @TEIform, are an anachronistic
> pain in the neck. They arent there when you might like them, if you
> use schema processing, and they pop up when you don't want them
> (when an editor shows you a list of attributes).
>

I agree, on balance.

From sebastian.rahtz at oucs.ox.ac.uk  Mon Nov 14 06:24:23 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 14 Nov 2005 11:24:23 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <43785F54.2060800@computing-services.oxford.ac.uk>
References: <437729E5.80808@oucs.ox.ac.uk>	<1131893088.43775160b8212@www.loria.fr>	<437755BB.50401@computing-services.oxford.ac.uk>	<43776760.8060201@oucs.ox.ac.uk>	<43776A7B.6010904@computing-services.oxford.ac.uk>	<ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>	<43784A4A.4080208@computing-services.oxford.ac.uk>
	<437856BC.70803@oucs.ox.ac.uk>
	<43785F54.2060800@computing-services.oxford.ac.uk>
Message-ID: <437873E7.4010904@oucs.ox.ac.uk>

Lou Burnard wrote:

>
> we do that already, even in our current sublunary world. namely viz 
> tagsdecl.
> Hmm, we could conceivably add an attribute to that giving the 
> canonical name for each element used?

but that a) doesn't cover attributes, and b) only covers simple renaming.

>
> Maybe its the content of the equiv element which needs to go into the 
> header, rather than a pointer to the ODD itself?

how would they get there, tho?

James and I suggested to each other today that Roma should spit
out an XSLT script for a given ODD which performed the canonicalisation
for instances against that ODD. How would that suit?

This would require some decisions on what "canonicalisation" means.
Redoing the names of things is fine, but what does the script do

 - when an element is added (make it into a <seg type=$name>?)
 - when an attribute is added  (???? squash it into @rend?)
 - when a datatype is changed (do nothing?)

obviously the canonicalisation does not (cannot) guarentee validitity 
against a
core schema set.

The I18N stuff requires this script generation anyway, probably.

Sebastian

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Nov 14 07:36:42 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 14 Nov 2005 21:36:42 +0900
Subject: [tei-council] @TEIform
In-Reply-To: <4378538C.4050801@oucs.ox.ac.uk> (Sebastian Rahtz's message of
	"Mon, 14 Nov 2005 09:06:20 +0000")
References: <437729E5.80808@oucs.ox.ac.uk>
	<1131893088.43775160b8212@www.loria.fr>
	<437755BB.50401@computing-services.oxford.ac.uk>
	<43776760.8060201@oucs.ox.ac.uk>
	<43776A7B.6010904@computing-services.oxford.ac.uk>
	<ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>
	<4378538C.4050801@oucs.ox.ac.uk>
Message-ID: <ygfu0efxv6t.fsf@chwpb.local>

Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk> writes:

> Christian Wittern wrote:
>
>>We have discussed at some point if/how an instance document should
>>mention its ODD source, but I don't think we have come to a
>>conclusion.  I would be uncomfortable dropping @TEIform (to which I do
>>not object)without at least this mechanism in place.
>>  
>>
> Since a DOCTYPE is not mandated (or even used, by some
> applications), the status quo is that there is no default
> link from an instance to a DTD (which is
> where the @TEIform is).....

Well -- I agree that these are different beasts, and I am not asking
for a link to a schema, but rather to an ODD.  

A dedicated attribute that takes a URI value would be good enough for
most cases, although I also see that for some cases embedding seems to
be elegant, which is something we have discussed recently in another
context as well.  Maybe we should call it the kangaroo method and make
it a general principle for auxiliary data (charDesc, prosopography,
you-name-it).  Is this something in scope for the SO group?

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 Nov 14 07:59:35 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 14 Nov 2005 12:59:35 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <ygfu0efxv6t.fsf@chwpb.local>
References: <437729E5.80808@oucs.ox.ac.uk>	<1131893088.43775160b8212@www.loria.fr>	<437755BB.50401@computing-services.oxford.ac.uk>	<43776760.8060201@oucs.ox.ac.uk>	<43776A7B.6010904@computing-services.oxford.ac.uk>	<ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>	<4378538C.4050801@oucs.ox.ac.uk>
	<ygfu0efxv6t.fsf@chwpb.local>
Message-ID: <43788A37.4000608@oucs.ox.ac.uk>

Christian Wittern wrote:

>A dedicated attribute that takes a URI value would be good enough for
>most cases, although I also see that for some cases embedding seems to
>be elegant, which is something we have discussed recently in another
>context as well.  Maybe we should call it the kangaroo method and make
>it a general principle for auxiliary data (charDesc, prosopography,
>you-name-it).  Is this something in scope for the SO group?
>  
>
You are suggesting a new section in the header which is used to
link to metadata? I do like the idea at first sight.

curiously, I just had a discussion here about
where to reference an RSS feed which relates to the current
document (we have currently have it in <notesStmt>, which
is not ideal).

-- 
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  Mon Nov 14 09:18:57 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Mon, 14 Nov 2005 15:18:57 +0100
Subject: [tei-council] @TEIform
In-Reply-To: <43788A37.4000608@oucs.ox.ac.uk>
References: <437729E5.80808@oucs.ox.ac.uk>	<1131893088.43775160b8212@www.loria.fr>	<437755BB.50401@computing-services.oxford.ac.uk>	<43776760.8060201@oucs.ox.ac.uk>	<43776A7B.6010904@computing-services.oxford.ac.uk>	<ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>	<4378538C.4050801@oucs.ox.ac.uk>
	<ygfu0efxv6t.fsf@chwpb.local> <43788A37.4000608@oucs.ox.ac.uk>
Message-ID: <3A5C92E3-87B5-4A62-9C6E-D68FD091AAA0@loria.fr>

Sorry to be abrupt here, but as I see it from the discussion so far:  
apart from the fear to loose a mechanism that is not used nor liked  
by anyone and the fact that there is a continuous thread on refereing  
to a schema in the header, do we have a good reason to pospone the  
final eradication of @TEIForm? ("Burn!")
Laurent

From James.Cummings at computing-services.oxford.ac.uk  Mon Nov 14 09:58:49 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Mon, 14 Nov 2005 14:58:49 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <437873E7.4010904@oucs.ox.ac.uk>
References: <437729E5.80808@oucs.ox.ac.uk>	<1131893088.43775160b8212@www.loria.fr>	<437755BB.50401@computing-services.oxford.ac.uk>	<43776760.8060201@oucs.ox.ac.uk>	<43776A7B.6010904@computing-services.oxford.ac.uk>	<ygfhdaf3nhi.fsf@kanji.zinbun.kyoto-u.ac.jp>	<43784A4A.4080208@computing-services.oxford.ac.uk>
	<437856BC.70803@oucs.ox.ac.uk>
	<43785F54.2060800@computing-services.oxford.ac.uk>
	<437873E7.4010904@oucs.ox.ac.uk>
Message-ID: <4378A629.4020507@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:
> James and I suggested to each other today that Roma should spit
> out an XSLT script for a given ODD which performed the canonicalisation
> for instances against that ODD. How would that suit?

As you know, I would like that very much.

> This would require some decisions on what "canonicalisation" means.
> Redoing the names of things is fine, but what does the script do
> 
> - when an element is added (make it into a <seg type=$name>?)

Or should this depend on its model class, if it uses an existing one?

> - when an attribute is added  (???? squash it into @rend?)

While I don't like that (especially not using @rend...) if I have
several attributes that I'd added. Let's say I add @favouriteColour
@eyeColour and @hairColour to <person> for some strange reason.  Does
that mean that we get:
<person rend="favouriteColour:009900; eyeColour:Brown; hairColour:Brown;">
Surely @rend is the wrong thing to use.
Let's see... an attribute for storing this kind of information...we could
call it @TEIForm. ;-)  *duck*

> - when a datatype is changed (do nothing?)

Frightening.

-James

From mz34 at nyu.edu  Tue Nov 15 10:25:01 2005
From: mz34 at nyu.edu (Matthew Zimmerman)
Date: Tue, 15 Nov 2005 10:25:01 -0500
Subject: [tei-council] Council Chair
Message-ID: <38576D65-D2D8-4AAE-8F7F-26820445B316@nyu.edu>

I am happy to announce that the Board has unanimously voted to  
reappoint Christian Wittern as chair of the TEI-C Technical Council  
for another term from Jan 1, 2006 to Dec 31, 2006, and Christian has  
graciously accepted.

MZ
_________________
Matthew Zimmerman
Faculty Technology Services, NYU
Tel: 212.998.3038
Fax: 212.995.4120

From Syd_Bauman at Brown.edu  Thu Nov 17 06:52:47 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 17 Nov 2005 06:52:47 -0500
Subject: [tei-council] Use of <imprint> wrapper inside <bibl>-like-things
Message-ID: <17276.28431.472950.912641@emt.wwp.brown.edu>

At the "class" sub-committee meeting in Oxford in September, it was
decided to drop the <imprint> element from <bibl> and <biblItem> (but
not from <monogr>). The effect of this change from the
sub-committee's point of view is to make the TEI class system a
little simpler and more coherent. That's a good thing. The result
from the encoder's point of view is that things that are encoded as

  <bibl xml:id="IMEV">
    <author>Carleton Brown</author> and <author>Rossell Hope Robbins</author>
    <title level="m">The index of Middle English verse

      New York
      1943

in P4 would need to become

    Carleton Brown and Rossell Hope Robbins
    The index of Middle English verse
    New York
    1943

in P5.

I am posting here just to double-check that this change is OK with
Council. While all of us at the meeting were convinced that the extra
level of nesting is not helpful, I think it would be a good idea to
ask some librarians, catalogers, bibliographers, etc.

From Syd_Bauman at Brown.edu  Thu Nov 17 06:58:43 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 17 Nov 2005 06:58:43 -0500
Subject: [tei-council] Use of  wrapper inside -like-things
In-Reply-To: <17276.28431.472950.912641@emt.wwp.brown.edu>
References: <17276.28431.472950.912641@emt.wwp.brown.edu>
Message-ID: <17276.28787.809885.530496@emt.wwp.brown.edu>

> At the "class" sub-committee meeting in Oxford in September, it was
> decided to drop the  element from  and  (but
> not from ).

Ooops. Hit 'send' before I added my footnote:

See http://www.tei-c.org/Council/tcm20.xml?style=printable, section
    #3, item #16.

From Syd_Bauman at Brown.edu  Thu Nov 17 07:03:53 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 17 Nov 2005 07:03:53 -0500
Subject: [tei-council] numbered divs
In-Reply-To: <43776AE4.2020701@oucs.ox.ac.uk>
References: <43772BA7.9010202@oucs.ox.ac.uk>
	<17271.13348.990964.718256@emt.wwp.brown.edu>
	<43776AE4.2020701@oucs.ox.ac.uk>
Message-ID: <17276.29097.983336.541874@emt.wwp.brown.edu>

> it's the thin end of the wedge, of course; how do we decide what
> constraints to delegate? of course, this

It is not so obvious to me that this particular constraint should be
delegated to Schematron, as opposed to schema-enforced, at least not
at the moment.

> Its an interesting idea. The flaw in practice is that the
> simplification of smoothing out things to clean up after element
> removal is done before odd2dtd kicks in. 

Oh, blimey.

> Wouldn't your dummy element be offered all the time by the editor
> as a possible choice?

Depends on how smart the editor is, but yes, many would do that.
(Which is why there should be only 1 such dummy GI, and its name
should make it obvious it is not a real element.)

From lou.burnard at computing-services.oxford.ac.uk  Thu Nov 17 07:12:06 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 17 Nov 2005 12:12:06 +0000
Subject: [tei-council] Use of  wrapper inside -like-things
In-Reply-To: <17276.28787.809885.530496@emt.wwp.brown.edu>
References: <17276.28431.472950.912641@emt.wwp.brown.edu>
	<17276.28787.809885.530496@emt.wwp.brown.edu>
Message-ID: <437C7396.5070906@oucs.ox.ac.uk>

Council members might also be interested to check the current state of 
document edw92, which includes the status of all the changes on that list.

http://www.tei-c.org/Drafts/edw92.xml

Syd Bauman wrote:
>>At the "class" sub-committee meeting in Oxford in September, it was
>>decided to drop the  element from  and  (but
>>not from ).
> 
> 
> Ooops. Hit 'send' before I added my footnote:
> 
> See http://www.tei-c.org/Council/tcm20.xml?style=printable, section
>     #3, item #16.
> 
> _______________________________________________
> 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  Thu Nov 17 07:10:40 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 17 Nov 2005 07:10:40 -0500
Subject: [tei-council] @TEIform
In-Reply-To: <437873E7.4010904@oucs.ox.ac.uk>
References: <437729E5.80808@oucs.ox.ac.uk>
	<1131893088.43775160b8212@www.loria.fr>
	<437755BB.50401@computing-services.oxford.ac.uk>
	<43776760.8060201@oucs.ox.ac.uk>
	<43776A7B.6010904@computing-services.oxford.ac.uk>

	<43784A4A.4080208@computing-services.oxford.ac.uk>
	<437856BC.70803@oucs.ox.ac.uk>
	<43785F54.2060800@computing-services.oxford.ac.uk>
	<437873E7.4010904@oucs.ox.ac.uk>
Message-ID: <17276.29504.203713.362607@emt.wwp.brown.edu>

> James and I suggested to each other today that Roma should spit out
> an XSLT script for a given ODD which performed the canonicalisation
> for instances against that ODD. How would that suit?

Well I like the idea a whole lot, but only if it's used to
canonicalize that which can be: restrictions and isomorphisms. True
extensions need human intervention and should be left alone. (By this
auto-canonicalize software, at least.)

Thus the auto-partial-canoncializer stylesheet should leave added
eleements and attributes alone. Changed datatypes will be a pain in
the keester, as it will be at least very difficult, if not
impossible, to determine whether or not the new datatype defines a
set of values that is a subset of the canonical one's.

> The I18N stuff requires this script generation anyway, probably.

I think this is its main use. And also for projects that create
, , and , all analogous to .

From sebastian.rahtz at oucs.ox.ac.uk  Thu Nov 17 07:24:11 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 17 Nov 2005 12:24:11 +0000
Subject: [tei-council] @TEIform
Message-ID: <437C766B.1040003@oucs.ox.ac.uk>

I am not sure this message got through, as it had an attachment.

I said

"here's a laugh for you, an XSLT script which transforms an instance
back to canonical form by reading its ODD and looking
for altIdent. See if you can catch it out."

http://www.tei-c.org/P5/canonicalise.xsl

-- 
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  Thu Nov 17 07:25:17 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 17 Nov 2005 12:25:17 +0000
Subject: [tei-council] @TEIform -> /dev/null
Message-ID: <437C76AD.3000308@oucs.ox.ac.uk>

I also said this, with an attachment:

"Just to prove it can be done, the attached XSLT transform is designed to
be run on a (compiled) ODD file.
It will construct a new custom XSLT script which will "canonicalize" XML
instances which are valid
against schemas from the original ODD, making normal TEI again. It deals
with renamed attributes
and elements, and  constructs. I leave it as an
exercise for the reader (that's you,
James) to add sensible support for new elements or attributes.

_now_  can I delete @TEIform, pretty please?

A prize for the person who explains why I put in that condition of
"(compiled)" up there.

Another prize for the first person to construct an ODD and actually test
that this works."

http://www.tei-c.org/P5/oddtofilter.xsl

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  Thu Nov 17 07:31:34 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 17 Nov 2005 12:31:34 +0000
Subject: [tei-council] @TEIform
In-Reply-To: <17276.29504.203713.362607@emt.wwp.brown.edu>
References: <437729E5.80808@oucs.ox.ac.uk>	<1131893088.43775160b8212@www.loria.fr>	<437755BB.50401@computing-services.oxford.ac.uk>	<43776760.8060201@oucs.ox.ac.uk>	<43776A7B.6010904@computing-services.oxford.ac.uk>		<43784A4A.4080208@computing-services.oxford.ac.uk>	<437856BC.70803@oucs.ox.ac.uk>	<43785F54.2060800@computing-services.oxford.ac.uk>	<437873E7.4010904@oucs.ox.ac.uk>
	<17276.29504.203713.362607@emt.wwp.brown.edu>
Message-ID: <437C7826.20502@oucs.ox.ac.uk>

Syd Bauman wrote:

>Well I like the idea a whole lot, but only if it's used to
>canonicalize that which can be: restrictions and isomorphisms. True
>extensions need human intervention and should be left alone. (By this
>auto-canonicalize software, at least.)
>  
>
That would be the default action of my script.

>I think this is its main use. And also for projects that create
>, , and , all analogous to .
>  
>
they'll need to use my  route, of course.

-- 
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  Thu Nov 17 07:40:18 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 17 Nov 2005 12:40:18 +0000
Subject: [tei-council] @TEIform -> /dev/null
In-Reply-To: <437C76AD.3000308@oucs.ox.ac.uk>
References: <437C76AD.3000308@oucs.ox.ac.uk>
Message-ID: <437C7A32.1010804@oucs.ox.ac.uk>

Sebastian Rahtz wrote:
> I also said this, with an attachment:
> 
> 
> _now_  can I delete @TEIform, pretty please?
> 
> 

When I saw him yesterday, Laurent was quite emphatic on the necessity 
for doing this AS SOON AS POSSIBLE

I suggest you make it so without further delay.

From pwillett at umich.edu  Thu Nov 17 07:52:59 2005
From: pwillett at umich.edu (Perry Willett)
Date: Thu, 17 Nov 2005 07:52:59 -0500
Subject: [tei-council] Use of  wrapper inside -like-things
In-Reply-To: <17276.28431.472950.912641@emt.wwp.brown.edu>
Message-ID: <000401c5eb75$da0c5730$922bd38d@CLUBSODA>

Speaking for myself and not for the entire library profession,  (or
 in  for that matter) has always struck me as
unnecessary. Seems like a vestige of MARC or something.

Perry Willett
University of Michigan
pwillett at umich.edu

-----Original Message-----
From: tei-council-bounces at lists.village.Virginia.EDU
[mailto:tei-council-bounces at lists.village.Virginia.EDU] On Behalf Of Syd
Bauman
Sent: Thursday, November 17, 2005 6:53 AM
To: TEI Council
Subject: [tei-council] Use of  wrapper inside -like-things

At the "class" sub-committee meeting in Oxford in September, it was
decided to drop the  element from  and  (but
not from ). The effect of this change from the
sub-committee's point of view is to make the TEI class system a
little simpler and more coherent. That's a good thing. The result
from the encoder's point of view is that things that are encoded as

    Carleton Brown and Rossell Hope
Robbins
    The index of Middle English verse

      New York
      1943

in P4 would need to become

    Carleton Brown and Rossell Hope
Robbins
    The index of Middle English verse
    New York
    1943

in P5.

I am posting here just to double-check that this change is OK with
Council. While all of us at the meeting were convinced that the extra
level of nesting is not helpful, I think it would be a good idea to
ask some librarians, catalogers, bibliographers, etc.

_______________________________________________
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 Nov 17 09:25:56 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Thu, 17 Nov 2005 14:25:56 +0000
Subject: [tei-council] @TEIform -> /dev/null
In-Reply-To: <437C7A32.1010804@oucs.ox.ac.uk>
References: <437C76AD.3000308@oucs.ox.ac.uk> <437C7A32.1010804@oucs.ox.ac.uk>
Message-ID: <437C92F4.8060804@oucs.ox.ac.uk>

> When I saw him yesterday, Laurent was quite emphatic on the necessity 
> for doing this AS SOON AS POSSIBLE

I sympathize, but why is it urgent? has it been traced as the cause of 
Paris riots?

>
> I suggest you make it so without further delay.
>
I'm very very reluctant indeed to make a new release at this moment,
while edw92 is on the work bench.

I can remove the code in the stylesheets, though.

sebastian

From nsmith at email.unc.edu  Thu Nov 17 09:42:54 2005
From: nsmith at email.unc.edu (Natasha Smith)
Date: Thu, 17 Nov 2005 09:42:54 -0500 (Eastern Standard Time)
Subject: [tei-council] Use of  wrapper inside -like-things
In-Reply-To: <437C7396.5070906@oucs.ox.ac.uk>
Message-ID: 

> Council members might also be interested to check the current state of 
> document edw92, which includes the status of all the changes on that list. 
> http://www.tei-c.org/Drafts/edw92.xml

> > See http://www.tei-c.org/Council/tcm20.xml?style=printable, section 
#3, item #16.

read both documents and agree with the decision to move  out from
 and .

best, ns

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Nov 18 18:57:40 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 19 Nov 2005 08:57:40 +0900
Subject: [tei-council] W3C Xpointer schema registry
Message-ID: 

Dear council members,

As instructed during the last call, I wrote a message to Henry
Thompson of the W3C, to express the TEI's interest in getting the
registry up and running.  It took me a while to write the latter, but
within hours from me writing it, the XPointer scheme registry got
announced on the W3C web page[1].  I never thought that TEI lobbying
could be *that* effective:-)

Now it is essential that we move along quickly to get our schemes
registered.  I think Syd would be the right person to ask to submit
our proposal.  You will need a public access account of the W3C for
this, for which you apply at [1].

Does this seem the right course of action?

Christian

[1] http://www.w3.org/
[2] http://cgi.w3.org/MemberAccess/Public

-- 

 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 Nov 18 20:17:29 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 18 Nov 2005 20:17:29 -0500
Subject: [tei-council] W3C Xpointer schema registry
In-Reply-To: 
References: 
Message-ID: <17278.32041.403478.1413@emt.wwp.brown.edu>

> As instructed during the last call, I wrote a message to Henry
> Thompson of the W3C, to express the TEI's interest in getting the
> registry up and running. It took me a while to write the latter,
> but within hours from me writing it, the XPointer scheme registry
> got announced on the W3C web page[1]. I never thought that TEI
> lobbying could be *that* effective:-)

Wow! Way to go, Christian! 
I'll forward this on to the SOM WG.

> Now it is essential that we move along quickly to get our schemes
> registered. I think Syd would be the right person to ask to submit
> our proposal. You will need a public access account of the W3C for
> this, for which you apply at [1].

OK. I'll plan to work on this very soon; hopefully will start
tonight, finish tomorrow.

From lou.burnard at computing-services.oxford.ac.uk  Sat Nov 19 14:41:33 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Sat, 19 Nov 2005 19:41:33 +0000
Subject: [tei-council] W3C Xpointer schema registry
In-Reply-To: <17278.32041.403478.1413@emt.wwp.brown.edu>
References: 
	<17278.32041.403478.1413@emt.wwp.brown.edu>
Message-ID: <437F7FED.8040501@computing-services.oxford.ac.uk>

Syd Bauman wrote:

> 
>>Now it is essential that we move along quickly to get our schemes
>>registered. I think Syd would be the right person to ask to submit
>>our proposal. You will need a public access account of the W3C for
>>this, for which you apply at [1].
> 
> 
> OK. I'll plan to work on this very soon; hopefully will start
> tonight, finish tomorrow.
> 

Hold on there a minute. I hate to sound like a wet blanket, but I really 
don't think this is more urgent than completing the class work. That may 
be because I don't know exactly what it is that you are expecting Syd to 
do , of course, but my belief remains that the highest priority at the 
moment is for the editors to complete the work initiated in Oxford, and 
not to be distracted by other considerations.

I am also a bit worried that we should be sending off proposals to the 
W3C, of any kind, which have not actually been seen by the COuncil as 
yet. Or were these "schemes" seen so long ago that I have forgotten them 
already?

> _______________________________________________
> 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 Nov 19 18:29:09 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 19 Nov 2005 18:29:09 -0500
Subject: [tei-council] classy measurements
Message-ID: <17279.46405.734463.561853@emt.wwp.brown.edu>

At the class meeting in Oxford we decided to create a new attribute
class "att.measurement" to have the attributes unit=, quantity=, and
commodity= for . This all seems like a very good idea on the
surface, but digging a bit deeper it reveals places where our goals
compete with one another, and problems with our declaration system.

unit symbols
---- -------
First, there is the question as to what to recommend people use as
the symbol for a variety of common units. In general, our goal is to
depend on outside standards wherever reasonable. Symbols for units
seems like a great place for TEI to say only what's necessary, and
point to other standards for the rest. The problem is, there are lots
of standards out there, and they often disagree, usually subtly. At a
minimum, there's

* SI (also ISO 1000?), *the* international system of units, aka
  "metric system", by BIPM

* ISO 31, in particular ISO 31-0

* ISO 2955, about which I know very little except that some people
  think it's obsolete

* ANSI X3.50, the American extension of 2955, which also does not
  seem to be readily available 

* ASTM 1238 and its super-set HL7

* ENV 12435 (which I *think* is the European equivalent of the
  American HL7)

* UCUM, The Unified Code for Units of Measures

* Unicode / ISO 10646

Several of these were invented without consideration of machine
interchange of data; several were invented specifically to address
machine interchange of data *using limited character sets*. But none
of them seem to address how to perform machine interchange of data
*using Unicode* (even Unicode itself; I can pretty easily find the
code-points and names of various characters, but not much about their
semantics and intended use).

This is a bit of a problem, because we (alright, I) would like some
guidance on which, if any, of the Unicode characters for unit symbols
should be used. E.g., Unicode seems to suggest that the double-prime
character (U+2033) be used for inches or seconds, and there are
characters for degrees Celsius, ounces, and angstroms. Also there are
a lot of characters that look like they are designed for specific
unit use, but I haven't been able to find out for sure. The names are
a bit odd, and they're in the CJK compatibility block. E.g., U+3392
looks like it would be used for megahertz. (See, e.g.,
http://www.fileformat.info/info/unicode/char/3392/index.htm)

I also think it very important to provide guidance on how to make
explicit the difference between standard and binary values, if the
encoder so desires. (I.e., "MB" vs. "MiB". See, e.g.,
http://www.iec.ch/zone/si/si_bytes.htm if interested.)

The Unified Code for Units of Measures is specifically designed to
'unify' the other standards that address machine interchange.
Furthermore, it does include the binary prefixes. Thus, it initially
looks like a really good candidate. However, it is expressly intended
for use with limited character sets. In particular, it only takes
characters from 7-bit ASCII. While I understand that no one may be
crying over the loss of U+3392 for megahertz, the inability to use mu
for micro or omega for ohm seems silly.

Furthermore, this specification is very detailed. E.g., in some cases
it forces differentiation of which standard a unit comes from. So,
e.g., there are three different symbols for "inch":

 [in_i] = inch, international = 2.54 cm
 [in_us] = the inch as used in USA from 1893 to 1959 = m/39.37
 [in_br] = the British imperial inch = 2.539998 cm

Not only are these symbols ugly and cumbersome, I think the *vast*
majority of TEI users do not care which inch they're using. So to be
forced to pick one would be an annoying burden.

Unless someone knows more about this or has a better idea, I'm going
to suggest that for now the documentation for this class should list
some of the most common symbols in the "suggested values include"
list, and suggest users refer to a standard, and list a bunch of
possible standards (perhaps in the bibliography).

Later, after we've finished straightening out the classes, I think 2
or 3 of us should come up with a concrete proposal for how to encode
units in a Unicode environment. How to put such a proposal into a
tagdoc file is another problem entirely (which I foreshadowed with
"problems with our declaration system", above :-), because the values
of ident= of  need to be xsd:Names. This suggestion defers
having to deal with this, too.

Regularization vs. Normalization
-------------- --- -------------
Second is the question of whether these attributes are used for
regularization or normalization. My suggestion is that the Guidelines
explicitly state that these attributes can be used either for
regularization:

  The following has been recommended in neuralgia of the uterus: Mix
  together one plus a half grain of alcoholic extract of
  belladonna and ...

or normalization:

  The following has been recommended in neuralgia of the uterus: Mix
  together one plus a half grain of alcoholic extract of
  belladonna and ...

and that we have no recommendation for doing both simultaneously.

type=, anyone?
------ -------
If the class subcommittee decided whether the new attributes would
replace type= of  or be added in addition to it, this
decision was not recorded in the minutes. Unless someone can think of
a good reason to drop type= of , I'm going to suggest we
keep it on the somewhat feeble grounds that it can't hurt much, and
it may be quite helpful if we've overlooked something.

I plan to have these three suggestions wrapped into the tagdoc
available on Sourceforge within a few hours.

From Syd_Bauman at Brown.edu  Sat Nov 19 18:43:08 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 19 Nov 2005 18:43:08 -0500
Subject: [tei-council] W3C Xpointer schema registry
In-Reply-To: <437F7FED.8040501@computing-services.oxford.ac.uk>
References: 
	<17278.32041.403478.1413@emt.wwp.brown.edu>
	<437F7FED.8040501@computing-services.oxford.ac.uk>
Message-ID: <17279.47244.877033.841725@emt.wwp.brown.edu>

[Cross-posted to Council and SO]

> Hold on there a minute. I hate to sound like a wet blanket, but I
> really don't think this is more urgent than completing the class
> work.

I disagree -- this is potentially *very* time sensitive. Maybe not,
but we have no way of knowing who else is queued up waiting to
register scheme names, and I don't think we should take the chance.
Turns out the W3C isn't open for business now, so I have to wait
until Monday.

> I am also a bit worried that we should be sending off proposals to
> the W3C, of any kind, which have not actually been seen by the
> COuncil as yet. Or were these "schemes" seen so long ago that I
> have forgotten them already?

Perhaps. They were first seen by the group as a whole in Ghent, I
think. But don't fret too much, even if you haven't committed them to
memory and written java implementations of them. If I understand
correctly, what we are registering with W3C is the name, not the
semantics. That is, we want to be first to the punch so that a
reference to the match() XPointer scheme means the TEI match()
XPointer scheme, not Joe's match() XPointer scheme. If we get there
first, Joe will be the one who needs to use a different name or use
the cumbersome namespace mechanism the XPointer Framework provides.

As a reminder to everyone, the names we're planning to register are

  xpath()
  left()
  right()
  range()
  string-range()
  match()

We had xpath2() in an earlier version of the list, but decided to
drop it because XPath 2.0 was only a draft at the time. Has it become
a real official W3C recommendation? If so, we should go ahead and add
xpath2() back to the list, no?

From James.Cummings at computing-services.oxford.ac.uk  Sat Nov 19 19:56:25 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Sun, 20 Nov 2005 00:56:25 +0000
Subject: [tei-council] W3C Xpointer schema registry
In-Reply-To: <17279.47244.877033.841725@emt.wwp.brown.edu>
References: 	<17278.32041.403478.1413@emt.wwp.brown.edu>	<437F7FED.8040501@computing-services.oxford.ac.uk>
	<17279.47244.877033.841725@emt.wwp.brown.edu>
Message-ID: <437FC9B9.40803@computing-services.oxford.ac.uk>

Syd Bauman wrote:
> We had xpath2() in an earlier version of the list, but decided to
> drop it because XPath 2.0 was only a draft at the time. Has it become
> a real official W3C recommendation? If so, we should go ahead and add
> xpath2() back to the list, no?

"This specification will remain a Candidate Recommendation until at 
least 28 February 2006."

I think it is fairly stable, though others may know better.  I'd say 
include it in the list.

I'm sure this has all been thought through before, but is there a need 
for both an xpath() and xpath2()?  (Just strikes me as problematic, 
what happens when xpath3 (if ever) comes along.)  Do they need to be 
separate because of the issues of backwards compatibility?

http://www.w3.org/TR/2005/CR-xpath20-20051103/#id-backwards-compatibility

-James

From wittern at kanji.zinbun.kyoto-u.ac.jp  Sun Nov 20 18:05:58 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 21 Nov 2005 08:05:58 +0900
Subject: [tei-council] W3C Xpointer schema registry
In-Reply-To: <437F7FED.8040501@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Sat, 19 Nov 2005 19:41:33 +0000")
References: 
	<17278.32041.403478.1413@emt.wwp.brown.edu>
	<437F7FED.8040501@computing-services.oxford.ac.uk>
Message-ID: 

Lou Burnard  writes:

> Syd Bauman wrote:
>
>> 
>>>Now it is essential that we move along quickly to get our schemes
>>>registered. I think Syd would be the right person to ask to submit
>>>our proposal. You will need a public access account of the W3C for
>>>this, for which you apply at [1].
>> OK. I'll plan to work on this very soon; hopefully will start
>> tonight, finish tomorrow.
>> 
>
> Hold on there a minute. I hate to sound like a wet blanket, but I
> really don't think this is more urgent than completing the class
> work. That may be because I don't know exactly what it is that you are
> expecting Syd to do , of course, but my belief remains that the
> highest priority at the moment is for the editors to complete the work
> initiated in Oxford, and not to be distracted by other considerations.
>

Syd first has to apply for an account, which should not take more than
five minutes.

> I am also a bit worried that we should be sending off proposals to the
> W3C, of any kind, which have not actually been seen by the COuncil as
> yet. Or were these "schemes" seen so long ago that I have forgotten
> them already?

Please have a look at 

http://www.tei-c.org/P5/Guidelines/SA.html#SATS

As Syd said, we need to register the names most urgently, since that
is a first-come, first served situation.  But I would also like to ask
Council members to look at the above again and raise any concerns or
issues that needs updating.

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  Sun Nov 20 20:14:17 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Mon, 21 Nov 2005 10:14:17 +0900
Subject: [tei-council] classy measurements
In-Reply-To: <17279.46405.734463.561853@emt.wwp.brown.edu> (Syd Bauman's
	message of "Sat, 19 Nov 2005 18:29:09 -0500")
References: <17279.46405.734463.561853@emt.wwp.brown.edu>
Message-ID: 

Syd Bauman  writes:

> unit symbols
> ---- -------
> First, there is the question as to what to recommend people use as
> the symbol for a variety of common units. In general, our goal is to
> depend on outside standards wherever reasonable. Symbols for units
> seems like a great place for TEI to say only what's necessary, and
> point to other standards for the rest. The problem is, there are lots
> of standards out there, and they often disagree, usually subtly. At a
> minimum, there's
>
[...]

> Several of these were invented without consideration of machine
> interchange of data; several were invented specifically to address
> machine interchange of data *using limited character sets*. But none
> of them seem to address how to perform machine interchange of data
> *using Unicode* (even Unicode itself; I can pretty easily find the
> code-points and names of various characters, but not much about their
> semantics and intended use).
>
> This is a bit of a problem, because we (alright, I) would like some
> guidance on which, if any, of the Unicode characters for unit symbols
> should be used. E.g., Unicode seems to suggest that the double-prime
> character (U+2033) be used for inches or seconds, and there are
> characters for degrees Celsius, ounces, and angstroms. Also there are
> a lot of characters that look like they are designed for specific
> unit use, but I haven't been able to find out for sure. The names are
> a bit odd, and they're in the CJK compatibility block. E.g., U+3392
> looks like it would be used for megahertz. (See, e.g.,
> http://www.fileformat.info/info/unicode/char/3392/index.htm)

As a general principle, compatibility characters are in Unicode for
compatibility with pre-existing standards, for the purpose of allowing
text encoded in these other encodings converted back and forth to
Unicode.   The should *never* be used in text that started life in
Unicode.  For that reason, we should not recommend the use of any of
these at all.  

Now with respect to the problem you have here, that is, assigning
single codepoints to units of measurement, this is something the
Unicode consortium deliberately avoided, except for these
compatibility characters.  Therefore you will find for each of these
compatibility characters a mapping to a codepoint sequence that should
be used in lieu of this single codepoint.  In the case you cite,
e.g. U+3392, this is the sequence 004D M 0048 H 007A z, which expands
to "MHz".  

I think this was a sensible decision and am very glad the UTC avoided
the mistake of some other standard bodies to assign codepoints to
standard units, it makes our life much easier in this respect.  It
would therefore enough to us to recommend the SI endorsed abbreviation
of the unit, IMHO.

> Furthermore, this specification is very detailed. E.g., in some cases
> it forces differentiation of which standard a unit comes from. So,
> e.g., there are three different symbols for "inch":
>
>  [in_i] = inch, international = 2.54 cm
>  [in_us] = the inch as used in USA from 1893 to 1959 = m/39.37
>  [in_br] = the British imperial inch = 2.539998 cm
>
> Not only are these symbols ugly and cumbersome, I think the *vast*
> majority of TEI users do not care which inch they're using. So to be
> forced to pick one would be an annoying burden.
>
>
> Unless someone knows more about this or has a better idea, I'm going
> to suggest that for now the documentation for this class should list
> some of the most common symbols in the "suggested values include"
> list, and suggest users refer to a standard, and list a bunch of
> possible standards (perhaps in the bibliography).

If you look at the Unicode codepoint area U+3380 to 33DF you see a
pretty long list -- do you really want to include them all?  I think
it would be better to just state the general principle in the tagdoc
and point to a list where these codes are enumerated.

>
> Later, after we've finished straightening out the classes, I think 2
> or 3 of us should come up with a concrete proposal for how to encode
> units in a Unicode environment. How to put such a proposal into a
> tagdoc file is another problem entirely (which I foreshadowed with
> "problems with our declaration system", above :-), because the values
> of ident= of  need to be xsd:Names. This suggestion defers
> having to deal with this, too.

See above.  none of our business, luckily.

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  Mon Nov 21 10:28:11 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Mon, 21 Nov 2005 10:28:11 -0500
Subject: [tei-council] classy measurements
In-Reply-To: 
References: <17279.46405.734463.561853@emt.wwp.brown.edu>

Message-ID: <17281.59275.939497.508402@emt.wwp.brown.edu>

> As a general principle, compatibility characters are in Unicode for
> compatibility ... we should not recommend the use of any of these
> at all.

Good. That knocks one set of problems off the list, and I was mighty
suspicious of those characters, anyway.

> Now with respect to the problem you have here, that is, assigning
> single codepoints to units of measurement,

Just want to make clear ... I am not *trying* to assign single
code-point symbols to units of measurement: I am trying to assign the
*right* symbols to units of measurement. I'm actually kinda pleased
those compatibility characters aren't the right ones to use. In
general I prefer the SI symbols when they're available.

> If you look at the Unicode codepoint area U+3380 to 33DF you see a
> pretty long list -- do you really want to include them all?

Uhhh... no, not at all. I only want to include a few units for now
(which is why I said "list some of the most common symbols"), but
more importantly these are all compatibility characters, and thus off
the table, are they not?

>  I think it would be better to just state the general principle in
> the tagdoc and point to a list where these codes are enumerated.

As I said, this is the general goal, but I haven't found a single,
one-stop-shopping document we can point to.

> > Later, after we've finished straightening out the classes, I
> > think 2 or 3 of us should come up with a concrete proposal for
> > how to encode units in a Unicode environment. How to put such a
> > proposal into a tagdoc file is another problem entirely (which I
> > foreshadowed with "problems with our declaration system", above
> > :-), because the values of ident= of  need to be
> > xsd:Names. This suggestion defers having to deal with this, too.
> 
> See above. none of our business, luckily.

I'm sorry, I don't understand what part you don't think we should be
worrying about. If we don't give TEI users advice on how to encode
units, who will?

Remember, it's not obvious; furthermore it's often arbitrary. In such
cases, the world is generally better off if we all agree on one
particularly arbitrary representation, so they're all the same. E.g.,
it would be a lot nicer if *everyone* used "in" instead of some TEI
folks using "in", some using "inch", and some using "inches".

From nil at scorpio.services.brown.edu  Mon Nov 21 16:15:42 2005
From: nil at scorpio.services.brown.edu (nil at scorpio.services.brown.edu)
Date: Mon, 21 Nov 2005 16:15:42 -0500
Subject: [tei-council] TEI XPointer scheme names submitted to W3C for
	registration
Message-ID: <17282.14590.694464.747657@emt.wwp.brown.edu>

The TEI scheme names have been submitted to the W3C for consideration
for the registry. See
http://www.w3.org/2005/04/xpointer-schemes/

From wittern at kanji.zinbun.kyoto-u.ac.jp  Mon Nov 21 17:59:10 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 22 Nov 2005 07:59:10 +0900
Subject: [tei-council] classy measurements
In-Reply-To: <17281.59275.939497.508402@emt.wwp.brown.edu> (Syd Bauman's
	message of "Mon, 21 Nov 2005 10:28:11 -0500")
References: <17279.46405.734463.561853@emt.wwp.brown.edu>

	<17281.59275.939497.508402@emt.wwp.brown.edu>
Message-ID: 

Syd Bauman  writes:

>> If you look at the Unicode codepoint area U+3380 to 33DF you see a
>> pretty long list -- do you really want to include them all?
>
> Uhhh... no, not at all. I only want to include a few units for now
> (which is why I said "list some of the most common symbols"), but
> more importantly these are all compatibility characters, and thus off
> the table, are they not?

Well, I mentioned this not to use the codepoints, but as an instance
of an enumeration of units for measurements.  And you have all the
*standard denominations* in the mapping to expansions. 
>> > Later, after we've finished straightening out the classes, I
>> > think 2 or 3 of us should come up with a concrete proposal for
>> > how to encode units in a Unicode environment. How to put such a
>> > proposal into a tagdoc file is another problem entirely (which I
>> > foreshadowed with "problems with our declaration system", above
>> > :-), because the values of ident= of  need to be
>> > xsd:Names. This suggestion defers having to deal with this, too.
>> 
>> See above. none of our business, luckily.
>
> I'm sorry, I don't understand what part you don't think we should be
> worrying about. If we don't give TEI users advice on how to encode
> units, who will?

My comment related only to the part *in a Unicode environment*, which
does not really make a difference here.  Advice and examples is
needed, of course.

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 Dec  9 08:13:00 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 09 Dec 2005 22:13:00 +0900
Subject: [tei-council] Council telecon 2005-12-16 at 1200 UTC: preparations,
	agenda items
Message-ID: 

Dear Council members,

As you know, we will hold our next teleconference call the next
Friday, December 16th, the time has changed from our usual 1300 UTC to
1200 UTC to make it slightly less inconvenient for our new member
Conal Tuohy from New Zealand to participate.  Apologies to those for
whom the new time is less convenient.

John, could I ask you to make the necessary technical arrangements for
the call and post an announcement here how to connect.

Also, as usual, please send me any agenda items you might have.
Please report on progress of action items (see
http://www.tei-c.org/Council/tcm19.xml?style=printable for the minutes
from our last call and
http://www.tei-c.org/Council/tcm20.xml?style=printable for the "Class
actions"), preferably to the list *before* the call, but we will also
make the usual review of actions at the beginning.  It would be nice,
if Lou and/or Syd could give us a brief "State of P5" address, again
preferably in writing to the list.

The season being what it is, I expect everybody to be occupied with
other things, so I hope we can be brief on the call (for the
newcomers: we usually plan for 60 minutes, but end up taking around
90, the record being around 120).

All the best,

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 Dec  9 14:13:21 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 9 Dec 2005 14:13:21 -0500
Subject: [tei-council] 6 of 7 TEI XPointer scheme names registered
Message-ID: <17305.55121.868097.610301@emt.wwp.brown.edu>

I am pleased to report that 6 of the 7 XPointer Scheme scheme names
the TEI submitted for registration have been registered without
comment. The 7th, "xpath()", is currently under discussion on the
relevant W3c list, the question being should it be "xpath()" or
"xpath1()". I have sent mail to the list basically saying that I
don't think the TEI cares which it is, but it hasn't been posted yet.
(I think this falls squarely into the class of things for which the
actual answer doesn't matter, so long as we all agree on it.)

From jawalsh at indiana.edu  Tue Dec 13 07:10:51 2005
From: jawalsh at indiana.edu (John A. Walsh)
Date: Tue, 13 Dec 2005 07:10:51 -0500
Subject: [tei-council] Conference Call Instructions
Message-ID: 

Hi all,

Please see below for conference call instructions.

John

---

You have been invited to participate in a Conference Call on  
12/16/2005 from 12:00:00 to 14:00:00 UCT.

The Conference Access Information is listed below:

Conf Id:		2947
Date:		12/16/2005
Begin Time:	12:00:00 UCT
End Time:	14:00:00 UCT
Voice Status:	Active
Announcement
	Entry:	Tone Only
	Exit:	Tone Only
Access Type:	PIN
Attendee Type:	Guest

Phone Number:	(812) 856-3600
PIN:		000920#

This email was automatically generated by the  IU UITS Conference  
system. Please do not reply to this message.

For conferencing assistance please call 812-855-4848.

--
| John A. Walsh
| Associate Director for Projects and Services, Digital Library Program
| Associate Librarian, University Libraries
| Adjunct Associate Professor, Department of English
| Indiana University, 1320 East Tenth Street, Bloomington, IN 47405
| Voice:812-855-8758 Fax:812-856-2062 

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Dec 13 20:20:04 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Wed, 14 Dec 2005 10:20:04 +0900
Subject: [tei-council] draft agenda for TEI council telecon 2005-12-16 1200
	UTC
Message-ID: 

TEI Council Members and Editors:

This is the draft agenda for the conference call the TEI Council will
hold Friday, December 16th, 2005 at 1200 UTC.

Please read through the following, in advance of the call.  

INSTRUCTIONS for conference call:

Participants will dial in to +1-812-856-3600

The Conference Access Information is listed below:

Conf Id:        2974
Date:        12/16/2005

PIN:        000920#

Expected members to participate:

Syd Bauman, Alejandro Bia, David Birnbaum, Lou Burnard, James
Cummings, Matthew Driscoll, Dot Porter, Susan Schreibman, Sebastian
Rahtz, Laurent Romary, Natasha Smith, Conal Tuohy, John Walsh, Perry
Willett, Christian Wittern, Matthew Zimmerman

(please alert me if I did forget anyone!)

Edward Vanhoutte excused himself and is busy working on his thesis while we talk.

In addition to the voice connection, we also expect to communicate via
IRC. Instructions to connect are as follows (quoted from James
Cumming's message):

Ok, on the day of the council call I'll set up a password (or 'key')
protected channel called #tei-council the joining instructions are the
same and I'd still suggest joining the #tei-c one.  Once there type:
/join #tei-council 2expensive
and in most IRC clients that will get you there.

(instructions also at: http://www.tei-c.org.uk/wiki/index.php/IRC)

Agenda:

7 items, ca 5-20 minutes apiece.

-----------------------------------------------------

1) Review of the minutes and action items (10 min)

   Minutes of the meeting are at
	 http://www.tei-c.org/Council/tcm19.html and
	 http://www.tei-c.org/Council/tcm20.html
	 To speed up the review of action items, *please report to the
	 council list* before the call as far as possible! 

	 We will discuss the reports during the call as necessary.

------------------------------------------------------------

2) Review of WG etc. progress (10 min) : 

-----------------------------------------------------

3) Proposal for new prosopography WG

  As discussed on the Council list, a new prosopography WG has been
  proposed.  I would like to take the necessary steps for starting the
  WG, that is finding a chair, writing up the charge, find members and
  start work.

4) P5 progress:  (20 min)

- on attributes and datatypes

- on classes

- other changes

-----------------------------------------------------

5) Other business  (5 minutes)

 TBA

-----------------------------------------------------

6) Meetings: (5 minutes)

   Next teleconference: Mid February, please have your diarys ready. 

   Council meeting 2006?

-- 
 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 Dec 14 00:03:42 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Wed, 14 Dec 2005 18:03:42 +1300
Subject: [tei-council] encoding page scans
Message-ID: 

Afternoon all! My first post on the TEI Council list is about encoding
images of page scans in TEI. 

A couple of months ago Jamie Norrish started a short thread on TEI-L
about this issue, but I don't feel that the issue has been adequately
addressed. Of course, it may be that I've missed something in P5 and
that this is now all sorted. I hope so :-)

If I haven't missed anthing, then at the moment there isn't a really
good way to encode these scans (they are not figures, but graphics
having a different relationship to the text). Many people are encoding
these in TEI, but there's no consensus on how to do it. Recently I've
come across another TEI customisation in which the URIs of scanned pages
are encoded as pb/@url. I've seen others in which it is encoded as
pb/@entity (a reference to an unparsed entity, like P4's
figure/@entity). There are other practices in use too. 

At the NZETC we are encoding page scans (in P4) using a list of figure
elements inside a note in the TEI.2/teiHeader/fileDesc/noteStmt, each of
which is linked to the corresponding pb element with a @corresp. It
seems awkward (to put it mildly) to encode the figures in a notesStmt,
but it seemed preferable to encoding them as part of the text (as had
been our practice). 

Of course METS provides one solution. But it seems like overkill to add
a METS wrapper around a TEI file just to support a single feature which
(to me) seems already like a natural piece of TEI, and which has several
times been hacked into TEI anyway. In the earlier thread, Christian
argued that the images were alternate representations of the whole text,
and hence didn't belong in the file at all. I can see his point (I
think), but I don't find it convincing. 

Can we establish a standard mechanism in TEI for this purpose? Off the
top of my head I would prefer to nest a graphic element inside a pb, but
to me the important thing is just that some simple mechanism is provided
within the standard TEI schema without customisation.

Cheers

Con

PS incidentally, I note that graphic/@scale has type data.probability.
Shouldn't this be a real number? 

--
Conal Tuohy
Senior Programmer
+64-4-463-6844
+64-21-237-2498
conal at nzetc.org
New Zealand Electronic Text Centre
www.nzetc.org

From sebastian.rahtz at oucs.ox.ac.uk  Wed Dec 14 04:09:52 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 14 Dec 2005 09:09:52 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: 
References: 
Message-ID: <439FE160.10701@oucs.ox.ac.uk>

I agree, its a running sore.

Don't forget, by the way, that for some people  points forward, for 
others it points back.
If we all used , that would need clearing up too.

Your "list of figure elements inside a note in the TEI.2/teiHeader/fileDesc/noteStmt" seems to me closer
to the right way. I'm with Christian, in the idea of a complete parallel document.

The question is not "what is the answer", but "what mechanism shall we use
to establish the answer".....

Sebastian

From lou.burnard at computing-services.oxford.ac.uk  Wed Dec 14 09:58:53 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Wed, 14 Dec 2005 14:58:53 +0000
Subject: [tei-council] measured and measurement
Message-ID: <43A0332D.2030404@oucs.ox.ac.uk>

The MS module defines an attribute class "measured" which adds 
attributes "unit" and "scope" to a number of elements.

The ST module defines an attribute class "measurement" which adds 
attributes "unit" "quantity" and "commodity"

There is evidentluy some overlap here, but I'm not sure how best to 
resolve it.

Constructive suggestions would be welcomed.

From dporter at uky.edu  Wed Dec 14 11:27:02 2005
From: dporter at uky.edu (Dot Porter)
Date: Wed, 14 Dec 2005 11:27:02 -0500
Subject: [tei-council] encoding page scans
In-Reply-To: 
References: 
Message-ID: <96f3df640512140827o3876ddc8s30c6e45bd8a793e5@mail.gmail.com>

I agree that it is be preferable to provide image file references via
indexing - either through a  METS file or a list of files in the TEI
Header -  rather than including them in the text encoding itself using
something like pb/@url. My main reason is that a single page in TEI
may point to multiple scanned images - the same manuscript page under
different lighting conditions, for example. Building those links into
the pb element would make it cumbersome to link one encoded page to
several different files, while a index could group images of the same
page together providing a single reference for the pb.

Going a step further, what if we want to create relationships between
areas of that page scan and the corresponding range in the TEI text?
Is this something that the TEI should cover, or is it better to rely
on other standards (METS, SVG)? The Edition Production Technology[1]
depends on @coords, which can be added to any tag and which indicates
where the tag contents reside on the image. Unfortunately this only
allows for one set of coordinates, even if there are multiple image
files for the same page. For another project, I've been working on a
system for encoding multiple sets of coordinates in a METS Structural
Map (stored in a separate file, rather than as a wrapper for the TEI),
and it seems to work pretty well. The UVic Image Markup Tool[2] uses
SVG within the TEI body to link to both file and coordinates; another
approach might be to have a TEI module for incorporating image files
and their areas in a project.

Dot

[1] http://beowulf.engl.uky.edu/~eft/EPPT-Demo.html
[2] http://www.tapor.uvic.ca/~mholmes/image_markup/

On 12/14/05, Conal Tuohy  wrote:
> Afternoon all! My first post on the TEI Council list is about encoding
> images of page scans in TEI.
>
> A couple of months ago Jamie Norrish started a short thread on TEI-L
> about this issue, but I don't feel that the issue has been adequately
> addressed. Of course, it may be that I've missed something in P5 and
> that this is now all sorted. I hope so :-)
>
> If I haven't missed anthing, then at the moment there isn't a really
> good way to encode these scans (they are not figures, but graphics
> having a different relationship to the text). Many people are encoding
> these in TEI, but there's no consensus on how to do it. Recently I've
> come across another TEI customisation in which the URIs of scanned pages
> are encoded as pb/@url. I've seen others in which it is encoded as
> pb/@entity (a reference to an unparsed entity, like P4's
> figure/@entity). There are other practices in use too.
>
> At the NZETC we are encoding page scans (in P4) using a list of figure
> elements inside a note in the TEI.2/teiHeader/fileDesc/noteStmt, each of
> which is linked to the corresponding pb element with a @corresp. It
> seems awkward (to put it mildly) to encode the figures in a notesStmt,
> but it seemed preferable to encoding them as part of the text (as had
> been our practice).
>
> Of course METS provides one solution. But it seems like overkill to add
> a METS wrapper around a TEI file just to support a single feature which
> (to me) seems already like a natural piece of TEI, and which has several
> times been hacked into TEI anyway. In the earlier thread, Christian
> argued that the images were alternate representations of the whole text,
> and hence didn't belong in the file at all. I can see his point (I
> think), but I don't find it convincing.
>
> Can we establish a standard mechanism in TEI for this purpose? Off the
> top of my head I would prefer to nest a graphic element inside a pb, but
> to me the important thing is just that some simple mechanism is provided
> within the standard TEI schema without customisation.
>
> Cheers
>
> Con
>
> PS incidentally, I note that graphic/@scale has type data.probability.
> Shouldn't this be a real number?
>
> --
> Conal Tuohy
> Senior Programmer
> +64-4-463-6844
> +64-21-237-2498
> conal at nzetc.org
> 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
>

--
***************************************
Dot Porter, Program Coordinator
Collaboratory for Research in Computing for Humanities
University of Kentucky
351 William T. Young Library
Lexington, KY  40506

dporter at uky.edu          859-257-9549
***************************************

From Conal.Tuohy at vuw.ac.nz  Wed Dec 14 18:01:37 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Thu, 15 Dec 2005 12:01:37 +1300
Subject: [tei-council] encoding page scans
Message-ID: 

Dot Porter wrote:

> I agree that it is be preferable to provide image file references via
> indexing - either through a  METS file or a list of files in the TEI
> Header -  rather than including them in the text encoding itself using
> something like pb/@url. My main reason is that a single page in TEI
> may point to multiple scanned images - the same manuscript page under
> different lighting conditions, for example. Building those links into
> the pb element would make it cumbersome to link one encoded page to
> several different files, while a index could group images of the same
> page together providing a single reference for the pb.

That's true. And there's different purposes (thumbnail, reference), and
formats too (e.g. JPEG, TIFF, etc)

> Going a step further, what if we want to create relationships between
> areas of that page scan and the corresponding range in the TEI text?
> Is this something that the TEI should cover, or is it better to rely
> on other standards (METS, SVG)? The Edition Production Technology[1]

I have a preference for something internal to TEI for the sake of making
it very easy to encode in the simple case. But I'm not too fussed so
long as some recommended practice is documented as part of the TEI
guidelines.

> depends on @coords, which can be added to any tag and which indicates
> where the tag contents reside on the image. Unfortunately this only
> allows for one set of coordinates, even if there are multiple image
> files for the same page. For another project, I've been working on a

The same problem as above then - the links should go from the image to
the text, rather than the other way? Or we could use link/@targets to
encode n-ary links, i.e. a single link element indicating a
correspondence between some text markup and 1 or more graphics (or
regions within graphics)? The weakness of link/@targets for multiple
links is that it doesn't attach any semantics to the different links.

> system for encoding multiple sets of coordinates in a METS Structural
> Map (stored in a separate file, rather than as a wrapper for the TEI),
> and it seems to work pretty well. 

I'm sure it does :-) and I've read the METS profiles for doing it[1]
though I've never done it myself ... but do you think it should really
be necessary to go to these lengths? It seems to me that we could use
METS to handle TEI figure elements too. Page scans are a different level
of description of the text from figures, but TEI is full of different
analytical levels of all kinds, so I don't find that argument convincing
in itself. But I suppose I could be convinced :-) The main thing, to my
mind, is that the guidelines should clearly document some standard
practice that doesn't involve treating page scans as figures, or making
custom extensions to the TEI schema.

Dot, could you post a little example of the METS and TEI markup you are
using to associate an image file with a TEI page?

> The UVic Image Markup Tool[2] uses
> SVG within the TEI body to link to both file and coordinates; 

That's an interesting example. I agree that inline SVG could be a good
way to mark up regions within a graphic. Just a quibble, though: in your
example, is the link between the graphical region and the text
represented by a purely conventional correspondence between the @n and
the @xml:id attributes? In the guidelines it suggest using a ptr to
provide a TEI-namespaced proxy for the SVG region, then linking the ptr
and the text markup with a TEI  element. 

> another
> approach might be to have a TEI module for incorporating image files
> and their areas in a project.

This last is the approach I think I would prefer. One of my criteria for
such a feature would be that in the simplest case it should be dead easy
to associate a page image with a page. Whereas the METS approach is
perfectly capable, but it's probably not so convenient for encoders, I
would guess. Having a separate file is an extra hassle, for a start,
though perhaps a "METS" TEI module could be produced which would add
METS as a root element, and introduce the TEI element embedded in the
METS structure map? Could the same be done with SVG? That could be a way
to at least provide recommended encoding mechanisms defined using the
standard TEI customisation practice.

Cheers

Con

[1] http://www.loc.gov/standards/mets/profiles/00000005.xml

From Conal.Tuohy at vuw.ac.nz  Wed Dec 14 18:03:15 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Thu, 15 Dec 2005 12:03:15 +1300
Subject: [tei-council] encoding page scans
Message-ID: 

Sebastian Rahtz wrote:

> Your "list of figure elements inside a note in the 
> TEI.2/teiHeader/fileDesc/noteStmt" seems to me closer
> to the right way. 

Perhaps something could be added to the Source Description, rather than
the Notes Statement? That might be a better place to encode references
to page scans, and then standard linking mechanisms (link, @corresp,
whatever) could be used to align them to pages.

"The  element is the seventh and final component of the
 element. It is a mandatory element, and is used to record
details of the source or sources from which a computer file is derived.
"

e.g.

	...

		...

> I'm with Christian, in the idea of a 
> complete parallel document.

Though there's a considerable extra burden to encoders that way, I
think.

> The question is not "what is the answer", but "what mechanism 
> shall we use
> to establish the answer".....

I'm not sure if I understand that ... could you clarify? I'm sorry if
I'm not going about this in the correct way ... I am new here :-)

Con

From sebastian.rahtz at oucs.ox.ac.uk  Wed Dec 14 18:15:31 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 14 Dec 2005 23:15:31 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: 
References: 
Message-ID: <43A0A793.5000408@oucs.ox.ac.uk>

Conal Tuohy wrote:

>
>
>	...
>	
>		
>			
>		
>		
>			
>		
>		...
>	
>
>  
>
not sure about , but something like that, yes

>I'm not sure if I understand that ... could you clarify? I'm sorry if
>I'm not going about this in the correct way ... I am new here :-)
>
>
>  
>
What I am saying is that we should not attempt to solve this
solely within the TEI Council, but should consult more widely.
How do we do that? by a work group? a SIG?

-- 
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 Dec 14 18:24:33 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Wed, 14 Dec 2005 23:24:33 +0000
Subject: [tei-council] measured and measurement
In-Reply-To: <43A0332D.2030404@oucs.ox.ac.uk>
References: <43A0332D.2030404@oucs.ox.ac.uk>
Message-ID: <43A0A9B1.6050703@oucs.ox.ac.uk>

Lou Burnard wrote:

> The MS module defines an attribute class "measured" which adds 
> attributes "unit" and "scope" to a number of elements.
>
> The ST module defines an attribute class "measurement" which adds 
> attributes "unit" "quantity" and "commodity"
>
> There is evidentluy some overlap here, but I'm not sure how best to 
> resolve it.
>
quantity, commodity and scope seem to be distinct, and unit is the same. 
so why don't
you just merge them?

-- 
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 Dec 14 19:57:33 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop)
Date: Thu, 15 Dec 2005 00:57:33 +0000
Subject: [tei-council] (very) Brief status report on P5 
Message-ID: <43A0BF7D.6040102@computing-services.oxford.ac.uk>

[Syd may want to add to this]

1. During October there was extensive work on attributes and datatypes, 
which was completed in time for a release of P5 (0.2.1) to take place on 
the 21st.

2. During November, the priority was to work on classes. A detailed 
programme of work was agreed following the Council meeting in Oxford, 
and is now complete. Full details of the changes made are available from 
http://www.tei-c.org/Drafts/edw92.xml

3. Some outstanding issues remain on the class front, in particular  
there is still need for a  review of many chapters not discussed at the  
Oxford meeting.  Enough work has been done, however, to proceed to the 
revision of chapter ST, which is the next priority.

4. In December, Matthew Driscoll visited Oxford, resulting in a number 
of minor corrections to the MS chapter.

5. A new "listPerson" element has been introduced to facilitate encoding 
of "personographical" data: this was tested on some data supplied by 
Matthew which now forms a new component of the test suite.

6. New material for inclusion in chapters SA and NH has been received 
but not yet reviewed by both editors.

in haste

Lou

From dporter at uky.edu  Thu Dec 15 17:38:52 2005
From: dporter at uky.edu (Dot Porter)
Date: Thu, 15 Dec 2005 17:38:52 -0500
Subject: [tei-council] encoding page scans
In-Reply-To: 
References: 
Message-ID: <96f3df640512151438n226bde3btd50baad9f7d5513e@mail.gmail.com>

Hi Conal,

Some comments on your comments...

On 12/14/05, Conal Tuohy  wrote:
> Dot Porter wrote:
>

> > depends on @coords, which can be added to any tag and which indicates
> > where the tag contents reside on the image. Unfortunately this only
> > allows for one set of coordinates, even if there are multiple image
> > files for the same page. For another project, I've been working on a
>
> The same problem as above then - the links should go from the image to
> the text, rather than the other way? Or we could use link/@targets to
> encode n-ary links, i.e. a single link element indicating a
> correspondence between some text markup and 1 or more graphics (or
> regions within graphics)? The weakness of link/@targets for multiple
> links is that it doesn't attach any semantics to the different links.
>

Oh, I don't really like this idea for the very same reason you give -
I'd rather have a linking system where the relationships between the
text and image are defined, rather than just noted. (I've actually
stopped using linkGrp/link completely... I use METS instead...)

> > system for encoding multiple sets of coordinates in a METS Structural
> > Map (stored in a separate file, rather than as a wrapper for the TEI),
> > and it seems to work pretty well.
>
> I'm sure it does :-) and I've read the METS profiles for doing it[1]
> though I've never done it myself ... but do you think it should really
> be necessary to go to these lengths?

I rather hope it isn't *necessary* but it does seem to work - though
it is incredibly intensive on the encoding side. I've just built a
small sample of material, using oXygen, and taking coordinates from
EPT and PhotoShop. It would be impossible to do more without special
software support.

 The main thing, to my
> mind, is that the guidelines should clearly document some standard
> practice that doesn't involve treating page scans as figures, or making
> custom extensions to the TEI schema.
>
yes, yes, yes

> Dot, could you post a little example of the METS and TEI markup you are
> using to associate an image file with a TEI page?
>

Boy, okay. The project is an edition of the Venetus A manuscript - the
earliest surviving copy of the Iliad, containing the main text plus
several layers of annotation.

Much simplified: First, we encode the main text and the annotations
separately (in separate documents, one document per book). In the main
text, the poetic lines () are assigned IDs based on the book and
line number - for example, Book 4 line 537 has xml:id="book.4.537".
IDs for the annotations are assigned based on the type of annotation
(marginal, interlinear, etc.), book number, the group number
(annotations are in groups of two or more), and then the number of the
specific annotation in a group. So an ID for a group of marginal
annotations would be xml:id="m.4.15", while the first annotation in
the group would be xml:id="m.4.15.1".

In the METS file, there are three file groups: two for the TEI files
and one for the facsimile scans. Each file is assigned its own ID. We
then use structural maps to link the text with the corresponding
image. In this example, we note the location (using COORDS) of the
first group of annotations in book 4 on the image:

FILEID links up to the file groups; COORDS records the coordinates on
the image file; BEGIN records the xml:id of the line in the TEI file
(multiple lines would have both BEGIN and END).

I also have a .pdf presentation that I put together in the hopes that
I wouldn't completely confuse the non-tech editors. The .zip file also
includes a sample METS file:
http://www.rch.uky.edu/Venetus/Venetus-METS.zip

> > The UVic Image Markup Tool[2] uses
> > SVG within the TEI body to link to both file and coordinates;
>
> That's an interesting example. I agree that inline SVG could be a good
> way to mark up regions within a graphic. Just a quibble, though: in your
> example, is the link between the graphical region and the text
> represented by a purely conventional correspondence between the @n and
> the @xml:id attributes? In the guidelines it suggest using a ptr to
> provide a TEI-namespaced proxy for the SVG region, then linking the ptr
> and the text markup with a TEI  element.
>
Well unfortunately as it is now, the system that the UVic IMT uses
doesn't actually link the graphical region and text on anything other
than the page-level - it's really a tool (and a markup system) for
annotating image areas, rather than a tool for linking images to text.
I think that the concept of combining SVG with TEI has applications
for the question at hand, though.

> > another
> > approach might be to have a TEI module for incorporating image files
> > and their areas in a project.
>
> This last is the approach I think I would prefer. One of my criteria for
> such a feature would be that in the simplest case it should be dead easy
> to associate a page image with a page. Whereas the METS approach is
> perfectly capable, but it's probably not so convenient for encoders, I
> would guess.

I would not call it "convenient", no. But I've had fun with it.

> Having a separate file is an extra hassle, for a start,

Yes.

> though perhaps a "METS" TEI module could be produced which would add
> METS as a root element, and introduce the TEI element embedded in the
> METS structure map?

This is interesting. Or a METS structural map in the TEI Header?

Could the same be done with SVG? That could be a way
> to at least provide recommended encoding mechanisms defined using the
> standard TEI customisation practice.
>

I don't know. But I do think that we'll be better off if we do take a
good look at what's already out there for describing images (METS, SVG
- others?) and get together a group of people who have been thinking
about these issues. So to Sebastian's last question - I think a work
group would be a useful step.

Talk to y'all tomorrow!

Dot

> Cheers
>
> Con
>
> [1] http://www.loc.gov/standards/mets/profiles/00000005.xml
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

--
***************************************
Dot Porter, Program Coordinator
Collaboratory for Research in Computing for Humanities
University of Kentucky
351 William T. Young Library
Lexington, KY  40506

dporter at uky.edu          859-257-9549
***************************************

From lou.burnard at computing-services.oxford.ac.uk  Thu Dec 15 18:31:07 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 15 Dec 2005 23:31:07 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: <96f3df640512151438n226bde3btd50baad9f7d5513e@mail.gmail.com>
References: 
	<96f3df640512151438n226bde3btd50baad9f7d5513e@mail.gmail.com>
Message-ID: <43A1FCBB.60907@computing-services.oxford.ac.uk>

> 
>  The main thing, to my
> 
>>mind, is that the guidelines should clearly document some standard
>>practice that doesn't involve treating page scans as figures, or making
>>custom extensions to the TEI schema.
>>
> 
> yes, yes, yes
> 
> 

No no no! In P5 we have a generic  and a generic  
element which could surely be used to mark the presence of a pagescan if 
you like. Whether you want to wrap them up in a (P5)   or in 
something else is a different question, of course. Also, at P5, you 
can't use the TEI without doing some kind of "custom extensions", so 
there's nothing to be afraid of there!

>>Dot, could you post a little example of the METS and TEI markup you are
>>using to associate an image file with a TEI page?
>>
> 

[details snipped]

> 
>   
>     
>       
>         
>       
>       
>         
>       
>     
> 
> FILEID links up to the file groups; COORDS records the coordinates on
> the image file; BEGIN records the xml:id of the line in the TEI file
> (multiple lines would have both BEGIN and END).

This seems to confuse two different things: the first  is pointing 
to an area, and second one to a sequence of lines, isn't it?

In P5, you can use a URI to point in either case, so the syntax is 
likely to be a lot less verbose tho not particularly more perspicuous.

Then you could either use the corresp attribute to say that the two 
things correspond, or a standoff  to associate them.

>>>The UVic Image Markup Tool[2] uses
>>>SVG within the TEI body to link to both file and coordinates;
>>

I think we're using the word "link" in a different sense here. SVG is an 
XML notation, albeit from a different namespace, so you can just embed 
it within your TEI document if you like. And indeed we have examples 
which do.

>>That's an interesting example. I agree that inline SVG could be a good
>>way to mark up regions within a graphic. Just a quibble, though: in your
>>example, is the link between the graphical region and the text
>>represented by a purely conventional correspondence between the @n and
>>the @xml:id attributes? In the guidelines it suggest using a ptr to
>>provide a TEI-namespaced proxy for the SVG region, then linking the ptr
>>and the text markup with a TEI  element.
>>

That's sort of what I said above, except that I wasn't talking about SVG!

Another thing to throw into the pot: There are formats like DjaVu which 
embed in a single object a compressed page image and an XML transcript 
of it. Anyone got any views on how that affects these issues?

p.s. shouldnt this conversation be going on on tei-l?

From lou.burnard at computing-services.oxford.ac.uk  Thu Dec 15 18:37:51 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Thu, 15 Dec 2005 23:37:51 +0000
Subject: [tei-council] measured and measurement
In-Reply-To: <43A0A9B1.6050703@oucs.ox.ac.uk>
References: <43A0332D.2030404@oucs.ox.ac.uk> <43A0A9B1.6050703@oucs.ox.ac.uk>
Message-ID: <43A1FE4F.6050007@computing-services.oxford.ac.uk>

Sebastian Rahtz wrote:

> Lou Burnard wrote:
> 
>> The MS module defines an attribute class "measured" which adds 
>> attributes "unit" and "scope" to a number of elements.
>>
>> The ST module defines an attribute class "measurement" which adds 
>> attributes "unit" "quantity" and "commodity"
>>
>> There is evidentluy some overlap here, but I'm not sure how best to 
>> resolve it.
>>
> quantity, commodity and scope seem to be distinct, and unit is the same. 
> so why don't
> you just merge them?
> 

The trouble is that qty, unit, cdty all relate to a single measurement 
e.g. "one hogshead of boiling oil" whereas scope is used to summarize 
the applicability of the qty and unit across a number of measurements
e.g. "14 picas in most cases". I suppose I might want to say something 
like "15 hogsheads of boiling oil, mostly " to mean that some of the 
hogsheads were a bit lukewarm, maybe, or contained something other than 
oil, but it's a bit of a stretch.

From Conal.Tuohy at vuw.ac.nz  Thu Dec 15 18:56:24 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Fri, 16 Dec 2005 12:56:24 +1300
Subject: [tei-council] encoding page scans
Message-ID: 

Conal:

> >  The main thing, to my
> > 
> >>mind, is that the guidelines should clearly document some standard
> >>practice that doesn't involve treating page scans as 
> figures, or making
> >>custom extensions to the TEI schema.

Dot:
> > yes, yes, yes

Lou:
> No no no! In P5 we have a generic  and a generic  
> element which could surely be used to mark the presence of a 
> pagescan if 
> you like. Whether you want to wrap them up in a (P5)   or in 
> something else is a different question, of course. 

Page scans are surely not figures?

What are the intended semantics of  when not contained in a
? Should  be reserved for formal figures, and bare
 used for everything else? 

I haven't seen the  element ... I will take a look.

> Also, at P5, you 
> can't use the TEI without doing some kind of "custom extensions", so 
> there's nothing to be afraid of there!

I'm sure I don't understand what you meant by that :-) but to clarify
what I meant above: I think there should be a standard encoding in TEI
(i.e. a standard module, not one that people have to write themselves)
which defines markup for page facsimiles. 

I would be interested in the idea that a light-weight encoding practice
(such as is commonly used today) might be mapped to a more sophisticated
one using ODD. So a sophisticated module would provide a rich semantic
basis, for interchange, and a light-weight extension module could be
used as a shorthand for the common simple case of one image file per pb
element. I'm not sure how easy it is in ODD to map something simple like
 to a more generally-capable markup -
especially if the more general markup linked to graphic elements encoded
in the teiHeader or something. Do any of the ODD experts have a feel for
that? Is it feasible at all?

> p.s. shouldnt this conversation be going on on tei-l?

Perhaps?

From sebastian.rahtz at oucs.ox.ac.uk  Thu Dec 15 19:06:05 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 16 Dec 2005 00:06:05 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: 
References: 
Message-ID: <43A204ED.4050901@oucs.ox.ac.uk>

Conal Tuohy wrote:

>What are the intended semantics of  when not contained in a
>? Should  be reserved for formal figures, and bare
> used for everything else? 
>  
>
 can _contain_ , and much else besides.
You use  anywhere you want to include an external
image file, no more and no less. So if we defined ,
its child would be 

>I haven't seen the  element ... I will take a look.
>
>  
>
Lou meant , its just a way of including images
in the text by using encoding binary data

>I think there should be a standard encoding in TEI
>(i.e. a standard module, not one that people have to write themselves)
>which defines markup for page facsimiles. 
>  
>
I agree.

>I would be interested in the idea that a light-weight encoding practice
>(such as is commonly used today) might be mapped to a more sophisticated
>one using ODD. So a sophisticated module would provide a rich semantic
>basis, for interchange, and a light-weight extension module could be
>used as a shorthand for the common simple case of one image file per pb
>element. I'm not sure how easy it is in ODD to map something simple like
> to a more generally-capable markup -
>especially if the more general markup linked to graphic elements encoded
>in the teiHeader or something. Do any of the ODD experts have a feel for
>that? Is it feasible at all?
>  
>
I think I'd want to sit down with you and some scrap paper
and really get to grips with what ODD is and isn't before
I could answer that.

Would you be _very_ unhappy with a secondary TEI
document consisting of a series of  elements,
whose body would contain  elements, structured to
cover Dot's point about multiple versions? Noting that this
would allow, inter alia, for _alternative_ transcriptons in different
TEI documents, linked to this document which describes a series
of page scans?

-- 
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 Dec 15 19:09:26 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 16 Dec 2005 09:09:26 +0900
Subject: UPDATED: [tei-council] draft agenda for TEI council telecon
	2005-12-16 1200 UTC
In-Reply-To:  (Christian Wittern's
	message of "Wed, 14 Dec 2005 10:20:04 +0900")
References: 
Message-ID: 

In light of the recent discussion, I would like to modify item 3
to make it a more general consideration of future TEI development. For
the convenience of having a complete agenda in one place, I will just
quote the rest as well.   -- Chris

Christian Wittern  writes:

> TEI Council Members and Editors:
>
> This is the draft agenda for the conference call the TEI Council will
> hold Friday, December 16th, 2005 at 1200 UTC.
>
> Please read through the following, in advance of the call.  
>
>
> INSTRUCTIONS for conference call:
>
> Participants will dial in to +1-812-856-3600
>
> The Conference Access Information is listed below:
>
> Conf Id:        2974
> Date:        12/16/2005
>
> PIN:        000920#
>
> Expected members to participate:
>
> Syd Bauman, Alejandro Bia, David Birnbaum, Lou Burnard, James
> Cummings, Matthew Driscoll, Dot Porter, Susan Schreibman, Sebastian
> Rahtz, Laurent Romary, Natasha Smith, Conal Tuohy, John Walsh, Perry
> Willett, Christian Wittern, Matthew Zimmerman
>
> (please alert me if I did forget anyone!)
>
> Edward Vanhoutte excused himself and is busy working on his thesis while we talk.
>
>
> In addition to the voice connection, we also expect to communicate via
> IRC. Instructions to connect are as follows (quoted from James
> Cumming's message):
>
> Ok, on the day of the council call I'll set up a password (or 'key')
> protected channel called #tei-council the joining instructions are the
> same and I'd still suggest joining the #tei-c one.  Once there type:
> /join #tei-council 2expensive
> and in most IRC clients that will get you there.
>
> (instructions also at: http://www.tei-c.org.uk/wiki/index.php/IRC)
>
>
> Agenda:
>
> 7 items, ca 5-20 minutes apiece.
>
> -----------------------------------------------------
>
>
> 1) Review of the minutes and action items (10 min)
>
>    Minutes of the meeting are at
> 	 http://www.tei-c.org/Council/tcm19.html and
> 	 http://www.tei-c.org/Council/tcm20.html
> 	 To speed up the review of action items, *please report to the
> 	 council list* before the call as far as possible! 
> 	 
> 	 We will discuss the reports during the call as necessary.
>
>
> ------------------------------------------------------------
>
> 2) Review of WG etc. progress (10 min) : 
>   
>
> -----------------------------------------------------
>
3) Proposal for new work items

  We need to decide on where we want to go this next year.  We should have
  enough money to fund about one WG meeting (in Europe, ~6 members?)
  beside the Council meeting. 

  Proposals floating around ask for a personography task force (I take
  task force to mean, as we used the word earlier, a group charged
  with a rather specific task and a lifespan in the order of 6 months)
  and a page-linking task force.  

  Are there other areas in urgent need of attention? We need to think
  about how to prioritize this and allocate our efforts accordingly

>
> 4) P5 progress:  (20 min)
>
> - on attributes and datatypes
>
> - on classes
>
> - other changes
>
>
> -----------------------------------------------------
>
> 5) Other business  (5 minutes)
>
>
>  TBA
>
> -----------------------------------------------------
>
> 6) Meetings: (5 minutes)
>
>    Next teleconference: Mid February, please have your diarys ready. 
>    
>    Council meeting 2006?
>
>
>
>
> -- 
>  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 
 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 Dec 15 20:35:10 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Fri, 16 Dec 2005 14:35:10 +1300
Subject: UPDATED: [tei-council] draft agenda for TEI council
	telecon2005-12-16 1200 UTC
Message-ID: 

> Christian Wittern  writes:

> 3) Proposal for new work items
>  
>   We need to decide on where we want to go this next year.  
> We should have
>   enough money to fund about one WG meeting (in Europe, ~6 members?)
>   beside the Council meeting. 
> 
>   Proposals floating around ask for a personography task force (I take
>   task force to mean, as we used the word earlier, a group charged
>   with a rather specific task and a lifespan in the order of 6 months)
>   and a page-linking task force.  
> 
>   Are there other areas in urgent need of attention? We need to think
>   about how to prioritize this and allocate our efforts accordingly

I have only one other item: more explicit identification of external
vocabularies used in TEI taxonomies. 

I would like to establish guidelines for explicitly linking to external
vocabularies via URI, so that indexing and cataloguing software can more
easily merge metadata from TEI documents in bulk, i.e. to promote
commensurability of the indexes. At the moment the guidelines provide
for an external vocabulary (a ) to be identified with a bibl,
but I'd like us to endorse a way to include a URI as part of that
identity, to facilitate merging. 

It's probably an easy one I think, but it is important to us in NZ.

We need it to help us to construct a union catalogue from TEI documents
which are independently encoded and catalogued by a number of agencies.
The NZ government has recently launched a "National Digital
Strategy"[1], and things are starting to happen ... we have the prospect
that a large number of "community" agencies of all types may soon be
digitising, encoding, and cataloguing texts, so we will need some clear
guidelines soon. Also we have other agencies locally (here and in
Australia) adopting TEI for encyclopedia applications, where this is
also useful. It's also potentially useful to the Ontology SIG I would
think.

In general (and this applies to the page-facsimile issue too), we are
trying to make it easier for the National Library of NZ to adopt TEI as
a general rule for text encoding. This is not yet a fait accompli. I
think there's a risk that some half-baked (non-TEI) solution will catch
on, especially (a cynic might say) given the involvement of Microsoft[2]
(I know - I'm running a risk writing this using Microsoft Outlook!). 

That's it from me.

Cheers

Con

[1] http://www.digitalstrategy.govt.nz/
[2]
http://www.digitalstrategy.govt.nz/templates/Page____268.aspx#Can%20trai
ning%20be%20funded?

From Conal.Tuohy at vuw.ac.nz  Thu Dec 15 21:01:08 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Fri, 16 Dec 2005 15:01:08 +1300
Subject: [tei-council] encoding page scans
Message-ID: 

Sebastian Rahtz wrote: 

>  can _contain_ , and much else besides.
> You use  anywhere you want to include an external
> image file, no more and no less. So if we defined ,
> its child would be 

OK

Conal:
> >I would be interested in the idea that a light-weight 
> encoding practice
> >(such as is commonly used today) might be mapped to a more 
> sophisticated
> >one using ODD. 

Sebastian:
> I think I'd want to sit down with you and some scrap paper
> and really get to grips with what ODD is and isn't before
> I could answer that.

Hmmm ... that might take a while to arrange :-)

I'm not sure that I expressed myself that clearly - I wondered just how
far ODD's "filter" system could go in terms of mapping TEI instances to
other schemas - is there anything it can't do, in principle? 

The reason I wondered was that it seemed to me that a good general
markup solution might be considerably more verbose than a light-weight
variant , and since a light-weight style has some
value, therefore that might be a constraint on the form of the more
general markup. I will need to get to grips with ODD and try it out, but
I think it should work. 

If the standard page facsimile markup were to encode facsimile elements
in the sourceDesc (with links pointing into the text), then an ODD
customisation for a light-weight page-facsimile markup would define a
sourceDesc whose content model EXCLUDED facsimile elements, but it could
define a filter to generate those basic facsimile elements from
//pb/@url, and the links from //pb/@xml:id

Sebastian:
> Would you be _very_ unhappy with a secondary TEI
> document consisting of a series of  elements,
> whose body would contain  elements, structured to
> cover Dot's point about multiple versions? Noting that this
> would allow, inter alia, for _alternative_ transcriptons in different
> TEI documents, linked to this document which describes a series
> of page scans?

I would be very happy if that were allowed, but I would very much like
the ability to encode them in a single file, as well. I think simplicity
is a key requirement, actually. Otherwise METS is just as good, I think.

Con

From Syd_Bauman at Brown.edu  Fri Dec 16 01:06:56 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 16 Dec 2005 01:06:56 -0500
Subject: [tei-council] encoding page scans
In-Reply-To: 
References: 
Message-ID: <17314.22912.871433.552250@emt.wwp.brown.edu>

CT> PS incidentally, I note that graphic/@scale has type
CT> data.probability. Shouldn't this be a real number?

Hmmm... perhaps. Remember that data.probability is a real number
between 0 and 1 (inclusive). It is probably unreasonable to have a
negative value for scale= of , but a value > 1 may make
sense. In which case, the desired constraint is
   xsd:double { minInclusive="0" }
and no existing TEI datatype will do the job. We could
a) decide negative values are OK (what do they mean?) and use
   tei.numeric 
b) use data.numeric, and live with the fact that the schema permits
   negative values that make no sense (prose remarks and perhaps
   Schematron rules would disallow negative values)
c) use data.outputMeasurement
d) create new TEI datatype
e) use RelaxNG code directly, w/o a datatype

I don't like (c), it has the wrong semantics.

SR> Don't forget, by the way, that for some people  points
SR> forward, for others it points back. If we all used , that
SR> would need clearing up too.

How much stronger than the current "By convention,  elements
should appear at the start of the page to which they refer." do you
think we should get?

LB> p.s. shouldnt this conversation be going on on tei-l?
CT> Perhaps?

I think it should be. But the real problem is we can't just post to
TEI-L and tell people to read the archives of this discussion,
because the archives of this list are viewable by subscribers only,
and thus are closed to public scrutiny. While I suppose there may be
an occasional sensitive discussion, generally speaking I'm of a mind
that the deliberations of Council should be open.

From Syd_Bauman at Brown.edu  Fri Dec 16 01:31:25 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 16 Dec 2005 01:31:25 -0500
Subject: [tei-council] (very) Brief status report on P5 
In-Reply-To: <43A0BF7D.6040102@computing-services.oxford.ac.uk>
References: <43A0BF7D.6040102@computing-services.oxford.ac.uk>
Message-ID: <17314.24381.659915.394768@emt.wwp.brown.edu>

Thank you, Lou, for posting this. 

> [Syd may want to add to this]

Only 2 things come to mind to add, one which has occurred since Lou
posted the list.

7. Most of our XPointer scheme names have been registered with W3C. 

8. Spurred by Torsten Schassan's bug report on Sourceforge[1] I went
   through and fixed lots of phrase-level encodings in the content of
   P5, mostly by fixing type= of . Well over 120 fixes made.
   28 s found which I want to ask Lou about before changing
   them. (Expect that list over the weekend, Lou :-)

> 1. During October there was extensive work on attributes and datatypes, 
> which was completed in time for a release of P5 (0.2.1) to take place on 
> the 21st.
> 
> 2. During November, the priority was to work on classes. A detailed 
> programme of work was agreed following the Council meeting in Oxford, 
> and is now complete. Full details of the changes made are available from 
> http://www.tei-c.org/Drafts/edw92.xml
> 
> 3. Some outstanding issues remain on the class front, in particular  
> there is still need for a  review of many chapters not discussed at the  
> Oxford meeting.  Enough work has been done, however, to proceed to the 
> revision of chapter ST, which is the next priority.
> 
> 4. In December, Matthew Driscoll visited Oxford, resulting in a number 
> of minor corrections to the MS chapter.
> 
> 5. A new "listPerson" element has been introduced to facilitate encoding 
> of "personographical" data: this was tested on some data supplied by 
> Matthew which now forms a new component of the test suite.
> 
> 6. New material for inclusion in chapters SA and NH has been received 
> but not yet reviewed by both editors.

Note
----
[1] http://sourceforge.net/tracker/index.php?func=detail&aid=1378784&group_id=106328&atid=644062

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Dec 16 02:35:44 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 16 Dec 2005 16:35:44 +0900
Subject: UPDATED: [tei-council] draft agenda for TEI council
	telecon2005-12-16 1200 UTC
In-Reply-To: 
	(Conal Tuohy's message of "Fri, 16 Dec 2005 14:35:10 +1300")
References: 
Message-ID: 

"Conal Tuohy"  writes:

>> Christian Wittern  writes:
>
>> 3) Proposal for new work items
>>  
>
> I have only one other item: more explicit identification of external
> vocabularies used in TEI taxonomies. 
>
> I would like to establish guidelines for explicitly linking to external
> vocabularies via URI, so that indexing and cataloguing software can more
> easily merge metadata from TEI documents in bulk, i.e. to promote
> commensurability of the indexes. At the moment the guidelines provide
> for an external vocabulary (a ) to be identified with a bibl,
> but I'd like us to endorse a way to include a URI as part of that
> identity, to facilitate merging. 

Fair enough. Looking at
http://www.tei-c.org.uk/P5/Guidelines/HD.html#HD55 I wonder if what we
need here is an endorsed way to provide a URL within  and
friends (do we have that?).  This looks like a pretty frequent
requirement in bibliographic citations to me.

Would that solve the problem at hand, Conal?

> In general (and this applies to the page-facsimile issue too), we are
> trying to make it easier for the National Library of NZ to adopt TEI as
> a general rule for text encoding. This is not yet a fait accompli. I
> think there's a risk that some half-baked (non-TEI) solution will catch
> on, especially (a cynic might say) given the involvement of Microsoft[2]
> (I know - I'm running a risk writing this using Microsoft Outlook!). 
>
That is certainly something I would like to see happen and we should
do what we can to facilitate it.

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 Dec 16 02:48:51 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 16 Dec 2005 16:48:51 +0900
Subject: [tei-council] encoding page scans
In-Reply-To: <43A1FCBB.60907@computing-services.oxford.ac.uk> (Lou Burnard's
	message of "Thu, 15 Dec 2005 23:31:07 +0000")
References: 
	<96f3df640512151438n226bde3btd50baad9f7d5513e@mail.gmail.com>
	<43A1FCBB.60907@computing-services.oxford.ac.uk>
Message-ID: 

Lou Burnard  writes:

>>  The main thing, to my
>> 
>>>mind, is that the guidelines should clearly document some standard
>>>practice that doesn't involve treating page scans as figures, or making
>>>custom extensions to the TEI schema.
>>>
>> yes, yes, yes

yes.  What we do need in the Guidelines is some recommendation on how
to do this.  It is a common requirement and it would be helpful if we
show people how to do it in a way that is likely to be similar to what
her neighbour is doing.  I think we might want to have one
quick-and-dirty way of doing this, which is I think what Conal is
asking for, which might be completely done within TEI.  Digital
Libraries and the like might want to adopt a more sophisticated
strategy, where METS gets into the game, which would also be helpful
if we document a recommended way.  I see a task force here as well.

> No no no! In P5 we have a generic  and a generic 
> element which could surely be used to mark the presence of a pagescan
> if you like. Whether you want to wrap them up in a (P5)   or
> in something else is a different question, of course. Also, at P5, you
> can't use the TEI without doing some kind of "custom extensions", so
> there's nothing to be afraid of there!

Yeah, quite right in the general case.  Nevertheless, we do want to
continue to give recommendations on best practice and the like.
Common requirements like this *should* be discussed in the Guidelines. 

>
>> 
>>   
>>     
>>       
>>         
>>       
>>       
>>         
>>       
>>     
>> FILEID links up to the file groups; COORDS records the coordinates
>> on
>> the image file; BEGIN records the xml:id of the line in the TEI file
>> (multiple lines would have both BEGIN and END).
>
> This seems to confuse two different things: the first  is
> pointing to an area, and second one to a sequence of lines, isn't
> it?

Right.  And the point is to say that these two components do
correspondend to each other.

> In P5, you can use a URI to point in either case, so the syntax is
> likely to be a lot less verbose tho not particularly more perspicuous.
>
> Then you could either use the corresp attribute to say that the two
> things correspond, or a standoff  to associate them.
>

I still think that for these cases there is no good reason to
re-invent METS.

>
> Another thing to throw into the pot: There are formats like DjaVu
> which embed in a single object a compressed page image and an XML
> transcript of it. Anyone got any views on how that affects these
> issues?
>

Now, here we do have a good case for a customization.  My djvu.odd would
just add some @coords to every  element, most likely.  But you
still need to have a place to put the image location.  I recently
briefly looked at Scansofts Omnipage, which produces (horrible,
horrible) XML which contains all this information, just crying for
being domesticated in TEI.

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 Dec 16 04:11:43 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 16 Dec 2005 09:11:43 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: <17314.22912.871433.552250@emt.wwp.brown.edu>
References: 
	<17314.22912.871433.552250@emt.wwp.brown.edu>
Message-ID: <43A284CF.10703@oucs.ox.ac.uk>

Syd Bauman wrote:

>Hmmm... perhaps. Remember that data.probability is a real number
>between 0 and 1 (inclusive). It is probably unreasonable to have a
>negative value for scale= of , but a value > 1 may make
>sense. In which case, the desired constraint is
>   xsd:double { minInclusive="0" }
>and no existing TEI datatype will do the job. We could
>a) decide negative values are OK (what do they mean?) and use
>   tei.numeric 
>b) use data.numeric, and live with the fact that the schema permits
>   negative values that make no sense (prose remarks and perhaps
>   Schematron rules would disallow negative values)
>c) use data.outputMeasurement
>d) create new TEI datatype
>e) use RelaxNG code directly, w/o a datatype
>  
>
I'd go straight to b) and live with the common sense approach.

>SR> Don't forget, by the way, that for some people  points
>SR> forward, for others it points back. If we all used , that
>SR> would need clearing up too.
>
>How much stronger than the current "By convention,  elements
>should appear at the start of the page to which they refer." do you
>think we should get?
>  
>
Stronger :-}

in what sense does a  "refer" to a page? its a page boundary,
by definition it occurs between two pages, favouring neither.

is there a page boundary at the start of every document?

perhaps I'm biased from a typesetting background, but I treat
 like a LaTeX \newpage, so it occurs at the point where
I expect a new page to start; and at the start of the document
I have implictly started a new page anyway.

sebastian

>
>  
>

From sebastian.rahtz at oucs.ox.ac.uk  Fri Dec 16 04:16:59 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 16 Dec 2005 09:16:59 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: 
References: 
Message-ID: <43A2860B.50002@oucs.ox.ac.uk>

I note that the W3C has a concept of non-normative "Note" documents,
which are not Recommendations, but sometimes have equivalent respect
and moral power. We don't have anything like that, and I think its a lack.
We have the Guidelines, in all their raging glory, and a set of
discussion documents which never leave /Drafts/ (how weird is that?), and
then we drift into things of educational status like the TEI Lite document.

These last few days, we've identified two clear areas where we feel
the TEI should take a lead, but we don't think that the message is
so definite that it should be in the Guidelines.

Am I going astray here? do others feel that in fact these
recommendations _should_ always be part of the Guidelines?

Sebastian

From Conal.Tuohy at vuw.ac.nz  Fri Dec 16 04:18:44 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Fri, 16 Dec 2005 22:18:44 +1300
Subject: UPDATED: [tei-council] draft agenda for TEI council
	telecon2005-12-16 1200 UTC
References: 

Message-ID: 

Conal:
> At the moment the guidelines provide
> for an external vocabulary (a ) to be identified with a bibl,
> but I'd like us to endorse a way to include a URI as part of that
> identity, to facilitate merging. 

Christian:
> Fair enough. Looking at
> http://www.tei-c.org.uk/P5/Guidelines/HD.html#HD55 I wonder if what we
> need here is an endorsed way to provide a URL within  and
> friends (do we have that?).  This looks like a pretty frequent
> requirement in bibliographic citations to me.
> 
> Would that solve the problem at hand, Conal?

Yes. Perhaps just adding ref to model.biblPart? 

Con

From Conal.Tuohy at vuw.ac.nz  Fri Dec 16 04:21:36 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Fri, 16 Dec 2005 22:21:36 +1300
Subject: [tei-council] encoding page scans
References: <17314.22912.871433.552250@emt.wwp.brown.edu>
	<43A284CF.10703@oucs.ox.ac.uk>
Message-ID: 

Sebastian Rahtz wrote:

> in what sense does a  "refer" to a page? its a page boundary,
> by definition it occurs between two pages, favouring neither.

That's true. Maybe the facsimiles should refer to the region between 2 page-breaks, then? Using an appropriate xpointer scheme, or perhaps with start and end attributes? 

Con

From sebastian.rahtz at oucs.ox.ac.uk  Fri Dec 16 04:29:39 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 16 Dec 2005 09:29:39 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: 
References: <17314.22912.871433.552250@emt.wwp.brown.edu>
	<43A284CF.10703@oucs.ox.ac.uk>

Message-ID: <43A28903.7000902@oucs.ox.ac.uk>

Conal Tuohy wrote:

>>in what sense does a  "refer" to a page? its a page boundary,
>>by definition it occurs between two pages, favouring neither.
>>    
>>
>
>That's true. Maybe the facsimiles should refer to the region between 2 page-breaks, then? Using an appropriate xpointer scheme, or perhaps with start and end attributes?
>  
>
that certainly would be less ambiguous. It would also allow for the 
situation
where the page facsimile was of a double page spread; I am sure none
of you do that, of course :-}

Sebastian

From lou.burnard at computing-services.oxford.ac.uk  Fri Dec 16 04:45:27 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 16 Dec 2005 09:45:27 +0000
Subject: UPDATED: [tei-council] draft agenda for TEI
	council	telecon2005-12-16 1200 UTC
In-Reply-To: 
References: 	

Message-ID: <43A28CB7.8020707@computing-services.oxford.ac.uk>

 (and ) are already available inside , inasmuch as 
 allows model.phrase

Conal Tuohy wrote:
> Conal:
> 
>>At the moment the guidelines provide
>>for an external vocabulary (a ) to be identified with a bibl,
>>but I'd like us to endorse a way to include a URI as part of that
>>identity, to facilitate merging. 
> 
> 
> Christian:
> 
>>Fair enough. Looking at
>>http://www.tei-c.org.uk/P5/Guidelines/HD.html#HD55 I wonder if what we
>>need here is an endorsed way to provide a URL within  and
>>friends (do we have that?).  This looks like a pretty frequent
>>requirement in bibliographic citations to me.
>>
>>Would that solve the problem at hand, Conal?
> 
> 
> Yes. Perhaps just adding ref to model.biblPart? 
> 
> Con
> _______________________________________________
> 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 Dec 16 04:39:27 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 16 Dec 2005 09:39:27 +0000
Subject: [tei-council] encoding page scans
In-Reply-To: 
References: 
Message-ID: <43A28B4F.1030301@oucs.ox.ac.uk>

Conal Tuohy wrote:

>I'm not sure that I expressed myself that clearly - I wondered just how
>far ODD's "filter" system could go in terms of mapping TEI instances to
>other schemas - is there anything it can't do, in principle? 
>  
>
the filtering I talked about in Sofia deals with one element
at a time. So if it was a matter of redoing a whole structure,
i'm wary

>The reason I wondered was that it seemed to me that a good general
>markup solution might be considerably more verbose than a light-weight
>variant 
>
In general, I dont think verbosity is a bad thing...

>If the standard page facsimile markup were to encode facsimile elements
>in the sourceDesc (with links pointing into the text), then an ODD
>customisation for a light-weight page-facsimile markup would define a
>sourceDesc whose content model EXCLUDED facsimile elements, but it could
>define a filter to generate those basic facsimile elements from
>//pb/@url, and the links from //pb/@xml:id
>
maybe. that would be pushing the ODD stuff into new territory;
you have to realize that the  mechanism is barely
explored, and there are few examples of its use.  I'd be delighted
to see experiments in this area!

Sebastian

From sebastian.rahtz at oucs.ox.ac.uk  Fri Dec 16 06:31:50 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 16 Dec 2005 11:31:50 +0000
Subject: [tei-council] fun for the conference call
Message-ID: <43A2A5A6.8060401@oucs.ox.ac.uk>

http://kitchen-cam.oucs.ox.ac.uk/ is showing my office, with James
and Lou expected to be sitting at the table for the conference call
in half an hour

--

-- 
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 Dec 16 07:15:01 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Fri, 16 Dec 2005 12:15:01 +0000
Subject: [tei-council] personography strawman proposal from LB, MJD, SR
Message-ID: <43A2AFC5.4080405@oucs.ox.ac.uk>

We suggest that a full-scale work group starting now from first
principles is not the best use of time or money.
A lot of work has already been done in this area, by a number of
different people, many of them using TEI with a few minor variations. It
seems then that what is needed would be more a clear statement of best
practice than  a  radically new set of TEI tags.

We propose work in 3 stages:

1. clearing up TEI P5 to add a few obviously missing elements (, 
)
and attributes  (generalising and simplifying ways of approximate dating 
for example),
and testing that P5 then covers a realistic quantity of existing person 
data.
Drafting a new section for P5  to describe this revised material (much
of it is already present in P5, but in the Corpus chapter).

2. investigating in a systematic way other existing schemata to see how 
they handle
person data and how their feature sets compare to those of what we have 
in P5.
This would aim to produce a kind of "cross-walk" of existing person data
schemata and some sample data sets.

3. organize a workgroup meeting to review the outputs from the first two
stages and  to develop the TEI recommendation.

Stage 1 has been largely completed already (it finished late last night;
P5 now adequately describes MJD's large set of person data, and my 
gravestone material).
For Stage 2, we suggest that part of the funds allocated to this area be 
used to fund
a student researcher in Copenhagen for  5 days work under the 
supervision of MJD.
For Stage 3, we propose that MJD be asked to convene a workgroup which 
will be funded to
meet once in the early spring, report to the Council in May, and 
conclude by the summer.

Work group objectives:
* review the TEI elements which are used to describe people, including
   where necessary those relating to place and date, and integrate them 
into a new module.

* review TEI customizations (eg Epidoc and the other classical 
archaeology work)
  which deal with people and work with their
  authors to incorporate any useful additions into the TEI core.

* investigate other encoding schemes which cover historical persons (eg 
HEML)
   and make recommendations on how the TEI scheme should relate to them.

-- 
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 mz34 at nyu.edu  Fri Dec 16 08:50:57 2005
From: mz34 at nyu.edu (Matthew Zimmerman)
Date: Fri, 16 Dec 2005 08:50:57 -0500
Subject: [tei-council] missed conference call
Message-ID: <8F8299E2-E1D7-4A2C-AF08-D95C03DC7226@nyu.edu>

A very auspicious start for me as TEI chair.

My lame explanation is I set the alarm for 5 A.M. so I could get to  
the office by 7 A.M. in case of a transit strike here, and apparently  
didn't turn the alarm on.

Hope my absence didn't hold up any work

MZ
_________________
Matthew Zimmerman
Faculty Technology Services, NYU
Tel: 212.998.3038
Fax: 212.995.4120

From lou.burnard at computing-services.oxford.ac.uk  Fri Dec 16 08:59:55 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 16 Dec 2005 13:59:55 +0000
Subject: [tei-council] missed conference call
In-Reply-To: <8F8299E2-E1D7-4A2C-AF08-D95C03DC7226@nyu.edu>
References: <8F8299E2-E1D7-4A2C-AF08-D95C03DC7226@nyu.edu>
Message-ID: <43A2C85B.5020208@oucs.ox.ac.uk>

Not only did we manage without you, but somehow we failed to allocate 
any work to you!

Matthew Zimmerman wrote:
> A very auspicious start for me as TEI chair.
> 
> My lame explanation is I set the alarm for 5 A.M. so I could get to  the 
> office by 7 A.M. in case of a transit strike here, and apparently  
> didn't turn the alarm on.
> 
> Hope my absence didn't hold up any work
> 
> MZ
> _________________
> Matthew Zimmerman
> Faculty Technology Services, NYU
> Tel: 212.998.3038
> Fax: 212.995.4120
> 
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 
> 

From mz34 at nyu.edu  Fri Dec 16 09:10:33 2005
From: mz34 at nyu.edu (Matthew Zimmerman)
Date: Fri, 16 Dec 2005 09:10:33 -0500
Subject: [tei-council] missed conference call
In-Reply-To: <43A2C85B.5020208@oucs.ox.ac.uk>
References: <8F8299E2-E1D7-4A2C-AF08-D95C03DC7226@nyu.edu>
	<43A2C85B.5020208@oucs.ox.ac.uk>
Message-ID: 

Now that isn't right!

On Dec 16, 2005, at 8:59 AM, Lou Burnard wrote:

> Not only did we manage without you, but somehow we failed to  
> allocate any work to you!
>
> Matthew Zimmerman wrote:
>> A very auspicious start for me as TEI chair.
>> My lame explanation is I set the alarm for 5 A.M. so I could get  
>> to  the office by 7 A.M. in case of a transit strike here, and  
>> apparently  didn't turn the alarm on.
>> Hope my absence didn't hold up any work
>> MZ
>> _________________
>> Matthew Zimmerman
>> Faculty Technology Services, NYU
>> Tel: 212.998.3038
>> Fax: 212.995.4120
>> _______________________________________________
>> 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

MZ
_________________
Matthew Zimmerman
Faculty Technology Services, NYU
Tel: 212.998.3038
Fax: 212.995.4120

From Conal.Tuohy at vuw.ac.nz  Fri Dec 16 09:28:53 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Sat, 17 Dec 2005 03:28:53 +1300
Subject: [tei-council] Facsimile work
Message-ID: 

I have created a page on the wiki with some notes about the Facsimile work item (I've categorised it as a SIG on the Wiki). http://www.tei-c.org/wiki/index.php/SIG:Facsimile

I think the next thing is to solicit examples of current practice, and for me and Dot to make a module that is functionally equivalent to her METS structure map.

From lou.burnard at computing-services.oxford.ac.uk  Fri Dec 16 13:01:06 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Fri, 16 Dec 2005 18:01:06 +0000
Subject: [tei-council] Notes from today
Message-ID: <43A300E2.6070607@oucs.ox.ac.uk>

Please check at http://www.tei-c.org/Council/tcm21.xml for any gross 
errors or misrepresentation

Lou

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Dec 16 16:23:33 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 17 Dec 2005 06:23:33 +0900
Subject: [tei-council] state of physical bibliography WG
Message-ID: 

Dear Council members,

As promised during yesterdays call, here is the message that came in
from Murray.

Julia, your message is timely. With the undergraduate term over, I am
about to e-mail the current members with a report on the progress of
my researches over the last few weeks and to suggest a plan of action.

For whatever reason, the current membership of the workgroup seems to
be such that forward progress in this workgroup will ultimately happen
because of the chair's own initiatives--some members even ignored my
request for information about their interest in continuing the work of
the group. I definitely will be recruiting further members, in part in
an attempt to change this climate; in particular, I am hoping to get
Elizabeth Solopova (who works with manuscript cataloguing at the
Bodleian) and Bettina Wagner (Bayerische Staatsbibliothek Muenchen,
description of incunabula) to join. Much of my own work over the fall
has been directed to assessing the feasability of the initial plans,
as the workgroup (i.e. principally you) clarified those to me during
the summer.

There are two main problems I see with those initial plans: a) an
encoding that can be induced (with no or little transformation) to
spit out in print a Bowers-like collation formula (a stated goal in
discussion in summer) may be incompatible with an encoding that allows
a full and explicit encoding of the physical facts of the printed book
(an implicit goal of all discussion so far), because Bowers depends on
various kinds of implicit  representation throughout (I will elaborate
on this  in discussion with the workgroup); and b) Bowers-like
collation formalae are not entirely compatible with the collation
symbolism commonly applied to medieval manuscripts and incunabulae
(primarily because Bowers depends on regular sequences of signings,
which are generally absent in MSS) and only partially compatible with
the collational formulae used outside of the English-speaking world.

Two alternatives are therefore presented: to consider that what we
want to encode is a Bowers (or other) formula, let the norms of the
particular sub-discipline or research culture govern its arrangement,
and throw up our hands about the direct physical description of the
document (in which case a simple  tag with allowance for the
kinds of typographical representations that people use is all that is
needed); or to decide that what we really want to do is encode the
physical structure of the book, manuscript, etc. (in which case an
encoding of a certain degree of generality (higher than Bowers
formulas) and explicitness (higher than Bowers formulas) is
required). I think the latter has more chance of being useful to more
people over a longer time and will be arguing for that route, and also
for the addition of members who can speak to usages outside of the
English-speaking of book describers who deal with letterpress books
after 1700.

That's where things stand right now, Christian.

Murray McGillivray

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  Sat Dec 17 18:47:17 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sun, 18 Dec 2005 08:47:17 +0900
Subject: [tei-council] Notes from today
In-Reply-To: <43A300E2.6070607@oucs.ox.ac.uk> (Lou Burnard's message of "Fri,
	16 Dec 2005 18:01:06 +0000")
References: <43A300E2.6070607@oucs.ox.ac.uk>
Message-ID: 

Lou Burnard  writes:

> Please check at http://www.tei-c.org/Council/tcm21.xml for any gross
> errors or misrepresentation
>
As always, thanks a lot for the quick and elegant handling of this.

It looks fine to me as it is.

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  Sun Dec 18 13:49:53 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou's Laptop)
Date: Sun, 18 Dec 2005 18:49:53 +0000
Subject: [tei-council] customization in P5
Message-ID: <43A5AF51.9070600@computing-services.oxford.ac.uk>

At present, there are two ways in which I can make a TEI schema.  I can 
either write an ODD and crunch it through the appropriate stylesheet, or 
I can hack together an invocation of the relevant modules using 
constructs specific to my chosen schema language (e.g. a DTD subset for 
DTD language or a RelaxNG schema with rferences to the right patterns) 
.  The constructs I use are quite different for different target 
languages, especially if I want to delete or emend elements or add new 
ones.  In P4, much of chapter ST is given over to explaining how  the 
customization mechanism is implemented in DTD world, but there is no 
discussion at all about how I might combine RelaxNG modules. And I don't 
have the faintest idea how I'd do it in W3C schema, before you ask.

 As I go about revising this chapter, I keep wondering whether or not 
any of this is still needed. If our recommendation is (as I think we 
agreed in Paris that it should be) to express each TEI customization 
declaratively as an ODD, why should we bother people with x.entities and 
things  like  ? If you run your ODD 
through the appropriate stylesheet, what you get out is a flat schema in 
the target language, not one that  invokes a set of modules at all. It 
uses lots of parameter entities, but they are not the ones defined in 
chapter ST.

Some time ago, the Meta group noted that if  we continued to  support 
modifiable DTD fragments, we would have to find some way of 
round-tripping between a TEI DTD modification subset and the 
corresponding ODD. This was not something we wanted to contemplate at 
the time, nor does it fill me with enthusiasm at the moment. Neither 
does the thought of maintaining  multiple ways of doing the same TEI 
customization independent of each other.

I don't have an answer to this and it raises difficult problems. If we 
say that the only means of TEI customization supported is via an ODD 
spec we need to put more thought into specifying exactly what an ODD 
conformant processor does. If we say that there are many means of 
customization, we need to explain all of them in quite some detail. Hmmm.

From sebastian.rahtz at oucs.ox.ac.uk  Sun Dec 18 14:30:20 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 18 Dec 2005 19:30:20 +0000
Subject: [tei-council] date, venue for next meeting
Message-ID: <43A5B8CC.5070600@oucs.ox.ac.uk>

for the sake of argument, can we look at the last week of May 2006 and
do comparative costings for Tokyo and Washington? How about if people
estimated travel costs for those two locations? I am happy to do 
correlate a
table if desired.

for example, for me Tokyo costs ?490 (more or less), and Washington 
about ?450.
But I refuse to fly to an airport named after Ronald Reagan :-}

I did this on the basis of May 20th-25th.

Oxford would cost me nothing, Paris about ?150

What are chances of cheapish hotels in Kyoto? or Washington?

On the whole, Paris likely to be cheapest :-}

-- 
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  Sun Dec 18 15:11:40 2005
From: Laurent.Romary at loria.fr (Laurent Romary)
Date: Sun, 18 Dec 2005 21:11:40 +0100
Subject: [tei-council] customization in P5
In-Reply-To: <43A5AF51.9070600@computing-services.oxford.ac.uk>
References: <43A5AF51.9070600@computing-services.oxford.ac.uk>
Message-ID: <0C1F90AB-A52F-480C-A0D2-EF09E17A3650@loria.fr>

As a matter of fact, a whole week of meetings, ending in a full  
afternoon of Roma/ODD tutorial in Nancy at the very time of our  
conference call put me in the best position just to forget it... I  
should send tankers of apologies to all of you, but Lou's message  
cheers me up a little bit since I can give you a kind of feedback  
from the mass. It appears that the principles of ODD, combined with  
the nice features of Roma do reach people's mind as we teach them. My  
audience was made of colleagues from Nancy who, for most of them, had  
experience of DTDs/Schemas and the like. They al appreciated the  
prospect of not having to fiddle with those things anymore and are  
very pleased with the idea of just having ODD as the sole  
custumization means for the TEI (or sole specification language for  
any kind of XML application, but this is rather out of topic).
So I would like to suggest that the council fully endorses the  
proposition of the Meta group that we highly recommend not to hack  
DTDs/Schemas for customize the TEI tagset, but ony use ODD specs. I  
then agree to put the issue of defining what an ODD conformant  
processor is on the agenda of my meeting with Lou next week.
Best wishes,
Laurent

PS: the DTD which is generated when deleting  a lot of elements from  
the 4 basic module (e.g. just to keep text/(front,body,back)/p) is  
not as robust as the corresponding RelaxNG schema). Incomplete  
stements are generated which prevent any further processing.

Le 18 d?c. 05 ? 19:49, Lou's Laptop a ?crit :

> At present, there are two ways in which I can make a TEI schema.  I  
> can either write an ODD and crunch it through the appropriate  
> stylesheet, or I can hack together an invocation of the relevant  
> modules using constructs specific to my chosen schema language  
> (e.g. a DTD subset for DTD language or a RelaxNG schema with  
> rferences to the right patterns) .  The constructs I use are quite  
> different for different target languages, especially if I want to  
> delete or emend elements or add new ones.  In P4, much of chapter  
> ST is given over to explaining how  the customization mechanism is  
> implemented in DTD world, but there is no discussion at all about  
> how I might combine RelaxNG modules. And I don't have the faintest  
> idea how I'd do it in W3C schema, before you ask.
>
> As I go about revising this chapter, I keep wondering whether or  
> not any of this is still needed. If our recommendation is (as I  
> think we agreed in Paris that it should be) to express each TEI  
> customization declaratively as an ODD, why should we bother people  
> with x.entities and things  like  "INCLUDE"> ? If you run your ODD through the appropriate  
> stylesheet, what you get out is a flat schema in the target  
> language, not one that  invokes a set of modules at all. It uses  
> lots of parameter entities, but they are not the ones defined in  
> chapter ST.
>
> Some time ago, the Meta group noted that if  we continued to   
> support modifiable DTD fragments, we would have to find some way of  
> round-tripping between a TEI DTD modification subset and the  
> corresponding ODD. This was not something we wanted to contemplate  
> at the time, nor does it fill me with enthusiasm at the moment.  
> Neither does the thought of maintaining  multiple ways of doing the  
> same TEI customization independent of each other.
>
> I don't have an answer to this and it raises difficult problems. If  
> we say that the only means of TEI customization supported is via an  
> ODD spec we need to put more thought into specifying exactly what  
> an ODD conformant processor does. If we say that there are many  
> means of customization, we need to explain all of them in quite  
> some detail. Hmmm.
>
>
>
>
> _______________________________________________
> 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  Sun Dec 18 16:29:48 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 18 Dec 2005 21:29:48 +0000
Subject: [tei-council] customization in P5
In-Reply-To: <0C1F90AB-A52F-480C-A0D2-EF09E17A3650@loria.fr>
References: <43A5AF51.9070600@computing-services.oxford.ac.uk>
	<0C1F90AB-A52F-480C-A0D2-EF09E17A3650@loria.fr>
Message-ID: <43A5D4CC.50200@oucs.ox.ac.uk>

> So I would like to suggest that the council fully endorses the  
> proposition of the Meta group that we highly recommend not to hack  
> DTDs/Schemas for customize the TEI tagset, but ony use ODD specs.

Just to be clear, this was the proposition of the whole council already, 
in Paris. I wrote a document which
outlined 3 ways of using the TEI, which I sent in from Timor, and the 
council firmly said "No", as I recall.
So I don't think we need formally discuss it more, it was already stated.

I think Lou should cut down chapter ST a lot,  and let it reference the 
customization chapter. That's
the one which needs bringing to the fore, and explaining how to use the 
TEI in anger (that's constructive
anger, not the sort I vented in the poor DHQ list, if any of you are on 
that).

>
> PS: the DTD which is generated when deleting  a lot of elements from  
> the 4 basic module (e.g. just to keep text/(front,body,back)/p) is  
> not as robust as the corresponding RelaxNG schema). Incomplete  
> stements are generated which prevent any further processing.

I am slightly surprised by that. Can you give me a sample ODD which 
generates Relax properly, but not DTD?
Such things need sorting out.

You may find the next release better, as a lot of the class changes 
affected this situation.

-- 
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 Dec 18 16:54:49 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 18 Dec 2005 16:54:49 -0500
Subject: [tei-council] customization in P5
In-Reply-To: <0C1F90AB-A52F-480C-A0D2-EF09E17A3650@loria.fr>
References: <43A5AF51.9070600@computing-services.oxford.ac.uk>
	<0C1F90AB-A52F-480C-A0D2-EF09E17A3650@loria.fr>
Message-ID: <17317.55977.731817.556417@emt.wwp.brown.edu>

I personally think that we should explicitly drop the idea of support
for customizations in DTD, W3C Schema, or any language other than ODD
and RelaxNG. Even the RelaxNG customizations should be downplayed as
something one does only when necessary, or for throw-away
one-time-use schemas. Moreover, my vague recollection from the
2005-04 meeting in Paris is that exactly this was decided there.
Various opinions were expressed as to whether customizations should
be permitted in RelaxNG (some against, many abstaining, and only 1 in
favor -- me), but nobody defended permitting customizations in DTD or
XSD. However, I can't find any reference to this in the minutes,
though. (Which would be my fault, I know.)-:

Thus I think the chapters on structure (ST) and customization (MD)
should barely mention DTDs nor W3C Schemas if at all. The chapter on
conformance (CF) should mention them only in as far as to point out
they are not the canonical expression of TEI constraints. (Of course,
neither is the RelaxNG, but it's at least a step closer.)

This would be a reversal of a decision Council made at the Oxford
meeting in 2003 (a decision I have to admit I supported at the time),
but I think it would be a really good idea to unchain TEI from DTDs
and XSDs as much as possible. It is not at all clear to me that the
effort and compromises needed to support even generating schemata in
DTDs and XSDs is worth it -- certainly the effort and compromises
needed to support customizations in those languages doesn't even come
close to being worth the benefit.

While I'm at it, there is another decision Council made at that
meeting which needs attention. We agreed then that the formal
definitions in the HTML version of P5 should be expressible in one 
or more of
   RelaxNG compact
   RelaxNG XML
   W3C Schema
   DTD
at user option. I think we should explicitly say that we will work on
releasing P5 with only RelaxNG compact declarations in the HTML
first, and then work on permitting expression of the latter 3 only if
there is some demand.

From sebastian.rahtz at oucs.ox.ac.uk  Sun Dec 18 17:31:39 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Sun, 18 Dec 2005 22:31:39 +0000
Subject: [tei-council] customization in P5
In-Reply-To: <17317.55977.731817.556417@emt.wwp.brown.edu>
References: <43A5AF51.9070600@computing-services.oxford.ac.uk>	<0C1F90AB-A52F-480C-A0D2-EF09E17A3650@loria.fr>
	<17317.55977.731817.556417@emt.wwp.brown.edu>
Message-ID: <43A5E34B.1020609@oucs.ox.ac.uk>

I don't agree with Syd's hard line; though I do find it sympathetic.

My reasons are simple:

 a) We have no mandate to undo the widely published and unchallenged
     declaration that we will support DTD and W3C Schema.
 b) As things stand, supporting DTD and W3C Schema is not an impossibly
     big burden (that's probably the most controversial part of this, of 
course;
     I know Syd would make interesting changes to content models if he 
could,
     but is prevented from doing so by DTD constraints)
 c) W3C Schema and DTD are, for good or bad, the constraints systems
     supported by a majority of tools. If we said we didn't care about them,
     we'd be isolating ourselves.
 d) If we dropped XSD and DTD, and gave ourselves the freedom to
     use Relax in an idiomatic way, we'd risk delaying P5 by another year.
     Is this the moment to throw things into flux again?

My feeling is that our direction is clear, to work on additional modules,
make increased use of the class system, write better tools, do I18N,
improve documentation etc. Rethinking decisions about constraint languages
is, to my mind, a low priority.

But I say again, my heart is with Syd on this; just not my head.....

Let me note that if we do only support ODD-generated schemas,
we have to drop the DTD and Relax NG parameterized schema fragments
entirely. We can't say "here they are, but you mustn't use them". It
plainly _is_ possible today to use P5 in the same way as we used to use
P4, with DTD subsets.

-- 
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 Dec 18 22:29:03 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sun, 18 Dec 2005 22:29:03 -0500
Subject: [tei-council] customization in P5
In-Reply-To: <43A5E34B.1020609@oucs.ox.ac.uk>
References: <43A5AF51.9070600@computing-services.oxford.ac.uk>
	<0C1F90AB-A52F-480C-A0D2-EF09E17A3650@loria.fr>
	<17317.55977.731817.556417@emt.wwp.brown.edu>
	<43A5E34B.1020609@oucs.ox.ac.uk>
Message-ID: <17318.10495.850620.656380@emt.wwp.brown.edu>

Sebastian, do you realize that we're talking about customization
here, not creation of schemas? Your arguments seem to be discussing
the latter, so I wanted to check that we are on the same page before
I responded at length. The question at hand is whether or not we
should support users writing customizations in:

* ODD	       (of course)
* RelaxNG      (I think so)
* DTD
* W3C Schema

Although your last paragraph does seem to be about customization, so
I'll address it now.

> Let me note that if we do only support ODD-generated schemas, we
> have to drop the DTD and Relax NG parameterized schema fragments
> entirely. We can't say "here they are, but you mustn't use them".

I'm not sure what you mean by the RelaxNG parameterized schema
fragments, but dropping the parameterization of the DTD fragments
would be a Good Thing. I think creating them has been a waste of your
valuable time, as will be maintaining them in the future.

> It plainly _is_ possible today to use P5 in the same way as we used
> to use P4, with DTD subsets.

Has anyone tested this? I will buy you a (cheap American) beer if it
does not turn out not to have problems, and there are not lots of
customizations that are trivial in ODD that are difficult in DTD.

From sebastian.rahtz at oucs.ox.ac.uk  Mon Dec 19 04:20:07 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Mon, 19 Dec 2005 09:20:07 +0000
Subject: [tei-council] customization in P5
In-Reply-To: <17318.10495.850620.656380@emt.wwp.brown.edu>
References: <43A5AF51.9070600@computing-services.oxford.ac.uk>	<0C1F90AB-A52F-480C-A0D2-EF09E17A3650@loria.fr>	<17317.55977.731817.556417@emt.wwp.brown.edu>	<43A5E34B.1020609@oucs.ox.ac.uk>
	<17318.10495.850620.656380@emt.wwp.brown.edu>
Message-ID: <43A67B47.5050304@oucs.ox.ac.uk>

Syd Bauman wrote:

>Sebastian, do you realize that we're talking about customization
>here, not creation of schemas?
>
I am not sure I get what the difference is? isnt
every real life schema a customization?

>I'm not sure what you mean by the RelaxNG parameterized schema
>fragments,
>
i mean what ends up in Schema/ when you do "make schemas".
you've probably never used them....

> but dropping the parameterization of the DTD fragments
>would be a Good Thing. I think creating them has been a waste of your
>valuable time, as will be maintaining them in the future.
>  
>
arguably. but the work is done now.

and another point - *we* may not want to generate DTDs
from ODD, but its one of the claims of the ODD system. The
folks in the W3C using it *definitely* want (parameterized) DTDs!

>>It plainly _is_ possible today to use P5 in the same way as we used
>>to use P4, with DTD subsets.
>>    
>>
>
>Has anyone tested this? I will buy you a (cheap American) beer if it
>does not turn out not to have problems, and there are not lots of
>customizations that are trivial in ODD that are difficult in DTD.
>  
>
I didn't make a claim  for the latter!  but look at most
of the .xml files in Test in SF; they refer to the DTDs with
a DOCTYPE, as in (eg)

]>

thats a customization, in my book. add in  if you 
want,
and it'll work.

sebastian

From wittern at kanji.zinbun.kyoto-u.ac.jp  Tue Dec 20 03:34:32 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Tue, 20 Dec 2005 17:34:32 +0900
Subject: [tei-council] date, venue for next meeting
In-Reply-To: <43A5B8CC.5070600@oucs.ox.ac.uk> (Sebastian Rahtz's message of
	"Sun, 18 Dec 2005 19:30:20 +0000")
References: <43A5B8CC.5070600@oucs.ox.ac.uk>
Message-ID: 

Sebastian Rahtz  writes:

> for the sake of argument, can we look at the last week of May 2006 and
> do comparative costings for Tokyo and Washington? How about if people
> estimated travel costs for those two locations? I am happy to do
> correlate a
> table if desired.
>
> for example, for me Tokyo costs ?490 (more or less), and Washington
> about ?450.

If we do the meeting in Kyoto, which I would recommend, you should
look for flights into Kansai (sometimes called Osaka) Airport (KIX).

I could go to Washington for about 800 Euro, to Paris or London for
about 750 Euro. Kyoto would cost me noting.  These fares are based on
the Feb. prices, since the search engine I used does not give prices
for May (and most Airlines have not published the discounted prices
for May yet anyway).

>
> Oxford would cost me nothing, Paris about ?150
>
> What are chances of cheapish hotels in Kyoto? or Washington?
>
> On the whole, Paris likely to be cheapest :-}

I just did a quick search here,

http://domestic.hotel.travel.yahoo.co.jp/bin/ajsearch?tuki=12&hi=20&haku=1&pnum=1&rnum=12&ken=26&larea=&marea=&os=1&pmin=&pmax=2&via=top&x=42&y=12

which revealed that there seem to be quite some options for "cheapish"
hotels in Kyoto -- in this case, less than 10000 Yen (about 70 Euro)
per night.  You might have to put up with staff that only barely
understands, much less speaks English though. 

I would like to add that the decision should not be solely on economic
grounds.  As I said during the call, I would try to organize some
workshop with the meeting, which will allow me to pay some travel out
of the pockets of a grant.  I just had a word with the powers to be
and the prospect for this seems to be quite good.  The catch with the
workshop is, that we will need to publish a report with the papers
presented, but again that should not be a problem I hope. 

All the best,

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  Tue Dec 20 04:17:41 2005
From: mjd at hum.ku.dk (M. J. Driscoll)
Date: Tue, 20 Dec 2005 10:17:41 +0100
Subject: [tei-council] date, venue for next meeting
In-Reply-To: 
References: <43A5B8CC.5070600@oucs.ox.ac.uk> (Sebastian Rahtz's message
	of	"Sun, 18 Dec 2005 19:30:20 +0000")
Message-ID: <43A7DA45.30256.3137F9@localhost>

A bit of checking on the internet suggests that it would be only slightly 
dearer for me to go to Kyoto (ca. 900 EUR) than to Washington (ca. 800 EUR).  
Paris or Oxford would only be about a quarter of that, probably even less the 
way things are going. On the other hand, I've been to Oxford, Paris and 
Washington, whereas I've never set foot in the land of the rising sun. Let's go 
for it.

Matthew

> Sebastian Rahtz  writes:
> 
> > for the sake of argument, can we look at the last week of May 2006 and
> > do comparative costings for Tokyo and Washington? How about if people
> > estimated travel costs for those two locations? I am happy to do
> > correlate a
> > table if desired.
> >
> > for example, for me Tokyo costs ??490 (more or less), and Washington
> > about ??450.
> 
> If we do the meeting in Kyoto, which I would recommend, you should
> look for flights into Kansai (sometimes called Osaka) Airport (KIX).
> 
> I could go to Washington for about 800 Euro, to Paris or London for
> about 750 Euro. Kyoto would cost me noting.  These fares are based on
> the Feb. prices, since the search engine I used does not give prices
> for May (and most Airlines have not published the discounted prices
> for May yet anyway).
> 
> >
> > Oxford would cost me nothing, Paris about ??150
> >
> > What are chances of cheapish hotels in Kyoto? or Washington?
> >
> > On the whole, Paris likely to be cheapest :-}
> 
> I just did a quick search here,
> 
> http://domestic.hotel.travel.yahoo.co.jp/bin/ajsearch?tuki=12&hi=20&haku=1&pnum=
> 1&rnum=12&ken=26&larea=&marea=&os=1&pmin=&pmax=2&via=top&x=42&y=12
> 
> which revealed that there seem to be quite some options for "cheapish"
> hotels in Kyoto -- in this case, less than 10000 Yen (about 70 Euro)
> per night.  You might have to put up with staff that only barely
> understands, much less speaks English though. 
> 
> I would like to add that the decision should not be solely on economic
> grounds.  As I said during the call, I would try to organize some
> workshop with the meeting, which will allow me to pay some travel out
> of the pockets of a grant.  I just had a word with the powers to be
> and the prospect for this seems to be quite good.  The catch with the
> workshop is, that we will need to publish a report with the papers
> presented, but again that should not be a problem I hope. 
> 
> 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

From sschreib at umd.edu  Tue Dec 20 08:08:37 2005
From: sschreib at umd.edu (Susan Schreibman)
Date: Tue, 20 Dec 2005 08:08:37 -0500
Subject: [tei-council] date, venue for next meeting
In-Reply-To: 
References: <43A5B8CC.5070600@oucs.ox.ac.uk>

Message-ID: <43A80255.3050902@umd.edu>

Hotels near the university of Maryland range from $150 for the nicest 
hotel on campus, to around $80.00, for a Best Western type hotel.

It would cost me:

$1250 to get to Tokyo
$800.00 to get to Paris
$700 to get to Oxford

one caveat with Maryland, is that we'd need to sort out transportation 
to dinner. I could rent a van from the campus pool, but it would not be 
large enough for everybody, so we might need to rent a car in addition 
unless somebody was driving in. That might cost an additional $300.00 
(based on a rental for four days)

Another option would be have Council members stay in a hotel in DC, and 
take the metro out to U of Maryland for the meeting (c 50 minutes). In 
that case, hotels would cost on average $170 a night, with minimal 
transport costs.

susan

susan

Christian Wittern wrote:

>Sebastian Rahtz  writes:
>
>  
>
>>for the sake of argument, can we look at the last week of May 2006 and
>>do comparative costings for Tokyo and Washington? How about if people
>>estimated travel costs for those two locations? I am happy to do
>>correlate a
>>table if desired.
>>
>>for example, for me Tokyo costs ?490 (more or less), and Washington
>>about ?450.
>>    
>>
>
>If we do the meeting in Kyoto, which I would recommend, you should
>look for flights into Kansai (sometimes called Osaka) Airport (KIX).
>
>I could go to Washington for about 800 Euro, to Paris or London for
>about 750 Euro. Kyoto would cost me noting.  These fares are based on
>the Feb. prices, since the search engine I used does not give prices
>for May (and most Airlines have not published the discounted prices
>for May yet anyway).
>
>  
>
>>Oxford would cost me nothing, Paris about ?150
>>
>>What are chances of cheapish hotels in Kyoto? or Washington?
>>
>>On the whole, Paris likely to be cheapest :-}
>>    
>>
>
>I just did a quick search here,
>
>http://domestic.hotel.travel.yahoo.co.jp/bin/ajsearch?tuki=12&hi=20&haku=1&pnum=1&rnum=12&ken=26&larea=&marea=&os=1&pmin=&pmax=2&via=top&x=42&y=12
>
>which revealed that there seem to be quite some options for "cheapish"
>hotels in Kyoto -- in this case, less than 10000 Yen (about 70 Euro)
>per night.  You might have to put up with staff that only barely
>understands, much less speaks English though. 
>
>I would like to add that the decision should not be solely on economic
>grounds.  As I said during the call, I would try to organize some
>workshop with the meeting, which will allow me to pay some travel out
>of the pockets of a grant.  I just had a word with the powers to be
>and the prospect for this seems to be quite good.  The catch with the
>workshop is, that we will need to publish a report with the papers
>presented, but again that should not be a problem I hope. 
>
>All the best,
>
>Christian
>
>
>  
>

-- 
Susan Schreibman, PhD
Assistant Dean
Head of Digital Collections and Research
McKeldin Library
University of Maryland 
College Park, MD 20742

Phone: 301 314 0358
Fax: 301 314 9408
Email; sschreib at umd.edu

From Syd_Bauman at Brown.edu  Tue Dec 20 10:05:19 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Dec 2005 10:05:19 -0500
Subject: [tei-council] date, venue for next meeting
In-Reply-To: 
References: <43A5B8CC.5070600@oucs.ox.ac.uk>

Message-ID: <17320.7599.127590.653431@emt.wwp.brown.edu>

Round-trip travel for me looks like it would be

  dest.          USD               EUR
  -----          ---               ---
* Kyoto:    1200 to 1500  ~=  1000 to 1300
* Paris:     800          ~=   700        
* Oxford:    600 to  700  ~=   500 to  600
* Maryland:   54 to  133  ~=    45 to  112

Reminder to US travelers: SWA flies to BWI, but does not show up on
travel search engines like travelocity, orbitz, or on travel agency
tools, you have to look at them separately
(http://www.southwest.com/). It's worth looking, they are often not
much more than half the price of the competition. But be warned --
their system can't handle flights in May yet, so I had to ask for
March :-)

From lou.burnard at computing-services.oxford.ac.uk  Tue Dec 20 10:36:17 2005
From: lou.burnard at computing-services.oxford.ac.uk (Lou Burnard)
Date: Tue, 20 Dec 2005 15:36:17 +0000
Subject: [tei-council] date, venue for next meeting
In-Reply-To: <17320.7599.127590.653431@emt.wwp.brown.edu>
References: <43A5B8CC.5070600@oucs.ox.ac.uk>	
	<17320.7599.127590.653431@emt.wwp.brown.edu>
Message-ID: <43A824F1.1080102@oucs.ox.ac.uk>

A rather cursory scan of lowest fares available on travelocity.com for 
the period May-Jun next year showed prices around $1000 for routes 
BWI-KIX and JFK-KIX. Also JFK-CDG at around $500. Both JFK-LHR and 
BOS-LHR are around $400

However, I think we agreed in thetelecon that our preference would be to 
go for Kyoto unles the costs turned out to be really silly. Which they 
don't seem to be so far.

Interestingly for Conall, I see that the best fare Auckland to 
Washington NZ air offers is just under 3000 NZD, while there is a direct 
flight to KIX for a paltry 2000 NZD. (But I don't know what the NZD is 
worth)

Syd Bauman wrote:
> Round-trip travel for me looks like it would be
> 
>   dest.          USD               EUR
>   -----          ---               ---
> * Kyoto:    1200 to 1500  ~=  1000 to 1300
> * Paris:     800          ~=   700        
> * Oxford:    600 to  700  ~=   500 to  600
> * Maryland:   54 to  133  ~=    45 to  112
> 
> Reminder to US travelers: SWA flies to BWI, but does not show up on
> travel search engines like travelocity, orbitz, or on travel agency
> tools, you have to look at them separately
> (http://www.southwest.com/). It's worth looking, they are often not
> much more than half the price of the competition. But be warned --
> their system can't handle flights in May yet, so I had to ask for
> March :-)
> 
> _______________________________________________
> 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 Dec 20 11:03:10 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Dec 2005 11:03:10 -0500
Subject: [tei-council] Facsimile work
In-Reply-To: 
References: 
Message-ID: <17320.11070.48915.632252@emt.wwp.brown.edu>

> I have created a page on the wiki with some notes about the
> Facsimile work item (I've categorised it as a SIG on the Wiki).
> http://www.tei-c.org/wiki/index.php/SIG:Facsimile

Wow, quick work Conal. Excellent. Page itself looks good, if
(understandably at this point) a bit sketchy. One question or perhaps
nit-pick. From the introduction:

   "... about markup of facsimile images with correspondence to parts
    of the text."

I had thought of the effort more as about how one encodes the
correspondence of encoded text with an image of its source, and
perhaps about how one encodes metadata about that image. But the
actual markup of facsimile images seems to me to mean something
somewhat different, and out of scope.

Did you actually want this to be a SIG, or just stuck it there for
lack of a better place on the wiki? If the latter, let's put our
heads together with James and find or create a better place.

If you really want this to be a SIG, there is a relatively
unobtrusive procedure to follow. I just realized that the procedure
for SIG creation is described in a document to which only the Board
of Directors has access. I'm not sure why that is, and will write to
the Board about it soon. In the meantime, here's a quick summary:

* Send mail to SIG coordinator (currently Susan S., I think)
  requesting SIG. Request should include
  - brief description of SIG mission (can be 1 sentence, basically
    exists to prove you know "TEI" does not stand for "Tax Executives
    Institute" (see http://www.tei-c.org/Publicity/not_the_tei.htm if
    you haven't already))
  - name & e-mail addr of contact person

* SIG coordinator presents SIG to Council, who vote approval or
  disapproval Council has never disapproved, and I doubt they ever
  will -- this step exists mostly to ensure
  a) Council is kept in the loop, and
  b) we don't have 2 SIGs doing same thing who don't know about each
     other

From James.Cummings at computing-services.oxford.ac.uk  Tue Dec 20 11:54:54 2005
From: James.Cummings at computing-services.oxford.ac.uk (James Cummings)
Date: Tue, 20 Dec 2005 16:54:54 +0000
Subject: [tei-council] Facsimile work
Message-ID: <43A8375E.8010500@computing-services.oxford.ac.uk>

Syd Bauman wrote:

>> Did you actually want this to be a SIG, or just stuck it there for
>> lack of a better place on the wiki? If the latter, let's put our
>> heads together with James and find or create a better place.

I think I suggested Conal stick it under the SIG area for now, just until it was
decided whether it should become one or not.  That allows an already understood
structure, and participation from outside the council.  If Conal wants to follow
this up to make it an actual SIG then great, but if not we can easily create
somewhere else on the wiki to put such things.

Suggestions appreciated,

-James

From Syd_Bauman at Brown.edu  Tue Dec 20 12:13:45 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Tue, 20 Dec 2005 12:13:45 -0500
Subject: [tei-council] customization in P5
In-Reply-To: <43A67B47.5050304@oucs.ox.ac.uk>
References: <43A5AF51.9070600@computing-services.oxford.ac.uk>
	<0C1F90AB-A52F-480C-A0D2-EF09E17A3650@loria.fr>
	<17317.55977.731817.556417@emt.wwp.brown.edu>
	<43A5E34B.1020609@oucs.ox.ac.uk>
	<17318.10495.850620.656380@emt.wwp.brown.edu>
	<43A67B47.5050304@oucs.ox.ac.uk>
Message-ID: <17320.15305.824106.237559@emt.wwp.brown.edu>

> I am not sure I get what the difference is? isnt every real life
> schema a customization?

No, every real life schema is the result of a customization. The
language the customization is made in and the language the schema is
expressed in can be different. E.g. In order to create a new content
model for  I could write

i.e., RelaxNG, in my ODD customization file, and generate from it
DTD, XSD, or RNG. Or I might write

     ( biblStruct+ )

i.e., DTD, in my ODD customization file (yes, I know ODD does not
currently support this), and generate from it DTD, XSD, or RNG.

Or I might generate a customization in ODD (probably via Roma web
interface, but that's unimportant) that just does module selection,
generate DTDs from that, and then do something like

etc. in my extension files.

I am arguing that it is not worth supporting the writing of
customizations in other languages -- customizations should be written
in RelaxNG, preferably inside your ODD. The argument "but I know the
DTD language, not RelaxNG" just doesn't hold water for me. If you
know DTD, learning enough RelaxNG to mimic what you can do with a
DTD takes less than an hour.

> >I'm not sure what you mean by the RelaxNG parameterized schema
> >fragments,
> i mean what ends up in Schema/ when you do "make schemas". you've
> probably never used them....

I think I had used them at one point long ago, but even if I did, I
never knew what they were called :-)

> >but dropping the parameterization of the DTD fragments would be a
> >Good Thing. I think creating them has been a waste of your
> >valuable time, as will be maintaining them in the future.
> arguably. but the work is done now.

But maintenance is still a potential time drain, and one that not
only produces no discernable benefit that I can ascertain, arguably
it in fact has some moral drawbacks. DTDs are simply not as
expressive as even ODD-limited RelaxNG, and really should be avoided.
By permitting this sort of shenanigans, we are both enabling people
to not take the short amount of time needed to learn RelaxNG, and,
perhaps worse, allowing for potentially very complex situations to
arise when someone makes a DTD that is a flattened file based on DTD
extension files that are to be used in conjunction with a
Roma-generated DTD that itself has customizations (other than simple
module selection).

> and another point - *we* may not want to generate DTDs from ODD,
> but its one of the claims of the ODD system.

This discussion isn't about generating DTDs from ODD. (Although you
are correct, I'm not all that psyched about that, either.) It's about
using DTD as a customization language.

> The folks in the W3C using it *definitely* want (parameterized)
> DTDs!

Why do they want the result DTDs parameterized? Is Felix actually
writing DTD extensions to P5 Roma-generated DTDs?

> ... but look at most of the .xml files in Test in SF; they refer to
> the DTDs with a DOCTYPE, as in (eg)
>        
>     
>     
>     ]>
>   
> thats a customization, in my book. add in  if
> you want, and it'll work.

Yes, quite right. But what if I want to add an updated version of the
WWP extensions, which have over 590 declarations? Has anyone tested
something of that scale? I haven't. And I'm not eager to. When the
WWP moves to P5 it is possible (although unlikely) that we will still
want to use DTDs for awhile longer. But I'll certainly write the
customization in RelaxNG in ODD, generating DTDs iff need be.

But of course, we're not really discussing the right question, here,
which isn't "should ODDs permit DTD and XSD customization", but
rather the question (IIRC) Lou initially raised, which was "should ST
discuss" these issues. In my current anti-DTD state of mind, I would
say no, even if it can be done, it should be explained in a separate
HOWTO, not in the Guidelines themselves. But that may be silly, and
bears some thought.

From sebastian.rahtz at oucs.ox.ac.uk  Tue Dec 20 15:50:37 2005
From: sebastian.rahtz at oucs.ox.ac.uk (Sebastian Rahtz)
Date: Tue, 20 Dec 2005 20:50:37 +0000
Subject: [tei-council] customization in P5
In-Reply-To: <17320.15305.824106.237559@emt.wwp.brown.edu>
References: <43A5AF51.9070600@computing-services.oxford.ac.uk>	<0C1F90AB-A52F-480C-A0D2-EF09E17A3650@loria.fr>	<17317.55977.731817.556417@emt.wwp.brown.edu>	<43A5E34B.1020609@oucs.ox.ac.uk>	<17318.10495.850620.656380@emt.wwp.brown.edu>	<43A67B47.5050304@oucs.ox.ac.uk>
	<17320.15305.824106.237559@emt.wwp.brown.edu>
Message-ID: <43A86E9D.9050104@oucs.ox.ac.uk>

Syd Bauman wrote:

>I am arguing that it is not worth supporting the writing of
>customizations in other languages -- customizations should be written
>in RelaxNG, preferably inside your ODD
>
It depends what you mean by "support".  Do you mean
that we should not make DTD fragments?

>. DTDs are simply not as
>expressive as even ODD-limited RelaxNG, and really should be avoided.
>  
>
they do have one advantage - you can do customization
at the instance level. you might well say that this is
pure evil anyway....

>>The folks in the W3C using it *definitely* want (parameterized)
>>DTDs!
>>    
>>
>
>Why do they want the result DTDs parameterized? Is Felix actually
>writing DTD extensions to P5 Roma-generated DTDs?
>  
>
no. but he may include the ITS DTD, generated from ODDs, inside
another DTD, where he may need the parameterization.

Felix isn't writing TEI at all, remember. He's defining his own language.

>
>Yes, quite right. But what if I want to add an updated version of the
>WWP extensions, which have over 590 declarations? Has anyone tested
>something of that scale?
>
I don't see why it wouldnt work. Why should it be different
than it was before? Mind you, converting that extension
file would be no joke at all!

>rather the question (IIRC) Lou initially raised, which was "should ST
>discuss" these issues. In my current anti-DTD state of mind, I would
>say no, even if it can be done, it should be explained in a separate
>HOWTO, not in the Guidelines themselves. 
>  
>
I don't feel that radical. But equally if the section doesn't
get written, I won't call it a showstopper.

-- 
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  Tue Dec 20 17:01:41 2005
From: Conal.Tuohy at vuw.ac.nz (Conal Tuohy)
Date: Wed, 21 Dec 2005 11:01:41 +1300
Subject: [tei-council] Facsimile work
Message-ID: 

> > I have created a page on the wiki with some notes about the
> > Facsimile work item (I've categorised it as a SIG on the Wiki).
> > http://www.tei-c.org/wiki/index.php/SIG:Facsimile

Syd:
> Wow, quick work Conal. Excellent. Page itself looks good, if
> (understandably at this point) a bit sketchy. 

I've had some correspondence with Dot and I expect to put up some more
stuff this week based on that, BTW. I'll post to the list when I have.
I'm off to the beach for my holidays on Monday, away from internet,
mobile phones - even electricity - so I want to get in on the wiki
before then, in case anyone is interested to see it over the next couple
of weeks :-)

> One question or perhaps
> nit-pick. From the introduction:
> 
>    "... about markup of facsimile images with correspondence to parts
>     of the text."
> 
> I had thought of the effort more as about how one encodes the
> correspondence of encoded text with an image of its source, and
> perhaps about how one encodes metadata about that image. But the
> actual markup of facsimile images seems to me to mean something
> somewhat different, and out of scope.

I had originally thought that too. Actually my own agenda is to provide
a simple markup, as well as a slightly more complex markup which would
have linked image files to text, but Dot's work convinced me otherwise.
I now think that TEI markup should allow the links between images and
text to be more granular in that a link might just point to a region
within the image. Probably just using inline SVG, though, so it
shouldn't make the TEI markup too image-flavoured, though I think it
will mean that the links should be "stand-off".

> Did you actually want this to be a SIG, or just stuck it there for
> lack of a better place on the wiki? If the latter, let's put our
> heads together with James and find or create a better place.

It's as James says; I just stuck it there (on his suggestion) because it
was SIG-ish, and I hadn't really considered setting one up formally. Now
that you mention it though, I think it is a good idea, since it's not
just me.

> If you really want this to be a SIG, there is a relatively
> unobtrusive procedure to follow. I just realized that the procedure
> for SIG creation is described in a document to which only the Board
> of Directors has access. I'm not sure why that is, and will write to
> the Board about it soon. In the meantime, here's a quick summary:
> 
> * Send mail to SIG coordinator (currently Susan S., I think)
>   requesting SIG. Request should include
>   - brief description of SIG mission (can be 1 sentence, basically
>     exists to prove you know "TEI" does not stand for "Tax Executives
>     Institute" (see http://www.tei-c.org/Publicity/not_the_tei.htm if
>     you haven't already))

LOL! 

>   - name & e-mail addr of contact person

OK. I have done this. Hope Susan is the right person! If not she will no
doubt let me know.

> * SIG coordinator presents SIG to Council, who vote approval or
>   disapproval Council has never disapproved, and I doubt they ever
>   will -- this step exists mostly to ensure
>   a) Council is kept in the loop, and
>   b) we don't have 2 SIGs doing same thing who don't know about each
>      other

I don't imagine this will be any more controversial than usual :-)

C

From Syd_Bauman at Brown.edu  Thu Dec 22 09:44:36 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 22 Dec 2005 09:44:36 -0500
Subject: [tei-council] date, venue for next meeting
In-Reply-To: <43A824F1.1080102@oucs.ox.ac.uk>
References: <43A5B8CC.5070600@oucs.ox.ac.uk>

	<17320.7599.127590.653431@emt.wwp.brown.edu>
	<43A824F1.1080102@oucs.ox.ac.uk>
Message-ID: <17322.48084.497106.253779@emt.wwp.brown.edu>

Not sure why Lou got so much better rates on travelocity.com than I
got on expedia.com. Nonetheless, one corection to my post:

> >                 USD               EUR
> > * Maryland:   54 to  133  ~=    45 to  112

Should have been 108 to  133  ~=    91 to  112

(The "54" is a one-way fare. :-)

From Syd_Bauman at Brown.edu  Thu Dec 22 09:55:53 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Thu, 22 Dec 2005 09:55:53 -0500
Subject: [tei-council] Facsimile work
In-Reply-To: 
References: 
Message-ID: <17322.48761.582737.925590@emt.wwp.brown.edu>

> I'm off to the beach for my holidays on Monday, ...

Oooohhh ...

> ... so I want to get in on the wiki before then, in case anyone is
> interested to see it over the next couple of weeks :-)

Good of you.

> I now think that TEI markup should allow the links between images
> and text to be more granular in that a link might just point to a
> region within the image. Probably just using inline SVG, though, so
> it shouldn't make the TEI markup too image-flavoured, though I
> think it will mean that the links should be "stand-off".

Whether such links are stand-off or in-line is an issue for
discussion, but the ability to point to a particular area of an image
is, IMHO, almost a requirement of TEI P5 markup. (After all, P4 could
do it, albeit only in a rudimentary manner:
http://www.tei-c.org/P4X/SA.html#SAXR1SP.)

The Stand-Off Markup, XLink and XPointer WG has a paper that, IIRC,
addresses this topic:
http://www.tei-c.org/Activities/SO/sow04.xml?style=printable.

From wittern at kanji.zinbun.kyoto-u.ac.jp  Thu Dec 29 21:35:44 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Fri, 30 Dec 2005 11:35:44 +0900
Subject: [tei-council] Thank you and good bye to outgoing Council members
Message-ID: 

Dear council members,

As the year approaches its end, all of Japan is busy cleaning shops
and poaches, washing cars and houses, wiping Buddhas and Bodhisattvas
and testing the temple gongs to make sure everything is ready for the
New Year.  Before I do the same to my office, and the network will go
down for maintenance as well, there are some last things that require
attention.

With the end of this year, the terms on the Council of Perry Willett
and Edward Vanhoutte will be fulfilled.  I would like to take this
opportunity to thank both of you for your time and devotion (even with
so many other committments requiring time and energy) to the TEI
Consortium, its members and the council.  I am sure we will be able
continue to count on your support and expertise as a member of the TEI
community.

I hope this message finds all of you in good spirits and I wish you
have a good beginning of the New Year 2006, whatever it might hold for
you and the TEI (some more releases of P5 for sure)

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 edward.vanhoutte at kantl.be  Fri Dec 30 04:01:33 2005
From: edward.vanhoutte at kantl.be (Edward Vanhoutte)
Date: Fri, 30 Dec 2005 10:01:33 +0100
Subject: [tei-council] Thank you and good bye to outgoing Council members
In-Reply-To: 
References: 
Message-ID: <43B4F76D.2090606@kantl.be>

Dear Christian and council members,

thank you very much for your kind wishes. It was a privilege to serve on 
the Council although I do realize my input has been rather minimal.
Keep up the good work and never forget the average moderate technical 
skills of much of the TEI community (hence the wide succes of TEILite). 
Since this has always been one of my main concerns, I'm happy to report 
that funding has been secured from King's College London, in 
collaboration with The Centre for Scholarly Editing and Document Studies 
(CTB) of the Royal Academy of Dutch Language and Literature (Belgium) 
and University College London for the construction of a suite of online 
tutorials called "TEI by Example".  These online tutorials would provide 
a useful teaching and learning aid to those embarking on a markup 
project in TEI and will of course address P5. Ron Van den Branden will 
be the executive project officer and the project will be managed by 
Melissa Terras and myself. Development of the tutorials will begin at 
the CTB in January 2006. We hope to announce a first release in Autumn 
2006.

Best wishes and so long,

Edward

Christian Wittern wrote:

>Dear council members,
>
>As the year approaches its end, all of Japan is busy cleaning shops
>and poaches, washing cars and houses, wiping Buddhas and Bodhisattvas
>and testing the temple gongs to make sure everything is ready for the
>New Year.  Before I do the same to my office, and the network will go
>down for maintenance as well, there are some last things that require
>attention.
>
>With the end of this year, the terms on the Council of Perry Willett
>and Edward Vanhoutte will be fulfilled.  I would like to take this
>opportunity to thank both of you for your time and devotion (even with
>so many other committments requiring time and energy) to the TEI
>Consortium, its members and the council.  I am sure we will be able
>continue to count on your support and expertise as a member of the TEI
>community.
>
>I hope this message finds all of you in good spirits and I wish you
>have a good beginning of the New Year 2006, whatever it might hold for
>you and the TEI (some more releases of P5 for sure)
>
>All the best,
>
>Christian Wittern
>
>
>
>
>  
>

-- 

================
Edward Vanhoutte
Researcher
University of Antwerp
Associate Editor, Literary and Linguistic Computing
University of Antwerp - CDE
Dept. of Literature
Universiteitsplein 1
b-2610 Wilrijk
Belgium

edward dot vanhoutte at kantl dot be
http://www.kantl.be/ctb/
http://www.kantl.be/ctb/vanhoutte/
http://www.kantl.be/ctb/staff/edward.htm

From wittern at kanji.zinbun.kyoto-u.ac.jp  Fri Dec 30 18:54:24 2005
From: wittern at kanji.zinbun.kyoto-u.ac.jp (Christian Wittern)
Date: Sat, 31 Dec 2005 08:54:24 +0900
Subject: [tei-council] Thank you and good bye to outgoing Council members
In-Reply-To:  (Christian Wittern's
	message of "Fri, 30 Dec 2005 11:35:44 +0900")
References: 
Message-ID: 

Council members,

As Susan reminded me (thanks!!), Natasha Smith is also leaving the
Council -- I must have forgotten this in the hope that she would be
continuing, sorry for that.  It goes without saying, that my thanks
and best wishes extend to Natasha as well.  Thank you for your time
and effort and please continue to support the TEI!

All the best,

Christian

Christian Wittern  writes:

> Dear council members,
>
> As the year approaches its end, all of Japan is busy cleaning shops
> and poaches, washing cars and houses, wiping Buddhas and Bodhisattvas
> and testing the temple gongs to make sure everything is ready for the
> New Year.  Before I do the same to my office, and the network will go
> down for maintenance as well, there are some last things that require
> attention.
>
> With the end of this year, the terms on the Council of Perry Willett
> and Edward Vanhoutte will be fulfilled.  I would like to take this
> opportunity to thank both of you for your time and devotion (even with
> so many other committments requiring time and energy) to the TEI
> Consortium, its members and the council.  I am sure we will be able
> continue to count on your support and expertise as a member of the TEI
> community.
>
> I hope this message finds all of you in good spirits and I wish you
> have a good beginning of the New Year 2006, whatever it might hold for
> you and the TEI (some more releases of P5 for sure)
>
> 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

-- 

 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 Dec 30 23:05:05 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Fri, 30 Dec 2005 23:05:05 -0500
Subject: [tei-council] summary of SO WG outputs
Message-ID: <17334.881.28807.793922@emt.wwp.brown.edu>

Action SB by 2005-12-31: Circulate summary report on SO workgroup
			 outputs to date
---------
The TEI Work-group on Stand-Off Markup, XLink and XPointer ("SO") was
conceived and authorized by Council at its January 2002 meeting in
London, and actually formed and charged the following summer. The
group, chaired by David Durand, has never had a face-to-face meeting,
met by conference call an average of ~ twice per month during its
first 1.5 years of existence, but has not met since then. The group
has produced several papers, some of which supersede others. Those
that have been superseded are listed last.

* SO W 02 "summary of technical rationale for decisions on XPointer
  and stand off markup"
  http://www.tei-c.org/Activities/SO/sow02.xml?style=printable
  Last updated 19 Nov 03. 
  White paper on issues, particularly ID v. XPointer.

* SO W 04 "Notes on Media formats and XPointer"
  http://www.tei-c.org/Activities/SO/sow04.xml?style=printable
  Last updated Fri, 17 Oct 03.
  A useful paper by Chris Caton that basically recommends the use of
  SVG and SMIL in TEI documents. I am sorry to report that this paper
  has been almost completely ignored by Council, as I think the
  approaches it recommends should at least be seriously considered and
  debated.
  Note: when Chris says that entities are depreciated, he means
  attributes of type ENTITY, not entity references.

* SO W 05 "Corpus Applications"
  http://www.tei-c.org/Activities/SO/sow05.xml?style=printable
  Last updated Thu, 06 Nov 03.
  A somewhat incomplete paper that requires technical updating to
  match current recommendations, that nonetheless deserves attention
  as it offers advice on markup up various linguistic properties of
  texts, particularly in the context of large corpora. The original
  propose of this paper was to demonstrate the use of various
  techniques described in the chapter on linking, segmentation, and
  alignment, but I suspect a lot of the advice it gives should be in
  the chapter on Language Corpora.

* SO W 06 "Stand-off Markup"
  http://www.tei-c.org/Activities/SO/sow06.xml?style=printable
  Last updated Tue, 06 May 03.
  This is Fabio's paper on XInclude, which DD and I are currently in
  the process of re-working and inserting into the chapter on linking,
  segmentation, and alignment. (I *think* this is probably the paper
  Lou was referring to on the conference call, and I was just confused
  that he was referring to something newer -- Lou, if Fabio has done
  something since that I'm unaware of, please let me know.)

* SO W 07 "Graphs"
  http://www.tei-c.org/Activities/SO/sow07.xml?style=printable
  Last updated Fri, 02 May 03.
  Also by Chris Caton, this paper analyzes how RDF might be used to
  encode graphs (and therefore trees) instead of TEI-specific markup.
  He basically encodes the example in P4 using mostly RDF. I just
  noticed, however, that the colors in the examples are no longer
  coming through.

* SO W 09 "Basic working decisions on pointing and linking"
  http://www.tei-c.org/Activities/SO/sow09.xml?style=printable
  Last updated Sat, 02 Oct 04
  On or about its conference call of 2004-03-29, Council requested
  that the WG (i.e., DD) produce a summary document of its decisions
  and recommendations so far, particularly in the area of XML's
  ID/IDREF mechanism and W3C's XPointer Framework. This is that
  summary document.

* SO W 01 "Differences Between XPointer and the TEI Extended Pointer
           Mechanism"
  This document has been superseded by SO W 02

* SO W 03 "Linking, Segmentation, and Alignment"
  This document has been incorporated into P5.

* SO W 08 "Canonical References"
  This document has been incorporated into P5.

In addition to the above papers, the WG has produced a proof-of-
concept Perl program that converts TEI P4 extended pointer syntax to
XPaths. I have not been able to run it for awhile, though, as the
underlying library it depends on for parsing has changed. It is at
http://www.tei-c.org/Activities/SO/exp-conv.tgz.

From Syd_Bauman at Brown.edu  Sat Dec 31 13:03:53 2005
From: Syd_Bauman at Brown.edu (Syd Bauman)
Date: Sat, 31 Dec 2005 13:03:53 -0500
Subject: [tei-council] class struggle procedure suggestion
Message-ID: <17334.51209.622738.261571@emt.wwp.brown.edu>

Action SB by 2005-12-31: organize a proposal on how best to prosecute
                         the class struggle

Personally, I like the idea of working on this via conference call
with each participant looking at the same information on his or her
screen. However, the various technical solutions for that (VNC,
Marratech) seem at first glance like significant overkill.

Thus, I'm going to suggest we try conference calls with a deliberate
plan to try to stay on the same page.

1. ED W 84 needs to be updated to reflect the current P5 

2. ED W 84 needs to be updated so that each record is easily uniquely
   identified [1]

3. For each set of modules listed below, the Class Crew holds a
   conference call going through the module as we did for header,
   core, etc. in Oxford. We should set aside 2 hrs for each call,
   hoping to be done in half that.

4. Notes from conference call should be posted very rapidly, ideally
   less than 24 hrs later.

5. Brief discussion period among Class Crew to affirm notes and hammer
   out any details (by default 1 week)

6. Editors implement agreed changes, post about any problems
   encountered (approximately 1 week)

7. ED W 84 is updated to reflect this set of changes

I don't see any reason not to start before the next Council call.
(Have we decided on the date for that call? Fri 24 Feb was
suggested.) I am going to suggest Thu 26 Jan at 14:00Z for the first
Class Crew conference call (C4 for short, although we hope not to be
as explosive :-).

Module Sets
------ ----
* gaiji, nets, figures
* transcr, textcrit, namesdates
* analysis, corpus, spoken (and personography, if it exists by then)
* iso-fs, declarefs
* drama, tagdocs, linking
* msdescription (perhaps MD & DB should be included in con call)
* dictionaries

There is almost nothing to be done for the following modules, so they
have not been included in the above sets:
* verse (only element empty)
* certainty (all elements empty, already a member of a model class)
* concurrent-decl (scheduled for execution by firing squad)

Notes
-----
[1] My personal suggestion would be to add an incrementing record
    number to each cell in the "module" column, but the details don't
    really matter. The point is to make it so that in a web browser,
    which typically has very limited searching capabilities, every
    participant can find the record in question ASAP -- if someone
    says "look at person", the others need to search through at least
    every occurrence of "person" in content models, etc., if not every
    occurrence of "personPart", "personGrp", etc.; if someone says
    "look at record 0283", everyone else can be on the same record v.
    fast.