Re: PaceExplainDuplicateIds
On 4/30/05, Bob Wyman <[EMAIL PROTECTED]> wrote: > The spec should STRONGLY state that each entry must have a unique > atom id. The point of the "require source" language is not to remove the > requirement for uniqueness but rather to provide a more useful way of doing > cross-feed determination of uniqueness. OK, that's fine with me. There is no "required source" language, though. Someone should write a Pace. This WG has, shall we say, more active management than most. I'm afraid I can't just write down what I think you mean. Robert Sayre
RE: PaceExplainDuplicateIds
Robert Sayre wrote: > compliant processors will still differ from one-off hacks. Why in the world are we letting "one-off hacks" influence the design of Atom? That strikes me as rather unwise. We aren't here to make life easy for script-kiddies. We're here to design a format that allows us to build useful applications for the people who rely on our systems. The fact that it might be a little difficult for some children or hackers to build decent code is not something that should enter into our considerations. The spec should STRONGLY state that each entry must have a unique atom id. The point of the "require source" language is not to remove the requirement for uniqueness but rather to provide a more useful way of doing cross-feed determination of uniqueness. bob wyman
Re: PaceExplainDuplicateIds
Robert Sayre wrote: On 4/30/05, Antone Roundy <[EMAIL PROTECTED]> wrote: On Saturday, April 30, 2005, at 02:02 PM, Robert Sayre wrote: The proposed compromise to allow duplicate IDs in feeds, on the condition that a source element is present, doesn't address the problem of quick scripts that probably won't group duplicate IDs. I don't understand the last part of this sentence--could you explain? Sure. Take a look at the discussion here: http://www.intertwingly.net/blog/2005/04/09/Clone-Wars Say someone writes a quick PHP script that doesn't keep any state and loops through the entries to display them on a web page. They'll have different results than a well-written desktop aggregator. There can be no expectation about interoperability of invalid feeds. In the feed mentioned there, I presume that the "spid" part of the URI was meant to be substituted with some sort of product id. The ids encoded inside the links clearly would do. Heck, the links themselves are better "globally unique identifiers" than the ones provided as the guids. One of the clearest requirements that aggregator authors have provided to Atom is the wisdom of requiring unique IDs on entries. There may be consensus that unique by source is sufficient. - Sam Ruby
Re: PaceOptionalFeedLink
--On April 30, 2005 3:03:50 PM -0400 Robert Sayre <[EMAIL PROTECTED]> wrote: > > "atom:feed elements MUST NOT contain more than one atom:link element > with a rel attribute value of "alternate" that has the same > combination of type and hreflang attribute values." That actually specifies something different, the duplication, without saying whether atom:link is recommended. I recommend adding this text: "An atom:feed element SHOULD/MAY contain one such atom:link element." I'll let other people contribute on whether it is SHOULD or MAY. wunder -- Walter Underwood Principal Architect, Verity
Re: PaceExplainDuplicateIds
On 4/30/05, Antone Roundy <[EMAIL PROTECTED]> wrote: > > On Saturday, April 30, 2005, at 02:02 PM, Robert Sayre wrote: > > > The proposed compromise to allow duplicate IDs in feeds, on the > > condition that a source element is present, doesn't address the > > problem of quick scripts that probably won't group duplicate IDs. > > I don't understand the last part of this sentence--could you explain? Sure. Take a look at the discussion here: http://www.intertwingly.net/blog/2005/04/09/Clone-Wars Say someone writes a quick PHP script that doesn't keep any state and loops through the entries to display them on a web page. They'll have different results than a well-written desktop aggregator. Robert Sayre
Re: PaceExplainDuplicateIds
On Saturday, April 30, 2005, at 02:02 PM, Robert Sayre wrote: The proposed compromise to allow duplicate IDs in feeds, on the condition that a source element is present, doesn't address the problem of quick scripts that probably won't group duplicate IDs. I don't understand the last part of this sentence--could you explain? Thanks.
PaceExplainDuplicateIds
Feel free to suggest alternate mealy-mouthed wording. :)
== Abstract ==
Weakens the constraint on duplicate entry ids in feeds to a SHOULD.
== Status ==
Open
== Rationale ==
The proposed compromise to allow duplicate IDs in feeds, on the
condition that a source element is present, doesn't address the
problem of quick scripts that probably won't group duplicate IDs. This
means that compliant processors will still differ from one-off hacks.
Rather than legislate the constraint, we should explain the situation,
and give the validator a SHOULD-level requirement so a warning can be
triggered.
== Proposal ==
Remove the bullet point that reads
{{{ atom:feed elements MUST NOT contain atom:entry elements with
identical atom:id values. }}}
Add a paragraph after the list that reads
{{{
Atom Processors use the atom:id element found in Atom entries to identify
distinct entries. It is RECOMMENDED that each entry in an Atom Feed Document
have a distinct atom:id value.
}}}
== Impacts ==
== Notes ==
CategoryProposals
Re: PaceXhtmlDivSuggestedOnly
On Saturday, April 30, 2005, at 12:03 PM, Thomas Broyer wrote: Graham wrote: The div is not part of the content, and inline content can safely appear within a div. I'm OK with that but I'm still bothered by putting my titles in a block-level element: because the div is still part of XHTML (even if not part of the content here), which defines it as a block-level container! PaceXmlContentWrapper would enable the use of an inline element in Atom elements that aren't supposed to have block content. And it would enable people who declare the namespace elsewhere to omit the container element. And it would keep the status of the top level element in the content, if there is one, unambiguous. Are you considering the following title OK? Hey this is an entry title! Look what the Atom spec allows us to do with it! If not (which I suppose), then the spec should at least be changed to introduce inline vs. block content. And the same distinction should be done for escaped HTML content to forbid (well, actually not, I know, because we use a SHOULD and not a MUST) titles like this one: I'd support forbidding block markup in titles and other such places where it's not appropriate. I'm not sure it's so easy. There's another problem with the actual spec: it allows any attribute on the XHTML div container without defining how they have to be handled. Should they be discarded along with the div? Should they be somehow "inherited" by the content? I'd support forbidding any attributes other than (a) namespace declaration(s) on container elements...in fact, I'm going to add that to PaceXmlContentWrapper. If the spec is changed to forbid any attribute (other than the XHTML namespace declaration), then the XHTML div is not really an XHTML div, it becomes (and actually it already is, as it is not part of the content) a dummy container belonging to the XHTML namespace, whichever its name (though it's better if it looks like an existing XHTML element). I disagree with this characterization. We may have profiled the XHTML div element for this particular use, but that doesn't stop it from being an XHTML div. I'm sorry but these kind of "hacks" have nothing to do within a standard (IETF or else), especially if they have no mean other than just being hacks and if there are clean solutions: Atom is XML using XML namespaces, it's enough for usefulness without the need to introduce such a dummy container; and people willing to use default namespaces only (prefix-free XML names) can still achieve that by introducing meaningless "span" or "div" containers, with the difference they will be part of the content. If the author adds a div or span, that's fine. But if the software ads it, it's altering the author's content, and should have a way to so indicate so that the change can be undone.
PaceOptionalFeedLink
== Abstract == Remove the requirement for a feed-level link element. == Status == Open == Rationale == The requirement makes people jump through hoops for little gain, since there is a strong incentive to provide the link if you have something. Unlike entries, feeds are almost always dereferenced from a URI. == Proposal == In section 4.1.1, strike the line that reads "atom:feed elements MUST contain at least one atom:link element with a relation of "alternate"." and replace it with "atom:feed elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same combination of type and hreflang attribute values." == Impacts == == Notes == CategoryProposals
Re: PaceXhtmlDivSuggestedOnly
Graham wrote: On 30 Apr 2005, at 3:43 pm, Thomas Broyer wrote: Using a XHTML "div" element is also quite inappropriate in an atom:title element as a "div" is meant for block content whereas a title is merely expected to be used as inline content (e.g. by putting it inside an "h2" or "h3" XHTML element). The div is not part of the content, and inline content can safely appear within a div. I'm OK with that but I'm still bothered by putting my titles in a block-level element: because the div is still part of XHTML (even if not part of the content here), which defines it as a block-level container! Are you considering the following title OK? Hey this is an entry title! Look what the Atom spec allows us to do with it! If not (which I suppose), then the spec should at least be changed to introduce inline vs. block content. And the same distinction should be done for escaped HTML content to forbid (well, actually not, I know, because we use a SHOULD and not a MUST) titles like this one: -1. Next. I'm not sure it's so easy. There's another problem with the actual spec: it allows any attribute on the XHTML div container without defining how they have to be handled. Should they be discarded along with the div? Should they be somehow "inherited" by the content? If the spec is changed to forbid any attribute (other than the XHTML namespace declaration), then the XHTML div is not really an XHTML div, it becomes (and actually it already is, as it is not part of the content) a dummy container belonging to the XHTML namespace, whichever its name (though it's better if it looks like an existing XHTML element). I'm sorry but these kind of "hacks" have nothing to do within a standard (IETF or else), especially if they have no mean other than just being hacks and if there are clean solutions: Atom is XML using XML namespaces, it's enough for usefulness without the need to introduce such a dummy container; and people willing to use default namespaces only (prefix-free XML names) can still achieve that by introducing meaningless "span" or "div" containers, with the difference they will be part of the content. -- Thomas Broyer
Re: PaceTextShouldBeProvided
On 4/30/05, Graham <[EMAIL PROTECTED]> wrote: > > Obviously, the WG doesn't find that MUST particularly crucial. > > Robert, will you stop banging your drum about this and let the WG get > a word in edgeways? If your position has such unanimous support it > will survive without you. So, I have to be quiet. Is that what you're saying? Let me suggest you take your own advice. I wrote six sentences, after a day of no one paying attention to this pointless, intentionally obfuscated, and otherwise badly written proposal. Robert Sayre On 4/28/05, Tim Bray wrote: > > And of course we're going to have to fish some sort of > consensus out of this horrid summary-required mess. -Tim Bill responded > I can't agree with that observation. Although there are a few strenuous > objections against title only feeds, on the balance consensus is for > them. Is there something you're seeing that should make us think the > current consensus level is inadequate?
Re: PaceTextShouldBeProvided
Obviously, the WG doesn't find that MUST particularly crucial. Robert, will you stop banging your drum about this and let the WG get a word in edgeways? If your position has such unanimous support it will survive without you. Thank you. Graham
Re: PaceXhtmlDivSuggestedOnly
On 30 Apr 2005, at 3:43 pm, Thomas Broyer wrote: Using a XHTML "div" element is also quite inappropriate in an atom:title element as a "div" is meant for block content whereas a title is merely expected to be used as inline content (e.g. by putting it inside an "h2" or "h3" XHTML element). The div is not part of the content, and inline content can safely appear within a div. -1. Next. Graham
Re: PaceTextShouldBeProvided
> Suggestions? Is this something that the editor can handle? Maybe Mark can. This editor doesn't understand the rationale. > > > > This section needs to be reworked. We can't make normative reference to the > > RNG. > > Suggestions? Is this something that the editor can handle? Paces should provide camera-ready text. > > PaceOptionalSummary does not introduce a MAY, it removes a crucial MUST Obviously, the WG doesn't find that MUST particularly crucial. Robert Sayre
Re: PaceTextShouldBeProvided
Robert Sayre wrote: On 4/29/05, Sam Ruby <[EMAIL PROTECTED]> wrote: == Abstract == Encourage interoperability and accessibility by suggesting that key textual constructs be both present and non-empty. I'd prefer that a bit more of the rationale made it into the text. Explain why we are saying SHOULD. Suggestions? Is this something that the editor can handle? === section 4.1.2 === Add: atom:entry elements SHOULD contain an atom:summary element if the atom:content in the form of atomInlineOtherContent. This section needs to be reworked. We can't make normative reference to the RNG. Suggestions? Is this something that the editor can handle? == Notes == In the event that PaceOptionalSummary is adopted, the words "is either not present or" would need to be added to the proposed addition to section 4.1.2. -1 to this. If PaceOptionalSummary is adopted, the summary will be a MAY, not a SHOULD. Please put your proposals in the section marked "Proposal". At the moment, the proposal is based on the existing draft-ietf-atompub-format-08. PaceOptionalSummary does not introduce a MAY, it removes a crucial MUST -- one that, if removed, would exasperate the problem that PaceTextShouldBeProvided is intended to address. - Sam Ruby
Re: PaceTextShouldBeProvided
On 4/29/05, Sam Ruby <[EMAIL PROTECTED]> wrote: > > == Abstract == > > Encourage interoperability and accessibility by suggesting that key > textual constructs be both present and non-empty. > I'd prefer that a bit more of the rationale made it into the text. Explain why we are saying SHOULD. > > === section 4.1.2 === > > Add: > >atom:entry elements SHOULD contain an atom:summary element if the > atom:content in the form of atomInlineOtherContent. This section needs to be reworked. We can't make normative reference to the RNG. > == Notes == > > In the event that PaceOptionalSummary is adopted, the words "is either > not present or" would need to be added to the proposed addition to > section 4.1.2. -1 to this. If PaceOptionalSummary is adopted, the summary will be a MAY, not a SHOULD. Please put your proposals in the section marked "Proposal". Robert Sayre
PaceXhtmlDivSuggestedOnly
I'm aware that this Pace actually has two purposes: nuke the xhtml:div
requirement and add distinction between inline and block content. If
someone wants me to split it into two Paces, I'll do it, but I think
these two purposes are related to each other and that's why I made a
single Pace.
http://intertwingly.net/wiki/pie/PaceXhtmlDivSuggestedOnly
== Abstract ==
Make the XHTML div wrapper optional, as it causes more problems than it
actually solves.
== Status ==
Open
== Rationale ==
The only purpose of the XHTML div wrapper is to have it carry the XHTML
namespace declaration in case the feed producer doesn't want to use
prefixed XML names (i.e. always use default namespaces). The required
wrapper is also expected to prevent feeds using wrong namespaces.
On the other hand, there has been many discussion about which attributes
are allowed/forbidden on the wrapper and how they should be handled by
Atom processors, without a clear and clean solution.
Using a XHTML "div" element is also quite inappropriate in an atom:title
element as a "div" is meant for block content whereas a title is merely
expected to be used as inline content (e.g. by putting it inside an "h2"
or "h3" XHTML element). This has no technical impact in the current spec
as the div is not part of the content but it might disturb
XHTML-friendly people.
Finally, mandating a "foreign" (outside the Atom namespace) element but
requiring it not being part of the content and not behaving as it would
in its originating language (XHTML) is not a clean position: so is this
element part of Atom or XHTML?
== Proposal ==
Nuke the XHTML div requirement and adds distinction between inline and
block content to help producers choose the best container for their
content (div or span).
This means making the following changes/addition to the
draft-ietf-atompub-format-08 document.
=== section 3.1 ===
Change the {{{atomXHTMLTextConstruct}}} definition to this one: {{{
atomXHTMLTextConstruct =
atomCommonAttributes,
attribute type { "xhtml" },
(text
| anyXHTML)*
}}}
And add the following paragraph: {{{
This specification further refines the Text construct depending on
the kind of content that is expected. A Text constructs expecting
inline content is further named Inline Text construct, whereas a
Text construct expecting block content is named Block Text construct.
}}}
=== section 3.1.1.2 ===
Replace the last paragraph with:{{{
If the value of "type" is "html", the content of the Text construct
MUST NOT contain child elements, and SHOULD be suitable for handling
as HTML [HTML]. Any markup within MUST be escaped; for example,
"" as "
". Atom Processors that display such content MAY
use that markup to aid in its display.
The content is subject to further constraints depending on its kind:
o HTML markup within an Inline Text construct SHOULD be such that
it could validly appear directly within an HTML element,
after unescaping.
o HTML markup within a Block Text construct SHOULD be such that
it could validly appear directly within an HTML element,
after unescaping.
}}}
=== section 3.1.1.3 ===
{{{
Example atom:title with XHTML content:
...
http://www.w3.org/1999/xhtml";>
Less: <
...
If the value of "type" is "xhtml", the content of the Text construct
MUST be XHTML [XHTML] text and markup. Atom Processors which display
the content MAY use the markup to aid in displaying it. Escaped
characters, such as "&" and ">", represent those characters, not
markup.
The content is subject to further constraints depending on its kind:
o the content of an Inline Text construct MUST be XHTML text and
markup that could validly appear within an XHTML span element.
o the content of a Block Text construct MUST be XHTML text and
markup that could validly appear within an XHTML div element.
Examples of valid XHTML content:
...
http://www.w3.org/1999/xhtml";>
This is an XHTML title
http://www.w3.org/1999/xhtml";>
Note that using span and div
containers allows us to keep using default namespaces
(namespaces not bound to any prefix).
The container element has been choosen to fit the kind of
content it contains: span for inline content
and div for block content.
...
http://www.w3.org/1999/xhtml";>
This is an XHTML paragraph.
...
The following example assumes that the XHTML namespace has been bound
to the "xh" prefix earlier in the document:
...
This is XHTML content.
...
}}}
=== section 4.1.3 The "atom:content" Element ===
Replace the {{{atomInlineXHTMLContent}}} definition with this one:{{{
atomInlineXHTMLContent =
element atom:content {
atomCommonAttributes,
Re: PaceTextShouldBeProvided
Sam Ruby wrote: == Abstract == Encourage interoperability and accessibility by suggesting that key textual constructs be both present and non-empty. == Status == Open == Rationale == There are existance proofs of tools that either are less useful in the presence of entries without without a title, or ones without either a summary or inline textual content. In fact, at least one such tool discards such entries entirely. This fact, when viewed in isolation, would argue that such elements be mandatory. Unfortunately, there are also existence proofs of title-only feeds, and entries for which there are no titles. Reluctantly, this leads one to conclude that while they must be allowed, it would be irresponsible for the spec not to warn potential producers of such feeds that not providing a textual fallback may lead to interoperability issues. The bias bothers me - why are the existence of title only feeds unfortunate, whereas tools that do not handle them gracefully are not? And, is this not the kind of spec text we've been traditionally kicking into the Fabled Implementors Guide? === section 4.1.2 === Add: atom:entry elements SHOULD contain an atom:summary element if the atom:content in the form of atomInlineOtherContent. -1 to this addition. As these requirements are only SHOULDs, no feeds which are currently valid will become invalid. However, those that follow these suggestions will find that their feeds are useful to a wider audience than they would be otherwise. As a rationale, usefulness to a wider audience is debatable. I'm concerned that this text is intended, or will be leveraged, to call out title-only feeds as bad practice. If this is accepted, I would ask the editors to take care that is not implied. cheers Bill
Re: PaceTextShouldBeProvided
On 29 Apr 2005, at 5:51 pm, Sam Ruby wrote: Encourage interoperability and accessibility by suggesting that key textual constructs be both present and non-empty. +1 Graham
