Bug #2688
openembedded text format ignored by Metacat
0%
Description
When metacat displays metadata documents, the original format is often lost. Newlines, new paragraphs, bullets and the like are largely ignored by the metacat stylesheets, and all spaced is lumped together, creating undesired results.
A number of solutions are being considered and some are deployed in the development metacat at the LTER network office.
A broad approach would be to prepend an html
tag wherever the user has specified within EML that the content should be treated as <literalLayout>. Another broad approach is to plant <pre> tags in critical sections such as methodology descriptions (I.e: eml/dataset/methods/description/) or in inline data. Other workarounds are to explore trimming white space in targeted locations (at beginning and end, not everywhere). There are a handful of different XSL treatments of whitespace, carriage returns, line feeds and new line characters discussed at http://www.dpawson.co.uk/xsl/sect2/N8321.html
Updated by Matt Jones over 17 years ago
Really this is more of an EML issue -- the EML Schema determines what layout and formatting are possible, and the XSLT stylesheets are maintained in the EML modules. I'm not sure how this should be fixed, and it requires broader discussion.
Updated by Margaret O'Brien over 16 years ago
This bug is related to bug 3181, in which some elements typed xs:string may be chaned to ComplexType TextType to accomodate formatting.
Updated by Margaret O'Brien about 16 years ago
other discussions:
additional discussion
literalLayout is a child of <para>, and this template could be added to eml-text.xsl to preserve it:
<xsl:template match="literalLayout">
<xsl:apply-templates/>
</xsl:template>There is still lots of potential for ugliness, however. Here is additional discussion:
http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/metacat-dev/2006-August/000880.html
Updated by Margaret O'Brien about 16 years ago
Inigo and Margaret will get together and discuss what changes to the txt:TextType will be necessary to accommodate common current uses. If these changes represent only additional optional elements added to the Type, they will be backward compatible.