2006/4/28, Andreas Sewe <[EMAIL PROTECTED]>:
The way I prefer to think about Atom and metadata is as follows:
- Every resource has editable metadata field like author, updated, or
summary (which incidentally are all Atom elements ;-)
- Atom Entries are capable of containing their metadata inline
- All other types of resources store their associated metadata
externally in Atom Entries
I really don't think it's a matter of storage.
I've been told that MacOSX's filesystem supports a notion of "file
attributes" (there're accessible using commands like "setattr" and
"getattr" in a shell console). Typically, this metadata is stored at
the filesystem level, and an AtomProtocol server could just build an
Atom Entry out of them.
WebDAV has the notion of properties on collections and their members.
WebDAV servers should allow clients to add/update any property they
want (they're called dead properties). Any WebDAV server can expose
embedded metadata as live properties accessible with
PROPFIND/PROPPATCH. A WebDAV-based AtomProtocol server could build an
Atom Entry out of the "file" properties.
Subversion also supports properties on files and folders (whether or
not you use the WebDAV/DeltaV binding).
Conclusion:
There are "files", there are metadata about them. Metadata can either
be embedded in the "file" or be stored externally. In the
AtomProtocol, any "file" must have an Atom Entry representation;
either it is its "primary" representation or it is derived from its
(external and/or embedded) metadata.
Note that "file" might be a BLOB in a database if you want.
(Note for RESTafarians: I've used "file" instead of resource and
representation, because metadata are not embedded in resources but in
their representations, and there can be metadata about resources and
metadata about their representations ; I thought "file" was easier to
understand)
--
Thomas Broyer
