Problem with Metadata Elements (section 6.4)
I was discussing extensions offlist with Dave Powell and came to explain what I previously said on the list about Simple/Structured Extension Elements [1] when I thought I found a real problem with that. There have been much discussion last weeks about authors, contributors and bylines and bylines were rejected to extensions (and I'm +1 on that, that's not the point). So imagine I want to create such a byline extension. Ideally, I'd like it to be text that can be enriched with some markup. The obvious choice here is to reuse the Text Construct mechanism: it is already implemented in every Atom Processor so adding support for my byline extension would be made much easier than redefining a different mechanism, and of course it is homogeneous with Atom so better for users. So my ext:byline element MAY have a type attribute with value text, html or xhtml. When not present, it defaults to text. Depending on the type attribute's value, the content is plain flowed text, escaped HTML or an XHTML div. My byline extension then looks like the following, and is obviously a Structured Extension Element (as it comes in atom:feed, atom:entry or atom:source): ext:byline type=textBy Thomas Broyer and al./ext:byline ext:byline type=htmlBy lt;a href=http://www.ltgt.net/;Thomas Broyerlt;/a and al./ext:byline ext:byline type=xhtml divBy a href=http://www.ltgt.net/;Thomas Broyer/a and al./div /ext:byline The problem come when I use a plain flowed text and can then omit the type attribute: ext:bylineBy Thomas Broyer and al./ext:byline My extension becomes a Simple Extension Element when processed by an Atom Processor, and an Atom Processor having some generic support for Simple Extension Elements (which is really the intent of SEE) would change its behavior when processing it, which is not really wanted. However, I don't think I badly designed the byline extension, or this would imply that Atom itself is badly designed (and I don't think so). Are other people here seeing a problem with Simple vs. Structured Extension ELements or am I the only one? [1] http://www.imc.org/atom-syntax/mail-archive/msg15751.html -- Thomas Broyer
Re: Problem with Metadata Elements (section 6.4)
Quoting Thomas Broyer [EMAIL PROTECTED]: The problem come when I use a plain flowed text and can then omit the type attribute: ext:bylineBy Thomas Broyer and al./ext:byline My extension becomes a Simple Extension Element when processed by an Atom Processor, and an Atom Processor having some generic support for Simple Extension Elements (which is really the intent of SEE) would change its behavior when processing it, which is not really wanted. However, I don't think I badly designed the byline extension, or this would imply that Atom itself is badly designed (and I don't think so). I don't think that this is a big problem. The allowed syntax of Structured Extension Elements is defined by the designer of the Structured Extension. It is the designer's responsibility to ensure that Structured Extensions don't flip into being Simple Extensions, so they need to be designed in a way such that they have at least one child element or attribute. In this case the easiest way to do this would be to make @type mandatory even when @type=text is required. -- Dave
Re: Problem with Metadata Elements (section 6.4)
David Powell wrote: Quoting Thomas Broyer: The problem come when I use a plain flowed text and can then omit the type attribute: ext:bylineBy Thomas Broyer and al./ext:byline My extension becomes a Simple Extension Element when processed by an Atom Processor, and an Atom Processor having some generic support for Simple Extension Elements (which is really the intent of SEE) would change its behavior when processing it, which is not really wanted. However, I don't think I badly designed the byline extension, or this would imply that Atom itself is badly designed (and I don't think so). I don't think that this is a big problem. The allowed syntax of Structured Extension Elements is defined by the designer of the Structured Extension. It is the designer's responsibility to ensure that Structured Extensions don't flip into being Simple Extensions, so they need to be designed in a way such that they have at least one child element or attribute. In this case the easiest way to do this would be to make @type mandatory even when @type=text is required. Of course yes, but the extension then doesn't follow the same rules as Text Constructs, which are part of Atom, and it's bothering me. If I can't design my extensions in the same way Atom designed its markup, I think there is a problem... That's why I think the Metadata Elements (Simple and Structured Extension Elements) wording is too strong in the spec. The intent is (should be) to give a hint to Atom implementors providing generic support for name/value pair properties and to extension designers, not to enforce a particular behavior. Changing that would also throw away your problem (discussed offlist) with later allowing (e.g. in Atom 1.1) Metadata Elements in Atom elements where foreign markup is today just foreign markup, without any defined role. To summarize for other people on the list, David's problem was that if we don't define a role today for foreign markup inside Atom elements other than atom:feed, atom:entry, Person Constructs and atom:source, e.g. inside atom:link, then we wouldn't be able to define it later, because foreign markup that would have been used with Atom 1.0 don't necessarily follow the rules of section 6.4 and therefor won't be ok if Atom 1.1 says that atom:link's foreign markup children are now considered Metadata Elements. -- Thomas Broyer
