[Esip-discovery] Datacasting custom elements proposal

[Bob Deen]

>> 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.
>
> 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."  ;-)

But this is a side point, it's still a schema regardless of where you 
put it.

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

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


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

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

-Bob