erik: we changed from abnf to
ebnf (?) yves, is your action still valid?

yves: yes

silvia: is there an issue with
the change?

yves: no, i am using abnf for
other things, but i'm sure ebnf shall be similar

silvia: then we only have the
parsing issues dom mentioned, which are minor

yves: the npt definition was not
exactly correct, that was the only thing holding up the
grammar

silvia: yes, as discussed in
email, just a small change

yves: i will look at that before
the f2f

(but i will be away next week)

3.2 Protocol for URI fragment Resolution in
HTTP

Erik: any problem with the
changes proposed by Philip?

silvia: no, they clarify things,
they might have made the document structure more complicated.
philip also proposed some changes to document structure but
they make sense

erik: i agree

jackjansen, i would be against a structure
where normative and non-normative are not separated. I would
like them to be clearly spaced

silvia: we should put an overview
table at the end of the document of what is normative and
informative, rather than spreading it through the document.
most of it is obvious, but it is important to put the info in
one place

jackjansen, the nice thing about a table is
that if it indexes all the normative stuff, you can use it to
find what you actually need

jackjansen, not sure i like the idea that it
should be clear from the wording, because then in non-normative
text you have to refrain from using SHOULD, MUST etc.

jackjansen, it should be clear from the layout
which is which

silvia, comments in-line about what is
normative is not useful

jackjansen, in SMIL spec, we put in text
markers for people who use screen readers etc. (as well as
colors)

jackjansen, in the published document there
are only text markers -- the visual markers were not
included

silvia, make a note now, put these in if we
come to committee draft

jackjansen, the xml format we use has a way to
distinguish paragraphs, so if we use that we can modify the
layout in stylesheet

thierry, distinguish in screen and aural?

jackjansen, just use the xml to make a clear
distinction between normative and informative text

<trackbot> Created ACTION-137
- Check that 5.1.4 is implementable using the protocol [on Jack
Jansen - due 2010-02-10].

3.4 Discovery of 'Track' and 'Named'
fragments:

silvia: nothing to discuss yet,
this is being worked on in ogg

3.4, 3.5 to be discussed later on

5. TEST CASES: (Michael)

erik: i'm in favour of making
next phone conf all about test cases, for a whole hour

silvia, last week we mentioned that the foms
people would be keen to have an indication on which sections
are fairly ready, and my suggestion was that section 5.2.1 can
be implemented

<Yves> the only indication of
stability is publishing LC or CR

conrad: perhaps we don't need to
specify that the mechanism for handling client-side fragments
involves http byte-range requests: just specify that "if the
client can already seek over the network, honor this fragment
syntax"

silvia, last week we decided that rather than
pulling out parts of the document which are stable, we simply
mark within the document how mature each part of the document
is, so implementers can go ahead

silvia, whereas last call etc. is really for
the whole document; we don't want to hold back implementers

Yves, the parts which are unstable may lead to
changes in the parts we think are stable now

silvia, unlikely as that section is really
trivial

jackjansen, that section has very little value
with out parts of chapters 3, 4

jackjansen, i like the sentiment about
allowing implementers to start implementing stuff, but ...

silvia, yes, but we have already been through
section 3 substantially, any changes will be minor

jackjansen, i probably agree, but then even if
we mark sections as "stable" we should specify that it may
change anyway. we don't want to be editing for all eternity
like the whatwg is doing

silvia, we should start having
implementations. we are really close to having the temporal
stuff finalized, even though the headers etc. may still be
under discussion

silvia, if we keep working on the spec without
any implementations, it's not going to move ahead in a
reasonable amount of time

jackjansen, if we mark these things as not
"stable/unstable" but "reaonsably stable, mature" etc. that is
fine with me