Nabble - w3.org - public-tt

Re: DynamicFlow002

2009-10-29T16:48:46Z

I will change the example and test to adhere to the syntax spec. No need to change the syntax. Also, btw, I expect to make a change to the rollUp test after conferring with Geoff on that feature.

On Fri, Oct 30, 2009 at 2:01 AM, Philippe Le Hegaret <plh@...> wrote:

Hi Glenn,

In test DynamicFlow002 (and the specification as well), you use the
value
in(word,jump) fill(1.0s) out(line,smooth) clear(break,0.3s)

however, the syntax for dynamic flow is
<flowFunction>+ <flowIntervalFunction>*

which means the flow function out() needs to appear before fill:

in(word,jump) out(line,smooth) fill(1.0s) clear(break,0.3s)

Did you mean the syntax for dynamic flow to be

( <flowFunction> <flowIntervalFunction>* )+

instead?

Philippe

DynamicFlow002

2009-10-29T11:01:28Z

Hi Glenn,

In test DynamicFlow002 (and the specification as well), you use the
value
in(word,jump) fill(1.0s) out(line,smooth) clear(break,0.3s)

however, the syntax for dynamic flow is
<flowFunction>+ <flowIntervalFunction>*

which means the flow function out() needs to appear before fill:

in(word,jump) out(line,smooth) fill(1.0s) clear(break,0.3s)

Did you mean the syntax for dynamic flow to be

( <flowFunction> <flowIntervalFunction>* )+

instead?

Philippe

Updated draft and test suite

2009-10-29T07:25:24Z

The editors draft [1] has now a new title and is using the namespaces
and media type.

The test suite has been updated accordingly. It also includes the
changes from Glenn and new tests for dynamic flow. I'm investigating
with Andrew to understand why the Adobe implementation can't run them.

Philippe

[1] http://dev.w3.org/cvsweb/~checkout~/2008/tt/spec/ttaf1-dfxp.html?content-type=text/html;%20charset=utf-8

RE: Reminder: TTWG meeting today

2009-10-23T06:45:06Z

will be on the call but will be five mins late.

g.

________________________________________
From: public-tt-request@... [public-tt-request@...] On Behalf Of Sean Hayes [Sean.Hayes@...]
Sent: Friday, October 23, 2009 5:22 AM
To: public-tt@...
Subject: Reminder: TTWG meeting today

Our CR window has now closed, and I’ve received no additional comments.
I have received only favourable comments regarding the proposed name change.
The test suite is updated.

Therefore as stated last week, I’d like to hold a short meeting today to finalize our steps for moving to PR after TPAC.

We are now in the silly season of time changes, so please check your local time against 14:00Z.

Fridays 14:00-16:00 UTC<http://www.timeanddate.com/worldclock/fixedtime.html?month=10&day=23&year=2009&hour=14&min=00&sec=0&p1=0> (10:00am-11:00am Boston local)
Zakim Bridge +1.617.761.6200<tel:+1.617.761.6200>, conference 3397 ("DFXP")

Sean Hayes

Reminder: TTWG meeting today

2009-10-23T02:22:13Z

Re: Timed text meeting Friday

Our CR window has now closed, and I’ve received no additional comments.

I have received only favourable comments regarding the proposed name change.

The test suite is updated.

Therefore as stated last week, I’d like to hold a short meeting today to finalize our steps for moving to PR after TPAC.

We are now in the silly season of time changes, so please check your local time against 14:00Z.

Fridays 14:00-16:00 UTC (10:00am-11:00am Boston local)
Zakim Bridge +1.617.761.6200, conference 3397 ("DFXP")

Sean Hayes

real-time javascript captions

2009-10-20T08:47:07Z

real-time javascript captions
Of interest to the group: NCAM has been playing with the delivery of real-time captions over the Web using Javascript. We’ve got a test running at http://narita.mit.edu:9000/orbited/captionStreamer/captionStreamer.html; take a look using any Javascript-enabled browser. Being a test, the service is sometimes unavailable; if you don’t see captions, try again later. If you test it, please send me a note off-list and let me know what browser (and device, if mobile) you used and if you had any problems. We’re particularly interested in mobile devices; we’ve tested on the iPhone/iPod touch but would like to know about others.

Thanks.
Geoff/NCAM

Re: Meeting notes for 16/10/09

2009-10-16T15:23:30Z

On Sat, Oct 17, 2009 at 2:01 AM, Sean Hayes <Sean.Hayes@...> wrote:

> 1 – Name change. We have decided to adopt if possible the generic name Timed
> Text Markup Language (TTML), with the profile issue and name DFXP being
> relegated to the body of the document and for use specifically for documents
> conforming to that profile. This entails some practical changes, most
> relevantly to the namespace URI’s which may cause some issues with existing
> implementations; and will change the TR location on the W3C website.
>
> Action – Glenn and Philippe will investigate any practical blockers to this
> change.
>
> Action - Sean will draft and send a formal proposal to list. Deadline for
> objections 23rd.
>
> 2 – We believe the ietf proposal is ready to send.
>
> Action - Philippe and Sean to discuss.
>
> 3 – We will adopt two suffixes: .dfxp for when the file is known to fit the
> constrained profile as given in the spec, and .ttml generically

These should be added to the IETF I-D before submission. Also don't
forget to add an Apple code (I assume DFXP and TTML).

Best Regards,
Silvia.

RE: Formal notice of proposed name change

2009-10-16T11:47:18Z

Re: Formal notice of proposed name change

The old namespace would now refer to a pre-release version, So it depends what you mean by applications and break. Readers of timed text can still accept docs in the old namespace, and should convert to the new ones. Writers of timed text should not produce the old form.

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,

Mobile: +44 7875 091385

From: public-tt-request@... [mailto:public-tt-request@...] On Behalf Of Geoff Freed
Sent: 16 October 2009 7:23 PM
To: public-tt@...
Subject: Re: Formal notice of proposed name change

a question re namespace: for the benefit of applications that already make use of DFXP, is there a way to grandfather the old namespace so these applications won’t break?

g.

On 10/16/09 12:19 PM, "Sean Hayes" <Sean.Hayes@...> wrote:

The Timed Text working group is entertaining a proposal to change the name of the format to:

Timed Text Markup Language

and the title of the specification from:

Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP)

To :

Timed Text Markup Language (TTML) 1.0

The concept and name Distribution Format Exchange Profile (DFXP) will be retained, but relegated to the discussion in the body of the document.

The TR URI would change to http://www.w3.org/TR/ttml

The media type would change to: application/ttml+xml

The namespace URI’s would change to undated URI’s e.g.:

NamePrefixValue
Defaulttt:http://www.w3.org/ns/ttml
Parameterttp:http://www.w3.org/ns/ttml#parameter
Styletts:http://www.w3.org/ns/ttml#styling
Metadatattm:http://www.w3.org/ns/ttml#metadata
Profilenonehttp://www.w3.org/ns/ttml/profile/
Featurenonehttp://www.w3.org/ns/ttml/feature/
Extensionnonehttp://www.w3.org/ns/ttml/extension/

We will use the file suffix convention of .ttml for any generic TTML document, and .dfxp for documents which are known to conform to a defined exchange profile.

The DFXP profile designators will be known by the URI’s:

DFXP Transformation http://www.w3.org/ns/ttml/profile/dfxp-transformation
DFXP Presentation http://www.w3.org/ns/ttml/profile/dfxp-presentation
DFXP Full http://www.w3.org/ns/ttml/profile/dfxp-full

The test suite would be updated to follow these changes in the week following the adoption of this change, implementations would be expected to adapt to these changes in order to be considered as passing the tests as evidence of implementation.

The deadline for objections to the change is the meeting on 23/10/09

Sean Hayes
Chair of TTWG

Re: Formal notice of proposed name change

2009-10-16T11:22:38Z

Re: Formal notice of proposed name change
a question re namespace: for the benefit of applications that already make use of DFXP, is there a way to grandfather the old namespace so these applications won’t break?

g.

On 10/16/09 12:19 PM, "Sean Hayes" <Sean.Hayes@...> wrote:

The Timed Text working group is entertaining a proposal to change the name of the format to:

Timed Text Markup Language

and the title of the specification from:

Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP)

To :

Timed Text Markup Language (TTML) 1.0

The concept and name Distribution Format Exchange Profile (DFXP) will be retained, but relegated to the discussion in the body of the document.

The TR URI would change to http://www.w3.org/TR/ttml

The media type would change to: application/ttml+xml

The namespace URI’s would change to undated URI’s e.g.:

NamePrefixValue
Defaulttt:http://www.w3.org/ns/ttml
Parameterttp:http://www.w3.org/ns/ttml#parameter
Styletts:http://www.w3.org/ns/ttml#styling
Metadatattm:http://www.w3.org/ns/ttml#metadata
Profilenonehttp://www.w3.org/ns/ttml/profile/
Featurenonehttp://www.w3.org/ns/ttml/feature/
Extensionnonehttp://www.w3.org/ns/ttml/extension/

We will use the file suffix convention of .ttml for any generic TTML document, and .dfxp for documents which are known to conform to a defined exchange profile.

The DFXP profile designators will be known by the URI’s:

DFXP Transformation http://www.w3.org/ns/ttml/profile/dfxp-transformation
DFXP Presentation http://www.w3.org/ns/ttml/profile/dfxp-presentation
DFXP Full http://www.w3.org/ns/ttml/profile/dfxp-full

The test suite would be updated to follow these changes in the week following the adoption of this change, implementations would be expected to adapt to these changes in order to be considered as passing the tests as evidence of implementation.

The deadline for objections to the change is the meeting on 23/10/09

Sean Hayes
Chair of TTWG

Formal notice of proposed name change

2009-10-16T09:19:17Z

The Timed Text working group is entertaining a proposal to change the name of the format to:

Timed Text Markup Language

and the title of the specification from:

Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP)

To :

Timed Text Markup Language (TTML) 1.0

The concept and name Distribution Format Exchange Profile (DFXP) will be retained, but relegated to the discussion in the body of the document.

The TR URI would change to http://www.w3.org/TR/ttml

The media type would change to: application/ttml+xml

The namespace URI’s would change to undated URI’s e.g.:

Name	Prefix	Value
Default	tt:	http://www.w3.org/ns/ttml
Parameter	ttp:	http://www.w3.org/ns/ttml#parameter
Style	tts:	http://www.w3.org/ns/ttml#styling
Metadata	ttm:	http://www.w3.org/ns/ttml#metadata
Profile	none	http://www.w3.org/ns/ttml/profile/
Feature	none	http://www.w3.org/ns/ttml/feature/
Extension	none	http://www.w3.org/ns/ttml/extension/

We will use the file suffix convention of .ttml for any generic TTML document, and .dfxp for documents which are known to conform to a defined exchange profile.

The DFXP profile designators will be known by the URI’s:

DFXP Transformation	http://www.w3.org/ns/ttml/profile/dfxp-transformation
DFXP Presentation	http://www.w3.org/ns/ttml/profile/dfxp-presentation
DFXP Full	http://www.w3.org/ns/ttml/profile/dfxp-full

The test suite would be updated to follow these changes in the week following the adoption of this change, implementations would be expected to adapt to these changes in order to be considered as passing the tests as evidence of implementation.

The deadline for objections to the change is the meeting on 23/10/09

Sean Hayes

Chair of TTWG

Meeting notes for 16/10/09

2009-10-16T08:01:46Z

1 – Name change. We have decided to adopt if possible the generic name Timed Text Markup Language (TTML), with the profile issue and name DFXP being relegated to the body of the document and for use specifically for documents conforming to that profile. This entails some practical changes, most relevantly to the namespace URI’s which may cause some issues with existing implementations; and will change the TR location on the W3C website.

Action – Glenn and Philippe will investigate any practical blockers to this change.

Action - Sean will draft and send a formal proposal to list. Deadline for objections 23^rd.

2 – We believe the ietf proposal is ready to send.

Action - Philippe and Sean to discuss.

3 – We will adopt two suffixes: .dfxp for when the file is known to fit the constrained profile as given in the spec, and .ttml generically

4 - Glenn. Reports rollup implementation is on track for end of month, Tests for rollup will be checked in next week.

Since we will not now be able to go to PR before the 23^rd of Oct, our revised schedule is to go to PR after TPAC (week of the 9^th), with a view to publish as Rec. on Dec 15^th.

5 – Exclusion issue is now moot due to schedule change.

A meeting is scheduled for next week 23/10/09 to finalize any name change decision.

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,

Mobile: +44 7875 091385

From: public-tt-request@... [mailto:public-tt-request@...] On Behalf Of Sean Hayes
Sent: 15 October 2009 2:45 PM
To: public-tt@...
Subject: Timed text meeting Friday

We will hold a meeting this week to discuss a few items as we approach the end of our CR phase.

Agenda

1. Short title. Dow we need to invent or modify the “brand” for Timed Text.

2. Progress on ietf type registration

3. File extension. (candidates include .dfxp, .ttxt)

4. Implementation and test suite progress.

5. Call for exclusion status

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,

Mobile: +44 7875 091385

RE: Timed text meeting Friday

2009-10-16T04:00:33Z

Re: Timed text meeting Friday

I agree that DFXP is the best short form handle for this specification, and I’d like to promote that by adopting a .dfxp file name convention, I’ve been using that for a while anyway (it makes life a lot easier to find caption files than .xml). I think we should probably grab DFXP as a mac code, and also an MPEG 4 media container type, and anywhere else we think relevant while we are at it.

I’m not that fussed about renaming the specification, although I would have a preference for: Timed Text Markup Language (TTML) 1.0 – Distribution Format Exchange Profile (DFXP), which would get authoring out of the title, and emphasise its XML heritage and role as a precursor to other formats. If this requires anything much more than a search and replace in the spec though, I’m willing to forgo it. If we did adopt it, then .ttml is a fine file extention too, and as far as I know unused.

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,

Mobile: +44 7875 091385

From: Geoff Freed [mailto:geoff_freed@...]
Sent: 15 October 2009 7:20 PM
To: Sean Hayes; public-tt@...
Subject: Re: Timed text meeting Friday

i won’t be able to make tomorrow’s call, but i’ve commented on two of the items below.

g.

On 10/15/09 9:44 AM, "Sean Hayes" <Sean.Hayes@...> wrote:

We will hold a meeting this week to discuss a few items as we approach the end of our CR phase.
Agenda

1. Short title. Dow we need to invent or modify the “brand” for Timed Text.
GF: i agree with glenn that we shouldn’t rename the spec (http://lists.w3.org/Archives/Public/public-tt/2009Sep/0021.html). i also agree that we shouldn’t spend much time on this. however, if we’re fishing for an official shorthand name to give to the public, i vote for DFXP. it’s unambiguous (unlike “timed text,” which could be any timed-text format, such as QTText, RealText, SubRip or SAMI) and brief (unlike ttaf1-dfxp).

3. File extension. (candidates include .dfxp, .ttxt)
GF: i think .ttxt is similar to .txt and therefore might cause confusion. i’m not unhappy with .xml, but i think .dfxp is the best possible extension because it immediately conveys what the file is.

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385

Re: Timed text meeting Friday

2009-10-15T11:19:54Z

Re: Timed text meeting Friday
i won’t be able to make tomorrow’s call, but i’ve commented on two of the items below.

g.

On 10/15/09 9:44 AM, "Sean Hayes" <Sean.Hayes@...> wrote:

We will hold a meeting this week to discuss a few items as we approach the end of our CR phase.
Agenda

1. Short title. Dow we need to invent or modify the “brand” for Timed Text.
GF: i agree with glenn that we shouldn’t rename the spec (http://lists.w3.org/Archives/Public/public-tt/2009Sep/0021.html). i also agree that we shouldn’t spend much time on this. however, if we’re fishing for an official shorthand name to give to the public, i vote for DFXP. it’s unambiguous (unlike “timed text,” which could be any timed-text format, such as QTText, RealText, SubRip or SAMI) and brief (unlike ttaf1-dfxp).

3. File extension. (candidates include .dfxp, .ttxt)
GF: i think .ttxt is similar to .txt and therefore might cause confusion. i’m not unhappy with .xml, but i think .dfxp is the best possible extension because it immediately conveys what the file is.

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,
Mobile: +44 7875 091385

Timed text meeting Friday

2009-10-15T06:44:49Z

We will hold a meeting this week to discuss a few items as we approach the end of our CR phase.

Agenda

1. Short title. Dow we need to invent or modify the “brand” for Timed Text.

2. Progress on ietf type registration

3. File extension. (candidates include .dfxp, .ttxt)

4. Implementation and test suite progress.

5. Call for exclusion status

Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

Office: +44 118 909 5867,

Mobile: +44 7875 091385

Re: Registration of media type application/ttaf+xml

2009-10-06T12:26:36Z

On Mon, Oct 5, 2009 at 6:35 PM, Glenn Adams <gadams@...> wrote:
> DFXP's mime type is formally based on RFC 3023 [XML Media Types], which
> specifies ".xml" as file name extension (see Section 3.2 of that RFC, under
> Additional Information);

That's only for the application/xml media type (and text/xml, but
let's not go there), not for all XML types. As this is a registration
for a new media type, it should use a new file extension.

Mark.

Re: Registration of media type application/ttaf+xml

2009-10-05T19:25:00Z

Hmm, I see. I guess that works, too.
Thanks for clarifying.
Regards,
Silvia.

On Tue, Oct 6, 2009 at 12:35 PM, Glenn Adams <gadams@...> wrote:

> DFXP's mime type is formally based on RFC 3023 [XML Media Types], which
> specifies ".xml" as file name extension (see Section 3.2 of that RFC, under
> Additional Information);
> On Tue, Oct 6, 2009 at 9:03 AM, Silvia Pfeiffer <silviapfeiffer1@...>
> wrote:
>>
>> I am concerned about the lack of a additional information typically
>> used in mime type registration RFCS, see e.g.
>> http://www.rfc-editor.org/rfc/rfc3839.txt (for 3gpp) or
>> http://tools.ietf.org/html/rfc4337 (mpeg4) or
>> http://www.ietf.org/rfc/rfc5334.txt (ogg):
>>
>> Magic number(s): (probably not relevant)
>> File extension(s):
>> Macintosh File Type Code(s):
>>
>> I think it is important that we specify a common file extension and a
>> mac file type code so as not to create confusion in the market with
>> some people creating .dfxp , some creating .xml and some creating
>> whatever they think is appropriate. This will make it very difficult
>> for example for Web servers to serve the correct mime types, since
>> they tend to do so based on file extensions.
>>
>> My suggestion is:
>>
>> File extension: .dfxp (I think four letters is reasonable nowadays,
>> even for windows?)
>>
>> Mac file type code: DFXP
>>
>>
>> Best Regards,
>> Silvia.
>>
>>
>> On Thu, Oct 1, 2009 at 6:46 AM, Philippe Le Hegaret <plh@...> wrote:
>> > The following media type registration will be submitted to
>> > the IESG for review, approval, and registration with IANA (as per [1]).
>> >
>> > At this point, we would appreciate comments on this registration
>> > information. If you see any problems, please let us know.
>> >
>> >
>> > Regards,
>> >
>> > Philippe
>> >
>> > [1] http://www.w3.org/2002/06/registering-mediatype
>> >
>> > [[
>> >
>> > This appendix registers a new MIME media type, "application/ttaf+xml"
>> > in conformance with [1144]BCP 13 and [1145]W3CRegMedia. The information
>> > in this appendix is being submitted to the Internet Engineering
>> > Steering Group (IESG) for review, approval, and registration with the
>> > Internet Assigned Numbers Authority (IANA).
>> >
>> > [1144] http://www.ietf.org/rfc/rfc4288.txt
>> > [1145] http://www.w3.org/2002/06/registering-mediatype.html
>> >
>> > MIME media type name:
>> > application
>> >
>> > MIME subtype name:
>> > ttaf+xml
>> >
>> > Required parameters:
>> > None.
>> >
>> > Optional parameters:
>> > The encoding of a TT AF document must be determined by the
>> > XML encoding declaration. This has identical semantics to the
>> > application/xml media type in the case where the charset
>> > parameter is omitted, as specified in [1146][XML Media],
>> > Sections 8.9, 8.10 and 8.11.
>> >
>> > The document profile of a TT AF document may be specified
>> > using an optional profile parameter, which, if specified, the
>> > value of which must adhere to the syntax and semantics of
>> > ttp:profile parameter defined by Section [1147]6.2.8
>> > ttp:profile of the published specification.
>> >
>> > Encoding considerations:
>> > Same for application/xml. See [1148][XML Media], Section 3.2.
>> >
>> > Restrictions on usage:
>> > None.
>> >
>> > Security considerations:
>> > As with other XML types and as noted in [1149][XML Media]
>> > Section 10, repeated expansion of maliciously constructed XML
>> > entities can be used to consume large amounts of memory,
>> > which may cause XML processors in constrained environments to
>> > fail.
>> >
>> > In addition, because of the extensibility features for TT AF
>> > and of XML in general, it is possible that
>> > "application/ttaf+xml" may describe content that has security
>> > implications beyond those described here. However, if the
>> > processor follows only the normative semantics of the
>> > published specification, this content will be outside TT AF
>> > namespaces and may be ignored. Only in the case where the
>> > processor recognizes and processes the additional content, or
>> > where further processing of that content is dispatched to
>> > other processors, would security issues potentially arise.
>> > And in that case, they would fall outside the domain of this
>> > registration document.
>> >
>> > Interoperability considerations:
>> > The published specification describes processing semantics
>> > that dictate behavior that must be followed when dealing
>> > with, among other things, unrecognized elements and
>> > attributes, both in TT AF namespaces and in other namespaces.
>> >
>> > Because TT AF is extensible, conformant
>> > "application/ttaf+xml" processors must expect that content
>> > received is well-formed XML, but it cannot be guaranteed that
>> > the content is valid to a particular DTD or Schema or that
>> > the processor will recognize all of the elements and
>> > attributes in the document.
>> >
>> > Published specification:
>> > This media type registration is extracted from Appendix
>> > [1150]D Media Type Registration of the [1151]Timed Text (TT)
>> > Authoring Format 1.0 - Distribution Format Exchange Profile
>> > (DFXP) specification.
>> >
>> > [1151] http://www.w3.org/TR/ttaf1-dfxp/
>> >
>> > Additional information:
>> > None.
>> >
>> > Person & email address to contact for further information:
>> > Glenn Adams (public-tt@...)
>> >
>> > Intended usage:
>> > COMMON
>> >
>> > Author/Change controller:
>> > The published specification is a work product of the World
>> > Wide Web Consortium's Timed Text (TT) Working Group. The W3C
>> > has change control over this specification.
>> >
>> > ]]
>> > http://www.w3.org/TR/ttaf1-dfxp/#media-type-registration
>> >
>> >
>> >
>> >
>> >
>
>

Re: Registration of media type application/ttaf+xml

2009-10-05T18:35:24Z

DFXP's mime type is formally based on RFC 3023 [XML Media Types], which specifies ".xml" as file name extension (see Section 3.2 of that RFC, under Additional Information);

On Tue, Oct 6, 2009 at 9:03 AM, Silvia Pfeiffer <silviapfeiffer1@...> wrote:

I am concerned about the lack of a additional information typically
used in mime type registration RFCS, see e.g.
http://www.rfc-editor.org/rfc/rfc3839.txt (for 3gpp) or
http://tools.ietf.org/html/rfc4337 (mpeg4) or
http://www.ietf.org/rfc/rfc5334.txt (ogg):

Magic number(s): (probably not relevant)
File extension(s):
Macintosh File Type Code(s):

I think it is important that we specify a common file extension and a
mac file type code so as not to create confusion in the market with
some people creating .dfxp , some creating .xml and some creating
whatever they think is appropriate. This will make it very difficult
for example for Web servers to serve the correct mime types, since
they tend to do so based on file extensions.

My suggestion is:

File extension: .dfxp (I think four letters is reasonable nowadays,
even for windows?)

Mac file type code: DFXP

Best Regards,
Silvia.

On Thu, Oct 1, 2009 at 6:46 AM, Philippe Le Hegaret <plh@...> wrote:
> The following media type registration will be submitted to
> the IESG for review, approval, and registration with IANA (as per [1]).
>
> At this point, we would appreciate comments on this registration
> information. If you see any problems, please let us know.
>
>
> Regards,
>
> Philippe
>
> [1] http://www.w3.org/2002/06/registering-mediatype
>
> [[
>
> This appendix registers a new MIME media type, "application/ttaf+xml"
> in conformance with [1144]BCP 13 and [1145]W3CRegMedia. The information
> in this appendix is being submitted to the Internet Engineering
> Steering Group (IESG) for review, approval, and registration with the
> Internet Assigned Numbers Authority (IANA).
>
> [1144] http://www.ietf.org/rfc/rfc4288.txt
> [1145] http://www.w3.org/2002/06/registering-mediatype.html
>
> MIME media type name:
> application
>
> MIME subtype name:
> ttaf+xml
>
> Required parameters:
> None.
>
> Optional parameters:
> The encoding of a TT AF document must be determined by the
> XML encoding declaration. This has identical semantics to the
> application/xml media type in the case where the charset
> parameter is omitted, as specified in [1146][XML Media],
> Sections 8.9, 8.10 and 8.11.
>
> The document profile of a TT AF document may be specified
> using an optional profile parameter, which, if specified, the
> value of which must adhere to the syntax and semantics of
> ttp:profile parameter defined by Section [1147]6.2.8
> ttp:profile of the published specification.
>
> Encoding considerations:
> Same for application/xml. See [1148][XML Media], Section 3.2.
>
> Restrictions on usage:
> None.
>
> Security considerations:
> As with other XML types and as noted in [1149][XML Media]
> Section 10, repeated expansion of maliciously constructed XML
> entities can be used to consume large amounts of memory,
> which may cause XML processors in constrained environments to
> fail.
>
> In addition, because of the extensibility features for TT AF
> and of XML in general, it is possible that
> "application/ttaf+xml" may describe content that has security
> implications beyond those described here. However, if the
> processor follows only the normative semantics of the
> published specification, this content will be outside TT AF
> namespaces and may be ignored. Only in the case where the
> processor recognizes and processes the additional content, or
> where further processing of that content is dispatched to
> other processors, would security issues potentially arise.
> And in that case, they would fall outside the domain of this
> registration document.
>
> Interoperability considerations:
> The published specification describes processing semantics
> that dictate behavior that must be followed when dealing
> with, among other things, unrecognized elements and
> attributes, both in TT AF namespaces and in other namespaces.
>
> Because TT AF is extensible, conformant
> "application/ttaf+xml" processors must expect that content
> received is well-formed XML, but it cannot be guaranteed that
> the content is valid to a particular DTD or Schema or that
> the processor will recognize all of the elements and
> attributes in the document.
>
> Published specification:
> This media type registration is extracted from Appendix
> [1150]D Media Type Registration of the [1151]Timed Text (TT)
> Authoring Format 1.0 - Distribution Format Exchange Profile
> (DFXP) specification.
>
> [1151] http://www.w3.org/TR/ttaf1-dfxp/
>
> Additional information:
> None.
>
> Person & email address to contact for further information:
> Glenn Adams (public-tt@...)
>
> Intended usage:
> COMMON
>
> Author/Change controller:
> The published specification is a work product of the World
> Wide Web Consortium's Timed Text (TT) Working Group. The W3C
> has change control over this specification.
>
> ]]
> http://www.w3.org/TR/ttaf1-dfxp/#media-type-registration
>
>
>
>
>

Re: Registration of media type application/ttaf+xml

2009-10-05T18:03:20Z

I am concerned about the lack of a additional information typically
used in mime type registration RFCS, see e.g.
http://www.rfc-editor.org/rfc/rfc3839.txt (for 3gpp) or
http://tools.ietf.org/html/rfc4337 (mpeg4) or
http://www.ietf.org/rfc/rfc5334.txt (ogg):

Magic number(s): (probably not relevant)
File extension(s):
Macintosh File Type Code(s):

I think it is important that we specify a common file extension and a
mac file type code so as not to create confusion in the market with
some people creating .dfxp , some creating .xml and some creating
whatever they think is appropriate. This will make it very difficult
for example for Web servers to serve the correct mime types, since
they tend to do so based on file extensions.

My suggestion is:

File extension: .dfxp (I think four letters is reasonable nowadays,
even for windows?)

Mac file type code: DFXP

Best Regards,
Silvia.

On Thu, Oct 1, 2009 at 6:46 AM, Philippe Le Hegaret <plh@...> wrote:

> The following media type registration will be submitted to
> the IESG for review, approval, and registration with IANA (as per [1]).
>
> At this point, we would appreciate comments on this registration
> information. If you see any problems, please let us know.
>
>
> Regards,
>
> Philippe
>
> [1] http://www.w3.org/2002/06/registering-mediatype
>
> [[
>
> This appendix registers a new MIME media type, "application/ttaf+xml"
> in conformance with [1144]BCP 13 and [1145]W3CRegMedia. The information
> in this appendix is being submitted to the Internet Engineering
> Steering Group (IESG) for review, approval, and registration with the
> Internet Assigned Numbers Authority (IANA).
>
> [1144] http://www.ietf.org/rfc/rfc4288.txt
> [1145] http://www.w3.org/2002/06/registering-mediatype.html
>
> MIME media type name:
> application
>
> MIME subtype name:
> ttaf+xml
>
> Required parameters:
> None.
>
> Optional parameters:
> The encoding of a TT AF document must be determined by the
> XML encoding declaration. This has identical semantics to the
> application/xml media type in the case where the charset
> parameter is omitted, as specified in [1146][XML Media],
> Sections 8.9, 8.10 and 8.11.
>
> The document profile of a TT AF document may be specified
> using an optional profile parameter, which, if specified, the
> value of which must adhere to the syntax and semantics of
> ttp:profile parameter defined by Section [1147]6.2.8
> ttp:profile of the published specification.
>
> Encoding considerations:
> Same for application/xml. See [1148][XML Media], Section 3.2.
>
> Restrictions on usage:
> None.
>
> Security considerations:
> As with other XML types and as noted in [1149][XML Media]
> Section 10, repeated expansion of maliciously constructed XML
> entities can be used to consume large amounts of memory,
> which may cause XML processors in constrained environments to
> fail.
>
> In addition, because of the extensibility features for TT AF
> and of XML in general, it is possible that
> "application/ttaf+xml" may describe content that has security
> implications beyond those described here. However, if the
> processor follows only the normative semantics of the
> published specification, this content will be outside TT AF
> namespaces and may be ignored. Only in the case where the
> processor recognizes and processes the additional content, or
> where further processing of that content is dispatched to
> other processors, would security issues potentially arise.
> And in that case, they would fall outside the domain of this
> registration document.
>
> Interoperability considerations:
> The published specification describes processing semantics
> that dictate behavior that must be followed when dealing
> with, among other things, unrecognized elements and
> attributes, both in TT AF namespaces and in other namespaces.
>
> Because TT AF is extensible, conformant
> "application/ttaf+xml" processors must expect that content
> received is well-formed XML, but it cannot be guaranteed that
> the content is valid to a particular DTD or Schema or that
> the processor will recognize all of the elements and
> attributes in the document.
>
> Published specification:
> This media type registration is extracted from Appendix
> [1150]D Media Type Registration of the [1151]Timed Text (TT)
> Authoring Format 1.0 - Distribution Format Exchange Profile
> (DFXP) specification.
>
> [1151] http://www.w3.org/TR/ttaf1-dfxp/
>
> Additional information:
> None.
>
> Person & email address to contact for further information:
> Glenn Adams (public-tt@...)
>
> Intended usage:
> COMMON
>
> Author/Change controller:
> The published specification is a work product of the World
> Wide Web Consortium's Timed Text (TT) Working Group. The W3C
> has change control over this specification.
>
> ]]
> http://www.w3.org/TR/ttaf1-dfxp/#media-type-registration
>
>
>
>
>

Re: Registration of media type application/ttaf+xml

2009-09-30T18:20:21Z

On Thu, 2009-10-01 at 00:44 +0200, Bjoern Hoehrmann wrote:

> * Philippe Le Hegaret wrote:
> >The following media type registration will be submitted to
> >the IESG for review, approval, and registration with IANA (as per [1]).
> >
> >At this point, we would appreciate comments on this registration
> >information. If you see any problems, please let us know.
>
> The security and interoperability sections must point out that the re-
> gistration fails to comply with the RFC 3023 SHOULD-level requirement
> for types using the "+xml" convention to have an optional charset para-
> meter and its omission permits construction of entities that carry the
> parameter that will be processed differently by different components of
> a system with possibly harmful or otherwise surprising results.
>
> >This appendix registers a new MIME media type, "application/ttaf+xml"
> >in conformance with [1144]BCP 13 and [1145]W3CRegMedia.
>
> > [1144] http://www.ietf.org/rfc/rfc4288.txt
> > [1145] http://www.w3.org/2002/06/registering-mediatype.html
>
> This appears to be incorrect; the W3C procedure requires ietf-types
> review to occur as part of a Last Call announcement. However, this
> appears to be the first mention of this type on ietf-types and the
> document is already past the Last Call stage.

That's correct, however the review didn't occur at Last Call so we're
doing it now. Since the document isn't in REC or PR yet, we'll be able
to fix the template.

Thank you for your comments Bjoern, we'll do the necessary changes,

Philippe

Re: Registration of media type application/ttaf+xml

2009-09-30T15:44:54Z

* Philippe Le Hegaret wrote:
>The following media type registration will be submitted to
>the IESG for review, approval, and registration with IANA (as per [1]).
>
>At this point, we would appreciate comments on this registration
>information. If you see any problems, please let us know.

The security and interoperability sections must point out that the re-
gistration fails to comply with the RFC 3023 SHOULD-level requirement
for types using the "+xml" convention to have an optional charset para-
meter and its omission permits construction of entities that carry the
parameter that will be processed differently by different components of
a system with possibly harmful or otherwise surprising results.

>This appendix registers a new MIME media type, "application/ttaf+xml"
>in conformance with [1144]BCP 13 and [1145]W3CRegMedia.

> [1144] http://www.ietf.org/rfc/rfc4288.txt
> [1145] http://www.w3.org/2002/06/registering-mediatype.html

This appears to be incorrect; the W3C procedure requires ietf-types
review to occur as part of a Last Call announcement. However, this
appears to be the first mention of this type on ietf-types and the
document is already past the Last Call stage.

> Person & email address to contact for further information:
> Glenn Adams (public-tt@...)

This reads as if public-tt@... is Glenn Adams' email address which
it is not.
--
Björn Höhrmann · mailto:bjoern@... · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Registration of media type application/ttaf+xml

2009-09-30T12:46:15Z

The following media type registration will be submitted to
the IESG for review, approval, and registration with IANA (as per [1]).

At this point, we would appreciate comments on this registration
information. If you see any problems, please let us know.

Regards,

Philippe

[1] http://www.w3.org/2002/06/registering-mediatype

[[

This appendix registers a new MIME media type, "application/ttaf+xml"
in conformance with [1144]BCP 13 and [1145]W3CRegMedia. The information
in this appendix is being submitted to the Internet Engineering
Steering Group (IESG) for review, approval, and registration with the
Internet Assigned Numbers Authority (IANA).

[1144] http://www.ietf.org/rfc/rfc4288.txt
[1145] http://www.w3.org/2002/06/registering-mediatype.html

MIME media type name:
application

MIME subtype name:
ttaf+xml

Required parameters:
None.

Optional parameters:
The encoding of a TT AF document must be determined by the
XML encoding declaration. This has identical semantics to the
application/xml media type in the case where the charset
parameter is omitted, as specified in [1146][XML Media],
Sections 8.9, 8.10 and 8.11.

The document profile of a TT AF document may be specified
using an optional profile parameter, which, if specified, the
value of which must adhere to the syntax and semantics of
ttp:profile parameter defined by Section [1147]6.2.8
ttp:profile of the published specification.

Encoding considerations:
Same for application/xml. See [1148][XML Media], Section 3.2.

Restrictions on usage:
None.

Security considerations:
As with other XML types and as noted in [1149][XML Media]
Section 10, repeated expansion of maliciously constructed XML
entities can be used to consume large amounts of memory,
which may cause XML processors in constrained environments to
fail.

In addition, because of the extensibility features for TT AF
and of XML in general, it is possible that
"application/ttaf+xml" may describe content that has security
implications beyond those described here. However, if the
processor follows only the normative semantics of the
published specification, this content will be outside TT AF
namespaces and may be ignored. Only in the case where the
processor recognizes and processes the additional content, or
where further processing of that content is dispatched to
other processors, would security issues potentially arise.
And in that case, they would fall outside the domain of this
registration document.

Interoperability considerations:
The published specification describes processing semantics
that dictate behavior that must be followed when dealing
with, among other things, unrecognized elements and
attributes, both in TT AF namespaces and in other namespaces.

Because TT AF is extensible, conformant
"application/ttaf+xml" processors must expect that content
received is well-formed XML, but it cannot be guaranteed that
the content is valid to a particular DTD or Schema or that
the processor will recognize all of the elements and
attributes in the document.

Published specification:
This media type registration is extracted from Appendix
[1150]D Media Type Registration of the [1151]Timed Text (TT)
Authoring Format 1.0 - Distribution Format Exchange Profile
(DFXP) specification.

[1151] http://www.w3.org/TR/ttaf1-dfxp/

Additional information:
None.

Person & email address to contact for further information:
Glenn Adams (public-tt@...)

Intended usage:
COMMON

Author/Change controller:
The published specification is a work product of the World
Wide Web Consortium's Timed Text (TT) Working Group. The W3C
has change control over this specification.

]]
http://www.w3.org/TR/ttaf1-dfxp/#media-type-registration

Re: please rename Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP)

2009-09-30T07:08:10Z

the reason that it was differentiated as TTAF1-DFXP is because we also had been developing a larger subset, called TTAF1-AFXP, namely "authoring format interchange profile";

at a particular point, the group decided to focus on a subset of a larger set of requirements, and called it DFXP, with the primary purpose of being an interchange system among distribution systems (and, incidentally, able to be directly used for distribution) as opposed to an interchange system among authoring systems (the larger goal of AFXP);

so there was good cause when we created this profile to distinguish it as such;

it is certainly possible that the TTWG may in the future take up the larger profile; however, i can't say how probably this might be or its possible timing;

On Wed, Sep 30, 2009 at 6:20 PM, Daniel Weck <daniel.weck@...> wrote:

Hi all,

The full "technical" name is fine as long as a short "friendly" name is somehow promoted for use by the community at large. As it happens, the Working Group name is "Timed Text", with the subtitle: "Delivering Captioning and Video Description for the Web". Well, guess what: I (and most people I know) tend to use "W3C Timed-Text" or "Timed Text", and we only refer to "DFXP" amongst *really* geeky people (i.e. specification writers or implementors). Will there ever be another deliverable from the "Timed Text" Working Group, other than the affectively-nicknamed "Timed Text" specification (normatively-named "TTAF1-DFXP") ? My guess is no, and the terms "W3C Timed Text" will prevail because in most cases there will be no need to differentiate any further.

Admittedly, the compressed term "TTAF1-DFXP" for "Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP)" doesn't exactly stir my imagination, but then, it's a formal title for an authoritative specification...not a brand name.

The main confusion, I think, stems from the fact that "TTAF1-DFXP" (in its expanded form) mixes "Authoring", "Distribution" and "Exchange" within the same title, in a way that immediately challenges my mental expectations. These terms denote concepts that normally address very different requirements, so my initial impression is that the specification document will simply describe the DFXP profile, and that the actual AF is specified elsewhere (the title is leading me to assume that there are other Profiles defined elsewhere as well). In order to figure-out what this specification means in the *real world*, I need to read the Abstract, the Definitions, and finally the Profiles section which reveals several "sub-profiles" for DFXP (Transformation, Presentation and Full).

I am not suggesting that changes are required for the document in its current state. I am merely stating the fact that the confusing title adds another layer of perceived complexity to a specification that is, it is fair to say, a pretty scary beast for implementors. In any case, well done to the working group members for pulling this one out, we all appreciate your dedication and hard work.

Kind regards, Daniel

On 30 Sep 2009, at 09:56, Dan Brickley wrote:

Hi Glen, and thanks also Silvia for the quick reply,

On Wed, Sep 30, 2009 at 2:03 AM, Glenn Adams <gadams@...> wrote:

Dan,
The intent of the 2nd Candidate Recommendation phase is to obtain
implementation feedback. While what you say below is of potential editorial
import, it does not represent useful implementation feedback.

This is true. I should also congratulate you on reaching this
milestone, I know it has been a lot of work. So my apologies for
jumping straight in with complaints in my previous message. The reason
I
feel my comment was particularly relevant to CR was a bit meta. I
doubt your technology will get the
widespread implementor review and the community excitement that it
deserves, not because of
any engineering or technical failings, but just because of the name.

As it is, the name of the specification is now a number of years old, and no such comment
as you submit now has been previously received.

I have to admit I thought of raising this a few times in previous
years, but it always seemed a bit, well, cheeky.

In the last 24 hours, I have received 3 comments from members of the
TTAF1-DFXP community which I think make my point for me. You all agree
that it will be known by a short name. But you disagree on what that
name will be:

Here (below) you mention the formal W3C short name "ttaf1-dfxp", but
no other abbreviated or convenience name. Meanwhile Silvia wrote "I
think that in common language, the format will be known as DFXP".
Yesterday, responding via Identi.ca (http://identi.ca/notice/10978839)
Philippe Le Hégaret wrote "@danbri I'm happy to convey concrete
proposals for new names to the WG. Having said that, folks know the
technology as Timed Text already."

So, what do we tell the bloggers - ttaf1-dfxp, DFXP or Timed Text?

Characteristics of a good informal name for the technology might be:

* short
* memorable
* unambiguous
* carries relevant meaning to newcomers

For communication outside the world of W3C, the immediate candidates
seem to be "DFXP" and "Timed Text". The former is short and has no
variants, whereas "Timed Text" is much less cryptic, but has some
variants; we could expect to see the whitespace collapsed for use in
tags, or the case dropped. Still "timedtext" remains meaningful.

Here's a quick survey of how these names are currently used in delicious tags:

http://delicious.com/search?p=dfxp&chk=&fr=del_icio_us&lc=0&atags=&rtags=&context=userposts|danbri|&context=all||

dfxp - 27 results

http://delicious.com/search?p=timedtext&chk=&context=userposts|danbri&fr=del_icio_us&lc=

timedtext - 31 results

ttaf1-dfxp - no results

This suggests that none of these options are well established
(contrast 'mathml' or 'html5', 'html' which are obvious tags).

While I might agree that the title is a bit lengthy, it is accurate, and it reflects the end results of a
long process which it represents well.

Sometimes it's best to move process history out of titles, before they
get to Recommendation. I say this as the lead editor of another REC,
http://www.w3.org/TR/rdf-schema/

"RDF Vocabulary Description Language 1.0: RDF Schema"

Now I could give you the whole story for why it has this unwieldy
name. But the key point is that the technology is universally known as
RDF Schema, and abbreviated 9 times out of 10 as "RDFS" (but
occasionally we see "RDF/S"). In short, we downplayed the use of the
word "Schema" due to the horrible tensions between RDF and XML people
at the time; around 1999-2000 RDFS was seen as a potential rival or
threat to XML Schema.

So why didn't we call it a basic/simple ontology language? Which is
how W3C has subsequently referred to the kind of technology that
defines the meaning of terms in RDF. Simply because the final RDFS
work was under the RDFCore WG, and an Ontology WG was beginning the
first OWL work at the same time, and that group quite reasonably
didn't want another group to go publishing a first "ontology"
recommendation in parallel.

So the awkward name was a product of W3C's process. It was, as you
say, accurate and reflects well the end results of a long process. In
retrospect, I wish we had just called it "RDF Schema (RDFS) 1.0".

I might agree with you that the name is not one that has much marketing zing, but then again, neither do most of the other names of specifications published by the W3C.

True, but many at least have a short and simple name. "CSS", "MathML"
do the job nicely, "SPARQL", "OWL" even have a kind of obscure charm
or character.

To re-state my concerns, they are that the long name of technology is
too long, doesn't describe the technology to a non-insider audience,
and doesn't come with a simple, short and memorable abbreviated name
suited for tags, conversation, mention in blogs etc.

"This is the Candidate Recommendation of the Timed Text (TT) Authoring
Format 1.0 – Distribution Format Exchange Profile (DFXP)"

I can barely say that in one breath.

Finally, I would note that both the name of the specification, its "short
name" (ttaf1-dfxp), and the various URIs derived from the short name, were
formally submitted to the Director some years ago and approved for use in
this work. Changing it now would require requesting a change and obtaining a
new approval. As a result, it is extremely unlikely that the TTWG will be
willing to adopt your suggested change.

Keep the formal short name, URL paths and so on.

One path might be to distinguish the technology from the specification
/ document / standard.

So the unfortunately named document remains "Timed Text (TT) Authoring
Format 1.0 – Distribution Format Exchange Profile (DFXP)" but the
technology it defines might simply be known as "DFXP" or "Timed Text",
or perhaps "Timed Text Web Format (TTWF)".

I understand that this seems a last minute request for a big change,
after years of work and consensus building.

But also I would stress that once it gets to REC, you'll be stuck with
it forever. We all will. At a minimum, please agree which informal
name you think we should all use in blog posts, tags etc, and make
sure this is prominently used in the abstract, in the associated W3C
site, press releases, etc.

My advice would be to take this up with the W3C Comms team (I've cc:'d
Ian) and Director during CR. If they say no, it's all fine, then I'll
drop my objection.

I would suggest that the best way you could address this issue is to go out
and implement exciting products based on this specification, and assign
those products a more marketable, and memorable name.

I'll get right on that ;)

cheers,

Dan

Re: please rename Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP)

2009-09-30T03:22:17Z

On Wed, Sep 30, 2009 at 11:22 AM, Glenn Adams <gadams@...> wrote:
> As an informal short name, "DFXP" is fine; however, the official short name
> will remain "ttaf1-dfxp" which is encoded in the DFXP namespace URIs. That
> having been said, I believe the TTWG will decline to make any change to the
> specification's title. For what its worth, you have my permission to use the
> informal short name (i.e., "DFXP") and to publicize it on that basis. Or, if
> you have something more catchy, give it a try.

Fixing in an information short name seems a good start. Although
Philippe suggested "Timed Text" (perhaps a little general), "DFXP"
does the job, so long as everyone agrees to use it (so you might
coordinate with Philippe on that point). As you say, "MP3" is somewhat
obscure but became a well known name.

Re: more catchy, perhaps we can work within the pragmatic constraint
of DFXP as the chosen informal name, and work backwards to an
alternative expansion. Silvia wrote "Doesn't even need a full
spell-out of what "DFXP" stands for.". I agree that the current
expansion isn't very helpful. But maybe there are other phrases that
expand to DFXP which capture something of the application domain?

* Digital Footnotes Exchange Profile (or Protocol, though that might mislead)
* Dynamic Footnote XML P-something
* Distributed Film X-something Publishing
* Distributed Footnote XML Publishing
* Digital Footnote Extension P-something

OK, none of those are super-catchy. But it's conceivable we could find
something that fits the existing acronym... "Footnote" and "Film"
aren't quite the right scope, but they do at least hint at the
application area.

> I'm not worried about TTAF or TTAF1-DFXP or DFXP, whatever you prefer to
> call it, succeeding or failing on the strength of its name. If it fails to
> be adopted, it won't be because of its name.

Things rarely fail for a single reason. My suggested edits to the
Abstract reflect a related concern about the way this technology is
being positioned and described...

> MP3 stands for MPEG-1 Audio Layer 3, which in turn, stands for "Moving
> Picture Expert Group Series 1, Audio Layer III" which is formally defined by
> "ISO/IEC 11172-3 Information technology -- Coding of moving pictures and
> associated audio for digital storage media at up to about 1,5 Mbit/s -- Part
> 3: Audio". Nowhere in that document does the acronym "MP3" appear, and yet
> it is widely known by that term and widely implemented and eminently
> successful.

Yes, MP3 did well. Mostly because it was the name for a technology
related to easy aquisition of online music. But it did have a very
short if cryptic name. DFXP could be comparable.

* "What's this?" "It's a DFXP file."
* "But the audio is in French." "So download a DFXP."
* "How does the find-a-scene search work?" "It indexes the DFXP"
* "Can you put the subtitles in a bigger font?" "Sure, it uses DFXP...."

All that sounds fine to me, although the lack of a useful acronym
expansion is a shame. Something with Timed Text in it appeals to me a
bit more, but I can understand the reluctance to change things at this
stage. Whatever you do, please pick one and stick with it! And hide
all that stuff about authoring versus exchange, it doesn't make sense
to 99% of your audience....

cheers,

Dan

Re: please rename Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP)

2009-09-30T03:20:10Z

Hi all,

The full "technical" name is fine as long as a short "friendly" name
is somehow promoted for use by the community at large. As it happens,
the Working Group name is "Timed Text", with the subtitle: "Delivering
Captioning and Video Description for the Web". Well, guess what: I
(and most people I know) tend to use "W3C Timed-Text" or "Timed Text",
and we only refer to "DFXP" amongst *really* geeky people (i.e.
specification writers or implementors). Will there ever be another
deliverable from the "Timed Text" Working Group, other than the
affectively-nicknamed "Timed Text" specification (normatively-named
"TTAF1-DFXP") ? My guess is no, and the terms "W3C Timed Text" will
prevail because in most cases there will be no need to differentiate
any further.

Admittedly, the compressed term "TTAF1-DFXP" for "Timed Text (TT)
Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP)"
doesn't exactly stir my imagination, but then, it's a formal title for
an authoritative specification...not a brand name.

The main confusion, I think, stems from the fact that "TTAF1-DFXP" (in
its expanded form) mixes "Authoring", "Distribution" and "Exchange"
within the same title, in a way that immediately challenges my mental
expectations. These terms denote concepts that normally address very
different requirements, so my initial impression is that the
specification document will simply describe the DFXP profile, and that
the actual AF is specified elsewhere (the title is leading me to
assume that there are other Profiles defined elsewhere as well). In
order to figure-out what this specification means in the *real world*,
I need to read the Abstract, the Definitions, and finally the Profiles
section which reveals several "sub-profiles" for DFXP (Transformation,
Presentation and Full).

I am not suggesting that changes are required for the document in its
current state. I am merely stating the fact that the confusing title
adds another layer of perceived complexity to a specification that is,
it is fair to say, a pretty scary beast for implementors. In any case,
well done to the working group members for pulling this one out, we
all appreciate your dedication and hard work.

Kind regards, Daniel

On 30 Sep 2009, at 09:56, Dan Brickley wrote:

> Hi Glen, and thanks also Silvia for the quick reply,
>
> On Wed, Sep 30, 2009 at 2:03 AM, Glenn Adams <gadams@...> wrote:
>> Dan,
>> The intent of the 2nd Candidate Recommendation phase is to obtain
>> implementation feedback. While what you say below is of potential
>> editorial
>> import, it does not represent useful implementation feedback.
>
> This is true. I should also congratulate you on reaching this
> milestone, I know it has been a lot of work. So my apologies for
> jumping straight in with complaints in my previous message. The reason
> I
> feel my comment was particularly relevant to CR was a bit meta. I
> doubt your technology will get the
> widespread implementor review and the community excitement that it
> deserves, not because of
> any engineering or technical failings, but just because of the name.
>
>> As it is, the name of the specification is now a number of years
>> old, and no such comment
>> as you submit now has been previously received.
>
> I have to admit I thought of raising this a few times in previous
> years, but it always seemed a bit, well, cheeky.
>
> In the last 24 hours, I have received 3 comments from members of the
> TTAF1-DFXP community which I think make my point for me. You all agree
> that it will be known by a short name. But you disagree on what that
> name will be:
>
> Here (below) you mention the formal W3C short name "ttaf1-dfxp", but
> no other abbreviated or convenience name. Meanwhile Silvia wrote "I
> think that in common language, the format will be known as DFXP".
> Yesterday, responding via Identi.ca (http://identi.ca/notice/10978839)
> Philippe Le Hégaret wrote "@danbri I'm happy to convey concrete
> proposals for new names to the WG. Having said that, folks know the
> technology as Timed Text already."
>
> So, what do we tell the bloggers - ttaf1-dfxp, DFXP or Timed Text?
>
> Characteristics of a good informal name for the technology might be:
>
> * short
> * memorable
> * unambiguous
> * carries relevant meaning to newcomers
>
> For communication outside the world of W3C, the immediate candidates
> seem to be "DFXP" and "Timed Text". The former is short and has no
> variants, whereas "Timed Text" is much less cryptic, but has some
> variants; we could expect to see the whitespace collapsed for use in
> tags, or the case dropped. Still "timedtext" remains meaningful.
>
> Here's a quick survey of how these names are currently used in
> delicious tags:
>
> http://delicious.com/search?p=dfxp&chk=&fr=del_icio_us&lc=0&atags=&rtags=&context=userposts
> |danbri|&context=all||
>
> dfxp - 27 results
>
> http://delicious.com/search?p=timedtext&chk=&context=userposts|
> danbri&fr=del_icio_us&lc=
>
> timedtext - 31 results
>
> ttaf1-dfxp - no results
>
>
> This suggests that none of these options are well established
> (contrast 'mathml' or 'html5', 'html' which are obvious tags).
>
>> While I might agree that the title is a bit lengthy, it is
>> accurate, and it reflects the end results of a
>> long process which it represents well.
>
> Sometimes it's best to move process history out of titles, before they
> get to Recommendation. I say this as the lead editor of another REC,
> http://www.w3.org/TR/rdf-schema/
>
> "RDF Vocabulary Description Language 1.0: RDF Schema"
>
> Now I could give you the whole story for why it has this unwieldy
> name. But the key point is that the technology is universally known as
> RDF Schema, and abbreviated 9 times out of 10 as "RDFS" (but
> occasionally we see "RDF/S"). In short, we downplayed the use of the
> word "Schema" due to the horrible tensions between RDF and XML people
> at the time; around 1999-2000 RDFS was seen as a potential rival or
> threat to XML Schema.
>
> So why didn't we call it a basic/simple ontology language? Which is
> how W3C has subsequently referred to the kind of technology that
> defines the meaning of terms in RDF. Simply because the final RDFS
> work was under the RDFCore WG, and an Ontology WG was beginning the
> first OWL work at the same time, and that group quite reasonably
> didn't want another group to go publishing a first "ontology"
> recommendation in parallel.
>
> So the awkward name was a product of W3C's process. It was, as you
> say, accurate and reflects well the end results of a long process. In
> retrospect, I wish we had just called it "RDF Schema (RDFS) 1.0".
>
>> I might agree with you that the name is not one that has much
>> marketing zing, but then again, neither do most of the other names
>> of specifications published by the W3C.
>
> True, but many at least have a short and simple name. "CSS", "MathML"
> do the job nicely, "SPARQL", "OWL" even have a kind of obscure charm
> or character.
>
> To re-state my concerns, they are that the long name of technology is
> too long, doesn't describe the technology to a non-insider audience,
> and doesn't come with a simple, short and memorable abbreviated name
> suited for tags, conversation, mention in blogs etc.
>
> "This is the Candidate Recommendation of the Timed Text (TT) Authoring
> Format 1.0 – Distribution Format Exchange Profile (DFXP)"
>
> I can barely say that in one breath.
>
>> Finally, I would note that both the name of the specification, its
>> "short
>> name" (ttaf1-dfxp), and the various URIs derived from the short
>> name, were
>> formally submitted to the Director some years ago and approved for
>> use in
>> this work. Changing it now would require requesting a change and
>> obtaining a
>> new approval. As a result, it is extremely unlikely that the TTWG
>> will be
>> willing to adopt your suggested change.
>
> Keep the formal short name, URL paths and so on.
>
> One path might be to distinguish the technology from the specification
> / document / standard.
>
> So the unfortunately named document remains "Timed Text (TT) Authoring
> Format 1.0 – Distribution Format Exchange Profile (DFXP)" but the
> technology it defines might simply be known as "DFXP" or "Timed Text",
> or perhaps "Timed Text Web Format (TTWF)".
>
> I understand that this seems a last minute request for a big change,
> after years of work and consensus building.
>
> But also I would stress that once it gets to REC, you'll be stuck with
> it forever. We all will. At a minimum, please agree which informal
> name you think we should all use in blog posts, tags etc, and make
> sure this is prominently used in the abstract, in the associated W3C
> site, press releases, etc.
>
> My advice would be to take this up with the W3C Comms team (I've cc:'d
> Ian) and Director during CR. If they say no, it's all fine, then I'll
> drop my objection.
>
>> I would suggest that the best way you could address this issue is
>> to go out
>> and implement exciting products based on this specification, and
>> assign
>> those products a more marketable, and memorable name.
>
> I'll get right on that ;)
>
> cheers,
>
> Dan

Re: please rename Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP)

2009-09-30T02:22:33Z

As an informal short name, "DFXP" is fine; however, the official short name will remain "ttaf1-dfxp" which is encoded in the DFXP namespace URIs. That having been said, I believe the TTWG will decline to make any change to the specification's title. For what its worth, you have my permission to use the informal short name (i.e., "DFXP") and to publicize it on that basis. Or, if you have something more catchy, give it a try.

I'm not worried about TTAF or TTAF1-DFXP or DFXP, whatever you prefer to call it, succeeding or failing on the strength of its name. If it fails to be adopted, it won't be because of its name.

MP3 stands for MPEG-1 Audio Layer 3, which in turn, stands for "Moving Picture Expert Group Series 1, Audio Layer III" which is formally defined by "ISO/IEC 11172-3 Information technology -- Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s -- Part 3: Audio". Nowhere in that document does the acronym "MP3" appear, and yet it is widely known by that term and widely implemented and eminently successful.

Glenn

On Wed, Sep 30, 2009 at 4:56 PM, Dan Brickley <danbri@...> wrote:

Hi Glen, and thanks also Silvia for the quick reply,

On Wed, Sep 30, 2009 at 2:03 AM, Glenn Adams <gadams@...> wrote:
> Dan,
> The intent of the 2nd Candidate Recommendation phase is to obtain
> implementation feedback. While what you say below is of potential editorial
> import, it does not represent useful implementation feedback.

This is true. I should also congratulate you on reaching this
milestone, I know it has been a lot of work. So my apologies for
jumping straight in with complaints in my previous message. The reason
I
feel my comment was particularly relevant to CR was a bit meta. I
doubt your technology will get the
widespread implementor review and the community excitement that it
deserves, not because of
any engineering or technical failings, but just because of the name.

> As it is, the name of the specification is now a number of years old, and no such comment
> as you submit now has been previously received.

I have to admit I thought of raising this a few times in previous
years, but it always seemed a bit, well, cheeky.

In the last 24 hours, I have received 3 comments from members of the
TTAF1-DFXP community which I think make my point for me. You all agree
that it will be known by a short name. But you disagree on what that
name will be:

Here (below) you mention the formal W3C short name "ttaf1-dfxp", but
no other abbreviated or convenience name. Meanwhile Silvia wrote "I
think that in common language, the format will be known as DFXP".
Yesterday, responding via Identi.ca (http://identi.ca/notice/10978839)
Philippe Le Hégaret wrote "@danbri I'm happy to convey concrete
proposals for new names to the WG. Having said that, folks know the
technology as Timed Text already."

So, what do we tell the bloggers - ttaf1-dfxp, DFXP or Timed Text?

Characteristics of a good informal name for the technology might be:

* short
* memorable
* unambiguous
* carries relevant meaning to newcomers

For communication outside the world of W3C, the immediate candidates
seem to be "DFXP" and "Timed Text". The former is short and has no
variants, whereas "Timed Text" is much less cryptic, but has some
variants; we could expect to see the whitespace collapsed for use in
tags, or the case dropped. Still "timedtext" remains meaningful.

Here's a quick survey of how these names are currently used in delicious tags:

http://delicious.com/search?p=dfxp&chk=&fr=del_icio_us&lc=0&atags=&rtags=&context=userposts|danbri|&context=all||

dfxp - 27 results

http://delicious.com/search?p=timedtext&chk=&context=userposts|danbri&fr=del_icio_us&lc=

timedtext - 31 results

ttaf1-dfxp - no results

This suggests that none of these options are well established
(contrast 'mathml' or 'html5', 'html' which are obvious tags).

> While I might agree that the title is a bit lengthy, it is accurate, and it reflects the end results of a
> long process which it represents well.

Sometimes it's best to move process history out of titles, before they
get to Recommendation. I say this as the lead editor of another REC,
http://www.w3.org/TR/rdf-schema/

"RDF Vocabulary Description Language 1.0: RDF Schema"

Now I could give you the whole story for why it has this unwieldy
name. But the key point is that the technology is universally known as
RDF Schema, and abbreviated 9 times out of 10 as "RDFS" (but
occasionally we see "RDF/S"). In short, we downplayed the use of the
word "Schema" due to the horrible tensions between RDF and XML people
at the time; around 1999-2000 RDFS was seen as a potential rival or
threat to XML Schema.

So why didn't we call it a basic/simple ontology language? Which is
how W3C has subsequently referred to the kind of technology that
defines the meaning of terms in RDF. Simply because the final RDFS
work was under the RDFCore WG, and an Ontology WG was beginning the
first OWL work at the same time, and that group quite reasonably
didn't want another group to go publishing a first "ontology"
recommendation in parallel.

So the awkward name was a product of W3C's process. It was, as you
say, accurate and reflects well the end results of a long process. In
retrospect, I wish we had just called it "RDF Schema (RDFS) 1.0".

> I might agree with you that the name is not one that has much marketing zing, but then again, neither do most of the other names of specifications published by the W3C.

True, but many at least have a short and simple name. "CSS", "MathML"
do the job nicely, "SPARQL", "OWL" even have a kind of obscure charm
or character.

To re-state my concerns, they are that the long name of technology is
too long, doesn't describe the technology to a non-insider audience,
and doesn't come with a simple, short and memorable abbreviated name
suited for tags, conversation, mention in blogs etc.

"This is the Candidate Recommendation of the Timed Text (TT) Authoring

Format 1.0 – Distribution Format Exchange Profile (DFXP)"

I can barely say that in one breath.

> Finally, I would note that both the name of the specification, its "short
> name" (ttaf1-dfxp), and the various URIs derived from the short name, were
> formally submitted to the Director some years ago and approved for use in
> this work. Changing it now would require requesting a change and obtaining a
> new approval. As a result, it is extremely unlikely that the TTWG will be
> willing to adopt your suggested change.

Keep the formal short name, URL paths and so on.

One path might be to distinguish the technology from the specification
/ document / standard.

So the unfortunately named document remains "Timed Text (TT) Authoring
Format 1.0 – Distribution Format Exchange Profile (DFXP)" but the
technology it defines might simply be known as "DFXP" or "Timed Text",
or perhaps "Timed Text Web Format (TTWF)".

I understand that this seems a last minute request for a big change,
after years of work and consensus building.

But also I would stress that once it gets to REC, you'll be stuck with
it forever. We all will. At a minimum, please agree which informal
name you think we should all use in blog posts, tags etc, and make
sure this is prominently used in the abstract, in the associated W3C
site, press releases, etc.

My advice would be to take this up with the W3C Comms team (I've cc:'d
Ian) and Director during CR. If they say no, it's all fine, then I'll
drop my objection.

> I would suggest that the best way you could address this issue is to go out
> and implement exciting products based on this specification, and assign
> those products a more marketable, and memorable name.

I'll get right on that ;)

cheers,

Dan

Re: please rename Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP)

2009-09-30T01:56:22Z

Hi Glen, and thanks also Silvia for the quick reply,

On Wed, Sep 30, 2009 at 2:03 AM, Glenn Adams <gadams@...> wrote:
> Dan,
> The intent of the 2nd Candidate Recommendation phase is to obtain
> implementation feedback. While what you say below is of potential editorial
> import, it does not represent useful implementation feedback.

This is true. I should also congratulate you on reaching this
milestone, I know it has been a lot of work. So my apologies for
jumping straight in with complaints in my previous message. The reason
I
feel my comment was particularly relevant to CR was a bit meta. I
doubt your technology will get the
widespread implementor review and the community excitement that it
deserves, not because of
any engineering or technical failings, but just because of the name.

> As it is, the name of the specification is now a number of years old, and no such comment
> as you submit now has been previously received.

I have to admit I thought of raising this a few times in previous
years, but it always seemed a bit, well, cheeky.

In the last 24 hours, I have received 3 comments from members of the
TTAF1-DFXP community which I think make my point for me. You all agree
that it will be known by a short name. But you disagree on what that
name will be:

Here (below) you mention the formal W3C short name "ttaf1-dfxp", but
no other abbreviated or convenience name. Meanwhile Silvia wrote "I
think that in common language, the format will be known as DFXP".
Yesterday, responding via Identi.ca (http://identi.ca/notice/10978839)
Philippe Le Hégaret wrote "@danbri I'm happy to convey concrete
proposals for new names to the WG. Having said that, folks know the
technology as Timed Text already."

So, what do we tell the bloggers - ttaf1-dfxp, DFXP or Timed Text?

Characteristics of a good informal name for the technology might be:

* short
* memorable
* unambiguous
* carries relevant meaning to newcomers

For communication outside the world of W3C, the immediate candidates
seem to be "DFXP" and "Timed Text". The former is short and has no
variants, whereas "Timed Text" is much less cryptic, but has some
variants; we could expect to see the whitespace collapsed for use in
tags, or the case dropped. Still "timedtext" remains meaningful.

Here's a quick survey of how these names are currently used in delicious tags:

http://delicious.com/search?p=dfxp&chk=&fr=del_icio_us&lc=0&atags=&rtags=&context=userposts|danbri|&context=all||

dfxp - 27 results

http://delicious.com/search?p=timedtext&chk=&context=userposts|danbri&fr=del_icio_us&lc=

timedtext - 31 results

ttaf1-dfxp - no results

This suggests that none of these options are well established
(contrast 'mathml' or 'html5', 'html' which are obvious tags).

> While I might agree that the title is a bit lengthy, it is accurate, and it reflects the end results of a
> long process which it represents well.

Sometimes it's best to move process history out of titles, before they
get to Recommendation. I say this as the lead editor of another REC,
http://www.w3.org/TR/rdf-schema/

"RDF Vocabulary Description Language 1.0: RDF Schema"

Now I could give you the whole story for why it has this unwieldy
name. But the key point is that the technology is universally known as
RDF Schema, and abbreviated 9 times out of 10 as "RDFS" (but
occasionally we see "RDF/S"). In short, we downplayed the use of the
word "Schema" due to the horrible tensions between RDF and XML people
at the time; around 1999-2000 RDFS was seen as a potential rival or
threat to XML Schema.

So why didn't we call it a basic/simple ontology language? Which is
how W3C has subsequently referred to the kind of technology that
defines the meaning of terms in RDF. Simply because the final RDFS
work was under the RDFCore WG, and an Ontology WG was beginning the
first OWL work at the same time, and that group quite reasonably
didn't want another group to go publishing a first "ontology"
recommendation in parallel.

So the awkward name was a product of W3C's process. It was, as you
say, accurate and reflects well the end results of a long process. In
retrospect, I wish we had just called it "RDF Schema (RDFS) 1.0".

> I might agree with you that the name is not one that has much marketing zing, but then again, neither do most of the other names of specifications published by the W3C.

True, but many at least have a short and simple name. "CSS", "MathML"
do the job nicely, "SPARQL", "OWL" even have a kind of obscure charm
or character.

To re-state my concerns, they are that the long name of technology is
too long, doesn't describe the technology to a non-insider audience,
and doesn't come with a simple, short and memorable abbreviated name
suited for tags, conversation, mention in blogs etc.

"This is the Candidate Recommendation of the Timed Text (TT) Authoring
Format 1.0 – Distribution Format Exchange Profile (DFXP)"

I can barely say that in one breath.

> Finally, I would note that both the name of the specification, its "short
> name" (ttaf1-dfxp), and the various URIs derived from the short name, were
> formally submitted to the Director some years ago and approved for use in
> this work. Changing it now would require requesting a change and obtaining a
> new approval. As a result, it is extremely unlikely that the TTWG will be
> willing to adopt your suggested change.

Keep the formal short name, URL paths and so on.

One path might be to distinguish the technology from the specification
/ document / standard.

So the unfortunately named document remains "Timed Text (TT) Authoring
Format 1.0 – Distribution Format Exchange Profile (DFXP)" but the
technology it defines might simply be known as "DFXP" or "Timed Text",
or perhaps "Timed Text Web Format (TTWF)".

I understand that this seems a last minute request for a big change,
after years of work and consensus building.

But also I would stress that once it gets to REC, you'll be stuck with
it forever. We all will. At a minimum, please agree which informal
name you think we should all use in blog posts, tags etc, and make
sure this is prominently used in the abstract, in the associated W3C
site, press releases, etc.

My advice would be to take this up with the W3C Comms team (I've cc:'d
Ian) and Director during CR. If they say no, it's all fine, then I'll
drop my objection.

> I would suggest that the best way you could address this issue is to go out
> and implement exciting products based on this specification, and assign
> those products a more marketable, and memorable name.

I'll get right on that ;)

cheers,

Dan

Re: please rename Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP)

2009-09-29T17:03:29Z

Dan,

The intent of the 2nd Candidate Recommendation phase is to obtain implementation feedback. While what you say below is of potential editorial import, it does not represent useful implementation feedback. As it is, the name of the specification is now a number of years old, and no such comment as you submit now has been previously received. While I might agree that the title is a bit lengthy, it is accurate, and it reflects the end results of a long process which it represents well. I might agree with you that the name is not one that has much marketing zing, but then again, neither do most of the other names of specifications published by the W3C.

Finally, I would note that both the name of the specification, its "short name" (ttaf1-dfxp), and the various URIs derived from the short name, were formally submitted to the Director some years ago and approved for use in this work. Changing it now would require requesting a change and obtaining a new approval. As a result, it is extremely unlikely that the TTWG will be willing to adopt your suggested change.

I would suggest that the best way you could address this issue is to go out and implement exciting products based on this specification, and assign those products a more marketable, and memorable name.

Regards,

Glenn

On Tue, Sep 29, 2009 at 11:27 PM, Dan Brickley <danbri@...> wrote:

Reviewing http://www.w3.org/TR/2009/CR-ttaf1-dfxp-20090924/#intro
again, I find I get stuck on the title of the document.

The name you have given your work does not do it (or W3C) justice:

"Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange
Profile (DFXP)"

The only piece of this which carries any hint as to the real world
value of your work is the phrase "Timed Text". I strongly encourage
you to rebrand the work around something more memorable. In practice
it will be called Timed Text, or Timed Text *something*, and all the
text floating around that talks about legacy systems, authoring,
presentation, smil etc will be ignored. The work will succeed or fail
on the usefulness of the text format. Giving it a name that simply
identifies its purpose will help it find a useful niche. Failing that,
at least give it a short enough name that two parties referrring to it
can do so in two or three syllables. Not twenty!

The current title (and abstract) need some work before this goes to REC.

Is the format designed ... for "authoring"? For "exchange"? Is
"publication" or "distribution" different to exchange? is conversion
from a legacy format "authoring"? What makes something "legacy"? Am I
mis-using the format if I use it for full text indexing or content
analysis or on-screen search in a smart EPG? Or for counting the swear
words in a movie sound-track to help human cataloguers classify it?

The abstract also focusses excessively on "means to an end" issues,
rather than the actual problems addressed by the technology.

Here is the abstract, with my comments in [chunky brackets]:

"""This document specifies the distribution format exchange profile
(DFXP) of the timed text authoring format (TT AF) in terms of a
vocabulary and semantics thereof.

[ suggest: This document specifies a format for exchanging Timed Text
information, by defining a vocabulary with associated semantics ]

The timed text authoring format is a content type that represents
timed text media for the purpose of interchange among authoring
systems. Timed text is textual information that is intrinsically or
extrinsically associated with timing information.

[ suggest: Timed Text is textual information that is intrinsically or
extrinsically associated with timing information. The format defined
here represents Timed Text in a manner suitable for exchange amongst
applications involved in the authoring, transcoding, presentation,
indexing, search or management of timed textual information, eg.
subtitling and captioning systems. We do not emurate the possible uses
of the technology, but focus instead on giving the format a clear
definition so that it can provide interoperability between diverse
systems.]

The Distribution Format Exchange Profile is intended to be used for
the purpose of transcoding or exchanging timed text information among
legacy distribution content formats presently in use for subtitling
and captioning functions.
[ suggest: delete this]

In addition to being used for interchange among legacy distribution
content formats, DFXP content may be used directly as a distribution
format, for example, providing a standard content format to reference
from a <text> or <textstream> media object element in a [SMIL 2.1]
document.
[suggest: delete this; a W3C format can be used wherever it is useful] """

In summary: please don't go to REC with this awkward, unwieldy name.
Just call it the Timed Text Markup Language or similar, and resist the
attempt in the overview to enumerate all the ways (authoring,
exchange, distribution) the format can be used, and go into a bit more
detail about what it can be used to *achieve*...

Thanks,

Dan

Re: please rename Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP)

2009-09-29T16:59:50Z

I think that in common language, the format will be known as DFXP and
it will be called a captioning or subtitling format - at most a timed
text format, even though that is not something people commonly use. I
would suggest keeping DFXP in the title somehow. Maybe something like
"The DFXP file format for timed text associated with audio or video
data". Doesn't even need a full spell-out of what "DFXP" stands for.

Cheers,
Silvia.

On Wed, Sep 30, 2009 at 1:27 AM, Dan Brickley <danbri@...> wrote:

> Reviewing http://www.w3.org/TR/2009/CR-ttaf1-dfxp-20090924/#intro
> again, I find I get stuck on the title of the document.
>
> The name you have given your work does not do it (or W3C) justice:
>
> "Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange
> Profile (DFXP)"
>
> The only piece of this which carries any hint as to the real world
> value of your work is the phrase "Timed Text". I strongly encourage
> you to rebrand the work around something more memorable. In practice
> it will be called Timed Text, or Timed Text *something*, and all the
> text floating around that talks about legacy systems, authoring,
> presentation, smil etc will be ignored. The work will succeed or fail
> on the usefulness of the text format. Giving it a name that simply
> identifies its purpose will help it find a useful niche. Failing that,
> at least give it a short enough name that two parties referrring to it
> can do so in two or three syllables. Not twenty!
>
> The current title (and abstract) need some work before this goes to REC.
>
> Is the format designed ... for "authoring"? For "exchange"? Is
> "publication" or "distribution" different to exchange? is conversion
> from a legacy format "authoring"? What makes something "legacy"? Am I
> mis-using the format if I use it for full text indexing or content
> analysis or on-screen search in a smart EPG? Or for counting the swear
> words in a movie sound-track to help human cataloguers classify it?
>
> The abstract also focusses excessively on "means to an end" issues,
> rather than the actual problems addressed by the technology.
>
> Here is the abstract, with my comments in [chunky brackets]:
>
> """This document specifies the distribution format exchange profile
> (DFXP) of the timed text authoring format (TT AF) in terms of a
> vocabulary and semantics thereof.
>
> [ suggest: This document specifies a format for exchanging Timed Text
> information, by defining a vocabulary with associated semantics ]
>
> The timed text authoring format is a content type that represents
> timed text media for the purpose of interchange among authoring
> systems. Timed text is textual information that is intrinsically or
> extrinsically associated with timing information.
>
> [ suggest: Timed Text is textual information that is intrinsically or
> extrinsically associated with timing information. The format defined
> here represents Timed Text in a manner suitable for exchange amongst
> applications involved in the authoring, transcoding, presentation,
> indexing, search or management of timed textual information, eg.
> subtitling and captioning systems. We do not emurate the possible uses
> of the technology, but focus instead on giving the format a clear
> definition so that it can provide interoperability between diverse
> systems.]
>
> The Distribution Format Exchange Profile is intended to be used for
> the purpose of transcoding or exchanging timed text information among
> legacy distribution content formats presently in use for subtitling
> and captioning functions.
> [ suggest: delete this]
>
> In addition to being used for interchange among legacy distribution
> content formats, DFXP content may be used directly as a distribution
> format, for example, providing a standard content format to reference
> from a <text> or <textstream> media object element in a [SMIL 2.1]
> document.
> [suggest: delete this; a W3C format can be used wherever it is useful] """
>
> In summary: please don't go to REC with this awkward, unwieldy name.
> Just call it the Timed Text Markup Language or similar, and resist the
> attempt in the overview to enumerate all the ways (authoring,
> exchange, distribution) the format can be used, and go into a bit more
> detail about what it can be used to *achieve*...
>
> Thanks,
>
> Dan
>
>

please rename Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange Profile (DFXP)

2009-09-29T08:27:50Z

Reviewing http://www.w3.org/TR/2009/CR-ttaf1-dfxp-20090924/#intro
again, I find I get stuck on the title of the document.

The name you have given your work does not do it (or W3C) justice:

"Timed Text (TT) Authoring Format 1.0 – Distribution Format Exchange
Profile (DFXP)"

The only piece of this which carries any hint as to the real world
value of your work is the phrase "Timed Text". I strongly encourage
you to rebrand the work around something more memorable. In practice
it will be called Timed Text, or Timed Text *something*, and all the
text floating around that talks about legacy systems, authoring,
presentation, smil etc will be ignored. The work will succeed or fail
on the usefulness of the text format. Giving it a name that simply
identifies its purpose will help it find a useful niche. Failing that,
at least give it a short enough name that two parties referrring to it
can do so in two or three syllables. Not twenty!

The current title (and abstract) need some work before this goes to REC.

Is the format designed ... for "authoring"? For "exchange"? Is
"publication" or "distribution" different to exchange? is conversion
from a legacy format "authoring"? What makes something "legacy"? Am I
mis-using the format if I use it for full text indexing or content
analysis or on-screen search in a smart EPG? Or for counting the swear
words in a movie sound-track to help human cataloguers classify it?

The abstract also focusses excessively on "means to an end" issues,
rather than the actual problems addressed by the technology.

Here is the abstract, with my comments in [chunky brackets]:

"""This document specifies the distribution format exchange profile
(DFXP) of the timed text authoring format (TT AF) in terms of a
vocabulary and semantics thereof.

[ suggest: This document specifies a format for exchanging Timed Text
information, by defining a vocabulary with associated semantics ]

The timed text authoring format is a content type that represents
timed text media for the purpose of interchange among authoring
systems. Timed text is textual information that is intrinsically or
extrinsically associated with timing information.

[ suggest: Timed Text is textual information that is intrinsically or
extrinsically associated with timing information. The format defined
here represents Timed Text in a manner suitable for exchange amongst
applications involved in the authoring, transcoding, presentation,
indexing, search or management of timed textual information, eg.
subtitling and captioning systems. We do not emurate the possible uses
of the technology, but focus instead on giving the format a clear
definition so that it can provide interoperability between diverse
systems.]

The Distribution Format Exchange Profile is intended to be used for
the purpose of transcoding or exchanging timed text information among
legacy distribution content formats presently in use for subtitling
and captioning functions.
[ suggest: delete this]

In addition to being used for interchange among legacy distribution
content formats, DFXP content may be used directly as a distribution
format, for example, providing a standard content format to reference
from a <text> or <textstream> media object element in a [SMIL 2.1]
document.
[suggest: delete this; a W3C format can be used wherever it is useful] """

In summary: please don't go to REC with this awkward, unwieldy name.
Just call it the Timed Text Markup Language or similar, and resist the
attempt in the overview to enumerate all the ways (authoring,
exchange, distribution) the format can be used, and go into a bit more
detail about what it can be used to *achieve*...

Thanks,

Dan

[Fwd: DFXP 1.0 is a Candidate Recommendation (Call for Implementations)]

2009-09-25T06:42:42Z

FYI

-------- Forwarded Message --------
From: Ian Jacobs <ij@...>
Subject: DFXP 1.0 is a Candidate Recommendation (Call for
Implementations)
Date: Thu, 24 Sep 2009 11:46:15 -0500

Dear Advisory Committee Representative,

I am pleased to announce that DFXP 1.0 is a W3C Candidate
Recommendation:
http://www.w3.org/TR/2009/CR-ttaf1-dfxp-20090924/

The approval and publication are in response to this transition request:
http://lists.w3.org/Archives/Member/chairs/2009JulSep/0064

The disposition of Last Call comments is available at:
http://www.w3.org/2009/09/dfxp-lc-issues

There were no Formal Objections. The Group is still investigating the
possibility of adding more examples in the document. Two comments were
rejected, in particular a late request for the addition of Ruby
annotation support.

The Working Group believes it will have satisfied its implementation
criteria by 20 October 2009. Only the dynamic flow feature does not
have two implementations at this time, and is also lacking tests.

The DFXP 1.0 Working Group Charter is available at
http://www.w3.org/2008/01/timed-text-wg

Patent disclosures relevant to this specification may be found on the
Timed Text Working Group's patent disclosure page in conformance with
W3C policy:
http://www.w3.org/2004/01/pp-impl/34314/status

More information is available on the Timed Text Working Group home page:
http://www.w3.org/AudioVideo/TT/

This Call for Implementations follows section 7.4.3 of the W3C Process
Document:
http://www.w3.org/2005/10/Process-20051014/tr#cfi

Thank you,

For Tim Berners-Lee, Director, and
Philippe Le Hégaret, Interaction Domain Lead;
Ian Jacobs, Head of W3C Communications

[...]

No TTWG meeting this week.

2009-09-17T07:49:58Z

We will not have a meeting this week

Sean Hayes

Re: DFXP 1.0 Last Call issues list

2009-09-12T20:14:54Z

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

Re: DFXP 1.0 Last Call issues list

2009-09-12T20:05:07Z

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

Re: DFXP 1.0 Last Call issues list

2009-09-12T19:56:40Z

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.

RE: DFXP 1.0 Last Call issues list

2009-09-12T13:54:43Z

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: +44 118 909 5867,

Mobile: +44 7875 091385

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.