- From: Glenn Adams <glenn@skynav.com>
- Date: Sat, 20 Sep 2014 21:56:29 -0600
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Nigel Megitt <nigel.megitt@bbc.co.uk>, TTWG <public-tt@w3.org>, "public-texttracks@w3.org" <public-texttracks@w3.org>
- Message-ID: <CACQ=j+cxmw_y8h9bwL-KMjQ+nTnBXBB6ReG4nNGHTC=UA4g5Gw@mail.gmail.com>
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. > > Just some thoughts... > > Cheers, > Silvia. >
Received on Sunday, 21 September 2014 03:57:16 UTC