Re: ISSUE-41/ACTION-97 decentralized-extensibility

> Henri Sivonen wrote:
> > On Oct 5, 2009, at 14:25, Maciej Stachowiak wrote:
> >
> >> On Oct 5, 2009, at 12:03 AM, Sam Ruby wrote:
> >>
> >>> Henri Sivonen wrote:
> >>>> I think you are jumping ahead of things. We don't yet have consensus
> >>>> on what problems to solve. We don't have consensus on whether
> >>>> "decentralized extensibility" is the right way to solve those
> >>>> problems. And we don't have consensus on whether Microsoft's
> >>>> proposal (even on the high level) is the right kind of
> >>>> "decentralized extensibility" for solving the problems.
> >>>> I think it would make the situation clearer if you could state what
> >>>> problems you want solved, why you believe the HTML WG should solve
> >>>> those problems, what "decentralized extensibility" is (so the WG can
> >>>> recognize whether alternative proposals constitute "decentralized
> >>>> extensibility"), why you believe "decentralized extensibility" is
> >>>> the right way to solve the problems and why you believe Microsoft's
> >>>> proposal is the right kind of "decentralized extensibility".
> >>>
> >>> Consensus on what the values of localName, prefix, namespaceURI (and
> >>> possibly tagUrn) should return -- that's what I would like to see
> >>> resolved.
> >>
> >> If you really want to nail this down to concrete technical questions,
> >> then it's really a question of parsing, not API behavior. All of
> >> HTML5's current behavior flows directly from the element's or
> >> attribute's {namespace, prefix, localName} tuple. That tuple is either
> >> set by the parser, or as a result of creating elements or attributes
> >> directly with DOM calls.(*)
> >>
> >> As I understand it, Microsoft's proposal does not change any behavior
> >> for elements or attributes created with DOM APIs. All it does is
> >> change the initial {namespace, prefix, localName} tuple for elements
> >> and attributes created by the parser, and this is observable through
> >> the API behavior. I don't believe Microsoft's proposal can be
> >> explained solely in terms of API changes, without having the parser do
> >> something different (at the very least record some additional
> >> information). But it can be explained solely in terms of parser 
> changes.
> >
> > I agree with this assessment. However, I further think it doesn't make
> > sense to nail down technical questions without knowing the purpose of
> > the nailing. Without knowing the purpose, one can't perform informed
> > nailing. I'm interested in a *good* outcome--not just *any* outcome 
> that
> > enjoys consensus potentially because people participating in the
> > consensus lacked information.
>
> Let's stop with the strawmen.
>
> I want to discuss technical ramifications alongside of the reasons.
>
> You said "you are jumping ahead of things".  I interpret that as not
> wanting to talk about technical ramifications just yet.  If so, here we
> disagree.  And even if so, that's fine.  We can have multiple
> discussions, and each of us can participate in the ones we wish to.
> Abstract discussions with no clear and tangible ramifications simply do
> not interest me.  YMMV.
>
> But to position this as me not wanting to know the purpose... that's
> simply a strawman.  Please stop.
>
> >> Stating my personal views once again:
> >> - I can live with what HTML5's current parsing algorithm does to
> >> elements and attributes with colons in the name.
> >
> > In my view, the current parser spec addresses the problems it sets out
> > to address in a satisfactory way (except likely for the way HTML
> > <script> elements are closed).
> >
> > I think the set of changes flowing from an empty set of additional
> > problems to solve should be the empty set of changes. That is, I think
> > it wouldn't be rational for me personally to be part of a consensus
> > endorsing changes compared to the current spec without problems to 
> solve
> > to motivate the set of changes.
> >
> > Sam, did you mean for the WG to endorse the current parsing spec 
> text by
> > consensus?
>
> I interpret Microsoft's post as a something to seed discussion, and not
> (yet) as a proposal.  If they meant something more than that, I hope
> that they clarify.


Actually, and I may have interpreted the following incorrectly, but 
Tony's submittal does sound like a base proposal that's also supposed to 
begin a discussion in order to refine the proposal:

"We have included a base proposal with several optional components. The 
purpose of this document is to seed a discussion and we expect the 
discussion to drive improvements in the document."

Adrian write this when he introduced Tony's submittal.


>
> For anybody to say that they can't live with something that has yet to
> be proposed is a bit premature, in my opinion.
>
> If no alternate proposals are made, then I am prepared to endorse the
> current parsing spec text as having consensus.  Like Maciej, I have yet
> to hear anybody (including Microsoft) indicate that they can't live with
> the current spec text.
>
> All of the above is independent of whether or not any given individual
> considers the current spec text to have sufficient "distributed
> extensibility".
>

> I'll try to make a separate statement later today on my personal (i.e.,
> not as chair) opinions are on the subject.  A quick overview: I believe
> that it is true that Microsoft could implement the current HTML5 spec in
> IE9 in a way that would effectively break the web AND I believe that it
> is true that if other browsers were to adopt what MS put out for
> discussion, that too would break the web.
>
> At the present time, we have a horrible mix of sites that test for user
> agents and infer capabilities, and sites that test for capabilities and
> infer behaviors unrelated to those capabilities.  One solution to that
> (a solution that I gather that both you and I, Henri, want to avoid as
> much as possible) is to version the web.  The other is to decide what is
> the appropriate level of breakage is possible, and even desirable.
>
> - Sam Ruby

Shelley

Received on Monday, 5 October 2009 17:25:45 UTC