W3C home > Mailing lists > Public > public-prov-wg@w3.org > January 2013

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

From: Stephan Zednik <zednis@rpi.edu>
Date: Tue, 29 Jan 2013 09:49:14 -0700
Cc: public-prov-wg@w3.org
Message-Id: <BA43168D-A82A-4DCD-B826-64877F792E5B@rpi.edu>
To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>

On Jan 29, 2013, at 7:12 AM, Luc Moreau <L.Moreau@ecs.soton.ac.uk> wrote:

> Hi Stephan,
> 
> I have a couple of questions.
> 
> If a developer wants to validate a prov xml document, with say dictionary, s/he will have to validate
> the document against extensions/prov-dictionary.xsd.
> 
> If a developer wants to validate a prov xml document, with links only, s/he will have to validate
> the document against extensions/prov-links.xsd
> 
> How would they validate a document with both links and dictionary?

They should validate against the standard prov.xsd schema which includes core, links, and dictionary.

<?xml version="1.0" encoding="utf-8"?>
<xs:schema targetNamespace="http://www.w3.org/ns/prov#"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:prov="http://www.w3.org/ns/prov#"
           elementFormDefault="qualified"
           attributeFormDefault="unqualified">

	<xs:include schemaLocation="prov-core.xsd"/>
	<xs:include schemaLocation="extensions/prov-dictionary.xsd"/>
	<xs:include schemaLocation="extensions/prov-links.xsd"/>
	
</xs:schema>

If there were other extensions defined in prov.xsd that the developer did NOT want to validate against then they could create their own local prov.xsd and include only the schemas they wish to validate against by way of the xs:include element.

> 
> Why don't we include all schemas in a single prov-xml.xsd file?  What's the downside with this approach?

The current prov.xsd schema is effectively this, but using imports and keeping modularity to the schema design.  If he have to change something in prov-core, we only have to change it once.

--Stephan

> 
> Thanks,
> Luc
> 
> On 23/01/2013 20:20, Stephan Zednik wrote:
>> 
>> I have committed a refactoring of the prov-xml schemas following the "substitution groups and abstract elements" pattern described by Stian in http://www.w3.org/2011/prov/wiki/ProvXMLNamespaces#Substitution_groups_and_abstract_elements
>> 
>> All schemas utilize the http://www.w3.org/ns/prov# target namespace.
>> 
>> I ask the group to please review the XML Namespace wiki page Stian created (link above) and our implementation of the "substitution groups and abstract elements" pattern.
>> 
>> changeset:
>> https://dvcs.w3.org/hg/prov/rev/ddc3e7cd2e94
>> 
>> The dependency hierarchy of the PROV-XML generated schemas is now:
>> 
>> prov.xsd
>> - prov-core.xsd
>> - extensions/prov-dictionary.xsd
>> -- prov-core.xsd
>> - extensions/prov-links.xsd
>> -- prov-core.xsd
>> 
>> note - prov.xsd does not technically need to include prov-core.xsd since both of the extensions already include it, but I added the include so the existence of prov-core.xsd is clear in prov.xsd.
>> 
>> The content of the extension schemas should not be considered final.  I invite members of the links and dictionary note to review the extension schemas and provide feedback.
>> 
>> All current XML serialization examples in eg-40 validate successfully with the refactored schema layout.  The PROV-XML group will be adding additional tests today for the extensions.
>> 
>> --Stephan
>> 
>> On Jan 17, 2013, at 10:12 AM, Stephan Zednik <zednis@rpi.edu> wrote:
>> 
>>> Hi Stian,
>>> 
>>> The PROV-XML group will look into a solution that follows this pattern.
>>> 
>>> --Stephan
>>> 
>>> On Dec 6, 2012, at 9:54 AM, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk> wrote:
>>> 
>>>> I've added some code example of my proposed solution at
>>>> 
>>>> http://dvcs.w3.org/hg/prov/file/6113b10ac714/xml/experimental/extensions
>>>> 
>>>> See description of this folder here:
>>>> 
>>>> http://www.w3.org/2011/prov/wiki/ProvXMLNamespaces#Experimental_example
>>>> 
>>>> On Thu, Dec 6, 2012 at 4:20 PM, Stian Soiland-Reyes
>>>> <soiland-reyes@cs.manchester.ac.uk> wrote:
>>>>> I've tested and found it to be easy to do several schemas in the same
>>>>> namespace as long as they just <xsi:include> each-other.
>>>>> 
>>>>> 
>>>>> So you can have an hierarchy of imports like:
>>>>> 
>>>>> prov.xsd
>>>>> -- imports core.xsd
>>>>> -- imports collection.xsd
>>>>> ---- imports core.xsd
>>>>> -- imports links.xsd
>>>>> ---- imports core.xsd
>>>>> 
>>>>> and so the top-level prov.xsd simply includes 2-3 <xsd:imports> of the
>>>>> underlying components.
>>>>> 
>>>>> 
>>>>> As far as I could figure it out, it means in the extensions the
>>>>> easiest way to 'fit in' would be to use abstract elements and
>>>>> substitution groups.
>>>>> 
>>>>> See   http://www.w3.org/2011/prov/wiki/ProvXMLNamespaces for a
>>>>> discussion of the different alternatives.
>>>>> 
>>>>> I've also got some test-schemas with this working, but I have not
>>>>> committed them yet as they are on a different machine.
>>>>> 
>>>>> 
>>>>> On Fri, Nov 30, 2012 at 3:34 PM, Stian Soiland-Reyes
>>>>> <soiland-reyes@cs.manchester.ac.uk> wrote:
>>>>>> Tracker, this is PROV-ISSUE-608
>>>>>> 
>>>>>> On Fri, Nov 30, 2012 at 3:29 PM, Stian Soiland-Reyes
>>>>>> <soiland-reyes@cs.manchester.ac.uk> wrote:
>>>>>>> They are usually application/xml.
>>>>>>> 
>>>>>>> On Thu, Nov 29, 2012 at 6:22 PM, Timothy Lebo <lebot@rpi.edu> wrote:
>>>>>>>> prov-wg,
>>>>>>>> 
>>>>>>>> Is there a mime type for xml schema?
>>>>>>>> Or, should we just use "application/xml"?
>>>>>>>> 
>>>>>>>> I'd like to add it to http://www.w3.org/2011/prov/wiki/ProvNamespaceManagement#Intro
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Tim
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Nov 29, 2012, at 12:58 PM, Graham Klyne <GK@ninebynine.org> wrote:
>>>>>>>> 
>>>>>>>>> Following the teleconference, I did a little digging, and my understanding is that it *is* possible to have a schema for a common target namerspace build from a number of separate schema files:
>>>>>>>>> 
>>>>>>>>> http://www.w3.org/TR/xmlschema-1/#compound-schema
>>>>>>>>> 
>>>>>>>>> By my reading, what you *cannot* do is have a single schema composed from multiple "sub-schema" defining terms in different target namespaces.
>>>>>>>>> 
>>>>>>>>> #g
>>>>>>>>> --
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Stian Soiland-Reyes, myGrid team
>>>>>>> School of Computer Science
>>>>>>> The University of Manchester
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Stian Soiland-Reyes, myGrid team
>>>>>> School of Computer Science
>>>>>> The University of Manchester
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Stian Soiland-Reyes, myGrid team
>>>>> School of Computer Science
>>>>> The University of Manchester
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Stian Soiland-Reyes, myGrid team
>>>> School of Computer Science
>>>> The University of Manchester
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
> 
> -- 
> 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, 29 January 2013 16:49:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:28 UTC