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
