[Esip-discovery] Datacasting custom elements proposal

Tue Mar 15 01:25:56 EDT 2011

Hi Sean,

> We used ROME for our implementation of our Datacasting client as well, which is how we're handling the custom elements at this point. 

Gotcha, thanks.

> 
> We definitely could namespace all the tags (datacasting:maxWindSpeed, etc), howver in some cases we may want "reserved" namespace'd tags (i.e. datacasting:guid or datacasting:datacenter, etc) and we would have to carefully deal with collision situations there, whereas using attributes completely eliminates that potential pitfall.

I'm not seeing this as a problem? So long as you namespace the tags, it wouldn't matter if you had datacasting:guid, as well as chris:guid, so long as xmlns:datacasting, and xmlns:chris were defined, no? That's the whole point of XML namespacing and schema, to tackle the namespace issue.

Attributes may obviate the need to deal with xmlns and Schema, but it adds another element to e.g., validation (can't use schema).

That said, I say this being a guy that uses attributes a ton in a lot of the XML I write and standards that I participate in :)

> We figured that the "custom element" concept is a tag-level concept whereas the name/value/etc is more of a descriptor for that type, similar to the "link" tag in Atom.

Cool. OK.

> 
> In regards to the specification question: You might be right -- that may not be an actual requirement of the specification. I may have misspoken on that. Every RSS/Atom reader I've used, though, as a best practice does ignore tags that are unrecognized. I guess that's what I was trying to say. Sorry for the mis-application of specifications!

No worries! I'm not an expert for sure, and was more trying to figure out the design choices and rationale behind them. 

Thanks for taking the time to answer my questions!

Cheers,
Chris

> 
> -Sean
> 
> ________________________________________
> From: Mattmann, Chris A (388J)
> Sent: Monday, March 14, 2011 7:03 PM
> To: Mccleese, Sean W (388A)
> Cc: esip-discovery at lists.esipfed.org
> Subject: Re: [Esip-discovery] Datacasting custom elements proposal
> 
> Hey Sean,
> 
>> 
>> Great question!
> 
> Thanks!
> 
>> 
>> The reason we went with the element name in the tag attributes instead of the tag name itself is that a lot of RSS/Atom parsers will look for "understood" tags by their tag name and, in finding one that's unrecognized, will simply move on to the next tag.
> 
> Can you name a few examples? I'd be interested in trying some out. I'm most familiar with the Java ROME API, but also have used commons-feedparser in the past (no longer maintained, but was pretty robust back when I wrote an RSS parser for Nutch in 2005).
> 
>> We didn't want the "datacasting" namespace to, as a default action, encompass all possible tag names (with possible conflicts, etc, arising from that).
> 
> Couldn't you just namespace the other tags? In other words, it would be perfectly acceptable to have:
> 
> <?xml version="1.0"
>  xmlns:dc="...dublin core uri..."
>  xmlns:datacasting="...data casting uri..."
> ?>
> 
> <item>
>  <dc:Title>My FOO RSS Item</dc:Title>
>  <datacasting:maxWinSpeed>81.2</datacasting:maxWinSpeed>
>  <foo:barElem xmlns:foo="blah blah uri">Some FOO value</foo:bar>
> 
> ..
> </item>
> 
> Right?
> 
>> 
>> By putting it in the attributes for the tag itself, we can override the "ignore if unrecognized" requirement for the RSS spec, which is where the channel-level definitions come into play. That also helps with the datatype / units declarations as well.
> 
> What version of the RSS spec has this? I'm familiar with 2.0, is that the version you're talking about?
> 
> Cheers,
> Chris
> 
>> 
>> 
>> On Mar 14, 2011, at 6:10 PM, "Mattmann, Chris A (388J)" <chris.a.mattmann at jpl.nasa.gov> wrote:
>> 
>>> Hi Sean,
>>> 
>>> Quick question:
>>> 
>>> Why not just declare:
>>> 
>>> <item>...
>>> <datacasting:maxWinSpeed>81.2</datacasting:maxWinSpeed>
>>> </item>
>>> 
>>> Cheers,
>>> Chris
>>> 
>>> On Mar 14, 2011, at 2:19 PM, Mccleese, Sean W (388A) wrote:
>>> 
>>>> As part of Andrew Bingham’s Datacasting team, I would like to put forth a proposal for DCP-2 (or beyond) to add support for custom elements in Datacasting (or *casting) RSS & Atom feeds.
>>>> 
>>>> The purpose of “custom elements” to enable data providers to define and use domain-specific RSS/Atom elements from within the feed itself without foreknowledge on the part of the user or RSS/Atom viewer. This would enable, for example, a data provider of Datacasting RSS feeds tracking hurricanes to define “Max Wind Speed” as a valid RSS/Atom item element and then use that element within the feed. This would be accomplished through a two-step process: channel-level definitions and item-level use.
>>>> 
>>>> A channel level definition would define the name of the element, its core data type and then units the element represents. Ex:
>>>> <datacasting:customEltDef name="maxWindSpeed" type="float" units="mph" />
>>>> 
>>>> This would inform the feed reader that the item “maxWindSpeed” is present within the feed with a floating point number data type and that the physical representation of the data is in MPH. Then, in order for this data type to appear within the feed’s item-level information, the following example is illustrative:
>>>> 
>>>> (for RSS):
>>>> <item> ….
>>>> <datacasting:customElement name="maxWindSpeed" value="81.2"/>
>>>> </item>
>>>> 
>>>> (for Atom):
>>>> <entry>
>>>> …
>>>> <datacasting:customElement name="maxWindSpeed" value="81.2"/>
>>>> </entry>
>>>> 
>>>> Thus, when viewing the item/entry in the appropriate feed reader, the “maxWindSpeed” element would be displayed along with all the other relevant metadata (e.g. description, author, etc).
>>>> 
>>>> I’ll add this to the Discovery Change Proposals page, but I wanted to make sure to inform the list about this proposed idea. If you’re interested in seeing a working representation of this in action, check out the GHRSST AMSR-E DatacastingRSS feed (http://ghrsst.jpl.nasa.gov/datacasting/AMSRE-L2P-gen.xml) which can be read with the Datacasting Feed Reader (http://datacasting.jpl.nasa.gov)
>>>> 
>>>> Thanks,
>>>> -Sean McClese
>>>> _______________________________________________
>>>> Esip-discovery mailing list
>>>> Esip-discovery at lists.esipfed.org
>>>> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery
>>> 
>>> 
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> Chris Mattmann, Ph.D.
>>> Senior Computer Scientist
>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>> Office: 171-266B, Mailstop: 171-246
>>> Email: chris.a.mattmann at nasa.gov
>>> WWW:   http://sunset.usc.edu/~mattmann/
>>> Phone: +1 (818) 354-8810
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> Adjunct Assistant Professor, Computer Science Department
>>> University of Southern California, Los Angeles, CA 90089 USA
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> 
> 
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann at nasa.gov
> WWW:   http://sunset.usc.edu/~mattmann/
> Phone: +1 (818) 354-8810
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann at nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
Phone: +1 (818) 354-8810
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++