I favor option #2. It
keeps the schedule and helps motivate us to review—I know I tend to wait until
the last day. If for some reason many people can’t attend the conference call,
then option #3 become the back up plan. That is, vote next Tuesday if quorum
is met, otherwise, post it as an online ballot.
Thanks
to allwho submitted their spec issues. While I can complete
the revisions to the spec spotted and submitted bar one,
I couldn't get it done by the deadline for the ballot, which has in fact
passed (10am or even 11am EST).
Although
most of the revisions are small,there are a lot of them and then there's the
one pointed out by Rudolfo regarding use of spaces in seg-source between mrk's
which can't be fixed by a simple revision. We'll have to discuss it and
make a decision. In any case I'll send out a revised 1.2 Committee Draft
spec late today that will address the typos, missing bits and details that
were submitted.
We had
twoscenarios outlined as of last week for how the ballot would proceed:
1/publish
finalcommittee draft spec today - have 1 week ballot in time for next
Tuesday's TC meeting.
2/if not
published today, spec would be published before next Tuesday and would have a
role call ballot to approve as Committee
Draft.
I would
like to propose a 3rd option - to postpone the TC teleconference for one week
until Tuesday 23 May, so we work towards publishing a final committee draft
before next Tuesday 16 May, and set up a web ballot commencing 1 week before
the TC teleconference.
Option 1
is no longer viable, - so we're down to 2 options still - #2 and #3.
We are
definitely making good progress cleaning up these little
things.
Hi All,
Some details that need
attention:
1) In section 3.2.5 the description of <mrk> element
mentions the optional attribute equiv-text but the attribute is not included
in the list of optional attributes for that element.
[doug]
The equiv-text attribute is not valid in the <mrk>
element.
3) <seg-source> is a new
element born with old bad habits. It has an optional "ts" attribute that is
deprecated. I don't see a reason for adding deprecated stuff to something new.
[doug]
In principle, I agree that deprecated items should not be added to new
structures. However, I can see the need to duplicate <source> attributes
in <seg-source>. Since <source> supports ‘ts’, it may be helpful
to use it in <seg-source>, but I can go either
way.
: