Tuesday, May 24, 2005, 5:26:39 PM, you wrote:
On 24 May 2005, at 4:07 pm, Robert Sayre wrote:
4.2.9 (editorial): The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element extension.
Remove is an empty element that.
That's not an editorial
David Powell wrote:
IF, the interpretation of Section 6, that Thomas Broyer has helped me
to hammered out is correct, then:
Extension Elements [6.4], in Atom 1.0, are allowed only as direct
children of atom:entry, atom:feed, Person Constructs, and atom:source.
They must be qualified with a
David Powell wrote:
I'm also a bit confused about the terminology in Section 6.3:
It might be the case that the software is able to process the
foreign markup correctly and does so. Otherwise, such markup is
termed unknown foreign markup.
So unknown foreign markup is foreign markup
Thursday, May 26, 2005, 7:20:23 PM, Thomas Broyer wrote:
But then 6.3 goes on to explain how to process it.
This sounds like a contradiction?
No, why?
Ok, I'd interpreted ignoring it to be processing it, as opposed to
failing. I'll concede that I misinterpreted that.
Say I am an Atom
David Powell wrote:
Thursday, May 26, 2005, 7:20:23 PM, Thomas Broyer wrote:
Say I am an Atom Processor and I find these extensions elements:
!-- defined before:
xmlns:geo=http://www.w3.org/2003/01/geo/wgs84_pos#; --
geo:lat26.58/geo:lat
geo:long-97.83/geo:long
Is this something I
Thursday, May 26, 2005, 11:16:05 PM, Thomas Broyer wrote:
David Powell wrote:
Thursday, May 26, 2005, 8:50:04 PM, Thomas Broyer wrote:
6.2 deals with the Atom vocabulary, which is the markup in the Atom
namespace or un prefixed attributes on Atom-namespaced elements (this is
my
On May 25, 2005, at 1:40 PM, David Powell wrote:
What is section 6.3 unknown foreign markup for?
I think the notion of foreign markup exists so that we can write the
extremely-important section 6.3, our MustIgnore assertion. The point
is, either software knows what to do with an
Wednesday, May 25, 2005, 10:04:52 PM, Tim Bray wrote:
On May 25, 2005, at 1:40 PM, David Powell wrote:
What is section 6.3 unknown foreign markup for?
I think the notion of foreign markup exists so that we can write the
extremely-important section 6.3, our MustIgnore assertion.
Wednesday, May 25, 2005, 10:04:52 PM, Tim Bray wrote:
I think the notion of foreign markup exists so that we can write the
extremely-important section 6.3, our MustIgnore assertion. The point
is, either software knows what to do with an extension and does it,
or if not it's not allowed to
4.2.9 The atom:link Element
The atom:link element is an empty element that defines a reference from an
entry or feed to a Web resource.
did we want to prevent expressions like this:
link href=.. type=.. rel=.. title=..
ext:foo .../
/link
e.
At 6:22 PM +1000 5/24/05, Eric Scheid wrote:
4.2.9 The atom:link Element
The atom:link element is an empty element that defines a reference from an
entry or feed to a Web resource.
did we want to prevent expressions like this:
link href=.. type=.. rel=.. title=..
ext:foo
On 5/24/05, Paul Hoffman [EMAIL PROTECTED] wrote:
I read empty as always empty, so the XML novice in me would say
that the above expression in inherently wrong.
4.2.9 (editorial): The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element
On 24 May 2005, at 4:07 pm, Robert Sayre wrote:
4.2.9 (editorial): The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element extension.
Remove is an empty element that.
That's not an editorial change, that's newly allowing extension
elements
On 5/24/05, Graham [EMAIL PROTECTED] wrote:
On 24 May 2005, at 4:07 pm, Robert Sayre wrote:
4.2.9 (editorial): The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element extension.
Remove is an empty element that.
That's not an editorial
On 5/24/05, Graham [EMAIL PROTECTED] wrote:
On 24 May 2005, at 4:07 pm, Robert Sayre wrote:
4.2.9 (editorial): The atom:link element is explicitly described as
empty, which violates the rules in 6 for foreign element extension.
Remove is an empty element that.
That's not an editorial
Graham wrote:
On 24 May 2005, at 5:44 pm, Robert Sayre wrote:
FYI:
http://www.imc.org/atom-syntax/mail-archive/msg11433.html
But if I encounter a link element that's weirdly non-empty and
contains markup from some other namespace, that's the kind of
situation you're talking about. I think
Tuesday, May 24, 2005, 9:22:29 AM, Eric Scheid wrote:
4.2.9 The atom:link Element
The atom:link element is an empty element that defines a reference from an
entry or feed to a Web resource.
Subject: Re: extension elements inside link elements?
did we want to prevent expressions like
David Powell wrote:
Whether the draft allowed it or not, atom:link isn't an extension
point.
Could you explain why?
--
Thomas Broyer
Tuesday, May 24, 2005, 8:24:16 PM, Graham wrote:
On 24 May 2005, at 7:08 pm, David Powell wrote:
Whether the draft allowed it or not, atom:link isn't an extension
point. That would be Section 6.3 style unknown foreign markup.
Unless there's a memo I missed, extensions are a subset of
Tuesday, May 24, 2005, 7:50:13 PM, Thomas Broyer wrote:
David Powell wrote:
Whether the draft allowed it or not, atom:link isn't an extension
point.
Could you explain why?
The following are extension points:
* Adding additional metadata to atom:feed by using Section 6.4
Extension
On May 24, 2005, at 10:43 AM, Graham wrote:
I also think removing that piece of text makes it unclear that the
element is normally empty.
+1 -Tim
On 5/24/05, Graham [EMAIL PROTECTED] wrote:
On 24 May 2005, at 5:44 pm, Robert Sayre wrote:
FYI:
http://www.imc.org/atom-syntax/mail-archive/msg11433.html
But if I encounter a link element that's weirdly non-empty and
contains markup from some other namespace, that's the kind of
22 matches
Mail list logo
