Re: HTML and XML

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