In fact they are. This seems to be a Stylesheets thing. The PDF version prints the namespace nodes, but the web version elides them. I'm pretty sure I could print them properly, but I'd rather not be mucking around right before a release in case there are unexpected side effects. On Thu, Oct 8, 2015 at 8:53 AM, James Cummings wrote:

Maybe I'm missing earlier discussion but with the examples on the ref page why not declare the namespace prefixes on xenodata? (Yes, in reality you'd do it on root TEI.)

James

-- Dr James Cummings, Academic IT, University of Oxford

-----Original Message----- From: Hugh Cayless [philomousos@gmail.com] Received: Thursday, 08 Oct 2015, 8:08 To: TEI Council [tei-council@lists.tei-c.org] Subject: [tei-council] Release?

The modified xenoData sections are viewable at

http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/rel... and

http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/rel...

Can at least some of you look them over and either approve or suggest/make corrections?

Once that's done, we need to decide whether we're proceeding with the release today. tomorrow, or at some later date. I don't have an opinion yet in the absence of feedback on the latest changes, except to say that I'd like to get this over with. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

The surrounding prose comments on them because they won't print in the web Guidelines though :-). I might actually put my namespace declarations on or inside <xenoData> if they applied nowhere else... On Thu, Oct 8, 2015 at 10:22 AM, Lou Burnard wrote:

Yes. Personally I think it's a good idea to suppress them in this case, since the surrounding prose already comments on what the namespace prefixes mean, and (as you rightly say) in the real world you wouldn't declare them at this level anyway.

On 08/10/15 14:05, Hugh Cayless wrote:

...

In fact they are. This seems to be a Stylesheets thing. The PDF version prints the namespace nodes, but the web version elides them. I'm pretty sure I could print them properly, but I'd rather not be mucking around right before a release in case there are unexpected side effects.

On Thu, Oct 8, 2015 at 8:53 AM, James Cummings < james.cummings@it.ox.ac.uk> wrote:

Maybe I'm missing earlier discussion but with the examples on the ref page

...

why not declare the namespace prefixes on xenodata? (Yes, in reality you'd do it on root TEI.)

James

-- Dr James Cummings, Academic IT, University of Oxford

-----Original Message----- From: Hugh Cayless [philomousos@gmail.com] Received: Thursday, 08 Oct 2015, 8:08 To: TEI Council [tei-council@lists.tei-c.org] Subject: [tei-council] Release?

The modified xenoData sections are viewable at

http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/rel... and

http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/rel...

Can at least some of you look them over and either approve or suggest/make corrections?

Once that's done, we need to decide whether we're proceeding with the release today. tomorrow, or at some later date. I don't have an opinion yet in the absence of feedback on the latest changes, except to say that I'd like to get this over with. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

Syd put them in the examples on the spec page—I assume because the namespaces don't show up. I copied the info over to the GLs example when I realized the xmlns:dc wasn't printing. On Thu, Oct 8, 2015 at 10:52 AM, Lou Burnard wrote:

On 08/10/15 15:27, Hugh Cayless wrote:

...

The surrounding prose comments on them because they won't print in the web Guidelines though :-).

Oh, did you put them in? I thought they were there originally.

I might actually put my namespace declarations on or

...

inside <xenoData> if they applied nowhere else...

On Thu, Oct 8, 2015 at 10:22 AM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:

Yes. Personally I think it's a good idea to suppress them in this case,

...

since the surrounding prose already comments on what the namespace prefixes mean, and (as you rightly say) in the real world you wouldn't declare them at this level anyway.

On 08/10/15 14:05, Hugh Cayless wrote:

In fact they are. This seems to be a Stylesheets thing. The PDF version

...

prints the namespace nodes, but the web version elides them. I'm pretty sure I could print them properly, but I'd rather not be mucking around right before a release in case there are unexpected side effects.

On Thu, Oct 8, 2015 at 8:53 AM, James Cummings < james.cummings@it.ox.ac.uk> wrote:

Maybe I'm missing earlier discussion but with the examples on the ref page

...

why not declare the namespace prefixes on xenodata? (Yes, in reality you'd do it on root TEI.)

James

-- Dr James Cummings, Academic IT, University of Oxford

-----Original Message----- From: Hugh Cayless [philomousos@gmail.com] Received: Thursday, 08 Oct 2015, 8:08 To: TEI Council [tei-council@lists.tei-c.org] Subject: [tei-council] Release?

The modified xenoData sections are viewable at

http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/rel... and

http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/rel...

Can at least some of you look them over and either approve or suggest/make corrections?

Once that's done, we need to decide whether we're proceeding with the release today. tomorrow, or at some later date. I don't have an opinion yet in the absence of feedback on the latest changes, except to say that I'd like to get this over with. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

I do not know if my comments are welcome on this matter any more, since I am being completely over-ruled on this. So feel free to continue to ignore me. But that said, could we at least make the datatype of @scope data.enumerated, not data.word? I'll argue why if needed, but I'm hoping this is self-evident. (Of course, I think the whole idea of having such an attribute *without* a suggested values list is self-evidently stupid, so apparently my barometer on self-evidentness is mis-calibrated.)

The datatype "data.word" has changed meaning over the years, even though the syntax has remained constant. Currently it means something akin to "a single magic token that can be anything and means whatever you want it to mean".[1] The meaning of "data.enumerated" has remained steadfast, even though we have at least debated about, if not changed, the syntax. It means something akin to "the value herein should be chosen from a list of *documented* possibilities; said list may be open or closed, and if not supplied by the TEI, should be supplied by the customizer". Notes ----- [1] Originally data.word was only about syntax -- it was just a way to give us a mechanism for disallowing certain crazy Unicode characters in attribute values. Thus it excludes control characters, combining characters, etc., but allows punctuation marks and currency symbols and the like. It did not permit whitespace with the expectation that it would be used in a RELAX NG list, thus allowing for whitespace normalization before comparison. But it has grown to mean more, for better or for worse.

Syd, your input is *always* welcome, and it is possible that we're all wrong and you're right. If so, you get to sing "Nyaa, nyaa, told you so!" at us.

It's not self-evident to me. I'm always learning new stuff about TEI. What's the advantage of data.enumerated in the absence of a valList?

All but one of the original voters went for 2 or 3 below, with 3 or 2 as their second favorite, so I'd say we do have consensus for releasing xenoData. We seem now to be split on whether or not to release it with @scope minus any recommended values. My view remains that @scope is not something I would probably ever use, but I could be convinced that other people might if it had a better set of values. I'd find an attribute that told me what the format of the data inside <xenoData> was much more useful. But we can proceed incrementally, and that's fine. Anybody want to change their minds between #2 and #3? 2) release xenodata with @scope, but without a list of recommended values

3) release xenodata without @scope

On Thu, Oct 8, 2015 at 12:05 PM, Lou Burnard wrote:

As we seem to be some way from a consensus on the right way forward, may I propose a further vote?

Option 1. Remove the attribute @scope for now.

Option 2. Remove the xenoData element for now.

We can then thrash out what is clearly a somewhat divisive issue at the ftf, targetting the next release for its resolution.

My vote is (now) for option 1, but I can live with option 2.

On 08/10/15 16:14, Hugh Cayless wrote:

...

Syd, your input is *always* welcome, and it is possible that we're all wrong and you're right. If so, you get to sing "Nyaa, nyaa, told you so!" at us.

It's not self-evident to me. I'm always learning new stuff about TEI. What's the advantage of data.enumerated in the absence of a valList?

On Thu, Oct 8, 2015 at 11:08 AM, Syd Bauman wrote:

I do not know if my comments are welcome on this matter any more,

...

since I am being completely over-ruled on this. So feel free to continue to ignore me. But that said, could we at least make the datatype of @scope data.enumerated, not data.word? I'll argue why if needed, but I'm hoping this is self-evident. (Of course, I think the whole idea of having such an attribute *without* a suggested values list is self-evidently stupid, so apparently my barometer on self-evidentness is mis-calibrated.)

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

In what way are you "screwed"? If it's JSON, I'd like to be told that, so I can extract it and feed it into a JSON parser, if it's Turtle, likewise. If you're saying you can't process it with XSLT, that's possibly true, but so what? On Thu, Oct 8, 2015 at 12:29 PM, Lou Burnard wrote:

My vote remains for 3 over 2. There is clearly disagreement about how precisely we want to recommend the scope of a chunk of xenodata should be expressed, if at all; whether a new attribute is needed; whether we can use or modify existing mechanisms etc.

Specifying the format of the content of the xenodata is something (I thought) we'd already explicitly ruled out in earlier discussion -- either it uses some predefined XML namespace or it doesn't. In the latter case you're screwed anyway.

On 08/10/15 17:23, Hugh Cayless wrote:

...

All but one of the original voters went for 2 or 3 below, with 3 or 2 as their second favorite, so I'd say we do have consensus for releasing xenoData. We seem now to be split on whether or not to release it with @scope minus any recommended values. My view remains that @scope is not something I would probably ever use, but I could be convinced that other people might if it had a better set of values. I'd find an attribute that told me what the format of the data inside <xenoData> was much more useful. But we can proceed incrementally, and that's fine. Anybody want to change their minds between #2 and #3?

2) release xenodata with @scope, but without a list of recommended values

...

3) release xenodata without @scope

On Thu, Oct 8, 2015 at 12:05 PM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:

As we seem to be some way from a consensus on the right way forward, may I

...

propose a further vote?

Option 1. Remove the attribute @scope for now.

Option 2. Remove the xenoData element for now.

We can then thrash out what is clearly a somewhat divisive issue at the ftf, targetting the next release for its resolution.

My vote is (now) for option 1, but I can live with option 2.

On 08/10/15 16:14, Hugh Cayless wrote:

Syd, your input is *always* welcome, and it is possible that we're all

...

wrong and you're right. If so, you get to sing "Nyaa, nyaa, told you so!" at us.

It's not self-evident to me. I'm always learning new stuff about TEI. What's the advantage of data.enumerated in the absence of a valList?

On Thu, Oct 8, 2015 at 11:08 AM, Syd Bauman wrote:

I do not know if my comments are welcome on this matter any more,

...

since I am being completely over-ruled on this. So feel free to continue to ignore me. But that said, could we at least make the datatype of @scope data.enumerated, not data.word? I'll argue why if needed, but I'm hoping this is self-evident. (Of course, I think the whole idea of having such an attribute *without* a suggested values list is self-evidently stupid, so apparently my barometer on self-evidentness is mis-calibrated.)

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

There are MIME types, for example. I don't see why we couldn't recommend using those. Granted, they wouldn't be 100% true, because your content might not be quite that format until it had been run through an XML processor, but it *is* embedded in an XML document, so I don't think that's unreasonable. On Thu, Oct 8, 2015 at 12:52 PM, Lou Burnard wrote:

Sorry, my brain is so clearly addled by years of XML that the thought of having to deal with something I can't process with XSLT just makes me feel all wobbly.

I think we did agree that you can put non-XML data into xenodata, but it's a long step from that to being able to do much more than say "it's in Wibble. Get your wibble processor on the job."

So, yes, I can see the case for an attribute @format with closed valuelist of "XML", "Other" ... but beyond that I think we're straying too far out of our zone of expertise. How do I know whether "wibble" means "Wibble 1.0" or "Wibble with the doohickey extensions?"

On 08/10/15 17:33, Hugh Cayless wrote:

...

In what way are you "screwed"? If it's JSON, I'd like to be told that, so I can extract it and feed it into a JSON parser, if it's Turtle, likewise. If you're saying you can't process it with XSLT, that's possibly true, but so what?

On Thu, Oct 8, 2015 at 12:29 PM, Lou Burnard < lou.burnard@retired.ox.ac.uk> wrote:

My vote remains for 3 over 2. There is clearly disagreement about how

...

precisely we want to recommend the scope of a chunk of xenodata should be expressed, if at all; whether a new attribute is needed; whether we can use or modify existing mechanisms etc.

Specifying the format of the content of the xenodata is something (I thought) we'd already explicitly ruled out in earlier discussion -- either it uses some predefined XML namespace or it doesn't. In the latter case you're screwed anyway.

On 08/10/15 17:23, Hugh Cayless wrote:

All but one of the original voters went for 2 or 3 below, with 3 or 2 as

...

their second favorite, so I'd say we do have consensus for releasing xenoData. We seem now to be split on whether or not to release it with @scope minus any recommended values. My view remains that @scope is not something I would probably ever use, but I could be convinced that other people might if it had a better set of values. I'd find an attribute that told me what the format of the data inside <xenoData> was much more useful. But we can proceed incrementally, and that's fine. Anybody want to change their minds between #2 and #3?

2) release xenodata with @scope, but without a list of recommended values

3) release xenodata without @scope

...

On Thu, Oct 8, 2015 at 12:05 PM, Lou Burnard <

lou.burnard@retired.ox.ac.uk> wrote:

As we seem to be some way from a consensus on the right way forward, may I

...

propose a further vote?

Option 1. Remove the attribute @scope for now.

Option 2. Remove the xenoData element for now.

We can then thrash out what is clearly a somewhat divisive issue at the ftf, targetting the next release for its resolution.

My vote is (now) for option 1, but I can live with option 2.

On 08/10/15 16:14, Hugh Cayless wrote:

Syd, your input is *always* welcome, and it is possible that we're all

...

wrong and you're right. If so, you get to sing "Nyaa, nyaa, told you so!" at us.

It's not self-evident to me. I'm always learning new stuff about TEI. What's the advantage of data.enumerated in the absence of a valList?

On Thu, Oct 8, 2015 at 11:08 AM, Syd Bauman < syd@paramedic.wwp.neu.edu> wrote:

I do not know if my comments are welcome on this matter any more,

since I am being completely over-ruled on this. So feel free to > continue to ignore me. But that said, could we at least make the > datatype of @scope data.enumerated, not data.word? I'll argue why if > needed, but I'm hoping this is self-evident. (Of course, I think the > whole idea of having such an attribute *without* a suggested values > list is self-evidently stupid, so apparently my barometer on > self-evidentness is mis-calibrated.) > > -- > tei-council mailing list > tei-council@lists.tei-c.org > http://lists.lists.tei-c.org/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived > > > -- > tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

I will go with option 1, as long as we follow it up with a consultation with the community to get a sense of the range of uses they would put it to. Cheres, Martin On 15-10-08 09:05 AM, Lou Burnard wrote:

As we seem to be some way from a consensus on the right way forward, may I propose a further vote?

Option 1. Remove the attribute @scope for now.

Option 2. Remove the xenoData element for now.

We can then thrash out what is clearly a somewhat divisive issue at the ftf, targetting the next release for its resolution.

My vote is (now) for option 1, but I can live with option 2.

On 08/10/15 16:14, Hugh Cayless wrote:

...

Syd, your input is *always* welcome, and it is possible that we're all wrong and you're right. If so, you get to sing "Nyaa, nyaa, told you so!" at us.

It's not self-evident to me. I'm always learning new stuff about TEI. What's the advantage of data.enumerated in the absence of a valList?

On Thu, Oct 8, 2015 at 11:08 AM, Syd Bauman wrote:

...

I do not know if my comments are welcome on this matter any more, since I am being completely over-ruled on this. So feel free to continue to ignore me. But that said, could we at least make the datatype of @scope data.enumerated, not data.word? I'll argue why if needed, but I'm hoping this is self-evident. (Of course, I think the whole idea of having such an attribute *without* a suggested values list is self-evidently stupid, so apparently my barometer on self-evidentness is mis-calibrated.)

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

My own answer to that would be the question "Why doesn’t your Dublin Core tell me what it’s talking about?"

On Oct 8, 2015, at 14:50 , Syd Bauman wrote:

"I'm adding some Dublin Core metadata to a bunch of TEI files. Do I need to explicitly indicate whether that DC metadata is about the TEI file or is about the book (or whatever) from which that TEI file was transcribed, or can I get away with just leaving it unsaid?

I think the weight of opinion is now for leaving out @scope, so, trying again: I’m about to check in a version with @scope removed. I have switched the Guidelines example to one that didn’t use @scope, and I’ve modified the example that did use @scope so that its Dublin Core is wrapped in RDF that says explicitly what the DC is talking about—I think obviating the need for @scope. Let me know what you think and maybe we can try for a release tomorrow. We’ll discuss attributes for <xenoData> at the F2F with the aim of deciding what to do (if anything) in the next release.

On Oct 8, 2015, at 15:27 , Fabio Ciotti wrote:

In this second turn election I vote for 1.

I think we should com up with a set of use cases and discuss them during f2f, to find the better solutions.

f

2015-10-08 19:18 GMT+02:00 Martin Holmes :

...

I will go with option 1, as long as we follow it up with a consultation with the community to get a sense of the range of uses they would put it to.

Cheres, Martin

On 15-10-08 09:05 AM, Lou Burnard wrote:

...

As we seem to be some way from a consensus on the right way forward, may I propose a further vote?

Option 1. Remove the attribute @scope for now.

Option 2. Remove the xenoData element for now.

We can then thrash out what is clearly a somewhat divisive issue at the ftf, targetting the next release for its resolution.

My vote is (now) for option 1, but I can live with option 2.

On 08/10/15 16:14, Hugh Cayless wrote:

...

Syd, your input is *always* welcome, and it is possible that we're all wrong and you're right. If so, you get to sing "Nyaa, nyaa, told you so!" at us.

It's not self-evident to me. I'm always learning new stuff about TEI. What's the advantage of data.enumerated in the absence of a valList?

On Thu, Oct 8, 2015 at 11:08 AM, Syd Bauman wrote:

I do not know if my comments are welcome on this matter any more,

...

since I am being completely over-ruled on this. So feel free to continue to ignore me. But that said, could we at least make the datatype of @scope data.enumerated, not data.word? I'll argue why if needed, but I'm hoping this is self-evident. (Of course, I think the whole idea of having such an attribute *without* a suggested values list is self-evidently stupid, so apparently my barometer on self-evidentness is mis-calibrated.)

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- Fabio Ciotti Dipartimento di Studi letterari, Filosofici e Storia dell’arte Università di Roma Tor Vergata President "Associazione Informatica Umanistica Cultura Digitale" (AIUCD) -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

Incidentally, James, I'm seeing some funny behavior with Mr. Oxford Jenkins. It, or some part of its web stack, seems confused about where things are, making it hard to view artifacts. If I do curl -IL http://tei.it.ox.ac.uk/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/P5 I get: HTTP/1.1 302 Found Date: Thu, 08 Oct 2015 13:16:30 GMT Server: Jetty(winstone-2.8) Location: http://tei.it.ox.ac.uk//job/TEIP5/lastSuccessfulBuild/artifact/P5/ Via: 1.1 tei.it.ox.ac.uk HTTP/1.1 404 Not Found Date: Thu, 08 Oct 2015 13:16:30 GMT Server: Apache/2.2.22 (Debian) Vary: Accept-Encoding Content-Type: text/html; charset=iso-8859-1 i.e., it's redirecting me to a path that lacks the /jenkins/ bit, and then telling me no it doesn't have that. Could be rewriteRules or maybe a slightly misconfigured proxy. On Thu, Oct 8, 2015 at 8:53 AM, James Cummings wrote:

Maybe I'm missing earlier discussion but with the examples on the ref page why not declare the namespace prefixes on xenodata? (Yes, in reality you'd do it on root TEI.)

James

-- Dr James Cummings, Academic IT, University of Oxford

-----Original Message----- From: Hugh Cayless [philomousos@gmail.com] Received: Thursday, 08 Oct 2015, 8:08 To: TEI Council [tei-council@lists.tei-c.org] Subject: [tei-council] Release?

The modified xenoData sections are viewable at

http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/rel... and

http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/rel...

Can at least some of you look them over and either approve or suggest/make corrections?

Once that's done, we need to decide whether we're proceeding with the release today. tomorrow, or at some later date. I don't have an opinion yet in the absence of feedback on the latest changes, except to say that I'd like to get this over with. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

The text is clear, but perhaps it's worth adding a sentence about @scope. Or are we intentionally leaving that out until we figure out what to do with it?

Indeed, Raffaele, we (meaning Lou, Martin, Peter, and James) have decided to thaw the freeze and remove the suggested values list for @scope, replacing it with only "May be used to name the referent of the data contained in xenoData". (Which seems to me to be outright incorrect -- it is not, and should not be, a *name*.) Fabio, Hugh, and I dissented, believing it would better not to have @scope than to have it w/o a suggested values list. @scope is also now defined as the wrong datatype, about which I'll be answering Hugh in a minute in the hopes that we can correct at least one of our egregious errors before we release Guidelines that explicitly and deliberately fail to provide guidance that we can quite easily predict would be useful.

Don't use tei.it.ox.ac.uk use bits.nsms.ox.ac.uk the tei.it ... /jenkins is a poor proxying. James -- Dr James Cummings, Academic IT, University of Oxford -----Original Message----- From: Hugh Cayless [philomousos@gmail.com] Received: Thursday, 08 Oct 2015, 9:21 To: TEI Council [tei-council@lists.tei-c.org] Subject: Re: [tei-council] Release? Incidentally, James, I'm seeing some funny behavior with Mr. Oxford Jenkins. It, or some part of its web stack, seems confused about where things are, making it hard to view artifacts. If I do curl -IL http://tei.it.ox.ac.uk/jenkins/job/TEIP5/lastSuccessfulBuild/artifact/P5 I get: HTTP/1.1 302 Found Date: Thu, 08 Oct 2015 13:16:30 GMT Server: Jetty(winstone-2.8) Location: http://tei.it.ox.ac.uk//job/TEIP5/lastSuccessfulBuild/artifact/P5/ Via: 1.1 tei.it.ox.ac.uk HTTP/1.1 404 Not Found Date: Thu, 08 Oct 2015 13:16:30 GMT Server: Apache/2.2.22 (Debian) Vary: Accept-Encoding Content-Type: text/html; charset=iso-8859-1 i.e., it's redirecting me to a path that lacks the /jenkins/ bit, and then telling me no it doesn't have that. Could be rewriteRules or maybe a slightly misconfigured proxy. On Thu, Oct 8, 2015 at 8:53 AM, James Cummings wrote:

Maybe I'm missing earlier discussion but with the examples on the ref page why not declare the namespace prefixes on xenodata? (Yes, in reality you'd do it on root TEI.)

James

-- Dr James Cummings, Academic IT, University of Oxford

-----Original Message----- From: Hugh Cayless [philomousos@gmail.com] Received: Thursday, 08 Oct 2015, 8:08 To: TEI Council [tei-council@lists.tei-c.org] Subject: [tei-council] Release?

The modified xenoData sections are viewable at

http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/rel... and

http://teijenkins.hcmc.uvic.ca/job/TEIP5/lastSuccessfulBuild/artifact/P5/rel...

Can at least some of you look them over and either approve or suggest/make corrections?

Once that's done, we need to decide whether we're proceeding with the release today. tomorrow, or at some later date. I don't have an opinion yet in the absence of feedback on the latest changes, except to say that I'd like to get this over with. -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council PLEASE NOTE: postings to this list are publicly archived

On 15-10-08 08:57 AM, Syd Bauman wrote:

I would vote very strongly *against* deliberately including an example of what is probably a bad idea. (You've convinced me, for now, that we should *allow* people to put non-XML data in there; I sure as #%!! don't think we should encourage it.)

...

I like what's there, and I can't see any errors. I think it might be useful to include one example which isn't XML -- maybe Hugh's GeoJSON -- but that's not a blocker for now.

This really seems wrong to me. It's external metadata. Why should you care what format it's in? There's nothing inherently wrong with (e.g.) JSON; it's not worse than XML in some way, just a different language for a different purpose (rapid transmission and parsing with JavaScript). It's surely the sort of thing people will want to put in there; why not signal that it's OK? Cheers, Martin