Tuesday, May 24, 2005, 9:28:09 PM, Tim Bray wrote:
> On the one hand I agree with Graham; this does feel like a
> substantial change. On the other, it's hard to see that having stuff
> inside <link> would do any damage; I best most software would never
> notice it. Having said that, I don't agree that it's editorial
> change and I'd like to see a couple more voices in favor and give
> people a chance to shout "No!" before going ahead and doing it. -Tim
I'm either +1 or -1. I haven't decided yet, but I'm lying in the road
on this one :) I can't answer this until something is explained to
me:
What is section 6.3 "unknown foreign markup" for?
* We have content constructs which are extensible by allowing any type
of data to be embedded using the IANA registry of MIME types.
* We have carefully designed an IANA registry for @rel values, and used
the distributed nature of namespace URIs to allow for unregistered
values.
* We have carefully defined two classes of extension construct (Simple
and Structured) to ensure that extensions are disambiguated by
namespace URIs, and that xml:lang issues are considered. Simple
extensions make generic support for this class of extension feasible
for real-world implementations; Structured extensions are there for
those that need the extra power.
And, we have "unknown foreign markup".
I believed that the purpose of "unknown foreign markup" was to define
an error handling strategy for parsers, and to give the spec a bit of
breathing room for things like Atom 1.1. This is great.
But I'm getting a sneaking suspicion though, that "unknown foreign
markup" is positioning itself as a third (poorly thought through)
class of extension point.
Please tell me that that isn't the intent?
In the future someone said:
> Hey, I've had an idea for an extension to atom:link. The text content
> of atom:link could be a tooltip giving a long description for the link
> It would work like this:
>
> <atom:link rel="alternate" href="http://example.com/dave">
> This is a picture of my holiday. I'm the one on the right.
> </atom:link>
>
> What do you think?
In the future someone said:
> Hey, I've had an idea for an extension to atom:link. The text content
> of atom:link could be a GUID of an ActiveX control that is capable of
> displaying the linked object. It would work like this:
>
> <atom:link rel="alternate" href="http://example.com/dave">
> 0A28AB31-3143-4b70-B969-8650BDFDBAC9
> </atom:link>
>
> What do you think?
--
Dave