[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: rss regularis(z)ation
> > 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|