- From: David Sheets <kosmo.zb@gmail.com>
- Date: Fri, 25 Jan 2013 11:23:37 -0800
- 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:09 UTC