Subject: Re: PacePersonRef posted

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 01 Jul 2004 17:28:49 +0200

* Antone Roundy wrote:
>* Rationale
>
>In most feeds, the author is the same for many, if not all, entries, 
>leading to repetition of author metadata. This can be avoided by 
>specifying the metadata in one place in the feed and referring to it 
>from other parts of the feed.

But your proposal still requires repetition, not the meta data, but
one has to repeat the reference again and again. Do I understand
correctly that your proposal makes the feed creator meta data non-
inheritable so that if all entries and the feed share the same
creator, one would have to state that for each entry again?

Another question, how would an Atom implementation resolve the
ambiguity auf creator meta data? Names for example are not unique
so this seems to encourage guessing which is likely to break. So
I am not sure whether it is worth to attempt to optimize for the
case where several authors each created several entries. The case
where the feed creator also created the entries however is some-
thing that would benefit from optimization, which should be done
through inheritance. We can provide control over the inheritance
if the entry author element is made optional and the case of an
entry without specified author becomes "ambiguous".

---

From: Antone Roundy <[email-masked]>
Date: Thu, 1 Jul 2004 09:56:54 -0600

> creator, one would have to state that for each entry again?
Yes, it makes the meta data non-inheritable.  Some people have 
expressed the opinion that it shouldn't be inheritable, and this 
proposal provides a mechanism for minimizing the size of the feed if 
inheritance is removed from the spec.  But I certainly wouldn't say we 
have consensus on that.  If the consensus ends up being that it be 
inheritable, then that provision of the proposal can be severed.

> so this seems to encourage guessing which is likely to break.
If you're saying that this proposal would make that situation worse, 
then I'm not following you.

> We can provide control over the inheritance
I don't follow you.  If an entry has no author and we ARE using 
inheritance, then it inherits from the feed, and is only ambiguous if 
the feed also doesn't have an author, right?

So, the questions for debate on this proposal (...when it gets to the 
Proceed list? Yeah, I keep responding too)--I think I'll add a section 
for these to the proposal:

1) Do we want a mechanism for specifying Person metadata once and 
referring to it from elsewhere in the feed?
2) Do we want entries to inherit the author from the feed if they don't 
specify one?
3) Do we want to define our own attributes (id and ref) or use common 
attributes (xml:id and xlink:href, for example).
4) Do we want to be able to refer to externally defined Person 
constructs, or must the data be local?  (This is not the same question 
as "do we want a Person construct to be extendable to refer to 
externally defined and possibly externally stored resources?", which is 
beyond the scope of this proposal.)

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 01 Jul 2004 18:52:53 +0200

>then I'm not following you.

I think so, it seems more difficult to infer from

  <author>
    <name>Mark</name>
  </author>
  ...
  <author>
    <name>Mark</name>
  </author>

that this is the same Mark as it would be from

  <author ref="x0001" />
  ...
  <author ref="x0001" />

so the proposal seems to make the format less intuitive and improper use
easier. If you'd actually generate two different person constructs for
the same meta data and thus use

  <author id="x0001">
    <name>Mark</name>
  </author>
  ...
  <author id="x0002">
    <name>Mark</name>
  </author>
  ...
  <author ref="x0001" />
  ...
  <author ref="x0002" />

what you safe in terms of bytes is rather insignificant so I am not
convinced that this would be very useful. Why do you re-use the author
element here? It would make more sense to me, as <author> would be
unstructured, to reference the author from the <entry> like

  <entry by = "x0001">...</entry>

>the feed also doesn't have an author, right?

Yes. Otherwise it is not really ambiguous but rather impossible to
specify anonymous authorship so the fact that everything would be
well-defined is not really helpful in that case.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 1 Jul 2004 14:01:54 -0600

> that this is the same Mark as it would be from

Okay, I see what you're saying now.  But I'd have to say it doesn't 
worry me too much.  If someone is concerned enough about their identity 
being properly understood, they should probably put a little more data 
in their author records.  And as they do, the probability of two 
different people having identical information in one feed will drop 
precipitously.

> the same meta data and thus use

If you know that the people are different, this probably is what I 
would expect to have done (except that the first elements in the 
example would be <person> rather than <author>...but that's not 
relevant to our current discussion).

If this proposal may make the mistake of thinking two different people 
are the same people more probable.  But conversely, it makes it 
POSSIBLE to unambiguously differentiate between two people with 
identical author metadata.

> convinced that this would be very useful.
If the Person construct contains nothing but a 4 letter name, the id is 
5 letters long, and each person authored less than 4 entries, then 
yeah, you'd actually use more bytes.  But in this case:

<person id="1">
	<name>Antone Roundy</name>
	<url>http://www.geckotribe.com/</url>
</person>

<author ref="1" />

...the reference requires just over 1/5 as many characters as the full 
Person construct would have.  As additional information gets added to 
Person constructs, the savings grow even faster.

> Why do you re-use the author
If size savings were the ONLY concern, that would be the way to go, and 
in fact, we'd put just about everything into <entry> as an attribute.  
But then, as others have said, if size savings were our primary concern 
we wouldn't be using XML at all.  The line between what goes into 
attributes and what goes into child elements has to be drawn somewhere, 
and I for one think that <author> and <contributor> information goes on 
the other side of the line.

> well-defined is not really helpful in that case.
I'm afraid I still don't entirely follow.  I suppose there are two 
issues: anonymous authorship and unknown authorship.  I don't see that 
this proposal affects anonymous authorship in any way--it's currently 
impossible to indicate that (other than to say something like 
<author><name>anonymous</name></author>, which doesn't entirely work, 
because what if the author's name (or nickname) really is 
"anonymous"?)--and this proposal doesn't change that.  Currently, there 
is likewise no way to specify an unknown author--if author were 
optional, that could be done by specifying neither a feed-level author 
nor an entry-level author, but making the entry author optional would 
only make the author unknown if no feed author were specified.  This 
proposal makes unknown authorship possible to indicate by omitting the 
entry author.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 01 Jul 2004 23:28:38 +0200

> <person id="1">

An 'id', in HTML and XML terms, should start with a letter.

> <author ref="1" />

Internal references should start with '#', and I really don't see the need  
for @ref when we already use @href everywhere.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Antone Roundy <[email-masked]>
Date: Thu, 1 Jul 2004 16:02:51 -0600

On Thursday, July 1, 2004, at 03:28  PM, Asbjørn Ulsberg wrote:
>> <author ref="1" />
> Internal references should start with '#', and I really don't see the 
> need for @ref when we already use @href everywhere.
If we decide to allow external references, then href will make more 
sense.  If not, it might be better to use something that won't suggest 
to people that they can use external references.  Whether or not to 
begin with "#" might follow the same logic.