Richard,
Apologies for the tardy response - I have been busy organising our presence at the Cloud Computing Expos in Prague and London on 18-19 and 20-21 May respectively (hope to see some of you there).
No worries - you have plenty to do as well, I'm sure... I agree with much of what you wrote in response. The bit which I disagree with most is on the links, and is a symptom of defining from XML first. E.g.: [Exhibit A]
link|||/47bb7df8-587e-47fa-bd89-6f2f81c14b19 [might become] link|/47bb7df8-587e-47fa-bd89-6f2f81c14b19 ... The blank fields are not [really] intentional, but there's a good reason for their existence. "link" is a generic Atom construct ... Again "link" is a generic Atom construct that can apply to anything... ...
[Exhibit B]
link|http://purl.org/occi/storage#device|Hard Drive|urn:uuid:4cc8cf62-69a4-4650-9e8c-7d4c516884df [might become] ide:0:0|4cc8cf62-69a4-4650-9e8c-7d4c516884df ... Sure this looks nicer/neater for us humans but it's less flexible and makes more work for the machines (and more importantly, programmers thereof). We need to find a balance and I'll certainly be working with you and Chris to do that.
In both cases here, you are using an Atom construct to define the structure in non-XML, as well as XML, formats. That's a mistake to me - our XML, JSON and TXT formats should all share the same nouns, verbs and attributes, and should also be automatically translatable into each other, but beyond that each should be well designed in their own right - I don't want to see things which look awkward in the JSON or TXT and be told that this is because they're mirroring Atom XML constructs. I don't believe this will make JSON or TXT either less flexible or more work for machines - to the contrary, I believe it's easier to parse if you don't have to have rules like 'always ignore ||| which is just there as legacy from the XML'. Yes, this will mean a little more work for an automatic translator between the formats, but that's code which is written once at most, whereas a typical users will start using a single format and find it easier if this behaves as naturally as they would expect that particular format to do. Cheers, Richard.