[Bug 25353] [DataCue] change DOMString? text to any? value

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25353

--- Comment #8 from Aaron Colwell <acolwell@google.com> ---
(In reply to Glenn Adams from comment #5)
> (In reply to Aaron Colwell from comment #4)
> > I thought DataCue
> > was only intended for things the UA doesn't know how to parse which is why I
> > feel like the .value property is a little strange.
> 
> Not exactly. It is intended to be used for @kind metadata tracks, which
> imply the UA doesn't know how to process (e.g., render) the content.

I have no problem with this.

> 
> At a minimum, the UA will need to parse the container sufficiently to
> extract a data cue's content (payload), but it may or may not be able to
> parse that payload.

I have no problem with this.

> 
> One basic type of parsing a UA may provide on that payload, if it can
> determine the payload is an encoded string (text), is to decode the payload
> bytes into a string, which was the original intention of the DOMString text
> attribute. But that doesn't imply the UA knows enough about that string to
> further parse it into a structure, e.g., if is plain text, xml text, json
> text, etc.

If the UA knows that this is text, then I'd expect it to return a type that
indicates "I know this is text data, but I don't understand how to parse it".
Perhaps something like UnparsedTextCue or some other name that clearly
indicates it is text, but the UA doesn't understand anything more than that.

> 
> My understanding of Ted's ask is that it should be possible for a UA that
> does know how to parse the cue's payload into something other than a string
> to expose the result of that parsing to the APP, without forcing every APP
> to perform the same decoding on the APP side of the fence.

My ask is that, if the UA knows how to parse it, then it should emit a
different cue type that explicitly indicates the parsed information instead of
this generic DataCue.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 16 April 2014 17:52:29 UTC