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

Hi Stian,

I had in mind that we wanted to allow xml blobs compatible with
with a legacy schema in a provenance trace.  In such a case,
we don't have the opportunity to redefine the legacy schema, or make an 
element
be substitutable for an abstract element.

I appreciate that xsd:any does not offer the level of type checking your 
solution
permits, but xsd:any allows for easier integration with legacy schemas.

I don't see the prov xml schema  as the way to fully validate a 
provenance trace,
but only a way of checking the prov core and the prov extensions defined 
by the WG.

Luc


On 02/05/2013 02:40 PM, Stian Soiland-Reyes wrote:
> 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.
>
>

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm

Received on Tuesday, 5 February 2013 16:11:43 UTC