talk@lists.collectionspace.org

WE HAVE SUNSET THIS LISTSERV - Join us at collectionspace@lyrasislists.org

View all threads

a new field proposal for taxon records

PS
Patrick Schmitz
Thu, Dec 6, 2012 9:51 PM

Nice. Thanks for this.


From: Ray Lee [mailto:rhlee@berkeley.edu]
Sent: Thursday, December 06, 2012 12:16 PM
To: Patrick Schmitz
Cc: John B. LOWE; Megan Forbes; CollectionSpace Talk List
Subject: Re: [Talk] a new field proposal for taxon records

Hi Everyone,
Some additional thoughts on how best to represent italicized taxonomic names
in the proposed termFormattedDisplayName field:

As I mentioned earlier, there are basically three ways to produce italicized
text in html: the <em> tag, the <i> tag, and the style attribute on an
arbitrary tag, e.g. <span style="font-style: italic">. Unlike most HTML
renderers, JasperReports doesn't render <em> in italics, so it's not a good
choice, if the primary use for the field is in reports generated by Jasper.

I had assumed that HTML5 would obsolete the <i> tag along with other
presentational elements, leaving just the <span style ...> option for
long-term interoperability. However, this isn't the case. In fact, the <i>
tag is staying in HTML5, and is being redefined to suit our purposes nicely.

The i
<http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-sema
ntics.html#the-i-element>  element now represents a span of text in an
alternate voice or mood, or otherwise offset from the normal prose in a
manner indicating a different quality of text, such as a taxonomic
designation, a technical term, an idiomatic phrase from another language, a
thought, or a ship name in Western texts

This makes <i> semantically the best option, as well as the most concise,
and the easiest for users to edit in the absence of an HTML editor.

Thanks,
Ray

On Tue, Dec 4, 2012 at 4:06 PM, Ray Lee rhlee@berkeley.edu wrote:

I agree that the format of the content of the field should be left up to
implementers. The choice, I think, will largely depend on where the field
will be used. For us, it's primarily in reports, so we're limited to what
JasperReports supports, which is RTF, HTML, and their own proprietary
markup. HTML would be the most interoperable choice.

Annoyingly, JasperReports does not properly render <em> and <strong> tags,
so we can't use them, as much as it's the right thing to do. It does
correctly render <i>, <b>, <span style="font-style: italic">, and <span style="font-weight: bold">. We'll probably be going with the latter two,
since they at least are valid HTML 4+.

References:
http://jasperreports.sourceforge.net/sample.reference/markup/index.html
http://community.jaspersoft.com/jasperreports-library/issues/4842

While this proposal doesn't prescribe that HTML be used, or that there be an
HTML editor widget, I think a rich text editor widget that we can apply as a
decorator to text fields is something that will be useful in the future.
Once we start driving public facing web sites out of CollectionSpace, users
will start to ask how to put italics, superscripts, bullets, and links in
their object descriptions (or other fields).

Thanks,
Ray

On Tue, Dec 4, 2012 at 7:53 AM, Patrick Schmitz pschmitz@berkeley.edu
wrote:

Note also John, that the contents of this field will be set by custom
script, so each implementor can do whatever they want. AIUI, the proposal
does not include an HTML editor widget or anything like that.

We (services) are probably going to add this field to the schemas, but will
not change all the UI templates (implementors can do so as needed). ChrisH
needs it for taxon, but we are inclined to add it to all the auths for
consistency. I think Ray has UI for it in Taxon, which we can commit that as
well, as a demo. Comments?

Patrick

"John B. LOWE" jblowe@berkeley.edu wrote:

Would it not make sense to use a functional markup rather than a
typographic markup for this?  That is, instead of storing an HTML

fragment, store an XML fragment that is then styled.

I.e. (very schematic psuedocode follows!)

Data:

<termFormattedDisplayName> <genus>some genus</genus><author>John Doe></author>... </termFormattedDisplayName>

Then css resembling:

.genus { style: italic }
.author { style: none}

This would allow presentation to be changed without modifying the
data, at the expense of having to style the data.  If the typographic

style for representing these elements is fixed, never going to change,
and will not conflict with existing styling, then HTML is fine and a
bit simpler to program around. Otherwise, the

functional markup is
likely to be more durable.

And I'm guessing in either case the XML/HTML tags would need to be
XML-encoded to hide the structure from the rest of the system?

John

On Mon, Dec 3, 2012 at 5:58 AM, Megan Forbes mforbes@movingimage.us wrote:

No objection from MMI.

On Tue, Nov 27, 2012 at 5:43 PM, Michael T. Black mtblack@berkeley.edu

wrote:

Hi Ray,

PAHMA would also like this feature.

Michael

On Nov 27, 2012, at 1:30 PM, Ray Lee rhlee@berkeley.edu wrote:

Hi

Everyone,
One of our deployments (so far) requires that taxonomic names be printed
with certain formatting rules on their reports. For example, the genus,
species, and supspecies/variety names must be italicized, while authors,

infraspecific ranks, and cultivar names are not. In order to support this,
we're considering adding a field alongside termDisplayName, probably called
termFormattedDisplayName. This field would contain HTML, which would allow

us to store a display name with rich styling applied. (At some point in the
future, maybe we could even convince the UI team to add support for WYSIWYG
editing of rich text fields.)

Since it's somewhat painful to add fields to repeating groups, and even

more painful to add fields to the repeating term group on authority items,
I'd like to propose adding the termFormattedDisplayName field to the common
schema. Is this something that other deployers would use?

Thanks,
Ray


Talk mailing list
Talk@lists.collectionspace.org

http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace
.org


Talk mailing list
Talk@lists.collectionspace.org

http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace
.org

--
Megan Forbes
Collection Manager

Museum of the Moving Image
36-01 35 Avenue  Astoria, NY 11106
movingimage.us  718 777 6800

Direct 718 777 6834


Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace
.org


Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace
.org

--

Sent from my Android phone with K-9 Mail. Please excuse my brevity.


Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace
.org

Nice. Thanks for this. _____ From: Ray Lee [mailto:rhlee@berkeley.edu] Sent: Thursday, December 06, 2012 12:16 PM To: Patrick Schmitz Cc: John B. LOWE; Megan Forbes; CollectionSpace Talk List Subject: Re: [Talk] a new field proposal for taxon records Hi Everyone, Some additional thoughts on how best to represent italicized taxonomic names in the proposed termFormattedDisplayName field: As I mentioned earlier, there are basically three ways to produce italicized text in html: the <em> tag, the <i> tag, and the style attribute on an arbitrary tag, e.g. <span style="font-style: italic">. Unlike most HTML renderers, JasperReports doesn't render <em> in italics, so it's not a good choice, if the primary use for the field is in reports generated by Jasper. I had assumed that HTML5 would obsolete the <i> tag along with other presentational elements, leaving just the <span style ...> option for long-term interoperability. However, this isn't the case. In fact, the <i> tag is staying in HTML5, and is being redefined to suit our purposes nicely. >From http://dev.w3.org/html5/html4-differences/#changed-elements: * The i <http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-sema ntics.html#the-i-element> element now represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name in Western texts This makes <i> semantically the best option, as well as the most concise, and the easiest for users to edit in the absence of an HTML editor. Thanks, Ray On Tue, Dec 4, 2012 at 4:06 PM, Ray Lee <rhlee@berkeley.edu> wrote: I agree that the format of the content of the field should be left up to implementers. The choice, I think, will largely depend on where the field will be used. For us, it's primarily in reports, so we're limited to what JasperReports supports, which is RTF, HTML, and their own proprietary markup. HTML would be the most interoperable choice. Annoyingly, JasperReports does not properly render <em> and <strong> tags, so we can't use them, as much as it's the right thing to do. It does correctly render <i>, <b>, <span style="font-style: italic">, and <span style="font-weight: bold">. We'll probably be going with the latter two, since they at least are valid HTML 4+. References: http://jasperreports.sourceforge.net/sample.reference/markup/index.html http://community.jaspersoft.com/jasperreports-library/issues/4842 While this proposal doesn't prescribe that HTML be used, or that there be an HTML editor widget, I think a rich text editor widget that we can apply as a decorator to text fields is something that will be useful in the future. Once we start driving public facing web sites out of CollectionSpace, users will start to ask how to put italics, superscripts, bullets, and links in their object descriptions (or other fields). Thanks, Ray On Tue, Dec 4, 2012 at 7:53 AM, Patrick Schmitz <pschmitz@berkeley.edu> wrote: Note also John, that the contents of this field will be set by custom script, so each implementor can do whatever they want. AIUI, the proposal does not include an HTML editor widget or anything like that. We (services) are probably going to add this field to the schemas, but will not change all the UI templates (implementors can do so as needed). ChrisH needs it for taxon, but we are inclined to add it to all the auths for consistency. I think Ray has UI for it in Taxon, which we can commit that as well, as a demo. Comments? Patrick "John B. LOWE" <jblowe@berkeley.edu> wrote: Would it not make sense to use a functional markup rather than a typographic markup for this? That is, instead of storing an HTML fragment, store an XML fragment that is then styled. I.e. (very schematic psuedocode follows!) Data: <termFormattedDisplayName> <genus>some genus</genus><author>John Doe></author>... </termFormattedDisplayName> Then css resembling: .genus { style: italic } .author { style: none} This would allow presentation to be changed without modifying the data, at the expense of having to style the data. If the typographic style for representing these elements is fixed, never going to change, and will not conflict with existing styling, then HTML is fine and a bit simpler to program around. Otherwise, the functional markup is likely to be more durable. And I'm guessing in either case the XML/HTML tags would need to be XML-encoded to hide the structure from the rest of the system? John On Mon, Dec 3, 2012 at 5:58 AM, Megan Forbes <mforbes@movingimage.us> wrote: No objection from MMI. On Tue, Nov 27, 2012 at 5:43 PM, Michael T. Black <mtblack@berkeley.edu> wrote: Hi Ray, PAHMA would also like this feature. Michael On Nov 27, 2012, at 1:30 PM, Ray Lee <rhlee@berkeley.edu> wrote: Hi Everyone, One of our deployments (so far) requires that taxonomic names be printed with certain formatting rules on their reports. For example, the genus, species, and supspecies/variety names must be italicized, while authors, infraspecific ranks, and cultivar names are not. In order to support this, we're considering adding a field alongside termDisplayName, probably called termFormattedDisplayName. This field would contain HTML, which would allow us to store a display name with rich styling applied. (At some point in the future, maybe we could even convince the UI team to add support for WYSIWYG editing of rich text fields.) Since it's somewhat painful to add fields to repeating groups, and even more painful to add fields to the repeating term group on authority items, I'd like to propose adding the termFormattedDisplayName field to the common schema. Is this something that other deployers would use? Thanks, Ray _____ Talk mailing list Talk@lists.collectionspace.org http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace .org _____ Talk mailing list Talk@lists.collectionspace.org http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace .org -- Megan Forbes Collection Manager Museum of the Moving Image 36-01 35 Avenue Astoria, NY 11106 movingimage.us 718 777 6800 Direct 718 777 6834 _____ Talk mailing list Talk@lists.collectionspace.org http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace .org _____ Talk mailing list Talk@lists.collectionspace.org http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace .org -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. _______________________________________________ Talk mailing list Talk@lists.collectionspace.org http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace .org