[Esip-discovery] Datacasting custom elements proposal

Thu Mar 31 01:36:09 EDT 2011

On Mar 30, 2011, at 10:53 PM, Mattmann, Chris A (388J) wrote:

> Hi Bob,
> 
>>> Yep that's one way to do it. You could also put the above inline in the XML document itself. Check out that link I sent you on inlining schema in XML document instances:
>>> 
>>> http://msdn.microsoft.com/en-us/library/aa302288.aspx
>> 
>> I saw that before but tuned out as soon as I saw "Few other XML Schema 
>> implementations besides those by Microsoft actually do support inline 
>> schemas."  ;-)
> 
> :) I hear ya.
> 
>>> 
>>> You could also use e.g., an xsd:annotation too. But you'd also reference the dc: namespace in your XML schema which would reference back to the definition for conforms-to-standard.
>> 
>> xsd:appInfo has to go inside xsd:annotation as far as I can tell.
>> 
>> How do you go about telling the validator (validating the schema itself) 
>> that e.g. dc:conforms-to-standard can appear only in the xsd:appInfo 
>> element and not somewhere else?  Something has to glue the two 
>> namespaces together.  That's what I'm not getting.
> 
> OK I just CC'ed Paul and gave up on getting him to join the list. Hey Paul can you chime in on the above? :)
> 
>> 
>>>> 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??))
>>> 
>>> LOL. I think James G's answer is what I would say too -- it's possible to do, especially with inline schemas, and with the ability to override definitions.
>> 
>> My understanding of James' answer was that it was a way to specify that 
>> arbitrary XML could go in the document itself.  I'm trying to add things 
>> to the schema language here, to extend the actual schema document.
>> 
>> Also, maybe I should qualify "validateable" by saying that I mean not 
>> just that it's well-formed XML but that the contents can be checked.  I 
>> mean, xsd:appInfo allows arbitrary XML, and by that token any schema 
>> using it that is well formed could be valididated, technically.  But 
>> that's not a real validation.  A true validation ensures that the 
>> document follows the rules... in this case, that the schema extensions 
>> in appInfo follow the specifications we set up.  If someone misspells 
>> it, e.g. "dc:conforms-2-standard" then that should be flagged by a 
>> validator.
> 
> James, is that your take?

In our code, we did not extend the schema language. I would be concerned that might be of limited use only because there would be no schema processors (aside from those you wrote) that would understand the extensions. It seems to me that the real benefit to XML is the common base of processing tools - I find the format/notation has little intrinsic benefit (although I realize that's an opinion and maybe far from universal ;-).

To me the whole idea of including arbitrary XML within a document with an otherwise known structure implies that the 'included' XML is not validated (but should be well-formed). However, we have found that there are often important semantic ideas that cannot be expressed in schema, which makes sense given its nature. In those cases we enforce 'rules' in code that consumes the parsed/validated XML. Certainly, you could do that with the 'arbitrary' XML. 

James
> 
>> 
>> 
>>>> 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.
>>> 
>>> Yep, they are able to do that. The guru I know for XML schemas is Paul Ramirez on the PDS Engineering Node. He's been doing most of the design implementation of stuff like this at JPL. I've been trying to get him to join the discussion...if anyone else knows Paul, help me encourage him :)
>> 
>> Can you find an example?
> 
> I'll defer to Paul on this.
> 
>> 
>> What I'm trying to do here is to poke at the schema definition to see if 
>> it can actually accommodate the metadata descriptions (m-a-m) we're 
>> envisioning here.  If not, then we can discard schemas as an option.  If 
>> it's possible but difficult, that's good to know.  It's also good to 
>> know if it's easy.
>> 
>> So what I'm getting at is twofold:
>> 
>> 1) can the schema language support additional m-a-m items (like 
>> conforms-to-standard) in the schema itself that can themselves be 
>> validated?  So that we can ensure the schema itself is valid?  (this 
>> goes to the schema that describes the schema.)
>> 
>> 2) can a data provider extend the datacasting (e.g.) schema to add 
>> his/her own custom metadata elements, without having to redefine the 
>> base schema?  i.e. as an augmentation or "subclass"?
>> 
>> If either answer is no, then I don't think the schema language will work 
>> for this application.  If both answers are yes, then examples would be 
>> useful to help us decide if it's really the right way to go.
>> 
>> I'm all for standards here.  Even though I have some vested interest in 
>> the datacasting model, if using the schema language really is the 
>> "proper" thing to do, then we should do it.  But we have to ensure that 
>> it will actually work, and truly is the "proper" thing.
>> 
>> Thanks...
> 
> Gotcha, we'll flush this out...
> 
> 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