Subject: Problem with Metadata Elements (section 6.4)

From: "Thomas Broyer" <[email-masked]>
Date: Mon, 30 May 2005 09:13:54 +0200 (CEST)

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="text">By Thomas Broyer and al.</ext:byline>
<ext:byline type="html">By &lt;a href="http://www.ltgt.net/">Thomas
Broyer&lt;/a> and al.</ext:byline>
<ext:byline type="xhtml">
  <div>By <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:byline>By 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

---

From: David Powell <[email-masked]>
Date: Mon, 30 May 2005 10:38:36 +0100

> 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

---

From: "Thomas Broyer" <[email-masked]>
Date: Mon, 30 May 2005 14:28:45 +0200 (CEST)

David Powell wrote:
>
> Quoting Thomas Broyer:
>
>> The problem come when I use a "plain flowed text" and can then omit
>> the "type" attribute:
>> 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.
> 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