Subject:
|
Re: LENNI Additions to RSS/Atom spec - preliminary proposal
|
Newsgroups:
|
lugnet.publish
|
Date:
|
Tue, 31 Aug 2004 13:45:57 GMT
|
Viewed:
|
2803 times
|
| |
|
|
(Bah! Have to use the web interface, which means I can't reply to all three
posts I wanted to in one post. Copied from my Sent folder. )
On Tue, Aug 31, 2004 at 06:04:39AM +0000, Kelly McKiernan wrote:
> RECOMMENDED ADDITIONAL XML ELEMENTS
>
> I am proposing the addition of the following six elements to existing
> RSS/Atom elements. Each of these six elements will be defined by the
> LENNI namespace (location TBD). These elements are all to be placed
> within the ITEM/ENTRY section (RSS/Atom, respectively) of the XML
> feed, with the potential exception of the "Community" element, which
> may reside one level higher in the XML structure.
In general, I wouldn't limit us to only Item level elements. That might
be a guideline for implementation, but it shouldn't be an official
requirement, right?
> The structure of the proposal below is of the form:
> * PROPOSED ELEMENT
> - Acceptable Value
> - Acceptable Value
> - ...
>
>
> ===============================================
> * COMMUNITY (required - one only)
> - LEGO
>
> When using the LENNI namespace, the Community element is required. It
> is the only LENNI-defined required element. "LEGO" is the only value
> that should be recognized by the LENNI namespace at this time.
>
> If the usefulness of LENNI becomes apparent outside the LEGO
> community, it would be helpful to share the LENNI namespace with
> little or no changes for use in other communities. (Note: wishful
> thinking at its best.)
>
> QUESTION: Should this one element only be placed in the
> CHANNEL/FEED (RSS/Atom) section, as it covers all items/entries?
> I'm leaning that way.
Feed level makes sense to me. Also, start thinking of alternate
meanings to LENNI, if it does go beyond LEGO, the 'L' would have to find
a new meaning :)
> ===============================================
> * FILTER (one or more per item/entry)
> - News: article-type content including information and picture
> links, usually presented under an organization or group
> - Blog: personal musings and observations, usually from an
> individual
> - MOC: Information and links specifically about a custom LEGO
> creation
> - Announcement: Press release-type content, either from an
> organization or an individual
> - Event: Usually used with Calendar element, but that is not
> required
> - Market: Specific to marketplace issues, such as buying, selling,
> trading, or advising of such opportunities
>
> These filters will be specified in the LENNI namespace. A previous
> suggested name for this element, "Category," is already used in RSS
> 2.0 for a different purpose, so it can't be used here. The name
> "filter" is slightly generic, so other suggestions are welcome.
"Topic"? "Subject"? "Compartment"?
Also, is this required? I'm leaning toward saying it IS.
> ===============================================
> * THEME (one or more per item/entry)
> - Adventure
> - Bionicle
> - Castle
> - Mecha
> - Micro
> - Mosaic
> - Pirate
> - Robotics
> - Sculpture
> - SNOT
> - Space
> - Sports
> - Star Wars
> - Technic
> - Town
> - Train
> - Western
>
> Please submit suggestions for additions to the Theme list. "SNOT" and
> "Micro" are technically not themes, and Mosaic/Sculpture also skirt
> this category; however, they are arguably important enough to merit
> their own Theme entry. As updated Themes become prevalent in LEGO
> Communities, they can be added to the LENNI namespace.
I guess we should have an "Other" theme, though ideally, it would allow
things like "Other - Micro", so that filters can use the value. Of
course, there's no way to enforce that everyone put the same "other - *"
entry, but I think that's the best we can hope for, until we release a
new version of the spec, with themes added to it.
Did that make any sense? It's still early in the morning...
Btw, is this optional? If so, it should say so - "one or more" implies
"at least one".
> ===============================================
> * AUDIENCE (one only per item/entry)
> - FOL
> - AFOL
> - KFOL
> - NYFOL (Not Yet Fan of LEGO) - optimistic, aren't I?
>
> The effectiveness of establishing ranges or more granular categories
> for Audience is questionable at this time. The above four top-level
> categories should adequately cover the majority of age-related
> filtering needs, while remaining simple enough to ensure adoption
> among content providers.
Are we going to give guidelines what's what? Also, I think the NYFOL
might be misplaced, if the main reason for this tag is "age related
filtering". Unless, of course, you want to make it NYKFOL, NYAFOL,
NYFOL... :)
> ===============================================
> * CALENDAR (One only per item/entry)
> Attributes
> - Startdate
> - Enddate
>
> One of the most important additions IMO, and one which may garner the
> attention of the world outside LEGO enthusiasts. A successful
> implementation of the Calendar extension has massive potential to
> revolutionize distributed content publishing (he said modestly).
>
> See samples below for Calendar implementation, as the attributes are different
> than other elements.
>
> ===============================================
> * GEOGRAPHY (One only)
> - TBD
>
> This is a very handy concept that requires more investigation. If
> used, the list of geographies should be from an existing W3C standard,
> should one exist with enough granularity to be useful.
Are we sure we want to limit it to one only? That pushes the burden
onto the filters... For instance, say there's an event in Boston. The
GEOGRAPHY tag would say something like "US-MA-Boston", let's assume.
That makes it easy for filters who care about US only events (US-*), MA
only events (US-MA-*), or events in Boston. But what about our remote
NELUGgers, who live in NH? Now, their filter will look something like
"US-(MA|NH)-*"... And the poor WAMALUGgers would have something like
"US-(DC|VA|MD)-*". Starts to get messy.
Of course, if we push it to the publishers, the same problem exists,
except now the work is done only once (the publisher needs to figure out
the areas that would care), and not on each subscriber's end.
Perhaps a solution would be to have a system that can tell you how far
an event is from you. If the GEOGRAPHY was just a lat/long, I could
easily subscribe to events that are within 50 miles of my home, etc.
> IMPLEMENTATION:
>
> Regardless of whether RSS or Atom specs are used, the implementation
> should always be pretty much the same. Below are two samples - note
> that the use of the namespace declaration is for example purposes
> only, and may not be well-formed XML.
Can we pick a different tag for LENNI? Even 'lenni' would be better, I
don't think I saw other namespaces tagged with caps?
...
> I welcome comments on this proposal, and whether you feel it merits
> implementation in both RSS and Atom or not. Personally, after
> reviewing the side-by-side samples, I am thinking it might be most
> feasible to simply say LENNI can be implemented on both RSS v2.0 and
> Atom style XML feeds. Software developers can then decide which they
> choose to support - or both, which would be the best of both worlds.
Yah, maybe both would be easiest on our end - punt the decision to the
developers. It does make the spec more complex, especially in future
versions, when the "staleness" of RSS might get in our way.
But if it's either do both, or do just RSS, I'll take both :)
On Tue, Aug 31, 2004 at 06:31:06AM +0000, Tim Courtney wrote:
> CAD -- can't believe you missed that one. :P
Not sure - is CAD a theme? It's more of a general umbrella of
activities. I mean, is "Inventory" a theme? I don't think so?
Perhaps we need to separate the two - have "Theme", which is a selection
from a predetermined list, and make use of the "Category" for more
general things, like "CAD", "Publishing", etc.
On Tue, Aug 31, 2004 at 11:01:44AM +0000, Larry Pieniazek wrote:
> > "SNOT" and "Micro" are technically not themes, and Mosaic/Sculpture
> > also skirt this category; however, they are arguably important
> > enough to merit their own Theme entry. As updated Themes become
> > prevalent in LEGO Communities, they can be added to the LENNI
> > namespace.
>
> I wonder if there ought to be a way to denote that a theme is fan
> created? Ala PCS or Sea Monkeys? Also, is there merit in allowing
> hierarchy (Space/PCS or Castle/Forestmen for example)?
>
> That may be excessive complexity, not sure.
Especially if the theme remains a selection from a "fixed list". A punt
would be to say "put PCS in the keywords", but that's really not a good
solution.
--
Dan Boger
dan@peeron.com
|
|
Message has 1 Reply:
Message is in Reply To:
12 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
