[oslc-core] rich text fields

[Robert Elves]

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 <ryman at ca.ibm.com> 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 <robert.elves at tasktop.com>
> To:
> Arthur Ryman/Toronto/IBM at IBMCA
> Cc:
> oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date:
> 03/30/2010 04:28 PM
> Subject:
> Re: [oslc-core] rich text fields
> Sent by:
> rob at tasktop.com
>
>
>
> 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 <ryman at ca.ibm.com> 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 <robert.elves at tasktop.com>
> To:
> Arthur Ryman/Toronto/IBM at IBMCA
> Cc:
> oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date:
> 03/30/2010 12:54 PM
> Subject:
> Re: [oslc-core] rich text fields
> Sent by:
> rob at tasktop.com
>
>
>
> 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 <ryman at ca.ibm.com> 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 <robert.elves at tasktop.com>
> To:
> oslc-core at open-services.net
> Date:
> 03/30/2010 10:41 AM
> Subject:
> [oslc-core] rich text fields
> Sent by:
> oslc-core-bounces at open-services.net
>
>
>
> 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
> Oslc-Core at open-services.net
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100330/09b1d135/attachment-0003.html>