Re: ISSUE-179 av_param: Chairs Solicit Proposals

I think x- vs. no x- is a distraction as far as the ISSUE is
concerned. The crux of the matter is that HTML already has a mechanism
for adding key-value pairs elements: attributes.

Adding key-value pairs to elements using nested param elements where
both the key and the value reside in attribute values (instead of the
key residing in an attribute name) is a misguided artifact of letting
the DTD validation mechanism affect language design in the HTML 4
cycle.

With today's validation technology, non-standard key-value pairs can
be made equally invalid when expressed as param as when expressed as
attributes. On the other hand, it's equally feasible to make a
validator call valid content that uses key-value pairs unknown to the
validator in advance.

In other words, even if this WG added <param> to where av_param
suggests, I could program a validator to flag params invalid unless
the param names have been approved somehow. Or I could program a
validator not to complain about attributes with names starting with
"dlna-" (or whatever).

As for browser implementation, <embed> implementations already pass
arbitrary key-value pairs expressed as attributes through a plug-in
interface (and <embed> even predates <param>), so it's clearly
possible to use attributes for passing parameters to software
components that aren't part of the browser engine proper.

The notion that <param> is somehow more extensible than attributes is
an illusion.

Because attributes are more compact and because all major browsers
have shipped implementations that parse <source> as a void element, I
think this WG should reject av_param no matter what this WG thinks of
DLNA or other such consortia minting key-value pairs that aren't
stardardized in *this* WG for inclusion in HTML proper.

(However, I have a hard time believing that there'd be key-value pairs
that wouldn't be useful for Web content but would be good ideas for
multivendor walled gardens like cable TV. That is, I'm predisposed to
assume that either HTML is missing features that should be defined in
HTML proper or the additional features are bad ideas and shouldn't be
specced by DLNA, either.)

I object to the av_param change proposal due to reasons given above.

P.S. Even if one agreed with the general idea of av_param, the
av_param proposal is obviously flawed: It fails to define parsing
algorithm changes that would make it possible to express the kind of
tree that'd use the proposed content models. It claims there are no
conformance classes changes, which logically has to be a bogus claim,
since it's proposing something that isn't an editorial change. It's
also disingenuous to claim that there are neither known negative
effects nor known risks, when I had stated at least one in the bug
report from which the ISSUE was escalated.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Sunday, 30 October 2011 10:02:38 UTC