RSS Advisory Board

Dave,I'm all for this change. At Medscape, we have many, many items that are authored by physicians outside our organization and do not want to put our there emails on our feeds. In order to stay "on spec" we were forced to kluge the authors' names into . Not ideal. You've got my support for this one. It's pragmatic and makes sense.Steve

For once... I would much prefer to keep the author field as is.

If you want to provide alternative author information, you could always use the enclosure tag to point to a vCard or such.

There is no need to break the specification for such a triviality.

Makes sense to me. Nothing precludes an enclosure or module offering richer and more structured info, but letting the basic item-level author be kind of fuzzy is a rational response to the fact that it *is* kind of fuzzy.

- Jon

Makes sense to me too. I agree.

Hello all,I'd like to expand this idea to cover the managingEditor, webMaster, and author elements.Thiswould allow for the potential reduction of spam. I would like to beable to put a Manila profile page URL into the above elements.Please see the related Re: question re: Manila RSS feed thread over on manila-dev (you may need to sign up).Toodle-loooooooo..........ThomaseditHere.com website hosting service.  "Websites as easy as see it, edit it, save it! SM"

Jon & Brent: fair enough, it's your call anyway.

Just keep in mind that you are going to break the specification for frivolous reasons. It's not because people's feeds do not validate that this is a good enough reason to change the spec.

Plus dc:creator is already "fuzzy" enough to stick whatever you feel like in it. No need to break everything along the way.

There is two ways to look at this circus:

- The spec matter and we take it seriously.

- It just doesn't matter a damn and we can all go home.

Also, I would very much appreciate if any change follows a formal process: there was no less than three proposals made today. Randomly adding comments to some blog is not my understanding of a "formal process/voting".

Thanks in advance for your understanding.

"These changes shouldn't break anything" is exactly the point, btw. Notsomething to be casual about. It's much easier to define a new element in anamespace that behaves exactly as you want. That CAN'T break anything. Bigdifference.-- Dave Winer

Is that a case of "Do as I say, not as I do"?

Well... perhaps the Board could consider formally voting on the four items on today's agenda?

groups.yahoo.com

> There is no need to break the specification for such a triviality.

The speakers of a language ultimately define it, not the writers of the dictionary. If the speakers of RSS are using the item-level author field in a certain way, nothing can stop them.

However, to your point, it would be useful to know what whether existing applications depend on the presence of an email address (real or imaginary) in that field, in what ways they depend on it, and what the consequences of a liberalizing change might be. Do you have examples?

- Jon

Re: Do you have examples?

zoe.nu

The speakers of a language ultimately define it, not the writers of the dictionary. If the speakers of RSS are using the item-level author field in a certain way, nothing can stop them.

Agree. But this is not about the Oxford Dictionary.

This is about a gratuitous change to a random spec. It's so happen that the "delinquent speaker" is also a Board member. Conflict of interest?

Zoe: I'd be more willing to continue this discussion if you would identify yourself. Are you Raphaël Szwarc, the author of Zoe, about which I have written (www.oreillynet.com)? If not, then who?

Re: identify

Yes.

On the other hand... perhaps I'm his evil twin. Or perhaps this fabled "R. Szwarc" doesn't exist in the first place. How could you know? How could you tell the difference?

"On the Internet, nobodies know you are a dog"-- Unknown

I don't think this is a trivial or gratuitous change at all. One of the points behind RSS is the automated processing of feeds. I do not want to provide spammers with yet another way of automatically finding my contact email addresses, nor should the specification force me to do so.

I live in a rural area where only dialup or satellite broadband are available. Until I recently bit the bullet and configured my dreamhost account to remove all attachments and convert all email to plain text, I was having to deal with literally dozens upon dozens of 143K+ emails which made my email account almost useless over dialup.

I welcome this proposal and think it is a realistic proposal to help the community.

I agree that for spam purposes alone this is a good change.It seems trivial to parse the author field to determineif it is indeed an email field for those tools that maywant to make use of it. Email addresses though should not be required when there are many other ways to relay infomationabout the author. What about those authors that may actuallynot have an email address but are posting online to blogs?

> Or perhaps this fabled "R. Szwarc" doesn't exist in the first place

Perhaps not. But OK, good enough for me. So, fabled R. Szwarc, please now tell us more specifically in what way the Zoe application depends on a (real or imaginary) email address in the item-level author field, please explain who will be incovenienced if the spec were to change, and please detail the nature of the incovenience.

I'd also like you to weigh that inconvenience against the feeling, expressed elsewhere in this thread, that circumstances have changed w/respect to public exposure of email addresses and that RSS should acknowledge the new situation.

If we were to vote today, I'd vote for the proposed change. But if I'm missing vital information, I'd like to know what I'm missing.

- Jon

Jon, the other thing that has to weigh on this decision is that the auther element is new. I would be surprised if any of the publicly available aggregators use it any way other than displaying its literal value. I can tell you for sure that Radio won't care, and won't break. The Manila aggregator won't either.

Another possibility, to address the concern about webMaster and managingEditor, which date back to RSS 0.91 and scriptingNews formats (in other words are ancient) is to allow author to be used at the channel level, much like the category element is allowed at either the item or channel level.

Jon: Thanks for taking the time to formulate an answer.

But... as you pointed out previously... this doesn't matter one way or another...

As you don't seem to frequent the RSS2-Support mailing list... here is an handy reference for your perusal:

groups.yahoo.com

The crux of it being:

Mea culpa. I made the naive mistake to take this "Specification" and "Board" fantasy seriously. Why bother? As Mr Udell rightly pointed out:

"The speakers of a language ultimately define it, not the writers of the dictionary."

Re: public exposure

And? Does this implies that you should not provide a valid email format? Sounds like a very bogus argument to me. In any case, who cares. Anything goes.

I am "but an egg", being more of a consumer than producer of RSS, but I would like to point out a few things about this topic:

One, while "speakers of a language ultimately define it", people who are new to a language consult the dictionary when learning to use it. Therefore, the dictionary exists to teach people how the language is used. Thus, someone new to the language, when saying "My name is Bill," expects to be understood. What he didn't know is that some people decided that "name" means a body part and "bill" means itching, so he's looking silly.

Secondly, AmphetaDesk ( www.disobey.com ), my peronal favorite aggregator, uses the author element, assuming it's an email address, constructing a mailto: anchor tag from it.

Seems to me that if you don't want spam, don't use the element, or set up a special email account, or use some filters, or whatever.

If we can't trust the standard as published, what can we trust?

This sounds suspiciously like discussions on some web development forums, where people debate whether it's okay that some WYSIWYG editors use bold and font tags for headings. Sure, it gets the point across, but at what cost?

My two cents anyway.

Hello all,

Dave Winer said...

Another possibility, to address the concern about webMaster and managingEditor, which date back to RSS 0.91 and scriptingNews formats (in other words are ancient) is to allow author to be used at the channel level, much like the category element is allowed at either the item or channel level.

Perhaps two new channel level elements would be in order to preserve the distinction between the webMaster and managingEditor. Something like webMasterContact and managingEditorContact. They would be optional and would allow relatively arbitrary strings. The elements could contain email addresses (would be redundant), suitably encoded HTML, URI, etc... Toodle-loooooooo..........Thomas

editHere.com website hosting service. "Websites as easy as see it, edit it, save it! SM"

> Mea culpa. I made the naive mistake to take this "Specification" and "Board"> fantasy seriously. Why bother? As Mr Udell rightly pointed out: "The speakers of> a language ultimately define it, not the writers of the dictionary."

Zoe: Dictionaries that don't adapt to current practice are more useful than dictionaries that do?

> Secondly, AmphetaDesk ( www.disobey.com ), my peronal favorite> aggregator, uses the author element, assuming it's an email address, constructing > a mailto: anchor tag from it.

Thanks Mike. That's the kind of example I was looking for.

> Seems to me that if you don't want spam, don't use the element

It was never required. It is not much used, but when used is often misused.

There are two ways the board can respond:

1. Acknowledge current practice.

2. Reject current practice, and recommend a namespaced alternative -- though as pointed out somewhere, dc:creator is currently as fuzzy as the proposed liberalization of item-level author.

Dave says that the second approach hasn't worked:

> This question comes up regularly, and I counsel people to invent a new> namespace and use an element from that space and give it the value that makes sense.

This, let's be clear, was the context in which the liberalization proposal arose.

Mike points out:

> if you don't want spam, don't use the element

Indeed that's the status quo. And yet, people who don't want spam nevertheless do use the element, in violation of the spec.

Dave's proposal seems reasonable to me. Like Dave, I would prefer that people follow the spec and use other means to communicate metadata not explicitly supported by the spec. But look at what really happens -- this from the Many-to-Many blog:

<title>Castronova on Shadowbane's Inflation (Clay Shirky)</title>

That tells me that there's real need for item-level author info that is a) not an email address, and is b) part of the RSS core, not an extension.

My notion of my responsibility as a board member is that I'm here to help RSS respond to such needs, and deal with changing environmental conditions.

It's ironic and significant that email is at the heart of this discussion. Many serious observers are suggesting that email's days are numbered. I'm not convinced that's true, but email sure is broken right now. If it goes down the tubes and Jon Postel is up there somewhere, watching, I doubt he'll take comfort in the fact that nobody found a way to keep SMTP viable.

- Jon

Why not split this element up in authorName and authorEmail? This would make things clear by the name itself, and the 'author' field can never lead to any confusion anymore.

> Jon, here is an illustration of what ZOë does with a RSS feed:

Thanks for the concrete example.

> Perhaps a fresh set of examples demonstrating best practices > would be more beneficial overall?

Perhaps a different attitude, from you, would be beneficial too.