JSAPPCATCHE 0.0 INTERNET DRAFT Jason Robinson Title: draft-jsappcatche-2010.txt Kitchen Pages, computer software. Expires: September 2011 October 2010 JSAppCatche for end use applications JSAppCatche and Configuration JSAppCatche Working Draft October 2010 Latest Editor's Draft: http://www.kitchenpages.com/library/xsrodomcs/ This version: http://www.kitchenpages.com/help/i3/draft-jsappcatche0-2010.txt Latest version: http://www.kitchenpages.com/library/xsrodomcs/ Version history: Differences between the last published draft and this document. Differences between latest editor's draft and latest version. Editor: Jason Robinson Copyright © 2010 Kitchen Pages ®, All Rights Reserved. Trademark and document use rules apply. -------------------------------------------------------------------------------- Abstract This specification standardizes a format for software process known as JSAppCatche store. JSAppCatche is a client-side application that supports Web standards such as HTML5 to be stored and embedded into Web documents. The specification relies on Emac626 specification as the client-side JavaScript format language processor, and a series of steps that runtimes follow when processing and verifying various aspects of a store. Pre-Packaging into a format acts as a container for data used by a store. The configuration document that contains any vocabulary which declares Function, Procedure or configuration parameters for a Runtime environment. The steps for processing a store describe the expected behavior for runtimes while processing the store. This specification is part of the KitCAD software family of technology topography, which together standardize current public release website uses as a whole. Status of this Draft Document This document may not be modified, and derivative works of it may be created. This document may only be posted in an Internet-Draft for information uses. The text found in this document when completed will be translated into a web HTML format for web browser viewing - draft is in text. Publication as a Working Draft does not imply endorsement by the Kitchen Pages, computer software or Jason Robinson. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. Feedback based on any aspect of this specification is welcome and encouraged. This document is produced by Jason Robinson for Kitchen Pages and computer software. The public is encouraged to send comments to the Author. Changes Since Last Publication Inital publication, No Changes. If you have implemented a previous draft, then you should read this section carefully as it could potentially affect your implementation. Table of Contents {TOC} 1. Introduction This section is non-normative. A Store is a client-side runtime authored using Web standards such as [HTML5] and accessed using client-side runtime such as JavaScript. A Store can be downloaded and installed on a client machine or device where they run as stand-alone store/s, but they can also be embedded into Web pages and run in a Web browser. Examples range from simple catche, data history, news dates, to complex applications that pull data from multiple sources to be "mashed-up" and presented to a user in some interesting and useful way (see [JavaScript Search] for more information). 1.1. Design Goals and Requirements This section is non-normative. The design goals and requirements for this specification are documented here in this document. 1.2. How This Document is Organized This section is non-normative. This document is organized into two halves, but not explicitly marked as such. The first half defines the various aspects of what constitutes the store format. Where possible, the first half avoids describing aspects related to processing, which are described in detail in the second half of the document. 1.3. Typographic Conventions This section is non-normative. This section defines the typographical conventions used by this specification. Some text in this specification is non-normative. Non-normative text includes: sections marked with the text This section is non-normative, authoring guidelines, examples, eg, and notes. Everything else in this specification is normative. Defined terms appear as this sample defined term. Such terms are referenced as sample defined term, providing a link back to the term definition. Words that denote a conformance clause or testable assertion use keywords from [RFC2119]: must, must not, should, recommended, may and optional. The keywords must, must not, should, recommended, may and optional in this specification are to be interpreted as described in [RFC2119]. Variables are formatted specially, e.g. variable. Code is also specially formatted, such as code. Words in italics denote a formal definition given in an external specification. This is an example. Examples are used to explain concepts or demonstrate how to use a feature. Examples are non-normative. Note: This is a note, it usually contains useful supplementary information in a non-normative form. Authoring Guidelines: This is an Authoring Guideline. Its purpose is to provide authors with best-practice authoring techniques. Authoring guidelines are non-normative. 1.4. The JSAppCatche Family of Specifications This section is non-normative. This specification is part of the KitCAD family of specifications, which together standardize runtime as a parts. 2. Conformance Any class of product can claim conformance to this specification. Note: Implementers can partially check their level of conformance to this specification by successfully passing the test cases of [C++Builder]. 3. Definitions The following terms are used throughout this specification so they are gathered here for the readers convenience. The following list of terms is not exhaustive; other terms are defined throughout this specification. Arbitrary means that a character, or text string, or file-name, or folder-name is not reserved for the purpose of this specification. A author is a person who is using a store or an authoring tool that generates or uses a store. A programmer is a person who created a store or an authoring tool that created a store. Initialization means a user agent procedurally stepping through the steps for processing a store, or store command. A language tag is a text string that matches the production of a Language-Tag defined in the [BCP47] specifications. A media type is defined in the [MIME] specification. Reserved means that a character, or text string, or file-name, or folder-name has a specified purpose and semantics in this specification or in some other specification or system. The intended purpose for any reservation is given when the term is used. Supported means that a user agent implements a mentioned specification, or conformance clause, or is able to process or otherwise render mentioned media type. Unsupported means the user agent does not implement a mentioned specification, or feature, or is unable to render or otherwise process a mentioned media type. A store is defined by the [JSAppCatche] as an end-user's conceptualization of an interactive single purpose application for re-displaying and/or updating local data or data on the Web, processed in a way to allow a single download and execution on a user's machine, or Internet-enabled runtimes. Because a store can be packaged it can also support post and get methods of [HTML] for shared use by users without relying on [HTTP]. 3.1. Character Definitions This section groups common sets of [Unicode] code points into definitions for the purpose processing in this specification. The space characters are code points: U+000A LINE FEED (LF), U+000C FORM FEED (FF), U+000D CARRIAGE RETURN (CR). The Unicode white space characters are code points marked in the [Unicode] specification with the property "White_Space", including: U+2028 LS (LINE SEPARATOR) U+2029 PS (PARAGRAPH SEPARATOR) 4. User Agents A user agent is an implementation of this specification that also supports [HTML], [C++], or [PASCAL]. In addition to a store, a user agent may support other legacy and proprietary application store and packing formats. It is optional for a user agent to support the optional aspects of the store RESERVED specification. Note: The user agent described in this specification does not necessarily denote a "store user agent" at large: that is, a user agent that implements all the specifications, and dependencies, defined in the JSAppCatche Family of Specifications. The user agent described is this specification is only concerned with how to processes store and configuration documents. 4.1. Optional Aspects of JSAppCatche store Specification (RESERVED) The optional aspects of the RESERVED specification are as follows. These aspects represent general features defined in the store specification that this specification does not make use of, and could apply to the store without RESERVED use, which advanced examples could be as follows: Language or logic. Code and Translation. Process and String of data. Cookie and data store. Package and API interface. Syndication and filter. AJAX and server-side communication reply. Compression or decompression algorithms. Encoded or Decoded. Decryption methods. EncodeURI or DecodeURI methods. Digital signature methods. Restriction, License, Patent aspects. Security or validation. Catche and XML document management. Existing methods, runtime, or data. 4.2. The dir Attribute A keyword attribute used to specify the directionality in which human-readable text is to be represented by a user agent (e.g., the text content of the name element, the description element, and the license element). The directionality set by the dir attribute applies to the store content and any attributes of the store where it is used, and to child elements in its content unless overridden with another instance of dir (i.e., in this specification, the dir attribute only affects the user client-side store element). 5.0. The JSAppCatche store [DIV] Element and its Attributes The store div element serves as a container for the other form based store elements, processes, or data of the configuration document. Context in which this element is used: The client-side store [DIV] element is accessable though the root element of a configuration document. Occurrences: Exactly one id, accessable from the root element of the [HTML] document. 5.1. The JSAppCatche store [DIV] id Attribute A DOM attribute that denotes an identifier for the store form to be generated by the jsappcatche.js onload function. Authoring Guidelines: programmers MUST use the id attribute with a store [DIV] element of appcatchestoresplaceholder if running jsappcatche.js runtime. The Scripting element loading the jsappcatche.js runtime MUST be added AFTER the store [DIV] element. If no store [DIV] element is accessable from the root of the [HTML] document then a new store [DIV] element may be generated by the jsappcatche.js javascript example. 6.0 The store Specificaiton in example use http://www.kitchenpages.com/library/i3/KitCAD225_kgc_exploit_function_catche.htm 6.1 The store Specification in use http://www.kitchenpages.com/library/i3/KitCAD225_kgc_exploit_function_catche.htm http://www.kitchenpages.com/search 7.0 The basic text store Specificaiton internal format Store Identifier:- KGraphicControl.QuickPaint(true, 0, 0)[250][250][250][C:\Program Files\Kitchen\Objects\BC2di_1000w_600d_903h_0hf.kpd] Store value:- document_message(Canvas.Draws_def); Width = 250; Height = 250; kpdsquare = 250; atmovex = -137; atmovey = -82; Fmovex = 0; Fmovey = 0; Store terminator:- ---appcatche--- Store delimiter:- \r\n Reserved for future uses:- RESERVED Escape modification:- " If compiled by JavaScript; The store formula required MUST be :- document.writeln( Store Identifier + "Store delimiter" + Store value + Store terminator + RESERVED + "Store delimiter" ); The Store terminator example applied by the appcatche.storen function call does not need to be ---appcatche--- followed by a RESERVED space and a Store delimiter as it could be exchanged for two or more astric symbols like ** or another kind of terminator identifier. Use of jsappcatche.js script provides automatic use of the default Store terminator ---appcatche--- followed by RESERVED space and CRLF (\r\n, \xD0\xA0, or \u000D\u000A). The Store terminator is removed from the last line of a string that is returned during a appcatche.exestr function call. 7.1 The RESERVED store Specification The RESERVED space provides programmers, authors, server-sides, and user clients the ability to double store size of the last line; inclusive of re-pre-processing a store, or acting as a store collecting [AJAX] data, or other server-side communicaiton request method/s and response. Inserting data between the \r and \n escaping that is the jsappcatche.js Store delimiter can also yeld simmilar results but may cause un-known results on systems that use \n \n escape or other escape methods not listed by this specification. See 4.1 for detailed description of general store uses not detailed here. 7.2 Example; Using jsappcatche.js to manage the JavaScript optimise with DOM storage String appcatche.catchstr as Store Identifier void function appcatche.catchstore (Store value as String) Creates Sender value/s within store void function appcatche.catchstoren (Store Identifier as String) Creates a new store for the Sender void function appcatche.catchstored () Closes a new store for the Sender bool function appcatche.ifstr (Store Identifier as String) returns bool Searchs store, and if found returns a value of true as bool to Sender String function appcatche.exestr (Store Identifier as String) returns String Splits store and returns matching value/s as string to Sender void function appcatche.clearstore () Clears all identification and value/s within store void function appcatche.usestore (bool, bool) Set store mode to true or false for allowing this kind of mode change override; Store mode should always be set to true Set store function appcatche.ifstr return bool as override to always be true or false 7.3 second store example note To run a second appcatche.catchstoren before the end of appcatche.catchstored requires the use of appcatcheli.catchstoren, appcatcheli.catchstore and appcatcheli.catchstored from jsappcatcheli.js Rest of text is missing! .... refer to w3 and other standards .... © Copyright 2004 Kitchen Pages, Jason Robinson. All Rights Reserved, modified and additional text. Author's Address Jason Robinson http://www.kitchenpages.com/feedback.html Please send comments to the author at the above address. This Referance, if any; will be: draft-jsappcatche0-2010.txt Next Referance, if any; will be: draft-jsappcatche1-2010.txt Support other Referance, if any: draft-jsappcatche0-2010.txt Previous Referance, if any; was: NONE-n/a RCS: $Id: draft-jsappcatche0-2010.txt,v 0.0 2010/10/01 00:00:01 markd Exp $