[Archivesspace_Users_Group] Fwd: [archivesspace] <title><emph render="italic">

Chris Fitzpatrick Chris.Fitzpatrick at lyrasis.org
Wed Oct 15 16:13:56 EDT 2014


Hi all,


I also agree generally with Chris' email. But just for some clarification, for mixed content editing, archivesspace uses codemirror ( http://codemirror.net ) which is a popular in-browser "code editor". I'd never used it before, but I have to say it's pretty good (at least as good as ACE, which is it's chief competitor )

The problem is that a default WYSIWYG won't work for EAD editing, as we are wanting to edit content in a way that results in EAD valid markup, not HTML valid markup. <emph render="bold"> or <name> or <xlink:href ... > means nothing to a browser and <span class="bold"> or <a href="http://archive.org"<http://archive.org>> is invalid on EAD export. So, the editor has to be a modified XML editor that works with our schema's requirements.

So,  since Aspace is a web app , we have to translate the markup from EAD into HTML as well as ensure ( or try our best ) that user generated content will result in good EAD markup.

It's actually kind of tricky, since the web framework assumes your only concerned with html validation ( since that's what 99.9% of the world is concerned with...)

Using a markup language ( like EAD ) as your data model presents a lot of challenges for software development. But we have focused recently on a lot of fixes for mixed content, which I hope will resolve a lot of the pain points...

Best, fitz.

Sent from my HTC

----- Reply message -----
From: "Callahan, Maureen" <maureen.callahan at yale.edu>
To: "Archivesspace Users Group" <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Fwd: [archivesspace] <title><emph render="italic">
Date: Wed, Oct 15, 2014 19:32

I agree with Chris (and related concerns that have been brought up by Mark Custer and others). I would like to second his request to have our representatives on the user and technical groups to do some deep thinking about error-resistant ways to handle mixed content/formatting.

Maureen

Maureen Callahan
Archivist, Metadata Specialist
Manuscripts & Archives
Yale University Library
maureen.callahan at yale.edu<mailto:maureen.callahan at yale.edu>
203.432.3627

Webpage: web.library.yale.edu/mssa
Collections: drs.library.yale.edu

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Prom, Christopher John
Sent: Wednesday, October 15, 2014 12:56 PM
To: Archivesspace Users Group
Subject: [Archivesspace_Users_Group] Fwd: [archivesspace] <title><emph render="italic">

I'd like to ask that the techical and user groups look at issues relate to the wrap in tag editor seriously as part of planning future work, not as a one off focusing on specific bugs, but on the assumption that we should review alternatives for the core architecture.

I have always been skeptical of having a purpose built editor for this editing and storing EAD or formatting in the DB.  Using the wrap-in-tage feature is very difficult in our staff testing, and there seem to be a huge number of support requests which is taking time away from more important (IMHO) issues.

As a design consideration, open source WYSIWYG editors such as ckeditor seem like a much a better way to accomplish what users want to accomplish.   We would also benefit from a broader community that has already hashed out most of the difficult design issues for formatting markup, and we could extend this library in other ways, for example to include the sematic markup in a more usable interface than the wrap in tag editor.

http://ckeditor.com/

I am not saying this is the 'solution' the problem, but it does seem to me that something is fundamentally broken at an architecture level here, and we should evaluate alternate strategies, given the large number or bugs and feature requests related to wrap-in-tag editor.

Chris Prom

Begin forwarded message:


From: Trevor Thornton <hellotrevorthornton at gmail.com<mailto:hellotrevorthornton at gmail.com>>
Subject: Re: [archivesspace] <title><emph render="italic">
Date: October 15, 2014 at 11:19:42 AM CDT
To: archivesspace at googlegroups.com<mailto:archivesspace at googlegroups.com>
Reply-To: archivesspace at googlegroups.com<mailto:archivesspace at googlegroups.com>

We didn't resolve it - we removed the XML tags from the titles prior to the final migration (I wrote a script to do this over the copy of the AT database we used for the migration). Not a solution, just an elimination of the problem.
Given that XML is permitted within many elements for which AS doesn't provide support for mixed content, I'd say that it seems like an oversight in the design, not a bug per se, but a missing feature that would better support a fairly common practice (or a legacy practice that persists in the data).

On Wed, Oct 15, 2014 at 11:10 AM, Al Matthews <prolepsis at gmail.com<mailto:prolepsis at gmail.com>> wrote:
Wondering too, how you resolved, Trevor.

On Wed, Oct 15, 2014 at 11:07 AM, Al Matthews <prolepsis at gmail.com<mailto:prolepsis at gmail.com>> wrote:
I follow some of the logic for the feature -> bug -> feature trajectory here: invisible is bad. But we experience this (or perhaps, something vaguely similar) with <chronlist><chronitem> as well.

Is direct print-to-screen of mixed tag content, from a supported migration, really not a bug?

On Wed, Oct 15, 2014 at 10:15 AM, Trevor Thornton <hellotrevorthornton at gmail.com<mailto:hellotrevorthornton at gmail.com>> wrote:
We had the same problem when we migrated from AT (where there was XML in some of the titles, especially for components). Looks like this feature has already been requested:
https://www.pivotaltracker.com/s/projects/386247/stories/74516352

On Wed, Oct 15, 2014 at 9:25 AM, Al Matthews <prolepsis at gmail.com<mailto:prolepsis at gmail.com>> wrote:
Hello. What I've indicated in subject line, <title><emph render="italic">, appears to be valid EAD per http://www.loc.gov/ead/tglib/elements/emph.html. However, based on some quick testing, there does not appear to be a way to make wrap-and-tag appear in Basic Information, Title, at least at item level. Moreover, <emph> is printed directly. Please tell me what I'm missing before I mistakenly report a bug.

Thanks much,

Al

--
You received this message because you are subscribed to the Google Groups "ArchivesSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archivesspace+unsubscribe at googlegroups.com<mailto:archivesspace+unsubscribe at googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to a topic in the Google Groups "ArchivesSpace" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/archivesspace/yQClbTl4ZpI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to archivesspace+unsubscribe at googlegroups.com<mailto:archivesspace+unsubscribe at googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.



--
You received this message because you are subscribed to the Google Groups "ArchivesSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archivesspace+unsubscribe at googlegroups.com<mailto:archivesspace+unsubscribe at googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "ArchivesSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archivesspace+unsubscribe at googlegroups.com<mailto:archivesspace+unsubscribe at googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20141015/8c11e9f0/attachment.html>


More information about the Archivesspace_Users_Group mailing list