Robert, Thx. I understand your scenario. We have two alternatives:
1. Use a standard format for rich text, i.e. XHTML. In your use case then following conversions happen: - Mylyn client GETs the change request. The Trac server converts the wiki text to XHTML and sends the reponse. - Mylyn client receives the response and converts it to wiki text, and displays it in a wiki text editor - User edits text and hits "Save button - Mylyn converts edited wiki text to XHTML and PUTs the modified change request to Trac - Trac receives the XHTML and converts it to native wiki text The disadvantage of this approach is that Trac and Mylyn must convert between their supported text format and XHTML. The advantage is that the two tools are loosely coupled. They'll be able to collaborate with any tools that support OSLC CM 2. Use the native rich text format of the server - Mylyn client GETs the change request. The Trac server puts the native wiki text in the response. - Mylyn client receives the response and displays it in a wiki text editor. This works because Mylyn supports the native wiki text format used by Trac. - User edits text and hits "Save button - Mylyn PUTs the modified change request to Trac - Trac receives the native wiki text The advantage of this approach is that no conversion or loss of fidelity of format occurs. The disadvantage is that Mylyn needs to support the native text format of all servers. This is a burden on the client. Approach #1 is more aligned with the goal of OSLC of facilitating collaboration by defining a standard. The use of XHTML is an aspect of defining standard resource formats. By adopting a common format, each service and consumer has a bounded amount of work to implement, i.e. the conversion to and from its native rich text format. However, OSLC also let's vendors define extensions, so another approach might be to include a copy of the rich text in the native format. Then any clients that happened to support that format could edit it directly, i.e. without conversion. Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 Twitter | Facebook | YouTube From: Robert Elves <[email protected]> To: Arthur Ryman/Toronto/IBM@IBMCA Cc: [email protected], [email protected] Date: 03/30/2010 05:16 PM Subject: Re: [oslc-core] rich text fields Sent by: [email protected] Yes, I'm just thinking of the scenario where an existing service, like Trac for example that uses a wiki style mark up, gets an OSLC_CM wrapper. Then a rich client (with no delegated web ui but OSLC_CM capability) then wants to present and allow editing of an existing record in the native (wiki) format. -Rob On Tue, Mar 30, 2010 at 4:58 PM, Arthur Ryman <[email protected]> wrote: Rob, Please describe the configuration more. Are you assuming that Trac or Jira are OSLC CM service providers and that Mylyn is an OSLC CM service consumer? Is Mylyn creating and updating change requests? Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 Twitter | Facebook | YouTube From: Robert Elves <[email protected]> To: Arthur Ryman/Toronto/IBM@IBMCA Cc: [email protected], [email protected] Date: 03/30/2010 04:28 PM Subject: Re: [oslc-core] rich text fields Sent by: [email protected] Okay, so it sounds like scenarios where a rich client (i.e. Mylyn) intends to edit wiki markup in a field (i.e. description) and the server usually serves up wiki (i.e. Trac, Jira, etc), translation to and from xhtml would need to take place by both parties. In this scenario, would you recommend simply wrapping and escaping the plain text content within the xhtml body? Sorry for all the questions Arthur, but just want to make sure I understand the implications. -Rob On Tue, Mar 30, 2010 at 3:03 PM, Arthur Ryman <[email protected]> wrote: Rob, OSLC should define some standard properties that can contain rich text. I assume you are therefore asking what should be done if the existing service can't handle rich text, i.e. it can only handle plain text. Fortunately, HTML and XHTML give a simple way to downcast rich text to plain text, namely just throw away the elements and keep their content. Browsers do this when they get elements they don't understand. If the existing service was capable of some amount of rich formatting then it could map what it could to its native format. However, the native format would have to be mapped back to XHTML when interchanged. Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 Twitter | Facebook | YouTube From: Robert Elves <[email protected]> To: Arthur Ryman/Toronto/IBM@IBMCA Cc: [email protected], [email protected] Date: 03/30/2010 12:54 PM Subject: Re: [oslc-core] rich text fields Sent by: [email protected] Thanks for your response on this Author. XHTML does make a lot of sense in terms of tool support and xml interchange, so I guess my only question now is what happens in the case where an existing service requires plain text (i.e. text/plain, so could be text possibly in wiki syntax) to be posted to it? The OSLC wrapper for such a service I guess would then need to do its best at converting the posted XHTML to its native syntax? -Rob On Tue, Mar 30, 2010 at 12:02 PM, Arthur Ryman <[email protected]> wrote: Robert, If we support multiple rich text formats then it increases the burden on all consumers and providers, for example to do full text search, or to present rich text in web pages, reports and documents. It simplifies interchange and collaboration if OSLC standardizes on a single format for rich text. IMHO, XHTML is the best candidate since it is widely supported, is a W3 standard, and is XML compliant, which makes it easy to parse. Most text editors can export and import XHTML. You mention wiki text, but each wiki has its own special syntax. AFAIK, there is no standardization or media types for any given wiki dialect. Wikis convert their markup to HTML anyway for display on the web so it would seem that any tool that captured rich text on a wiki would have the capability to convert it to HTML. There are tools for converting HTML to XHTML, e.g. HTML Tidy. If this conversion is done at interchange time then it simplifies all other consumers. Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 Twitter | Facebook | YouTube From: Robert Elves <[email protected]> To: [email protected] Date: 03/30/2010 10:41 AM Subject: [oslc-core] rich text fields Sent by: [email protected] Hi Group, I need to raise a concern about strict use of xhtml in the current core spec. Although this will work great for those services that use html, I'm concerned that for many services out there that use another syntax (i.e. text / wiki), this may unnecessarily complicate both the producers and consumers. Is it worth exploring inclusion of a media type attribute on these properties? Thanks, -Rob -- Robert Elves Tasktop Developer, http://tasktop.com/ Mylyn Committer, http://eclipse.org/mylyn _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net -- Robert Elves Tasktop Developer, http://tasktop.com/ Mylyn Committer, http://eclipse.org/mylyn -- Robert Elves Tasktop Developer, http://tasktop.com/ Mylyn Committer, http://eclipse.org/mylyn -- Robert Elves Tasktop Developer, http://tasktop.com/ Mylyn Committer, http://eclipse.org/mylyn
