Please contact me at dhagberg - at - millibits.com if you have any questions. The discussion below is related to the re-use of Wikipedia technologies for knowledge management in another system. = Simple Content Markup = ----------------------------- == ISSUE == For wide acceptance and delivery of Voyager, we need to have a simple, clean, consistent model for simple content contribution that allows for adding a minimal amount of content structure, formatting, and semantics. The current contribution/editing interface for simple documents is not sufficient for several reasons: * The wrapping problem. Currently, to get documents to display ''exactly'' the same on-screen, in the Preview window and on SunSolve, the TEXTAREA forms are set to Hard-Wrap. This feature will auto-wrap the ''1st'' time. But the when one attempts to edit the document, they will find that they need to manually re-wrap the entire paragraph they were working on. * The table problem. Currently, if a user contributes an article with an ASCII table, that table *must* be narrower than 75 characters and, every time a longer word or a column needs to be added to the table, the user will need to manually re-wrap the entire table. * The list problem. If the user wants to contribute an article with a numbered list, they would format it like this one (or similarly). If they go back and add an item to the middle of the list, they will need to re-number the entire list. * The styling/formatting problem. Adding *emphasis* like this or /this/ is not the most effective means of communications with Sun's customer base, who expect professional-looking documentation of the same caliber they can get from docs.sun.com or the Microsoft Knowledge Base. * The semantics/linkage problem. Currently, there's no way for a contributor to mark 48004566 as a BugId. It could very well be an Oracle shared memory segment size or the output of the df command. * The StarOffice problem. Firing up StarOffice every time the user wants to contribute a document with the *slightest* amount of formatting is a lot of overhead. 90+% of our contributors would prefer an all-in-one solution where the content and editing is kept in the browser. == SOLUTION == A simple text format that follows intuitive rules for formatting has been widely adopted in the open source and technical communities called WikiWikiWeb or just Wiki for short. See http://www.wikipedia.org/wiki/WikiWiki for background and the very first implementation, http://c2.com/cgi/wiki, for details, and http://twiki.org/ for one of the more full-featured wiki implementations available. A short description of this proposed format follows. Also note that this document is also in Wiki format, and can be seen at http://www.wikipedia.org/wiki/User%3ADhagberg * Paragraphs are separated by a blank line, just like this document. Simple end-of-line breaks are ignored. Multiple blank lines will be collapsed into a single paragraph break. * Lines that start with spaces will be treated as literal text to allow for script, code, or output samples as shown below. Inside literal text, none of the formatting characters described below are significant. if [ -r /tmp/filename ]; then echo "FILE exists!" exit 1 fi * Emphasis is added by surrounding a word with 2 or more single-quote (apostrophe) characters like ''this'' for emphasis, this for strong emphasis, and ''this'' for very strong emphasis. * Sections are started by beginning a line with == Section Name ==. Sub-sections are started by beginning a line with === Subsection Name === and Sub-sub-sections are started by beginning a line with ==== Sub-subsection Name ====. * Bulleted lists, like this one, start with an asterisk (*) at the beginning of the line. For nesting, start the line with 2 or more asterisks. The list ends at the first blank line (so actually, in this document, each bulleted paragraph is its own list). * Numbered lists start with a hash (#) at the beginning of the line. Again, for nesting, start the line with 2 or more hash signs. The list ends at the first blank line, so if this document used # instead of *, all the numbers would be 1. * Definition lists start each term with a semicolon (;) at the start of the line, the term, a colon, and the definition body, with no spaces before the semicolon or between the term and the definition body (this lets people use semicolons normally in a sentence: like this). See the next paragraph for an example: ;This term:This is the definition for the term and may span a paragraph break, so here's a little more text to fill it in. * Links to CMS-specific items will be done like BugId:4700556, PatchId:110556-05, and Article:27005 but cannot be shown on Wikipedia since they do not know how to interpret these types of links. * Image URLs, like http://www.wikipedia.org/upload/wiki.png will be shown as links unless they are in square brackets, in which case they will be shown inline. A similar treatment will be used for the ''Attachments'' functionality of the CMS. * Tables will be handled slightly differently than implemented on the Wikipedia, namely that if the following section were not indented, it would be formatted as the table following the example: |Top Left | Top Right| | Bot Ctr ||
What about improperly nested sections? For example, people wanting a different section based on the font size (appearance), may try to do essentially, an H1 followed by a couple of H3's, skipping level 2 entirely. When converted to Docbook, we could just interpret them as elements, but might look different when rendered in Wiki than when it is transformed from Docbook XML to HTML or PDF.
Essentially, my question is: does wiki restrict nestings, or is this something we have to handle during conversion to docbook?
--Scott
----
Hi. I turned Dhagberg into a redirect to your user page. Those are allowed, as you can see by going to goatasaur. :) -- User:Goatasaur 07:24 29 Jun 2003 (UTC)
:I am fixing all the talk pages and removing redirects to user pages - User:TextureUser Talk:TextureUser:Texture 19:29, 2 Jul 2004 (UTC)
See other meanings of words starting from letter:
Words begining with Dhagberg:
Dhagberg
Dhagberg
Dhagberg
Please contact me at dhagberg - at - millibits.com if you have any questions. The discussion below is related to the re-use of Wikipedia technologies for knowledge management in another system. = Simple Content Markup = ----------------------------- == ISSUE == For wide acceptance and delivery of Voyager, we need to have a simple, clean, consistent model for simple content contribution that allows for adding a minimal amount of content structure, formatting, and semantics. The current contribution/editing interface for simple documents is not sufficient for several reasons: * The wrapping problem. Currently, to get documents to display ''exactly'' the same on-screen, in the Preview window and on SunSolve, the TEXTAREA forms are set to Hard-Wrap. This feature will auto-wrap the ''1st'' time. But the when one attempts to edit the document, they will find that they need to manually re-wrap the entire paragraph they were working on. * The table problem. Currently, if a user contributes an article with an ASCII table, that table *must* be narrower than 75 characters and, every time a longer word or a column needs to be added to the table, the user will need to manually re-wrap the entire table. * The list problem. If the user wants to contribute an article with a numbered list, they would format it like this one (or similarly). If they go back and add an item to the middle of the list, they will need to re-number the entire list. * The styling/formatting problem. Adding *emphasis* like this or /this/ is not the most effective means of communications with Sun's customer base, who expect professional-looking documentation of the same caliber they can get from docs.sun.com or the Microsoft Knowledge Base. * The semantics/linkage problem. Currently, there's no way for a contributor to mark 48004566 as a BugId. It could very well be an Oracle shared memory segment size or the output of the df command. * The StarOffice problem. Firing up StarOffice every time the user wants to contribute a document with the *slightest* amount of formatting is a lot of overhead. 90+% of our contributors would prefer an all-in-one solution where the content and editing is kept in the browser. == SOLUTION == A simple text format that follows intuitive rules for formatting has been widely adopted in the open source and technical communities called WikiWikiWeb or just Wiki for short. See http://www.wikipedia.org/wiki/WikiWiki for background and the very first implementation, http://c2.com/cgi/wiki, for details, and http://twiki.org/ for one of the more full-featured wiki implementations available. A short description of this proposed format follows. Also note that this document is also in Wiki format, and can be seen at http://www.wikipedia.org/wiki/User%3ADhagberg * Paragraphs are separated by a blank line, just like this document. Simple end-of-line breaks are ignored. Multiple blank lines will be collapsed into a single paragraph break. * Lines that start with spaces will be treated as literal text to allow for script, code, or output samples as shown below. Inside literal text, none of the formatting characters described below are significant. if [ -r /tmp/filename ]; then echo "FILE exists!" exit 1 fi * Emphasis is added by surrounding a word with 2 or more single-quote (apostrophe) characters like ''this'' for emphasis, this for strong emphasis, and ''this'' for very strong emphasis. * Sections are started by beginning a line with == Section Name ==. Sub-sections are started by beginning a line with === Subsection Name === and Sub-sub-sections are started by beginning a line with ==== Sub-subsection Name ====. * Bulleted lists, like this one, start with an asterisk (*) at the beginning of the line. For nesting, start the line with 2 or more asterisks. The list ends at the first blank line (so actually, in this document, each bulleted paragraph is its own list). * Numbered lists start with a hash (#) at the beginning of the line. Again, for nesting, start the line with 2 or more hash signs. The list ends at the first blank line, so if this document used # instead of *, all the numbers would be 1. * Definition lists start each term with a semicolon (;) at the start of the line, the term, a colon, and the definition body, with no spaces before the semicolon or between the term and the definition body (this lets people use semicolons normally in a sentence: like this). See the next paragraph for an example: ;This term:This is the definition for the term and may span a paragraph break, so here's a little more text to fill it in. * Links to CMS-specific items will be done like BugId:4700556, PatchId:110556-05, and Article:27005 but cannot be shown on Wikipedia since they do not know how to interpret these types of links. * Image URLs, like http://www.wikipedia.org/upload/wiki.png will be shown as links unless they are in square brackets, in which case they will be shown inline. A similar treatment will be used for the ''Attachments'' functionality of the CMS. * Tables will be handled slightly differently than implemented on the Wikipedia, namely that if the following section were not indented, it would be formatted as the table following the example: |Top Left | Top Right| | Bot Ctr ||
| Top Left | Top Right |
| Bot ctr | |
Dhagberg
What about improperly nested sections? For example, people wanting a different section based on the font size (appearance), may try to do essentially, an H1 followed by a couple of H3's, skipping level 2 entirely. When converted to Docbook, we could just interpret them as
See other meanings of words starting from letter:
D
DA | DB | DC | DE | DF | DG | DH | DI | DJ | DK | DL | DM | DN | DO | DP | DR | DS | DT | DU | DW | DX | DY | DZ |Words begining with Dhagberg:
Dhagberg
Dhagberg
Sponsored links: praca, nurkowanie.
These materials are based on Wikipedia and licensed under the GNU FDL
YouTube.com videos better site than Turbo Tax 2007
