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

Re: NUís polyglot possibilities (Was: The non-polyglot elephant in the room)

From: David Sheets <kosmo.zb@gmail.com>
Date: Fri, 25 Jan 2013 11:23:37 -0800
Message-ID: <CAAWM5TyuJxeBFp_sv2kVQL38NpmTT_3GDmQ6fnhTSPsFGKhZjw@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: Alex Russell <slightlyoff@google.com>, "Michael[tm] Smith" <mike@w3.org>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, public-html WG <public-html@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>
On Fri, Jan 25, 2013 at 4:55 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Fri, Jan 25, 2013 at 12:14 AM, Alex Russell <slightlyoff@google.com> wrote:
>> What am I missing?
>
> You aren't missing anything.

This statement contradicts the rest of your email in which you outline
what Alex is missing.

>> Under what conditions can the expectations of producers
>> and consumers of polyglot documents be simplified by the addition of
>> polyglot markup to their existing world/toolchain?
>
> 1) The producer wants to maintain a document as a single file of bytes
> on an HTTP server that serves from the file system.

Common.

> AND
> 2) The producer wants to serve those bytes as text/html to cater to
> the general publicóincluding IE8.

Common.

> AND
> 3) The producer wants to facilitate a non-browser consumer that
>   a) Does not possess a conforming HTML parser.

As far as I can tell, there exist many more solid XML parsers for many
more languages/platforms than solid HTML parsers. XML parsers also
tend to support distinct processing models that may be superior for
some applications e.g. streaming.

> AND
>   b) Possesses an XML parser or a non-conforming HTML parser that
> happens to barf less if the input is XML-like.

Common.

> AND
>   c) Is not seeking to consume Web content in general (as that would
> necessitate violating condition a).

Web services. Web applications. Web APIs.

> AND
>   d) Has a line of communication back to the producer in order to
> complain when the document inevitably becomes non-polyglot by accident
> as a result of an edit.

Inevitably? Document generators that aren't poorly constructed don't
have this problem.

If the publisher is publishing polyglot, we can assume they care that
they are publishing polyglot. Is communication especially hard on the
Internet?

> So a very narrow case.

Broadly compatible web document services is a *very* narrow case?
Libraries, case files, specifications, structured document systems of
any kind...

> Not worth a REC, in my opinion.

Is this opinion based on your above reasoning?
<http://www.w3.org/2005/10/Process-20051014/tr#q75> states that
publication as a Working Group Note indicates work has ended. How is
this possible when work on HTML The Living Standard and HTML 5.1
continue? Are you advocating that the W3C publish material that will
not be maintained? Wouldn't that be worse than either publishing a REC
or publishing nothing?

> A solution in search of a problem.

This is plainly false. You have given a set of constraints in your
message which polyglot satisfies marvelously. Other problems that
polyglot solves exist and have already been explicated in this and
other threads.

What is your motivation for advocating against polyglot? What harm do
you see it doing as a REC?

David
Received on Friday, 25 January 2013 19:24:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 25 January 2013 19:24:12 GMT