[Esip-discovery] Datacasting custom elements proposal

[Bob Deen]

Hey...

Okay glad we're on the same page.  As a Datacasting co-I, I'm obviously 
more concerned with your context #2.  What is the relationship between 
these two contexts?  How does datacasting relate to ESIP Discovery Feeds?

Resetting the discussion a little... let's consider what happens if we 
put the m-a-m in the schema.

I'm far from an expert on schema (and I mean *far*), but it looks like 
if we wanted to describe additional m-a-m, say for example 
conforms-to-standard, the only option is to put it in an 
annotation/appInfo group.  So it might look something like this:

<xsd:element name="windSpeed" type="xsd:decimal">
   <xsd:annotation>
     <xsd:appInfo>
       <dc:conforms-to-standard>ISO-whatever</dc:conforms-to-standard>
     </xsd:appInfo>
   </xsd:annotation>
</xsd:element>

The important point here is that the standard we're conforming to is 
specified in the *schema* - i.e. it applies to all instances of this 
element being used, just like the name or data type - rather than 
something that's put in the actual XML document being described.

What confuses me about this is that it seems like the contents of 
appInfo are not defined - any well-formed XML is okay.  So can you 
impose a schema on the schema, that would define what the m-a-m items in 
appInfo are, so the schema itself could validate?  Or is appInfo simply 
not validateable?

Also, pardon my schema ignorance.  But if you have a well-defined 
schema, say for datacasting, can that be augmented via additional 
schemas (namespaces?) *without* changing the datacasting schema itself 
and still be validateable?  (which is really the same as the question 
above, about having a schema just for the additions to the schema's 
schema (did I really just write that sentence??))

In other words if I have a document like this:

<a:foo>test
   <a:date>today</a:date>
</a:foo>

which is described by a schema, is it possible to create a schema that 
defines an additional element, one which drops in to the middle of the 
above, *without* modifying the original schema?  When the original 
schema was not designed with such in mind?  e.g.

<a:foo>test
   <a:date>today</a:date>
   <b:time>now</b:time>
</a:foo>

Put another way, are schemas subclassable in an object-oriented sense? 
The goal is for the above to still be a valid a, with additions 
specified by b, without modifying or duplicating a's schema, yet still 
be fully validateable.

Thanks...

-Bob


On 3/23/11 1:44 AM, Mattmann, Chris A (388J) wrote:
> Hi Bob,
>
>> Sigh.  This is why I hate jumping in to an ongoing thread...
>
> No worries.
>
>>
>> So let's take a step back.  My understanding here is that we're trying
>> to collectively decide the best way to describe custom metadata elements
>> in a *casting feed.
>
> Well that's part of it. Moreover, this conversation is related to the development of a specification for an ESIP Discovery Feed:
>
> http://wiki.esipfed.org/index.php/Discovery_OpenSearch_Services
>
> Datacasting is one example that Sean McCleese put forward to think about in the context of this discussion.
>
>>
>> Assuming it is correct, then please allow me to reframe the question.
>> There are two separate but related topics:
>>
>> 1) How to represent the custom metadata itself.
>> 2) How to represent the description of the custom metadata
>> (metadata-about-metadata, or m-a-m).
>>
>> For topic 1, there are two methods that seem viable:
>>
>> 1a) Use the metadata keyword as the actual XML element (or possibly
>> attribute) name.
>> 1b) Use name=xxx value=yyy attributes.
>>
>> For topic 2, there are three potential locations for the m-a-m:
>>
>> 2a) In the XML schema.
>> 2b) In the channel portion of the feed.
>> 2c) In the item itself.
>
> To clarify, 2b/2c don't preclude the inclusion of XMLSchema since it may be inlined too.
>
>>
>> We can probably safely rule out 2c.  2a more or less requires 1a.
>>
>> Is that an accurate restatement of the topic?
>
> Yep and in 2 contexts:
>
> 1. in the context of the ESIP Discovery Feed work
> 2. in the context of the Datacasting project as an example of that.
>
> I think #1 is the more pertinent topic here. Some feel (e.g., based on Ruth's comments) that #2 must conform to #1.
>
> I'm less interested in mandating that then working on #1.
>
> As for #2, since Sean brought up the topic on this list, I thought I'd weigh in.
>
>>>
>>> That's not true. They expect changes all the time. New missions define new elements and extensions of the existing PDS data model.
>>
>> I meant that changes do not occur quickly or often.
>
> Gotcha.
>
>>   Of course each
>> mission can be different.  But within a mission, once the metadata is
>> defined, it pretty much does not change.  There may be updates or errata
>> from time to time, but it's not constantly in flux.  I claim that's not
>> the case with us; within one feed I would hope the metadata is augmented
>> often.
>
> Why is that? If datacasting expects to serve Earth science missions, and/or DAACs, etc., then I would say they are in a similar to boat as to PDS -- that is, once the metadata is defined it pretty much does not change. This has been my experience working with e.g., AIRS, MLS, MISR, and TES data, at the least.
>
> 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
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>