| Re: [smila-dev] XML and attachments |
Hi, +1 for adding attachment handling to XML. One could think about configuring a similar behaviour that we realized for differing between JSON / BON: In BON serialization we serialize the attachments with content as described in the wiki: http://wiki.eclipse.org/SMILA/Documentation/Data_Model_and_Serialization_Formats#BON_Binary_Object_Notation_Format In JSON serialization we just write the names of the attachments to a metadata system attribute (“_attachmentNames”). http://wiki.eclipse.org/SMILA/Documentation/Data_Model_and_Serialization_Formats#JSON_format When parsing such a serialized output back to a record, we remove the system attribute and set attachments (with content <null>) in the record. So in XML we could allow to configure exactly these two behaviour for (de-)serialization. Don’t know if we really need to configure between attachments with and without content in a single record serialization, as you mentioned below. IMHO we don’t need it, and it would made the API easier to just switch between with/without attachment content for the whole record. BTW, don’t know if we still need this record versioning at all. We don’t support this for other serialization formats beside XML. Cheers, Andreas Von: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] Im Auftrag von Thomas Menzel Hi folks, I have seen there is now support for transporting attachments in JSON and BON. I was wondering if we should add this to XML as well to stay lossless between the formats. To keep it simple I would make the following suggestion which is a change to the XML record format. <Attachment key=’name’>${base64}</Attachment> However, it is still somewhat compatible with the old format because: · From the reading perspective it wanst possible to parse <Attachment/> tags anyhow · From the writing perspective we could allow an option to either just write the old 2.0 style, i.e. just the attachment names as a hint or write them out incl. the binary content encoded as base64. It should also be possible to filter which of the attachment shall be parsed as base64 and which not. API suggestion: enum AttachmentWriteStyle { BASE64, HINT, OMIT }; /** * Serialize2. * * @param record * the record to be serialized * @param attachmentNamesAsBase64 * the attachment names to be base64 encoded in the XML output. If an attachment name is included in both * lists then this one wins. * @param attachmentNamesAsHint * for those attachment only their names are written (2.0 style) * @param remainderStyle * controls how the attachmets are written that are not included in either of the arrays. */ void serialize2(Record record, String[] attachmentNamesAsBase64, String[] attachmentNamesAsHint, AttachmentWriteStyle remainderStyle) { } /** * Serialize2. * * @param record the record to be serialized * @param attachmentNames the attachment names * @param namedStyle the style how the name attachments are to be written * @param remainderStyle controls how the attachmets are written that are not included in attachmentNames[] */ void serialize2(Record record, String[] attachmentNames, AttachmentWriteStyle namedStyle, AttachmentWriteStyle remainderStyle) { } Of course for each there will be the diff. kinds of outputs (string, byte[] , stream) for each of these. I was 1st wondering if there is actually another need for this at all apart from staying compatible, and I think there is, namely logging. Well, tell me what you think and if you had other plans regarding this. Also, I would propose to increase the record version to 2.1 then, or does this justify a jump to 3.0? Thomas Menzel @ brox IT-Solutions GmbH Taglocity Tags: smila |