W3C home > Mailing lists > Public > public-html@w3.org > January 2013

(wrong string) €™s polyglot possibilities (Was: The non-polyglot elephant in the room)

From: Alex Russell <slightlyoff@google.com>
Date: Sat, 26 Jan 2013 13:04:44 -0500
Message-ID: <CANr5HFW+kVRaEAxUDUgQo4NUoqHfF_9g5yuY=HgokBi_07Cs2w@mail.gmail.com>
To: David Sheets <kosmo.zb@gmail.com>
Cc: "www-tag@w3.org List" <www-tag@w3.org>, "Michael[tm] Smith" <mike@w3.org>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, public-html WG <public-html@w3.org>
On Jan 25, 2013 11:08 PM, "David Sheets" <kosmo.zb@gmail.com> wrote:
>
> On Fri, Jan 25, 2013 at 5:50 PM, Alex Russell <slightlyoff@google.com>
wrote:
> > On Jan 25, 2013 7:36 PM, "David Sheets" <kosmo.zb@gmail.com> wrote:
> >> Do you feel that the polyglot document does not help publishers
> >> understand the (X)HTML syntax?
> >
> > This is the core question worth answering, and as far as I can tell
from the
> > responses here, I have no reason to think that polyglot markup aids
> > understanding. It lacks the signage that clearly html or XML documents
> > provide and without that clarity, its value seems washed out beyond
> > recognition.
>
> Polyglot documents are valid HTML documents with additional constraints.
>
> How does this decrease clarity more than lenient (or conformant) HTML
parsing?
>
> >> I believe that the polyglot document serves precisely this purpose.
> >>
> >> Do you feel that the polyglot document hurts long-term viability of
> >> the standards?
> >
> > I don't know, but it does impose constraints without demonstrated value.
>
> It imposes constraints on document representations which are harmless.
> Do you acknowledge *any* demonstrated value from polyglot? Or do you
> feel that every argument I have made is somehow lacking? You have
> offered no standard for "demonstrated value" despite my repeated
> request.
>
> What constraints does it impose on the standard? Why are those
> constraints, if any (waiting...), undesirable?
>
> >> I believe that the polyglot document decreases fragmentation and
> >> guides spec authors to more sane rules.
> >
> > We disagree.
>
> You believe it increases fragmentation? It is does not effect
fragmentation?

It does not affect it for the previously cited reasons of signage and
contract writing.

> You believe it does not encourage sane rules? It has no effect on sane
rules?

That is correct. It lacks a mechanism to say " this is danger than the
other thing" without multiple processors.

> What specific issues do spec authors have with the existence of polyglot?
>
> >> Do you feel that the unelected, top-down structure of HTML
> >> standardization should be given greater leeway to further fragment
> >> implementations and introduce special cases? On what grounds?
> >
> > Yes. Because HTML is what gives the web value.
>
> My understanding is that a loosely-coupled, evolvable system of
> interoperable standards, hyperlinks, a uniform resource identifier
> syntax, and extensible formats and protocols are what give the web
> value. With only HTML markup, we'd have a pretty boring system. I
> think these are some general principles of the technical architecture.
> HTML uses these principles and is very important but is far from the
> whole story. All deployed web standard software (servers, browsers and
> XML processors alike) contribute value. Should we encourage
> monoculture or allow diversity?

I think at this point it's clear that you care about something other than
the interoperable web that we've collectively built. The web exhibits all
sort visibly valuable diversity right now. That your preferred version of
"diversity" isn't winning does not seem a TAG problem.

> What specific, real costs does polyglot impose on HTML's development?
>
> Do you have a replacement for XML you would like to offer? Do you
> believe XML should be deprecated?
>
> What harm will the web experience if polyglot becomes a REC?
>
> Without an enunciated understanding of both costs and benefits of
> polyglot, I fail to see how you or anyone else (myself included) can
> render a rational positive or negative judgement on its suitability
> for REC. Right now, I have several compatibility and simplicity items
> in the "pro" column and 1 questionable syntactic item (HTML tags
> should allow "/") in the "con".
>
> Please, help me compile a comprehensive accounting of specific pros and
cons.
>
> Thanks,
>
> David
Received on Saturday, 26 January 2013 18:05:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:36 UTC