I'm posting this in lieu of a Pace - I'll put one together post-feedback (and once I've got my current batch of day-work out of the way ;-)
The PaceEntriesAllTheWayDown thread has been looking at similarity between entities at the Entry level of granularity. This is definitely useful analysis, whether or not any of these Paces is accepted. But I think there's also a lot can gained by splitting the Atom. There is plenty of prior art for recognising constructs in XML syntax, in the context of syndication it's provided by RDF/XML in RSS 1.0. There may not be general support for Atom as RDF/XML, but something like its grammar of structure is possible. The same kind of structural interpretation is possible without any commitment to any aspect of RDF. Amongst other characteristics, RDF/XML identifies resources, properties and literals based on the structure of the syntax. Atom has a virtually identical set of sub-atomic particles - the constructs with URIs, properties with literal values, properties which have URIs as their value. If Atom syntax is consistent in the way it expresses these (which should be a desirable thing in itself), then the same interpretation can be applied to extensions. Things with the same Atomic Weight (or rather position in the structure) are treated in the same fashion. I'm don't think PaceConstructAttribute is the way to go, I think it needs to be more transparent. But I reckon the rationale is good: [[ If an Atom consumer knows that an extension element follows the rules defined for a Construct that it already knows about from the Atom core specification, it may be able to perform some appropriate processing on it without knowing everything about the element. ]] I think PacePropertyDesign is heading in the right direction, though needs some fleshing out. I would be tempted to remove the RDF references - I don't think they're needed (maybe keep as purely informative). Cheers, Danny. -- http://dannyayers.com
