Declaration of omex and its version in the manifest file
34 views
Skip to first unread message
Nicolas Le Novere
Apr 16, 2014, 6:00:59 AM4/16/14
to combine...@googlegroups.com
Stuart Moodie sent me very useful comments on the specifications. I would like to open discussions on some of his suggestions. The first one deals with the way we declare the OMEX manifest.
Currently, we use:
<?xml version="1.0" encoding="utf-8"?>
<omexManifest xmlns="http://identifiers.org/combine.specifications/omex-manifest">
<content location="./manifest.xml"
format="http://identifiers.org/combine.specifications/omex-manifest"/>
<content location="./models/model.xml"
format="http://identifiers.org/combine.specifications/sbml"/>
<content location="./simulation.xml" master="true"
format="http://identifiers.org/combine.specifications/sedml"/>
<content location="./article.pdf"
format="application/pdf"/>
<content location="./metadata.rdf"
format="http://identifiers.org/combine.specifications/omex-metadata"/>
</omexManifest>
Problems:
1) There are no declaration of OMEX itself, that is the format of the archive, e.g with:
http://identifiers.org/combine.specifications/omex.version-X
2) There are somehow two declarations of the OMEX manifest format, one within the namespace declaration (xmlns) and one in the format attribute of the corresponding content element.
3) The file manifest.xml is declared as a content in itself. What is the use of that? We already opened the file, so we do not need to know where it is or what is its format. Plus, the file manifest.xml at the root of the archive is the only mandatory content of a COMBINE archive. If there is not such a file, the archive is invalid, one should not read it.
I propose to kill all birds in one shot by replacing the declaration of the manifest file, by a content element pointing to the archive itself:
<?xml version="1.0" encoding="utf-8"?>
<omexManifest xmlns="http://identifiers.org/combine.specifications/omex-manifest">
<content location="."
format="http://identifiers.org/combine.specifications/omex"/>
<content location="./models/model.xml"
format="http://identifiers.org/combine.specifications/sbml"/>
<content location="./simulation.xml" master="true"
format="http://identifiers.org/combine.specifications/sedml"/>
<content location="./article.pdf"
format="application/pdf"/>
<content location="./metadata.rdf"
format="http://identifiers.org/combine.specifications/omex-metadata"/>
</omexManifest>
We could keep the manifest declaration optional for backward compatibility, although it serves no purpose. Up to the developers to decide.
<?xml version="1.0" encoding="utf-8"?>
<omexManifest xmlns="http://identifiers.org/combine.specifications/omex-manifest">
<content location="."
format="http://identifiers.org/combine.specifications/omex"/>
<content location="./manifest.xml"
format="http://identifiers.org/combine.specifications/omex-manifest"/>
<content location="./models/model.xml"
format="http://identifiers.org/combine.specifications/sbml"/>
<content location="./simulation.xml" master="true"
format="http://identifiers.org/combine.specifications/sedml"/>
<content location="./article.pdf"
format="application/pdf"/>
<content location="./metadata.rdf"
format="http://identifiers.org/combine.specifications/omex-metadata"/>
</omexManifest>
Above, I did not use a versioned URI for the OMEX declaration since we do not have one yet. Stuart proposed that we add an explicit version in the declaration. For instance, the Open Document Format uses a URI to identify the manifest version and then an explicit version attribute to identify the archive version. This is necessary for ODF since the contents are identified with mime types, hence not versioned. Since our OMEX specification will be versioned, this would be somehow redundant.
<?xml version="1.0" encoding="utf-8"?>
<omexManifest xmlns="http://identifiers.org/combine.specifications/omex-manifest" version="1">
<content location="."
format="http://identifiers.org/combine.specifications/omex"/>
<content location="./manifest.xml"
format="http://identifiers.org/combine.specifications/omex-manifest"/>
<content location="./models/model.xml"
format="http://identifiers.org/combine.specifications/sbml"/>
<content location="./simulation.xml" master="true"
format="http://identifiers.org/combine.specifications/sedml"/>
<content location="./article.pdf"
format="application/pdf"/>
<content location="./metadata.rdf"
format="http://identifiers.org/combine.specifications/omex-metadata"/>
</omexManifest>
Note that in the example above, the "version" attribute refers to the OMEX version, not the OMEX manifest version. At the moment, they are linked. However, one can easily imagine that they are split in the future, the OMEX manifest format becoming independent, on part with the other content specifications.
What do-you guys think?
--
Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT
Tel: +441223496433 Mob:+447833147074 n.len...@gmail.com
orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/lenov/
Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/
Currently, we use:
<?xml version="1.0" encoding="utf-8"?>
<omexManifest xmlns="http://identifiers.org/combine.specifications/omex-manifest">
<content location="./manifest.xml"
format="http://identifiers.org/combine.specifications/omex-manifest"/>
<content location="./models/model.xml"
format="http://identifiers.org/combine.specifications/sbml"/>
<content location="./simulation.xml" master="true"
format="http://identifiers.org/combine.specifications/sedml"/>
<content location="./article.pdf"
format="application/pdf"/>
<content location="./metadata.rdf"
format="http://identifiers.org/combine.specifications/omex-metadata"/>
</omexManifest>
Problems:
1) There are no declaration of OMEX itself, that is the format of the archive, e.g with:
http://identifiers.org/combine.specifications/omex.version-X
2) There are somehow two declarations of the OMEX manifest format, one within the namespace declaration (xmlns) and one in the format attribute of the corresponding content element.
3) The file manifest.xml is declared as a content in itself. What is the use of that? We already opened the file, so we do not need to know where it is or what is its format. Plus, the file manifest.xml at the root of the archive is the only mandatory content of a COMBINE archive. If there is not such a file, the archive is invalid, one should not read it.
I propose to kill all birds in one shot by replacing the declaration of the manifest file, by a content element pointing to the archive itself:
<?xml version="1.0" encoding="utf-8"?>
<omexManifest xmlns="http://identifiers.org/combine.specifications/omex-manifest">
<content location="."
format="http://identifiers.org/combine.specifications/omex"/>
<content location="./models/model.xml"
format="http://identifiers.org/combine.specifications/sbml"/>
<content location="./simulation.xml" master="true"
format="http://identifiers.org/combine.specifications/sedml"/>
<content location="./article.pdf"
format="application/pdf"/>
<content location="./metadata.rdf"
format="http://identifiers.org/combine.specifications/omex-metadata"/>
</omexManifest>
We could keep the manifest declaration optional for backward compatibility, although it serves no purpose. Up to the developers to decide.
<?xml version="1.0" encoding="utf-8"?>
<omexManifest xmlns="http://identifiers.org/combine.specifications/omex-manifest">
<content location="."
format="http://identifiers.org/combine.specifications/omex"/>
<content location="./manifest.xml"
format="http://identifiers.org/combine.specifications/omex-manifest"/>
<content location="./models/model.xml"
format="http://identifiers.org/combine.specifications/sbml"/>
<content location="./simulation.xml" master="true"
format="http://identifiers.org/combine.specifications/sedml"/>
<content location="./article.pdf"
format="application/pdf"/>
<content location="./metadata.rdf"
format="http://identifiers.org/combine.specifications/omex-metadata"/>
</omexManifest>
Above, I did not use a versioned URI for the OMEX declaration since we do not have one yet. Stuart proposed that we add an explicit version in the declaration. For instance, the Open Document Format uses a URI to identify the manifest version and then an explicit version attribute to identify the archive version. This is necessary for ODF since the contents are identified with mime types, hence not versioned. Since our OMEX specification will be versioned, this would be somehow redundant.
<?xml version="1.0" encoding="utf-8"?>
<omexManifest xmlns="http://identifiers.org/combine.specifications/omex-manifest" version="1">
<content location="."
format="http://identifiers.org/combine.specifications/omex"/>
<content location="./manifest.xml"
format="http://identifiers.org/combine.specifications/omex-manifest"/>
<content location="./models/model.xml"
format="http://identifiers.org/combine.specifications/sbml"/>
<content location="./simulation.xml" master="true"
format="http://identifiers.org/combine.specifications/sedml"/>
<content location="./article.pdf"
format="application/pdf"/>
<content location="./metadata.rdf"
format="http://identifiers.org/combine.specifications/omex-metadata"/>
</omexManifest>
Note that in the example above, the "version" attribute refers to the OMEX version, not the OMEX manifest version. At the moment, they are linked. However, one can easily imagine that they are split in the future, the OMEX manifest format becoming independent, on part with the other content specifications.
What do-you guys think?
--
Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT
Tel: +441223496433 Mob:+447833147074 n.len...@gmail.com
orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/lenov/
Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/
Jonathan Cooper
Apr 17, 2014, 10:27:19 AM4/17/14
to combine...@googlegroups.com
Hi all,
I'm in agreement with most of Nicolas' suggestions, except for the
version attribute (see below). I'm ambivalent on whether the manifest
itself should be listed in the manifest; for completeness it makes sense
for every file to be listed, but I can see the argument for treating the
manifest specially.
On 16/04/2014 11:00, Nicolas Le Novere wrote:
> Above, I did not use a versioned URI for the OMEX declaration since we
> do not have one yet. Stuart proposed that we add an explicit version
> in the declaration. For instance, the Open Document Format uses a URI
> to identify the manifest version and then an explicit version
> attribute to identify the archive version. This is necessary for ODF
> since the contents are identified with mime types, hence not
> versioned. Since our OMEX specification will be versioned, this would
> be somehow redundant.
>
> <?xml version="1.0" encoding="utf-8"?>
> <omexManifest
> xmlns="http://identifiers.org/combine.specifications/omex-manifest"
> version="1">
> <content location="."
> format="http://identifiers.org/combine.specifications/omex"/>
>
should be on the content element, since the namespace on the
omexManifest element is referring to the manifest, and there's a high
likelihood of confusion. This has the downside that the version
attribute would only be allowed on the content element with
location='.'. However, if we're using versioned URIs, I don't think we
should have a version attribute at all - too easy to get inconsistency
if you have the same information recorded in 2 ways.
Best wishes,
Jonathan
I'm in agreement with most of Nicolas' suggestions, except for the
version attribute (see below). I'm ambivalent on whether the manifest
itself should be listed in the manifest; for completeness it makes sense
for every file to be listed, but I can see the argument for treating the
manifest specially.
On 16/04/2014 11:00, Nicolas Le Novere wrote:
> Above, I did not use a versioned URI for the OMEX declaration since we
> do not have one yet. Stuart proposed that we add an explicit version
> in the declaration. For instance, the Open Document Format uses a URI
> to identify the manifest version and then an explicit version
> attribute to identify the archive version. This is necessary for ODF
> since the contents are identified with mime types, hence not
> versioned. Since our OMEX specification will be versioned, this would
> be somehow redundant.
>
> <?xml version="1.0" encoding="utf-8"?>
> <omexManifest
> xmlns="http://identifiers.org/combine.specifications/omex-manifest"
> version="1">
> <content location="."
> format="http://identifiers.org/combine.specifications/omex"/>
>
> Note that in the example above, the "version" attribute refers to the
> OMEX version, not the OMEX manifest version. At the moment, they are
> linked. However, one can easily imagine that they are split in the
> future, the OMEX manifest format becoming independent, on part with
> the other content specifications.
If the version attribute refers to the OMEX version, then I think it
> OMEX version, not the OMEX manifest version. At the moment, they are
> linked. However, one can easily imagine that they are split in the
> future, the OMEX manifest format becoming independent, on part with
> the other content specifications.
should be on the content element, since the namespace on the
omexManifest element is referring to the manifest, and there's a high
likelihood of confusion. This has the downside that the version
attribute would only be allowed on the content element with
location='.'. However, if we're using versioned URIs, I don't think we
should have a version attribute at all - too easy to get inconsistency
if you have the same information recorded in 2 ways.
Best wishes,
Jonathan
David Nickerson
Apr 20, 2014, 3:56:42 AM4/20/14
to combine...@googlegroups.com
I agree with Nicolas' proposal to remove the content item from the
manifest file (keeping it for compatibility if need be).
I agree with Jonathan. Version information for all other content items
is handled by the format URI so it makes little sense to have a
special case for the archive format itself. Particularly putting the
version on the manifest element which is a different format than the
archive.
I'm pretty sure there was a big discussion on the use of '.' to
represent the archive itself back in Connecticut last year and it was
clear (in my memory at least) that there wasn't any agreement on what
'.' should refer to. If we want (need?) the ability to define the
version of the archive then we need to agree on how to address the
archive from the manifest file, and then its trivial to use a
versioned format URI to define the version. Or look into wrapping the
ZIP file in an XML wrapper which defines the OMEX element :) One
solution that avoids the '.' controversy could be something like:
<?xml version="1.0" encoding="utf-8"?>
<omexManifest xmlns="http://identifiers.org/combine.specifications/omex-manifest"
archiveFormat="http://identifiers.org/combine.specifications/omex">
metadata of the ZIP file itself?
Cheers,
David.
manifest file (keeping it for compatibility if need be).
is handled by the format URI so it makes little sense to have a
special case for the archive format itself. Particularly putting the
version on the manifest element which is a different format than the
archive.
I'm pretty sure there was a big discussion on the use of '.' to
represent the archive itself back in Connecticut last year and it was
clear (in my memory at least) that there wasn't any agreement on what
'.' should refer to. If we want (need?) the ability to define the
version of the archive then we need to agree on how to address the
archive from the manifest file, and then its trivial to use a
versioned format URI to define the version. Or look into wrapping the
ZIP file in an XML wrapper which defines the OMEX element :) One
solution that avoids the '.' controversy could be something like:
<?xml version="1.0" encoding="utf-8"?>
<omexManifest xmlns="http://identifiers.org/combine.specifications/omex-manifest"
<content location="./models/model.xml"
format="http://identifiers.org/combine.specifications/sbml"/>
<content location="./simulation.xml" master="true"
format="http://identifiers.org/combine.specifications/sedml"/>
<content location="./article.pdf"
format="application/pdf"/>
<content location="./metadata.rdf"
format="http://identifiers.org/combine.specifications/omex-metadata"/>
</omexManifest>
or perhaps the OMEX format information is something the belongs in the
format="http://identifiers.org/combine.specifications/sbml"/>
<content location="./simulation.xml" master="true"
format="http://identifiers.org/combine.specifications/sedml"/>
<content location="./article.pdf"
format="application/pdf"/>
<content location="./metadata.rdf"
format="http://identifiers.org/combine.specifications/omex-metadata"/>
</omexManifest>
metadata of the ZIP file itself?
Cheers,
David.
tomm...@auckland.ac.nz
Apr 24, 2014, 5:17:09 AM4/24/14
to combine...@googlegroups.com, n.len...@gmail.com
I strongly disagree with using "." alone as a self reference to the current manifest file, as this is a violation of standards established in RFC 1808 with regards to relative URIs.
According to the example shown, the '.' references the current _directory_ of the file, not the actual file itself. However in the abnormal example, the _empty_ reference will resolve to the current base URL, in our case it would be the actual self-reference path to the manifest file.
If the combine archive standard will keep a self-reference entry, please use the empty string to denote that so that the standard would have consistencies with other established standards.
Regards,
Tommy.
Nicolas Le Novere
Apr 24, 2014, 5:23:55 AM4/24/14
to combine...@googlegroups.com
Hi Tommy,
"." does not refer to the manifest file. "." refers to the archive itself. In the manifest file, the manifest is refered to as "./manifest.xml" (although the current idea is to make the declaration of manifest optional altogether)
Would "." be invalid for the archive?
A few other archives use "/". I am just afraid of problems when opening/merging archives.
On 24/04/14 10:17, tomm...@auckland.ac.nz wrote:
> I strongly disagree with using "." alone as a self reference to the current manifest file, as this is a violation of standards established in RFC 1808 with regards to relative URIs.
>
> https://tools.ietf.org/html/rfc1808#section-5
>
> According to the example shown, the '.' references the current _directory_ of the file, not the actual file itself. However in the abnormal example, the _empty_ reference will resolve to the current base URL, in our case it would be the actual self-reference path to the manifest file.
>
> If the combine archive standard will keep a self-reference entry, please use the empty string to denote that so that the standard would have consistencies with other established standards.
>
> Regards,
> Tommy.
>
> On Wednesday, 16 April 2014 11:00:59 UTC+1, Nicolas Le Novere wrote:
>
> Stuart Moodie sent me very useful comments on the specifications. I would like to open discussions on some of his suggestions. The first one deals with the way we declare the OMEX manifest.
>
> Currently, we use:
>
> <?xml version="1.0" encoding="utf-8"?>
> <omexManifest xmlns="http://identifiers.org/combine.specifications/omex-manifest <http://identifiers.org/combine.specifications/omex-manifest>">
> <content location="./manifest.xml"
> format="http://identifiers.org/combine.specifications/omex-manifest <http://identifiers.org/combine.specifications/omex-manifest>"/>
> <content location="./models/model.xml"
> format="http://identifiers.org/combine.specifications/sbml <http://identifiers.org/combine.specifications/sbml>"/>
> <content location="."
> format="http://identifiers.org/combine.specifications/omex <http://identifiers.org/combine.specifications/omex>"/>
> <content location="./models/model.xml"
> format="http://identifiers.org/combine.specifications/sbml <http://identifiers.org/combine.specifications/sbml>"/>
> <content location="."
> format="http://identifiers.org/combine.specifications/omex <http://identifiers.org/combine.specifications/omex>"/>
> <content location="./manifest.xml"
> format="http://identifiers.org/combine.specifications/omex-manifest <http://identifiers.org/combine.specifications/omex-manifest>"/>
> <content location="./models/model.xml"
> format="http://identifiers.org/combine.specifications/sbml <http://identifiers.org/combine.specifications/sbml>"/>
> <content location="."
> format="http://identifiers.org/combine.specifications/omex <http://identifiers.org/combine.specifications/omex>"/>
> <content location="./manifest.xml"
> format="http://identifiers.org/combine.specifications/omex-manifest <http://identifiers.org/combine.specifications/omex-manifest>"/>
> <content location="./models/model.xml"
> format="http://identifiers.org/combine.specifications/sbml <http://identifiers.org/combine.specifications/sbml>"/>
> orcid.org//0000-0002-6309-7327 <http://orcid.org//0000-0002-6309-7327> http://lenoverelab.org/perso/lenov/ <http://lenoverelab.org/perso/lenov/>
> --
> 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 <mailto: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.
"." does not refer to the manifest file. "." refers to the archive itself. In the manifest file, the manifest is refered to as "./manifest.xml" (although the current idea is to make the declaration of manifest optional altogether)
Would "." be invalid for the archive?
A few other archives use "/". I am just afraid of problems when opening/merging archives.
On 24/04/14 10:17, tomm...@auckland.ac.nz wrote:
> I strongly disagree with using "." alone as a self reference to the current manifest file, as this is a violation of standards established in RFC 1808 with regards to relative URIs.
>
> https://tools.ietf.org/html/rfc1808#section-5
>
> According to the example shown, the '.' references the current _directory_ of the file, not the actual file itself. However in the abnormal example, the _empty_ reference will resolve to the current base URL, in our case it would be the actual self-reference path to the manifest file.
>
> If the combine archive standard will keep a self-reference entry, please use the empty string to denote that so that the standard would have consistencies with other established standards.
>
> Regards,
> Tommy.
>
> On Wednesday, 16 April 2014 11:00:59 UTC+1, Nicolas Le Novere wrote:
>
> Stuart Moodie sent me very useful comments on the specifications. I would like to open discussions on some of his suggestions. The first one deals with the way we declare the OMEX manifest.
>
> Currently, we use:
>
> <?xml version="1.0" encoding="utf-8"?>
> <content location="./manifest.xml"
> format="http://identifiers.org/combine.specifications/omex-manifest <http://identifiers.org/combine.specifications/omex-manifest>"/>
> <content location="./models/model.xml"
> format="http://identifiers.org/combine.specifications/sbml <http://identifiers.org/combine.specifications/sbml>"/>
> <content location="./simulation.xml" master="true"
> format="http://identifiers.org/combine.specifications/sedml <http://identifiers.org/combine.specifications/sedml>"/>
> <content location="./article.pdf"
> format="application/pdf"/>
> <content location="./metadata.rdf"
> format="http://identifiers.org/combine.specifications/omex-metadata <http://identifiers.org/combine.specifications/omex-metadata>"/>
> format="application/pdf"/>
> <content location="./metadata.rdf"
> </omexManifest>
>
>
> Problems:
>
> 1) There are no declaration of OMEX itself, that is the format of the archive, e.g with:
> http://identifiers.org/combine.specifications/omex.version-X <http://identifiers.org/combine.specifications/omex.version-X>
>
>
> Problems:
>
> 1) There are no declaration of OMEX itself, that is the format of the archive, e.g with:
>
> 2) There are somehow two declarations of the OMEX manifest format, one within the namespace declaration (xmlns) and one in the format attribute of the corresponding content element.
>
> 3) The file manifest.xml is declared as a content in itself. What is the use of that? We already opened the file, so we do not need to know where it is or what is its format. Plus, the file manifest.xml at the root of the archive is the only mandatory content of a COMBINE archive. If there is not such a file, the archive is invalid, one should not read it.
>
> I propose to kill all birds in one shot by replacing the declaration of the manifest file, by a content element pointing to the archive itself:
>
> <?xml version="1.0" encoding="utf-8"?>
> <omexManifest xmlns="http://identifiers.org/combine.specifications/omex-manifest <http://identifiers.org/combine.specifications/omex-manifest>">
> 2) There are somehow two declarations of the OMEX manifest format, one within the namespace declaration (xmlns) and one in the format attribute of the corresponding content element.
>
> 3) The file manifest.xml is declared as a content in itself. What is the use of that? We already opened the file, so we do not need to know where it is or what is its format. Plus, the file manifest.xml at the root of the archive is the only mandatory content of a COMBINE archive. If there is not such a file, the archive is invalid, one should not read it.
>
> I propose to kill all birds in one shot by replacing the declaration of the manifest file, by a content element pointing to the archive itself:
>
> <?xml version="1.0" encoding="utf-8"?>
> <content location="."
> format="http://identifiers.org/combine.specifications/omex <http://identifiers.org/combine.specifications/omex>"/>
> <content location="./models/model.xml"
> format="http://identifiers.org/combine.specifications/sbml <http://identifiers.org/combine.specifications/sbml>"/>
> <content location="./simulation.xml" master="true"
> format="http://identifiers.org/combine.specifications/sedml <http://identifiers.org/combine.specifications/sedml>"/>
> <content location="./article.pdf"
> format="application/pdf"/>
> <content location="./metadata.rdf"
> format="http://identifiers.org/combine.specifications/omex-metadata <http://identifiers.org/combine.specifications/omex-metadata>"/>
> format="application/pdf"/>
> <content location="./metadata.rdf"
> </omexManifest>
>
> We could keep the manifest declaration optional for backward compatibility, although it serves no purpose. Up to the developers to decide.
>
> <?xml version="1.0" encoding="utf-8"?>
> <omexManifest xmlns="http://identifiers.org/combine.specifications/omex-manifest <http://identifiers.org/combine.specifications/omex-manifest>">
>
> We could keep the manifest declaration optional for backward compatibility, although it serves no purpose. Up to the developers to decide.
>
> <?xml version="1.0" encoding="utf-8"?>
> <content location="."
> format="http://identifiers.org/combine.specifications/omex <http://identifiers.org/combine.specifications/omex>"/>
> <content location="./manifest.xml"
> format="http://identifiers.org/combine.specifications/omex-manifest <http://identifiers.org/combine.specifications/omex-manifest>"/>
> <content location="./models/model.xml"
> format="http://identifiers.org/combine.specifications/sbml <http://identifiers.org/combine.specifications/sbml>"/>
> <content location="./simulation.xml" master="true"
> format="http://identifiers.org/combine.specifications/sedml <http://identifiers.org/combine.specifications/sedml>"/>
> <content location="./article.pdf"
> format="application/pdf"/>
> <content location="./metadata.rdf"
> format="http://identifiers.org/combine.specifications/omex-metadata <http://identifiers.org/combine.specifications/omex-metadata>"/>
> format="application/pdf"/>
> <content location="./metadata.rdf"
> </omexManifest>
>
> Above, I did not use a versioned URI for the OMEX declaration since we do not have one yet. Stuart proposed that we add an explicit version in the declaration. For instance, the Open Document Format uses a URI to identify the manifest version and then an explicit version attribute to identify the archive version. This is necessary for ODF since the contents are identified with mime types, hence not versioned. Since our OMEX specification will be versioned, this would be somehow redundant.
>
> <?xml version="1.0" encoding="utf-8"?>
> <omexManifest xmlns="http://identifiers.org/combine.specifications/omex-manifest <http://identifiers.org/combine.specifications/omex-manifest>" version="1">
>
> Above, I did not use a versioned URI for the OMEX declaration since we do not have one yet. Stuart proposed that we add an explicit version in the declaration. For instance, the Open Document Format uses a URI to identify the manifest version and then an explicit version attribute to identify the archive version. This is necessary for ODF since the contents are identified with mime types, hence not versioned. Since our OMEX specification will be versioned, this would be somehow redundant.
>
> <?xml version="1.0" encoding="utf-8"?>
> <content location="."
> format="http://identifiers.org/combine.specifications/omex <http://identifiers.org/combine.specifications/omex>"/>
> <content location="./manifest.xml"
> format="http://identifiers.org/combine.specifications/omex-manifest <http://identifiers.org/combine.specifications/omex-manifest>"/>
> <content location="./models/model.xml"
> format="http://identifiers.org/combine.specifications/sbml <http://identifiers.org/combine.specifications/sbml>"/>
> <content location="./simulation.xml" master="true"
> format="http://identifiers.org/combine.specifications/sedml <http://identifiers.org/combine.specifications/sedml>"/>
> <content location="./article.pdf"
> format="application/pdf"/>
> <content location="./metadata.rdf"
> format="http://identifiers.org/combine.specifications/omex-metadata <http://identifiers.org/combine.specifications/omex-metadata>"/>
> format="application/pdf"/>
> <content location="./metadata.rdf"
> </omexManifest>
>
> Note that in the example above, the "version" attribute refers to the OMEX version, not the OMEX manifest version. At the moment, they are linked. However, one can easily imagine that they are split in the future, the OMEX manifest format becoming independent, on part with the other content specifications.
>
> What do-you guys think?
>
> --
> Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT
> Tel: +441223496433 Mob:+447833147074 n.len...@gmail.com <javascript:>
>
> Note that in the example above, the "version" attribute refers to the OMEX version, not the OMEX manifest version. At the moment, they are linked. However, one can easily imagine that they are split in the future, the OMEX manifest format becoming independent, on part with the other content specifications.
>
> What do-you guys think?
>
> --
> Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT
> orcid.org//0000-0002-6309-7327 <http://orcid.org//0000-0002-6309-7327> http://lenoverelab.org/perso/lenov/ <http://lenoverelab.org/perso/lenov/>
> --
> 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 <mailto: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.
tomm...@auckland.ac.nz
Apr 24, 2014, 5:47:12 AM4/24/14
to combine...@googlegroups.com, n.len...@gmail.com
On Thursday, 24 April 2014 10:23:55 UTC+1, Nicolas Le Novere wrote:
Hi Tommy,
"." does not refer to the manifest file. "." refers to the archive itself. In the manifest file, the manifest is refered to as "./manifest.xml" (although the current idea is to make the declaration of manifest optional altogether)
Would "." be invalid for the archive?
Oh, in that case "." is correct as that would refer to the directory (or container) that is the archive, so this would be valid. I had made a wrong assumption, my apologies.
A few other archives use "/". I am just afraid of problems when opening/merging archives.
"/" would cause problems as the interpretation will vary in the context, between the inside of the context of the archive, and then for the expanded archive on the user's file system and on web servers. I would discourage using "/" to denote the root of the archive due to this potential ambiguity.
> To unsubscribe from this group and stop receiving emails from it, send an email to combine-archi...@googlegroups.com <mailto:combine-archive+unsub...@googlegroups.com>.
Reply all
Reply to author
Forward
0 new messages