[
Lists Home |
Date Index |
Thread Index
]
> > Some cleavage :
> > http://www.intertwingly.net/wiki/pie/NamespaceDiscussion
>
> Is that cleavage a joining or a coming apart?
Heh, hopefully the former.
> > Note that the namespace cleavage has only appeared in this
> "simple" branch.
>
> It seems that elsewhere technical judgement was suspended insofar as
> namespaces were accepted without much thought (that wiki being
> another place where I'm waiting for a good argument pro namespaces).
> At least I haven't seen any explicit consensus pro XML Namespaces
> doe Atom.
No, me neither. I personally think that XML namespaces are the right choice
here, but the process is very much at fault if the decision isn't made in a
clearly consensual way. (is consensual a word? - sounds smutty)
So I guess that page doesn't really have any influence on
> Atom syntax. What matters are the current test feeds (which to the
> man are namespaced), the blogs that filter the wiki noise, if you
> can call it a wiki, and the opinion of maybe 20-40 people, yourself
> and a few other on this list included.
>
> I may yet have to hack Perl...
Go for it.
>
> > The RSS 1.0 branch uses namespaces extensively even for
> relatively simple
> > feeds, using standard terms like those of Dublin Core. There it just
> > works...
>
> RSS1.0 uses XML Namespaces to tunnel URIs through XML for the
> benefit of RDF. Does the XML serialization really 'just work'?
Does for me ;-)
> > I wouldn't characterise those as much aspects of RSS practice, rather of
> > certain practitioners. I don't think the CDATA stuff is quite
> as bizarre as
> > it seems - the motivation is to use HTML markup for content, but without
> > namespaces and XHTML this leads to a bit of a mess.
>
> It sanctions sloppy production of markup Danny. That's the real
> world use case for RSS CDATA. The lack of namespaces and XHTML has
> nothing to do with it. You can make the effort tidy your HTML to XML
> - it's not that hard and cheapest overall when the producer does it
> instead of the consumer. Worst of all CDATA tunneling plays into the
> hands of legacy HTML engines with code bases dedicated to rendering
> gorp no matter - gorp rendition raises the bar greatly for an RSS
> client. Saying producing sloppy syntax isn't a bizarre need is no
> different to saying producing sloppy semantics isn't a bizarre need.
Sorry Bill, I'm 99.9% in agreement. If XHTML and XML namespaces were used,
it wouldn't be sloppy, but of course you're right - neither of these are
essential to tidy it up. All I was trying to say that the mess hadn't
appeared from nowhere, so wasn't bizarre in that sense.
> > there has been a continuous tug-of-war between developers that want
> > to do things as 'properly' as possible and those that want
> things to be as
> > 'simple' as possible.
>
> But we shouldn't confuse simple with simplistic.
Indeed.
> > There probably wouldn't have been any conflict if
> > 'simple' hadn't used underspecification as a tool.
>
> +1
>
> > The 'properly's have
> > often frightened the 'simple's when talking about standards,
> namespaces and
> > so on, and now the 'properly's are moving on with Atom. Meanwhile the
> > 'simple' RSS 2.0 wagons have circled around some good stuff but
> also quite a
> > lot of garbage.
>
> Not really. RSS users are understanding that 'simple' should mean
> simple - not technical debt, not deferred costs, not crapping on the
> next guy.
I'm not sure they are - some people appear to be still clinging to RFC 822
dates for a lot more than just backwards compatibility.
Cheers,
Danny.
|
