[oslc-core] rich text fields

Wed Apr 7 14:16:15 EDT 2010

With tools like Tidy to go from HTML to XHTML, and the ability to
parse XHTML with XML tools I think this is probably an acceptable
overhead in terms of implementation cost and performance.

- Dave

On Wed, Apr 7, 2010 at 1:48 PM, Robert Elves <robert.elves at tasktop.com> wrote:
> 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
>