As someone who has spent a lot of time talking with folks about 'shareable' metadata, I just want to second Mark's comment that we really should not be putting html content into metadata fields. If you want a feel for what this looks like downstream, do a search on <p> (or other html tags of your choice) in something like OAIster (http://www.oaister.org/). Downstream applications that reuse your metadata generally ignore the markup but still keep it in the metadata. We've also seen example like:
<dc:title><i>GOPHERUS POLYPHEMUS</i> (Gopher Tortoise) COYOTE PREDATION</dc:title> where creators have tried to not include actual html markup, but in the end cause even more confusion for applications using the metadata (not to mention users who are accessing these). Sarah Shreeves -- Sarah L. Shreeves Coordinator, IDEALS http://www.ideals.uiuc.edu/ University of Illinois at Urbana-Champaign sshre...@illinois.edu 217-244-3877 or 217-333-4648 Mark Diggory wrote: > On Mon, Jul 13, 2009 at 7:07 AM, Antonio Cuomo<anto...@parliaments.info> > wrote: > >> Dear Mark, it's the common behavior with all the DSpace installation i have >> seen (MIT included). >> >> The problem is that all the data in the field dc.description are saved as >> plain text for security issues. >> > > I understand now, this is a discussion about Item metadata fields, not > Community Collection descriptions where html content is allowed. I > agree with Alan's assessment here: > > 1.) I really do not advise placing html content into metadata fields. > this will cause much difficulty downstream in the application when > those fields are rendered into things like <meta name="dc.description > value="..."/> fields, oai records and other xml centric serializations > > 2.) Placing html into metadata fields suggests that they are more than > content, but also presentation. Overall this is a very bad practice > and I do not recommend doing it. > > If you do feel it necessary to approach doing this you might approach > some of Patricks comments, but I will heavily caution that if the user > inputs ill-formed xml, it will break the rendering pipeline and result > in a 500 error page being rendered. The concern here is that the field > value is parsed into the sax stream before the i18n and serialization > transformations occur and thus needs to be well formed for those > stages to occur. > > Another alternative might be to look at using JTidy to cleanup the > value prior to having saxon or xalan parse it. See for instance > > http://scm.dspace.org/svn/repo/modules/dspace-rdf/trunk/src/main/java/org/dspace/adapters/rdf/DSpaceObjectAdapter.java > > Mark > ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
