Re: Registration of media type FO and ZFO
At 03:01 08/06/10, Bjoern Hoehrmann wrote:
* Jakub Hytka wrote:
Thanks for the suggestions Frank. I added some information under published specification to describe both media types. We still want to keep the vnd.software602.filler.xml+form and vnd.software602.filler.xml+zip+form subtypes, because they are highly descriptive in our opinion. Is this a important issue to be considered?
Here follows the updated registration proposal:
------------------------------------------------------ ---FO---
Type name: application
Subtype name: Vendor Tree - vnd.software602.filler.xml+form
Required parameters: None
Optional parameters: None
Encoding considerations: UTF-8
Security considerations: FO is a XML-based plain text format, secured by signing the file itself through the means of the XML Signature standard.
See RFC 4288 on the possible values for the Encoding considerations. I am not sure what kind of format you have. Could application/xml also be used instead of vnd.software602.filler.xml+form, i.e., are these simply XML documents with a special type, or is there some special encoding that makes them non-XML without additional decoding? If they are XML, then I would advise to reference RFC 3023 for encoding considerations, and add the optional 'charset' parameter, and consider calling the type e.g. vnd.software602.filler.form+xml.
Very much so indeed. The current subtype name is highly unclear, and if it's indeed XML, then +xml should be last. "because they are highly descriptive" is really a non-starter. The +xml suffix is highly descriptive, the +form 'suffix' is completely undefined. Regards, Martin
By the way, your first message in this thread sounded like this is not the first time you send the proposal, if that is so, please note that I could not find a previous message from you in the archive.
Additional information:
Magic number(s): NONE File extension(s): FO Macintosh file type code(s): -
I would advise against using this extension, I believe it is in common use for XSL FO already.
Type name: application Subtype name: Vendor Tree - vnd.software602.filler.xml+zip+form Required parameters: None Optional parameters: None Encoding considerations: UTF-8
Please see above for the encoding considerations. Perhaps you should re- fer to the application/zip registration here.
Additional information:
Magic number(s): NONE File extension(s): FO Macintosh file type code(s): -
Same as above. -- Bj$B�S(Bn H$B�I(Brmann $B%-(B mailto:bjoern@hoehrmann.de $B%-(B http://bjoern.hoehrmann.de Weinh. Str. 22 $B%-(B Telefon: +49(0)621/4309674 $B%-(B http://www.bjoernsworld.de 68309 Mannheim $B%-(B PGP Pub. KeyID: 0xA4357E78 $B%-(B http://www.websitedev.de/
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
Martin Duerst napsal(a):
At 03:01 08/06/10, Bjoern Hoehrmann wrote:
* Jakub Hytka wrote:
Thanks for the suggestions Frank. I added some information under published specification to describe both media types. We still want to keep the vnd.software602.filler.xml+form and vnd.software602.filler.xml+zip+form subtypes, because they are highly descriptive in our opinion. Is this a important issue to be considered?
Here follows the updated registration proposal:
------------------------------------------------------ ---FO---
Type name: application
Subtype name: Vendor Tree - vnd.software602.filler.xml+form
Required parameters: None
Optional parameters: None
Encoding considerations: UTF-8
Security considerations: FO is a XML-based plain text format, secured by signing the file itself through the means of the XML Signature standard.
See RFC 4288 on the possible values for the Encoding considerations. I am not sure what kind of format you have. Could application/xml also be used instead of vnd.software602.filler.xml+form, i.e., are these simply XML documents with a special type, or is there some special encoding that makes them non-XML without additional decoding? If they are XML, then I would advise to reference RFC 3023 for encoding considerations, and add the optional 'charset' parameter, and consider calling the type e.g. vnd.software602.filler.form+xml.
Very much so indeed. The current subtype name is highly unclear, and if it's indeed XML, then +xml should be last. "because they are highly descriptive" is really a non-starter. The +xml suffix is highly descriptive, the +form 'suffix' is completely undefined.
Regards, Martin
See the reply to Bjoern's message. The reason is to avoid the files being handled as simple XML files, but rather as XML forms, intended for usage in 602XML. That's also why we want to apply to the vendor's tree.
By the way, your first message in this thread sounded like this is not the first time you send the proposal, if that is so, please note that I could not find a previous message from you in the archive.
Additional information:
Magic number(s): NONE File extension(s): FO Macintosh file type code(s): -
I would advise against using this extension, I believe it is in common use for XSL FO already.
Type name: application Subtype name: Vendor Tree - vnd.software602.filler.xml+zip+form Required parameters: None Optional parameters: None Encoding considerations: UTF-8
Please see above for the encoding considerations. Perhaps you should re- fer to the application/zip registration here.
Additional information:
Magic number(s): NONE File extension(s): FO Macintosh file type code(s): -
Same as above. -- Bj��n H��rmann キ mailto:bjoern@hoehrmann.de キ http://bjoern.hoehrmann.de Weinh. Str. 22 キ Telefon: +49(0)621/4309674 キ http://www.bjoernsworld.de 68309 Mannheim キ PGP Pub. KeyID: 0xA4357E78 キ http://www.websitedev.de/
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
Jakub
participants (2)
-
Jakub Hytka -
Martin Duerst