[oslc-core] rich text fields

Thu Apr 1 19:59:19 EDT 2010

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100401/effb9fdc/attachment-0003.html>