W3C home > Mailing lists > Public > public-tt@w3.org > September 2014

Re: {minutes} Geneva F2F day 1 16/09/2014

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 21 Sep 2014 22:49:02 +1000
Message-ID: <CAHp8n2=mmBdhEot+xVsmsr9xOrevwhJUPHnoq2vLmiVZ0SW-zg@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: Nigel Megitt <nigel.megitt@bbc.co.uk>, TTWG <public-tt@w3.org>, "public-texttracks@w3.org" <public-texttracks@w3.org>
On Sun, Sep 21, 2014 at 1:56 PM, Glenn Adams <glenn@skynav.com> wrote:

>
> On Sat, Sep 20, 2014 at 6:41 PM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com> wrote:
>
>> On Sun, Sep 21, 2014 at 12:42 AM, Glenn Adams <glenn@skynav.com> wrote:
>> >
>> > On Sat, Sep 20, 2014 at 7:30 AM, Silvia Pfeiffer <
>> silviapfeiffer1@gmail.com>
>> > wrote:
>> >>
>> >> Most interesting read. Seems like there is not that much that doesn't
>> >> map in either direction.
>> >>
>> >> A few additions / corrections about WebVTT that relate to this
>> >> discussion and that were missed (though Simon caught most):
>> >>
>> >> 1.) Mapping WebVTT - 608/708
>> >> This wasn't mentioned, but I wanted to make sure people are aware that
>> >> there is already a spec that provides a basic mapping between WebVTT
>> >> and 608 and 708 captions at
>> >>
>> https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html
>> >> .
>> >> It does indeed require some CSS.
>> >>
>> >> 2.) Repetition of cue settings:
>> >> There's a plan to allow for some file metadata to set different
>> >> default values for settings, so repetition is not necessary.
>> >>
>> >> 3.) CSS works by using ::cue and ::cue-region - the first for cues and
>> >> the second for regions.
>> >> These selectors work from a Web page (wherever CSS is specified there)
>> >> and override default styling of WebVTT cues.
>> >>
>> >> 4.) cue overalpping:
>> >> It's actually not true that cues cannot overlap in time. They can and
>> >> are expected to. In fact, chapter cues are specifically defined as a
>> >> particular kind of overlapping cues that are hierarchically
>> >> structured, or in your words: are nested.
>> >>
>> >> 5.) cue ids:
>> >> I think it might be possible to map numeric identifiers to XML
>> >> identifiers - at least it's possible to use them like this for CSS:
>> >> ::cue(#\31) { color: green; }
>> >> This references a cue with id=1. That might work for mapping to TTML
>> >> xml:id too.
>> >
>> >
>> > it would be necessary to prefix a numeric identifer with at least one
>> alpha
>> > to use with xml:id
>>
>> Interesting. How does this work in the context of browsers?
>>
>> For comparison, I'm looking at SVG, though I'm wondering if that's
>> applicable to TTML.
>>
>> Here's how they define ID in SVG:
>> http://www.w3.org/TR/SVG/svgdtd.html#DTD.1.4
>>
>> <!ENTITY % SVG.id.attrib
>>     "id ID #IMPLIED"
>> >
>>
>> (so, it's "id" and not "xml:id")
>>
>> It works, e.g. in an example document like this, the element is
>> identifyable:
>>
>> <svg xmlns='http://www.w3.org/2000/svg' id='1'>
>>     <script>
>>       alert(document.getElementById('1'));
>>       alert(document.getElementById('1') == document.documentElement);
>>     </script>
>> </svg>
>>
>
> The syntax of the ID attribute value type is defined originally by SGML,
> but in the XML context (SVG is an XML language) as the Name construct [1].
>
> [1] http://www.w3.org/TR/REC-xml/#NT-Name
>
> [4]   NameStartChar   ::=   ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] |
> [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] |
> [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] |
> [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF][4a]   NameChar
>    ::=   NameStartChar <http://www.w3.org/TR/REC-xml/#NT-NameStartChar> |
> "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040][5]   Name
>    ::=   NameStartChar <http://www.w3.org/TR/REC-xml/#NT-NameStartChar> (
> NameChar <http://www.w3.org/TR/REC-xml/#NT-NameChar>)*
>
> In XML Schema 2, the value space for ID typed attributes is defined
> equivalently at [2].
>
> [2] http://www.w3.org/TR/xmlschema-2/#ID
>
>
>>
>> It seems to me that SVG have moved away from xml:id
>
>
> SVG has never moved away from the formal XML definition of ID. Also, it
> never directly used xml:id, which is a different name for the otherwise
> unqualified 'id' attribute, both of which use the same value syntax.
>
>
>> , since the #myRect
>> reference in the example below doesn't work
>>
>> <svg xmlns="http://www.w3.org/2000/svg"
>> xmlns:xlink="http://www.w3.org/1999/xlink"
>>      version="1.2" baseProfile="tiny" viewBox="0 0 480 360">
>>
>>   <desc>Forward reference of use element</desc>
>>
>>   <use xlink:href="#myRect" x="200" fill="green"/>
>>   <circle cx="450" cy="50" r="50" fill="yellow"/>
>>
>>   <g fill="red">
>>     <rect xml:id="myRect" width="100" height="100"/>
>>   </g>
>> </svg>
>>
>> but starts working if you add id="myRect" on the <rect> element.
>
>
> Again, SVG did not adopt use of the attribute named xml:id, but uses the
> unqualified 'id' attribute [3]. However, from the perspective of value
> syntax, both are the same and neither admit '1' as a legal value.
>
> [3] http://www.w3.org/TR/SVG/struct.html#IDAttribute
> id = "name"Standard XML attribute for assigning a unique *name* to an
> element. Refer to the Extensible Markup Language (XML) 1.0
> <http://www.w3.org/TR/2008/REC-xml-20081126/> Recommendation [XML10
> <http://www.w3.org/TR/SVG/refs.html#ref-XML10>].
>
>
>> It
>> continues to work even when replacing the "myRect" string with merely
>> a number such as "1".
>>
>
> That is a violation of SVG syntax. It may be that some UAs don't enforce
> that syntax as required by SVG.
>
>
>>
>> Is there any intention to move to that approach in TTML, too?
>
>
> You are mixing up two things here:
>
> (1) the names of attributes id vs xml:id, and
> (2) the value syntax for these attributes.
>
> SGML, HTML1 through HTML4, and XML variously make use of id. Some XML
> languages additionally or alternatively use xml:id [4]. Both id and xml:id
> have the same value syntax, neither of which accept '1' as a legal value.
>
> [4] http://www.w3.org/TR/xml-id/
>
> E.g., HTML4 specified [5]:
>
>    - *ID* and *NAME* tokens must begin with a letter ([A-Za-z]) and may
>    be followed by any number of letters, digits ([0-9]), hyphens ("-"),
>    underscores ("_"), colons (":"), and periods (".").
>
> [5] http://www.w3.org/TR/REC-html40/types.html#type-name
>
> HTML5 made a non-backward compatible change by removing this syntax
> restriction, allowing any single character value even digits provided they
> are unique in a document.
>
> In your tests, I suspect you are using the somewhat bastardized form of
> SVG that is embedded in HTML5 and that supports this non-backward
> compatible change regarding the ID value type.
>
>
>> If so,
>> then maybe the WebVTT identifiers should be mapped into an "id"
>> attribute rather than the "xml:id" attribute?
>>
>
> We did have an issue [6] (now closed - withdrawn) to consider allowing id
> in addition to xml:id, but even if that were to occur, we would not alter
> the value syntax for id to match the syntactically weaker form introduced
> by HTML5.
>
> [6] http://www.w3.org/AudioVideo/TT/tracker/issues/205
>
> XML validity is still considered a positive requirement for TTML.
>
>
OK, so that's obviously not a solution then. Thanks for explaining.

Silvia.
Received on Sunday, 21 September 2014 12:49:49 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:18 UTC