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 ho