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
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
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
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
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
[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
* 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
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.
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
* 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
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
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
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.
* 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
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
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)
* 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
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
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
--
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
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
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
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
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
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
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
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:
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
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
* 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
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
* Graham [EMAIL PROTECTED] [2005-05-23 12:50]:
http://www.intertwingly.net/wiki/pie/PaceClarifyAuthorContributor
+1
Regards,
--
Aristotle
* 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
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
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
+1 make atom:author plural
+1 keep atom:contributor
- Robin Cover
* 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
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'
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
* 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
/ 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
* 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
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
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
* 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
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
* 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
* 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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
--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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
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
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
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,
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
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
* 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
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
99 matches
Mail list logo
