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

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

--- Comment #14 from Glenn Adams <glenn@skynav.com> ---
(In reply to Aaron Colwell from comment #13)
> (In reply to Glenn Adams from comment #11)
> > (In reply to Aaron Colwell from comment #8)
> > > 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.
> > 
> > If such a type (interface) were to add members beyond what is in a base
> > DataCue type, then that might be warranted. However, there is a fairly
> > significant standardization overhead with defining a new public type. If the
> > base type can work as is, then the extra overhead may not be justified.
> 
> It is not lost on me that my comments here might be considered part of that
> extra overhead. :) 
> 
> My primary concern here is that this design easily leads to simply returning
> key/value hashmaps for .value instead of requiring a type to be defined and
> the semantics to be explicitly defined for each attribute. This leaves
> implementers in a situation where they have to reverse engineer the hashmap
> and hope that the semantics don't change somewhere down the road or new keys
> magically appear or are conditionally present. It is also unclear what web
> applications are supposed to expect from this interface since sometimes
> .data is parsed and sometimes it is not, which means applications will have
> to always have their own parsers "just in case". I'm not sure that is a good
> interop story.

I think it is fine. The world doesn't work in lock step. Evolution is required
to determine what is important and what can be discarded. Current information
is always imperfect. Extensibility mechanisms are important even though they
allow a certain degree of non-interoperability. We don't know what metadata
types every browser will support, so we need a way to move from zero to that
state. View DataCue as one link in a longer chain still being forged.

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

Received on Thursday, 17 April 2014 16:56:09 UTC