OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Blueberry is not "closed" (was: Closing Blueberry)



Title: RE: Blueberry is not "closed" (was: Closing Blueberry)


> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
> Sent: Friday, July 20, 2001 6:30 PM
> To: xml-dev@lists.xml.org; www-xml-blueberry-comments@w3.org
> Subject: Re: Blueberry is not "closed" (was: Closing Blueberry)
>
> I believe it's World 2 (well, not everybody, but enough
> people to cause lots of aggravation and unnecessary hassle)
> unless we design the spec and the software so that only
> people who need to use Blueberry do use Blueberry.

I doubt if I use more than 10% of the features of Word, or Excel, or PowerPoint ... or even XMetaL, or XSLT, and so on.  The furor over Blueberry seems disproportionate: I'm sure we all endure lots of aggravation and unnecessary hassle every time Windows  or a web browser is "upgraded" with even more features that most don't have any use for. Nevertheless, almost everybody gets the "upgrade" sooner or later (like when they buy a new machine). The hassles are just another thing most have learned to cope with, and reluctantly acknowledge that Moore's Law has made the virtues of universal interoperability more salient than the evils of bloat.

I'd be a lot more sympathetic to those fighting against the aggravation and hassle that Blueberry's additional complexity will presumably bring if those people were just as diligent in fighting against all the other aggravations, hassles, and complexities useful to only a small minority of users that are already rampant in the XML world.  The XML community has managed to more or less cope with the transition from a world of one clear, simple 40-page XML Recommendation in 1998 to a world of literally thousands and thousands of pages of difficult, partially-contradictory XML-related Recommendations.  I have done my fair share of bitching and moaning about this, heaven knows ... Nevertheless, in a world of XML specs where there is no consistent interpretation of how namespaces really work, what parts of XML syntax are significant and what is "sugar", when different specs assume different processing orders, and few even claim to understand what the "post validation infoset" really is ... it's hard for me to get worked up about tweaking a couple of productions to get the Unicode NEL character treated as a newline.