I don't know if this is significant or if someone's on top of this, but I see 5 pull requests waiting to be merged into the Stylesheets repo, including the one from Syd's sydboccurs2 branch with corrections on @minOccurs and @maxOccurs. I'm not sure of protocol on merging pull requests, but don't we need to pull in Syd's branch, or are we testing the Stylesheets using that branch to make sure the updates work properly prior to release? Elisa Typeset by hand on my iPad

On Dec 2, 2016, at 2:06 PM, Syd Bauman wrote:

The updates for *validation* of @minOccurs and @maxOccurs have been pushed into the TEI repo, and seem to be working fine. (HTML tagdoc page correct, but a bit ugly IIRC.) I had hoped to get wide agreement (preferable) or serious dissension from my "do what W3C does" solution, but haven't really.

As for *processing* of @minOccurs and @maxOccurs, I am pretty sure that the code in the sydb-occurs2/ branch works for RNG (and thus XSD), although Lou would prefer some different choices for some invalid combinations. (In particular, LB wants the invalid combination @minOccurs="3" with no @maxOccurs to behave as though @maxOccurs were unbounded.) I have no objection to changing it to what LB wants, but see no need to do so in a rush.

HOWEVER, I am having a bit of a hard time getting DTDs to work, in large part because they are always invalid because there are content models that are not surrounded by parens. I do not know if this is an error in something I did or that "dtdMagic" absorption into odd2dtd was incomplete. I tried calling Hugh a few minutes ago to see if we could hammer that out, but he wasn't around.

SO, my point is that release is not ready because DTDs are not ready, but otherwise things should be ready very soon, IMHO. -- 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

Au contraire! DTD generation is working now (at least, I don't get any invalid DTDs in my tiny tests). I'm not sure it would make sense to issue a pull request for a change that would make things worse. I'm hoping it makes things better. But Elisa has made an important point. There are 4 pull requests from contributors who are not on Council pending. 1) Do we have a procedure for honoring or rejecting such pull requests? 2) Who among us has the GitHub authority to make such a pull? 3) Who among us has the TEI authority to make such a pull? 4) Who among us has the technical chops to be sure such a pull is the right thing to do? 1) I don't think we do have a process, but I think we should. I don't know enough about git to be confident of what it should be, though. Ideally it would boil down to something like "Councilor volunteers for, or is assigned the pull (by Council Chair); Councilor creates a copy of repo that reflects the pull, and tests it locally; Councilor posts results of test to rest of us with a recommendation; 1 week later Councilor executes recommendation (either pulling in or declining to do so, explaining why to requester), unless there has been discussion to the contrary.". 2) Idunno. Back in the Sourceforge days Lou and I both had such authority. James, too, IIRC. Maybe anyone can do it? What's the difference between a "contributor" and a "member", anyway? 3) At first crack, I would say all members of Council. 4) This one's easy -- no one. :-|

Sorry--I'm not awake yet...Of course, now that I reread all the posts, I guess we're not ready to commit these branches to Stylesheets dev. (Of course we haven't resolved the minOccurs/maxOccurs discussion and DTD processing doesn't work yet, though I think if we have to ignore DTDs the latest solution ought to be fine generally). But hope we're testing stuff against the branches.

Incidentally, I think I noticed there are some other chapters which declare (i.e. xinclude the specs for) classes or elements which don't seem to be mentioned (i.e. not there as <gi> or in a <specDesc> or <ident>) in that chapter. Post-release we should probably write a test for this to alert us at very least that these are places where the prose needs to be expanded to discuss the specs included in that chapter. -James On 03/12/16 12:48, Lou Burnard wrote:

I started trying to update the prose, which led me to look more closely. I noticed the following a) there is a list of global attributes in ST which includes some module specific ones, but not all of them b) the new att.global.source class though described in ST is actually declared in CO

I'll try to rectify both these departures from orthodoxy later today, unless anyone objects. On (a) I think we should describe only the attributes actually provided by the ST module in ST, though with references to (all) the other subclasses. On (b) I assume Homer nodded.

On 02/12/16 18:27, James Cummings wrote:

...

That's good news. Of course I've not tested that @source now actually appears globally. Anyone might want to run an eye over the brief prose about it (in ST from memory). If anyone finds any references to att.source or att.readFrom anywhere that would be an error. I tried to change these all to att.global.source

James

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

On 2 Dec 2016 18:21, Lou Burnard wrote: I checked out P5 and Stylesheets this afternoon, then ran P5 makefile successfully to a conclusion locally. So yes, we seem to be getting somewhere!

On 02/12/16 17:47, Hugh Cayless wrote:

...

There was a commit by James referencing it, so I guess so. We'll see :-)

On Fri, Dec 2, 2016 at 12:37 PM, Lou Burnard wrote:

...

Did if you fix the predeclare issue ? DTDs won't work otherwise.

Sent from my Honor Mobile

-------- Original Message -------- Subject: Re: [tei-council] Release 3.1.0 where are we? From: James Cummings To: tei-council@lists.tei-c.org CC:

I'm assuming that it will break all tests because I've not done anything for that. Only on phone here can be online in a few hours if needed.

James

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

On 2 Dec 2016 17:31, Hugh Cayless wrote: I think it's a bad idea to release on a Friday anyway :-)

I've merged the att.global.source branch. Let's see if Jenkins likes it. FYI, I did:

git fetch --all (to make sure I had all the remote branches) git checkout att.global.source git rebase dev (git merge dev would work too--rebase seemed fairly safe in this case) git checkout dev git merge att.global.source

On Fri, Dec 2, 2016 at 12:14 PM, Magdalena Turska wrote:

...

Just to answer James' timing question, his dates would work for me, except for Friday 16th

2016-12-02 17:06 GMT+00:00 Hugh Cayless :

...

I can merge it if no-one's done it yet. What about the max/minOccurs thing? Is there a fix in the works Syd? When can we create a release branch?

On Wed, Nov 30, 2016 at 2:09 PM, James Cummings < James.Cummings@it.ox.ac.uk> wrote:

> Hi Hugh, > > Sorry, things have been very busy for me at the moment here. (Everyone has > noticed that the end of the calendar year is coming and > they suddenly have > cropped up wanting everything finished before then.) > > I think the work and prose for the att.global.source is > done. Lou was > starting to test that branch, but if someone could and > get it merged in, > that'd be good to get that one off the docket. I think > the Lou/Syd > @maxOccurs (where I think the default should be assumed > to be unbounded but > I've not been closely following the discussion) is the > real release > blocker. There are a couple there that are still marked > Needs Discussion, > if that is the case then those should be postponed to > next release. > > If we need to push the date back (so that people can > solve these problems, > test everything builds, check prose, etc.) then I am also > potentially > available for most of the 13/14/15/19/20/21 but don't know Magdalena's > schedule. > > Other than solving those problems, merging those > branches, then adding > notes to the release notes if you've implemented > _anything_ since January. > -James > > > > On 30/11/16 17:39, Hugh Cayless wrote: > >> Given that we were supposed to make a release branch >> last week, it seems >> safe to say we're not ready to go :-). >> https://github.com/TEIC/TEI/milestone/2 shows 7 open >> tickets, including >> the >> showstopper one flagged by Syd and Lou. I'm presuming we >> should push the >> release date back. Does anyone need help? James and >> Magdalena, what do you >> need from us? >> > -- > Dr James Cummings, James.Cummings@it.ox.ac.uk > Academic IT Services, University of Oxford > > -- > 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

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

-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

On 03/12/16 13:35, Lou Burnard wrote:

Indeed so. In fact, I think I wrote just such a stylesheet when I was working on The Schemaspec Formerly Known as TEI Simple

Excellent! Let's not run it on the whole TEI until after release. I suspect it will find a whole bunch of places where we have introduced elements or classes and not actually discussed them in the prose. Which sounds like a thing that we should not be doing. -James -- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

I disagree. @facs is for pointing to image facsimiles of something (like a page). @source (if I understand correctly) is for pointing to the source of the content. In a digital world that may be a digital edition, text, or something that can be identified with a URI. If I am quoting a digital edition, I would expect to be able to point to that edition (and better inside it). I've tried to phrase it so vaguely because @source is also used on schemaSpec and other ODD components. I'm happy for it to be rephrased however... just want to make sure it is understood why it is so vague. ;-) -james On 03/12/16 13:46, Lou Burnard wrote:

"the attribute will contain a pointer to a digital surrogate of that source or a description of it,"

I don't think you can use @source to point to a "digital surrogate" can you? That's @facs in my book.

-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

I think you and I agreed in that discussion. (And remember that I'm not entirely comfortable with @source being global... I was just out-voted.) I'll have a look this late-afternoon then. -J On 03/12/16 13:53, Lou Burnard wrote:

Well, let's not reprise the discussion about whether to use <ref> or <bibl> or <bibl> containing <ref> ...

I'll check in my rewrite after lunch and you can then correct that!

On 03/12/16 13:51, James Cummings wrote:

...

I disagree. @facs is for pointing to image facsimiles of something (like a page). @source (if I understand correctly) is for pointing to the source of the content. In a digital world that may be a digital edition, text, or something that can be identified with a URI. If I am quoting a digital edition, I would expect to be able to point to that edition (and better inside it). I've tried to phrase it so vaguely because @source is also used on schemaSpec and other ODD components.

I'm happy for it to be rephrased however... just want to make sure it is understood why it is so vague. ;-)

-james

On 03/12/16 13:46, Lou Burnard wrote:

...

"the attribute will contain a pointer to a digital surrogate of that source or a description of it,"

I don't think you can use @source to point to a "digital surrogate" can you? That's @facs in my book.

-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

Changes and example seem reasonable to me. -James On 03/12/16 16:28, Lou Burnard wrote:

Sorry, took longer than expected. All checked in now though.

On 03/12/16 13:59, James Cummings wrote:

...

I think you and I agreed in that discussion. (And remember that I'm not entirely comfortable with @source being global... I was just out-voted.)

I'll have a look this late-afternoon then.

-J

On 03/12/16 13:53, Lou Burnard wrote:

...

Well, let's not reprise the discussion about whether to use <ref> or <bibl> or <bibl> containing <ref> ...

I'll check in my rewrite after lunch and you can then correct that!

On 03/12/16 13:51, James Cummings wrote:

...

I disagree. @facs is for pointing to image facsimiles of something (like a page). @source (if I understand correctly) is for pointing to the source of the content. In a digital world that may be a digital edition, text, or something that can be identified with a URI. If I am quoting a digital edition, I would expect to be able to point to that edition (and better inside it). I've tried to phrase it so vaguely because @source is also used on schemaSpec and other ODD components.

I'm happy for it to be rephrased however... just want to make sure it is understood why it is so vague. ;-)

-james

On 03/12/16 13:46, Lou Burnard wrote:

...

"the attribute will contain a pointer to a digital surrogate of that source or a description of it,"

I don't think you can use @source to point to a "digital surrogate" can you? That's @facs in my book.

-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

I have to go to a doctor's appt now, but can check-in a fix for this in a few hours if you (the release techs) like. I also have cleaned up references to @render, as it will be removed on 2017-01-01 or so. Back in a few hours.

In both the prose (1.3.1.1.4 "Sources, certainty, and responsibility") and the tagdoc discussing the new att.global.source, URIs are divided into "full", "fragmentary", and "private-URI syntax". I'm not sure what these mean. I would prefer we divide the world of our URIs up into "absolute", "relative", and something like "private URI that will be expanded to an absolute URI as documented in a <preFixDef> in the TEI header".