[go: up one dir, main page]

Re: HTML and XML

On 16 Feb 2009, at 14:34, Julian Reschke wrote:

> Bijan Parsia wrote:
>> On 16 Feb 2009, at 12:06, Julian Reschke wrote:
>> ...
>> DTDs with errors in major coursework in the presence of oXygen and  
>> pretty extensive training is within the past few weeks.
>> ...
>
> Were the students told how to test their submissions?

Have you ever used oXygen? The testing is built into the editing.

I notice you didn't say whether you found it easier to believe that  
my graduate students earlier had trouble producing well formed XML.

>> Second, uhm, well isn't this part of the point? It's hard to  
>> evaluate these claims stripped of context. Prima facie, claims of  
>> ease of authoring (of any strict computer format) is the  
>> *extraordinary* claim, thus requires backing.
>> (Also, not all computers run IE :))
>
> Luckily enough most of the others run Firefox. Or xmlint.

Thanks for giving additional evidence in support of my point. You did  
not give, in your reply, a reliable procedure for testing XML well  
formedness for many people. I'll not that your instructions involve  
using a browser in a way that many (most) users of browsers would not  
expect to use it or a rather obscure tool. Furthermore, your  
instructions are incomplete, as I'm pretty sure that a .txt suffix on  
the file name for this content:
"""<test>
    <foo>dfdf<b>fd</foo></b>
</test ref="dfsdf>"""

will load it without giving any errors. (Checked, so it did.) And if  
I serve it with the right mime type, even the .xml won't help.

I reiterate that it is, prima facie, non-trivial in many computing  
environments to produce well formed XML.

>> I would think that the main point is that in isolation simplicity  
>> is not, itself, a reliable indicator of over all usability. I  
>> would be very interested to have good evidence that XML formats  
>> have good usability (and in what circumstances).
>
> I think the usability of XML depends on the knowledge of the people  
> using it.

Usability is always relative to a population, of course. That's my  
point above.

> Users authoring docbook or XSLTs do not seem have trouble with it.

Those are pretty expert audience, esp. the XSLT.

> On the other hand, users thinking that XHTML somehow is simply a  
> newer form of HTML, not understanding the underlying differences,  
> fail miserably.

I don't think that informing about  the differences is enough...it  
typically requires a tool chain switch.

But, uhm, this was my point. Assertions simpliciter that XML _is_  
easy are non-starters.

> In all cases though, *testing* the document using conforming  
> software will highlight errors early on.

In the DBLP case, where I was dealing with "XML" I did not generate,  
this wasn't true. As I said, having a standard parse mode that would  
give me a DOM to analyze (plus lots of warnings) would have been much  
better than what I had: Errors and no joy.

In fact, the problems tended to occur in elements I didn't *care*  
about. So, in order to extract some data, I have to fix all the well- 
formedness errors *then* use my XQuery?

Well defined error handling resulting in a sensible DOM would make  
XML *easier* to work with (though not necessarily easier to author  
correctly), at least for me. Given that lots of people have trouble  
generating well formed XML, coping with the results in a better way  
is very helpful.

YMMV.

Cheers,
Bijan.

Received on Monday, 16 February 2009 15:45:58 UTC