Overview
EchoExample has been in flux. There is disagreement between the use of the 2003-07-01 snapshot ("property-centric") and this version ("role-centric"). Is this an OpenPoll?
See also ElementsVsAttributes, SubTitle, EchoAPI r3, live attribute-centric example feed
Property-centric (in this context)
-
Definition: Using unique element names for each different meaning of a property.
Comment: When a new interpretation, specialization, or intent is needed for a property, a new element name is created for that property. It is intended that schemas and documentation relate similar or related types.
Role-centric (in this context)
-
Definition: Using a base set of elements names with a 'rel' (or 'role') attribute to indicate interpretation, specialization, or intent.
Property-centric:
-
Each defined meaning has a unique XML name.
-
XPath is simpler because it can ask for a specific property by name.
-
Mappings to objects, dictionaries, or hashes can base on just the XML name; a role would have to be stored seperately.
-
Less verbose.
-
More easily interoperable with RDF.
Role-centric:
-
XPath is simpler as a result of not having to look up/down a level each time.
-
A flexible way of noting variations of the same data type.
-
Fewer elements are easier to grok.
-
Can lead having roles that are nothing like the intent of their element name.
-
Doesn't aid applications in understanding new roles any more than new properties do.
-
Potential for namespace collision, if qualified names are not used.
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.
-
[DeveloperDude] +1
-
[SamRuby] +1
-
[DiegoDoval] +1
-
[ChristianRomney] +1
-
[AdamRice] +1. How's this for a rule of thumb on when to prefer attributes over elements? A. there's naturally a restricted vocabulary for their values; B. they give meta-data about the data between the tags; C. they reduce the number of unique tags (a benefit to the ViewSourceClan) and cut down on bloat without creating parsing problems. I like <url role="weblog">...</url> better than either <link role="weblog" href="..."/> or <weblog>...</weblog>. Data that fails to meet these criteria--a date, a URL, etc--may be better bracketed between elements than stuffed into attributes. As I see it, the element defines what kind of data it contains, and attributes gives hints as to how to interpret it. Following this logic consistently would argue in favor of <person role="author"> over <author> and <date rel="issued"> over <issued> (btw, can someone clue me in on the difference between rel and role?). Note that in most cases, unadorned <person> and <date> could probably be interpreted correctly anyhow--only in more sophisticated feeds would the attributes really be required for clarification. I think I'm starting to sound role-centric...
-
[BruceLoebrich] +1. To me, Adam makes a lot of sense and that's why I put my vote here, but I suspect, based on the examples, Adam's vote should be under role centric and that would put my vote there as well. The role centric example is much simpler with fewer elements to learn. A date is a date is a date. Defining it once and letting it serve multiple roles is both more straightforward and more versatile than than having a different name for each role a date can serve in a weblog.
-
[SimonFell] +1
[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.
-
[ZhangYining] From what I see, the element naming tries to follow the semantics rather than just data types; secondly, it's hard to have a clear cut on what "variation" is/is not, there could be many types of variations, and using attribute will probably open up too many variations, which in the end becomes confusing and requires looking up for the meaning.
[AsbjornUlsberg, RefactorOk] Most (maybe every) attribute values will have to be enumerations, that is a set of predefined values. It can't be another way. Having everything inside elements requires us to make new element types each time we need a new type of date, or a new type of title. That's too much work and will break people's systems. Instead, with an role-centric model, we can just make a new "rel" value on the <date> or <title> element, which gives the element a new meaning. This way I agree with AdamRice, although I feel that all URI's should be inside attributes as they aren't content -- they are references to content. Also, I can't think of another way to refer to external content that with an "src" attribute on the <content> element.
[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.
-
[AdamRice] I didn't mean for my model to be disconcerting, honest! You make valid points, and I suspect I would lose in any broader argument with you, but I will argue with one point you made on the ElementsVsAttributes page: "elements provide for a future point of extension whereas attributes cannot". Attributes can. If a limited vocabulary for attributes has been defined, and some people want to create new attributes for some custom purpose, outside aggregators that encounter these will have a better handle on the contents than if they encounter completely novel elements, in which case I assume they'll just discard them. That is, an aggregator encountering <date rel="fifthrevision">...</date> will at least know "it's a date" and perhaps be able to put it to some use, assuming the contents are formatted as other dates are. This strikes me as a gentler way to introduce new features, within limits.
-
[JeremyGray] One can extend elements through the addition of new child elements or attributes, but one cannot extend an attribute. As such, if one wishes or needs to add information detailing a particular attribute, one needs to do so through sibling attributes, or worse, through child elements of the attribute's parent element (ick). This difference is key to my earlier statement, and I do apologize for not explaining it in more detail and/or providing an example at that time. As for what I might call a datatype-centric element scheme, I'd much rather see an application process an unknown element as a date through the usage of schema information, even though such processing is of arguable use and is most likely a corner case. Supporting the corner case in this instance would be at quite a loss to the majority of usages and of users (not just the ViewSourceClan). If backed by a schema, an application will have no harder a time with issued or modified, and a human will benefit significantly. Additionally, as others have mentioned, issued and modified, whether as entry/issued or entry/@issued, offer performance benefits to boot. Don't take this the wrong way, but I'm really having a hard time seeing any benefit the approach you suggest. As prior art goes, there's a pretty clear history that properties have datatypes, not the other way around.
-
[AsbjornUlsberg] I'm sorry, but I think you are plain wrong when you're stating that elements are easier to extend than attributes. Of course, if the attribute has the same semantical meaning as the element, it's true, but that's not the case here. The case is wether we should chose:
<date rel="published">2003-08-11T14:54</date>
or
<published>2003-08-11T14:54</date>From what you're writing, I conclude that <date published="true" /> would be the same as <published>, and there I agree. Extending this "published" attribute is as difficult as extending a "publish" element. But if we move the level up a notch, we won't give the attribute, nor the element, a name which can't be extended. "published" is therefore replaced with "rel" (which is much more generic), and when you want to extend the <date> element's range of semantical values, you just introduce a new attribute value. Introducing new elements each time you want a new type of date is just plain stupid, and this design is one of the main reasons RSS is so terrible as it is, imho.
[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.
-
[JeremyGray] Except, as I've already argued, that the same thing can be achieved through schema information without resulting in the kind of under-specification that would result from having a role attribute that one could and would assume to take on any value one wants to assign to it. If this is a goal of the project, its not one that has been clearly stated anywhere that I've seen. What I have seen consistenly mentioned, however, is that the format should respect prior art where possible and should provide those working with it with a spec that is as clear and simple as possible. To be absolutely clear, however, there are times and places where an role-qualified approach may be best. <content> is one example. <link> may well be another, given the prior art it respects.
[AsbjornUlsberg] Describing functionality and types through Schemas is all well, but many Echo parsers won't use Schemas. Hence, they will rely their interpretation of a given element upon what meaning a programmer has given it. <date> will be interpret as a date, no matter what "rel" says it is. It is a date, and you don't need a schema to understand that. You need to understand the value of the "rel" attribute to understand what kind of date it is, but that's not essential.
When a parser meets the <wibble> element, it won't know what to do. Should it display the contents? Should it ignore the element? Should it allow entries to be sorted by it? Should it be indexed? Should it be searchable? Such questions are impossible to answer unless you read the specification or the schema. Instead, if it was <date rel="wibble" />, the parser knows "this is a date" and can handle it as such. It can allow the user to sort entries by it, it can filter entries based on it's content, it can put it in it's internalt "date-index", etc. And it can do this without any programmer's intervention, without looking at schemas and without reading any specs. It's done automagically.
[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.
-
[JeremyGray] Perhaps you have misunderstood me. I have already stated on a number of occasions that I am not against reasonable use of attributes, and have even presented a number of reasons why attributes are desirable over elements in certain situations. I have never argued against the things you seem to be claiming I have. I have made and will continue to make precisely two points:
-
elements can be extended whereas attributes cannot, so side with elements when future extensibility is desirable
-
the use of elements like <date type="foo"> as a replacement for datatyping which should be performed by documentation and schemata is likely to cause more problems than it solves.
-
[AsbjornUlsberg] I don't understand this "attributes cannot be extended"-statement of yours. Attributes can be extended just as much as elements (only, they cannot have children), but attribute-values can be extended incredibly much easier than elements. When speaking of extensibility, attribute-values does it much cleaner than elements.
-
[AsbjornUlsberg] Who's said anything about replacing schemata and documentation? Is it wrong to give an element a name which reflects its type, even if the type is given in a schema?
My only point which could possibly (and incorrectly) be perceived to act against flexibility is with respect to using elements like <issued> over elements like <date type="issued"> when it comes to simple types where schema information and documentation are sufficient for code and the resulting XML is far better for ViewSourceClan consumption and therefore adoption.
-
[AsbjornUlsberg] I agree that an element-centric format would be ideal for the ViewSourceClan, but even if we should try to leverage and make things easy, we can't just follow the ViewSourceClan's wishes. We have a higher goal than just satisfying them, and this will make the format a bit less self-explaining, but on the contrary, it will be richer, more extendable and better. Also: Who said the ViewSourceClan can't read attributes?
Now that I've reminded you of my points, could you perhaps clarify yours? I fail to see anything that is mutually exclusive or otherwise in conflict.
-
[BruceLoebrich] My intent was not to represent or attack your overall positions, but to address the slippery slope argument and present my views on flexibility. The Attributes vs elements argument is a red herring. Roles won't be extended and can be either. I believe author/contributor is less flexible than just having contributor with roles. I believe the same for created/issued/modified vs date and link/id/weblog/homepage vs url even though they are not complex structures. End users like myself want a small number of flexible core elements. I don't want to have to use extensions/modules/namespaces, let alone write my own. Read AdamRice in property-centric and RussellBeattie in role-centric for far more eloquent summaries of my view. I'll follow Russell's lead and put up my own example shortly.
-
[JeremyGray] I think we're getting our wires crossed here. I did not perceive your post as an attack. I just didn't see your comments as mutually exclusive or otherwise in opposition to my own, and asked if you could clarify. Let's try to move on. I feel it is safe to say that both of us want reuse and extensibility. I also think its safe to say that both of us would agree that while there are good places to use attributes (e.g. types of content, role qualifiers for appropriate element structures such as that of a contributor, etc.) elements are a safer bet as they leave room for future extension through child elements. If you disagree with these statements, please let me know. Otherwise, if we're in agreement, our time is better spent whipping up examples like Russell has done. (My schedule doesn't permit me to do this at present, but I'll try to get around to it within the coming days)
-
[AdamRice] I think we're in agreement pretty much. Some mooted tags, like <weblog> seem excessively specific, but clearly, there's no bright line marking off the "sweet spot of specificity". And there are some tags, like <issued>, where I have a hard time imagining how that would ever be extended or subclassed, but A. you say there are performance benefits to treating it as an element, and B. just because I can't imagine it doesn't mean it won't happen.
-
[JeremyGray] Yeah, I'd like to see things like <weblog> handled via a post-1.0 extension module, but I am just one person of many, so if the group decides its necessary I'll go along.
-
[AsbjornUlsberg] Do you mean the entity and type weblog now, or do you mean the XML-element? Having a separate <weblog> element over <link rel="weblog" /> can't be defended, imho.
-
[AsbjornUlsberg] When saying "extension" I take you are talking about extending the data model (by adding sub-elements and such) and not just extending the semantical meaning or type of the entity (be it element or attribute)? If so, yes: elements are easier to extend model-wise, but not value/meaning-wise. Elements and attributes have different purposes, and I believe attributes are much better used when just extending the meaning of an element, and not the whole model. If the model should be extended, you should of course use elements, but we're not talking about extending the <date>, <author> etc. model, we're talking about specifying the meaning of these.
-
Therefore, I believe it should be <date rel="issued" /> and not <issued> as it's very unlikely that the entity of "issued" will ever need sub-elements or other extensions in the model.
-
[AsbjornUlsberg] The almost XML-equivalent format Enamel is based solely upon elements, henve attributes don't exist. The format is terser and less ambiguous than XML, and I would like to see Echo in Enamel some day. But as we are modelling this format based on XML, I find it dumb not to use attributes. If you hate attributes, don't use XML.
-
[AsbjornUlsberg] I'm looking forward to seeing an example, Jeremy, because I'm kind of puzzled and confused in what your statement really is, and how you'd like the format.
[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.