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
