Re: ISSUE-303 (<a> link element): Permit HTML-style <a> elements to contain href links [TTML2]

FYI, the SVG WG is backing away from Xlink syntax, reverting to older
unqualified @href. I would be reluctant to introduce Xlink features.


On Tue, Mar 25, 2014 at 5:21 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote:

>  Thanks for the suggestion Andreas. It looks as though the only change
> needed to my proposal is to put the href and target attributes into the
> xlink namespace in order to create xlink 'simple' links. This is very
> similar to the approach taken by SVG with the <a> element [2], which seems
> to be an appropriately close example to take inspiration from.
>
>  [2] http://www.w3.org/TR/SVG11/linking.html#Links
>
>  To complete the definition we could also consider adding in the xlink
> behaviour attributes show and actuate.
>
>  This could be very helpful for extending TTML to permit referencing of
> external image resources in place of text, for example, by setting
> show="embed" actuate="onLoad". Note that the temporal extent of the
> rendering of such an external resource would be identical to that defined
> in TTML depending on the location of the <a> element, which does not itself
> have begin and end attributes. This could be extended to audio clips noting
> that the playback temporal extent would be clipped by the applicable
> temporal extent, in the case that the audio clip has a longer temporal
> extent than the applicable TTML temporal extent.
>
>  Links that the user may follow, to be loaded in a different context,
> i.e. not replacing the TTML content, would have show="new" or show="other"
> and actuate="onRequest". I would leave it up to implementations to define
> how the request mechanism may work in terms of user interface, but add a
> note that if more than one 'onRequest' link is simultaneously displayed
> that may add unhelpful complexity due to the need to do more than simply
> trigger a 'follow link' action in a time-constrained display, for example
> requiring an interaction to decide which link to follow.
>
>  Links that are automatically followed but loaded in a different context
> would have show="new" or show="other" and actuate="onLoad".
>
>  NB I don't propose to add a mechanism for linking *into* a TTML2
> document.
>
>  Kind regards,
>
>  Nigel
>
>
>   On 24/03/2014 16:31, "Andreas Tai" <tai@irt.de> wrote:
>
>   Because TTML is an XML Format you may consider XLink [1] for this
> purpose.
>
> Best regards,
>
> Andreas
>
> [1] http://www.w3.org/TR/xlink11/
>
> Am 21.03.2014 16:23, schrieb Glenn Adams:
>
> We had a rule for TTML1: no references to external resources. We will
> remove that rule for TTML2 for images and fonts, and perhaps now
> anchor/links as well.
>
>
> On Fri, Mar 21, 2014 at 8:24 AM, Timed Text Working Group Issue Tracker <
> sysbot+tracker@w3.org> wrote:
>
>> ISSUE-303 (<a> link element): Permit HTML-style <a> elements to contain
>> href links [TTML2]
>>
>> http://www.w3.org/AudioVideo/TT/tracker/issues/303
>>
>> Raised by: Nigel Megitt
>> On product: TTML2
>>
>> Permit <a> elements with href and target attributes only, around content
>> elements or text.
>>
>> This appears to be the minimal useful set of attributes around a link
>> that may appear in a timed context.
>>
>> The purpose of the target is to permit the linked content to be loaded
>> into an alternate context: one possible use case for this is to allow the
>> linked content to be loaded into a different window or iframe without
>> interrupting the flow of captions displayed against a video that's being
>> watched.
>>
>> More concretely, this could be used for example for 'go here for more
>> information' links or 'go here to vote for candidate X' links. A third
>> example could be 'go here for these subtitles in language [xyz]'.
>>
>> I don't know if this has been raised before, but it seems so obvious that
>> I'm surprised I couldn't find an issue for it - happy to be told where to
>> look for it if this is a duplicate. Apologies if I'm opening a can of worms
>> that everybody would rather stay closed...
>>
>>
>>
>>
>
>
> --
> ------------------------------------------------
> Andreas Tai
> Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
> R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
> Floriansmuehlstrasse 60, D-80939 Munich, Germany
>
> Phone: +49 89 32399-389 | Fax: +49 89 32399-200
> http: www.irt.de | Email: tai@irt.de
> ------------------------------------------------
>
> registration court&  managing director:
> Munich Commercial, RegNo. B 5191
> Dr. Klaus Illgner-Fehns
> ------------------------------------------------
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------
>