elifesciences / XML-mapping

Mapping the XML to new Continuum requirements and build of a new Kitchen sink
3 stars 9 forks source link

supplementary-material mimetype and mime-subtype #48

Closed gnott closed 8 years ago

gnott commented 8 years ago

I'm looking specifically at this for parsing,

<media mimetype="xlsx" xlink:href="elife-00666-fig3-figsupp1-data1-v1.xlsx"/>

Would it have a mime-subtype and also switched, so it'd be something like this?

<media mime-subtype="xlsx" mimetype="application" xlink:href="elife-00666-fig3-figsupp1-data1-v1.xlsx"/>
Melissa37 commented 8 years ago

I think we have this in the archive, but going forward I just want to have one mimetype which is the file format. Does that sound OK?

M

gnott commented 8 years ago

One impact will be in the CrossRef deposits. When components are deposited the mime type needs to fit a specific list allowed. Right now the mimetype + mime-subtype is used to set it. We would have to create new translation code to convert the values to the acceptable types.

Other places it may not matter right now are, for example, when files are uploaded to S3, S3 uses the file extension of the file name to guess a default mime type it should put on the object.

I don't think there are lots of other places the mimetype is used in our code, although it could be used in places I'm not aware of. Other users of the XML might depend on these standard values also.

Melissa37 commented 8 years ago

This has been discussed over email now