Asbjørn Ulsberg wrote: > On Mon, 23 May 2005 08:54:32 +0200, Anne van Kesteren wrote: >>>> * 4.2.2 The "atom:category" Element >>>> Why is significant information hidden in attributes? That is bad for >>>> i18n and prevents people from defining the expansion of an >>>> abbreviation, for example. >>> >>> Minor flaw. It happens. >> >> I think you are rushing things too fast. It would be much better if we >> fixed this. > > I agree.
+1, drop the "label" attribute and make its value a child of the atom:category element. Some more wording would also be needed to explain the exact role of the "term" attribute. Couldn't its value default to the "label" when not present (this imply making it optional)? >>>> Can't we name them consistently? I'd suggest 'href' or 'url'. >>> >>> Nope. Too late. >> >> And this. > > +2. I have no opinion about atom:uri, it seems find to me but I'm not attached to it. @href gives an Hypertext REFerence to another, related, resource (alternate, related, self, feed, etc.), so -1 to changing its name. @src tells the Atom Processor where the content of the entry is located. I wouldn't be opposed to "href" in this case, but nothing else than "href" or "src". Other listed examples were about attribute vs. text node, I'm +0.5 to moving text nodes into attributes (in atom:logo and atom:icon) These are also common usages in many XML dialects (XHTML, XInclude, XLink, SVG, etc.) Many of these tend to use XLink when linking to or embedding external resources, so using XLink wouldn't bother me either (hey, some are talking about replacing atom:author|atom:contributor with Dublin Core, so why not?) -- Thomas Broyer
