Subject: RE: Default atom:content item

From: "Jon Davis" <[email-masked]>
Date: Sat, 2 Oct 2004 02:13:03 -0700

> ok, your basic premise is flawed: multipart/related is not supported, 
> only multipart/alternative, and so that word document shouldn't be there.
>
> if you want to provide material which are not *alternatives* to the 
> content but are related somehow to the entry, then use the <link> 
> element, which includes not only an attribute for describing the 
> relationship in question in a machine-readable form, but also a human-
> readable title attribute.

Understand that I would prefer NOT to have distinct attachments (re: your
reference to <link>). Meanwhile I'm trying to implement a reader where
multiple atom:content elements are allowed, without requiring an
atom:content[type="multipart/alternative"] parent, so atom:content elements
can be treated as distinct attachments. This is the equivalent of
multipart/mixed, unless we can remove the allowability of multiple
atom:content elements directly under atom:entry (but allow multiple
atom:content elements under an atom:content[type="multipart/alternative"]
parent). 

>> - Specify in the specification that content elements distinct from the 
>> "primary content" (attached files) should not be used, but rather the 
>> author should anticipate that all atom:content elements will be 
>> treated as identical in purpose, varying only in formatting or language.
>
> I thought the language around 'multipart/alternative' described that
behaviour.

Perhaps it would if only atom:entry didn't support multiple atom:content
elements without an atom:content[type="multipart/alternative"] parent!

Jon 

-----Original Message-----
From: Eric Scheid [mailto:[email-masked]] 
Sent: Saturday, October 02, 2004 1:54 AM
To: Jon Davis
Subject: Re: Default atom:content item

On 2/10/04 6:45 PM, "Jon Davis" <[email-masked]> wrote:

> I disagree, for the reason I explained at the start. Consider someone 
> using an Atom implementation producing an Entry with a primary 
> formatting of XHTML, an ASCII alternative, and an attached Word 
> document that should be treated as an attachment rather than as the
primary Entry content.

ok, your basic premise is flawed: multipart/related is not supported, only
multipart/alternative, and so that word document shouldn't be there.

if you want to provide material which are not *alternatives* to the content
but are related somehow to the entry, then use the <link> element, which
includes not only an attribute for describing the relationship in question
in a machine-readable form, but also a human-readable title attribute.

> - Specify in the specification that content elements distinct from the 
> "primary content" (attached files) should not be used, but rather the 
> author should anticipate that all atom:content elements will be 
> treated as identical in purpose, varying only in formatting or language.

I thought the language around 'multipart/alternative' described that
behaviour.

e.

---

From: "Jon Davis" <[email-masked]>
Date: Sat, 2 Oct 2004 02:34:22 -0700

Sorry for the flood of posts, hopefully this is my final post with one last
question (or set of questions, rather). 

Eric was correct that my premise was incorrect; I had forgotten the meaning
of "multipart/alternative", mistaking it for the meaning of
"multipart/related".

Do I understand correctly that all atom:content elements should be treated
as multipart/related unless they are under an
atom:content[type="multipart/alternative"] parent?

If this is what was intended by the specification, is there any possiblity
that an elaboration can be made as such? Essentially, what I was indicating
previously applies, but with the roles of atom:entry and
atom:content[@type="multipart/alternative"] reversed:

1. An atom:content element MAY contain more than one atom:content elements
IF the @type attribute is "multipart/alternative" AND each child
atom:content element is an alternative format of the content.
2. When multiple atom:content elements exist, readers SHOULD NOT refer to
any individual atom:content child element of an atom:entry element as
alternative content elements of the primary content of the entry. Readers
SHOULD instead determine the primary content of the entry from the hierarchy
of the atom:content children of atom:content elements marked as
"multipart/alternative".

If this is NOT what was intended by the specification, could someone please
explain whether ALL atom:content elements are multipart/alternative,
regardless of position (under atom:entry or under atom:content), and if so,
why are there two ways of listing multiple atom:content items (one way being
under atom:entry and one way being under
atom:content[type="multipart/alternative"] elements)?

Jon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jon Davis
Sent: Saturday, October 02, 2004 2:13 AM
To: 'Atom Syntax'
Subject: RE: Default atom:content item

>> - Specify in the specification that content elements distinct from 
>> the "primary content" (attached files) should not be used, but rather 
>> the author should anticipate that all atom:content elements will be 
behaviour.

Jon 

-----Original Message-----
From: Eric Scheid [mailto:[email-masked]]
Sent: Saturday, October 02, 2004 1:54 AM
To: Jon Davis
Subject: Re: Default atom:content item

primary Entry content.

e.

---

From: Sam Ruby <[email-masked]>
Date: Sat, 02 Oct 2004 06:42:15 -0400

Jon Davis wrote:
> that an elaboration can be made as such?

If you are asking if Atom 0.3 can be updated, this group has moved 
beyond that and has no plans on updating Atom 0.3.

If you are asking if draft-ietf-atompub-format-02 can be updated, the 
answer is certainly: the way you make that happen is described here: 
http://www.intertwingly.net/wiki/pie/HowToGetInvolved .

- Sam Ruby

---

From: "Jon Davis" <[email-masked]>
Date: Sat, 2 Oct 2004 03:52:41 -0700

>> If this is what was intended by the specification, is there any 
>> possiblity that an elaboration can be made as such?

Bad choice of words. What I meant was, "Would it make sense that an
elaboration be made as such?", opening it up for discussion.

> If you are asking if Atom 0.3 can be updated, this group has 
> moved beyond that and has no plans on updating Atom 0.3.

I was referring to the current IETF draft spec.

> If you are asking if draft-ietf-atompub-format-02 can be updated, 
> the answer is certainly: the way you make that happen is described 
> here: 
> http://www.intertwingly.net/wiki/pie/HowToGetInvolved
> 
> - Sam Ruby 

Yes, and that URL points here. "If you want to propose a change to the
specification, it's probably best to float the idea on the mailing list
first."

Jon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sam Ruby
Sent: Saturday, October 02, 2004 3:42 AM
To: Jon Davis
Cc: 'Atom Syntax'
Subject: Re: Default atom:content item

Jon Davis wrote:
> 
> If this is what was intended by the specification, is there any 
> possiblity that an elaboration can be made as such?

If you are asking if Atom 0.3 can be updated, this group has moved beyond
that and has no plans on updating Atom 0.3.

If you are asking if draft-ietf-atompub-format-02 can be updated, the answer
is certainly: the way you make that happen is described here: 
http://www.intertwingly.net/wiki/pie/HowToGetInvolved .

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Sat, 02 Oct 2004 08:32:35 -0700

> specification, it's probably best to float the idea on the mailing list

Unfortunately, you've kind of come in in the middle of the discussion.  
One thing that might help would be to look at 
http://www.intertwingly.net/wiki/pie/AtomPubIssuesList - in particular 
there's a lot of discussion of PaceReformedContent3 at the moment. -Tim

---

From: "Jon Davis" <[email-masked]>
Date: Sat, 2 Oct 2004 14:13:38 -0700

>> specification, it's probably best to float the idea on the mailing 
>> list first."
>

Thanks.

*sigh* Wikis. They are powerful and handy, yes, .. But it's when from
big-name domain names say things that feel like, "Where have you been? Don't
you understand that it's all discussed here at
http://www.interwingly.net/wiki/pie/SomeObscureWikiTopicThatOnlyThoseWhoHave
BeenAroundForTwoYearsWouldEverKnowAnythingAbout" that makes me feel like the
wiki-based system is powerful and seemingly sufficient, but nonetheless
flawed because each topic / page is given almost equal priority in
presentation.

This process is also slow. Atom has been under construction for months, and
the core of it is atom:content, which is as broken as it was months ago. 

I'm discontinuing my involvement here for a while, as quick as I showed up
(note that I was paying close attention since the Echo days), partly for the
benefit of all of you, not just because I feel bad for spamming the group
with so many posts in one night and annoying all of you and also for not
paying more attention to the wiki, but also because I feel like the PROCESS
of developing Atom is broken (this comment having nothing to do with my
participation herein). 

The wiki says to refer to the mailing list to discuss things. The mailing
list says to refer to the wiki to discuss things. The wiki says to get
approval from the mailing list before adding anything to the wiki. The
mailing list says to get approval from the wiki before adding anything to
the mailing list. Meanwhile, scanning the discussions, words go around in
terms of uber-knowledge and uber-education that really simply don't apply in
real-world implementation except as philosophical technical studies, and
meanwhile very little gets done in one year.

You guys need to delegate some individuals to take authoritative ownership
of certain parts of Atom, to make a decision about things, move forward, and
open the floor for discussion of what happened rather than what to do next.
Give authoritative ownership not just those who manage the wiki, mailing
list, and spec draft write-up. Your current plan encourages knuckleheads
like myself to jump in and slow things down. And perhaps those of you who
are "high on the chain", whose voices are louder than others because of who
you work for and because of your background, are enjoying some authority
freely given to you by your peers, but the fact that I am technically a peer
here gives me unease.

I give Big Company M feedback like "I don't understand how this works and I
think you should change it to such-and-such" all the time, but ultimately I
trust that Big Company M has staff on hand who will ultimately make an
educated decision even after hearing me that will probably be the right one.
In the end, stuff gets done, and it's done in days or weeks, not months or
years.

This reminds me of the difference between a democracy and a republic. A
democracy is "a government of the masses. Authority derived through mass
meeting or any other form of "direct" expression. Results in mobocracy.
Attitude toward property is communistic--negating property rights. Attitude
toward law is that the will of the majority shall regulate, whether is be
based upon deliberation or governed by passion, prejudice, and impulse,
without restraint or regard to consequences. Results in demogogism, license,
agitation, discontent, anarchy". Whereas, in a republic, "Authority is
derived through the election by the people of public officials best fitted
to represent them. Attitude toward law is the administration of justice in
accord with fixed principles and established evidence, with a strict regard
to consequences. A greater number of citizens and extent of territory may be
brought within its compass. Avoids the dangerous extreme of either tyranny
or mobocracy. Results in statesmanship, liberty, reason, justice,
contentment, and progress. Is the "standard form" of government throughout
the world. A republic is a form of government under a constitution which
provides for the election of (1) an executive and (2) a legislative body,
who working together in a representative capacity, have all the power of
appointment, all power of legislation, all power to raise revenue and
appropriate expenditures, and are required to create (3) a judiciary to pass
upon the justice and legality of their government acts and to recognize (4)
certain inherent individual rights. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Tim Bray
Sent: Saturday, October 02, 2004 8:33 AM
To: Jon Davis
Cc: 'Sam Ruby'; 'Atom Syntax'
Subject: Re: Default atom:content item

On Oct 2, 2004, at 3:52 AM, Jon Davis wrote:

> specification, it's probably best to float the idea on the mailing 
> list first."

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Sun, 3 Oct 2004 16:17:51 -0400

> The wiki says to refer to the mailing list to discuss things. 
> The mailing list says to refer to the wiki to discuss things. 
> The wiki says to get approval from the mailing list before 
> adding anything to the wiki. The mailing list says to get 
> approval from the wiki before adding anything to the mailing 
> list. Meanwhile, scanning the discussions, words go around in 
> terms of uber-knowledge and uber-education that really simply 
> don't apply in real-world implementation except as 
> philosophical technical studies, and meanwhile very little 
> gets done in one year.

For what it's worth the mailing list is the only authoritative discussion
venue for an IETF working group.  No external approval is required to
participate in a discussion on the mailing list, either.  I don't care if
people collect their thoughts on a wiki, but if any decisions are made they
need to be made and documented on this list.

-Scott-
(speaking as the area advisor for this WG)