[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [syndication] Re: Third draft of a generic syndication markup language



On Mon, 2 Oct 2000, Aaron Swartz wrote:

> Ian Graham <ian.graham@utoronto.ca> wrote:
> 
> > Comments, criticism, suggestions and contributions are, as always, greatly
> > appreciated.
> 
> Here are my thoughts from a first look:

Somehow I figured that you, Aaron, would be the first person to comment
;-)
 
> > uuid: A unique identifier for this item or collection. This is
> > unique only within a given aggregation service.
> 
> What means an aggregation service? Personally, I'd prefer this to be a
> globally unique URI -- I think that'd cause much less confusion.

Well, I also would prefer that this be a global ID. But, with many small
providers/aggregators, it is IMHO in practice impossible to get such
organizations to adopt the procedural mechanisms necessary to [properly
issue globally unique IDs -- we can't even agree on what they should be!.
Perhaps a more appropriate wording to indicate this would help.

> You also have a mistake down near the description of collection/item/data --
> you repeat the description, with the wrong element names.

Oops. Funny that my parser didn't pick that out.  I will fix it tomorrow.

> > creator contains human language-independent information about
> > the creator (person, organization, etc.) that has created
> > the data content of the message.
> 
> What does this mean? A short description? A name? This isn't clear.

It could be either, or neither (see below). It is intentionally vague --
but perhaps a bit too much. I'll work on better wording, and see if that
helps.

> > This may be different from the organization providing the metadata (which is
> > defined by the creator element of a containing 'collection' element, or is
> > implied by the information in a serviceInfo element).
> 
> It seems that the organization would do better if defined explicitly. The
> creator element of a containing collection element seems a really bad place
> to put it.

Yes, I will have to think on that. The goal was to try and find a
vocabulary -- and examples -- that make these distinctions so baldly 
obvious that even relatively naive devlopers would not get them confused.
Obviously I'm not quite there yet (which in now way places you in the
'naive' category, of course ;-) )
 
> > information for contacting the creators of the data.
> 
> Again, this is vague -- and since the content is PCDATA, I can't even use
> things like Dublin Core to clarify the meaning.

Well, I'm only using the DTD loosely here, to define the markup structure
of only those lements I've defined in hte DTD -- the intention being that
any other namespace-qualified elements would be perfectly ok.
Unfortunately DTDs have no easy way of saying that ....

> > picsRating contains 'PICS" rating information. Everybody loves
> > ratings
> 
> Not exactly. What is a specific ratings system like PICS doing in a generic
> syndication spec? Generalize! It seems a lot of this stuff would do better
> if it were opened up by use of namespaces to allow others systems to
> describe some of these things.

I inclued PICS ratings since this is the only current standard for
specifying content ratings, and because I saw it in many other standards,
but I must admit I did so with trepidation. It might be better dropped
entirely. Thoughts?

As for using namespace for extensibility -- this is precisely what I
intended. The idea is that the content of these 'core' elements could be
any 'mucky' text with ill-defined text content, since that is easy to
write and easy for (in most cases) a human being, as opposed to a piece of
software, to understand. Namespace qualified markup, (or RDF)
could then be used to meaningfully extend the semantice -- although
a less-smart processor could still process the data.

> Otherwise, it looks like your work is really progressing. I'm trying hard to
> think of actual things you've left out, but I think that in general the spec
> would do better if it clarified some terminology and allowed people to
> specify more specific items in general categories (via namespaces).

Thanks, Aaron, for your well-posed questions and ideas. I will put up
some revisions tomorrow, given a few minutes of spare time, of course ;-)

Ian
--
--
Ian Graham ..........................  http://www.utoronto.ca/ian/