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