[oslc-core] rich text fields

Thu Apr 1 18:12:15 EDT 2010

I'm biased against XHTML myself. I've found it to be a complete pain
to maintain a blog with valid XHTML. I know tools can help, but I've
found those tools and especially web-based rich text editors to be
horrible and unpredictable. I have to edit HTML by hand to get what I
want. And, didn't XHTML fail and is now being super-ceded by HTML5, a
much more forgiving (and non XML) format? On the other hand, I love
wikis and the fact that wiki text looks a lot like plain text.

So, I'm not that comfortable with adopting XHTML as the OSLC wide
standard for rich text, but I understand the value of having a
standard here and unfortunately for me, XHTML really seems like the
best fit. I wish we had a way to better accomodate wiki syntax, but
there are so many wiki syntaxes out there. There is Creole, which is
supposed to be a standard but very few wikis support it.

Here's an idea that would give a little more flexibility to providers:
adopt the Atom content model. We would introduce a special "Rich Text"
value-type, which would behave just like the Atom <content> element.
So, for a rich text field a provider would provide a "type" attribute
of TEXT, HTML, XHTML or a valid MIME content-type. This way, a client
would be able to detect if the content was plain text, escaped HTML,
real live XHTML or some other content-type. Domain specs could put
constraints on that too, like requiring only text, HTML or XHTML or
requiring only XHTML.

   http://tools.ietf.org/html/rfc4287#page-14

Personally, I think it is a well thought-out model. It doesn't do much
for the wiki syntax case, but it does give implementations flexibility
to provide HTML, XHTML or plain text -- which I think is the the right
thing to do. What do you think?

- Dave

Do we need a more rigid content model for text content

On Tue, Mar 30, 2010 at 5:15 PM, Robert Elves <robert.elves at tasktop.com> wrote:
> 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
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
>