Subject: Re: PaceElementOrder: options

From: Randy Charles Morin <[email-masked]>
Date: Mon, 12 Jul 2004 14:15:33 -0700 (PDT)

Danny Ayers wrote:
>>Some questions, starting with the biggy:
>>Why order the elements? 
Bill de hÓra wrote:
>XML. Schemata. Clarity, Robustness.
>But really we should be asking why are we specifying disorder.
Danny Ayers wrote:
>>Would an order make any significant difference to an application? 
Bill de hÓra wrote:
>Again, I would instead ask what the value of no order is.

I like these question? Why disorder? What is the value of not specifying the order? I know that I have major pluses w/ my tools if we can just specify order. What's the counter argument?

Randy
http://www.kbcafe.com

---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!

---

From: Norman Walsh <[email-masked]>
Date: Mon, 12 Jul 2004 17:35:25 -0400

/ Randy Charles Morin <[email-masked]> was heard to say:
| I like these question? Why disorder? What is the value of not
| specifying the order? I know that I have major pluses w/ my tools if
| we can just specify order. What's the counter argument?

Usability and flexibility. As a user, I don't want to remember which
comes first, atom:modified or atom:issued. And as an implementor, I
wouldn't want to be required to sort the metadata that came out of my
internal representation into some particular order.

Defining an order also encourages people to think that order is
significant; I predict that this will lead to confusion in the area of
extensions.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Is your cucumber bitter? Throw it away.
http://nwalsh.com/            | Are there briars in your path? Turn
                              | aside. That is enough. Do not go on to
                              | say, 'Why were things of this sort ever
                              | brought into the world?'--Marcus
                              | Aurelius

---

From: Walter Underwood <[email-masked]>
Date: Mon, 12 Jul 2004 14:45:50 -0700

--On Monday, July 12, 2004 02:15:33 PM -0700 Randy Charles Morin 
<[email-masked]> wrote:
>
> I like these question? Why disorder? What is the value of not specifying
> the order? I know that I have major pluses w/ my tools if we can just
> specify order. What's the counter argument?

Increased interoperability and minimal specification. The internet
robustness principle, specifically the "be generous in what you accept"
part, and avoid specifying things that don't really change the content
of the message.

Mail headers and HTTP headers do not have a required order. They
work fine.

A specified order means that we can have a completly legal message
except that the order of two elements is swapped. The content and
semantics are fine, except that the "issued" date is listed after
the "modified" date instead of before.

If we say that clients MUST NOT accept feeds with out of order
elements, then this will (probably) be caught. If we say SHOULD NOT,
then this might not be found until after it is deployed. That is
an interoperability problem.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Jul 2004 14:48:06 -0700

How will extensions be ordered, in relation to the "core" metadata as 
well as themselves?

How do your tools benefit from ordering?

On Jul 12, 2004, at 2:15 PM, Randy Charles Morin wrote:

> I like these question? Why disorder? What is the value of not 
> specifying the order? I know that I have major pluses w/ my tools if 
> we can just specify order. What's the counter argument?

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

---

From: Randy Charles Morin <[email-masked]>
Date: Mon, 12 Jul 2004 15:12:17 -0700 (PDT)

>How will extensions be ordered?
I suggest we use prior art, the same approach as HR-XML [1]. The HR-XML vocabulary and schemas indicate where the extensions should be located w/in the core elements, but does not impose an order on the extensions relative to other extensions.
 
>How do your tools benefit from ordering?
Example - If you generate C# using XSD.exe [2] from my Atom XSD [3] and the elements are not ordered, then the generated classes do not account for cardinality of the unordered elements. This is because XSD cannot describe cardinality of unordered elements. If the elements are ordered, then the generated class can account for cardinality of elements and can be made to exactly describe the Atom data model. So, by ordering elements, I can create perfectly matched syntax helper classes without writing one line of code (all generated code). I can do this w/ XSD to generate C# and VB and XMLSpy to generate Java, C# and C++ [4]. 
Thanks and now its your turn,
 
Randy
http://www.kbcafe.com
 
[1] - http://www.hr-xml.org/channels/home.htm
[2] - http://msdn.microsoft.com/library/en-us/cptools/html/cpconXMLSchemaDefinitionToolXsdexe.asp
[3] - http://www.kbcafe.com/rss/?guid=20040710135750
[4] - http://www.kbcafe.com/iBLOGthere4iM/?guid=20031215221537

Mark Nottingham <[email-masked]> wrote:
How will extensions be ordered, in relation to the "core" metadata as 
well as themselves?

		
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 13 Jul 2004 01:31:49 +0100

Norman Walsh wrote:

> comes first, atom:modified or atom:issued. 

Yet as a user I will have to remember which elements are optional, 
which have children, what attributes apply. Such concerns about the 
order of a handful of elements on the user seem misplaced compared 
to @rel, @type, atom:content or atom:author.

> And as an implementor, I

Metadata's a red herring. We're talking about well known elements 
not arbitrary keyed stuff. If we were working with arbitrary keys, 
then I would claim RDF is yer only man, and not XML. [but see the 
last para below]

Perhaps I don't understand the sort burden beyond my own work - 
worst case in code this is an operation over a dictionary's keyset 
to emit a known order, no?

> significant; I predict that this will lead to confusion in the area of

Ahh; well I predict it won't, at least until there's some specific 
extensions, usecases, or extensibility models to look at! Even then, 
ordering of extensions elements doesn't seem to be the same issue as 
ordering of core elements.

If the intention is to make this feedinfo thing an associative array 
to aid extensibility, that needs to be spec'd out *. 'Cos that's not 
what we have.

cheers
Bill

* 'atom:dict' maybe

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 13 Jul 2004 01:36:17 +0100

> part, and avoid specifying things that don't really change the content

However this 'content' is inscribed in XML syntax, and normal use of 
said XML is to declare an element order.

> Mail headers and HTTP headers do not have a required order. They

Not the same thing. Those are defined pretty much to be extensible 
dictionaries. We don't appear to have such a definition, but people 
are talking as though we have - this is my point.

> elements, then this will (probably) be caught. 

I don't see asking people to emit a list of XML elements in a given 
order to be a burden; in the scheme of things it's trivial compared 
to asking them to get the encoding straight.

cheers
Bill

---

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

On Jul 12, 2004, at 3:12 PM, Randy Charles Morin wrote:

> Example - If you generate C# using XSD.exe [2] from my Atom XSD [3] 
> and the elements are not ordered, then the generated classes do 
> not account for cardinality of the unordered elements. This is because 
> XSD cannot describe cardinality of unordered elements. If the elements 
> are ordered, then the generated class can account for cardinality of 
> elements and can be made to exactly describe the Atom data model. So, 
> by ordering elements, I can create perfectly matched syntax helper 
> classes without writing one line of code (all generated code). I can 
> do this w/ XSD to generate C# and VB and XMLSpy to generate Java, C# 
> and C++ [4].

In other words, there are a minority of XML tools that rely upon a 
quirky, very limited and problematic expression of constraints upon XML 
-- i.e., XML Schema -- and therefore you'd like to constrain the syntax 
of Atom to accommodate its limitations and thereby enable a few 
implementors to save some time doing code generation. If I read you 
right, it still won't be possible to describe the cardinality of 
extensions; only the core metadata will have this feature. Furthermore, 
it sounds like it will still be possible to do code generation; people 
will just have to go back and tweak their implementation to account for 
cardinality.

Keeping this in perspective, those same implementers will be writing 
GUIs, integrating network stacks, presentation engines, etc. and there 
will be many orders of magnitude fewer such implementers than there 
will be Atom authors, who will have to remember the proper ordering of 
these elements and have one more reason why their feeds are broken. 
Even more so, the ordering of metadata has absolutely no semantic 
relevance; it doesn't carry any information at all.

Can you understand why the need to enable this scenario doesn't 
overwhelm me?

---

From: Tim Bray <[email-masked]>
Date: Mon, 12 Jul 2004 20:51:43 -0700

> Can you understand why the need to enable this scenario doesn't 

Mark, climb down.  What they're saying is that IF you require strict 
ordering of elements, THEN a substantial class of software tools will 
find Atom easier to deal with.  I think we're looking at a straight 
cost-benefit trade-off here.

Basically, do we
1) think that the benefits of enabling XML Schema use exceed the costs 
of strict ordering, or
2) think that the benefits of loose ordering exceed the costs of making 
life harder for the schema-dependent, or
3) are we missing the point because the trade-off isn't real or there's 
a way to dodge it or something?

These seem like reasonable open questions that we should discuss 
reasonably. -Tim

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 13 Jul 2004 04:57:03 +0100

Mark Nottingham wrote:

> If I read you 
> extensions; only the core metadata will have this feature. 

Red herring. I'm only interested in the elements we have to hand.

> will be many orders of magnitude fewer such implementers than there will 
> be Atom authors, who will have to remember the proper ordering of these 
> elements 

This is the least of anyone's current comprehension worries.

> Even more 
> so, the ordering of metadata has absolutely no semantic relevance; it 
> doesn't carry any information at all.

Not the point; order of elements in XML syntax is significant. Going 
against that seems to based on some notion that something might 
break somewhere because the effort to order elements is alledged to 
be too much. Woe betide us perhaps, but I'm utterly unconvinced. 
Perhaps this will make sense to me when we have an extensibility model.

And what's with with all this metadata talk anyway? Sounds dangerous ;)

cheers
Bill

---

From: Randy Charles Morin <[email-masked]>
Date: Mon, 12 Jul 2004 20:55:28 -0700 (PDT)

But the argument that order is too difficult is overwhelming? Statements like "minority of XML tools" indicate to me that you are not prepared to be reasonable. VS.NET and XMLSpy are two of the most popular XML tools, if not the two most popular XML tools.
Thanks,
 
Randy
http://www.kbcafe.com

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Jul 2004 21:18:40 -0700

On Jul 12, 2004, at 8:55 PM, Randy Charles Morin wrote:

> But the argument that order is too difficult is overwhelming?

No, the argument is that the benefits are minimal and diminishing, and 
the costs are high.

> Statements like "minority of XML tools" indicate to me that you are 
> not prepared to be reasonable. VS.NET and XMLSpy are two of the 
> most popular XML tools, if not the two most popular XML tools.

XML Spy is so broken it hurts. Seriously; if I had a dollar for every 
time I heard someone say "But XML Spy said it was valid" I'd be flying 
business a lot more than I do.

Besides, as soon as there's ONE decent Atom library for Java and one 
for C#, this argument will be completely without base.

Cheers,

---

From: Randy Charles Morin <[email-masked]>
Date: Mon, 12 Jul 2004 21:25:52 -0700 (PDT)

More complete list of tools that behave better if XML is ordered in the XSD.

Ones that I've used...

   XSD.exe - http://msdn.microsoft.com/library/en-us/cptools/html/cpconXMLSchemaDefinitionToolXsdexe.asp
   WSDL.exe - http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp
   XMLSpy - http://www.altova.com/products_ide.html
   VS.NET - http://msdn.microsoft.com/vstudio/
   Apache Axis - http://ws.apache.org/axis/
   MSSOAP SDK - http://www.microsoft.com/downloads/details.aspx?FamilyId=C943C0DD-CEEC-4088-9753-86F052EC8450&displaylang=en
   IBM SOAP4J - http://www.alphaworks.ibm.com/tech/soap4j/

And others that I haven't used.

   Code Generation Extensions - http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=80258a8c-bb4c-48e6-948b-05f6da568f55
   Castor Eclipse plugins - http://xdoclipse.sourceforge.net/
   WSDL2Java Eclipse plugin - http://www.myspotter.com/wsdl2java.shtml
   Novell's jBroker - http://www.novell.com/documentation/workbench41/docs/jbroker-web/docs/reference/tools/wsdl2java.html
   Webmethods - http://www.webmethods.com/docs/glue/api/electric/wsdl/tools/WSDL2Java.html

Thanks and sorry about that last one,

Randy
http://www.kbcafe.com

implementors to save some time doing code generation. 
		
---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Jul 2004 21:56:29 -0700

On Jul 12, 2004, at 9:25 PM, Randy Charles Morin wrote:

> 	1.  	XSD.exe -  
> http://msdn.microsoft.com/library/en-us/cptools/html/ 
> cpconXMLSchemaDefinitionToolXsdexe.asp
> 	2.  	WSDL.exe -  
> http://msdn.microsoft.com/library/en-us/cptools/html/ 
> cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp
> 	3.  	XMLSpy - http://www.altova.com/products_ide.html
> 	4.  	VS.NET - http://msdn.microsoft.com/vstudio/
> 	5.  	Apache Axis - http://ws.apache.org/axis/
> 	6.  	MSSOAP SDK -  
> http://www.microsoft.com/downloads/details.aspx?FamilyId=C943C0DD- 
> CEEC-4088-9753-86F052EC8450&displaylang=en
> 	7.  	IBM SOAP4J - http://www.alphaworks.ibm.com/tech/soap4j/
>
> 	1.  	Code Generation Extensions -  
> http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx? 
> id=80258a8c-bb4c-48e6-948b-05f6da568f55
> 	2.  	Castor Eclipse plugins - http://xdoclipse.sourceforge.net/
> 	3.  	WSDL2Java Eclipse plugin -  
> http://www.myspotter.com/wsdl2java.shtml
> 	4.  	Novell's jBroker -  
> http://www.novell.com/documentation/workbench41/docs/jbroker-web/docs/ 
> reference/tools/wsdl2java.html
> 	5.  	Webmethods -  
> http://www.webmethods.com/docs/glue/api/electric/wsdl/tools/ 
> WSDL2Java.html

OK, that's a good list.

Tell me if I've got this right -- if we don't have any ordering, these  
tools will not be able to automatically generate code that understands  
the cardinality of atom elements; e.g., "MUST have only one title,"  
"MAY have up to three content sections" (I made these up). However,  
they will still be able to generate some code; it's just that any  
consideration of cardinality will have to be hand-coded in.

Are there any other semantically significant things that such a  
decision would disable Schema from describing?

Looking at that case, how would an implementation use that information,  
except through validation? I.e., would the cardinality information from  
the schema ever actually get used by an aggregator? If so, how?

 From the other side, the major problem I've heard is that ordering is  
hard to remember, and may cause more instances to be invalid. From my  
experience, this is true; it's annoying when a metadata-oriented  
application requires you to put elements in an order, even though it  
isn't meaningful. It isn't the end of the world, of course, because  
people will have references, validators, etc.

Are there any other downsides to ordering? I will grant that part of my  
motivation is a) a visceral and growing dislike of XML Schema and b) a  
perhaps-too-pedantic belief that ordering, when required, should be  
semantically significant. Let's leave those to the side.

My take is this: it's about programmer efficiency -- not capability --  
vs. ease *and* correctness of authoring. Considering that programmers  
are a) a smaller and more knowledgeable population, and b) they program  
it once, while authoring is a continual process, my leaning is towards  
unordered elements in Atom.

The fact that a good, solid Atom library that handles this stuff  
automagically will remove the burden from the programmer is what  
cemented it for me. That does require such a library to be built, while  
the libraries above are already existant, but I suspect people are  
going to build some good Atom libraries anyway, because there's a lot  
that Schema can't capture, no matter what we do.

> Thanks and sorry about that last one,

Not at all - there's heat here (on all sides, I think), but light as  
well (ditto), and I for one don't mind a bit of give-and-take if it  
gets us closer to the answer. I assumed you were of a like mind -- a  
complement, I hope :)

---

From: Randy Charles Morin <[email-masked]>
Date: Tue, 13 Jul 2004 00:59:50 -0700 (PDT)

I think we've put all the cards on the table and we come to a choice. Not that this choice isn't already made or needs to be made.

   Order the elements because it will help some tools do a better job.
   Don't order the elements because it's more difficult.

Agreed? Everything else seems to be just argumentative.
Thanks,

Randy
http://www.kbcafe.com

OK, that's a good list.

		
---------------------------------
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Jul 2004 01:19:34 -0700

OK by me; I take it my characterisation of the benefits of ordering 
were on-target? I want to make sure I understand the pros.

Cheers,

On Jul 13, 2004, at 12:59 AM, Randy Charles Morin wrote:

> I think we've put all the cards on the table and we come to a choice. 
> Not that this choice isn't already made or needs to be made.
> 	• 	Order the elements because it will help some tools do a better job.
> 	• 	Don't order the elements because it's more difficult.
>

---

From: Norman Walsh <[email-masked]>
Date: Tue, 13 Jul 2004 08:06:33 -0400

/ Bill de hÓra <[email-masked]> was heard to say:
| Walter Underwood wrote:
|> Increased interoperability and minimal specification. The internet
|> robustness principle, specifically the "be generous in what you accept"
|> part, and avoid specifying things that don't really change the content
|> of the message.
|
| However this 'content' is inscribed in XML syntax, and normal use of
| said XML is to declare an element order.

I think any appeal to "normal use of XML" is a stretch. For example,
my normal XML vocabulary is DocBook and of the 400 or so elements in
DocBook, I'd guess that only a small handful declare an order.

|> Mail headers and HTTP headers do not have a required order. They
|> work fine.
|
| Not the same thing. Those are defined pretty much to be extensible
| dictionaries. We don't appear to have such a definition, but people

Uhm, well, I thought the statement that any namespace qualfied element
was allowed basically *did* give us such a definition.

| are talking as though we have - this is my point.

Hmm. Ok, maybe we should say that's what we have then. Feeds and
entries aren't dictionaries in the strict sense because they would
allow duplicate keys, but I expect to be able to write:

  <atom:entry>
    <atom:title>...</atom:title>
    <dc:subject>Some subject</dc:subject>
    <dc:subject>Another subject</dc:subject>
    <atom:author><atom:name>Norman Walsh</atom:name></atom:author>
    <geo:lat>42.4</geo:lat>
    <geo:long>-72.2</geo:long>
    <dc:subject>Yet one more subject</dc:subject>
    <atom:modified>2004-07-12T08:38:44Z</atom:modified>
    <atom:link rel="alternate"
               href="http://norman.walsh.name/2004/07/12/someEssay"/>
  </atom:entry>

| I don't see asking people to emit a list of XML elements in a given
| order to be a burden; in the scheme of things it's trivial compared to
| asking them to get the encoding straight.

Fair enough. My preference is for a content model that allows
arbitrary order, but I won't stand in the way of consensus if I'm in
the minority.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Words--so innocent and powerless they
http://nwalsh.com/            | are, as standing in a dictionary, how
                              | potent for good and evil they become,
                              | in the hands of one who knows how to
                              | use them!--Nathaniel Hawthorne

---

From: Norman Walsh <[email-masked]>
Date: Tue, 13 Jul 2004 08:53:37 -0400

/ Tim Bray <[email-masked]> was heard to say:
| Basically, do we
| 1) think that the benefits of enabling XML Schema use exceed the costs
| of strict ordering, or
| 2) think that the benefits of loose ordering exceed the costs of
| making life harder for the schema-dependent, or
| 3) are we missing the point because the trade-off isn't real or
| there's a way to dodge it or something?
|
| These seem like reasonable open questions that we should discuss
| reasonably. -Tim

I've already said I won't stand in the way of consensus on this issue,
but let me make one more point: if we decide that the elements should
be in an order, we then have to decide *what* order. I'd be just as
happy to avoid having that discussion :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Until death, it is all life.-- Cervantes
http://nwalsh.com/            |

---

From: Randy Charles Morin <[email-masked]>
Date: Tue, 13 Jul 2004 05:56:23 -0700 (PDT)

Your understanding is accurate, but argumentative. The tools can be made to work w/ an XSD unfriendly vocabulary, but they will be much more difficult to use. Assigning the title of an entry goes from this
   entry.title = "Hello";
to this
   entry.Items = new XmlNode[1];
   entry.Items[x] = "Hello";
   entry.ItemTypes[x] = entryItemTypes.title;
Thanks,
 
Randy
http://www.kbcafe.com

Cheers,

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 13 Jul 2004 14:17:41 +0100

Norman Walsh wrote:

> I think any appeal to "normal use of XML" is a stretch.

I don't.

>                href="http://norman.walsh.name/2004/07/12/someEssay"/>

"Yuck", would be my technical assessment :) however... the pace 
we're talking about (explicitly) doen't deal with order of entry 
children just feed children (I punted). Going by your rnc, can I 
assume you expect to write:

<feed>
   <entry>
     ...
   </entry>
   <tagline>FD85 1117 1888 1681 7689 B5DF </tagline>
   <entry>
       ...
   </entry>
   <entry>
       ...
   </entry>
   <entry>
       ...
   </entry>
   <entry>
       ...
   </entry>
   <entry>
       ...
   </entry>
   <title>Bill de hÓra</title>

   <entry>
     ...
   </entry>
   <modified>2004-07-12T18:56:24Z</modified>
   <entry>
     ...
   </entry>

   <generator
        url="http://www.movabletype.org/"
        version="2.64">Movable Type</generator>
   <entry>
     ...
   </entry>
   <copyright>Copyright (c) 2004, dehora</copyright>
   <entry>
     ...
   </entry>
   <entry>
     ...
   </entry>
   <id>tag:www.dehora.net,2004:/journal//2</id>
   <link
     rel="alternate"
     type="text/html"
     href="http://www.dehora.net/journal/" />
</feed>

?

cheers
Bill

---

From: Elias Torres <[email-masked]>
Date: Tue, 13 Jul 2004 09:48:25 -0400

I like how Randy and Tim are setting up the discussion. I tend to
agree with both: we need to have order (be strict) for "dumb" tools to
understand and we need to be as simple as possible for users to
publish feeds. But, IF in fact this is a cost-benefit discussion, I
would say that the users would benefit the most (especially since
there are more of them) if we don't impose order. The number of
definitive Atom libraries will be much smaller and good programmers
write those, every other developer can just use them. Now, if a
developer chooses to start from scratch, I think by using XML we have
already given them a starting point, plus a XML Schema with choice
groups.  Lastly, all they would have to do is code up cardinality and
their personal tweaks to their library.

My two cents. 

----- Original Message -----
From: Randy Charles Morin <[email-masked]>
Date: Tue, 13 Jul 2004 00:59:50 -0700 (PDT)
Subject: Re: PaceElementOrder: options 
To: Mark Nottingham <[email-masked]>, [email-masked]
Cc: Atomlist <[email-masked]>

Randy
http://www.kbcafe.com

 

OK, that's a good list.

Are there any other semantically signif!
 icant
 things that such a 
decision would disable Schema from describing?

Are there any other downsides to ordering? I will grant that part of my 
motivation is a) a visceral and growing dislike of XML Schema and b) a 
perhaps-too-pedantic belief that ordering, when required, should be 
semantically significant. Let's leave those to the
 side.

Not at all - there's heat here (on all sides, I think), but light as 
well (ditto), and I for one don't mind a bit of give-and-take if it 
gets us closer to the answer. !
 I assumed
 you were of a like mind -- a 
complement, I hope :)

		________________________________
Do you Yahoo!?

---

From: Norman Walsh <[email-masked]>
Date: Tue, 13 Jul 2004 09:54:35 -0400

/ Bill de hÓra <[email-masked]> was heard to say:
| "Yuck", would be my technical assessment :) however... the pace we're
| talking about (explicitly) doen't deal with order of entry children

Ah. I didn't realize that. My bad. I object to any proposal that
establishes a fixed order in one place but leaves the other unordered.
Given the similarity of content, I think that's just going to be too
confusing.

| just feed children (I punted). Going by your rnc, can I assume you
| expect to write:

My RNC attempts to implement what the -00 draft says. Personally, I
favor putting all the non-entry feed elements in a wrapper, making
that wrapper the required first element of the feed, and letting the
content of that wrapper be unordered:

<feed>
  <feedinfo>
  </feedinfo>
  <entry>
    ...
  </entry>
  <entry>
    ...
  </entry>
</feed>

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | A philosophical contempt of life is no
http://nwalsh.com/            | guarantee of courage in the face of
                              | death.--Gustave Vapereau

---

From: Antone Roundy <[email-masked]>
Date: Tue, 13 Jul 2004 08:07:00 -0600

> arbitrary order, but I won't stand in the way of consensus if I'm in
I'd prefer what you might call "stream processable" order, ie. feed 
stuff before entries, and if we have any kind of inheritance, 
defaulting or referencing mechanisms, requiring things to be defined 
before use.  Other than that, arbitrary order would be my preference, 
but I won't fall on my sword for it.

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 13 Jul 2004 16:22:30 +0100

> content of that wrapper be unordered:

Ok, I'll go for that; that being:

  1. feed children are ordered: (feedinfo, entry*)
  2. feedinfo children are unordered
  3. entry children are unordered

cheers
Bill