Re: Author and contributor
On 23 May 2005, at 07:22, A. Pagaltzis wrote: In [EMAIL PROTECTED] (http://www.imc.org/atom-syntax/mail-archive/msg15517.html), Antone Roundy suggests: make atom:author plural keep atom:contributor punt bylines to an extension +1 to all I think that makes sense, especially if one thinks that atom could be used for wiki entries, where there being numerous authors is a fact of daily life. Henry
Re: some small comments on 08
Robert Sayre wrote:
What happens when it does contain child elements? I think we should
define that for interoperability. (See HTML for what happens when
you don't.) This question also applies to the next section.
No, that's broken. There can be no expectation of interoperability.
I think there should be. Authors will try to do it anyway and defined
error handling is better than reverse engineering the market leader's
error handling.
For white-space significance text I need to use 'html' or 'xhtml'
instead using PRE or xhtml:pre?
I don't understand what you're saying here, but I'm pretty sure every
possible whitespace issue has been debated by Graham, Paul, Martin,
etc. Feel free to try and explain this again if I don't get it.
White-space may be collapsed inside 'text' as currently defined.
* 4.2.2 The atom:category Element
Why is significant information hidden in attributes? That is bad
for i18n and prevents people from defining the expansion of an
abbreviation, for example.
Minor flaw. It happens.
I think you are rushing things too fast. It would be much better if we
fixed this.
* Links
I don't understand why we have so many different link constructs.
atom:link href=iri/, atom:imageiri/atom:image,
atom:uriiri/atom:uri, atom:content src=iri/.
Can't we name them consistently? I'd suggest 'href' or 'url'.
('url' is used in CSS and extensions of HTML and XHTML 1 made by
the WHATWG.)
Nope. Too late.
And this.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: Author and contributor
A. Pagaltzis wrote: In [EMAIL PROTECTED] (http://www.imc.org/atom-syntax/mail-archive/msg15517.html), Antone Roundy suggests: make atom:author plural keep atom:contributor punt bylines to an extension To me that sounds like the simplest thing that can possibly work, and looks like it hits the 80/20 mark. It also requires the least squabbling over its implementation. And Robert has expressed that he is fine with the proposal in that thread. Ive expressed an affinity for the idea of putting atom:category in atom:contributor, but I see a lot of potential delay in that and no pressing need for it. Again, +1 to Antones suggestion. +1. -- Anne van Kesteren http://annevankesteren.nl/
Author and contributor
co-chair-modeWe observe a significant amount of discomfort with the current one-author/multiple-contributors model in atom-format. Despite the mentions that Rob dug up, nobody can claim this has had serious in-depth discussion in the IETF context. On the other hand, we note that the current setup does have a coherent logical grounding, namely adopting Dublin Core semantics by identifying a singular primary-creator role and a plural contributor role. If we leave things the way they are, a pointer to this derivation would improve the draft. However, aside from Rob Sayre, nobody has been particularly militant in defending the current setup. Personally I don't think any of the alternatives proposed are going to have fewer corner cases, but quite likely they won't have more either. Unfortunately, among those who want to change the current setup, we do not observe consensus on the subject of what to change them to. Near as we can tell, people want to make atom:author plural, some want to nuke atom:contributor and others don't. If, in the next couple of days, a large number of people can coalesce behind ONE SPECIFIC change to the spec in this area, and there is no significant body of resistance to this change, Paul and I are prepared to be convinced that rough consensus exists for such a change./co-chair-mode
Re: A different question about atom:author and inheritance
Sunday, May 22, 2005, 9:53:23 PM, Robert Sayre wrote: The draft hasn't changed for more than a month, while Tim and Paul have been last-calling this thing for months now, and very little of substance has transpired since then. The document has been quite stable since March 12th, when format-06 was produced. No, the draft hasn't changed in the last month, but it will do when draft-09 is released. I was talking about the batch of proposals, including PaceAllowDuplicateIDs (a fundamental change), that were accepted 4 days ago. http://www.imc.org/atom-syntax/mail-archive/msg15289.html -- Dave
atom:type, xsl:output
[forwarding for Jimmy, he's having mail problems] From: Jimmy Cerra [EMAIL PROTECTED] I'm a little confused by the type attribute for atom:content and other elements. This the following correct? * When @type=html then the content of the element is a xsd:string [1] of an HTML DIV element plus optional insignificant whitespace around it. Which version of HTML is defined? How do you differentiate between HTML 4.01, HTML 3.2, the upcoming HTML 5, or nonstandard HTML (like with marquee elements)? * When @type=xhtml then the content of the element is a xhtml:div XML fragment plus optional insignificant whitespace around it. Again which version of XHTML is defined? How do you differentiate between XHTML 1.0, 1.1, or 2.0? Since XHTML 2.0 may have a new namespace, so will you allow that? How does requiring XHTML:div impact which XHTML modules are required (I have a guess)? And what about exotic versions like XHTML+MathML+SVG or XHTML 1.1 plus MathML 2.0? (Some blogs actually use it XHTML 1.1 plus MathML 2.0!) * When @type=text then the content of the element is a xsd:string of a text/plain document. * When @type=mime/type [2], ONLY for atom:content, then the content (or src document) is that type of document. Why not allow other elements to use this? What about content that isn't compatible with XML 1.0 (like XML 1.1, Turtle, RTF, PNG); should it be entity encoded/put into cdata section like HTML? What should one do when encountering these situations? Does that mean that if you use application/xhtml+xml, you can do (rest of feed omitted for brevity): atom:content type=application/xhtml+xml html xmlns=... headtitle.../title/head body ... /body /html /atom:content How do you specify xml-stylesheets processing instructions, doctype and xml declarations, and other data about the content? PIs may be a non-issue if they are not read by the XML processor for the Atom feed; although, that isn't guaranteed. I think you should at least allow @type=xml, as others have suggested for xml 1.0 content, along with adopting XSLT's output attributes (perhaps not using @method or @media-type). This would ease the pain with XML, and all media/types for @type require the content to be xsd:string valid (that is, entity encoded or using CDATA sections). Sorry for the boatload of questions. -- Jimmy Cerra http://pawsgroup.blogspot.com [1] That is, a text node in the XML tree. [2] A mime type, noting the exception in 4.1.3.1.
Re: some small comments on 08
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-23 09:05]: Robert Sayre wrote: For white-space significance text I need to use 'html' or 'xhtml' instead using PRE or xhtml:pre? I don't understand what you're saying here, but I'm pretty sure every possible whitespace issue has been debated by Graham, Paul, Martin, etc. Feel free to try and explain this again if I don't get it. White-space may be collapsed inside 'text' as currently defined. Last I asked, I understood that whitespace would be preserved if you supply 'text/plain' content; @type='text' is more like inline text in an XML document (or in HTML). Maybe the spec could be more explicit about that, though. Regards, -- Aristotle
Re: some small comments on 08
A. Pagaltzis wrote: * Anne van Kesteren [EMAIL PROTECTED] [2005-05-22 11:35]: * 4.1.3.1 The type attribute Can I circumvent the DIV element by using the media type of XHTML? (I really dislike this combined construct by the way.) I used to find it extremely horrible. Now I’m not sure. There is some symmetry here: with @type=xml, you have to Which @type=xml? Did you mean @type=text/xml? enclose a full XML document, which will always have a root element. The pseudo-XHTML DIV required for @type=xhtml makes XHTML fragments behave the same way. With the difference that this div is not part of the content. I don’t know if I like it. I don’t know if it’s a good solution. But it is consistent on some level, at least. It is not, not at all. To everyone here: please, comment on PaceOptionalXhtmlDiv, either +1 or -1, but at least argument. See also further explanation and technical arguments in Consensus call on last raft of issues [1] [1] http://www.imc.org/atom-syntax/mail-archive/msg15320.html -- Thomas Broyer
Re: 4.2.7.1 Comparing atom:id
At 16:09 05/05/22, Anne van Kesteren wrote: Robert Sayre wrote: I think the last paragraph of RFC3987, section 5.1 already says that :) http://rfc.net/rfc3987.html#s5.1. That also says that fragment components should be excluded. Is that true for Atom? It says: When IRIs are compared to select (or avoid) a network action, such as retrieval of a representation, fragment components (if any) should be excluded from the comparison. IDs are just identifiers, not used for network action, so this doesn't apply. Regards,Martin. Are we going to refer to that specification and that section from 4.2.7.1 in a future draft? -- Anne van Kesteren http://annevankesteren.nl/
Re: some small comments on 08
* Thomas Broyer [EMAIL PROTECTED] [2005-05-23 10:50]: A. Pagaltzis wrote: There is some symmetry here: with @type=xml, you have to Which @type=xml? Did you mean @type=text/xml? Sorry, I meant any XML media type. enclose a full XML document, which will always have a root element. The pseudo-XHTML DIV required for @type=xhtml makes XHTML fragments behave the same way. With the difference that this div is not part of the content. Ah! Good catch. I dont know if I like it. I dont know if its a good solution. But it is consistent on some level, at least. It is not, not at all. To everyone here: please, comment on PaceOptionalXhtmlDiv, either +1 or -1, but at least argument. I was leaning +1 and almost voted that way when you posted the Pace, but I was not sure if I had enough of the picture so I abstained at the time. Im still not firmly convinced (and intermittently thought maybe it was not so bad to keep the DIV, see above), but Im still dont see that it really is necessary. In particular, I dont see why mandating the pseudo-XHTML DIV is a better solution than promoting correct implementation by way of good examples, which you argued in that thread as well. So +1, absent an overwhelming example that people are more likely to get their namespaces wrong than right. Regards, -- Aristotle
Re: some small comments on 08
Thomas Broyer wrote: It is not, not at all. To everyone here: please, comment on PaceOptionalXhtmlDiv, either +1 or -1, but at least argument. See also further explanation and technical arguments in Consensus call on last raft of issues [1] ... For the record: I am +1 on http://www.intertwingly.net/wiki/pie/PaceOptionalXhtmlDiv. Best regards, Julian
Re: Deterministic content models (conflict with Atom Publishing Protocol?)
Hello Thomas, At 07:34 05/05/22, Thomas Broyer wrote: I'm sorry to raise this issue back again but... The Atom Publishing Protocol defines SOAP bindings. This (in my mind) means there will be WSDL files over there. WSDL rely on XML Schema which in turn are limited to deterministic content models. Will the APP limit Atom entries in SOAP envelopes content model to fit WSDL/XML Schema constraints (actually, the APP will already need to limit Atom entries to have a mandatory atom:content I think)? Or should the Atom Syndication Format use deterministic content models to allow XML Schema, thus such uses as WSDL for Web Services? Are you speaking about potential non-determinism or actual non-determinism? Is such non-determinism in the core of the Atom format, in potential extensions, or in payloads (e.g. XHTML,...)? If there is actual non-determinism now in the Atom core, that would be a reason for concern. If there is potential non-determinism in the payloads or extensions, it should be possible to handle that by a more open content model in XML Schema. Regards,Martin.
Re: updated and modified yet again
On 22 May 2005, at 06:29, Tim Bray wrote: News flash! Bob and I agree! I have been following this discussion and am finding I am also agreeing with Tim, Bob and Aristotle P. The points are subtle. This made me wonder if the points are not playing themselves out a different level. Perhaps the problem is that we are not clear about the difference between semantics and what is being said. At the level of semantics an entry as identified by its id has a number of dated representations. These representations can be grouped in different ways according to different identity criteria. One very precise such identity criteria would be string identity. Two representations are identical if they are character by character identical. Another identity criteria, lets call it update identity, says that two such representations are equivalent if they have the same atom:updated time stamp. This is a very vague identity criterion, which leaves it up to the interaction between users and consumers to set constraints on the criterion. The user has to face the fact that consumers may drop some of his changes (conceived of as changes under the criterion of string identity) if he does not change the date. So let us think of this from the point of view of the three players in this game: the original publisher, the final consumer, and the intermediary. The original publisher -- When the publisher is the same person as the person defining the identity criteria, then it makes sense that he should not publish two entries in a feed that are identical according to his own criteria. This can not be conceived to be a restriction on him. The final consumer -- The final consumer may have different identity criteria to the publisher of the feed, but since he is not the one to publish the feed there is not much for him to do. He cannot force the original publisher to be more precise, because that would be to ask the person who is publishing to see a distinction where he sees none. And this does not even take into account that other consumers may disagree with him anyhow. The aggregator -- The problematic case comes from those aggregating feeds. And I think here I can identify two different problems: a- The aggregator may say he has different identity criteria from the publisher. If he has then one can simply answer: your business is to be transparent, not to place yourself in between your user and his public. b- The aggregator wants to be completely transparent. But has a problem because he is not sure who to trust, and different people are making different claims about the same thing (the id). In everyday life there is a well known method for doing this honestly: we quote the source of who said what. If Smith says that the red car is his and John says that the car is his, I don't need to say that the car belongs to Smith and to John, I can just say Smith says that 'the car is his' and John says that 'the car is his'. I just need to quote what others have said. If this is the problem faced by Bob then I don't think atom:modified is going to help. That would be being precise in the wrong place. What would have helped was perhaps the solution proposed by Roy Fielding a few months ago, namely that a feed should be able to contain a feed. Bob's pub sub service would then be just able to quote what others (feeds) have said. It would then have been correct to hold the position currently held that no feed should *directly* contain an entry with the same atom:updated value. It would allow that a feed could contain two feeds each with different entries containing the same id and the same atom:updated time stamp. It would then be up to the consumer to decide which one it trusts. Henry Story
Re: some small comments on 08
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-23 10:35]: A. Pagaltzis wrote: Last I asked, I understood that whitespace would be preserved if you supply 'text/plain' content; @type='text' is more like inline text in an XML document (or in HTML). Maybe the spec could be more explicit about that, though. However, text/plain is not allowed everywhere where 'text' is allowed. True. But it seems reasonable to tell people they shouldnt stick content with significant linebreaks and whitespace into their titles? Not that I have any strong position about this; it just seems to make sense. Regards, -- Aristotle
Re: atom:type, xsl:output
On 23 May 2005, at 9:14 am, Danny Ayers wrote: * When @type=html then the content of the element is a xsd:string [1] of an HTML DIV element plus optional insignificant whitespace around it. Which version of HTML is defined? How do you differentiate between HTML 4.01, HTML 3.2, the upcoming HTML 5, or nonstandard HTML (like with marquee elements)? I believe the answer would be street HTML, not any specific version. * When @type=mime/type [2], ONLY for atom:content, then the content (or src document) is that type of document. Why not allow other elements to use this? Because the other elements are for purely textual content. XML 1.1 Not supported. Turtle Don't know. RTF It is compatible, as a string, though certain obsolete characters are not. PNG Should be base64 encoded. What should one do when encountering these situations? See section 4.1.3.3 Processing Model Does that mean that if you use application/xhtml+xml, you can do (rest of feed omitted for brevity): Yes. This is why we have a special XHTML mode for fragments. Graham
spec text regarding feed/entry inheritance
The question of inheritance of author/contributor from feed into entry needs to be disambiguated. I looked from the format-08 text and found that we already have reasonable wording in section 4.2.4 (The atom:copyright Element). There is also a hint in section 4.2.11 (The atom:source Element) that some other elements should also be inheritable. Proposal: insert text similar to § 4.2.4 ¶ 3 into § 4.2.1 The atom:author Element § 4.2.2 The atom:category Element § 4.2.3 The atom:contributor Element - some relevant snippets - 4.2.4 The atom:copyright Element If an atom:entry element does not contain an atom:copyright element, then the atom:copyright element of the containing atom:feed element's atom:head element, if present, is considered to apply to the entry. 4.1.2 The atom:entry Element atom:entry elements MUST contain exactly one atom:author element, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. ... but that doesn't explain that the atom:entry inherits the author from the feed. It actually suggests that an entry may be author-less, because the spec text for atom:author only says this: 4.2.11 The atom:source Element Such metadata SHOULD be preserved if the source atom:feed contains any of the child elements atom:author, atom:contributor, atom:copyright, or atom:category and those child elements are not present in the source atom:entry. ... which calls out atom:category in the same sentence as atom:author, atom:contributor, and atom:copyright ... which might suggest that atom:category should also be inherited. I don't recall what the thinking was, but I'd +1 inheritance of atom:category from atom:feed into atom:entry. e.
Re: Author and contributor
* Eric Scheid [EMAIL PROTECTED] [2005-05-23 15:48+1000] On 23/5/05 3:22 PM, A. Pagaltzis [EMAIL PROTECTED] wrote: Antone Roundy suggests: +1 make atom:author plural +1 keep atom:contributor punt bylines to an extension To me that sounds like the simplest thing that can possibly work, and looks like it hits the 80/20 mark. It also requires the least squabbling over its implementation. And Robert has expressed that he is fine with the proposal in that thread. Again, +1 to Antone¹s suggestion. +1,+1, and +1 from me too. +1, +1, +.5 from me BTW, and aside re Dublin Core semantics, DC allows all DC terms to be repeated, including 'creator'; the definition is given in http://dublincore.org/documents/dcmi-terms/ An entity primarily responsible for making the content of the resource. with the notes Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.. It says 'an entity' rather than 'the entity'. 'Primarily' might suggest one rather than many, but the notion of multiple entities being 'jointly first' in their responsibility for making the content seems to sneak us out of that one. Dublin Core has a group on Agents, see http://dublincore.org/groups/agents/ ...at the last Dublin Core Advisory Board meeting I said I'd try to get FOAF measured up against their functional requirements doc, http://rdfweb.org/pipermail/rdfweb-dev/2004-October/013820.html ...probably time to revisit that discussion. Also worth noting in that regard is that there are different idioms for deploying dc:creator (sometimes as a relationship to a string, sometimes as a relationship to an Agent of some kind) in RDF; http://danbri.org/words/?p=63 was an experiment in making explicit rules for mapping between them. Dan I¹ve expressed an affinity for the idea of putting atom:category in atom:contributor, but I see a lot of potential delay in that and no pressing need for it. seeing as that proposal was my idea, and despite no technical objections to it, I'm happy to withdraw it just so atom:author can get through the process hoops. e.
Re: Deterministic content models (conflict with Atom Publishing Protocol?)
Martin Duerst wrote: At 07:34 05/05/22, Thomas Broyer wrote: I'm sorry to raise this issue back again but... The Atom Publishing Protocol defines SOAP bindings. This (in my mind) means there will be WSDL files over there. WSDL rely on XML Schema which in turn are limited to deterministic content models. Will the APP limit Atom entries in SOAP envelopes content model to fit WSDL/XML Schema constraints (actually, the APP will already need to limit Atom entries to have a mandatory atom:content I think)? Or should the Atom Syndication Format use deterministic content models to allow XML Schema, thus such uses as WSDL for Web Services? Are you speaking about potential non-determinism or actual non-determinism? Atom core uses interleaved content models, which are not compatible with XML Schema (or DTD). I call them non-deterministic. I know that RelaxNG as well as other schema languages have been created partly because of this limitation of XML Schema, though I don't think we need interleaving in the case of Atom. If Atom aim to be used on devices/systems with small capabilities, having a clear content model makes the parsing easier, e.g. using a state machine based on SAX. The SOAP-WSDL-XML Schema is another approach of the problem, which is more likely to b a big concern as it is part of Atom (here, the protocol) Is such non-determinism in the core of the Atom format, in potential extensions, or in payloads (e.g. XHTML,...)? Payloads will most likely be parsed as black boxes to retrieve XML document fragments or the raw XML as string. Extensions are a concern but as they're part of core (hey, they are extensions ;o) ) Atom processors might just skip them. -- Thomas Broyer
Re: Author and contributor
On Mon, May 23, 2005 at 05:56:18AM -0400, Dan Brickley wrote: Antone Roundy suggests: +1 make atom:author plural +1 keep atom:contributor punt bylines to an extension +1, +1, +.5 from me +1, +.5, +.5 from me. James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
PaceClarifyAuthorContributor posted
http://www.intertwingly.net/wiki/pie/PaceClarifyAuthorContributor == Abstract == Allow multiple authors. Clarify relationship between atom:author and atom:contributor. == Status == Open == Rationale == The current draft only allows one atom:author per entry, meaning either: - All authors of a document have to be shoehorned into that atom:author element - One author has to be chosen as primary and the rest are contributors Secondly, no explicit relationship is given between author and contributor atom:contributor. The most intuitive approach, and that outlined in this pace, is that each person involved should only appear in one role (as an author, or as a contributor). Also, for the sake of making processing at the display end easier, each person should only be mentioned once. == Notes == Neither bylines nor inheritance are dealt with by this Pace. == Proposal == In 4.1.1, replace: o atom:feed elements MUST contain exactly one atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. with: o atom:feed elements MUST contain one or more atom:author elements, UNLESS all of the atom:feed element's child atom:entry elements contain at least one atom:author element. Remove: o atom:feed elements MUST NOT contain more than one atom:author element. In 4.1.2, replace: o atom:entry elements MUST contain exactly one atom:author element, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. With: o atom:entry elements MUST contain one or more atom:author elements, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. Remove: o atom:entry elements MUST NOT contain more than one atom:author element. Add: o Within the atom:author and atom:contributor elements an atom:entry contains, any single Person SHOULD NOT be mentioned more than once. == Impacts == Listing several people in a single atom:author element and then crediting them individually as atom:contributors is consciously barred by this pace, in anticipation that a separate byline element may be introduced if the functionality is required. CategoryProposals
Re: PaceClarifyAuthorContributor posted
On 5/23/05, Graham [EMAIL PROTECTED] wrote: Add: o Within the atom:author and atom:contributor elements an atom:entry contains, any single Person SHOULD NOT be mentioned more than once. == Impacts == Listing several people in a single atom:author element and then crediting them individually as atom:contributors is consciously barred by this pace, in anticipation that a separate byline element may be introduced if the functionality is required. -1 to this part. Why would you bar it? There is no right answer, so just let it be looser. -1 to atom:byline, should anyone propose it. Robert Sayre
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 12:15 pm, Robert Sayre wrote: -1 to this part. Why would you bar it? There is no right answer, so just let it be looser. Because we have to have this line: Within the atom:author and atom:contributor elements an atom:entry contains, any single Person SHOULD NOT be mentioned more than once. Anything looser makes it very hard to interpret the intended meaning of a set of atom:author and atom:contributor elements programmatically. Please describe a suitable algorithm if you wish to remove this constraint. Graham
Re: Author and contributor
I'm not 100% convinced of the need for contributor, but in the interests of consensus: +1 make atom:author plural +1 keep atom:contributor +1 punt bylines to an extension Cheers, Danny. -- http://dannyayers.com
Re: PaceClarifyAuthorContributor posted
On 5/23/05, Graham [EMAIL PROTECTED] wrote: On 23 May 2005, at 12:15 pm, Robert Sayre wrote: -1 to this part. Why would you bar it? There is no right answer, so just let it be looser. Because we have to have this line: Within the atom:author and atom:contributor elements an atom:entry contains, any single Person SHOULD NOT be mentioned more than once. That's what I'm -1 on. Anything looser makes it very hard to interpret the intended meaning of a set of atom:author and atom:contributor elements programmatically. What is the interop problem you are trying to avoid? You don't just throw in a SHOULD NOT and say otherwise it would be hard. Please describe a suitable algorithm if you wish to remove this constraint. You get N authors and N contributors. The Person rule is terrible overspecification. Robert Sayre
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 12:28 pm, Robert Sayre wrote:
What is the interop problem you are trying to avoid? You don't just
throw in a SHOULD NOT and say otherwise it would be hard.
With the line in place, generating a basic byline is as simple as:
print by '
foreach (atom:author) print atom:author.name;
if (count(atom:contributor)) {
print with contributions from ;
foreach (atom:contributor) print atom:contributor.name;
}
Without that line, the code has to do duplicate detection (including
looking for a name in a list of names, that may be formatted
differently). It is impossible to do this with 100% reliably. Hence
the SHOULD NOT.
Graham
Re: some small comments on 08
On 5/23/05, Anne van Kesteren [EMAIL PROTECTED] wrote: Robert Sayre wrote: What happens when it does contain child elements? I think we should define that for interoperability. (See HTML for what happens when you don't.) This question also applies to the next section. No, that's broken. There can be no expectation of interoperability. I think there should be. Authors will try to do it anyway and defined error handling is better than reverse engineering the market leader's error handling. There is no consensus for me to record, AFAIK. For white-space significance text I need to use 'html' or 'xhtml' instead using PRE or xhtml:pre? I don't understand what you're saying here, but I'm pretty sure every possible whitespace issue has been debated by Graham, Paul, Martin, etc. Feel free to try and explain this again if I don't get it. White-space may be collapsed inside 'text' as currently defined. * 4.2.2 The atom:category Element Why is significant information hidden in attributes? That is bad for i18n and prevents people from defining the expansion of an abbreviation, for example. Minor flaw. It happens. I think you are rushing things too fast. It would be much better if we fixed this. I would never describe this process as too fast. I happen to agree with you here, but I don't think the problem you've found is important. Maybe other folks will. *shrugs wrt the atom:uri element, you're ignoring an incredibly unproductive thread that already occurred on this topic. I want you to recite the Atompub Web Address Oath of Silence: I hereby promise that should I ever again be tempted to raise an issue around the naming of web addresses, I shall strike myself firmly on the head with a heavy blunt object until I come to my senses.[0] Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg13865.html
Re: PaceClarifyAuthorContributor posted
On 5/23/05, Graham [EMAIL PROTECTED] wrote:
On 23 May 2005, at 12:28 pm, Robert Sayre wrote:
What is the interop problem you are trying to avoid? You don't just
throw in a SHOULD NOT and say otherwise it would be hard.
With the line in place, generating a basic byline is as simple as:
print by '
foreach (atom:author) print atom:author.name;
if (count(atom:contributor)) {
print with contributions from ;
foreach (atom:contributor) print atom:contributor.name;
}
Without that line, the code has to do duplicate detection ...
Fully disagree. Try a record album by the Rolling Stones or
Grandmaster Flash and The Furious 5. OK to list the band members as
contributors? Definitely.
later,
Robert Sayre
Re: spec text regarding feed/entry inheritance
Dan Brickley wrote: Is anybody working on a set of AtomPub test cases? Not quite; I'm working up some sample documents around authoring in particular to see if the WG could agree on the author/contributors for particular entries. I'm waiting until the next draft ships before raising that here. In Atom, re inheritance, it'd be great just having a collection of pairs of Atom docs, and a flag to say whether the first can be considered implied (eg. by inheritance rules) from the second. That's a good approach. ps. is it only built-in properties from the Atom ns that can be inherited? Or extensions too? Again, this will reviewed when the next draft comes around. cheers Bill
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 1:09 pm, Robert Sayre wrote: Fully disagree. Try a record album by the Rolling Stones or Grandmaster Flash and The Furious 5. OK to list the band members as contributors? Definitely. Maybe there's a minor bug in the wording here, but the restriction is not intended to block that (mentioning the band and then the member would not count as mentioning someone twice), and the pseudocode I proposed would produce more-or-less sensible results. In any case, the alternative you propose is no model at all, and anything created under would not be decodeable programatically, unless you can provide psuedocode that proves otherwise. Graham
Re: PaceClarifyAuthorContributor posted
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:40]: What is the interop problem you are trying to avoid? You don't just throw in a SHOULD NOT and say otherwise it would be hard. How else would you present a list of distinct authors for a set of entries? What is the point of allowing multiple atom:author elements, if not to require that each of them refer to only a single person (or entity) so that the data can be extracted precisely without resorting to fuzzy matching? I thought wed gone over this. Regards, -- Aristotle
Re: PaceClarifyAuthorContributor posted
On 5/23/05, Graham [EMAIL PROTECTED] wrote: On 23 May 2005, at 1:09 pm, Robert Sayre wrote: Fully disagree. Try a record album by the Rolling Stones or Grandmaster Flash and The Furious 5. OK to list the band members as contributors? Definitely. Maybe there's a minor bug in the wording here, There's a large bug in the idea, IMO. In any case, the alternative you propose is no model at all, and anything created under would not be decodeable programatically, unless you can provide psuedocode that proves otherwise. Fully disagree. I reject the notion that you have generate a complete sentence. You can trivially generate a two lists of strings. Robert Sayre
Re: PaceClarifyAuthorContributor posted
* Graham [EMAIL PROTECTED] [2005-05-23 12:50]: http://www.intertwingly.net/wiki/pie/PaceClarifyAuthorContributor +1 Regards, -- Aristotle
Re: PaceClarifyAuthorContributor posted
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:30]: -1 to atom:byline, should anyone propose it. We already have pretty good consensus that bylines, if needed by anyone, will be implemented in an extension, not in Atom. No need to punch it down here again separately. Regards, -- Aristotle
Re: atom:modified indicates temporal ORDER not version....
I just found an excellent article on the subject of identity: http://plato.stanford.edu/entries/identity/ It is heavy reading. But it does give an excellent overview of the subject. I can't say that I managed in a couple of hours to fully digest all the information in there. Henry On 22 May 2005, at 02:51, Robert Sayre wrote: On 5/21/05, Henry Story [EMAIL PROTECTED] wrote: On 22 May 2005, at 02:27, Robert Sayre wrote: On 5/21/05, Bob Wyman [EMAIL PROTECTED] wrote: Robert Sayre wrote: Temporal order of what? They are all the same entry, so what is it you are temporally ordering? We are discussing the temporal ordering of multiple non- identical *instances* of a single Atom entry. It is common in the realm of software engineering to deal with this concept of instances. Things are often considered to be simultaneously different and the same. (I am who I am today -- as I was when I was a child, nonetheless, I am very different today than I was when I was a child. The instance of me today differs from the instance of me that you might have come across many years ago.) But, perhaps this concept is too abstract for some readers... I'm unconvinced. Have a giant -1. How can you be unconvinced about something so fundamentally basic to human thought? People change over time. When you clip your nails your body is not the same as it was before, yet as far as the law is concerned, you are the same person who went to whatever school you went to. Change over time exists. For something to be able to change there has to be something that is the thing that changes. Really you can't get more basic than this. If you are left to argument over this, I would suggest moving your discussion over to a philosophy forum. Gee, Henry, maybe you should draw us a UML diagram to explain all this. Robert Sayre
Re: PaceClarifyAuthorContributor posted
On 5/23/05, A. Pagaltzis [EMAIL PROTECTED] wrote: * Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:30]: -1 to atom:byline, should anyone propose it. We already have pretty good consensus that bylines, if needed by anyone, will be implemented in an extension, not in Atom. Is your name Tim or Paul? If not, please avoid declaring what the consensus is. It only causes problems. Trust me on this. No need to punch it down here again separately. -1 to atom:byline. :) Robert Sayre
Re: Author and contributor
+1 make atom:author plural +1 keep atom:contributor - Robin Cover
Re: PaceClarifyAuthorContributor posted
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 14:45]: On 5/23/05, A. Pagaltzis [EMAIL PROTECTED] wrote: * Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:30]: -1 to atom:byline, should anyone propose it. We already have pretty good consensus that bylines, if needed by anyone, will be implemented in an extension, not in Atom. Is your name Tim or Paul? If not, please avoid declaring what the consensus is. It only causes problems. Trust me on this. Sorry; it is not for me to determine whether the thus far 8 +1 votes in favour of punting any byline element to an extension constitute a consensus. In any case, the point was that it clearly doesnt look like anyone is trying to propose such a thing, so we should please stick to the points that are actually being discussed. Regards, -- Aristotle
Re: PaceClarifyAuthorContributor posted
On 5/23/05, A. Pagaltzis [EMAIL PROTECTED] wrote: In any case, the point was that it clearly doesn't look like anyone is trying to propose such a thing, so we should please stick to the points that are actually being discussed. Ah, yes, the point. That would be banning duplicate 'Persons' will obviate the need for fuzzy logic and constitute a coherent 'model' to program against. YMMV. Robert Sayre
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 02:29:33PM +0200, A. Pagaltzis wrote: * Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:40]: What is the interop problem you are trying to avoid? You don't just throw in a SHOULD NOT and say otherwise it would be hard. How else would you present a list of distinct authors for a set of entries? What is the point of allowing multiple atom:author elements, if not to require that each of them refer to only a single person (or entity) so that the data can be extracted precisely without resorting to fuzzy matching? I thought we???d gone over this. I think we're trying to do too much here. Why on earth are we disallowing a list of authors that includes the same person twice? Why does it actually cause problems? I can write the following English sentence: The book was written by James Aylett, James Aylett, and James Aylett. I can do so meaning the /same/ James Aylett, using the repetition for effect. Banning this in Atom doesn't actually seem to have any good reason beyond a kind of technical tidying. Surely it's more useful to have the semantics if you list the same person twice, you mean it (leaving mean it to be a context of the feed; the feed description could explain it, for instance). So I'm -1 on this restriction, as I don't think it actually helps anyone. If you've got a way of displaying a list of people who wrote an article, then you've got a way that will work no matter which people you put in there. If the author of an entry or feed really wants the same person multiple times, who are we to stop them? James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
* James Aylett [EMAIL PROTECTED] [2005-05-23 15:15]: I think we're trying to do too much here. Why on earth are we disallowing a list of authors that includes the same person twice? Why does it actually cause problems? I can write the following English sentence: The book was written by James Aylett, James Aylett, and James Aylett. Sorry, I got confused because I read the Impacts section Robert quoted before reading the entire Pace in detail. This is what the Impacts section of the Pace refers to: authornameJames Aylett, James Aylett, and James Aylett/name/author +1 to forbidding this. This is what the last change directed in the Pace forbids and which the last sentence in the Rationale refers to: authornameJames Aylett/name/author authornameJames Aylett/name/author authornameJames Aylett/name/author -1 to forbidding this. In other words, I am still +1 to most of the Pace, save for the one addition to 4.1.2 which imposes this restriction. Which is actually precisely what Robert objected to once you see past the irrelevant squabble over his mention of the byline. :-) Regards, -- Aristotle
Re: Deterministic content models (conflict with Atom Publishing Protocol?)
/ Thomas Broyer [EMAIL PROTECTED] was heard to say: | I'm sorry to raise this issue back again but... | | The Atom Publishing Protocol defines SOAP bindings. This (in my mind) | means there will be WSDL files over there. WSDL rely on XML Schema | which in turn are limited to deterministic content models. | | Will the APP limit Atom entries in SOAP envelopes content model to | fit WSDL/XML Schema constraints (actually, the APP will already need | to limit Atom entries to have a mandatory atom:content I think)? | | Or should the Atom Syndication Format use deterministic content models | to allow XML Schema, thus such uses as WSDL for Web Services? | | I'm personally in favor of the second one, as it also simplifies Atom | parser/processor development. I'm operating on about two-hours of sleep in the last 48 and time-shifted across six time zones. I say that by way of explanation in case what I'm about to say is more than usually stupid. There is no 1:1 correspondence between schemas and documents. You can have as many schemas as you want. If your application demands additional constraints, such as determinism, you can define your own schema that enforces them. Then your system will reject documents that it can't handle. I would strongly oppose any attempt to make the schema deterministic without simultaneously making the normative prose deterimistic. I didn't make the RELAX NG grammar impossible to translate literally into W3C XML Schemas because I thought it would be fun, I attempted to model the constraints in the normative prose as closely as possible and that was the result. I would prefer to leave things as they are because I think it makes it easier for authors. But you can make a solid argument that determinism is easier for authors too, so I wouldn't object to making Atom deterministic in the normative prose, I suppose. Be seeing you, norm -- Norman Walsh [EMAIL PROTECTED] | There has never been a perfect http://nwalsh.com/| government, because men have passions; | and if they did not have passions, | there would be no need for | government.-- Voltaire pgpAbnuAJpH07.pgp Description: PGP signature
Re: PaceClarifyAuthorContributor posted
* James Aylett [EMAIL PROTECTED] [2005-05-23 14:01+0100] On Mon, May 23, 2005 at 02:29:33PM +0200, A. Pagaltzis wrote: * Robert Sayre [EMAIL PROTECTED] [2005-05-23 13:40]: What is the interop problem you are trying to avoid? You don't just throw in a SHOULD NOT and say otherwise it would be hard. How else would you present a list of distinct authors for a set of entries? What is the point of allowing multiple atom:author elements, if not to require that each of them refer to only a single person (or entity) so that the data can be extracted precisely without resorting to fuzzy matching? I thought we???d gone over this. I think we're trying to do too much here. Why on earth are we disallowing a list of authors that includes the same person twice? Why does it actually cause problems? I can write the following English sentence: The book was written by James Aylett, James Aylett, and James Aylett. I can do so meaning the /same/ James Aylett, using the repetition for effect. Banning this in Atom doesn't actually seem to have any good reason beyond a kind of technical tidying. Surely it's more useful to have the semantics if you list the same person twice, you mean it (leaving mean it to be a context of the feed; the feed description could explain it, for instance). It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). Dan
Re: PaceClarifyAuthorContributor posted
On 5/23/05, Dan Brickley [EMAIL PROTECTED] wrote: It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). Why would that be good? Robert Sayre
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 10:35:07AM -0400, Robert Sayre wrote: It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). Why would that be good? I'm -1 on having the spec say anything. I'm +0.5 on the spec explicitly saying that you can't infer anything. I don't see this as something that has any actual technical impact - I think people are trying to clear up a possible ambiguity that is useful to allow. One reason why I think it's not a good idea to restrict this is that if we say repetition of the same atom:name implies distinct Person referents, we're implying that you shouldn't have the same Person referent using different names (eg: pseudonyms) - something that is impossible to detect, and so can't reasonably be part of a spec. And if we're not trying to disallow the same person being referred to by two distinct textual strings, then why are we disallowing it for two identical textual strings? Seems an arbitrary non-technical semantic to me. James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 10:35-0400] On 5/23/05, Dan Brickley [EMAIL PROTECTED] wrote: It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). Why would that be good? So we can be clear on the conclusions that can be drawn from an Atom description of a document, eg. if creating an A-Z index of authors (where two distinct John Smith entries might be needed), or merging against other information about the author(s) (eg. their photo url, lists of interests, posts/comments in other systems, etc). Dan
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 10:42:25AM -0400, Dan Brickley wrote: It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). So we can be clear on the conclusions that can be drawn from an Atom description of a document, eg. if creating an A-Z index of authors (where two distinct John Smith entries might be needed), or merging against other information about the author(s) (eg. their photo url, lists of interests, posts/comments in other systems, etc). Why can't we just have the semantics that if you have two Person constructs, you'll get the effects of having two Person constructs? That way it's up to the producer of the feed - if they want the semantics that they'll have identical names listed twice in author lists, indexes or whatever, they can do that. If they'd rather not, they can do the uniqueness filtering on creation. Baking it into the spec strikes me as needlessly creating rules - we can be precise about what the semantics are without this rule, IMHO. James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
* Dan Brickley [EMAIL PROTECTED] [2005-05-23 16:40]: It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). Doesnt seem to me like there should be any implication. Any user interface that presents a list of authors which contains identically named, but distinct authors will have to somehow disambiguate them in order to avoid confusing the user sooner or later. If a publisher wants to be certain of a particular interpretation he will need to make the elements distinct anyway. I was going to mention that there are two other elements in atom:author besides atom:name, but now that I think about it Im not sure if two elements with identical content in the atom:name element but divergent information in the others can automatically be thought of as referring to different authors or not. I think it is intuitive and should be implied that they are different authors, though, even if they are different only in the sense that they refer to the same physical person acting in different roles. I suppose that in this way, a meaningful, though application-specific subset of the semantics offered by allowing atom:category in these elements would be implementable. Whatever it is, I dont see a strong case for prescribing a any particular interpretation here. Regards, -- Aristotle
Re: PaceClarifyAuthorContributor posted
* James Aylett [EMAIL PROTECTED] [2005-05-23 15:43+0100] On Mon, May 23, 2005 at 10:35:07AM -0400, Robert Sayre wrote: It would be good if Atom were clear on whether repetition of the exact same name implies the two authors are distinct (eg. things written by father/son pairings, where they have same name). Why would that be good? I'm -1 on having the spec say anything. I'm +0.5 on the spec explicitly saying that you can't infer anything. I don't see this as something that has any actual technical impact - I think people are trying to clear up a possible ambiguity that is useful to allow. I'm fine with either design; was just a plea for the chosen design to be documented clearly. Note: the description of multiple authors of an entry does not in itself imply that each of these descriptions is about a different entity would be plenty. One reason why I think it's not a good idea to restrict this is that if we say repetition of the same atom:name implies distinct Person referents, we're implying that you shouldn't have the same Person referent using different names (eg: pseudonyms) - something that is impossible to detect, and so can't reasonably be part of a spec. Fair point. Again I'm not arguing that distinctness be part of the spec, just that people have a tendency to assume that distinctness is intended, so a few words to be explicit on Atom's assumptions would be worthwhile. I'm reminded of http://internetalchemy.org/2005/04/unique-name-assumption Two sons and two fathers went to a pizza restaurant. They ordered three pizzas. When they came, everyone had a whole pizza. How can that be? And if we're not trying to disallow the same person being referred to by two distinct textual strings, then why are we disallowing it for two identical textual strings? Seems an arbitrary non-technical semantic to me. I'm fine with allowing it. But there are two quite different designs here that look the same at the instance level; only the Atom spec can arbitrate between users who take differing interpretations. Dan James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: multiple ids
On Sunday, May 22, 2005, at 07:14 PM, Paul Hoffman wrote: At 2:11 AM -0400 5/21/05, Bob Wyman wrote: If multiple atom:entry elements with the same atom:id value appear in an Atom Feed document, they describe the same entry. +1. I can live with Tim's original wording because the phrase that Bob removes is impossible to measure or enforce, but Bob's wording is cleaner for the same result. Yeah, I like Bob's better too. And if the word appear can be interpreted to refer to the action of first appearing, and not to the state of existing (having been copied from the feed where it appeared)...yes, I'm totally twisting it to my liking...then consuming apps are free to determine for themselves whether the entries originated (appeared) in the same feed and are therefore the same entry or whether one of them is trying to DOS the other. ...but I'd rather that we state that If multiple atom:entry elements originating in the same Atom Feed (document?) have the same atom:id value, they describe the same entry. We MIGHT consider omitting the word document. It's purpose is of course to speak to multiple instances of an entry within the same document, but the same rule applies to multiple instances appearing in a feed at different times. Removing document would change the focus of the sentence, making the fact that multiple instances can appear in the same document less clear...or even totally unclear...so perhaps two sentences or something like this would be even better: If multiple atom:entry elements originating in the same Atom feed have the same atom:id value, whether they exist simultaneously in one document or in different instances of the feed document, they describe the same entry.
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 3:45 pm, James Aylett wrote: Why can't we just have the semantics that if you have two Person constructs, you'll get the effects of having two Person constructs? That way it's up to the producer of the feed - if they want the semantics that they'll have identical names listed twice in author lists, indexes or whatever, they can do that. That's the intention of the spec, and the restriction. If you can come up with better wording, then we can go with that. The other intention is that one person shouldn't (and doesn't need to be) listed as both an author and a contributor (ie a author is by definition a contributor). Does anyone object to that? Graham
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 04:14:15PM +0100, Graham wrote: The other intention is that one person shouldn't (and doesn't need to be) listed as both an author and a contributor (ie a author is by definition a contributor). Does anyone object to that? If your intention is to disallow James Aylett as both contributor and author, I'm -0 (at least, possibly +0). If your intention is to disallow James Aylett and James Lark as authors, and James Aylett as contributor (with James Lark as a second contributor) then I'm -1. Because that's semantically the same as Funky Group Name as author, and James Aylett and James Lark as contributors, which I would find useful. James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 11:12:33AM -0400, Dan Brickley wrote: I'm fine with either design; was just a plea for the chosen design to be documented clearly. Note: the description of multiple authors of an entry does not in itself imply that each of these descriptions is about a different entity would be plenty. I'd be happy with that (particularly as the concept, but I'm happy with it textually as well). James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
On 5/23/05, Graham [EMAIL PROTECTED] wrote: The other intention is that one person shouldn't (and doesn't need to be) listed as both an author and a contributor (ie a author is by definition a contributor). Does anyone object to that? Yes. It's a total rathole. Just state the cardinality and be done with it. Robert Sayre
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 2:55 pm, James Aylett wrote: -- atom:author atom:personatom:nameAnne Rice/atom:name/atom:person atom:personatom:nameHoward Allen O'Brien/atom:name/ atom:person /atom:author -- then I've hacked around your restriction. That's still the same person listed twice. As I understand your wording, it's violating the spec - but it's undetectable. No way on earth any Atom processor that isn't a human being is going to notice, so how can we reasonably put that as a restriction in the spec? That's exactly why there's a restriction, because the processor can't tell for itself what's going on, so it needs the publisher to provide correct data about what's what. With the restriction, the processor can safely treat them as separate people and tell the end user This entry was written by Anne Rice and Howard Allen O'Brien. Without the restriction, all it can conclude is The names Anne Rice and Howard Allen O'Brien are in some way related to the authorship of this entry Graham
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 04:20:44PM +0100, Graham wrote: -- atom:author atom:personatom:nameAnne Rice/atom:name/atom:person atom:personatom:nameHoward Allen O'Brien/atom:name/ atom:person /atom:author -- then I've hacked around your restriction. That's still the same person listed twice. As I understand your wording, it's violating the spec - but it's undetectable. No way on earth any Atom processor that isn't a human being is going to notice, so how can we reasonably put that as a restriction in the spec? That's exactly why there's a restriction, because the processor can't tell for itself what's going on, so it needs the publisher to provide correct data about what's what. With the restriction, the processor can safely treat them as separate people and tell the end user This entry was written by Anne Rice and Howard Allen O'Brien. Without the restriction, all it can conclude is The names Anne Rice and Howard Allen O'Brien are in some way related to the authorship of this entry Why can't you conclude that the entry was written by Anne Rice and Howard Allen O'Brien? That's what it says (well, authored). It's the responsibility of the creator of the feed to ensure it makes sense - our job with Atom isn't really to try to define the semantics of authorship, just to provide a way of expressing authorship (no matter what your semantics are). I don't see a /technical/ reason for prohibiting this. None of the examples given cause me any problems, providing (as danbri says) that the spec makes it clear that we're not imposing these restrictions. Let the publishers decide what to say (because they will anyway, even if only in 0.001% of the cases and by mistake in an undetectable way). James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: atom:type, xsl:output
On May 23, 2005, at 2:43 AM, Graham wrote: * When @type=html then the content of the element is a xsd:string [1] of an HTML DIV element plus optional insignificant whitespace around it. Which version of HTML is defined? How do you differentiate between HTML 4.01, HTML 3.2, the upcoming HTML 5, or nonstandard HTML (like with marquee elements)? I believe the answer would be street HTML, not any specific version. Agreed. What it says is SHOULD be suitable for handling as HTML. I.e. can be passed to your local HTML rendering control, which is doubtless a forgiving tag-soup engine. -Tim
Re: PaceClarifyAuthorContributor posted
On 5/23/05, James Aylett [EMAIL PROTECTED] wrote: I don't see a /technical/ reason for prohibiting this. None of the examples given cause me any problems, providing (as danbri says) that the spec makes it clear that we're not imposing these restrictions. Let the publishers decide what to say (because they will anyway, even if only in 0.001% of the cases and by mistake in an undetectable way). Exactly. It's extremely easy to think of cases that don't fit the model proposed. Consider the Huffington Post, where the feed might list Arianna Huffington as the author, and everybody else as a contributor. But, it would make sense to list her as a contributor as well. Robert Sayre
Re: PaceClarifyAuthorContributor posted
On May 23, 2005, at 5:18 AM, Graham wrote: On 23 May 2005, at 1:09 pm, Robert Sayre wrote: Fully disagree. Try a record album by the Rolling Stones or Grandmaster Flash and The Furious 5. OK to list the band members as contributors? Definitely. Maybe there's a minor bug in the wording here Uh, Graham, I thought your Pace did a good job of capturing the consensus that seems to be emerging, and then slipped in just a little extra with the name-duplication rules. I'm with Rob, that stuff is past the 80/20 point, I'd suggest you pare down the Pace as a friendly amendment. -Tim
Re: PaceClarifyAuthorContributor posted
On May 23, 2005, at 7:45 AM, James Aylett wrote: Baking it into the spec strikes me as needlessly creating rules - we can be precise about what the semantics are without this rule, IMHO. +1 -Tim
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 4:58 pm, Tim Bray wrote: Uh, Graham, I thought your Pace did a good job of capturing the consensus that seems to be emerging, and then slipped in just a little extra with the name-duplication rules. I'm with Rob, that stuff is past the 80/20 point, I'd suggest you pare down the Pace as a friendly amendment. -Tim Pared down. Graham
Re: PaceClarifyAuthorContributor posted
On 23 May 2005, at 4:52 pm, Robert Sayre wrote: Exactly. It's extremely easy to think of cases that don't fit the model proposed. Consider the Huffington Post, where the feed might list Arianna Huffington as the author, and everybody else as a contributor. But, it would make sense to list her as a contributor as well. Why? She's already credited as the author. If you can explain why that isn't completely redundant and confusing to software, a gold star to you. Graham
Re: PaceClarifyAuthorContributor posted
On Monday, May 23, 2005, at 09:12 AM, Dan Brickley wrote: I'm reminded of http://internetalchemy.org/2005/04/unique-name-assumption Two sons and two fathers went to a pizza restaurant. They ordered three pizzas. When they came, everyone had a whole pizza. How can that be? Possible answers: * One of them already had a pizza when they entered the restaurant. * They stole a pizza from somebody else in the restaurant before theirs came. * The one that didn't participate in the joint ordering of three pizzas placed a separate order for one pizza, which was filled before the order for three. * When they came refers to when the came to the restaurant--they all had pizzas before they arrived, but wanted three more. BTW, +1 to the Pace
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 05:08:10PM +0100, Graham wrote: Exactly. It's extremely easy to think of cases that don't fit the model proposed. Consider the Huffington Post, where the feed might list Arianna Huffington as the author, and everybody else as a contributor. But, it would make sense to list her as a contributor as well. Why? She's already credited as the author. If you can explain why that isn't completely redundant and confusing to software, a gold star to you. Erm ... it's not redundant, because it's expressing something that a person might want to express. Software can't really be confused by this, providing we make semantics clear - and I don't think people will be confused (unless the feed producer intended them to be confused). However I'm not religious about this particular issue, and I'm +1 on the latest PaceClarifyAuthorContributor. I think we still need a clarification along the lines of what danbri suggested, to make things as obvious as possible. James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: PaceClarifyAuthorContributor posted
On 5/23/05, Graham [EMAIL PROTECTED] wrote: On 23 May 2005, at 4:52 pm, Robert Sayre wrote: Exactly. It's extremely easy to think of cases that don't fit the model proposed. Consider the Huffington Post, where the feed might list Arianna Huffington as the author, and everybody else as a contributor. But, it would make sense to list her as a contributor as well. Why? She's already credited as the author. If you can explain why that isn't completely redundant and confusing to software, a gold star to you. Authorship is confusing to software, silly. - In section 4.2.3, append to: The atom:contributor element is a Person construct that indicates a person or other entity who contributed to the entry or feed. The text: and who is not also a named author. - -1. Robert Sayre
posted PaceAuthorContributor
http://www.intertwingly.net/wiki/pie/PaceAuthorContributor == Abstract == Allow multiple authors. == Status == Open == Rationale == The current draft only allows one atom:author per entry, meaning either: - All authors of a document have to be shoehorned into that atom:author element - One author has to be chosen as primary and the rest are contributors == Notes == Neither bylines nor inheritance are dealt with by this Pace. == Proposal == In 4.1.1, replace: o atom:feed elements MUST contain exactly one atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. with: o atom:feed elements MUST contain one or more atom:author elements, UNLESS all of the atom:feed element's child atom:entry elements contain at least one atom:author element. Remove: o atom:feed elements MUST NOT contain more than one atom:author element. In 4.1.2, replace: o atom:entry elements MUST contain exactly one atom:author element, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. With: o atom:entry elements MUST contain one or more atom:author elements, unless the atom:entry contains an atom:source element which contains an atom:author element, or, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. Remove: o atom:entry elements MUST NOT contain more than one atom:author element. == Impacts == CategoryProposals
Re: PaceClarifyAuthorContributor posted
On Mon, May 23, 2005 at 10:36:33AM -0600, Antone Roundy wrote: I'm reminded of http://internetalchemy.org/2005/04/unique-name-assumption Two sons and two fathers went to a pizza restaurant. They ordered three pizzas. When they came, everyone had a whole pizza. How can that be? Possible answer [snip] They participated in collective ownership, had being an indication of possession, not of eating. (The question isn't terribly well phrased, because the 'and' in Two sons and two fathers strongly suggests, to me at least, that they are distinct sets.) James -- /--\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
Re: posted PaceAuthorContributor
On May 23, 2005, at 9:56 AM, Robert Sayre wrote: http://www.intertwingly.net/wiki/pie/PaceAuthorContributor == Abstract == Allow multiple authors. For those whose enquiring minds want to know, the difference between Graham's version and Robert's version is that Graham's version contains: = In section 4.2.3, append to: The atom:contributor element is a Person construct that indicates a person or other entity who contributed to the entry or feed. The text: and who is not also a named author. == Otherwise, they are pretty well identical as far as I can tell. I mildly prefer Robert's version, this feels like trying to legislate morality. --Tim
Re: posted PaceAuthorContributor
On 23 May 2005, at 6:20 pm, Tim Bray wrote: this feels like trying to legislate morality. --Tim If I want to give someone full credit for an entry, do I: a) Just credit them as an author? b) Or do I need to credit them as an author and a contributor? If (a) is enough, what happens when someone does (b)? Or if the answer is (b), does someone else doing (a) imply that that author contributed nothing? Implementers need to know this stuff. Graham
Re: posted PaceAuthorContributor
On May 23, 2005, at 10:38 AM, Graham wrote: On 23 May 2005, at 6:20 pm, Tim Bray wrote: this feels like trying to legislate morality. --Tim If I want to give someone full credit for an entry, do I: a) Just credit them as an author? b) Or do I need to credit them as an author and a contributor? I suspect most people would guess right, and a culture of doing the right thing would develop. If you're worried, one good way to address the issue would be to say that the semantics of this element are based on the Dublin Core's [dc:creator], DC is pretty clear as I recall. I've been thinking that would be a good idea anyhow. -Tim
Re: posted PaceAuthorContributor
On 23 May 2005, at 6:52 pm, Tim Bray wrote: I suspect most people would guess right, and a culture of doing the right thing would develop. Dave, impersonating Tim like this is not on. Graham
atom:author clarification
Hiya,
I'm trying to understand the intention of the draft, together with some of
the comments posted here recently. I've only been looking at Atom for a
couple of days so I may be misunderstanding.
As I understand it, the intention is that atom:author within atom:feed
applies to all child atom:entry elements; that is, the value is inherited.
This being the case I have a dilemma with a feed I would like to aggregate
from others.
If I collect the atom:entry elements from those feeds and include them
in another feed that I produce, there is no place for my name to appear
within the new feed. That is, I am not the author of the entries so I
cannot appear as the atom:author of any atom:entry. And if the intention
is that the atom:author within atom:feed be inherited then I cannot place
my name there.
The only other element that seems appropriate is the atom:generator
element, however it is implied that this is the tool used to generate
it ('the agent used'), rather than the person whose responsibility the
feed is. In this case I am not looking for any particular 'advertisement'
of name, but a means whereby a reader can examine the feed and know who
is responsible (to blame) for it.
Is there a suitable place for identifying the feed's author without
affecting the entries themselves ? Is the atom:feed/atom:author a suitable
place for this ?
--
Gerph http://gerph.org/
... And I'm lonely here inside of me.
Re: Deterministic content models (conflict with Atom Publishing Protocol?)
Norman Walsh wrote: There is no 1:1 correspondence between schemas and documents. You can have as many schemas as you want. If your application demands additional constraints, such as determinism, you can define your own schema that enforces them. Then your system will reject documents that it can't handle. Won't that cause interoperability problems? Well, actually, I misunderstood WSDL a bit: you're actually not forced to use XML Schema in WSLD (would it be 1.0, 1.1 or 2.0), though I think (I have no figure about that) XML Schema is the most widely supported schema language in WSDL implementations, and providing no interop with XML Schema might still cause interop problems. I would strongly oppose any attempt to make the schema deterministic without simultaneously making the normative prose deterimistic. Sure! I wasn't actually strictly speaking of schemas. I would prefer to leave things as they are because I think it makes it easier for authors. I Agree, though many HTML pages which I've looked at the source has their HEAD content in the form: * TITLE * META * LINK * STYLE or SCRIPT * SCRIPT or STYLE so a deterministic content model would be a pain I think... But you can make a solid argument that determinism is easier for authors too, so I wouldn't object to making Atom deterministic in the normative prose, I suppose. Hmm, I can't see any such argument... -- Thomas Broyer
Re: posted PaceAuthorContributor
--On May 23, 2005 10:52:47 AM -0700 Tim Bray [EMAIL PROTECTED] wrote: If you're worried, one good way to address the issue would be to say that the semantics of this element are based on the Dublin Core's [dc:creator], DC is pretty clear as I recall. I've been thinking that would be a good idea anyhow. Let's call it atom:creator, then, and actually use the DC definition. Not because DC is better, but because it makes the metadata crosswalks (interoperability) work smoothly. wunder -- Walter Underwood Principal Architect, Verity
Re: posted PaceAuthorContributor
* Walter Underwood [EMAIL PROTECTED] [2005-05-23 11:16-0700] --On May 23, 2005 10:52:47 AM -0700 Tim Bray [EMAIL PROTECTED] wrote: If you're worried, one good way to address the issue would be to say that the semantics of this element are based on the Dublin Core's [dc:creator], DC is pretty clear as I recall. I've been thinking that would be a good idea anyhow. Let's call it atom:creator, then, and actually use the DC definition. +1 Not because DC is better, but because it makes the metadata crosswalks (interoperability) work smoothly. FWI the original DC had Author: The person(s) primarily responsible for the intellectual content of the object (see http://dublincore.org/workshops/dc1/report.shtml first workshop report). After the 3rd workshop (on DC and images, in 1996) this became http://www.dlib.org/dlib/january97/oclc/01weibel.html#table AUTHOR OR CREATOR The person(s) or organization(s) primarily responsible for the intellectual content of the resource. What we have today is http://dublincore.org/documents/dcmi-terms/#H2 An entity primarily responsible for making the content of the resource. (Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.) Aside- the DCMI Localization and Internationalization Working Group, http://dublincore.org/groups/languages/ have been busy getting DC definitions translated into other languages. See the WG homepage for links. I realise it is just one part of Atom, but it is handy at least to have had that part of the translation effort done already. Calling it atom:creator makes sense to me; DC changed to use 'creator' rather than 'author' to accomodate digital image use cases. These also seem appealing w.r.t. Atom; there are a *lot* more digital images being shared and described now than there were back in 1996 when DC made the change. Dan
Atom 08 - HTML Version
Hi, I will use the HTML version http://ietf.levkowetz.com/tools/rfcmarkup/rfcmarkup.cgi?url=http:// ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- format-08.txt for something specific. Is it fine, or do people recommend another HTML Version of [[[ Expires: October 20, 2005 April 18, 2005 The Atom Syndication Format draft-ietf-atompub-format-08 ]]] - http://www.ietf.org/internet-drafts/draft-ietf-atompub- format-08.txt -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Atom 08 - HTML Version
At 4:20 PM -0400 5/23/05, Karl Dubost wrote: Hi, I will use the HTML version http://ietf.levkowetz.com/tools/rfcmarkup/rfcmarkup.cgi?url=http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub-format-08.txt for something specific. Is it fine, or do people recommend another HTML Version of [[[ Expires: October 20, 2005 April 18, 2005 The Atom Syndication Format draft-ietf-atompub-format-08 ]]] - http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt The latter, definitely. The former makes good guesses about HTMLizing, but may have errors introduced by the automated guessing process. --Paul Hoffman, Director --Internet Mail Consortium
Re: Deterministic content models (conflict with Atom Publishing Protocol?)
Thomas Broyer wrote: I Agree, though many HTML pages which I've looked at the source has their HEAD content in the form: * TITLE * META * LINK * STYLE or SCRIPT * SCRIPT or STYLE so a deterministic content model would be a pain I think... Wow! Sorry, it would NOT be pain (hey hey you might be the only one needing some rest ;o) -- Thomas Broyer
Re: Atom 08 - HTML Version
Paul Hoffman wrote: The latter, definitely. The former makes good guesses about HTMLizing, but may have errors introduced by the automated guessing process. You might have wanted to point to http://atompub.org/2005/04/18/draft-ietf-atompub-format-08.html -- Thomas Broyer
Review of Atom 0.8 Spec against W3C QA Specification Guidelines
This is a review of [[[ Network Working Group M. Nottingham, Ed. Internet-Draft R. Sayre, Ed. Expires: October 20, 2005 April 18, 2005 The Atom Syndication Format draft-ietf-atompub-format-08 ]]] - http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- format-08.txt against W3C QA Framework: Specification Guidelines. http://www.w3.org/TR/qaframe-spec/ (A new version of Specification Guidelines will be published next week in Proposed Recommendation. This review has been made with the Editor's draft version which is not public yet). Short Intro: W3C QA Specification Guidelines has been designed to help W3C editors write better specifications. It focuses on how to define and specify conformance for a specification. Additionally, it addresses how a specification might allow variation among conforming implementations. I have done the review of Atom 0.8 to test W3C QA Specification Guidelines with an external technical document and I thought it could be also useful to the Atom community. The QA Specification Guidelines Specification is organized with a series of mandatory Requirements and optional Good Practices. For each of them, you will find an explanation and a benefits analysis, plus techniques, examples, and other readings. You might want to read the Test FAQ too. http://www.w3.org/QA/WG/2005/01/test-faq to create a test suite for Atom and shared between developers http://intertwingly.net/wiki/pie/ConformanceTests Best Regards. Requirement 01: Include a conformance clause. NO. There is indeed a section which is an attempt of conformance clause but doesn't fulfill all the requirements that we could expect from such sections. It would be good to have a specific table of content item with the words conformance to help developers to understand right away the conformance model of the specification. Requirement 02: Define the scope. YES. In the introduction of the document are given what the technology is about. Though it could be certainly improved, by giving a more systemic way of describing the scope. Requirement 03: Identify who or what will implement the specification. NO. For example, we can see Atom Processors in the specification, but it is defined what's an atom processor. The list of class of products would help to define the conformance model, and then the conformance clause. What about authoring tools? What about validators? etc. Requirement 04: Make a list of normative references. YES. The list of normative references is given. Requirement 05: Define the terms used in the normative parts of the specification. NO. Atom Processors is not defined. Atom Feed is defined, Atom Entry as well. Some of the important concept really need more definitions. It's really important because it avoids broad interpretation of some terms. Requirement 06: Create conformance labels for each part of the conformance model. NO. The conformance model being not completely clear. It's very hard to know what are the different type of conformance and then to put labels on them. Requirement 07: Use a consistent style for conformance requirements and explain how to distinguish them. YES. the RFC is using a consistent style explained in Notational conventions. Requirement 08: Indicate which conformance requirements are mandatory, which are recommended, and which are optional. YES/NO. Because of the lack of conformance clause clearly defined, it might be confusing. For example This specification does not define a DTD for Atom Documents, and hence does not require them to be valid (in the sense used by XML). But a document could be valid against the RELAXNG Schema. Is there any reason to not make the schema normative? Requirement 09: If the technology is subdivided, then indicate which subdivisions are mandatory for conformance. N/A. The technology seems to not be modular and then not subdivided. Requirement 10: If the technology is subdivided, then address subdivision constraints. N/A. Requirement 11: Address Extensibility. YES. Perfectly addressed. Requirement 12: Identify deprecated features. N/A. None. Requirement 13: Define how each class of product handles each deprecated feature. N/A. None. List of Good Practices (OPTIONAL): Good Practice 01: Define the specification's conformance model in the conformance clause. NO. Good Practice 02: Specify in the conformance clause how to distinguish normative from informative content. NO. Good Practice 03: Provide the wording for conformance claims. NO. Good Practice 04: Provide an Implementation Conformance Statement Pro Forma. NO. Good Practice 05: Require an Implementation Conformance Statement as part of
Re: Atom 08 - HTML Version
Le 05-05-23 à 16:54, Paul Hoffman a écrit : ]]] - http://www.ietf.org/internet-drafts/draft-ietf-atompub- format-08.txt The latter, definitely. The former makes good guesses about HTMLizing, but may have errors introduced by the automated guessing process. Thanks. :) The bad thing with IETF specification is that we can't give precise references to the text. I have used the text version instead. I'm sending another mail. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Atom 08 - HTML Version
Monday, May 23, 2005, 9:20:07 PM, Karl Dubost wrote: Hi, I will use the HTML version http://ietf.levkowetz.com/tools/rfcmarkup/rfcmarkup.cgi?url=http:// ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- format-08.txt Only the text version is normative, but the editor produces an HTML version of the specification here. If you want an HTML version, it is probably what you are looking for. http://atompub.org/2005/04/18/draft-ietf-atompub-format-08.html -- Dave
Re: PaceClarifyAuthorContributor posted
Dan Brickley wrote: So we can be clear on the conclusions that can be drawn from an Atom description of a document, eg. if creating an A-Z index of authors You won't be able to produce such an index anyway, because atom:name is free text. Names might appear as John Smith, J. Smith and Smith, J.. Moreover, all these three cases might refer to the same John Smith, or two or three distinct John Smith (well, actually, one might also be James Smith, or Janet Smith ;-) ) I already raised up the Person identity [1] matter, I was answered it's not an Atom matter, use an extension (such as FOAF). I agree. [1] http://www.imc.org/atom-syntax/mail-archive/msg13816.html -- Thomas Broyer
Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines
Hi Karl. Thanks for the review. Some thoughts inline. On 5/23/05, Karl Dubost [EMAIL PROTECTED] wrote: Requirement 01: Include a conformance clause. NO. There is indeed a section which is an attempt of conformance clause but doesn't fulfill all the requirements that we could expect from such sections. It would be good to have a specific table of content item with the words conformance to help developers to understand right away the conformance model of the specification. I tend to agree with Paul wrt conformance levels: http://www.imc.org/atom-syntax/mail-archive/msg10296.html Requirement 02: Define the scope. YES. In the introduction of the document are given what the technology is about. Though it could be certainly improved, by giving a more systemic way of describing the scope. Requirement 03: Identify who or what will implement the specification. NO. For example, we can see Atom Processors in the specification, but it is defined what's an atom processor. The list of class of products would help to define the conformance model, and then the conformance clause. What about authoring tools? What about validators? etc. Requirement 04: Make a list of normative references. YES. The list of normative references is given. Requirement 05: Define the terms used in the normative parts of the specification. NO. Atom Processors is not defined. Atom Feed is defined, Atom Entry as well. Some of the important concept really need more definitions. It's really important because it avoids broad interpretation of some terms. Fully agree about Atom Processors. Requirement 06: Create conformance labels for each part of the conformance model. NO. The conformance model being not completely clear. It's very hard to know what are the different type of conformance and then to put labels on them. See comment #1. Requirement 07: Use a consistent style for conformance requirements and explain how to distinguish them. YES. the RFC is using a consistent style explained in Notational conventions. Requirement 08: Indicate which conformance requirements are mandatory, which are recommended, and which are optional. YES/NO. Because of the lack of conformance clause clearly defined, it might be confusing. For example This specification does not define a DTD for Atom Documents, and hence does not require them to be valid (in the sense used by XML). But a document could be valid against the RELAXNG Schema. Is there any reason to not make the schema normative? No consensus to make the schema normative. Everyone had a different reason for opposing it, as I recall. :) Requirement 09: If the technology is subdivided, then indicate which subdivisions are mandatory for conformance. N/A. The technology seems to not be modular and then not subdivided. Requirement 10: If the technology is subdivided, then address subdivision constraints. N/A. Requirement 11: Address Extensibility. YES. Perfectly addressed. Requirement 12: Identify deprecated features. N/A. None. Requirement 13: Define how each class of product handles each deprecated feature. N/A. None. Robert Sayre
Re: posted PaceAuthorContributor
On 23 May 2005, at 7:44 pm, Dan Brickley wrote: What we have today is http://dublincore.org/documents/dcmi-terms/#H2 An entity primarily responsible for making the content of the resource. (Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.) The WG consensus in supporting multiple atom:authors seems to be against having a singular creator, so -1 on this change. Graham
RE: Compulsory feed ID?
Antone Roundy wrote re the issue of DOS attacks: I've been a bit surprised that you [Bob Wyman] haven't been more active in taking the lead on pushing the conversation forward and ensuring that threads addressing the issue don't die out, given the strength of your comments on the issue in the past and the obvious significance to your business. ... Perhaps you, who are probably in a better position than any of us to speak from experience on how to deal with this, could refresh our memories of specifically what you think the best solution is. Yes, this issue is very important to us at PubSub and should be very important to others as well. However, as I've learned from other recent discussions, my viewpoint is not commonly held in this Working Group. Thus, what I've been trying to do is pick carefully the issues that I work on. For instance, I've put a great deal of effort into multiple ids since that allows us the freedom to either work out proprietary solutions to the DOS problem on our own or allows us to punt the problem forward to the end-users' aggregators if we can't come up with a decent solution. Clearly, the best solution here would be for folk to use signatures. But, that is going to take either a great deal of work to get adopted or something really creative (and simple)... The history of attempts to get signatures used does not make pleasant reading... We are putting effort into working out methods to make signatures more acceptable to the community and I hope to have some proposals soon... If we successful (wish us luck!) that will at least provide a solution for some people... Basically, it doesn't make sense for me to keep demanding that people deal with issues that they clearly don't want to address. I've been mentioning the DOS problem for months now and getting nowhere. So, the reason I'm not pushing harder is that it is clear that implementable work-arounds will be more useful than never agreed-to solutions... bob wyman
Re: atom:author clarification
On 24/5/05 4:14 AM, Justin Fletcher [EMAIL PROTECTED] wrote: As I understand it, the intention is that atom:author within atom:feed applies to all child atom:entry elements; that is, the value is inherited. This being the case I have a dilemma with a feed I would like to aggregate from others. The intention has long been that. Text explaining that inheritance has slipped from the spec, and is currently up for discussion. Is there a suitable place for identifying the feed's author without affecting the entries themselves ? Is the atom:feed/atom:author a suitable place for this ? Yes. If you are copying the entries from another feed you could also look at the atom:source element. e.
Re: Refresher on Updated/Modified
Monday, May 23, 2005, 6:18:53 AM, Roger B wrote: I'm asking you specifically because you seem to be approaching your argument in a reasonable tone and fashion. My apologies if I'm pestering. No apologies required, I welcome any useful criticism. Near as I can tell, folks have modification dates. In my case, that is a date that is updated every time the user clicks save. In Tim's case, that is a date that he chooses. In other apps, that may be a date that matches when a new comment was added to a blog entry. Nothing in the spec is going to change these realities. And none of these approaches are *wrong*, or invalid. We each get to define change in our own apps, so we can approach atom:modified's MUST clause as we see fit. For all practical purposes, it doesn't matter whether folks use atom:updated or atom:modified. You're going to get the same date. You may get the same date in some cases, but not all. explained below... With that in mind, what are the actual benefits of atom:modified over atom:updated? The end result will always be identical, unless I'm missing a crucial, well-hidden point. When a publisher updates an existing entry, the value that they put in atom:updated combines three parameters: a) The last modified date of the entry (ie: the value that would go into atom:modified if it existed) b) The atom:updated value of the previous instance. c) Whether the publisher's opinion is that the change is significant. (some publishing systems may not allow the publisher to express this opinion - in that case, this parameter will be hard-coded) The publisher chooses whether the new atom:updated value should be the current modification date, or the previous atom:updated value based on whether, in their opinion the change is significant. If a publisher wants to change an entry, and wants to indicate that in their opinion the change was not significant, the current draft allows them to do this by publishing a new version of the entry with the same value of atom:updated as the previous version. The problem is, for a set of instances of an entry (ie where the entry was modified over time) atom:updated is the only way for a publisher to indicate the order of those instances. So these instances become second-class, in the sense that the publisher is prevented from communicating this information. Given multiple instances of an entry, one original, and one that has been corrected, it is impossible to tell which is which, so any processor has a 50% or greater chance of displaying the wrong version. Fortunately, under typical circumstances, a Feed Document doesn't contain more than one instance of the same entry, so you can work out the order of instances from two separate polls based on when you polled the feed. But under other circumstances this is important. An example - Atom is supposed to support archiving according to the charter, but it isn't possible to archive a feed, unless you don't mind either a) the order of instances of entries that appeared in your feed being lost (so that it is impossible for a reader to tell which of two instances is the later one that incorporates corrections); or b) the archiver stripping out older instances before putting them in the archive - but this means that you only have a partial archive of what was published in your feed. Note that without atom:modified an archiver could only support b) if it was tightly coupled with the publishing process because the current draft of Atom is incapable of representing the modified dates of entry instances necessary for the archiver to strip out the older instances. (see http://www.imc.org/atom-syntax/mail-archive/msg15549.html - for more discussion of this example) PubSub is another example of a system where this is a problem - it's probably best to read what Bob Wyman says about that though. The recommendation made by PaceAllowDuplicateIDs to use atom:updated to select the latest instance of an entry, is a completely inappropriate use of atom:updated given its semantics, but unfortunately it is the only course of action unless atom:modified (or something similar) is introduced. Please note that it has not escaped me that this cuts both ways. Why fight for atom:updated over atom:modified when it is beyond the scope of the Atom spec to define the nature of change in the universe? Hey, if Tim doesn't consider a typo a real modification, then it just isn't. Period. It's his writing, his app, and he defines the rules and the terms. It has been suggested that atom:modified is being proposed because the processor mistrusts the publisher, or the publisher's opinion, or because the processor doesn't find the opinion significant. This couldn't be further from the truth. Without atom:modified, the feature of atom:updated that allows a publisher to express their opinion on significance, is a false promise. If publishers don't update atom:updated, the entry becomes
Re: posted PaceAuthorContributor
* Robert Sayre [EMAIL PROTECTED] [2005-05-23 18:26-0400] On 5/23/05, Graham [EMAIL PROTECTED] wrote: On 23 May 2005, at 7:44 pm, Dan Brickley wrote: What we have today is http://dublincore.org/documents/dcmi-terms/#H2 An entity primarily responsible for making the content of the resource. (Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.) The WG consensus in supporting multiple atom:authors seems to be against having a singular creator, so -1 on this change. Dan tells us you can have multiple dc:creators. I didn't know that, but I'd be happy to use Dublin Core if we possibly can. Yep, all the main DC terms are considered optional and repeatable. Dan
Re: atom:author clarification
On Tue, 24 May 2005, Eric Scheid wrote: On 24/5/05 4:14 AM, Justin Fletcher [EMAIL PROTECTED] wrote: As I understand it, the intention is that atom:author within atom:feed applies to all child atom:entry elements; that is, the value is inherited. This being the case I have a dilemma with a feed I would like to aggregate from others. The intention has long been that. Text explaining that inheritance has slipped from the spec, and is currently up for discussion. Is there a suitable place for identifying the feed's author without affecting the entries themselves ? Is the atom:feed/atom:author a suitable place for this ? Yes. If you are copying the entries from another feed you could also look at the atom:source element. Ah yes; quite correct and quite clearly stated in the draft. Thanks for pointing that out, sorry for redundant question :-) -- Gerph http://gerph.org/ ... I'm not just deaf and dumb; staring at the sun.
Re: inheritance issues (was: Author and contributor)
On 24/5/05 9:02 AM, Thomas Broyer [EMAIL PROTECTED] wrote: The problem is mostly when there are author(s) without contributor in the feed (resp. entry) and contributor(s) without author in the entry (resp. feed). Is the entry author-less (resp. contributor-less) or is it inheriting the feed author(s) (resp. contributor(s))? I suggest considering author(s)+contributor(s) as a whole, that is, the entry would be author-less (resp. contributor-less). This issue would not exist if there couldn't be an atom:contributor without at least an atom:author, though I'm not sure this wouldn't bring some more issues... oh darn. This damn inheritance stuff is nasty. Consider too a feed which has both authors and contributors at the feed level, an entry with neither authors or contributors (simple case of inheritance), and another entry with a single author and no contributors (does the entry inherit the feed contributors?), and a third entry with no specified author (inherits, right?), but with contributors (no inheritance, right?). The first case is easy to guess the intention. The third case is easy to guess the intention. It's the second case which is the beotch. Second area of concern with writing the spec text - the atom:source element needs to be mentioned in the text about inheritance. My understanding is that inheritance draws first from atom:source (if it exists), and then atom:feed. e.
Re: atom:author clarification
On 24/5/05 9:23 AM, Justin Fletcher [EMAIL PROTECTED] wrote: Ah yes; quite correct and quite clearly stated in the draft. Thanks for pointing that out, sorry for redundant question :-) No, don't be sorry. We all know way too much about the spec text, getting outsiders to interpret what we've written is very important for feedback. Tim/Paul/Others: is there any process or such where we could take the time to get clueful outsiders to read over the spec and relate to us which parts are confusing. Ideally this should happen once we've run out of issues to distract us. e.
Re: inheritance issues (was: Author and contributor)
On 24 May 2005, at 12:31 am, Eric Scheid wrote: Second area of concern with writing the spec text - the atom:source element needs to be mentioned in the text about inheritance. My understanding is that inheritance draws first from atom:source (if it exists), and then atom:feed. I'd say it draws from atom:source OR atom:feed. atom:feed should not be used if atom:source exists, even if it doesn't contain an atom:author, which it SHOULD. (unrelated question: what's with this plus sign atomLink+ in the atom:source production?) Graham
Re: atom:author clarification
At 9:35 AM +1000 5/24/05, Eric Scheid wrote: Tim/Paul/Others: is there any process or such where we could take the time to get clueful outsiders to read over the spec and relate to us which parts are confusing. Ideally this should happen once we've run out of issues to distract us. That was the IETF-wide last call, last month. The announcement was made on the IETF-Announce mailing list, and brought in a few folks. In addition, Tim and I pestered a number of people we know who we thought might not be following the document and asked them to look in. --Paul Hoffman, Director --Internet Mail Consortium
Re: inheritance issues
Eric Scheid wrote: oh darn. This damn inheritance stuff is nasty. Inheritance suggests a programming model to allow the evaluator to be coded for it. It's rarely as simple as it looks to define a decent model that does what people think it does at first glance. As things stand, it will be an immense coincidence if we do not end up dishing out nasty surprises for users. Atom's just not a very good programming language ;) cheers Bill
Re: inheritance issues (was: Author and contributor)
On 5/23/05, Eric Scheid [EMAIL PROTECTED] wrote: On 24/5/05 9:56 AM, Graham [EMAIL PROTECTED] wrote: (unrelated question: what's with this plus sign atomLink+ in the atom:source production?) well spotted. That means oneOrMore, while * means zeroOrMore. + is accurate for format-08, which requires an alternate link. Robert Sayre
Re: inheritance issues (was: Author and contributor)
On 24/5/05 10:36 AM, Robert Sayre [EMAIL PROTECTED] wrote: On 5/23/05, Eric Scheid [EMAIL PROTECTED] wrote: On 24/5/05 9:56 AM, Graham [EMAIL PROTECTED] wrote: (unrelated question: what's with this plus sign atomLink+ in the atom:source production?) well spotted. That means oneOrMore, while * means zeroOrMore. + is accurate for format-08, which requires an alternate link. and yet atom:source goes at length to say it is optional, and also some or all metadata elements could be copied, and while it encourages the copying of atom:author, atom:contributor, atom:copyright, and atom:category, the spec text provides no guidance or requirement that [EMAIL PROTECTED] MUST be copied. The text is normative, the rnc is not, and on that distinction it would be valid to not copy any links. Alternatively, it would also be entirely valid (given the spec text there), to copy some other link (eg. @rel=self) and not copy the @rel=alternate link at all. Is this what we meant the spec to say? e.
Re: inheritance issues (was: Author and contributor)
If an atom:entry is copied from one feed into another feed, then the source atom:feed's metadata (all child elements of atom:feed other than the atom:entry elements) MAY be preserved within the copied entry by adding an atom:source child element, if it is not already present in the entry, and including some or all of the source feed's metadata elements as the atom:source element's children. Such metadata SHOULD be preserved if the source atom:feed contains any of the child elements atom:author, atom:contributor, atom:copyright, or atom:category and those child elements are not present in the source atom:entry. On 5/23/05, Eric Scheid [EMAIL PROTECTED] wrote: and yet atom:source goes at length to say it is optional, Disagree, the MAY is about putting atom:source in at all (yes, it's possible to copy entries without using atom:source). The text implies that the source must be an atom:feed element, and those have required elements. The RNC also requires atom:title and atom:updated, etc. I guess we could add All required feed metadata elements MUST be present. OK? Robert Sayre
Re: inheritance issues (was: Author and contributor)
* Eric Scheid [EMAIL PROTECTED] [2005-05-24 01:40]: Consider too a feed which has both authors and contributors at the feed level, an entry with neither authors or contributors (simple case of inheritance), and another entry with a single author and no contributors (does the entry inherit the feed contributors?), and a third entry with no specified author (inherits, right?), but with contributors (no inheritance, right?). The first case is easy to guess the intention. The third case is easy to guess the intention. It's the second case which is the beotch. I think of these things in terms of what is possible to express. a) Any entry always has an author. b) A feed may or may not have an author. c) An entry may or may not have contributors. d) A feed may or may not have contributors. Any solution must not prevent any of these from being expressible. I already discussed why replacement is preferrable to merging when any of these are given at both the feed and entry level. Now with that in mind, c) and d) suggest to me that atom:feed/atom:contributor never inherits to entries. If entries were to inherit from the feed, then in a feed with contributors it is not possible to express that an entry had no contributors. With atom:author we can inherit safely, because a) means that there is no case in which an entry can have no author, which means that specifying an inheritable author at the feed level does not pose a problem in expressing any of the possible cases for an entry. So in summary: The set of atom:entry/atom:author overrides the set of atom:feed/atom:author for a particular entry, should the set be non-empty. [Inheritance with replacement semantics.] The set of atom:feed/atom:contributor applies only to the feed and not to any of its entries. [No inheritance.] Any permissible assertion about the feed and one of its entries is thus possible. Regards, -- Aristotle
Re: atom:type, xsl:output
Graham, * When @type=html then the content of the element is a xsd:string [1] of an HTML DIV element plus optional insignificant whitespace around it. Which version of HTML is defined? How do you differentiate between HTML 4.01, HTML 3.2, the upcoming HTML 5, or nonstandard HTML (like with marquee elements)? I believe the answer would be street HTML, not any specific version. I don't like this, since the behavior of an unknown version of HTML is obviously undefined. You can't expect any HTML processors (used to parse atom content items) to follow the standards when the standard of the instance being used is unknown! There should be a way to identify the version of html used so that the behavior of the processor can be explicitly defined. * When @type=mime/type [2], ONLY for atom:content, then the content (or src document) is that type of document. Why not allow other elements to use this? Because the other elements are for purely textual content. I understand. XML 1.1 Not supported. I'm confused. There is nothing inherent in the spec that prevents XML 1.1 or any future versions from being supported. And why introduce incompatibilities in atom:content that also bork with arbitrary XML 1.0 documents too? I assert this, because the spec says in section 4.1.3.3, Processing Model, that: ] 4. If the value of type ends with +xml or /xml ] (case-insensitive), the content of atom:content MAY include child ] elements, and SHOULD be suitable for handling as the indicated ] media type. If the src attribute is not provided, this would ] normally mean that the atom:content element would contain a ] single child element which would serve as the root element of the ] XML document of the indicated type. First off: it is an error to lie about your media-type, so I would change SHOULD be suitable for handling as the indicated media type to MUST be suitable for handling as the indicated media type. Secondly, XML may be entity (or CDATA) encoded like @type=html or plain xml like @type=xhtml. This is becuase of the content of atom:content MAY include child elements phrase. There is no guarantee if an entity escaped passage is xml or a text node example of an xml document (i.e. an example of an xml document), for example. SO the following could legally be interpreted as either a text node or as full-fledged xml: ] atom:content type=application/xmllt;?xml version=1.0? ] lt;tag //atom:content There is no way to make even an educated guess in advance without reading the text node with an xml processor and seeing if it is well-formed. This really sucks for processing Atom with XSLT. In any case, the above example could never be the root element of the XML document of the indicated type if written as xml instead of entity-escaped either, since there is that pesky XML declaration. Yet it still conforms to what the mime type says it is. That's one reason why I think this is a bug in the Atom spec. It's also a reason why I wish atom:content adopted xslt:output attributes for specifying the doctype/xml declaration and version info of the content. Finally: In general there could also be processing instructions that must be put as children of the atom:content element, but how should they be interpreted? A non-atom aware processor will read those processing instructions as belonging to the ATOM DOCUMENT instead of the atom:content's XML CONTENT! This is a horrible situation, especially when you want the content of a blog to be an actual XML document that uses XML declarations, DOCTYPE declarations, and processing instructions. There needs to be a way to specify these things without using an external file referenced with a @src attribute. RTF It is compatible, as a string, though certain obsolete characters are not. PNG Should be base64 encoded. I understand, thanks. What should one do when encountering these situations? See section 4.1.3.3 Processing Model Thanks for the pointer. I can't believe I missed that. -- Jimmy Cerra P.S. Thanks you Danny Ayers, wherever you are! __ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/
