[oslc-core] rich text fields

Mon Apr 5 10:52:09 EDT 2010

Dave,

I think the goals of OSLC are different than Atom.

Atom is a publishing format and it does not dictate the content that is 
being published. Typically, you have one entity publishing content and 
many others reading that content. It's a write-once, read-many 
architecture.

In contrast, OSLC is for facilitating tool collaboration and the 
information hosted by a tool is expected to be created or modified by a 
variety of other tools. Since many tools need to update rich text, there 
is a lot of benefit to defining a single format for interchange.

I've participated in the development of reporting and document generation 
tools. We found that there was a lot of variation in how tools stored rich 
text, e.g. Word, RTF, HTML, XHTML etc. This significantly complicates how 
you process that text. OSLC should be making life easier for tools, and 
standardizing on a rich text format would be a very useful simplification.

I think we need to differentiate how users interact with text versus how 
tools interchange text. A tool should present text in an easily edited 
way, so a wiki format is fine for that purpose. However, when it comes to 
interchanging text, a standard should be used. XHTML seems like a good 
choice as the interchange format. A domain specification can place further 
constraints on the markup, e.g. allow only <span> content in a dc:title.

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:
Dave <snoopdave at gmail.com>
To:
Robert Elves <robert.elves at tasktop.com>
Cc:
Arthur Ryman/Toronto/IBM at IBMCA, oslc-core at open-services.net, 
oslc-core-bounces at open-services.net
Date:
04/01/2010 06:13 PM
Subject:
Re: [oslc-core] rich text fields

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
>
>