[oslc-core] rich text fields

Thu Apr 8 09:15:08 EDT 2010

Rob,

I agree. I think it would be appropriate for OSLC to make a statement 
like: Domain specs SHOULD use XHTML for properties that contain rich text 
in order to achieve maximum interoperability with other tools.

However, it's also conceivable that some specialized domain might use 
another well-established standard for rich text for some specific 
artifacts, e.g. ODF, OOXML, DocBook, DITA, so we don't want to exclude 
them. 

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:
Dave <snoopdave at gmail.com>
Cc:
oslc-core at open-services.net
Date:
04/07/2010 01:48 PM
Subject:
Re: [oslc-core] rich text fields
Sent by:
oslc-core-bounces at open-services.net

Hi Dave,

I think even with this few fields mandated to xhtml, services will still 
need to clean/translate from xhtml to their native format. It may be that 
this translation is an acceptable overhead in order to achieve seamless 
interoperability. If that is the case, then standardizing on XHTML for all 
rich text fiels would make sense since service providers are going to have 
to be xhtml savvy anyway (servers/clients could then treat all rich text 
fields uniformly). Thoughts?

-Rob

On Wed, Apr 7, 2010 at 1:05 PM, Dave <snoopdave at gmail.com> wrote:
I captured this issue as #15 under OSLC Defined Resources:

  http://open-services.net/bin/view/Main/OslcCoreV1Issues

Here's what I wrote:

OPEN Should we really mandate XHTML for rich text fields? What about
systems that support wiki syntax or just HTML? Response: Make common
properties dc:title and dc:description XML literal with type XHTML and
recommend XHTML for rich text interchange, but beyond that no mandate.
Once that is done in spec, mark this issue as deferred to ensure that
we have some guidance on how to deal with text fields, rich text
fields and wiki syntax.

The response part is based on the discussion that we had in the Core
WG meeting today. Robert, do you think that response is acceptable?

Thanks,
- Dave

On Mon, Apr 5, 2010 at 11:07 AM, Arthur Ryman <ryman at ca.ibm.com> wrote:
> Robert/Dave,
>
> I think it's valid for a domain spec to define the content of any given
> property. The use of MIME types does not seem aligned with how RDF
> datatypes are identified. OSLC resource formats should have RDF/XML
> representations so they can be combined with other Semantic web data
> sources.
>
> I believe the start of this thread was how to define the content of the
> standard properties dc:title and dc:description. In my team's 
experience,
> we have found that many tools need to use rich text for these 
properties.
> For example, users of requirements tools often assign meaning to text
> styles. I therefore proposed that we use XHTML for these properties,
> <span> content for dc:title, and <div> content for dc:description. This
> aligns with the RDF XML Literal datatype.
>
> 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:
> Dave <snoopdave at gmail.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 08:00 PM
> Subject:
> Re: [oslc-core] rich text fields
> Sent by:
> rob at tasktop.com
>
>
>
> Hi Dave,
>
> I think this could work. Service consumers could then examine the 
Resource
> Shape to determine the accepted type. Would we want to scope the
> acceptable types to just those three:  text/plain, text/html, and
> application/xhtml+xml to keep things relatively simple?
>
> -Rob
>
>
> On Thu, Apr 1, 2010 at 6:12 PM, Dave <snoopdave at gmail.com> wrote:
> 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
>>
>>
>
>
>
> --
> 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