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: Luc Moreau <l.moreau@ecs.soton.ac.uk>
Date: Tue, 29 Jan 2013 14:12:25 +0000
Message-ID: <EMEW3|dca11c602e16de0b9be41a2c297aff1bp0SECW08l.moreau|ecs.soton.ac.uk|5107D8C9.40907@ecs.soton.ac.uk>
To: public-prov-wg@w3.org
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?

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

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 
> <mailto: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 
>> <mailto: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 14:13:04 UTC

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