Issue 14988: Content of RecordPart could be more XML friendly (rms-ftf) Source: (, ) Nature: Enhancement Severity: Significant Summary: As it is currently designed, the RecordPart requires the content to be stored as a hexBinary blob. This is very convenient to deal with non-XML data, but it's considerably limiting when dealing with XML data. Considering the emergence of XML databases, if the content of the record part were stored as regular XML, I could perform a XQuery statement that could traverse both the RMS-related data as well as the record-specific data. This is also aligned with the emergence of XMLSec (allowing digital signatures embedded in XML documents). The simplest way to solve this issue (while providing backward compatibility) would be to provide a choice between "content" - which would still be the hexBinary blob - and a new "xmlContent" element - which would then be of the type "any" and then could store any arbitrary XML document. Resolution: Revised Text: Actions taken: January 19, 2010: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 19 Jan 2010 16:12:56 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Daniel Ruoso Company: Prefeitura de Fortaleza mailFrom: daniel@ruoso.com Notification: Yes Specification: RMS Section: XSD FormalNumber: gov/2009-03-10 Version: 1.0 RevisionDate: May 2009 Page: 1 Title: Content of RecordPart could be more XML friendly Nature: Enhancement Severity: Significant test: 3qw8 B1: Report Issue Description: As it is currently designed, the RecordPart requires the content to be stored as a hexBinary blob. This is very convenient to deal with non-XML data, but it's considerably limiting when dealing with XML data. Considering the emergence of XML databases, if the content of the record part were stored as regular XML, I could perform a XQuery statement that could traverse both the RMS-related data as well as the record-specific data. This is also aligned with the emergence of XMLSec (allowing digital signatures embedded in XML documents). The simplest way to solve this issue (while providing backward compatibility) would be to provide a choice between "content" - which would still be the hexBinary blob - and a new "xmlContent" element - which would then be of the type "any" and then could store any arbitrary XML document.