- From: Elliotte Harold <elharo@metalab.unc.edu>
- Date: Tue, 17 Feb 2009 06:21:58 -0800
- To: Bijan Parsia <bparsia@cs.man.ac.uk>
- Cc: www-tag@w3.org
Bijan Parsia wrote: > The programs submitted were only .class files. When *decompiled*, it > results in syntactically incorrect java files. Obviously, there are lots > of possibilities here. Perhaps your decompiler was at fault then, and perhaps your students were more honest than mine. > And we aren't arguing it here. The question is not whether we accept > imprecise input, but whether we make the (low level) handling of all > byte streams precise. That's what HTML5 strives for. That's how I > understand the XML5 effort. The low level handling of byte streams in XML 1.0 is precise; far more so than in most other formats. It's just that sometimes that low level handling leads to a mandatory decision to halt parsing and not report any further content from the stream. I am skeptical anyone can do better than this. > This is evidence that you are still confused about the matter under > discussion. Just as an application that depends on its input conforming > to a certain schema cannot meekly accept arbitrary well formed input, so > too an application which depends on the data being wellformed (but, > perhaps, described in prose) cannot blindly accept arbitrary byte > streams as input (or at least as input on par with well-formed input). > But many classes of application (and of user) need to have more > elaborate handling of various classes of error. One way to improve the > situation of such applications when using XML is to define the data > model that results from parsing, as XML, arbitrary input streams. 1. I don't believe an application should depend on its input conforming to a certain schema. 2. I do not believe defining a data model that results from parsing, as XML, arbitrary input streams would improve the situation of such applications. In particular I believe it would sweep real problems under the rug. I believe it is better to fail sooner than later. A data model more complex than a byte array that accepts arbitrary input streams will hide real problems on both the consumer and producer sides. It would be a step backwards, not a step forwards. > Well, if I accept your standards of evidence, how on earth do you expect > to convince me of anything? We have disparate experience and we are not > colleagues (e.g., you evidently don't treat me as such as you > systematically dismiss my experience). Build something better. Convince people to use it. Show in practice that it can solve problems XML does not; and that it is sufficiently better to pay the cost of transition. Argument alone will not do it. > I don't understand why it's important to you to engage in argument if it > matters naught to you the content or the fact of the argument. Why do > you even bother to engage in discussion rather than just evaluting built > things as they come alone? It is a puzzle. Perhaps I hope to avoid you wasting your time, and encourage you to devote it to something more likely to succeed. Personally I've seen so much money and talent and years of peoples' lives wasted on XML projects I knew were doomed to failure. Tilting at windmills I suppose. Sometimes you just have to prove these things to yourself, and learn from experience. And perhaps you'll be the exception. However I'll warn you that the track record is not good. Of the hundreds of efforts to improve on XML, I'd say there's one, arguably two, cases that have achieved some level of adoption. You've shown nothing to indicate that your format will be one of the exceptions. -- Elliotte Rusty Harold elharo@metalab.unc.edu Refactoring HTML Just Published! http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA
Received on Tuesday, 17 February 2009 14:22:35 UTC