XML Schema for manifest.xml

Skip to first unread message

Stian Soiland-Reyes

Jun 13, 2014, 9:51:06 AM6/13/14
to combine...@googlegroups.com

Is there an XML Schema (or RelaxNG) for the COMBINE manifest.xml, now
that draft1 is out?

If not - would anyone be able to help me review one I cook up..? :)

Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718

Jonathan Cooper

Jun 15, 2014, 2:46:17 PM6/15/14
to combine...@googlegroups.com
Hi Stian,
I'm not aware of one, but I'd be happy to review one. I might even
manage to knock one up this week - I'm lecturing on XML technologies all
week, so will be in the right head space, if I get time!
Best wishes,

Nicolas Le Novere

Jun 15, 2014, 5:07:15 PM6/15/14
to combine...@googlegroups.com

Just a word of caution that draft1 does not represent the latest version anymore. We're working on a release candidate based on the clarifications discussed at HARMONY 2014. No huge changes affecting a schema though.
Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT
Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere
Skype:n.lenovere, n.len...@gmail.com, ORCID: 0000-0002-6309-7327
http://lenoverelab.org/, http://lenoverelab.org/perso/lenov/

Stian Soiland-Reyes

Jun 15, 2014, 6:41:26 PM6/15/14
to Jonathan Cooper, combine...@googlegroups.com
Here's my first draft :


Feel free to put in pull requests!

It validates the example from page 8 in the spec (using Eclipse's XML editor):



Attributes are unqualified (otherwise the empty namespace examples
would not work).

I did not set 'location' or 'format' to xsd:anyURI (which I feel would
be more appropriate), because the current spec says they are

It is mainly trying to build a structural schema for generating Jaxb
bindings, not so much focusing on validation.

I found it much much harder to build a validation-capable restricted
schema that follows the specification, say for restrictions on only a
single master attribute or for ./manifest.xml to be present. (And
presumably for that manifest.xml to not be a master?). One of the
reasons for this is that they are all using the same 'content'
element, and they can (presumably) be in any order. XSD is quite
formal, but expressing such things becomes quite tricky while at the
same time complying with 'unique particle constraints'.

It might be possible in a less obtrusive way using something like:

<xsd:unique name="locationUniq">
<xsd:selector xpath="./content" />
<xsd:field xpath="@location" />

(Note: I did not add this - the spec does not require 'location' to be unique)
> --
> You received this message because you are subscribed to the Google Groups
> "COMBINE archive" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to combine-archi...@googlegroups.com.
> Visit this group at http://groups.google.com/group/combine-archive.
> For more options, visit https://groups.google.com/d/optout.

Frank Bergmann

Jun 16, 2014, 2:12:14 AM6/16/14
to Stian Soiland-Reyes, Jonathan Cooper, combine...@googlegroups.com
I think the schema looks fine as it is. Indeed it won’t help much for validation as the devil is in the details (ensuring that the format is indeed a identifiers.org url or an existing mime type, or ensuring that a file specified in the location attribute exists in the archive) and that certainly goes beyond XSD. So I think what you have is fine, the rest would have to be done from a software implementation.

All the best
Reply all
Reply to author
0 new messages