Subject: PaceElementOrder

From: Tim Bray <[email-masked]>
Date: Wed, 07 Jul 2004 21:23:41 -0700

I propose a modification to this Pace 
(http://www.intertwingly.net/wiki/pie/PaceElementOrder).  I don't know 
what the right section number is in the about-to-appear -00 drafts, but 
I'd like language like this:

  The child elements of <atom:feed> may appear in any order, subject 
only to
  the constraint that the the <atom:entry> children appear in a group 
after all
  other child elements.  That is to say, the "feed-level" elements must 
all
  appear before the first <atom:entry> element.  The order in which the
  child elements of <atom:feed> appear is not considered significant.

It's also been proposed that we consider imposing a *strict* ordering, 
something like
title/author/copyright/dates/.../entries.  It might simplify some 
software tasks, I could go either way on that.

But I think forcing the <entry> children to the end is just good 
practice, because a feed parser that wants to do anything to an 
<atom:entry> involving any of the feed-level metadata can be built 
using a stream interface; otherwise loading the whole thing into a DOM 
or equivalent will be necessary. -Tim

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Jul 2004 22:42:38 -0700

On Jul 7, 2004, at 9:23 PM, Tim Bray wrote:

> what the right section number is in the about-to-appear -00 drafts, 
> but I'd like language like this:
>

+1: I don't understand the Pace at it sits.

> software tasks, I could go either way on that.

-1: how would extensions be ordered?

--
Mark Nottingham     http://www.mnot.net/

---

From: Tim Bray <[email-masked]>
Date: Fri, 09 Jul 2004 23:07:14 -0700

On Jul 9, 2004, at 10:42 PM, Mark Nottingham wrote:

>> It's also been proposed that we consider imposing a *strict* 
>> ordering, something like

Urgh, indeed, good catch.  I *guess* you could say they could go 
anywhere in-between the fixed-order Atom elements, or reserve a spot 
after all the feed-level stuff and before the Entries and say 
"Extensions go here", but those both feel kludgy.

On the other hand, leaving the order semi-unconstrained (i.e. requiring 
only that the <atom:entry> crowd bring up the rear) is going to result 
in serious ugliness in any XSD we produce, which may spill over into 
SOAP/WSDL territory... still, I lean to -1. -Tim

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Jul 2004 23:08:43 -0700

On Jul 9, 2004, at 11:07 PM, Tim Bray wrote:
>
> On the other hand, leaving the order semi-unconstrained (i.e. 
> requiring only that the <atom:entry> crowd bring up the rear) is going 
> to result in serious ugliness in any XSD we produce, which may spill 
> over into SOAP/WSDL territory... still, I lean to -1. -Tim

XSD's problem, not mine.

:)

---

From: Norman Walsh <[email-masked]>
Date: Sat, 10 Jul 2004 08:48:36 -0400

/ Mark Nottingham <[email-masked]> was heard to say:
| On Jul 7, 2004, at 9:23 PM, Tim Bray wrote:
|
|> I propose a modification to this Pace
|> (http://www.intertwingly.net/wiki/pie/PaceElementOrder).  I don't
|> know what the right section number is in the about-to-appear -00
|> drafts, but I'd like language like this:
|>
|>  The child elements of <atom:feed> may appear in any order, subject
|> only to
|>  the constraint that the the <atom:entry> children appear in a group
|> after all
|>  other child elements.  That is to say, the "feed-level" elements
|> must all
|>  appear before the first <atom:entry> element.  The order in which the
|>  child elements of <atom:feed> appear is not considered significant.

If we want to make a distinction between atom:entry children and other
children, I suggest that we put the other children in a wrapper.

  <atom:feed>
    <atom:feedinfo>
      <atom:title>...</atom:title>
    </atom:feedinfo>
    <atom:entry>...</atom:entry>
  </atom:feed>

(I don't have any particular attachment to the name "feedinfo".)

This would make it easy to constrain the feed information to appear
first without struggling over the order of extension elements that
are peer to atom:entry.

It would also clarify extension elements that are intended to be peer
to atom:title on a feed (but not atom:entry).

In fact, now that I think about it, I think this makes oodles of sense
regardless of the ordering issues.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | A censor is a man who knows more than
http://nwalsh.com/            | he thinks you ought to.--Granville Hacks

---

From: Danny Ayers <[email-masked]>
Date: Sat, 10 Jul 2004 17:56:30 +0200

Mark Nottingham wrote:

>> requiring only that the <atom:entry> crowd bring up the rear) is 
>> going to result in serious ugliness in any XSD we produce, which may 
>> spill over into SOAP/WSDL territory... still, I lean to -1. -Tim
>
>
> XSD's problem, not mine.

Quite.

It seems like putting the cart before the horse to constrain order in 
the spec for the benefit of the schema without some reference to 
schema-validity.  If we really want a schema, we should be prepared to 
use it. I'd suggest either making schema-validity a SHOULD (and 
processor validation a MAY) or allowing any order. I suspect the latter 
is more likely to gain consensus.

Cheers,
Danny.

-- 

Raw
http://dannyayers.com

---

From: Tim Bray <[email-masked]>
Date: Sat, 10 Jul 2004 13:01:34 -0700

So, it seems like we have the following options on this:

1. Do nothing, no rules about ordering
2. Require all the feed-level elements appear before the <atom:entry> 
elements
3. #2, but have an <atom:feed-info> to contain all that stuff.  Thus the
    content-model of <atom:feed> becomes
    atom:feed-info, atom:entry+
4. Require a specific ordering for all the elements.

Until #3 came along, I'd have said that the general leaning was to #2; 
there was no support voiced for #1 and not much for #4.  Now would be a 
good time to prove me wrong by speaking up for #1 or #4, or point out 
why one of #2 or #3 is better than the other.  -Tim

---

From: Ken MacLeod <[email-masked]>
Date: 10 Jul 2004 15:34:24 -0500

Tim Bray <[email-masked]> writes:

> Until #3 came along, I'd have said that the general leaning was to
> #2; there was no support voiced for #1 and not much for #4.  Now
> would be a good time to prove me wrong by speaking up for #1 or #4,
> or point out why one of #2 or #3 is better than the other.  -Tim

With #3, see also the suggestion for the <site> element, that also
provides a solution for "replicating" the feed information in
synthetic feeds and indexes,

  http://imc.org/atom-syntax/mail-archive/msg06355.html

Alas, there is still metadata in the "protocol feed" (which is now
different from "a logical feed that is also a site").  Note still that
people using stream parsers would also still like the referenced
elements to come before the referencing elements.

Bob Wyman follows this to its inevitable conclusion in

  http://imc.org/atom-syntax/mail-archive/msg06380.html

Which implies creating new solutions, such as an extension mechanism
that indicates which metadata elements should be replicated (to
prevent server pounding outside of an explicit user action) and which
elements should be hosted at the origin server (because there's lots
more in the origin resource).  PaceSimplifiedFeedFormat does this for
entries, for example.

I'm for exploring #3 and fleshing out its issues.

  -- Ken

---

From: Antone Roundy <[email-masked]>
Date: Sat, 10 Jul 2004 15:36:24 -0600

> Tim Bray <[email-masked]> writes:
...
>> 4. Require a specific ordering for all the elements.
-1 on #1 and #4.  I lean towards #2, but a little voice in my head is 
whispering that we might find some real benefits in #3.  I'd be 
interested in exploring what those might be.

> elements to come before the referencing elements.
+1 on ensuring that ordering doesn't cause headaches for stream 
parsers.  I don't think there's any reason NOT to have the minimal 
ordering requirements to help with stream processing.

>   http://imc.org/atom-syntax/mail-archive/msg06380.html
This message expresses my main concern with #3.  I am very much in 
favor of keeping feeds self-contained to the extent that, for example,  
an HTML representation could be made of the feed without having to 
fetch any external data. Things like images that would be referenced by 
an HTML document, but not actually included inside it, can be external. 
And references by extensions or <link> (or its successors?) to external 
resources are fine. But elements that are part of the Atom 
core--CERTAINLY all required elements, should carry their data in the 
feed itself.

If we can reap benefits from #3 while drawing a firm line against that 
evolving into a situation where feed-level metadata is stored outside 
of the feed, then that sounds good.

Antone

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 10 Jul 2004 14:56:10 -0700

This tangentially brings up something that I've been musing on for a 
while.

It seems to me that some feed-level metadata are really "defaults" for 
entries in the feed; that is, they filter down into the feed entries 
unless that entry has more specific information.

Current examples of this are atom:author and atom:contributor.

Another kind of feed-level metadata is about the whole feed itself, not 
the entries in the current Atom document. For example, if I update 
atom:title on a feed, that's the title for the whole feed, including 
all previously seen entries.

Contrast this with the defaulting mechanism, which applies to just the 
entries in the current Atom document, not previously seen ones.

This leads me to believe that there may be some value in separating 
feed-wide metadata with entry defaults, in a manner something like 
this:

<feed>
     <feed-info>
         ...
     </feed-info>
     <entry-defaults>
        ...
     </entry-defaults>
     <entry>
        ...
     </entry>
     ...
</feed>

Another approach would be to specify an attribute that can be used on 
all extensions to clarify this, e.g.:

<feed>
     <author atom:entryDefault="1">
        ...
     </author>
     ...
</feed>

Ideally, such an attribute would be crafted so that it could say that 
the metadata applied just to the feed, just as a default for entries, 
or both.

Either approach would make the separation between these kinds of 
metadata much more specific, and remove the need for entry-level 
metadata to be re-specified at the feed level if it's defaulted.

The acid test for this is whether we can see extensions using such a 
mechanism; if people thought it would prove useful, it would be worth 
the additional
mechanism.

Thoughts?

On Jul 10, 2004, at 1:01 PM, Tim Bray wrote:

> there was no support voiced for #1 and not much for #4.  Now would be 
> a good time to prove me wrong by speaking up for #1 or #4, or point 
> out why one of #2 or #3 is better than the other.  -Tim
>

---

From: Danny Ayers <[email-masked]>
Date: Sun, 11 Jul 2004 00:59:51 +0200

Some questions, starting with the biggy:

Why order the elements?

It may be useful to describe the possible benefits of ordering, and 
seeing how well each option provides those benefits.

Would an order make any significant difference to an application?

How useful is it to have feed-level metadata up front? Are incomplete 
parsing/readings likely?

Would it make any significant difference to the XML processor?

If not, in what respect is the format underconstrained? (That's the only 
rationale given in the Pace).

If there is to be a specific ordering, what should it be?

> out why one of #2 or #3 is better than the other.  -Tim

A variant on 3. would be an <atom:entries> container. Which is drifting 
towards head/body - a good thing or not?

Cheers,
Danny.

-- 

Raw
http://dannyayers.com

---

From: Tim Bray <[email-masked]>
Date: Sat, 10 Jul 2004 17:18:08 -0700

> Some questions, starting with the biggy:

As I've now stated several times, it may be useful, while processing an 
<atom:entry>, to know what the URI or title or author or copyright of 
the <atom:feed> is.  If you require that the feed-level stuff all 
precede the entries, then you can use a stream parsing API as opposed 
to an in-memory DOM thing.  This feels to me like a significant benefit 
to implementors. -Tim

---

From: Martin Duerst <[email-masked]>
Date: Sun, 11 Jul 2004 09:45:10 +0900

At 15:36 04/07/10 -0600, Antone Roundy wrote:

>whispering that we might find some real benefits in #3.  I'd be interested 
>in exploring what those might be.

Differentiation of extensions. If an extension is inside feed-info,
it's a new way of providing info about a feed. If it's after, it's
something else than, but similar to, entry.

Regards,    Martin.

---

From: Graham <[email-masked]>
Date: Sat, 10 Jul 2004 23:50:46 -0400

> feed-wide metadata with entry defaults, in a manner something like 

3rd option for entry defaults:

<feed>
  <author name="person A">
   <entry />
   <entry />
   <entry />
  </author>
</feed>

That would also allow different defaults for different groups of 
entries.

Graham

---

From: Norman Walsh <[email-masked]>
Date: Sun, 11 Jul 2004 10:19:36 -0400

/ Martin Duerst <[email-masked]> was heard to say:
[...]
| Differentiation of extensions. If an extension is inside feed-info,
| it's a new way of providing info about a feed. If it's after, it's
| something else than, but similar to, entry.

Yes, that's one. A few more:

1. Differentiation of extensions.
2. Ability to easily identify/grab/transform the whole set of feed metadata
3. Provides an easy mechanism to group all the feed metadata up front
   without requiring an explicit order
4. Provides a mechanism for accomplishing 3 that can easily be tested by
   a grammar-based schema language
5. Uses a common idiom (HTML "head", TEI/GCA "front", DocBook "info) that
   users will find familiar

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Wink at small faults; for thou has
http://nwalsh.com/            | great ones.--Thomas Fuller (II)

---

From: Walter Underwood <[email-masked]>
Date: Sun, 11 Jul 2004 12:22:03 -0700

--On Saturday, July 10, 2004 5:18 PM -0700 Tim Bray <[email-masked]> wrote:
>
> If you require that the feed-level stuff all precede the entries, then
> you can use a stream parsing API as opposed to an in-memory DOM thing.
> This feels to me like a significant benefit to implementors.

Strongly agree. Ultraseek uses a stream parser for XML indexing.

Very large feeds are certainly plausible, which causes problem
for DOM/in-memory approaches. Perhaps the Congressional Record
would be a feed.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Ken MacLeod <[email-masked]>
Date: 11 Jul 2004 17:19:19 -0500

> That would also allow different defaults for different groups of

So with an author and a contributor it might look like this?

<feed>
  <author name="person A">
    <contributor name="person B">
      <entry />
      <entry />
    </contributor>
  </author>
  <author name="person B">
    <contributor name="person C">
      <entry />
    </contributor>
  </author>
</feed>

With all the use-cases for multiple feeds, synthetic feeds,
independent entries, I'm leaning heavily towards -1 on inheritance or
defaults in any manner.  Making entries as independent as possible
would be a good "core Atom" goal, and then explicit references for
"more info".  I'm still good with "hard local references", such as
<site> and <author> with known required-to-be-copied elements:

<feed>
  <site id="site1" />
  <person id="person A" />
  <person id="person B" />
  <entry>
    <site ref="site1" />
    <author ref="person A" />
  </entry>
  <entry>
    <site ref="site1" />
    <author ref="person B" />
    <contributor ref="person A" />
  </entry>
</feed>

In this scenario, the "redundantly replicated" @ref elements in, yes,
every entry are acting like foreign keys in a database table.
Absolutely no inheritance of any kind -- it's all explicit.

  -- Ken

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 11 Jul 2004 17:49:04 -0700

+1

This has the implication of taking the defaulting mechanism OUT of 
feed-level author, copyright, etc. -- I'm all for that, but wanted to 
make sure you meant that too.

---

From: Ken MacLeod <[email-masked]>
Date: 11 Jul 2004 21:47:23 -0500

Mark Nottingham <[email-masked]> writes:

> feed-level author, copyright, etc. -- I'm all for that, but wanted
> to make sure you meant that too.

Yes, that's what I meant.

Feed-level site information moves into a child element of the feed
called <site>.  <person> elements could be in <site> or move
seperately as element children of the <feed> also, but are still
referenced explicitly from <entry>s.

Extensions to <site> would go in <site>, extensions to <person> would
go in <person>.  New entity constructs could be child elements of
<feed> as well.  Two examples are <category> and <section>.

My term for these "major" independent elements in the original Syntax
document on the wiki was "Entity" elements, which in current style now
be "Entity constructs", basically a small or micro-content resource
that has an <id>.

  -- Ken

---

From: Norman Walsh <[email-masked]>
Date: Mon, 12 Jul 2004 07:36:28 -0400

/ Ken MacLeod <[email-masked]> was heard to say:
[...]
| With all the use-cases for multiple feeds, synthetic feeds,
| independent entries, I'm leaning heavily towards -1 on inheritance or
| defaults in any manner.  Making entries as independent as possible
| would be a good "core Atom" goal, and then explicit references for
| "more info".  I'm still good with "hard local references", such as
| <site> and <author> with known required-to-be-copied elements:
|
| <feed>
|   <site id="site1" />
|   <person id="person A" />
|   <person id="person B" />
|   <entry>
|     <site ref="site1" />
|     <author ref="person A" />
|   </entry>
|   <entry>
|     <site ref="site1" />
|     <author ref="person B" />
|     <contributor ref="person A" />
|   </entry>
| </feed>
|
| In this scenario, the "redundantly replicated" @ref elements in, yes,
| every entry are acting like foreign keys in a database table.
| Absolutely no inheritance of any kind -- it's all explicit.

The question here though is, what are the real benefits of these
references. Wouldn't this be better still for achieving independence
of entries?

<feed>
  <entry>
    <site>site1</site>
    <author>personA</author>
  </entry>
  <entry>
    <site>site1</site>
    <author>personB</author>
    <contributor>personA</contributor>
  </entry>
</feed>

References would give you a way of establishing that two entries
really refer to the same author, but in a single original feed, that's
going to be the case in the vastly overwhelming majority of cases with
no possibility of confusion. And in an aggregated feed, you aren't
going to be able to collapse refs unless we give authors and sites a
unique identifier.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | How can there be laughter, how can
http://nwalsh.com/            | there be pleasure, when the world is
                              | burning?--The Dhammapada (probably 3rd
                              | century BC)

---

From: Danny Ayers <[email-masked]>
Date: Mon, 12 Jul 2004 15:47:50 +0200

The desire for schema-validity in the group seems to be pretty strong 
(more so than I guessed). Which means an XML Schema is more desirable, 
which in turn means that element order standardization is probably also 
desirable.

--verbose :  granted that the normative schema will (only) be defined in 
prose, schema-validity in this sense will be a MUST. The informative 
machine-readable schemas would in effect offer schema-validation as a 
MAY. But a very desirable MAY in development, to assist with 
forementioned MUST. Given that lack of element order (and nesting) make 
the XSD either painful or under-constrained, I think there's a good case 
for mandating an order (disallowing any optional nesting).

Cheers,
Danny.

Danny Ayers wrote:

> processor validation a MAY) or allowing any order. I suspect the 
> latter is more likely to gain consensus.
>
> Cheers,
> Danny.
>

-- 

Raw
http://dannyayers.com

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 12 Jul 2004 10:44:27 -0400

> for mandating an order (disallowing any optional nesting).

-1 

Let's not twist ourselves in knots
to accomdate the shortcomings of XSD.

    -joe

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 12 Jul 2004 15:49:13 +0100

Graham wrote:

>> feed-wide metadata with entry defaults, in a manner something like this:
> 

If this is what is really wanted, let's mark it up:

<feed>
   <defaults>
     <author name="person A">
      ...
   </defaults>
   <entry />
   <entry />
   ...
  </author>

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 12 Jul 2004 16:08:14 +0100

>     <atom:entry>...</atom:entry>

No, the issue I had in mind when I wrote that Pace remains:

   <atom:feed>

cheers
Bill

---

From: Ken MacLeod <[email-masked]>
Date: 12 Jul 2004 10:35:34 -0500

> If this is what is really wanted, let's mark it up:

Is it your preference for a "defaulting" model rather than an
"explicit reference" model?

Just want to make sure.

  -- Ken

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 12 Jul 2004 16:24:40 +0100

> why one of #2 or #3 is better than the other.  -Tim

As the Pace author, 2 captures my intent. Here's what I was after

  1. I don't care how anyone orders or sorts entry elements. That 
seems to be the /intent/ of the wording I wanted to change. 
Unfortunately the wording is not limited to just that intent.

  2. I care that we do not have non-entry elements and entry 
elements interpolated. They are written in the document in a 
particular order; Atom markup should respect that order. There is no 
requirement for it to do so.

I can't get past the notion that having all the feed metadata and 
entries at the same level is poor design. That is, mixing of 
individual and repeating elements at the same level while explicitly 
allowing arbitrary ordering is poor design.

3 is interesting - imho RSS1.0 via its channel element gets this 
right; we don't.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 12 Jul 2004 16:35:57 +0100

> Some questions, starting with the biggy:

XML. Schemata. Clarity, Robustness.

But really we should be asking why are we specifying disorder.

> Would an order make any significant difference to an application?

Again, I would instead ask what the value of no order is.

> How useful is it to have feed-level metadata up front? Are incomplete 

I've always found this a strawman, but yes, they are.

> Would it make any significant difference to the XML processor?

That depends on the processor.

> If not, in what respect is the format underconstrained? 

The intent of the wording *seems to be* and all discussion here 
about ordering prior to that Pace *was* that the spec is not going 
to tell you how to order entries - there shall be no mandated 
natural order entries. But the wording spills over to cover all 
immediate children atom:feed. Thus I claim the spec wording is 
underconstrained.

> If there is to be a specific ordering, what should it be?

As we're not going to have normative schema, then it should be the 
order written out in the spec. That is if atom:author comes after 
atom:entry in the spec then atom:author comes after *every* 
atom:entry in every instance of valid Atom markup.

Seriously, if we're going to allow free for all ordering of elements 
Atom, XML syntax becomes something a non-requirement. We should be 
using Python dicts or something that better reflects the needs of 
the spec.

cheers
Bill

---

From: Ken MacLeod <[email-masked]>
Date: 12 Jul 2004 10:48:13 -0500

> references. Wouldn't this be better still for achieving independence

The benefits of using references is misunderstood when communicative
shorthands are used in examples.  This isn't so much about
establishing referential identity as it is about redundancy.

Here's a less-shorthanded version of the example:

<feed>
  <entry>
    <site>
      <title>Kitty Adventures.</title>
      <link rel="alternate" type="text/html" href="http://example.com/kitties/"/>
    </site>

    <author>
      <name>Kitty Owner</name>
    </author>
      ...
  </entry>
  <entry>
    <site>
      <title>Kitty Adventures.</title>
      <link rel="alternate" type="text/html" href="http://example.com/kitties/"/>
      <author ref="tag:example.com,2004:authors/kitty"/>
    </site>

    <author>
      <name>Kitty Owner</name>
    </author>
    <contributor>
      <name>Best Friend</name>
    </contributor>
    ...
  </entry>
</feed>

I see the primary solution for "solving" the "physical feed
defaulting/inheritance" issue as having entries be as independent as
possible.  The above example most definitely achieves that, but at a
cost of significant redundancy.  A secondary solution of references is
therefore proposed to address the newly created redundancy issue.

  -- Ken

---

From: Norman Walsh <[email-masked]>
Date: Mon, 12 Jul 2004 11:49:42 -0400

/ Bill de hÓra <[email-masked]> was heard to say:
| Norman Walsh wrote:
|
|> If we want to make a distinction between atom:entry children and other
|> children, I suggest that we put the other children in a wrapper.
|>   <atom:feed>
|>     <atom:feedinfo>
|>       <atom:title>...</atom:title>
|>     </atom:feedinfo>
|>     <atom:entry>...</atom:entry>
|>   </atom:feed>
|
| No, the issue I had in mind when I wrote that Pace remains:
|
|    <atom:feed>
|      <atom:entry>...</atom:entry>
|      <atom:feedinfo>
|        <atom:title>...</atom:title>
|      </atom:feedinfo>
|      <atom:entry>...</atom:entry>
|    </atom:feed>

Sorry. Having put all the metadata into feedinfo, I imagined that we would
also require feedinfo to be first.

  atom:feed = atom:feedinfo, (atom:entry|anyExtensionElement)*

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Simplicity is always a virtue.--Edward
http://nwalsh.com/            | Abbey

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 12 Jul 2004 16:54:02 +0100

> "explicit reference" model?

Ken,

Explicit reference (ie "let's be clear about what we're doing 
here...").

I'm agreeing with you so far on the need for defaulting (we don't).

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 12 Jul 2004 16:58:57 +0100

>   atom:feed = atom:feedinfo, (atom:entry|anyExtensionElement)*

That's the point. Even if you put all feed metadata into a feedinfo 
block, you still need to alter the wording in question to specify 
said block can't appear just anywhere (it can at the moment).

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 12 Jul 2004 16:50:32 +0100

> to accomdate the shortcomings of XSD.

It's not an XSD issue. It's an XML issue. In my mind anyway.

cheers
Bill

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Jul 2004 02:25:18 +1000

> therefore proposed to address the newly created redundancy issue.

your extended example has some confusing things in it. For example, where is
"tag:example.com,2004:authors/kitty" defined? It is referenced, but not
defined.

perhaps this:

<feed>
    <definitions>
        <channel id="tag:example.com,2004:channelOne">
            <title />
            <tagline />
            ...
        </channel>
        <person id="fred">
            ...
        </person>
    </definitions>
    <entries>
        <entry>
            <channel ref="tag:example.com,2004:channelOne" />
            <author ref="fred" />
            <contributor>
                ...
            </contributor>
        </entry>
        <entry />
        <entry />
        <entry />
        <entry />
        <entry />
     </entries>
</feed>

Here we can have a "site" [1] represented only once, and within a container
that allows "site" specific ns-extensions, and then repeatedly referenced by
multiple entries in a minimal manner. Ditto with persons and copyright and
whatever else comes to mind. We could also allow multiple different
definitions of the same type (eg. multiple "sites") ... which allows for
synthetic feeds nicely.

Note that it wouldn't be necessary to use the <definitions> mechanisms ... a
fully flattened feed could be published which contains no id/ref uses, just
massive redundancy (which gzip helps, a bit).

What's missing here though is the concept of who is producing/publishing
this [entire document]. That is, if pubsub was to publish a synthetic feed,
then we would see multiple <channel> elements defined and used, but we'd
still need one more to say "this is a pubsub feed, even though none of the
entries come from pubsub". We need another another container on peer with
<definitions> and <entries>. Maybe <publication> or <feed>??

e.

[1] "site" ???? some sites have multiple feeds. "channel" fits better.

---

From: Antone Roundy <[email-masked]>
Date: Mon, 12 Jul 2004 10:38:51 -0600

> "explicit reference" model?
Just for the record, we can have both.

<feed>
	<referenceable>
		<person name="asdf">
			...
		</person>
	<referenceable>
	<defaults>
		<author>
			...
		</author>
	</defaults>
	<entry>
		<!--default author-->
	</entry>
	<entry>
		<author ref="asdf" />
	</entry>
	...
</feed>

---

From: Ken MacLeod <[email-masked]>
Date: 12 Jul 2004 12:25:34 -0500

Eric Scheid <[email-masked]> writes:

> > defaulting/inheritance" issue as having entries be as independent
> > as possible.  The above example most definitely achieves that, but
> > at a cost of significant redundancy.  A secondary solution of
> > references is therefore proposed to address the newly created
> > redundancy issue.
> 
> your extended example has some confusing things in it. For example,
> where is "tag:example.com,2004:authors/kitty" defined? It is
> referenced, but not defined.

gah.  copy-n-paste error from another example, the second embedded
"site" should not be referencing an author, since the entry explicitly
embeds the author.

> Note that it wouldn't be necessary to use the <definitions>
> mechanisms ... a fully flattened feed could be published which
> contains no id/ref uses, just massive redundancy (which gzip helps,
> a bit).

Rather than a <definitions> element, I think free-standing "entity
constructs" beneath <feed> would be fine (and supporting the streaming
order requirements intended by PaceElementOrder).  I think it was Bill
de hÓra who just mentioned that this is pretty much how RSS/RDF 1.0
does it with <rss:channel>.

> What's missing here though is the concept of who is
> producing/publishing this [entire document]. That is, if pubsub was
> to publish a synthetic feed, then we would see multiple <channel>
> elements defined and used, but we'd still need one more to say "this
> is a pubsub feed, even though none of the entries come from
> pubsub". We need another another container on peer with

Note: in this model I think of all <feed>s as a "physical feed",
distinct from some "logical" model of where entries come from (site,
category, query).  Here is how you associate a physical feed to its
source site:

<feed id="tag:synth-site,2004:synth-feed-42">
  <site ref="synth-site"/>
  <modified>2004-05-27T03:48:48Z</modified>
  <site id="site1">
    ...
  </site>
  <site id="synth-site">
    <title>Synthesizing site</title>
    ...
  </site>
  <person id="person A">
    ...
  </person>
  <person id="person B">
    ...
  </person>
  <entry id="tag:site1,2004:00001">
    <site ref="site1" />
    <author ref="person A" />
  </entry>
  <entry id="tag:site1,2004:00002">
    <site ref="site1" />
    <author ref="person B" />
    <contributor ref="person A" />
  </entry>
</feed>

Here, elements that have an @id are "entity constructs" that are
effectively independent whereever they occur, and any other elements
are properties of the containing element.  Elements with @ref are
property elements that reference other entity constructs.

  -- Ken

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Jul 2004 03:53:38 +1000

> does it with <rss:channel>.

my thinking with <definitions> is that it is mostly obvious that what is
contained therein are definitions which need to be referenced elsewhere to
be instantiated. Compare this with a free-floating <tagline> element ...
because it is free-floating as a feed-immediate-child does that mean it
applies to this feed?

>   <title>Synthesizing site</title>

if you want to satisfy a streaming parser, you'd better define <site
id="synth-site"> before you reference it with <site ref="synth-site"> ;-)

bundling them all in <definitions>, and requiring that block to be before
<entries> or <this-feed-info>, is one way to support block level
cardinality.

> category, query).

With synthetic feeds you would want to reference sources, but we still have
to allow for including entries which are specific to this particular feed.
That is, they are not synthetically included in from elsewhere. These could
be little editorial/advertorial announcements (like "this feed provided by
SynthetiCorp - upgrade now to get full content!"), or maintenance notes
("news from abroad will be delayed today"), or even blatent advertisments
("Soylent Corp says eat the green crackers!").

Thus, we'd need a way of saying "this feed document is the source of this
entry, not someplace else".

e.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Jul 2004 11:51:23 -0700

There's a lot of things we *could* do. What's the motivation for either 
defaulting or referencing?

   a) smaller feed representations
   b) save people from excessive keystrokes
   c) modularity
   d) ???

I'm concerned about the complexity and potential vagueness that ANY 
solution in this space might introduce. The simplest thing to do is to 
not have any defaulting or referencing mechanism, so that everything in 
the feed has to be explicit; i.e., if you want entries to have an 
atom:author, each entry must have an atom:author.

Which of the motivations listed above is of enough concern to justify 
the added machinery?