DFXP 1.0 Last Call issues list

[Philippe Le Hegaret]

... is at
 http://www.w3.org/2009/09/dfxp-lc-issues.html

I'm trying to close the loop with Silvia on some of her issues. Besides
that, I believe we'll be all set to move to CR. If you believe I'm
missing something, please let me know.

Philippe
       

[Silvia Pfeiffer]

Getting onto it now - hope there is still time.
Will give you feedback asap.
Thanks,
Silvia.

On Sat, Sep 12, 2009 at 12:33 AM, Philippe Le Hegaret <plh@...> wrote:

... is at
 http://www.w3.org/2009/09/dfxp-lc-issues.html

I'm trying to close the loop with Silvia on some of her issues. Besides
that, I believe we'll be all set to move to CR. If you believe I'm
missing something, please let me know.

Philippe

[Silvia Pfeiffer]

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.


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.


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.


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.


Best Regards,
Silvia.

On Sat, Sep 12, 2009 at 12:15 PM, Silvia Pfeiffer <silviapfeiffer1@...> wrote:

Getting onto it now - hope there is still time.
Will give you feedback asap.
Thanks,
Silvia.

On Sat, Sep 12, 2009 at 12:33 AM, Philippe Le Hegaret <plh@...> wrote:

... is at
 http://www.w3.org/2009/09/dfxp-lc-issues.html

I'm trying to close the loop with Silvia on some of her issues. Besides
that, I believe we'll be all set to move to CR. If you believe I'm
missing something, please let me know.

Philippe

[Glenn Adams]

inline below ([GA])

On Sat, Sep 12, 2009 at 1:06 AM, Silvia Pfeiffer <silviapfeiffer1@...> 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; 

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?).

 

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.

 

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".

 

 

Best Regards,
Silvia.

On Sat, Sep 12, 2009 at 12:15 PM, Silvia Pfeiffer <silviapfeiffer1@...> wrote:

Getting onto it now - hope there is still time.
Will give you feedback asap.
Thanks,
Silvia.

On Sat, Sep 12, 2009 at 12:33 AM, Philippe Le Hegaret <plh@...> wrote:

... is at
 http://www.w3.org/2009/09/dfxp-lc-issues.html

I'm trying to close the loop with Silvia on some of her issues. Besides
that, I believe we'll be all set to move to CR. If you believe I'm
missing something, please let me know.

Philippe

[Silvia Pfeiffer]

On Sat, Sep 12, 2009 at 4:53 PM, Glenn Adams <gadams@...> wrote:

inline below ([GA])

On Sat, Sep 12, 2009 at 1:06 AM, Silvia Pfeiffer <silviapfeiffer1@...> 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?

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.

 

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.

 

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.

[Sean Hayes-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Actually I do think there is a genuine issue here, it’s not the definition of GPS or UTC per se (which are well defined); but since we don’t have dates in TT time expressions, a key piece of information, namely the start time at which real time events are offset from, does not seem to be normatively referenced in the specification. One is given in ATSC A/65 as Jan  6 1980, but I think we should perhaps use instead the start of GPS time. I suggest adding the following text around the discussion on UTC and GPS, which I believe is correct and should clarify the issue:

 

---

In the timed text specification clock values are given by the syntax in 10.3; (this is a subset of the SMIL time syntax and does not include date information and therefore requires a base reference time). When GPS or UTC mode is used, then the time base is real world time and time references are converted into seconds on the real time line, and represent a count of the number of seconds since the base point, which is: 00:00:00 UTC January 1st, 1972.

 

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.

 

In Timed Text then, when an even actually occurs in real time is determined by the ttm:clockMode attribute: in GPS mode, leap seconds are not accounted for, but in UTC mode they are. So for example, as of 2009 when UTC = TAI + 34 leap seconds, an event specified as Ns in Timed text using the gps clockMode will occur 34 seconds after one specified using utc mode.

---

 

 

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

 

Office:  [phone], 

Mobile: [phone]

 

From: public-tt-request@... [mailto:public-tt-request@...] On Behalf Of Silvia Pfeiffer
Sent: 12 September 2009 8:32 AM
To: Glenn Adams
Cc: Philippe Le Hegaret; public-tt@...; daniel.weck@...; werner.bailer@...; Gur@...
Subject: Re: DFXP 1.0 Last Call issues list

 

On Sat, Sep 12, 2009 at 4:53 PM, Glenn Adams <gadams@...> wrote:

inline below ([GA])

On Sat, Sep 12, 2009 at 1:06 AM, Silvia Pfeiffer <silviapfeiffer1@...> 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?

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.

 

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.

 

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.

[Glenn Adams]

inline

On Sat, Sep 12, 2009 at 3:31 AM, Silvia Pfeiffer <silviapfeiffer1@...> wrote:

On Sat, Sep 12, 2009 at 4:53 PM, Glenn Adams <gadams@...> wrote:

inline below ([GA])

On Sat, Sep 12, 2009 at 1:06 AM, Silvia Pfeiffer <silviapfeiffer1@...> 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.

Note:

See 10.3 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.

[Sean Hayes-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Slight corrections based on  http://tycho.usno.navy.mil/leapsec.html; while UTC is TAI+34, GPS is also ahead of TAI; so the delta between GPS and UTC is currently 15s.

 

The GPS Epoch is defined by January 6, 1980, so probably we should use that too; like ATSC.

 

Sean

 

 

From: public-tt-request@... [mailto:public-tt-request@...] On Behalf Of Sean Hayes
Sent: 12 September 2009 12:00 PM
To: Silvia Pfeiffer; Glenn Adams
Cc: Philippe Le Hegaret; public-tt@...; daniel.weck@...; werner.bailer@...; Gur@...
Subject: RE: DFXP 1.0 Last Call issues list

 

Actually I do think there is a genuine issue here, it’s not the definition of GPS or UTC per se (which are well defined); but since we don’t have dates in TT time expressions, a key piece of information, namely the start time at which real time events are offset from, does not seem to be normatively referenced in the specification. One is given in ATSC A/65 as Jan  6 1980, but I think we should perhaps use instead the start of GPS time. I suggest adding the following text around the discussion on UTC and GPS, which I believe is correct and should clarify the issue:

 

---

In the timed text specification clock values are given by the syntax in 10.3; (this is a subset of the SMIL time syntax and does not include date information and therefore requires a base reference time). When GPS or UTC mode is used, then the time base is real world time and time references are converted into seconds on the real time line, and represent a count of the number of seconds since the base point, which is: 00:00:00 UTC January 1st, 1972.

 

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.

 

In Timed Text then, when an even actually occurs in real time is determined by the ttm:clockMode attribute: in GPS mode, leap seconds are not accounted for, but in UTC mode they are. So for example, as of 2009 when UTC = TAI + 34 leap seconds, an event specified as Ns in Timed text using the gps clockMode will occur 34 seconds after one specified using utc mode.

---

 

 

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

 

Office:  [phone], 

Mobile: [phone]

 

From: public-tt-request@... [mailto:public-tt-request@...] On Behalf Of Silvia Pfeiffer
Sent: 12 September 2009 8:32 AM
To: Glenn Adams
Cc: Philippe Le Hegaret; public-tt@...; daniel.weck@...; werner.bailer@...; Gur@...
Subject: Re: DFXP 1.0 Last Call issues list

 

On Sat, Sep 12, 2009 at 4:53 PM, Glenn Adams <gadams@...> wrote:

inline below ([GA])

On Sat, Sep 12, 2009 at 1:06 AM, Silvia Pfeiffer <silviapfeiffer1@...> 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?

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.

 

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.

 

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.

[Silvia Pfeiffer]

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

On Sat, Sep 12, 2009 at 3:31 AM, Silvia Pfeiffer <silviapfeiffer1@...> wrote:

On Sat, Sep 12, 2009 at 4:53 PM, Glenn Adams <gadams@...> wrote:

On Sat, Sep 12, 2009 at 1:06 AM, Silvia Pfeiffer <silviapfeiffer1@...> 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.

Note:

See 10.3 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.

[Glenn Adams]

we will discuss your offer to help with examples; we do not use HTML format direct for editing/creating the DFXP document you see, but rather an XML format which goes through a build process using XSLT to create the final HTML version;

glenn

[Silvia Pfeiffer]

The link that I posted was the link to the xml file, which I am assuming is your editing file.

Regards,
Silvia.

On Sun, Sep 13, 2009 at 1:05 PM, Glenn Adams <gadams@...> wrote:

we will discuss your offer to help with examples; we do not use HTML format direct for editing/creating the DFXP document you see, but rather an XML format which goes through a build process using XSLT to create the final HTML version;

glenn