Re: round 2: Proposed Changes for format-11

[Peter Robinson]

Robert Sayre <[EMAIL PROTECTED]> wrote:

> The diffs linked below should reflect comments on the first round.

A few more minor nits I'm afraid.  (I don't think I've seen these
discussed before.)

> http://www.franklinmint.fm/2005/08/02/draft-ietf-atompub-format-11.txt

| Atom allows the use of IRIs [RFC3987].  Every URI [RFC3986] is also
| an IRI, so a URI may be used wherever below an IRI is named.

s/ below//

You've replaced 'is needed.' with 'is named.' in the last clause.  I'm
not sure that's an improvement, or what was wrong with 'is needed.' in
the first place.  But if you don't like that, what about 'is required.'
or 'is called for.'?

You've also replaced 'a URI can' with 'a URI may'.  Do you mean 'a URI
MAY'?  I suppose it depends on whether you see that sentence as a
statement of fact or as part of the spec.

Regards,

Peter

round 2: Proposed Changes for format-11

[Robert Sayre]

The diffs linked below should reflect comments on the first round. No
effort has been made to resolve the ambiguity discovered around
leading and trailing whitespace. Awaiting chairs' instructions for
that.

http://www.franklinmint.fm/2005/08/02/draft-ietf-atompub-format-11-from-10.diff.html
http://www.franklinmint.fm/2005/08/02/draft-ietf-atompub-format-11.html
http://www.franklinmint.fm/2005/08/02/draft-ietf-atompub-format-11.txt

Robert Sayre

Re: Proposed changes for format-11

[Antone Roundy]

On Monday, August 1, 2005, at 09:55  AM, A. Pagaltzis wrote:

* Robert Sayre <[EMAIL PROTECTED]> [2005-08-01 17:25]:

On 8/1/05, Sam Ruby <[EMAIL PROTECTED]> wrote:

Perhaps the following could be added to section 6.2:

  The Atom namespace is reserved for future
  forwards-compatable revisions of Atom.


s/compatable/compatible/


Sounds OK to me, but I recall squawking about this.


There wasn’t any squawking about the rule as such, I think. A
minor amount of squawking was about what a consumer should do
when it encounters Atom-namespaced elements in locations it
didn’t expect them.

Per spec: it should simply treat them as unknown foreign markup.
Intent: this allows old consumers to continue working with future
revisions of the spec, so long as changes are not so drastic that
a new namespace is warranted to prevent existing consumers from
doing anything with new documents.

It sounds to me like we might benefit from adding language specifying 
that elements in the Atom namespace can appear as children of elements 
from other namespaces, but may not appear as children of elements in 
the Atom namespace except as specified by the spec (or from wording the 
language to be added so that it says that).


...I am correct about our intent to allow Atom elements to be used as 
children of extension elements, right?  For example, that one be able 
to do this:



My title



...rather than having to do this:


My title



...right?

Re: Proposed changes for format-11

[A. Pagaltzis]

* Robert Sayre <[EMAIL PROTECTED]> [2005-08-01 17:25]:
> On 8/1/05, Sam Ruby <[EMAIL PROTECTED]> wrote:
> > Perhaps the following could be added to section 6.2:
> > 
> >   The Atom namespace is reserved for future
> >   forwards-compatable revisions of Atom.

s/compatable/compatible/

> Sounds OK to me, but I recall squawking about this.

There wasn’t any squawking about the rule as such, I think. A
minor amount of squawking was about what a consumer should do
when it encounters Atom-namespaced elements in locations it
didn’t expect them.

Per spec: it should simply treat them as unknown foreign markup.
Intent: this allows old consumers to continue working with future
revisions of the spec, so long as changes are not so drastic that
a new namespace is warranted to prevent existing consumers from
doing anything with new documents.

(You probably know this, of course…)

I think that specification of behaviour is a wise choice.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Proposed changes for format-11

[Robert Sayre]

On 8/1/05, Sam Ruby <[EMAIL PROTECTED]> wrote:
> 
> Eric Scheid wrote:
> > On 1/8/05 5:39 PM, "David Powell" <[EMAIL PROTECTED]> wrote:
> >
> >>>This specification does not place any restrictions on what elements
> >>>may be used as Metadata Extensions, but the RelaxNG grammar
> >>>explicitly excludes elements in the Atom namespace. The Atom
> >>>namespace is reserved for future forwards-compatable revisions of
> >>>Atom.
> >>
> >>I'm not sure I like this paragraph. It starts by saying that it places
> >>no restriction on the elements, then mentions the RelaxNG, then in the
> >>final sentence, it says that actually there is a restriction after
> >>all. I don't know - perhaps I'm not reading it right, but it sounds
> >>contradictory. It would make more sense to me if everything was
> >>dropped except the last sentence.
> >
> > I agree, especially since elsewhere the RelaxNG is noted to be Informative,
> > not Normative.
> 
> This paragraph appears to be expressing two separate thoughts.  Perhaps
> the solution is to separate the thoughts into separate paragraphs.

That's a good rule of thumb.

> 
> Perhaps the following could be added to section 6.2:
> 
>   The Atom namespace is reserved for future forwards-compatable
>   revisions of Atom.

Sounds OK to me, but I recall squawking about this.

> Which would enable the text in appendix B to simply state:
> 
>   The RelaxNG grammar explicitly excludes elements in the Atom
>   namespace which are not defined in this revision of the specification.

Sounds good.

Robert Sayre

Re: Proposed changes for format-11

[Sam Ruby]

Eric Scheid wrote:
> On 1/8/05 5:39 PM, "David Powell" <[EMAIL PROTECTED]> wrote:
> 
>>>This specification does not place any restrictions on what elements
>>>may be used as Metadata Extensions, but the RelaxNG grammar
>>>explicitly excludes elements in the Atom namespace. The Atom
>>>namespace is reserved for future forwards-compatable revisions of
>>>Atom.
>>
>>I'm not sure I like this paragraph. It starts by saying that it places
>>no restriction on the elements, then mentions the RelaxNG, then in the
>>final sentence, it says that actually there is a restriction after
>>all. I don't know - perhaps I'm not reading it right, but it sounds
>>contradictory. It would make more sense to me if everything was
>>dropped except the last sentence.
> 
> I agree, especially since elsewhere the RelaxNG is noted to be Informative,
> not Normative.

This paragraph appears to be expressing two separate thoughts.  Perhaps
the solution is to separate the thoughts into separate paragraphs.

Perhaps the following could be added to section 6.2:

  The Atom namespace is reserved for future forwards-compatable
  revisions of Atom.

Which would enable the text in appendix B to simply state:

  The RelaxNG grammar explicitly excludes elements in the Atom
  namespace which are not defined in this revision of the specification.

- Sam Ruby

Re: Proposed changes for format-11

[Eric Scheid]

On 1/8/05 5:39 PM, "David Powell" <[EMAIL PROTECTED]> wrote:

> 
>> This specification does not place any restrictions on what elements
>> may be used as Metadata Extensions, but the RelaxNG grammar
>> explicitly excludes elements in the Atom namespace. The Atom
>> namespace is reserved for future forwards-compatable revisions of
>> Atom.
> 
> I'm not sure I like this paragraph. It starts by saying that it places
> no restriction on the elements, then mentions the RelaxNG, then in the
> final sentence, it says that actually there is a restriction after
> all. I don't know - perhaps I'm not reading it right, but it sounds
> contradictory. It would make more sense to me if everything was
> dropped except the last sentence.

I agree, especially since elsewhere the RelaxNG is noted to be Informative,
not Normative.

e.

Re: Proposed changes for format-11

[David Powell]

draft-11:

> This specification does not place any restrictions on what elements
> may be used as Metadata Extensions, but the RelaxNG grammar
> explicitly excludes elements in the Atom namespace. The Atom
> namespace is reserved for future forwards-compatable revisions of
> Atom.

I'm not sure I like this paragraph. It starts by saying that it places
no restriction on the elements, then mentions the RelaxNG, then in the
final sentence, it says that actually there is a restriction after
all. I don't know - perhaps I'm not reading it right, but it sounds
contradictory. It would make more sense to me if everything was
dropped except the last sentence.


Also, Section 6.4 still doesn't permit Extension Elements in atom:source.
I thought that we were going to fix this:
http://www.imc.org/atom-syntax/mail-archive/msg15916.html


And, did we ever get a resolution to the composite MIME types thing
(I'm guessing that we didn't):
http://www.imc.org/atom-syntax/mail-archive/msg15911.html

-- 
Dave

Re: Proposed changes for format-11

[Robert Sayre]

Sigh, I can't do anything right today.

On 7/31/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
> 
> On 1/8/05 9:34 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
> 
> > If anyone objects to any of the *new
> > text*, please speak up.
> 
> spello:
> 
> s/forwards-compatable/forwards-compatible/
> 
> e.
> 
>

Re: Proposed changes for format-11

[Eric Scheid]

On 1/8/05 9:34 AM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:

> If anyone objects to any of the *new
> text*, please speak up.

spello:

s/forwards-compatable/forwards-compatible/

e.

Re: Proposed changes for format-11

[Robert Sayre]

On 7/31/05, Graham <[EMAIL PROTECTED]> wrote: 
> And what is this mysterious "source attribute"? 
> I presume you mean
> "src", but it is not expanded to "source" anywhere else in the document.

Oops. Thanks.

Robert Sayre

Re: Proposed changes for format-11

[Robert Sayre]

Sounds good.

On 7/31/05, Sam Ruby <[EMAIL PROTECTED]> wrote:
> Robert Sayre wrote:
> > The documents linked below represent the editors' efforts to resolve
> > our single IESG objection, and to fix a few spec bugs that have been
> > brought up in the past few weeks. If anyone objects to any of the *new
> > text*, please speak up.
> >
> > diffs:
> > http://franklinmint.fm/2005/07/31/draft-ietf-atompub-format-11-from-10.diff.html
> >
> > txt:
> > http://franklinmint.fm/2005/07/31/draft-ietf-atompub-format-11.txt
> >
> > html:
> > http://franklinmint.fm/2005/07/31/draft-ietf-atompub-format-11.html
> >
> > Robert Sayre
> >
> 
> This is truly a nit:
> 
> If neither the type attribute nor the source attribute is provided,
> Atom Processors MUST behave as though it were present with a value
> of "text".
> 
> What is "it"?  The type attribute?  The source attribute?
> 
> Suggestion:
> 
> s/ it / the type attribute /
> 
> - Sam Ruby
>

Re: Proposed changes for format-11

[Graham]

On 1 Aug 2005, at 1:07 am, Sam Ruby wrote:



   If neither the type attribute nor the source attribute is provided,
Atom Processors MUST behave as though it were present with a value
of "text".



And what is this mysterious "source attribute"? I presume you mean  
"src", but it is not expanded to "source" anywhere else in the document.


Graham

Re: Proposed changes for format-11

[Sam Ruby]

Robert Sayre wrote:
> The documents linked below represent the editors' efforts to resolve
> our single IESG objection, and to fix a few spec bugs that have been
> brought up in the past few weeks. If anyone objects to any of the *new
> text*, please speak up.
> 
> diffs:
> http://franklinmint.fm/2005/07/31/draft-ietf-atompub-format-11-from-10.diff.html
> 
> txt:
> http://franklinmint.fm/2005/07/31/draft-ietf-atompub-format-11.txt
> 
> html:
> http://franklinmint.fm/2005/07/31/draft-ietf-atompub-format-11.html
> 
> Robert Sayre
> 

This is truly a nit:

If neither the type attribute nor the source attribute is provided,
Atom Processors MUST behave as though it were present with a value
of "text".

What is "it"?  The type attribute?  The source attribute?

Suggestion:

s/ it / the type attribute /

- Sam Ruby

Proposed changes for format-11

[Robert Sayre]

The documents linked below represent the editors' efforts to resolve
our single IESG objection, and to fix a few spec bugs that have been
brought up in the past few weeks. If anyone objects to any of the *new
text*, please speak up.

diffs:
http://franklinmint.fm/2005/07/31/draft-ietf-atompub-format-11-from-10.diff.html

txt:
http://franklinmint.fm/2005/07/31/draft-ietf-atompub-format-11.txt

html:
http://franklinmint.fm/2005/07/31/draft-ietf-atompub-format-11.html

Robert Sayre