[Esip-discovery] Datacasting custom elements proposal

[Mattmann, Chris A (388J)]

Hi Hook,

Gotcha, thanks for the pointer to the list. I'll check it out!

One thing is that if the list of clients include our own dog food (i.e. things that this group is building), then I have to agree with Chris in that we are the ones that can help define whether collisions occur or not (pertaining to the upstream spec) so I don't think it's really a huge issue. OTOH, if we're targetting tools downstream of the spec that we don't control that's where things get fuzzy... 

Cheers,
Chris

On Mar 18, 2011, at 7:14 AM, Hua, Hook (388C) wrote:

> Hi Chris,
> 
> Regarding the feedreaders we are targeting, I'd say we have to look no further than our own listing of clients:
> http://wiki.esipfed.org/index.php/Discovery_Clients
> 
> In an ideal world, we would have a table setup with facets for each client (like a shoppers guide). One facet would show whether each client implementation conforms to namespaces (and therefore collisions).
> 
> --Hook
> 
> ________________________________________
> From: Mattmann, Chris A (388J)
> Sent: Friday, March 18, 2011 6:41 AM
> To: Hua, Hook (388C)
> Cc: Mccleese, Sean W (388A); esip-discovery at lists.esipfed.org
> Subject: Re: [Esip-discovery] Datacasting custom elements proposal
> 
> Hi Hook,
> 
> On Mar 17, 2011, at 11:34 PM, Hua, Hook (388C) wrote:
> 
>> Hi Sean and Chris,
>> 
>> (1) I recall we had a similar discussion back in the Federated OpenSearch Cluster about whether we should assume that the clients are namespace aware. There could be some readers that are badly written (e.g. not using formal XML parsers) and therefore not compliant. All we can do on the server side is to do the right thing and always use namespaces.
> 
> +1.
> 
>> (2) Sean, your points on custom tags could also be equally valid for OpenSearch and ServiceCasting responses as well. Your example custom tag for dataSource could also be a custom tag for the other Discovery responses.
>> 
>> So should we generalize your proposal across the other Discovery services too? If so, then we probably shouldn't use a "datacasting" namespace as in:
>> 
>> <datacasting:dataSource>foo</datacasting:dataSource>
>> 
>> But for the sake of making progress, I could see the need to concentrate on one service type at a time. But then again, there are overlaps.
> 
> I'd say it might be good to consider some following research questions and to actually generate some #s behind them before getting far down any path. I've heard a lot of concern regarding collision. Does anyone know:
> 
> 1. what the frequency % of collision is in at least some X use cases? IOW, how often does this happen? I have my own views on this BTW but I'd rather just see some real data points.
> 2. what are the top Y feed readers we're targeting? I would hope the answer is not Y = all of them. Downstream users and consumers can always think of ways to break "standards" and rather than design for those cases, I think resources and effort are best spent designing for the actual ones first (starting small then growing big).
> 
> Cheers,
> Chris
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++