Re: DFXP 1.0 Last Call issues list

On Sat, Sep 12, 2009 at 11:00 PM, Glenn Adams <gadams@xfsi.com> wrote:

> On Sat, Sep 12, 2009 at 3:31 AM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com> wrote:
>
>> On Sat, Sep 12, 2009 at 4:53 PM, Glenn Adams <gadams@xfsi.com> wrote:
>>
>>> On Sat, Sep 12, 2009 at 1:06 AM, Silvia Pfeiffer <
>>> silviapfeiffer1@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Most of my feedback has been addressed.
>>>>
>>>> Here is a short list of things that I think can still be improved.
>>>>
>>>> However, I do not think any of this should stand in the way of moving
>>>> the specification to CR.
>>>>
>>>>
>>>> 1. ttp:clockMode
>>>>
>>>> There is still no example on what a specification that uses gps, utc and
>>>> local values would look like.
>>>>
>>>> I am particularly worreid about the GPS time coordinates, for which the
>>>> format is not defined anywhere - not even in the given reference for GPS -
>>>> only when I do a bit of a search, I find
>>>> http://tycho.usno.navy.mil/usno_head.html , but that format seems not
>>>> to fit with the rough description given in DFXP as:
>>>>
>>>> "The primary difference between GPS time and UTC time is that GPS time
>>>> is not adjusted for leap seconds, while UTC time is adjusted as follows: UTC
>>>> = TAI (*Temp Atomique International*) + *leap seconds accumulated since
>>>> 1972*. TAI is maintained by the *Bureau International des Poids et
>>>> Mesures* (BIPM) in Sevres, France. The GPS system time is steered to a
>>>> Master Clock (MC) at the US Naval Observatory which is kept within a close
>>>> but unspecified tolerance of TAI."
>>>>
>>>> Maybe it makes sense to remove the gps specification, since it's not
>>>> expected to be substantially different to UTC and since not specifying the
>>>> format properly will mean we won't get interoperable implementations of this
>>>> feature. However, I am not too fussed about leaving it in - it just won't
>>>> get used then.
>>>>
>>>
>>> [GA] GPS based time codes are used in US DTV broadcasts for PSIP, which
>>> is the format of transmitting program event (i.e., EPG) related data; the
>>> normative reference to the US Navy Observatory site is sufficient for anyone
>>> to ascertain the differences between UTC and GPS time codes;
>>>
>>> since most of the world's aviation and naval industry is satisfied with
>>> the definition of GPS time codes, you should be as well, and I leave it to
>>> you (the reader) to research yourself sufficiently the difference between
>>> the two, which is well captured by the description given in DFXP;
>>>
>>
>> I spent half an hour searching for it and I am still unclear what the
>> actual *format* should look like. If it is so clear to you, why not add a
>> simple one-line example?
>>
>
> [GA] ah, you misinterpret the meaning of clockMode: it has nothing to do
> with format; the format of time expressions remain the same for all values
> of clockMode, and that format is prescribed by 10.3; to repeat what is state
> in the first paragraph of clockMode:
>
> The ttp:clockMode attribute is used to specify the interpretation of time
> expressions as real-time time coordinates when operating with time base of
> clock as defined by *6.2.11 ttp:timeBase*<http://dev.w3.org/2008/tt/spec/ttaf1-dfxp.html#parameter-attribute-timeBase>
> .
>
> *Note:*
>
> See *10.3 Time Value Expressions*<http://dev.w3.org/2008/tt/spec/ttaf1-dfxp.html#timing-time-value-expressions> for
> the specification of time expression syntax.
> I point your attention to the phrase "the *interpretation* of time
> expressions" (emphasis added); the purpose of clockMode is to tell the DFXP
> process what time expressions *mean* and not how to parse them; if
> timeBase is 'clock' and clockMode is 'local', then time expressions *mean* the
> local wall clock time; if clockMode is 'utc', then time expressions *mean* the
> UTC time (i.e., refer to the UTC time system); if clockMode is 'gps', then
> time expressions *mean* the GPS time, which is approximately the same as
> UTC time but differs by a fixed number of seconds from UTC time (the number
> of accumulated leap seconds); at present, this number of seconds is 15; see
> ftp://tycho.usno.navy.mil/pub/gps/leapsecnanu.txt;
>
> see also http://leapsecond.com/java/gpsclock.htm (look at top three rows
> in table at top of page) for a visual demonstration of local,  utc, and gps
> times;
>


Thanks, that indeed clarifies it. I was under the impression that DFXP was
using a time specification similar to HTML5 that includes year and month.
Now I understand that there is a generic time specification and the
ttp:clockMode only tells us how that is interpreted. Thanks a lot for this
clarification.



 2. Other requested examples as per
>>>> http://www.w3.org/2009/09/dfxp-lc-issues.html
>>>>  and
>>>> http://lists.w3.org/Archives/Public/public-tt/2009Jun/0020.html
>>>> would be helpful to add, but are not urgent, since they don't
>>>> fundamentally change the spec.
>>>>
>>>
>>> [GA] I agree it may be helpful, but it is strictly informative, so is not
>>> strictly necessary. Furthermore, nobody is volunteering to create these
>>> examples (are you?).
>>>
>>
>> I would if I even knew for most of these things what an example would look
>> like. I am asking for these examples because they would clarify the spec.
>>
>
> you can find such examples in the DFXP test suite; it should be apparent to
> a reader what they look like, as the syntax is spelled out concretely in the
> spec;
>


Then it may indeed be helpful to take the examples out of the test suite and
add them to the document. If there is anything I can help with, I'd be very
happy to.

I assume http://dev.w3.org/2008/tt/spec/ttaf1-dfxp.xml is your editor
document - so I could create a patch for it and send through. Would that be
helpful?



>  3. Section ordering
>>>> http://lists.w3.org/Archives/Public/public-tt/2009Jun/0028.html
>>>> I am not overly fussed about, though I think the concrete suggestions I
>>>> made would be trivial to execute and would improve the readability.
>>>>
>>>>
>>> [GA] I'm afraid you underestimate the editorial work involved to do this
>>> reordering, and it adds nothing to the technical content of the document.
>>>
>>
>> Moving a section is not difficult. I have edited other W3C drafts and I
>> know what's involved.
>>
>
> [GA] it is not merely a matter of moving a section, but of making
> adjustments throughout the document to accommodate the difference in order;
> the present order was carefully chosen as being the most logical sequence
> for elaboration of synactic and semantic definitions; any change in order at
> this stage is unnecessary and has no technical consequence, but does put a
> significant burden on the editor; there are other knock-on effects as well,
> such as the order of table content and test suite tests, etc., that follow
> the specification order, all of which would have to be carefully reviewed
> and changed to keep the correct ordering relationship;
>


As said earlier: I don't think any of theses issues should stop publishing
the CR. The document is good enough as it is and I understand the issues
involved with changing numbering.


Best Regards,
Silvia.