Re: Multiple XML schema files for a common target namespace (PROV-ISSUE-608)

On Tue, Feb 5, 2013 at 2:18 PM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote:
>> No, also to give a defined place for third-party extensions to put
>> their thing. If I am doing stianprov.xsd - how should I do it
>> otherwise? Copy-paste everything from prov.xsd and redefine it?
> We had a xsd:any that catered for that.

This allows XML documents without a schema defined for
non-prov-namespaced elements to still be valid. We allow such elements
many places, particularly as attributes of a prov:entity etc.

It might still be the case that extensions want to make their own
schema and also define precisely where their new types/elements are to
be used - perhaps  to use JAXB to generate code stubs, or because they
want to give their schemas to others to say "Here's how you make
My-PROV-XML documents".  If anything can go anywhere, you don't really
have a schema, just lots of fragments that can be combined however you
like.


If they are to formally extend this without the substitution group, I
think they would have to do something like I had to do here to "lock
down" the xsd:any.

https://raw.github.com/myGrid/scufl2/master/scufl2-t2flow/src/main/resources/uk/org/taverna/scufl2/translator/t2flow/xsd/t2flow-extended.xsd

something like..

 <xsd:redefine schemaLocation="prov.xsd">
  <xsd:complexType name="Document">
   <xsd:complexContent>
    <xsd:restriction base="prov:Document">
     <xsd:sequence>
                                           <xsd:element name="myStuff">
                                        </xsd:sequence>
   </xsd:complexContent>
  </xsd:complexType>
 <xsd:redefine>

I am not sure why this would be considered nicer or cleaner than the
substitution group. This would also not work with multiple third-party
extensions as they would disagree about what prov:Document is.

Such a lock-down would be needed if the extension really wanted to
prevent 'unknown' any's to appear - but I think for most cases they
would rather just want to say where their extension can be used, just
like in Java you would implement an interface, and then know where you
can pass your implementation.



>> This would be a bigger maintenance problem (more chance of getting it
>> wrong somewhere), and would not work for third-party extensions.
> What do you mean? The prov namespace will be frozen at the end of
> the working group activity.  xsd:any allows for third party extensions.

We still have to get it right during our administrative work. The
copy-pasted bits from an updated prov-dictionary.xsd would have to be
updated and equal in prov.xsd etc.

A little script can simplify this, of course.


-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Tuesday, 5 February 2013 14:41:38 UTC