XML for Import/Export
Document Actions
An (extremely obvious) XML representation of the lens data would look something like the following. We have no schema for it, but it should be easy enough once finalized. Names are, as usual, not concrete [KEF: not finalized, not fixed in concrete?].
<contentselect>
<lens>
<title>Modules I Like<title>
<description>I read these modules and I like them. You might like them too!<description>
<type>selected<type>
<notify email="jccooper@rice.edu" />
<license src="http://creativecommons.org/licenses/by/2.0" />
</lens>
<creator> <!-- optional data about the creator of this listing; uses values from the owner's system account as default -->
<name>Cameron<name>
<!-- default: "J Cameron Cooper" -->
<description>System Architect of Connexions and author of Building Websites with Plone<description>
<!-- default: "Just a Connexions user." -->
<expandedName>James Cameron Cooper<expandedName>
<!-- default: "" -->
<logo src="http://jcameroncooper.com/logo" />
<!-- default: "" -->
<website src="http://jcameroncooper.com" /> <!-- default: "http://cnx.org" -->
</creator>
<content>
<entry>
<contentId>m13579</contentId>
<versionRange start="1.1" stop="" />
<notifyOnChange />
<!-- <implicitEndorseContents /> -->
<tags>
<tag>dog</tag>
<tag>adolescent</tag>
<tag>training</tag>
</tags>
<comments>
<comment><![CDATA[Absolutely right; the best way to deal with a dog is to treat it like a dog.] ]></comment>
</comments>
</entry>
<entry>
<contentId>col10143</contentId>
<versionRange start="1.1" stop="1.1" />
<notifyOnChange />
<implicitEndorseContents />
<tags>
<tag>ELEC 302</tag>
<tag>state space</tag>
<tag>puns</tag>
</tags>
<comments>
<comment><![CDATA[Hey, it's Featured Content!] ]></comment>
</comments>
</entry>
</content>
</contentselect>
Actually, this is more complex than it really needs to be. The non-entry elements could be flattened out, which would be more like the actual data we store. It would remove the problem with some of those elements regarding categorization. This would lead to tags like: lensname, lensdescription, creatorname, etc.
Atom is also probably quite adequate to express this, though we may need a stripped down version for plain export as well as one that has all the information expected in a usable feed. [KEF: This has two different use cases -- 1. A way to populate lenses 2. A way to find out what is in someone else's lens. Maybe OK to be the same, but should think through them.]
XML is not the only option here, of course. One can imagine INI type files that would do the same, though it seems to be too complex and variable for a reasonable CSV.
Re: XML for Import/Export
Such a representation could be a
(1) feed, for external tracking of a list
(2) export, for getting the data out in an appropriate format for editing and getting it back in
The two may not be compatible, but could be closely related.
If by flattening out attributes you also mean taking values of attributes like lens/notify/@email and making them character data child content of the leaf element, I agree (also with creator/logo/@src and creator/website/@src).
If entry/notifyOnChange expresses boolean true or false by its presence or absence, you might consider encoding that information as an XML attribute of the parent element, unless of course it needs to be able to hold attributes itself.
Atom would be interesting, and if it is adequate then it's attractive because it's a standard that others are using, and so the bar for others to reuse our content is lowered.
The flattening out bit even gives descriptions. The hierarchy in the XML here doesn't actually reflect the way we store the data; I just put it there because it looks more elegant. If we were to map more closely, we would have lensname, lensdescription, creatorname, creatordescription, etc, and no containing organization for that data as in the above example.
Forgive me if I seem pedantic--I'm not trying to be. I'm coming at this without having read the design doc, and I'm trying to get the mental model expressed by the XML. Perhaps I need to read the design doc first.
Of course, we could require some explicit value (True) to show on-ness. I think that's a bit fragile.