XML Schema for manifest.xml

[Stian Soiland-Reyes]

Hi,

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]

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,
Jonathan

[Nicolas Le Novere]

Hello,

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]

Here's my first draft :

https://github.com/stain/ro-combine-archive/blob/master/src/main/xsd/combine.xsd


Feel free to put in pull requests!

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

https://github.com/stain/ro-combine-archive/blob/master/src/main/xsd/combine-example.xml



Assumptions:


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
xsd:string.



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" />
</xsd:unique>

(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]

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
Frank