[XML-SIG] Content Syndication

Dan Libby danda@netscape.com
Thu, 01 Jul 1999 22:07:56 -0700


This is a multi-part message in MIME format.
--------------FE2EB5A6AEB2FA2FBFED03C7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mark Nottingham wrote:

> One other thing. How do people feel about disallowing embedded HTML in the
> items?

HTML is a display-oriented format.  It usually is not even well-formed in the
xml sense.  Further, it has great potential to break the layout of your page,
for example, if the publisher embeds a </TABLE> tag.  It is possible to watch
for this, and avoid it, but its not exactly 'simple'.  The real problem is that
it gives the publisher control over the display of the content. In a syndicated
system, I think what you really want is to be able to publish *data*, and let
the receiver format it however they choose, so long as they can understand it.
Eg: If I'm the receiver and I think Titles should be bolded, I can insert it
into an html template that wraps <B> around all titles.  Or I can put it in a
<DIV CLASS="TITLE"> and let a style sheet handle it.  Or if I have an XML
capable browser, I can simply create a style sheet that understands the title
tag.

On second thought, one thing that might be a cool compromise is if we had an
optional tag indicating which style-sheet(s) the publisher thinks should be
used.

If you have a real need to transfer HTML documents, then what you need is
something like ICE that takes care of the packaging and tagging of documents.
Otherwise, what we provide as a subset will never be fully html compliant -- eg
some tags won't work, and will also be problematic from a validation point of
view, since HTML is generally not "valid" in the xml sense.

> > This brings up the issue of what the purpose of the format is.  RSS was
> > originally intended to be a metadata format.  ie: Information about other
> > sites.  ScriptingNews (and the above description) tend to indicate a
> desire for
> > more of a publishing/syndication approach, where the format *is* the
> content,
> > not just a description of it.  It's a fine line, and I'm not sure what the
> right
> > answer is.
>
> This is probably the first (and most important) thing to decide. SN itself
> uses the format to publish its entire content, but it's child channels
> don't; I think that's the problem.
>

I'd like to hear people's thoughts on this topic.  I'm going to be gone till
Tues though, so if I'm quiet, that's why.  My own feeling, having worked a
little with RDF and metadata previously, is that the goal should be to transfer
data about resources.  We should not try to dictate how that data will be
presented, if at all, which is what happens when embedded HTML is allowed.
Reader's comments and related links could certainly be construed as "metadata"
about a given resource, so it would be nice to be able to transmit these as
well.

-dan



--------------FE2EB5A6AEB2FA2FBFED03C7
Content-Type: text/x-vcard; charset=us-ascii;
 name="danda.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dan Libby
Content-Disposition: attachment;
 filename="danda.vcf"

begin:vcard 
n:Libby;Dan
x-mozilla-html:TRUE
org:Netscape Communications
adr:;;;Mountain View;CA;94043;USA
version:2.1
email;internet:danda@netscape.com
x-mozilla-cpt:;0
tel;home:650-964-5913
tel;work:650-937-2276
fn:Dan Libby
end:vcard

--------------FE2EB5A6AEB2FA2FBFED03C7--