- From: Pierre-Anthony Lemieux <pal@sandflow.com>
- Date: Tue, 2 Feb 2016 11:31:26 -0800
- To: Glenn Adams <glenn@skynav.com>
- Cc: Dae Kim <dakim@netflix.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, TTWG <public-tt@w3.org>
Thanks for adding a definition for "conditionalized element" in the latest ED! Best, -- Pierre On Fri, Jan 29, 2016 at 9:30 AM, Glenn Adams <glenn@skynav.com> wrote: > > > On Fri, Jan 29, 2016 at 10:24 AM, Pierre-Anthony Lemieux <pal@sandflow.com> > wrote: >> >> > btw, what does "conditionalized element" have to do with the initial >> > element? >> >> "conditionalized element" is referenced in the definition of >> <condition>, which is referenced by the definition of <initial>. > > > most every element type in TTML2 now specifies optional use of the > @condition attribute; so that isn't related to the initial element as such > >> >> >> More importantly, TTML2 is unfinished, so I am interested in >> understanding how users plan to use it, so that their feedback can >> guide decisions by the group, including features at risk. > > > there are no features at risk at this juncture, since we have not surveyed > any implementations to determine coverage; i am aware of at least two > implementations that support the condition element > >> >> >> Best, >> >> -- Pierre >> >> On Fri, Jan 29, 2016 at 9:16 AM, Glenn Adams <glenn@skynav.com> wrote: >> > >> > >> > On Fri, Jan 29, 2016 at 8:14 AM, Pierre-Anthony Lemieux >> > <pal@sandflow.com> >> > wrote: >> >> >> >> Hi Dae, >> >> >> >> > initial >> >> >> >> How does Netflix plan to use <initial>? >> >> >> >> The current ED states "conditionalized element" is "To Be Defined". >> > >> > >> > btw, what does "conditionalized element" have to do with the initial >> > element? >> > >> >> >> >> >> >> Best, >> >> >> >> -- Pierre >> >> >> >> On Thu, Jan 28, 2016 at 9:35 AM, Dae Kim <dakim@netflix.com> wrote: >> >> > Hello all, >> >> > >> >> > We're starting to engage with subtitle program vendors for TTML2 >> >> > support >> >> > and >> >> > I'm hoping the following features will be preserved as-is to Rec: >> >> > >> >> > initial >> >> > >> >> > >> >> > https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#styling-vocabulary-initial >> >> > >> >> > tts:position >> >> > >> >> > >> >> > https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-position >> >> > >> >> > tts:textEmphasis >> >> > >> >> > >> >> > https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-textEmphasis >> >> > >> >> > tts:ruby >> >> > >> >> > >> >> > https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-ruby >> >> > >> >> > tts:rubyAlign >> >> > >> >> > >> >> > https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-rubyAlign >> >> > >> >> > tts:rubyPosition >> >> > >> >> > >> >> > https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-rubyPosition >> >> > >> >> > tts:rubyReserve (specifically, "outside") >> >> > >> >> > >> >> > https://rawgit.com/w3c/ttml2/master/spec/ttml2.html?content-type=text/html;charset=utf-8#style-attribute-rubyReserve >> >> > >> >> > If everyone can kindly review, I'd like to collect everyone's >> >> > opinions >> >> > on >> >> > these. >> >> > >> >> > >> >> > Cheers, Dae >> >> > >> >> > >> >> > >> >> > Dae Kim | Video Engineer | Encoding Technology >> >> > 9420 94f4 a834 b038 2920 34b3 38ad b632 3738 942c 942f >> >> > >> >> > On Thu, Jan 28, 2016 at 8:34 AM, Nigel Megitt >> >> > <nigel.megitt@bbc.co.uk> >> >> > wrote: >> >> >> >> >> >> Thanks all for attending today's TTWG meeting. Minutes can be found >> >> >> in >> >> >> HTML format at https://www.w3.org/2016/01/28-tt-minutes.html >> >> >> >> >> >> In text format: >> >> >> >> >> >> [1]W3C >> >> >> >> >> >> [1] http://www.w3.org/ >> >> >> >> >> >> Timed Text Working Group Teleconference >> >> >> >> >> >> 28 Jan 2016 >> >> >> >> >> >> See also: [2]IRC log >> >> >> >> >> >> [2] http://www.w3.org/2016/01/28-tt-irc >> >> >> >> >> >> Attendees >> >> >> >> >> >> Present >> >> >> nigel, andreas, pierre, shinjan, glenn, tmichel, dae >> >> >> >> >> >> Regrets >> >> >> frans >> >> >> >> >> >> Chair >> >> >> nigel >> >> >> >> >> >> Scribe >> >> >> nigel >> >> >> >> >> >> Contents >> >> >> >> >> >> * [3]Topics >> >> >> 1. [4]This Meeting >> >> >> 2. [5]Action Items >> >> >> 3. [6]IMSC issues >> >> >> 4. [7]Commit policy on github >> >> >> * [8]Summary of Action Items >> >> >> * [9]Summary of Resolutions >> >> >> __________________________________________________________ >> >> >> >> >> >> <tmichel> I will be a few minutres late ... >> >> >> >> >> >> <scribe> scribe: nigel >> >> >> >> >> >> This Meeting >> >> >> >> >> >> nigel: [Goes through likely topics for meeting]: Actions, IMSC >> >> >> 1 issues, TTML2, possibly profiles >> >> >> ... Any specific topics to cover, or AOB? >> >> >> >> >> >> pal: IMSC 1 issues please >> >> >> >> >> >> nigel: Yes >> >> >> >> >> >> glenn: I'd like to discuss commit policy on github >> >> >> >> >> >> nigel: Okay >> >> >> >> >> >> Action Items >> >> >> >> >> >> action-453? >> >> >> >> >> >> <trackbot> action-453 -- Thierry Michel to Schedule between >> >> >> tmichel and philippe the transition to cr3 with any director >> >> >> call as needed. -- due 2016-01-21 -- PENDINGREVIEW >> >> >> >> >> >> <trackbot> >> >> >> [10]http://www.w3.org/AudioVideo/TT/tracker/actions/453 >> >> >> >> >> >> [10] http://www.w3.org/AudioVideo/TT/tracker/actions/453 >> >> >> >> >> >> tmichel: IMSC 1 CR3 is published and has been announced to AC >> >> >> and Chairs, and triggered a 2 month patent exclusion >> >> >> >> >> >> close action-453 >> >> >> >> >> >> <trackbot> Closed action-453. >> >> >> >> >> >> tmichel: I had to extend the CR exit point to Feb 28 because we >> >> >> moved the publication back by 2 days. >> >> >> >> >> >> nigel: Thanks >> >> >> >> >> >> pal: I'll modify that on github too - Feb 28? >> >> >> >> >> >> tmichel: Feb 28 yes >> >> >> >> >> >> nigel: Thanks everyone whose helped with publication of that >> >> >> CR. >> >> >> >> >> >> action-454? >> >> >> >> >> >> <trackbot> action-454 -- Philippe Le Hégaret to Create stub >> >> >> files to redirect from hg to github for ttml1 and ttml2 -- due >> >> >> 2016-01-28 -- PENDINGREVIEW >> >> >> >> >> >> <trackbot> >> >> >> [11]http://www.w3.org/AudioVideo/TT/tracker/actions/454 >> >> >> >> >> >> [11] http://www.w3.org/AudioVideo/TT/tracker/actions/454 >> >> >> >> >> >> glenn: I noticed on the CR3 that a message was issued, a call >> >> >> for exclusions message. Is a call for exclusions a >> >> >> ... multiple event or a single event? Normally in the past >> >> >> process a call for exclusions only occurred on the first CR >> >> >> ... but not subsequent CRs. Has that changed? >> >> >> >> >> >> tmichel: It's actually the com team who does that. I don't >> >> >> remember - I need to check if we sent an exclusion for the >> >> >> ... 2nd CR and will look into it and let you know. My >> >> >> interpretation is every CR publication triggers an exclusion >> >> >> ... period of 2 months, but I will investigate. >> >> >> ... It makes sense because if you add functionality into the CR >> >> >> version then it may result in a patent exclusion. >> >> >> >> >> >> glenn: I agree. >> >> >> >> >> >> action-454? >> >> >> >> >> >> nigel: Okay I guess we'll close this one. >> >> >> >> >> >> close action-454 >> >> >> >> >> >> <trackbot> Closed action-454. >> >> >> >> >> >> action-455? >> >> >> >> >> >> <trackbot> action-455 -- Glenn Adams to Update ttml2 >> >> >> spec/readme to include config for keyword replacement. -- due >> >> >> 2016-01-28 -- OPEN >> >> >> >> >> >> <trackbot> >> >> >> [12]http://www.w3.org/AudioVideo/TT/tracker/actions/455 >> >> >> >> >> >> [12] http://www.w3.org/AudioVideo/TT/tracker/actions/455 >> >> >> >> >> >> action-445? >> >> >> >> >> >> <trackbot> action-445 -- Andreas Tai to Propose to mdolan this >> >> >> addition to the profile registry document. -- due 2015-11-06 -- >> >> >> OPEN >> >> >> >> >> >> <trackbot> >> >> >> [13]http://www.w3.org/AudioVideo/TT/tracker/actions/445 >> >> >> >> >> >> [13] http://www.w3.org/AudioVideo/TT/tracker/actions/445 >> >> >> >> >> >> atai: I checked with Mike and will make a proposal for a new >> >> >> column for the profile registry table that shows where >> >> >> ... the profile information can be found inside the TTML >> >> >> document instance for the corresponding TTML profile >> >> >> specification. >> >> >> ... Some are for ttp:profile attribute, or element, or >> >> >> ebuttm:documentConformsToStandard element. >> >> >> >> >> >> mike: Andreas and I exchanged a couple of emails and it makes >> >> >> sense to me. >> >> >> ... I'm hopelessly behind on the profile document! >> >> >> >> >> >> nigel: What can I do to help? >> >> >> >> >> >> mike: The wiki is what I think we want to produce, in the text. >> >> >> It's more about putting it into a document template >> >> >> ... and using the tools to publish it in W3C. >> >> >> >> >> >> nigel: Thierry, would you be able to assist? >> >> >> >> >> >> tmichel: Yes, I'd be happy to help turn the wiki text into a >> >> >> first version on github >> >> >> >> >> >> action-429? >> >> >> >> >> >> <trackbot> action-429 -- Mike Dolan to Draft a wg note for the >> >> >> profile short name registry and ttml media type registration -- >> >> >> due 2015-10-08 -- OPEN >> >> >> >> >> >> <trackbot> >> >> >> [14]http://www.w3.org/AudioVideo/TT/tracker/actions/429 >> >> >> >> >> >> [14] http://www.w3.org/AudioVideo/TT/tracker/actions/429 >> >> >> >> >> >> action-429: [TTWG meeting 2016-01-28] tmichel to help this >> >> >> along with a first draft on github >> >> >> >> >> >> <trackbot> Notes added to action-429 Draft a wg note for the >> >> >> profile short name registry and ttml media type registration. >> >> >> >> >> >> close action-445 >> >> >> >> >> >> <trackbot> Closed action-445. >> >> >> >> >> >> IMSC issues >> >> >> >> >> >> pal: I'd like to start with issue #127 >> >> >> >> >> >> [15]https://github.com/w3c/imsc/issues/127 >> >> >> >> >> >> [15] https://github.com/w3c/imsc/issues/127 >> >> >> >> >> >> nigel: Extensibility goals not documented >> >> >> >> >> >> pal: The discussion is whether or how IMSC 1 can have an >> >> >> opinion on IMSC 2 and how an IMSC 1 document will be >> >> >> ... processed by an IMSC 2 processor and vice versa. Before we >> >> >> have started on IMSC 2 it is very difficult to have a >> >> >> ... good opinion. I think we should have that discussion when >> >> >> we start on IMSC 2. >> >> >> >> >> >> glenn: The issue here is whether we address this in IMSC 1 or >> >> >> wait. I'm insisting on addressing it in IMSC 1 and not >> >> >> ... waiting. I agree that it needs a bit of thinking. We don't >> >> >> have to refer to IMSC 2, we can simply refer to future >> >> >> ... versions. At least TTML2 talks about future and past >> >> >> versions. >> >> >> ... In retrospect we should have given more thought to >> >> >> extensibility and at least documented our goals. I'm asking >> >> >> ... for informative material that describes our goals. It would >> >> >> be a sad state of affairs if we cannot document our goals now. >> >> >> >> >> >> pal: I don't think this is as dire as you just painted it. IMSC >> >> >> 1 already allows foreign vocabulary, which allows for >> >> >> ... straightforward extensibility. >> >> >> >> >> >> glenn: It may be sufficient to describe those goals, for >> >> >> example the goal of supporting vocabulary not in IMSC 1. >> >> >> >> >> >> pal: That's §6.2 >> >> >> >> >> >> glenn: I'm asking for a specifically labelled section on goals, >> >> >> in an annex, the introduction or somewhere else. >> >> >> >> >> >> pal: Okay. I don't really know how to write that section. I'd >> >> >> like to consider a concrete proposal. >> >> >> >> >> >> glenn: I hope people already have goals in mind and could >> >> >> articulate them. >> >> >> ... Foreign vocabulary is one goal. The same comments are going >> >> >> to apply with #126 on interoperability. >> >> >> >> >> >> nigel: [opens up to group to offer options for extensibility] >> >> >> >> >> >> glenn: Both forward and backward compatibility come into this >> >> >> category. I would hope that a goal is to be as >> >> >> ... forward and backward compatible as possible, as a generic >> >> >> goal that applies to most of W3C development. >> >> >> ... That doesn't mean it's not possible to create a breaking >> >> >> change in the future. If we think that such a breaking change >> >> >> ... could occur then we could document it as a discussion >> >> >> point. >> >> >> >> >> >> nigel: One of the points I think is probably implied is that >> >> >> the purpose of the profile exercise is that extensions from >> >> >> within TTML are excluded unless listed. >> >> >> >> >> >> glenn: Since we don't list all the features there's an >> >> >> implication that unlisted features from TTML 1 are permissible >> >> >> in IMSC 1, yes? >> >> >> >> >> >> pal: We put a significant effort in to list all TTML 1 profile >> >> >> features. >> >> >> >> >> >> glenn: Okay, so all features from TTML Annex D are listed as >> >> >> prohibited or permitted, yes? >> >> >> >> >> >> pal: Yes, that was the goal, and I think we achieved it. >> >> >> >> >> >> glenn: We could argue about if that's extensibility or >> >> >> interoperability, but it is possibly both, so we could discuss >> >> >> that under extensibility goals. >> >> >> ... I suggest we open this up for comments over the next couple >> >> >> of weeks and that I will draft a proposal based on that. >> >> >> >> >> >> nigel: Those comments should be on the github issue >> >> >> >> >> >> pal: What are we asking people to do? >> >> >> >> >> >> glenn: Give us opinions on what are and are not extensibility >> >> >> goals. >> >> >> ... I haven't written down my own thoughts on this yet. I'm >> >> >> more struck by the absence of this topic than anything else. >> >> >> That was my point in filing the issue. >> >> >> ... I'm prepared to draft something but can't articulate my own >> >> >> thinking on this right now. >> >> >> >> >> >> nigel: I think we should be careful to understand if we need >> >> >> this or if we can build on something already in TTML1 >> >> >> ... by inheritance? >> >> >> >> >> >> glenn: I don't think we have extensibility goals described in >> >> >> TTML1 >> >> >> ... which in retrospect we should have put in. >> >> >> ... In TTML1 we used a QA guideline checklist. One of the >> >> >> points there was a set of good practices. Number 18 >> >> >> ... states that if extensibility is allowed define an extension >> >> >> mechanism. >> >> >> ... I suggest we review what's in IMSC 1 and TTML 1 and go from >> >> >> there. >> >> >> >> >> >> nigel: Okay so action on everyone to complete this research and >> >> >> record their goals in the issue. >> >> >> >> >> >> glenn: Very much the same comments apply to the >> >> >> interoperability issue. >> >> >> >> >> >> pal: What's the time box that we have on this? >> >> >> >> >> >> glenn: I can respond by mid-Feb with some material. >> >> >> >> >> >> nigel: Okay, that sounds like 2 weeks to note extensibility and >> >> >> interoperability goals in the github issues. >> >> >> >> >> >> pal: How are we doing on #111 and #114? >> >> >> >> >> >> glenn: I've got to draft some material based on a conversation >> >> >> I had with Nigel, where we think we may be able to resolve both >> >> >> of those. >> >> >> ... Mid-Feb is reasonable for those too. >> >> >> >> >> >> pal: #125 [16]https://github.com/w3c/imsc/issues/125 Unable to >> >> >> normatively determine non-conformance when testing content >> >> >> constraints. >> >> >> >> >> >> [16] https://github.com/w3c/imsc/issues/125 >> >> >> >> >> >> glenn: At present IMSC 1 specifies that if a document is not >> >> >> conformant then behaviour is undefined. Correct? >> >> >> >> >> >> pal: Correct. The document does not specify a normative >> >> >> behaviour in the presence of a non-conformant document. >> >> >> >> >> >> glenn: A couple of points: 1. Since all behaviour re >> >> >> non-conformance is unspecified then it is impossible to >> >> >> normatively >> >> >> ... test non-conformance because any outcome is possible, from >> >> >> aborting to ignoring and anything in between. >> >> >> ... I'm not happy with that state of affairs. Part 2, which I >> >> >> did make a proposal for, is to introduce the concept of a >> >> >> ... validating processor and to allow for some normative >> >> >> behaviour in the face of non-conformance if and when the >> >> >> ... IMSC processor is also a validating processor. So an IMSC >> >> >> transformation or validation processor that also supports >> >> >> ... validation and it is enabled then it is possible to define >> >> >> some constraints on non-conformance. >> >> >> >> >> >> atai: I thought the conclusion here from previous meetings when >> >> >> we discussed this is that handling of non-conformant >> >> >> ... files is out of spec and I agree with that. What Glenn >> >> >> wants to define is behaviour on encountering non-conformant >> >> >> documents. >> >> >> ... I think that's out of scope of the spec. The topic came up >> >> >> before and from what I read of the minutes the conclusion >> >> >> ... was out of scope. >> >> >> >> >> >> pal: That's my recollection, but it sounds like Glenn is >> >> >> proposing something a little narrower, only for validating >> >> >> processors. >> >> >> ... So for those who choose to describe processors as >> >> >> validating then this is the behaviour. >> >> >> >> >> >> glenn: That's right. I don't disagree with Andreas but I think >> >> >> we can do better than that at little or no cost to the >> >> >> specification. >> >> >> ... For example the TTT toolset has a presentation engine in >> >> >> it. It performs validation processing as a precursor to >> >> >> ... presentation. It's an existing implementation (also of a >> >> >> transformation processor) that does implement the optional >> >> >> ... features of validation. So we can go further than saying >> >> >> it's completely out of scope and having normative >> >> >> ... language that allows us to introduce defined behaviour. >> >> >> >> >> >> pal: The particular thing here is that it's a class of >> >> >> processors described as validating processors. >> >> >> >> >> >> glenn: Yes, TTML2 introduces these all formally along with some >> >> >> specific vocabulary for controlling it. I didn't want >> >> >> ... to inject that into this proposal because that would be >> >> >> going too far, but I took the semantics of what we're >> >> >> ... proposing and put them into a form that we could adopt in >> >> >> IMSC 1. >> >> >> >> >> >> atai: Thank you for the clarification. It is of course a >> >> >> different use case. I would like to see the concrete proposal. >> >> >> ... There are of course existing possibilities to check >> >> >> conformance, for example using an XML schema. This already >> >> >> ... has a defined behaviour for how to identify >> >> >> non-conformance. I'm not sure if we should also define >> >> >> behaviour for >> >> >> ... QC processes of TTML. >> >> >> >> >> >> glenn: Take a look at #125 because there is a proposed set of >> >> >> language there. >> >> >> >> >> >> Commit policy on github >> >> >> >> >> >> glenn: There are two kinds of policies that are commonly used >> >> >> in development - Review Then Commit, when a >> >> >> ... consensus approval is obtained prior to a commit. Then >> >> >> there's Commit Then Review, which allows a >> >> >> ... retroactive veto. In the history of this group all of the >> >> >> work on TTML1 and TTML2 in Mercurial and CVS was done >> >> >> ... on a Commit Then Review (CTR) lazy consensus process. It >> >> >> was based on the editor to decide when to commit >> >> >> ... and then notify the group and make sure that they had log >> >> >> info to give them a chance to review post facto and >> >> >> ... object if necessary. Most teams follow a CTR process >> >> >> because it provides the least barriers to making changes. >> >> >> ... It can result in more bugs potentially. My experience is >> >> >> I've worked with both kinds of processes. With github >> >> >> ... which has a Pull Request mechanism it is possible to >> >> >> snapshot the changes and call them out for review. We >> >> >> ... discussed and agreed the move to github in Sapporo and >> >> >> talked about the review process but I don't recall doing >> >> >> ... so in depth. At the time I remember thinking it should be >> >> >> up to the Editor to decide how to use that facility. I never >> >> >> ... anticipated changing from CTR to RTC. Recently both Nigel >> >> >> and Pierre have in the context of IMSC 1 been following >> >> >> ... a RTC process in their thinking. I would object to that for >> >> >> TTML2. I might be willing to agree to it for other work. >> >> >> ... I find it a strong barrier to process. For example right >> >> >> now I have 4 different issues that Pierre has delegated to me >> >> >> ... to create PRs. All of those fixes are going to change the >> >> >> same lines of code. >> >> >> >> >> >> pal: I think there's a misunderstanding - you can create a PR >> >> >> that covers multiple issues, and we've done that in the >> >> >> ... past. >> >> >> >> >> >> glenn: I agree that's possible. >> >> >> >> >> >> nigel: github also provides a tool for merging work in other >> >> >> branches to resolve the clashes. >> >> >> >> >> >> glenn: I agree there are tools there but it's much more awkward >> >> >> and difficult to do that. My basic point is that >> >> >> ... we don't have a firm consensus on CTR or RTC as a policy. >> >> >> Secondly even if we are using RTC on e.g. IMSC 1 I don't >> >> >> ... think it should be a blanket policy but up to the Editor to >> >> >> decide what policy to use. For trivial changes there's >> >> >> ... no reason to follow the more time consuming process. >> >> >> >> >> >> atai: I think we should check again what we discussed at TPAC. >> >> >> I think we explicitly had some discussion about the >> >> >> ... new policy with github and I thought we agreed but I'm not >> >> >> sure. >> >> >> >> >> >> nigel: We did discuss this in Sapporo and I'm pretty sure we >> >> >> did agree that. For WDs we always followed a RTC process >> >> >> ... and said that to reduce the time between ED updates and WD >> >> >> publications and to use the automated WD publication >> >> >> ... tool we would use PRs. >> >> >> >> >> >> glenn: I do recall saying that I wouldn't be happy to adopt >> >> >> this for TTML2. >> >> >> >> >> >> nigel: I'm happy to review the notes on this and return to it >> >> >> as a topic. In the meantime I would also like plh's views >> >> >> ... and I would myself strongly recommend that we use pull >> >> >> requests for everything including TTML2. >> >> >> >> >> >> glenn: I don't mind using pull requests but I object to a 2 >> >> >> week period before a merge is permitted. >> >> >> ... I think it should be up to the Editor or possibly the Chair >> >> >> to decide to merge if a change is non controversial and >> >> >> ... not to impose a 2 week delay on all PRs. >> >> >> >> >> >> nigel: That's coincident with what we said in Sapporo. There >> >> >> may be a middle ground there that is actually acceptable. >> >> >> >> >> >> glenn and pal: [discussion without conclusion on who should be >> >> >> allowed to merge pull requests] >> >> >> >> >> >> nigel: We're out of time now so I'll adjourn. An hour again, >> >> >> same time next week. Thanks everyone [adjourns meeting] >> >> >> >> >> >> Summary of Action Items >> >> >> >> >> >> Summary of Resolutions >> >> >> >> >> >> [End of minutes] >> >> >> __________________________________________________________ >> >> >> >> >> >> >> >> >> Minutes formatted by David Booth's [17]scribe.perl version >> >> >> 1.144 ([18]CVS log) >> >> >> $Date: 2016/01/28 16:33:11 $ >> >> >> >> >> >> [17] >> >> >> http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm >> >> >> [18] http://dev.w3.org/cvsweb/2002/scribe/ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ---------------------------- >> >> >> >> >> >> http://www.bbc.co.uk >> >> >> This e-mail (and any attachments) is confidential and may contain >> >> >> personal >> >> >> views which are not the views of the BBC unless specifically stated. >> >> >> If you have received it in error, please delete it from your system. >> >> >> Do not use, copy or disclose the information in any way nor act in >> >> >> reliance on it and notify the sender immediately. >> >> >> Please note that the BBC monitors e-mails sent or received. >> >> >> Further communication will signify your consent to this. >> >> >> >> >> >> --------------------- >> >> > >> >> > >> >> >> > > >
Received on Tuesday, 2 February 2016 19:32:16 UTC