UserPreferences

PropertiesVsRoles


Overview

EchoExample has been in flux. There is disagreement between the use of the [WWW]2003-07-01 snapshot ("property-centric") and [WWW]this version ("role-centric"). Is this an OpenPoll?

See also ElementsVsAttributes, SubTitle, [WWW]EchoAPI r3, [WWW]live attribute-centric example feed

Property-centric (in this context)

Role-centric (in this context)


Property-centric:

Role-centric:

Choices

Property-Centric

[AaronSw] The property system has a clear, easily-understandable model.

[MarkHershberger] Using elements [for properties] is simpler, it is clearer what is allowed and what is not. If attributes [roles?] are used, then the DTD or schema _must_ be used to produce a valid feed. Property-centric design also makes XPath simpler.

[TimBray] <title rel="subtitle"> really seems excessive. The 0.1 snapshot hit a sweet spot, except for a bit of bloat.

[GeorgBauer] As I said before, I prefer property centric with sparse attribute usage. Elements for content, attributes for technical descriptions of that content (like the type attribute in the content tag). But don't overload context of elements by using attributes (like the rel attribute does)!

[JeremyGray] While I feel (and have stated on ElementsVsAttributes) that attributes have definite value when used appropriately, I lean towards [unique] elements [for properties]. What surprises me is that the role-centric option presented isn't really attribute-centric as I would have guessed before clicking the link. I expected to find things like <entry issued="2003-07-11T06:42:00Z" ...> not <date rel="issued">2003-07-11T06:42:00Z</date>. ["Specific-Element-Centric" vs. "Generic-Element-with-qualifying-attribute-Centric" perhaps. :) DeleteOk? -- KenMacLeod] While I can see some value in the "Role-Centric" approach, I think it would lead towards underspecification in much the same way that <content> elements with arbitrary MIME types do (i.e. people assuming they can do <date rel="fifthedit">2003-07-12T08:35:00Z</date>). Heck, I have to say I would be much happier with <content> elements with MIME type attributes (which are property-centric with data-type qualification) than I would be with <date> elements with attributes as shown in the current sample (which are data-type centric with property qualification, a strange and different animal, indeed).

Role-Centric

[RandomPerson] I agree with Russell; in addition, I think the XPaths would be easier to assemble as a result of not having to look up/down a level each time.

[RussellBeattie] I agree Attributes are ugly, but I think there needs to be a more flexible way of noting variations of the same data types: Title/subtitle, weblog/homepage/email/etc., created/issued/modified, and more. Attributes make elements easier to grok: <date type="issued"> is much clearer than just <issued> which you'd need to look up to see exactly what was needed. If attributes are nixed completely (which it looks like it will be), it would be nice to see a bit more hierarchy included instead. Like <dates><created>2003-02-05T12:29:29Z</created></dates>. It seems redundant, but to me is clearer.

[AsbjornUlsberg, RefactorOk] +1

[DannyAyers] I don't have a problem with the basic idea of a role-centred approach, but there are dangers. As an extreme example of this approach see the <guid> in RSS 2.0 - the data type of the element switches between URI and string dependent on the isPermaLink attribute. This is *not good*! (validation pretty much goes out of the window for a start). I think if used, the role attribute should be a gentle human-semantic modifier, nothing more.

[AsbjornUlsberg] Of course, Danny. The element defines the type, the attribute defines it's semantical meaning. Anything else will just muddle things up.

Discuss

[JeremyGray] To BruceLoebrich and RussellBeattie: This data-type centric approach is quite disconcerting. This isn't at all like saying <content type="mimetypegoeshere">, its like saying <xml type="content">, at which point one can easily argue that each and every element in the standard can be expressed in that manner. Or would that be <xml type="content" secondarytype="mimetypegoeshere">. Or would that be... This is one hell of a slippery slope.

Data-type centric elements aren't going to help people learn and understand the spec. They are going to help confuse and disillusion people. Good getting started guides with solid examples, reference material will help learn and understand the spec. A schema will back it all up.

Note that I'm not saying that <content type="mimetypegoeshere"> shouldn't exist - it operates at an entirely different level than this, as it is "property-centric", "intent-centric", whatever you might like to call it.

[JoeEnglish] I don't think datatype-centric markup helps much in the way of extensibility. If your aggregator encounters a previously-unknown element <wibble>2003-07-10T15:59:60-08:00</wibble>, it will have no idea what to do with it. If it's marked up as <date role="wibble">2003-07-10T15:59:60-08:00</date>, it still won't have any idea what to do with it (except possibly to tell the user that something -- not sure what -- happened then). One possible exception to this is link -- a reasonable default behaviour for links is to give the reader something to click on. A generic link element with optional rel and title attributes could subsume homepage, weblog, permalink, and could be extended to include trackback links, links to comment pages, and whatever else someone might want to point to.

[BruceLoebrich] To JeremyGray: I find the term data-type centric to be far more accurate description of my position than attribute [role?] centric, thanks. Suggesting this approach is a slippery slope resulting in attributes being extended with other attributes and/or child elements seems ludicrous however. This isn't OPML, attributes (and they can be elements instead for all I care) like role/type/class would never be extended. Such attributes are hints used to distinguish between otherwise identical elements. I already wrote about date, so let's shift to author and contributor. That's a pretty narrow view of syndicated content. If I'm a TV station with a feed, editor, producer, anchor, reporter, director, camera and graphics might be far more appropriate. All of these roles are people and require the exact same child elements. We can build a format that requires every non-weblog content producer to come up with their own namespaces or we can create one with the flexibility to meet real needs. I know I'm going to lose, but my vote is for flexibility.

[RussellBeattie] I've added my version of what a feed might look like on my page (click on my name). This might be a good idea for everyone to do so we can see visually what people think the feeds should look like.

[AsbjornUlsberg] I like your example very much, Russel. It's almost exactly what I've pictured and want.