[Esip-discovery] Datacasting custom elements proposal

Thu Mar 24 23:15:47 EDT 2011

On Mar 24, 2011, at 7:05 PM, Bob Deen wrote:

> 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.

We have a schema that does something similar by defining an element that can contain arbitrary XML and allowing it (almost) anywhere. The documents still validate but ignore the extra XML. Our schema is available from our trac site (http://scm.opendap.org/trac/browser/trunk/xml/dap/dap3.2.xsd) and xml.opendap.org, but our Trac/SVN site has more interesting stuff since there are several schema in the .../xml/dap directory. Regardless, look at the way the element OtherXML (yeah, creative name, I know ;-) is defined. In subsequent schemas we changed the name to AnyXML, but we haven't actually _used_ those schemas...

James

> 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
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 
> 
> _______________________________________________
> Esip-discovery mailing list
> Esip-discovery at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-discovery

--
James Gallagher
jgallagher at opendap.org
406.723.8663