Here is at least one more blog reference to Danny Ayer's book. (re: This first reference.)
I just got it recently and so far so good. A variety of topics and apparently useful core information.
Another good book seems to be Developing Feeds with RSS and Atom, by Ben Hammersley. That one seems to stay more to the core though I've barely cracked either of them.
At least two more with similarly sounding titles are on their way.
Update: Brian Jones has a blog with more information. Not a whole lot more yet, but more. For example the default stroage will be zipped XML. The XML will be "fully documented". A royalty-free license is mentioned with no hints as to what it provides. However on their press site comes this encourage news...
PressPass: Won't this make it easier for your competitors to copy Microsoft Office?So now I mainly wonder a few things...Sinofsky: Certainly this will make it easier for other developers to use our formats to build solutions that don't require Office. However, the ability of other technology providers to use the new file format to integrate their solutions with the Microsoft Office System is an important and frequently requested capability by the industry. We feel it's to everyone's advantage to respond. Customers also know that the true value of a desktop application is not the format in which data is stored but the full breadth of capabilities offered by that application, along with the quality and security of the user experience that it provides.
What does it mean these days to anyone knowledgeable enough to care to say that you store your data "in XML format" without saying anything meaningful about what that format actually is.
My interpretation of this contentless "news" about content is that it serves as FUD given the recent ballyhoo about OASIS and the Open Document format. I have seen no other meaningful information to suggest an alternative explanation.
Unwittingly the typical customer says, "Why switch to another office suite when Microsoft is also publishing 'in XML format'".
A tag line found on Danny Ayers blog...
Tags: hReview, microformats, microformat, rdf
Is there something concerning about this?
Mark Baker suggests about web description languages...
I generally think it's a bad idea to describe the data produced using a schema since schemas generally (DaveO's excellent extensibility advice notwithstanding) change foreseeably over time, and I don't want a change in the schema produced by a service breaking clients if I can help it. Instead, I'm more a fan of simply using a media type as a name for an open-ended sequence of backwards-compatible schemas (think "text/html" vs. HTML 2.0, 3.2, 4.01, etc..), as well as, of course, associating an extensible processing model to that media type to accomodate as many unanticipated extensions as possible over time.
Chris Sells makes a, er, "point"...
The thing that I really need that I'm missing is for my computer, and everyone's computer that I'm conferencing with, to have a stylus attached to their screen. The "let's just sketch something on the white board" is really the last remote collaboration frontier 'til we get some kind of fancy "virtual presence" stuff going.Good point. A freehand drawing and handwriting surface should "just be" part of the standard desktop.I don't mean that every computer needs to be a Tablet PC. Frankly, I'm not very productive on a computer that doesn't have a keyboard. But, I want to be able to sketch something right on my computer screen like a tablet can and instantly share it as I do so. Plus, and here's the rub, I want everyone else to have a stylus, too. If they don't, they'll turn to the white board and I'm out of luck across the great divide.
Martin Fowler looks for a rigoruous definition of "agile" software development practices, and measurements of which practices may be more effective than others.
...agile methods fundamentally expect teams to decide what process to follow and furthermore expect teams to actively and regularly change their process. Any attempt to define a rigorous process that can be tested for conformance runs contrary to this philosophy...The first part of the quote above *is* the definition of agile in my experience: if the team decides what to follow and actively improves their performance then they are "being agile". The second part of the quote becomes less interesting in this case.How can you do a survey on whether agile methods are more effective that alternatives, or whether Extreme Programming is more effective than Scrum, when you can't get a clear definition of what Scrum is in the first place? If a client wants a system built using Extreme Programming how can they tell if it's really being done?
Comparing textbook definitions to each other is less interesting than comparing an agile team to its own history. If the team is improving then that's the goal.
A useful excercise for a team when considering their own agility is for them to explicitly describe their feedback loops (plural), who should be in their loops for which information, and how are decisions (and their timing) made in each of these loops.
(Hint: many problems in an organization of any size occur, and are therefore obscured, outside the boundaries or on the border of the "team" per se.)
Using this approach Scrum, XP, and other approaches become possible sources of improvement and less a necessarily well-defined instruction manual that can be graded independent of actual performance.
