Not Invented Here

Joe Gregorio

Jeremy Gray on [atom-syntax] People have often argued that Atom should leverage existing web technology wherever possible but threads like this seem to repeatedly steer us towards re-invention, in a sense, of technology by lifting (and sometimes mutating) it into Atom when it could be leveraged more directly. As a few off-the-cuff examples of pseudo-NIH we have: the overlap of numerous Atom elements with those of Dublin Core, recent discussion regarding definition of and reference to elements for purposes of reuse that would be provided for at a specification level by RDF, invention of API/protocol solutions instead of profiling/extension of WebDAV, etc. Of course, there are times, places, and reasons to _not_ leverage a given technology A in the face of requirement B, but one can only pursue so much NIH before attempts at its justification wear thin. :(

This reminded me recently of Tim Bray's comments on OpenOffice:

The way that these guys store the data is massively, fiendishly, outrageously clever. They have their own XML tag set, which includes (in one namespace) all the basic word-processing, spreadsheet, and slide-show machinery. Then, for graphics they use SVG, for styles they use XSL-FO, for links they use XLink... you get the picture, they've invented the absolute minimum possible.

Update: I couldn't resist. Here is a short form of Mark Pilgrim's Atom feed, and here is the same information with as many of the elements moved into equivalent namespaces for as many equivalents as I could find.

I'm sort of vaguely curious: how would one go about leveraging all the beauty and joy of Dublin Core? I just don't have much experience with this stuff: all I really know about is RSS 1.0's use of dc:date. dc:date is whatever you want, "5th of June" is a perfectly valid dc:date, W3CDTF is only mentioned as "best practice". RSS 1.0 says it's dc:date, unlike DCMI's dc:date, is a W3CDTF and nothing but, but quite possibly without having noticed that W3CDTF says that anyone who uses it needs to profile it, to say what precision is required and allowed, and how to interpret missing precision. RSS 1.0 doesn't, so many people assume that the example is normative, and don't realize that 2004 is a perfectly valid RSS 1.0 dc:date with completely undefined precision beyond the year. So, err, what's the value in leveraging things like Dublin Core again?

Posted by Phil Ringnalda on 2004-06-08

How is defining a profile of an already existing element in Dublin Core more work than defining a new element from scratch?

Posted by Joe on 2004-06-08

First, a little nitpick with the example. IIRC, you can't put default namespace attributes in a namespace qualified element like dc:description in your example.

At the Atom Meeting, Eric Miller said using Atom's namespace for a lot of this stuff made sense, since we're restricting the acceptable values, in many cases.

WRT to the WebDAV stuff, I agree we shouldn't reinvent it. I just think it will go nowhere if we require its use at the most basic conformance level.

Don't you think the Atom community is currently taking a pretty a hard look at the existing drafts, looking for cases where we could re-use other work? I definitely feel consensus forming around removing binary stuff from atom:content.

Posted by Robert Sayre on 2004-06-08

"IIRC, you can't put default namespace attributes in a namespace qualified element like dc:description in your example."

You appear to have recalled incorrectly.

"At the Atom Meeting, Eric Miller said using Atom's namespace for a lot of this stuff made sense, since we're restricting the acceptable values, in many cases."

Dublin Core specifically states that you are to restrict the acceptable values in many cases. They usually say something like "Recommended best practice is to select a value from a controlled vocabulary"

"Don't you think the Atom community is currently taking a pretty a hard look at the existing drafts, looking for cases where we could re-use other work?"

This was just an experiment, not a proposal. I like to have a side-by-side comparison in front of me to base decisions on.

Posted by Joe on 2004-06-08

I think I did recall correctly...

"Note that default namespaces do not apply directly to attributes."

http://www.w3.org/TR/REC-xml-names/#defaulting
http://www.imc.org/atom-syntax/mail-archive/msg03903.html

Posted by Robert Sayre on 2004-06-08

There is a BIG difference between

"you can't put default namespace attributes in a namespace qualified element"

and

"default namespaces do not apply directly to attributes."

The latter being true, the former being false.

Posted by joe on 2004-06-08

Sorry, I'll try to be more precise. You can put them there, but the 'type' attribute in dc:description is not http://purl.org/atom/ns#type (it's not in any namespace), as I understand it.

Are you saying I'm incorrect, or that this doesn't matter?

Posted by Robert Sayre on 2004-06-08

You are correct that @type does not reside in the Atom namespace.

It also doesn't matter.

Posted by joe on 2004-06-08

"WRT to the WebDAV stuff, I agree we shouldn't reinvent it. I just think it will go nowhere if we require its use at the most basic conformance level."

No one is suggesting Atom require the use of WebDAV.  Atom uses only the methods from the HTTP spec without any need for WebDAV features at this time.  The methods from the HTTP spec are the core functionality in WebDAV, too.  On top of the HTTP-spec methods, WebDAV adds things like multi-user locking and transactions, things Atom users may need in the future.

If or when Atom needs those features from WebDAV, Atom is positioned to make a profile of WebDAV for Atom users just as it is making a profile of HTTP for Atom users today.

Posted by Ken MacLeod on 2004-06-08

See, I thought that the NEWRESOURCE stuff was specifically intended for collections.

// And that it was requiring that the PostURI be a collection resource.

It became clear later that even the WebDAV experts weren't in complete agreement on that.

Posted by Robert Sayre on 2004-06-08

I'm often reminded of my need to break down and get my blog up and running, something I've only been holding back on because I've wanted to build my own blog system as a way to dogfood my company's tech and I've been too busy with work itself to do that. :(

Nothing like being quoted on someone else's blog to really kick you in the butt. :)

Posted by Jeremy Gray on 2004-06-08

Funky Atom!

Posted by Randy Charles Morin on 2004-06-08

I wish WebDAV had a core profile we could use directly in Atom, without inventing our own API. E.g., the core of WebDAV should be something like what the Atom API looks like at the moment, so we could just use it and easilly apply the other ornaments of WebDAV in the future.

As WebDAV doesn't have such a core profile afaik, we need to build our own "core" API. If the community feels that the Atom API doesn't give enough functionality, we can either extend the API to be more WebDAV-like, or replace it completely with WebDAV. The current API and WebDAV could also co-exist quite nicely.

Posted by Asbjørn Ulsberg on 2004-06-08

comments powered by Disqus