Re: The atom:uri element

* Asbjørn Ulsberg <[EMAIL PROTECTED]> [2005-05-24 14:50]: > I've mentioned this several times before and haven't had time > to follow the evolvement of the draft up until now, but as far > as I can tell, atom:uri is still in place in the > specification... Do we really need a pace to have that

Re: The atom:uri element

On 25/5/05 2:34 PM, "James Cerra" <[EMAIL PROTECTED]> wrote: > I agree with this. I thought it was unusual to name a tag after a specific > technology rather than its intent (atom:email is an exception). In this > instance, I think atom:name, atom:resource, or atom:link works better. +1 atom:l

Re: The atom:uri element

> > Or is it so that the atom:uri element have many proponents on the list > > so it can't be renamed or changed to atom:link, atom:email or something I agree with this. I thought it was unusual to name a tag after a specific technology rather than its intent (atom:email is an exception). I

Re: atom:type, xsl:output

Graham, > > Secondly, XML may be entity (or CDATA) encoded like > > @type="html" or plain xml like @type="xhtml". This is > If I follow you right, you misunderstand. Atom documents are > unambiguous. XML has to be inserted literally, with no entity > escaping (except for entities that are pa

Re: atom:type, xsl:output

Aristotle, > Embedding XML 1.1 documents inside an XML 1.0 document is not > possible, because... I understand. Thanks. > An Atom processor does not know whether the embedded XML document > is a valid document of the given type. Only an attached processor > for the given document type will be

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

Le 05-05-24 à 21:04, A. Pagaltzis a écrit : So it seems to me that your complaint is outside the scope of the specification, and, indeed, this WG. I had a lengthy discussion with Paul Hoffman out of the list to avoid unnecessary arguments on this list which has suffered it in the past. Ju

Re: inheritance issues (was: Author and contributor)

* Thomas Broyer <[EMAIL PROTECTED]> [2005-05-24 15:15]: > A. Pagaltzis wrote: > > * Thomas Broyer [2005-05-24 09:05]: > >> c) > >> feed: > >> author: A > >> contributor: B > >> entry: > >> contributor: C > [...] > >> c) The entry inherits the author but overrides the > >>contributor.

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

* Karl Dubost <[EMAIL PROTECTED]> [2005-05-24 20:05]: > > > It means that all XSLTs, Web hosting services, etc can NOT > > > claim conformance to Atom. :) > > > > Yes they can. > > no for the reason I gave and no because there's no way to claim > conformance to the spec. They are plenty marketing

Re: extension elements inside link elements?

* Thomas Broyer <[EMAIL PROTECTED]> [2005-05-24 20:10]: > What about: > >The "atom:link" element defines a reference from an entry or >feed to a Web resource. Atom doesn't define any child to the >"atom:link", though it might contain extension markup. I may be trying to pick a colour

Re: extension elements inside link elements?

On 5/24/05, Graham <[EMAIL PROTECTED]> wrote: > On 24 May 2005, at 5:44 pm, Robert Sayre wrote: > > > FYI: > > http://www.imc.org/atom-syntax/mail-archive/msg11433.html > > > > "But if I encounter a element that's weirdly non-empty and > > contains markup from some other namespace, that's the ki

Re: Comments about Extensions (1)

On 5/24/05, Thomas Broyer <[EMAIL PROTECTED]> wrote: > > David Powell wrote: > > >Section 6.4: > > > >The RNGs in this section require Extension Elements to be in a > >namespace that isn't the Atom namespace. This requirement is missing > >from the text. > > > > > > It's actually worse than jus

Re: Comments about Extensions (1)

David Powell wrote: Section 6.4: The RNGs in this section require Extension Elements to be in a namespace that isn't the Atom namespace. This requirement is missing from the text. It's actually worse than just that. Section 6.1 defines "foreign markup" as being "markup from other vocabu

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

At 2:51 PM -0400 5/24/05, Karl Dubost wrote: Are you insecure? Well, I do sometimes worry my protocols aren't as long as those from other Working Groups, but I try not to think about it. Where did you read, imagine such a thing? The case has been settled for a long time by choice of the At

Re: extension elements inside link elements?

On May 24, 2005, at 10:43 AM, Graham wrote: I also think removing that piece of text makes it unclear that the element is normally empty. +1 -Tim

Re: extension elements inside link elements?

On May 24, 2005, at 9:26 AM, Graham wrote: 4.2.9 (editorial): The atom:link element is explicitly described as empty, which violates the rules in 6 for foreign element extension. Remove "is an empty element that". That's not an editorial change, that's newly allowing extension elements in

Re: atom:type, xsl:output

On May 24, 2005, at 1:25 AM, Graham wrote: 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." +1 I'm tempted to agree but can't, because the

Re: extension elements inside link elements?

Tuesday, May 24, 2005, 7:50:13 PM, Thomas Broyer wrote: > David Powell wrote: >>Whether the draft allowed it or not, atom:link isn't an extension >>point. >> >> > Could you explain why? The following are extension points: * Adding additional metadata to atom:feed by using Section 6.4 Extens

Re: extension elements inside link elements?

Tuesday, May 24, 2005, 8:24:16 PM, Graham wrote: > On 24 May 2005, at 7:08 pm, David Powell wrote: >> Whether the draft allowed it or not, atom:link isn't an extension >> point. That would be Section 6.3 style "unknown foreign markup". > Unless there's a memo I missed, extensions are a subset

Re: extension elements inside link elements?

On 24 May 2005, at 7:08 pm, David Powell wrote: Whether the draft allowed it or not, atom:link isn't an extension point. That would be Section 6.3 style "unknown foreign markup". Unless there's a memo I missed, extensions are a subset of "unknown foreign markup". Graham

Comments about Extensions (1)

Section 6.4: The RNGs in this section require Extension Elements to be in a namespace that isn't the Atom namespace. This requirement is missing from the text. Proposal Add to section 6.4.1: > A Simple Extension Element MUST be namespace-qualified. The element > MUST be defined outsi

Re: extension elements inside link elements?

David Powell wrote: Whether the draft allowed it or not, atom:link isn't an extension point. Could you explain why? -- Thomas Broyer

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

Le 05-05-24 à 14:31, Paul Hoffman a écrit : I am completely unclear why this discussion is going on. Is there a desire on the part of the W3C to take the Atom work into the W3C? Are you insecure? Where did you read, imagine such a thing? The case has been settled for a long time by choice of

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

I am completely unclear why this discussion is going on. Is there a desire on the part of the W3C to take the Atom work into the W3C? If so, talking to the W3C/IETF liaison pair would be more appropriate than this mailing list. If not, then suggesting that our document should be more W3C-like

Re: extension elements inside link elements?

Tuesday, May 24, 2005, 9:22:29 AM, Eric Scheid wrote: >> 4.2.9 The "atom:link" Element >> >> The "atom:link" element is an empty element that defines a reference from an >> entry or feed to a Web resource. > Subject: Re: extension elements inside link elements? > did we want to prevent expres

Re: extension elements inside link elements?

Graham wrote: On 24 May 2005, at 5:44 pm, Robert Sayre wrote: FYI: http://www.imc.org/atom-syntax/mail-archive/msg11433.html "But if I encounter a element that's weirdly non-empty and contains markup from some other namespace, that's the kind of situation you're talking about. I think it w

Re: inheritance issues

On Tuesday, May 24, 2005, at 10:21 AM, Walter Underwood wrote: Inheriting values saves typing. It does not save bandwidth, because HTTP compression will do nearly as well. 6% of the feeds I subscribe to use compression. I don't think we can depend on that yet.

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

Le 05-05-24 à 12:19, James Aylett a écrit : The implication (and I think it's pretty clear, but perhaps I'm used Implication :) You just name it and that's the source of lng (endless) discussions when specs are released. What is a conformant Atom Authoring Tool? The term "Atom Aut

Re: extension elements inside link elements?

On 24 May 2005, at 5:44 pm, Robert Sayre wrote: FYI: http://www.imc.org/atom-syntax/mail-archive/msg11433.html "But if I encounter a element that's weirdly non-empty and contains markup from some other namespace, that's the kind of situation you're talking about. I think it would be OK to lea

Re: inheritance issues

--On May 24, 2005 7:39:40 AM -0600 Antone Roundy <[EMAIL PROTECTED]> wrote: > On Tuesday, May 24, 2005, at 01:52 AM, Henry Story wrote: >> Simplify, simplify. I am for removing all inheritance mechanisms... +1. Inheritance has very minor advantages and very serious disadvantages. Inheriting val

Re: extension elements inside link elements?

On 5/24/05, Graham <[EMAIL PROTECTED]> wrote: > On 24 May 2005, at 4:07 pm, Robert Sayre wrote: > > > 4.2.9 (editorial): The atom:link element is explicitly described as > > empty, which violates the rules in 6 for foreign element extension. > > Remove "is an empty element that". > > That's not

Re: extension elements inside link elements?

On 5/24/05, Graham <[EMAIL PROTECTED]> wrote: > On 24 May 2005, at 4:07 pm, Robert Sayre wrote: > > > 4.2.9 (editorial): The atom:link element is explicitly described as > > empty, which violates the rules in 6 for foreign element extension. > > Remove "is an empty element that". > > That's not

Re: extension elements inside link elements?

On 24 May 2005, at 4:07 pm, Robert Sayre wrote: 4.2.9 (editorial): The atom:link element is explicitly described as empty, which violates the rules in 6 for foreign element extension. Remove "is an empty element that". That's not an editorial change, that's newly allowing extension element

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

On Tue, May 24, 2005 at 11:08:26AM -0400, Karl Dubost wrote: > Let's go a bit further though. Let's say I'm a developer who's > creating an authoring tool for Atom, so more a producer than a > consumer application. > > "Atom Feed Documents" > "Atom Entry Documents" > > I read "An Atom Entry

Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

Le 05-05-23 à 18:04, Robert Sayre a écrit : Hi Karl. Thanks for the review. Some thoughts inline. my pleasure On 5/23/05, Karl Dubost <[EMAIL PROTECTED]> wrote: Requirement 01: Include a conformance clause. I tend to agree with Paul wrt conformance levels: http://www.imc.org/atom-syntax/

Re: extension elements inside link elements?

On 5/24/05, Paul Hoffman <[EMAIL PROTECTED]> wrote: > > I read "empty" as "always empty", so the XML novice in me would say > that the above expression in inherently wrong. 4.2.9 (editorial): The atom:link element is explicitly described as empty, which violates the rules in 6 for foreign eleme

Re: inheritance issues

Antone Roundy wrote: > > On Tuesday, May 24, 2005, at 01:52 AM, Henry Story wrote: >> Simplify, simplify. I am for removing all inheritance mechanisms... > > I would agree if we had a better way to avoid all the repetition that > would lead to. However, the only proposal[0] I can remember that

Re: extension elements inside link elements?

At 6:22 PM +1000 5/24/05, Eric Scheid wrote: > 4.2.9 The "atom:link" Element The "atom:link" element is an empty element that defines a reference from an entry or feed to a Web resource. did we want to prevent expressions like this: I read "empty" as "always empty",

Re: some small comments on 08

Thomas Broyer wrote: * it is not less reliably implementable than the current draft's mandatory div element; if we go for a SHOULD or MAY on discarding the div elements, it is even *more* reliably implementable. We had a discussion about optional div not so long ago, and I came away u

Re: inheritance issues

On Tuesday, May 24, 2005, at 01:52 AM, Henry Story wrote: Simplify, simplify. I am for removing all inheritance mechanisms... I would agree if we had a better way to avoid all the repetition that would lead to. However, the only proposal[0] I can remember that would have done so has been r

Re: some small comments on 08

Thomas Broyer wrote: > Graham wrote: >> -1, and additionally I don't think the Pace is even complete or >> reliably implementable. > > FYI, it is not, Oops, before it'd be misinterpreted: * the Pace is not *complete* * it is not less reliably implementable than the current draft's mandatory

Re: some small comments on 08

Asbjørn Ulsberg wrote: > On Mon, 23 May 2005 08:54:32 +0200, Anne van Kesteren wrote: * 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.

Re: some small comments on 08

Graham wrote: > On 24 May 2005, at 9:40 am, Henri Sivonen wrote: >> On May 23, 2005, at 12:31, Julian Reschke wrote: >>> For the record: I am +1 on >> PaceOptionalXhtmlDiv>. > > -1, and additionally I don't think the Pace is even complete or > reliably impl

Re: Author and contributor

On Mon, 23 May 2005 07:22:49 +0200, A. Pagaltzis <[EMAIL PROTECTED]> wrote: • make atom:author plural • keep atom:contributor • punt bylines to an extension It's the best suggestion made so far that has any potential of getting into the spec until christmas, so I'm +1 on this. :-) -- Asbj

Re: The atom:uri element

On Tue, 24 May 2005 14:40:41 +0200, Asbjørn Ulsberg <[EMAIL PROTECTED]> wrote: Or is it so that the atom:uri element have many proponents on the list so it can't be renamed or changed to atom:link, atom:email or something [...] ^^

Re: some small comments on 08

On Mon, 23 May 2005 08:54:32 +0200, Anne van Kesteren <[EMAIL PROTECTED]> wrote: * 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 ha

Re: inheritance issues (was: Author and contributor)

A. Pagaltzis wrote: > * Thomas Broyer [2005-05-24 09:05]: >> c) >> feed: >> author: A >> contributor: B >> entry: >> contributor: C [...] >> c) The entry inherits the author but overrides the contributor. I'm >>also open to considering it invalid. [...] > The rule you propose for co

The atom:uri element

I've mentioned this several times before and haven't had time to follow the evolvement of the draft up until now, but as far as I can tell, atom:uri is still in place in the specification... Do we really need a pace to have that element renamed before the spec goes final? Or is it so that

Re: Deterministic content models (conflict with Atom Publishing Protocol?)

Norman Walsh wrote: > Look at the content model for entry: it's a bag o' stuff some of which > is required and some of which is optional (and optionally repeatable) > and it's all allowed to occur in any order. > > I've forgotten the details of XSD's support for "&" content models, but > I'm pret

Re: Fetch me an author. Now, fetch me another author.

On Sat, 21 May 2005 17:16:25 +0200, Eric Scheid <[EMAIL PROTECTED]> wrote: what if in that example was renamed to (and specced to be something other than a Person Construct), and some mechanism introduced to indicate the nature of the contribution by each of the s? +1. This makes ver

Re: Deterministic content models (conflict with Atom Publishing Protocol?)

/ Martin Duerst <[EMAIL PROTECTED]> was heard to say: | 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 Look at the content model for entry: it's a bag o' stuff some of which is required and some of which i

Re: some small comments on 08

On 24 May 2005, at 9:40 am, Henri Sivonen wrote: On May 23, 2005, at 12:31, Julian Reschke wrote: For the record: I am +1 on . -1, and additionally I don't think the Pace is even complete or reliably implementable. Graham

Re: some small comments on 08

On May 23, 2005, at 12:31, Julian Reschke wrote: For the record: I am +1 on . +1 from me too. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/

Re: atom:source

On 24 May 2005, at 2:23 am, Robert Sayre wrote: 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:t

Re: atom:type, xsl:output

On 24 May 2005, at 5:06 am, James Cerra wrote: 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." +1 Secondly, XML may be entity (or CDATA) en

extension elements inside link elements?

> 4.2.9 The "atom:link" Element > > The "atom:link" element is an empty element that defines a reference from an > entry or feed to a Web resource. did we want to prevent expressions like this: e.

Re: inheritance issues (was: Author and contributor)

* Thomas Broyer <[EMAIL PROTECTED]> [2005-05-24 09:05]: > a) > feed: > author: A > contributor: B > entry: > no author not contributor > > b) > feed: > author: A > contributor: B > entry: > author: C > > c) > feed: > author: A > contributor: B > entry: > contributor

Re: atom:type, xsl:output

* James Cerra <[EMAIL PROTECTED]> [2005-05-24 06:35]: > > > 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 arb

Re: inheritance issues

Simplify, simplify. I am for removing all inheritance mechanisms... Henry On 24 May 2005, at 02:02, Bill de hÓra wrote: 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 sim

Re: inheritance issues (was: Author and contributor)

A. Pagaltzis wrote: > > * 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 contri