Sean Lyndersay wrote:
> 
> As an format that is not intended for publishing on the web, but
> which is really a contract between the platform and the clients of
> the platform, the native format we use is not really required to be
> "pure" RSS 2.0.

Sean,

I'm not sure what you are looking for.  If the position you find
yourself in is that you are feature complete, the format you have
selected you expect to support in perpetuity, you have baked silent data
loss right into the Windows platform, but you will accept bug reports,
then simply realize that bug reports can be created at will.

If, instead, the position is that you have an internal data model which
is open for discussion, then we can have a discussion.  If you look on
the web, you will find plenty of RSS 2.0 feeds that contain small bits
of HTML markup -- things like bold words or italics -- in titles.  You
will find feeds with multiple enclosures.  You will find feeds with
relative references.  The RSS 2.0 spec doesn't disallow any of these,
nor does it specify how such things are to be interpreted.

Even so, such things are out there.  And they either need to be in your
model, or you have either data loss or data corruption.

You seem to think that you have picked RSS 2.0.  If you take a look at
the current food fight regarding the RSS Advisory Board, you would
realize that RSS 2.0 is frozen.  There are only two paths forward.
Creating new formats with new names, or the use of extensions.  The
newly reconsituted RSS Advisory Board thought that it could change RSS
by providing a small number of much needed clarifications.  They were wrong.

By changing what the description element is, you are changing RSS 2.0.
Call what you are creating a new format.  Or use a different element, in
a namespace.  Perhaps atom:summary would do.  Or you could create your own.

- Sam Ruby

Reply via email to