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 nam
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
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
>>>m
David Powell wrote:
Thursday, May 26, 2005, 8:50:04 PM, you 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 interpretation, it's not clearly stated in the spec, and I'm quite
sure I alre
Thursday, May 26, 2005, 8:50:04 PM, you wrote:
>>6.2 says that new elements and attributes can be added.
>>
> 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 interpretation, it's not clearly sta
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:
26.58
-97.83
Is this something I know how to process?
* yes: this is "known foreign markup", I process it
* no: this is "unknown fo
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
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 ma
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
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 asserti
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 a
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 would do any damage; I best most software would never
> notice it. Having said that, I don't agree th
* Thomas Broyer <[EMAIL PROTECTED]> [2005-05-24 20:10]:
> What about:
>
>The "atom:link" element defines a reference from an entry or
>feed to a Web resource. Atom doesn't define any child to the
>"atom:link", though it might contain extension markup.
I may be trying to pick a colour
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 element that's weirdly non-empty and
> > contains markup from some other namespace, that's the ki
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 May 24, 2005, at 9:26 AM, Graham 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 in
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
Extens
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
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 "unknown
foreign markup".
Graham
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, 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
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 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 it w
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 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 it would be OK to lea
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
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
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
element
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 eleme
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:
I read "empty" as "always empty",
> 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:
e.
29 matches
Mail list logo
