| |
Next techie question for LENNI… including semi-dynamic options for filters.
OK, now that I’ve gotten a pretty good idea of what to do with the LENNI spec
(which should have a v0.2 draft this weekend), the one big question that is
still bugging me is how to deal with content filters. Note: for this discussion,
I’m calling “theme” = “interest” since it appears to be a wider filter at this
point. See this thread about themes.
For the Audience one, it’s pretty simple to say in the spec it’s
AFOL/KFOL/FOL/NYFOL or something like that. But for a category list that’s
probably (make that definitely) going to need to be updated, how to deal with
that? You don’t want to hard-code it into the actual application itself, since
that way lies madness. Can you imagine a twice-yearly “Theme” update and making
software developers update their products just for that?
I’d be more unpopular than a Bionicle fan at a Train club meeting. No wait, that
really happened…
So there are several potential methods of describing how such a list could be
maintained and still retain usability and flexibility. Here are a couple, please
let me know if there’s anything obvious I’ve missed. Remember, this is based on
RSS 2 /Atom 0.3, so it has to work with those formats.
First possibility: XSD, XML Schema Definition. I believe RSS 2.0 supports XSD,
but I’m not absolutely sure. I know 0.92 doesn’t, and I’m staying as far away
from RDF-centric RSS 1.0 as possible. Also, I think Atom can be extended to use
XSD, but again, I’m not sure. Any clarification is helpful.
Like a DTD, an XSD can be an external document (hosted at the same place as the
namespace, most likely) and is a validating document. But it doesn’t use the
same syntax as DTDs do, which is nice since I’m too lazy (or busy) to learn them
right now.
This page shows how to
restrict a given value to a list of entries. For example, to define three car
models:
<xs:element name=”car”>
<xs:simpleType>
<xs:restriction base=”xs:string”>
<xs:enumeration value=”Audi”/>
<xs:enumeration value=”Golf”/>
<xs:enumeration value=”BMW”/>
</xs:restriction>
</xs:simpleType>
</xs:element>
So, for example, maybe we could have a schema doc with the following:
... lenni.xsd
<!-- ... -->
<xs:element name=”interest”>
<xs:simpleType>
<xs:restriction base=”xs:string”>
<xs:enumeration value=”Aquazone”/>
<xs:enumeration value=”Bionicle”/>
<xs:enumeration value=”CAD”/>
<xs:enumeration value=”Castle”/>
<xs:enumeration value=”Mecha”/>
<xs:enumeration value=”Mosaic”/>
<xs:enumeration value=”Pirate”/>
<xs:enumeration value=”Robotics”/>
<xs:enumeration value=”Space”/>
<xs:enumeration value=”Star Wars”/>
<xs:enumeration value=”Technic”/>
<xs:enumeration value=”Train”/>
</xs:restriction>
</xs:simpleType>
</xs:element>
(Note: I’m still picking up XSD syntax so the above might not be exactly
correct.)
...somefeed.xml
<?xml version=”1.0”?>
<rss version=”2.0” xmlns:lenni=”http://www.anagrafyxx.com/LENNI/”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”http://www.anagrafyxx.com/LENNI/lenni.xsd”>
<!-- ... -->
<item>
<title>This is my Sample</title>
<link>http://www.anagrafyxx.com/LENNI/sample.php</link>
<lenni:filter>News</lenni:filter>
<lenni:interest>Bionicle</lenni:interest>
<lenni:interest>SNOT</lenni:interest>
<lenni:audience>FOL</lenni:audience>
</item>
... and so on.
Now, this doesn’t actually physically restrict anybody from putting “Galidor” in
their feed, even if it isn’t in the xs:enumeration list. It just means that if
somebody tries to validate that feed, it would not validate. But maybe that’s
enough.
Another way of doing this is a “roll-your-own” method, since I haven’t found
anything else. It would make software development a bit easier, I think,
although I’m surprised that I couldn’t find anything like this after searching
for a couple of hours.
Here’s the idea: create a second standalone XML doc, not RSS, which is a
definition of the permissible values for the “interest” element. It could look
like standard XML:
... interestlist.xml
< ? xml version=”1.0”?>
<interest_def>
<interest_choice>Aquazone</interest_choice>
<interest_choice>Bionicle</interest_choice>
<interest_choice>CAD</interest_choice>
<interest_choice>Castle</interest_choice>
<interest_choice>Clikit</interest_choice>
<interest_choice>Dacta</interest_choice>
<interest_choice>Duplo</interest_choice>
<interest_choice>Harry Potter</interest_choice>
<interest_choice>Mecha</interest_choice>
<interest_choice>Micro</interest_choice>
<interest_choice>Model Team</interest_choice>
<interest_choice>Mosaic</interest_choice>
<interest_choice>Pirate</interest_choice>
<interest_choice>Robotics</interest_choice>
<interest_choice>Sculpture</interest_choice>
<interest_choice>SNOT</interest_choice>
<interest_choice>Space</interest_choice>
<interest_choice>Star Wars</interest_choice>
<interest_choice>Technic</interest_choice>
<interest_choice>Town</interest_choice>
<interest_choice>Train</interest_choice>
<interest_choice>Western</interest_choice>
</interest>
This would basically act as a plugin to software that would suck in the XML file
and use it for parsing. It’s really just metadata, but the nice thing is it
would remove hardcoding from software sources when interest lists were updated.
The bad thing, of course, is requiring an external function, relying on a file
that might or might not be available in the future. The whole thing about LENNI
as a “spec” is that it should not require external resources, so although this
would be way cool, it’s also sort of a compromise to the independence of the
project as a whole. Of course, software developers could just use this XML as a
reference source and have their own local copy, and check the list at regular
intervals for updates, which would be preferred. So maybe I’m just being uppity.
Now, those are just a couple of ways of dealing with creating a pulldown list.
The way I see it working is two ways: content generators (that write out the
XML) would have a <select> list presented, with the above listing (or some
variation thereof) as the choices. The select would be a multiple selection box,
like:
<select name=”interest” multiple=”yes” size=10>
<option>...</option>
</select>
For the content consumers, aka “aggregators”, there’d need to be something like
a preferences area where you can select which ones you’d want. I’d also
recommend software developers code in an update alert when the list is updated,
so people can re-examine their settings. It would also have Audience and
Geography in the prefs (as well as obviously in the XML generators).
I hope this makes sense, and that I’m not complicating it unnecessarily. Any
other potential solutions?
Thanks,
Kelly
|
|
Message has 1 Reply:
4 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
