HTML And EARL

I started writing about the ERT thread in IRC, to Aaron Swartz, and thought
it might be a good idea to send it here too. I'll include WFH, because I
mention him here, and I think he may be able to provide some valuable
insight.

<sbp> following from Al's rant on ER: we could come up with some subset of
RDDL, that we could do XRDF/EARL =XSLT=> RDDL/EARL
<sbp> then the link could be human and machine readable. Dunno. The ER
thread confuses me in a sense, because there is so much work being
repeated, and some things not being said clearly, and other things being
said too clearly
<sbp> I mean, there have been about 5 emails of discussion about putting
<meta/> into the body of an HTML page. What's that all about? IF you're
going to do it, just do it: write a module, create a namespace. Don't
expect people to be happy about serving it as text/html (William F.
Hammond!), don't expect people to implement it on a wide scale until they
are 110% satisfied that it will benefit them (financially?), don't expect
tools to process it unless you write them yourself. But it can be done.
HTML was built that way
<sbp> Of course, HTML is odd that way. Architecturally, it's absolutely
terrible, it could be retrofitted onto SGML, and the only reason to
retrofit it onto XML is to process it with XSLT. And it is retrofitting:
HTML moves (moved) faster than those technologies
<sbp> People write what they want done with it, rather than what they mean;
it's an inescapable fact. You either hack about with the world's quakiest
document architecture, or you wait and contribute to the new one, which
probably won't be any better (aren't I the cynic?)
<sbp> oops, it must have been chopped off, here's a paste: "don't expect
tools to process it unless you write them yourself. But it can be done.
HTML was built that way"
[...]
<sbp> HTML will always be hacked. It doesn't matter how good it is really,
because it's never going to be perfect for all uses. You have to make sure
that it's extensible, and that extensions don't bugger things up too badly
[...]
<sbp> how this relates to EARL: there's no way we're going to mandate a
link from HTML to "EARL" in any official capacity, because there's no way
to make that link official. We can only ever hack it
<AaronSw> Nah, use the <link> tag
<sbp> which isn't a bad thing necessarily, but it requires consensus, and
that's a difficult thing to get, especially when you have people with
different agenda's around
<AaronSw> that's what us RSS folks are doing
<sbp> <link> is a perfect example of a terrible hack
<AaronSw> especially now that Mozilla supports it.
[...]
<sbp> you RSS folks also forgot that classes and properties are disjoint,
so that doesn't particularly sway me
[...]
<AaronSw> Heheh.
[...]
<sbp> :-)
[...]
<sbp> <link>: why develop an inextensible linking mechanism that uses
tokens, and requires consensus, then hack in a profile attribute, not
define how it should be used, and then mess things up totally by declaring
that some joint properties have different meanings. Aaaargh!
<sbp> pushed it through: yuck
<sbp> so <link> isn't architecturally sound... but what's it used for?
rel="stylesheet". Ta da, it works. That's all that matters for HTML
[...]
<sbp> so we can say, "sure, use <metadata>some set of elements defining a
link to an EARL report</metadata>"... but we can't expect anyone to take us
seriously; even if we create the proper XHTML m12n family for it, or
whatever
<AaronSw> Why not? You're the onl one who won't take it seriously.
<AaronSw> Nobody else cares about architectural soundness -- they just want
it to work.
<sbp> what I mean is, it won't even work. Where are the tools? My whole
point *is* that no one cares about architectural soundness, and that HTML
has thrived because of that
<sbp> well, not my whole point; much of it
<AaronSw> Mozilla is a tool, it works. Same with iCab.
<sbp> yeah?
<AaronSw> yeah yeah?
<sbp> I mean, so what?
[...]
<AaronSw> So just do it and stop whining.

Cheers,

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Sunday, 21 October 2001 15:56:17 UTC