Re: DFXP 1.0 Last Call issues list

inline

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:
>
>> inline below ([GA])
>>
>> 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;


> The Web world is what I am concerned about, not the aviation and naval
> industry and most of the Web world will not have seen a standard GPS
> timecode format.
>
>
>
>> 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;


>
>
>>  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;


>
>
>>  4. Use of external metadata
>>> http://lists.w3.org/Archives/Public/public-tt/2009Jun/0034.html
>>> I may be blind, but I cannot see an example of foreign namespace metadata
>>> from Dublin Core added in 12.1.1 of http://www.w3.org/TR/ttaf1-dfxp/,
>>> see ISSUE-137.
>>
>>
>> [GA] You are looking at the wrong version of DFXP. Look at at the current
>> editor's update at:
>>
>>
>> http://dev.w3.org/2008/tt/spec/ttaf1-dfxp.html#metadata-vocabulary-metadata
>>
>> look specifically at the last example in 12.1.1 "Example Fragment -
>> Foreign Element Metadata".
>>
>>
>
> Excellent - I thought that might be the case. That example clarifies a lot.
> Thanks for the link.
>
>
> Best Regards,
> Silvia.
>