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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> To: >> Arthur Ryman/Toronto/IBM@IBMCA >> Cc: >> [email protected], [email protected] >> Date: >> 03/30/2010 04:28 PM >> Subject: >> Re: [oslc-core] rich text fields >> Sent by: >> [email protected] >> >> >> >> 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 <[email protected]> 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 <[email protected]> >> To: >> Arthur Ryman/Toronto/IBM@IBMCA >> Cc: >> [email protected], [email protected] >> Date: >> 03/30/2010 12:54 PM >> Subject: >> Re: [oslc-core] rich text fields >> Sent by: >> [email protected] >> >> >> >> 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 <[email protected]> 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 <[email protected]> >> To: >> [email protected] >> Date: >> 03/30/2010 10:41 AM >> Subject: >> [oslc-core] rich text fields >> Sent by: >> [email protected] >> >> >> >> 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 >> [email protected] >> 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 > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > >
