James Snell wrote:
I like the fundamental idea here, but there are a couple of issues:
1. There needs to be a clear description of what a profile is. 2. There needs to be a clear description of how profiles are defined
3. There needs to be a clear description of how profiles are handled
[...]
While this has the potential to cause a significant update to the current document (something I'm hesitant to support), the current @version is meaningless as is and really should be drastically improved. Something like the following would be far more useful.
<feed profile="syndication">...</feed> <feed profile="archiving">...</feed> <feed profile="aggregation">...</feed> ...etc
I'm -1 on this pace.
One concern I have is that I don't want to see feed data constrained according to usecases (ie system monitoring); that makes the data less useful and goes down the route of publishers telling clients how to write their applications or making assumptions on how data will be processed downstream. While I believe that claiming Atom is a container for metadata is good, I doubt that profiling represents a more flexible approach - it moves us away from agents coordinating together to agents enforcing policy on one another via a profiling mechanism.
The place to put such constraints is on the range and domain of the metadata properties or in themed extensions - RDF clearly gets this right as do RSS1.0 modules. I have doubts about profiles will work out as they seem to range over the entire feed rather than an item of metadata.
As for @version being meaningless; it's not. It's sufficient for someone to swap in a code handler by switching on type. It might not have any forward or back compatible semantics but it is does signify wrt other versions. The @profile (as presented above) has no more or less meaning that @version.
cheers Bill
