Title: Creativyst Universal Format (CUF-tm) Code Standard (v1.0a) Author(s): John Repici Version: 1.0a Doc-Type: Standard Audience-Type: Implementor By(/For): Creativyst, Inc. DocPath: Doc/Std/CUF/v10a/CUFStd.txt (or ".htm") Released: 25-July-2002 (C) Copyright 2002, Creativyst, Inc. ALL RIGHTS RESERVED Creativyst Universal Format (CUF-tm) Code Standard (v1.0a) CUF(tm) codes are message formatting codes that permit application users the flexibility to include elements of style, design, and layout within application-maintained messages and documents in a simple, easy-to-understand way. Users inputting messages into CUF(tm) compliant applications may also include links, glossary entries, and even tables within their messages Application developers and those who deploy applications are also afforded some control over what elements are permitted and within what limits such elements may be displayed. CUF(tm) codes are designed to be manually inserted into messages by users of an application. They may also be semi-automatically inserted (such as a user clicking on a tool-bar button that inserts the CUF code corresponding to a function). Though CUF(tm) codes may also be completely automated within text streams, other standards such as XML SHOULD be considered in such cases. section 2 -------------------- You may use this document Though this document is (C) Copyright 2002, Creativyst, Inc. ALL RIGHTS RESERVED It is part of what we refer to as a SHARED standard. That basically means anyone, whether for commercial purposes or not --including competing products-- may use the various components of this standard and distribute them, provided they meet and agree to a minimal set of restrictions and requirements that are printed here and on the other components of the standard. For specific information on what the requirements are, see the sections below starting with the section titled "CUF(tm) Licensing" section 3 -------------------- Philosophy and Design Goals As the HTML specification continues to develop into a robust document markup language, a need has emerged among non-IT professionals for formatting codes that are easy to use and understand. The W3C has chosen to move toward separating content from format in newer HTML standards. This has taken HTML from being a formatting standard that was already difficult for non-IT professionals to use, to a document standard specifically for use by programmers and web-page designers. This was not a bad decision by the W3C. As mentioned, HTML's utility as an end-user formatting code was already questionable to begin with. As HTML standards become more complex, a cooperative effort on SIMPLE formatting codes can fill the void. Such an effort should embrace simplicity and ease of use over technical flexibility so that the non-IT community can best benefit. For this reason, the overriding philosophy for this standard is simplicity for end users. Design goals 1. Simple for non-IT professionals to use 2. Extremely low initial learning barrier to users (typing text). 3. Flexibility when required despite easy learning curve. 4. Non-SGML syntax in order to compliment SGML based markups 5. Easy for developers to add to new and existing applications 6. A secure, consistent, concisely defined interface 7. Open source and community section 4 -------------------- Document Conventions (Meta-Standards) These are the conventions used in this standard. These are taken from the Creativyst Documentation Standards and Conventions document. Where usage differs, those printed here should be considered the most authoritative source for conventions as they are used in THIS DOCUMENT. MUST/WILL The feature that this refers to is REQUIRED by the standard. The implementor MUST included the feature in the implementation SHOULD The feature is STRONGLY recommended but not absolutely REQUIRED by the standard. The implementor SHOULD include the feature, but does not have to. This is sometimes used to refer to features that simply don't fit within the framework of some applications, allowing designers the option of leaving out features that just don't make sense in the context of the application being developed. MAY Describes a feature which the implementor may or may not choose to include. Such features are suggestions only and should also be thought of as one of many possible additions an implementor might want to add within the scope of the standard. SHOULD NOT Describes a feature that SHOULD be avoided by implementations. Though avoiding such features is STRONGLY recommended they are not out-right prohibited by the standard. MUST NOT/WILL NOT Describes features that are strictly PROHIBITED within the standard. . . . Audience-Types These are mutually exclusive categories for user-centric documentation and discussions: IMPLEMENTOR The developer producing a library of code or set of functions that implements this standard. DEVELOPER The developer designing an application that uses the functions that are implemented by the implementor. DEPLOYER / INTEGRATOR The deployer or application integrator that uses the application developed by the DEVELOPER. For example, this could be a web page designer that uses a particular BBS application developed by a DEVELOPER. This could also be a company that buys an application and deploys it within its enterprise. A deployer will be responsible for selecting configuration options that effect how a particular installation will behave among other things. END-USER / USER A software user. This is sometimes, but not always, a person who's expertise is not in the software or application design industry. It is anyone (software savvy or not) who uses the end product as what is typically known as a "user". However, this is explicitly NOT a developer who is using an implementation (such as a library of functions), or a deployer who installs an application as part of his or her enterprise/site designs (this caveat attempts to avoid the overlap and the resulting ambiguity that arises between these audience categories). . . . Qualifier to audience-types: A given audience-type may OPTIONALLY be qualified with a single qualifier. Following is a list of the one audience-type qualifier referenced in this document. INSTALLER: Anyone in any of the audience-categories who installs and/or initializes a product of that type. Following is a table of how this qualifier effects the documents for audience-types: END-USER: If there is no deployer, an END-USER will often be responsible for installing the application. DEPLOYER: A deployer will often install applications. These can include application specialists, network and web-site administrators (a.k.a. webmasters), and user support specialists. DEVELOPER: Often responsible for the installation of the tool or library code provided by the IMPLEMENTOR. Often the IMPLEMENTOR and DEVELOPER are the same person. For example, a DEVELOPER may implement a standard from scratch as part of his or her application. IMPLEMENTOR The implementor may also be an installer, unzipping the text of the standard, example functions or an example implementation. Also, tools to aid in development of the implementation and verifying the implementation may all be installable distributables. section 5 -------------------- Line Formatting in CUF(tm) Line formatting WILL NOT occur between these tags: [{]nobr] .. [{]/nobr] While line-formatting is explicitly shut off [{]code] .. [{]/code] Inside a preformatted area (or code block) [{]pre] .. [{]/pre] Inside a preformatted area (or code block) [oL] .. [/oL] Inside an ordered list. [uL] .. [/uL] Inside an unordered list. [List] .. [/List] Inside a list. [{]form] .. [{]/form] While formatting forms [{]table] .. [{]/table] While formatting tables Explicit break and paragraph tags will be translated into their HTML counterparts whether inside or outside of these tags. Otherwise, line formatting WILL occur in this fashion: A single new-line character by itself WILL be translated into a single HTML BRake tag. Multiple consecutive new-line characters WILL be consolidated and translated into a single Paragraph tag. Explicit break and paragraph tags WILL NOT be consolidated. section 6 -------------------- Bare Links in CUF(tm) If there are HTML links such as URLs, URIs, and mailto links embedded in the text of a CUF(tm) message, such links MAY be converted into HTML anchors. This MAY be implemented as a DEPLOYER and/or END-USER specified option. This mechanism MUST NOT be considered a replacement for the tags which permit the same functions. Tags that permit links to be embedded in CUF(tm) messages and are part of the CORE LEVEL standard MUST be included even if bare link translation is implemented. If translation of Bare links into anchors is implemented the implementer SHOULD give END-USERS a way to circumvent the translation. The simplest way the implementer MAY do this is to simply inform users that the null tag ([{]']) can be inserted in a way that makes it unrecognizable as a bare link (e.g. "ht[{]']tp://"). Naturally, for this to work, Bare Link translation MUST occur before the null link is removed. section 7 -------------------- DEVELOPER Defined Tags in CUF(tm) Tags defined by an application DEVELOPER which extend the set of tags defined as part of the CUF(tm) standard are called "proprietary" tags, "extension" tags, or "user defined" tags. Applications claiming CUF(tm) compliance MAY include extension tags but any included MUST conform to the following conditions: 1. A user defined tag MUST have a syntax which is consistent with the syntax of tags defined by the CUF(tm) standard and 2. A user defined tag MUST NOT be easily confused or syntactically ambiguous with any tag defined in the current CUF(tm) standard and 3. User defined tags of general purpose functionality MAY be shared with Creativyst for possible inclusion in future versions and 4. User defined tags SHOULD be included with the understanding that they may conflict with future versions. If tag-names are registered with Creativyst, Inc. we will try to keep them out of future versions but no guarantees are given (if of course, they have the same function, they do not conflict). 5. Except for "OLD TAGS" (tags from an older version of an application), a user defined tag MUST NOT perform the same function as a differently named tag that is already defined in CUF(tm). 6. If a user defined tag is an "OLD TAG" AND has the same function as a CUF(tm) tag it MAY be included but it MUST be either undocumented or clearly documented as an OBSOLETE tag with the CUF(tm) compliant tag given as the prefered replacement. 7. User defined tags MUST be part of an application that MUST NOT be a code library, or include a code library for use by DEVELOPERS, DEPLOYERS, or USERS and MUST NOT include any documentation which describes the use of the functions or code that implements tags. In other words, such replacement tags are NOT permitted in software distributed as a CUF IMPLEMENTATION, but are permitted in APPLICATIONS that are CUF(tm) compliant. section 8 -------------------- Compliance Levels in CUF(tm) In order for an IMPLEMENTATION to claim compliance with this standard it MUST meet the compliance considerations as they are documented here. CUF(tm) tag compliance is defined in five levels: CORE Core level codes MUST be included in all implementations that call themselves CUF(tm) compliant. The implementation MAY limit or allow limits on core tags that produce links to outside content in order to prevent linking to unwanted content. Such limits however MUST permit a deployer to easily override them permitting full functionality. TOGGLE Toggle level formatters SHOULD be included with all implementations that call themselves CUF(tm) compliant. If an implementation includes a particular toggle level code it SHOULD allow the DEPLOYER to toggle it on and off. An implementation that includes a toggle level code MAY also limit the code's abilities. For example a TABLE code MAY be limited to some percentage of the width of the message space, and a FONT code MAY be limited to just the seven HTML size attributes. OBSOLETE For listing old obsolete codes. These MUST NOT be included in new implementations unless otherwise noted, but MAY be included in implementations where they were once used and could be embedded in stored CUF(tm) messages. IMPLEMENTATION Implementation-level codes. These SHOULD be used for their specified functions in implementations where they make sense. For example, many of these are page level modifiers (adding script text to pages for example). In cases where such functionality is required, these SHOULD be used. When this functionality is implemented, replacement tags that perform the same functions but have different tags MUST NOT be used. section 9 -------------------- The CUF(tm) CLI To claim CUF(tm) compliance an implementation MUST export two symbols exactly as named here: CUF CUFTog The case shown here MUST Be used if case is significant in the target platform or environment. CUF(msg) CUF MUST always be a function call with this calling syntax. It WILL translate the CUF codes embedded in the message referenced by the 'msg' parameter into natively formatted text, ready for display. There is one parameter: msg This is a pointer or reference to the text message to be translated (which includes embedded CUF-tm codes). It MUST be passed BY REFERENCE (which can be either pointer or reference) IF the platform supports such a method of passing. In such cases the message WILL be translated IN PLACE. If the platform does not support passing by reference, that fact MUST be clearly documented. Return: The function returns no value but has a side effect of translating the CUF(tm) codes embedded within the message referenced by the 'msg' parameter into native formatting codes or sequences. Thread safe Re-entrancy The function must be thread-safe if implemented on platforms that permit multi-threading. That is, it must be callable from multiple threads within a single process and memory address space without adverse interactions between calls in different threads. There is not a need for recursive reentrancy. CUFTog(name, value); or CUFTog{'name'} = value; or CUFTog['name'] = value; CUFTog MUST be implemented as a function call, a hash table, or an associative array. CUFTog MUST NOT be implemented as a hash table or associative array within platforms that do not support these constructs natively. There are two parameters: name The name of the configuration parameter (see below) that is being set. In platforms that support strings or pointers to char as a variable type this MUST be a string or string literal. value The value to set the configuration variable (given in name) to. In platforms that support strings or pointers to char as a variable type this MUST be a string or string literal. The name parameter MUST include the following label values set as prescribed: Font Support for the [FONT...] tag MAY be set with a value denoting that the font tag is ON or OFF (a boolean value, e.g. "1", "OFF", "0") or a set of values to determine limitations. In any case an empty sting or boolean LOW value must be interpreted as the FONT tag not being supported. Image Support for various Image tags MAY be set with a value denoting that the image tags are ON or OFF (a boolean value, e.g. "1", "OFF", "0") or may contain a set of values denoting more subtle limitations. In any case an empty sting or boolean LOW value MUST be interpreted to mean Image support is disabled. Table Support for various TABLE tags MAY be set with a value denoting that the table tags are ON or OFF (a boolean value, e.g. "1", "OFF", "0") or may contain a set of values denoting more subtle limitations. In any case, an empty sting or boolean LOW value MUST be interpreted to mean table support is disabled. Form Support for various FORM tags MAY be set with a value denoting that the FORM tags are ON or OFF (a boolean value, e.g. "1", "OFF", "0") or MAY contain a set of values denoting more subtle limitations. In any case, an empty sting or boolean LOW value MUST be interpreted to mean form support is disabled. Glossary Support for the GLOSSARY tag MAY be set with a value denoting that the GLOSSARY tag is ON or OFF (a boolean value, e.g. "1", "OFF", "0") but SHOULD contain the query string used to invoke the glossary lookup. It MAY contain a set of values denoting more subtle limitations. In any case, an empty sting or boolean LOW value MUST be interpreted to mean glossary support is disabled. The name parameter SHOULD include the following label values set as prescribed: GlossAlt01 Alternate glossaries for a glossary program to chain (through) to if it can not find a word in its database. It SHOULD GlossAlt05 contain the query sting used to invoke the outside glossary to lookup the term. It MAY contain a set of values denoting more subtle limitations. In any case, an empty string MUST be interpreted to mean there is no glossaary at this alternate number or at any higher alternate numbers. The label names MUST be case sensitive. section 10 -------------------- CUF(tm) Code Tags The central formatting mechanism used in CUF(tm) are formatting TAGS. A format tag is a human-understandable bracketed code that tells the CUF interpreter how to format a given part of a CUF-compliant message. They are very similar to HTML tags, sometimes even using the same name as the HTML tag with the same function. The main difference in the appearance of CUF(tm) tags vs. HTML tags is that they start and end with square brackets instead of angle brackets. An example of a CUF(tm) formatting tag is the [br] (line-BReak) tag. It tells the CUF interpreter to insert codes into the text of the message that will cause a line-break in the native display system. In the case of HTML this would insert an HTML "BR"eak tag into the text when it is displayed. Note that it has the same name as the HTML tag but begins and ends with square brackets instead of angle brackets. CUF(tm) codes are case-insensitive by default, though future CUF tags and "extension tags" MAY use case to discern sub-functions of a given function. For a categorized, HTML formatted table with the entire list of CUF(tm) codes in this (version 1.0a) release of the standard see the document entitled CUF(tm) Code List v1.0a (filename: CUFcodes.htm). In the following list an elipse means that there MAY be other text included within the syntax of the tag. Formally this is defined as .*? in Perl Regular expressions. The information represented by the elipse is optional and MUST be consistent with the form of the tag if included. The following list presents the standard tags, the compliance level for each tag, and a brief description of the tag's function. - - - - code: [A...] [/A] level: CORE Anchor tag. Make text between tags an HTML anchor (link). Works the same as the HTML A tag. Capability MAY be limited by the application or deployer. code: [b] [/b] level: CORE Bold text. Make all text between [b] and [/b] bold. code: [background:..] level: IMPLEMENTATION Background IMAGE tag. Set the background image to display behind the text of the current message or its web page (depending on application). Capability MAY be limited by the application or implementer. code: [bgcolor:...] level: IMPLEMENTATION Background color tag. Set the background color of the the message area for this message or its web page (depending on application). Capability MAY be limited by the application or implementer. code: [bgfixed] level: IMPLEMENTATION Background IMAGE FIXED tag. Stipulate that the background image is fixed (so the text of the message scrolls over it on Internet Explorer). Capability MAY be limited by the application or implementer. code: [br] level: CORE BRreak tag. Insert a line-BReak into the document. Works the same as the HTML BR tag. code: [button...][/button] level: TOGGLE Button tag. Define a button control within a form. Works the same as the HTML BUTTON tag. Capability MAY be limited by the application or implementer. code: [center] [/center] level: CORE Center tag. Display text between them centered. Works the same as the HTML CENTER tag. code: [code] [/code] level: CORE Code tag. Display code as formatted. Works the same as the HTML CODE tag. code: [color=...] [/color] level: CORE Change color Make all text between them the specified color (e.g. [color=red]this will display in red[/color]) code: [comment] [/comment] level: CORE Comment tags. These tags and all information between them MUST NOT be displayed or in any way displayable after the message has been processed by the CUF(tm) interpreter. This is for comments that are only visible to the USER editing the CUF(tm) message. code: [cr] level: CORE Copyright symbol. Insert a copyright symbol (a 'c' in a circle) into the document. code: [cuf] level: CORE Display CUF(tm) as a hyperlink that, when clicked, leads to the main CUF information page at http://www.Creativyst.com/Doc/Std/CUF/. This tag MUST be included in any implementation or application that uses any CUF related material that Creativyst, Inc holds copyright or trademark rights to. This includes all documentation, code, or other materials at or below http://www.Creativyst.com/Doc/Std/CUF/v10a code: [div] [/div] level: IMPLEMENTATION Div tag. Produce an HTML division. Works the same as the HTML DIV tag. code: [e2e] level: IMPLEMENTATION Edge to edge (or "bleed") tag. Set the current message to bleed to the edge of the message area or web page (depending on application). Capability MAY be limited by the application or developer. code: [f#] [/f] level: CORE font SIZE tag. Make font between them the size specified by '#'. The # is the HTML 1 through 7 font sizes and has the same meaning. code: [fieldset...][/fieldset] level: TOGGLE Button tag. Define a button control within a form. Works the same as the HTML BUTTON tag. Capability MAY be limited by the application or implementer. code: [font ...] [/font] level: TOGGLE font tag. Works the same as the HTML FONT tag. Capability may be limited. code: [form...] [/form] level: TOGGLE Form tag. Define and entry form between the tags. Works the same as the HTML FORM tag. Automatic line break formatting is disabled between these tags. Capability MAY be limited by the application or implementer. code: [glossary=...] level: TOGGLE Glossary term tag. Produce a hyperlink of the term after the equals sign. The hyperlink produces a glossary entry for the term when it is clicked. code: [hr...] level: CORE Horizontal rule tag. Insert a horizontal rule into the document. Works the same as the HTML HR tag. code: [hr###] level: OBSOLETE Centered horizontal rule tag. Where ### is a number from 1 to 100. Insert a centered horizontal rule that is ### percent of the width of the message area (or enclosing tag). Currently obsolete, but is that the correct path? Implementers SHOULD implement these for now until more feedback is collected. code: [hrR###] level: OBSOLETE Right aligned horizontal rule tag. Where ### is a number from 1 to 100. Insert a right aligned horizontal rule that is ### percent of the width of the message area (or enclosing tag). Currently obsolete, but is that the correct path? Implementers SHOULD implement these for now until more feedback is collected. code: [hrL###] level: OBSOLETE Left aligned horizontal rule tag. Where ### is a number from 1 to 100. Insert a left aligned horizontal rule that is ### percent of the width of the message area (or enclosing tag). Currently obsolete, but is that the correct path? Implementers SHOULD implement these for now until more feedback is collected. code: [http:...] [/http] level: CORE HTTP tag. Make the URL between the two tags a hyperlink. Capability MAY be limited by the application or implementer. code: [img:...] level: OBSOLETE Alternate (Obsolete) Image tag. Insert the image denoted by the link after the colon. Capability may be limited by the application or implementer. Should not be used in new projects. Should NEVER be documented. May not be supported in future versions. code: [input...] level: TOGGLE Input tag. Define an input control within a form. Works the same as the HTML INPUT tag. Capability MAY be limited by the application or implementer. code: [i] [/i] level: CORE Bold text. Make all text between them italic. code: [img ...] level: TOGGLE Image tag. Insert an image into the message document. Works the same as the HTML IMG tag. Capability may be limited by the application or implementer. code: [img] [/img] level: TOGGLE Image tag. Insert the image denoted by the link between the two tags. Capability may be limited by the application or implementer. code: [legend...][/legend] level: TOGGLE Legend tag. Define a legend control within a form. Works the same as the HTML LEGEND tag. Capability MAY be limited by the application or implementer. code: [label...][/label] level: TOGGLE Label tag. Define a label control within a form. Works the same as the HTML LABEL tag. Capability MAY be limited by the application or implementer. code: [Li...] [/Li] level: CORE List Item tag. Insert a List Item into a list in the document. Works the same as the HTML LI tag. code: [Link=...] [/Link] level: IMPLEMENTATION Link internal tag. Make the text between the tags a hyperlink to an internal message. Denote the message to link to by implementation specific means after the equals sign. code: [List] [/List] level: IMPLEMENTATION Begin an un-ordered bullet list in the output display. Use [li] tags to denote bullet points. code: [List=...] [/List] level: IMPLEMENTATION Begin an ordered or un-ordered bullet list in the output display. Use [li] tags to denote list items. code: [Marquee...] [/Marquee] level: CORE Marquee tag. Display text between tags as a scolling marque. Works like the non-standard HTML MARQUEE tag. MAY be limited to work only in clients that support the <Marquee> tag. code: [nobr] [/nobr] level: CORE Suppress automatic break insertion. Normally, CUF will replace a single line- fee by itself with a BReak tag and multiple line-feeds together into a single Paragraph tag. That behavior will be suppressed for all text between these two tags. code: [nopagetitle] level: IMPLEMENTATION No Page Title tag. Stipulate that the no extraneous titles, toolbars, or header information be included with the message. Only the message alone should be displayed when this tag is included. Capability MAY be limited by the application or implementor. code: [oL...] [/oL] level: CORE Ordered List tag. Begin an Ordered List in the document. Works the same as the HTML OL tag. code: [option...] [/option] level: TOGGLE Option tag. Define an option control in a select control within a form. Works the same as the HTML OPTION tag. Capability MAY be limited by the application or implementer. code: [optgroup...][/optgroup] level: TOGGLE Optgroup tag. Define an optgroup control in a select control within a form. Works the same as the HTML OPTGROUP tag. Capability MAY be limited by the application or implementer. code: [p] level: CORE Paragraph tag. Insert a paragraph break into the document. Works the same as the HTML P tag. code: [pagecounter] level: IMPLEMENTATION Page Counter tag. Insert a TEXT based counter in the message to display the number of times this message has been viewed or this page has been visited. The counter should track the last IP address to have bumped it in order to avoid repeated bumps by the same viewer. Capability MAY be limited by the application or implementer. code: [pre] [/pre] level: CORE pre tag. Display PRE-formatted text. Works the same as the HTML PRE tag. code: [rj] [/rj] level: CORE Right Justify tag. The text between these tags will be right justified. code: [rtm] level: CORE Registered Trademark symbol. Insert a REGISTERED trademark symbol (an 'r' in a circle) into the document. code: [script...][/script] level: IMPLEMENTATION Script tag. Define or include a script between the tags. Works the same as the HTML SCRIPT tag. Capability MAY be limited by the application or implementer. code: [sec2] [/sec2] level: IMPLEMENTATION Members Only text. The text between these two tags will normally be eliminated from displays. It will only be made visible to other members (or authorized users). code: [select...] [/select] level: TOGGLE Select tag. Define a select control within a form. Works the same as the HTML SELECT tag. Capability MAY be limited by the application or implementer. code: [sp] level: CORE Produce a hard space. Creates a non-breaking space (hard space) in the output display. code: [sp##] level: CORE Produce a specified number of hard spaces in the translated message. ## is a number between 1 and 99 which specifies the number of hard spaces to display. code: [sp=##] level: CORE Produce a specified number of hard spaces in the translated message. ## is a number between 1 and 99 which specifies the number of hard spaces to display. This has the same function as [sp##]. The equal sign version is included for consistency with other tags that use the equal sign. code: [spL] [/spL] level: CORE While between these two tags, make all spaces found at the beginning of lines into hard spaces. That is, convert leading space to non-breaking spaces. (Note: the case of the 'L' is not important, and is only in uppercase here for clarity). code: [st] [/st] level: CORE Strike through text. Make all text between them strike through. code: [style..][/style] level: IMPLEMENTATION Style tag. Define CSS styles between the tags. Works the same as the HTML STYLE tag. Capability MAY be limited by the application or implementer. code: [sub] [/sub] level: CORE Sub tag. Display text between them as sub-script. Works the same as the HTML SUB tag. code: [sup] [/sup] level: CORE Sup tag. Display text between them as super-script. Works the same as the HTML SUP tag. code: [table...] [/table] level: TOGGLE Table tag. Make table row, header, and cell definition between the tags. Works the same as the HTML TABLE tag. Automatic line break formatting is disabled between these tags. Capability MAY be limited by the application or implementer. code: [textarea..][/textarea] level: TOGGLE Textarea tag. Define a text area input control within a form. Works the same as the HTML TEXTAREA tag. Capability MAY be limited by the application or implementer. code: [textcolor:...] level: IMPLEMENTATION Foreground color tag. Set the foreground color of the text for this message or its web page (depending on application). Capability MAY be limited by the application or implementer. code: [td...] [/td] level: TOGGLE Table Header tag. Define a table data cell between the tags. Works the same as the HTML TD tag. Capability MAY be limited by the application or implementer. code: [th...] [/th] level: TOGGLE Table Header tag. Define a table header cell between the tags. Works the same as the HTML TH tag. Capability MAY be limited by the application or implementer. code: [threadflip] level: IMPLEMENTATION Flip Thread tag. Works in concert with the threadpage tag. Specifies that the BBS thread created be listed in reverse order (most recent comments first). Capability MAY be limited by the application or implementer. code: [threadpage] level: IMPLEMENTATION Thread Page tag. Cast the current message area or web page as a simple Bulletin Board System where visitors can contribute comments to a linear conversation Capability MAY be limited by the application or implementer. code: [tm] level: CORE Tradmark symbol. Insert a trademark symbol (a small 'tm') into the document. code: [tr...] [/tr] level: TOGGLE Table Row tag. Define a table row between the tags. Works the same as the HTML TR tag. Capability MAY be limited by the application or implementer. code: [u] [/u] level: CORE Underlined text. Make all text between them underlined. code: [uL...] [/uL] level: CORE Un-ordered List tag. Begin an Un-ordered List in the document. Works the same as the HTML UL tag. code: [url] [/url] level: CORE Alternate Url tag. Make the URL between the two tags a hyperlink. Capability MAY be limited by the application or implementer. code: [url=...] [/url] level: CORE Url tag. Make the text between the tags a hyperlink that leads to the url specified after the equals sign. Capability MAY be limited by the application or implementer. code: [whiteboard] level: IMPLEMENTATION Whiteboard tag. Specifies a message area that allows non-users (or non-members or outsiders, etc) to have group editing ability over whatever message or page content is in that area. An example of this is an application that specifies a web page where non-members can collectively make edits to it. Capability MAY be limited by the application or implementer. code: [{] level: CORE Display an Open bracket. This will be replaced with a single open bracket in the displayed message. This can be useful in messages that describe CUF(tm) codes themselves. If the open bracket of the code is replaced with this code it will not be interpreted as a CUF code. That is, it will be displayed in the message instead of interpreted as a CUF code. code: ['] level: CORE Null tag. Do nothing. This tag will be replaced with nothing. You would not think that a tag that does nothing would be very useful. In fact it can be very useful. For example, a user can prevent a bare html link from being converted into a hyperlink like this htt[']p://a.link.com. This will show up in the displayed message as http://a.link.com without being converted to a hyperlink. There are other uses for a null tag but this is not the place to discuss them. IMPLEMENTERS: This link MUST be processed AFTER other links and interpretations have been completed. This is to insure that CUF text interpretation can be overridden by the inclusion of this link. code: [!-- --] level: CORE HTML Comment tags. These will insert an HTML open and close comment tag respectively into the displayed message. In browser-based display applications such information will not show up on the browser, but will still be available when the USER selects "view source" from the browser's menu. code: [*]...[*****] level: OBSOLETE Un-numbered Bullet List tags from one to five hierarchical levels. Currently obsolete, but is that the correct path? Implementers SHOULD implement these for now until more feedback is gleaned. code: [.]...[.....] level: OBSOLETE Numbered Bullet List tags from one to five hierarchical levels. Currently obsolete, but is that the correct path? Implementers SHOULD implement these for now until more feedback is gleaned. Section 11 -------------------- CUF(tm) Licensing CUF is an openly SHARED standard and trademark of Creativyst, Inc. To put it in simplified form, the agreement below states that we will allow any individual or organization to use this standard and trademark without cost, whether for profit or non-profit purposes, including competing products, as long as they meet our minimal restrictions and requirements as documented here and with the other components. We maintain only limited control over the standard (hence the word "shared" instead of "open"). This control seeks mainly to protect the standard from becoming cumbersome or ambiguous and to promote it as widely as possible. The requirements also impose some very minimal ethical requirements which we think most people will be comfortable with. These simply seek to deny access to a small group of bad players, such as child pornographers, and employee-hostile organizations. If you are implementing a CUF(tm) interpreter, you MUST certify it within six months of distribution. Certification requires you to register the code for your implementation which will be shared at the CUF site. You may withdwawl your implementation at a later date but must not refer to this standard if you do. The actual trade-mark symbol may be substituted wherever you see "(tm)" in the text of this standard and notices. Section 12 -------------------- License to use this document This document is: (C) Copyright 2002, Creativyst, Inc. ALL RIGHTS RESERVED You may use and freely distribute this document containing the CUF(tm) standard and entitle "Creativyst Universal Format (CUF-tm) Code Standard (v1.0a)" provided: 1. You distribute it complete and unchanged from its original form, inluding all licensing notices. 2. You MUST NOT distribute any derivative works you may produce. Section 13 -------------------- License to use the CUF(tm) Trademark for Applications You may use the term CUF or Creativyst Universal Format(tm), or Creativyst Universal Formatters(tm) in reference to an APPLICATION that includes an implementation of the CUF(tm) standard provided: 1. You download and use one of the open source implementations distributed on Creativyst, Inc's website at www.Creativyst.com in accordance with the copyright. 2. If your application includes proprietary formatting functions they must meet the requirements documented in the section of this standard entitled "DEVELOPER Defined Tags in CUF(tm)" This is the easiest way to include CUF functionality within your application because all the code needed to meet the requirements of the standard is already written for you. In order to use the code of course you are required to adheer to the copyright requirements as well. You may also write your own implementation. Since part of that process requires you to share the CUF() code here on the site, the requirements listed here will continue to apply in such a case. Section 14 -------------------- License to use the CUF(tm) Trademark for Implamentations You may use the term CUF(tm) or Creativyst Universal Format(tm), or Creativyst Universal Formatters(tm) to refer to an IMPLEMENTATION of the CUF(tm) standard provided: 1. You include all CORE-LEVEL CUF(tm) tags implemented as described in the CUF(tm) standards document entitle: "Creativyst Universal Format (CUF-tm) Code Standard (v1.0a)"and 2. You comply with all other requirements defined by the CUF(tm) standard document entitle: "Creativyst Universal Format (CUF-tm) Code Standard (v1.0a)" 3. You include the line-formatting conventions described in the CUF(tm) standards document and 4. Your application or implementation includes credit to Creativyst, Inc. in any documentation that references CUF(tm) and you include the phrase "Creativyst Universal Format". Alternatively you may include the phrase CUF(tm) hyperlinked to the Creativyst CUF(tm) documentation page at http://creativyst.com/Doc/Std/CUF/ in your document. This hyperlink will in itself satisfy the requirement above to give credit to Creativyst, Inc. for the standard used while not crowding your brand. 5. You include this copyright and trademark usage notice somewhere in the application or implementation documentation (hardcopy or electronic). 6. You upload your implementation for distribution on Creativyst's CUF(tm) website, and grant permission for it to be distributed under the terms of Creativyst Inc's CUF(tm) trademark and copyright agreements. 7. You and your company meet the ethical requirements printed below under the heading "Ethical Requirements for Licensing Creativyst Intellectual Property" You must include this copyright notice in user documentation. You must include the trademark symbol at least once when referring to CUF(tm). This is required by this license for any instance of the application or implementation that claims compliance with the CUF(tm) standard. You may not claim CUF(tm) compliance without including this notice. This license is granted to users of this version (v1.0a) of the CUF(tm) standard non-exclusively and regardless of whether it is to be used for personal or commercial purposes. All other rights to this standard and to the use of the term CUF(tm) to refer to message formatting methods are reserved by Creativyst, Inc. Section 15 -------------------- License to use the CUF(tm) Help Pages You may use the CUF(tm) help pages, such as the table of codes, and works you derive from them as part of your application or implementation provided: 1. These and derivative works include the copyright notice as it appears at or near the bottom of the page. It can be placed directly above or below your own copyright notice in the case of derivative works. You may say "parts of this document" or something similar ahead of the Creativyst copyright notice. 2. The title of such works includes one of either the phrase "Creativyst Universal Format" or the phrase "CUF(tm)". If the phrase CUF(tm) is used in place of the phrase that mentions Creativyst explicitly the entire phrase "CUF(tm)" (including the trademark symbol) must be hyperlinked to the CUF(tm) documentation page at: http://creativyst.com/Doc/Std/CUF/ 3. You and your company meet the ethical requirements printed below in the section entitled "Ethical Requirements for Licensing Creativyst Intellectual Property" Section 16 -------------------- License To Use Provided CUF(tm) Interpreters You may use any of the implementations of the CUF(tm) standard interpreter that may be provided for download at the Creativyst CUF(tm) documentation area at or below: http://creativyst.com/Doc/Std/CUF/ with limitations as discussed in this notice. note: The text printed here in the standard is INFORMATIONAL, and provides an overview of the actual license agreement which is included with the download of each implementation and which supersedes anything in the text of this section. Permission to Use the Implementation: Permission to use the interpreter is granted for commercial and non-commercial purposes to enhance END-USER applications with these limitations: 1. The original copyright notice (this notice) must be reproduced and distributed with the application and 2. Any documentation of CUF(tm) functionality within the application credits the Creativyst Universal Formatting (CUF-tm) Code standard. Web-based online documentation may credit CUF(tm) without explicitly mentioning Creativyst if it includes the trademark symbol and if the entire phrase ("CUF" and the trademark symbol) is hyperlinked to the Creativyst Universal Format Codes page at: http://creativyst.com/Doc/Std/CUF/v10a/index.htm. 3. If code is distributed the copyright notice included with the original code must be included in its original form in the code. 4. you meet the ethical requirements printed below in the section entitled "Ethical Requirements for Licensing Creativyst Intellectual Property" (Section 17) Derivative works that meet the above requirements are permitted: if derivative works carry this original copyright notice as well as all derivative author's copyright notices. This notice must be included unchanged with the code. Copyright notices should always be dated. Newer copyright notices should be placed OVER earlier copyright notices on derivative code and older notices should be left completely unchanged. The original notice must be referenced and rights must be granted as they are granted in the original code. Copyright notices for derivative works should be kept brief and must not restrain rights to the derived work to be more restrictive than rights to the original work. Section 17 -------------------- Ethical Requirements for Licensing Creativyst Intellectual Property Among other requirements, Creativyst, Inc. imposes these specific ethical requirements on any and all rights to use its intellectual property. Anyone who does not meet these requirements are explicitly excluded from any rights to use intellectual property held by Creativyst, Inc. 1. You must not traffic in child pornography or slavery Any company, individual, or organization involved in or that has previously been involved in the production or distribution of child pornography or slavery does not meet the ethical requirement to use intellectual property rights held by Creativyst, Inc. 2. You must not practice terrorism Any company, individual, or organization involved in terrorist acts does not meet the ethical requirement to use intellectual property rights held by Creativyst, Inc. 3. You must observe ethical labor practices You must not perform unfair labor practices such as blocking the distribution (payout) of 401K funds rightfully owed to past or current employees, improperly taxing or charging those in your employ, or employing children who have been deemed by your local authorities as being too young to safely perform the work. 4. You must not traffic in illegal drugs or finance known sources. If you distribute illegal drugs, raw materials for specific use in the production of illegal drugs, or you finance known sources of such materials (including governments who export them) you are excluded from any rights to use intellectual property controlled by Creativyst, Inc. Note that this does NOT limit those who personally USE illegal drugs. This only limits those who produce for distribution, distribute, or finance known producers and/or distributors of illegal drugs. --------- --------- --------- --------- --------- ---------