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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> > To: >> > Dave <[email protected]> >> > Cc: >> > Arthur Ryman/Toronto/IBM@IBMCA, [email protected], >> > [email protected] >> > Date: >> > 04/01/2010 08:00 PM >> > Subject: >> > Re: [oslc-core] rich text fields >> > Sent by: >> > [email protected] >> > >> > >> > >> > 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 <[email protected]> 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 <[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 >> >> >> >> >> > >> > >> > >> > -- >> > 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 >
