Look at that giant email. Seems to me that it's a debate taking place
for no discernable reason. There's no technical reason for the
placement of the attributes, and management has made it clear that any
objections are "irrelevant."
Hope that helps!
On 5/18/06, James M Snell <[EMAIL PROTECTED]> wrote:
David,
David Powell wrote:
> Tuesday, May 16, 2006, 4:50:03 AM, James M Snell wrote:
>
>> A few of the individuals on the WG had a problem with the placement of
>> the attributes due to various limitations of a few existing Atom 1.0
>> implementations.
>
> That doesn't accurately state my problem with FTE. My concern is more
> general than the compatibility with a specific Atom implementations.
> The fact that the MS feed platform exhibits the issue is just a
> confirmation that the issue is more than a theoretical concern.
>
My apologies for the misrepresentation. It was unintentional.
> An implementor that wants to /consume/ Atom (such as a feed API, or
> store), ought to be able to create an accurate implementation just by
> reading RFC4287. That document describes what properties entries,
> feeds, links, and extension elements have, and how they are
> represented in an Atom document. Using this it is possible to create a
> database schema or OO API that can represent feed data.
>
When I look at RFC4287 I see the following statements:
1.3 : "Some sections of this specification are illustrated with
fragments of a non-normative RELAX NG Compact schema
[RELAX-NG]. However, the text of this specification provides
the definition of conformance."
4.2.7 : "The "atom:link" element defines a reference from an entry or
feed to a Web resource. This specification assigns no meaning
to the content (if any) of this element."
6.1 : "Markup from other vocabularies ("foreign markup") can be used
in an Atom Document."
6.3: "Atom Processors that encounter foreign markup in a location
that is legal according to this specification MUST NOT stop
processing or signal an error."
6.4: "Atom allows foreign markup anywhere in an Atom document, except
where it is explicitly forbidden."
Further, the RELAX NG definition for atom:link is,
atomLink =
element atom:link {
atomCommonAttributes,
attribute href { atomUri },
attribute rel { atomNCName | atomUri }?,
attribute type { atomMediaType }?,
attribute hreflang { atomLanguageTag }?,
attribute title { text }?,
attribute length { text }?,
undefinedContent
}
atomCommonAttributes =
attribute xml:base { atomUri }?,
attribute xml:lang { atomLanguageTag }?,
undefinedAttribute*
undefinedAttribute =
attribute * - (xml:base | xml:lang | local:*) { text }
undefinedContent = (text|anyForeignElement)*
My interpretation of the text and the RELAX NG definition is that while
the specification does not assign any meaning to extensions of the link
element, it is nonetheless explicitly allowed.
It may have been a mistake, but the discussion of section 6.4 is
explicitly scoped *only* to child elements of atom:entry, atom:feed,
atom:source and Person constructs. Note that this section does NOT state
that ONLY those elements may be extended; rather, the section defines
the characteristics of two types of extensions that could occur on those
subsets of elements. The characteristics of extensions on other
elements in the Atom vocabulary are left undefined.
The definitions of the atomCommonAttributes (which allows any number of
"undefinedAttributes" and the definition of undefinedContent is very
clear on the point that extensions ARE allowed on Link. Such extensions
may not be semantically meaningful to RFC4287, but they are nonetheless
legal and a valid component of the Atom data model.
>[snip]
> What I see as a problem is that reasonable implementations will not
> preserve Atom documents bit-for-bit, so they will need to explicitly
> support this draft if they don't want to corrupt data by dropping the
> thr:count attributes. By the letter of RFC4287 there is no problem
> with the draft, but practically there is something like a layering
> concern if an extension requires existing conformant implementations
> to be changed.
>
Atom does not define any notion of "conformance". That is, there are no
requirements anywhere that define what aspects of the Atom data model an
implementation MUST/SHOULD/MAY support. It is, therefore, reasonable to
expect that different implementations will offer varying levels of
support for a variety of the core features offered by the protocol. For
instance, Atom's data model allows for multiple enclosure links. In my
Atom implementation, this is easily handled and exposed by the API; in
Microsoft's implementation, however, only a single enclosure is exposed.
Some implementations do not expose any link other than the first
"alternate" link that they happen to find in the entry.
I'm sure there are countless such examples. Some implementations don't
use/preserve the scheme attribute on the category element; some
implementations don't fully support the atom content model (e.g. base64
encoded content); some implementations don't support XML digital
signatures; etc.
Because there is no definition of conformance, even for the core Atom
format, it is perfectly reasonable to expect that existing
implementations may have to change a bit in order to support the
introduction of new extensions, depending on the level of support they
have for the full atom data model as defined by RFC4287.
> Atom implementations with generic support for links and extensions,
> will find that this draft moves the goalposts of what a reasonable
> implementation is expected to handle, and I firmly believe that it
> should be possible for implementations to provide generic support for
> extensions in order to assist their adoption.
>
RFC4287 sets the goal posts. Extension attributes and elements ARE
allowed on Link. Whether or not an implementation chooses to support
such extensions is an implementation choice.
>[snip]
>> None of the folks I know of that have actually
>> implemented support for the extension has had any problems with them.
>
> Does that include any stateful feed APIs, or APP servers that aren't
> based on native XML back-ends?
>
I am not certain what you mean by "stateful feed APIs", but the answer
is yes to the question about non-native XML back-ends.
>[snip]
- James
--
Robert Sayre
"I would have written a shorter letter, but I did not have the time."
