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
