|
a r t i c l e s  >
s c a t d r a f t v 0 . 1
summary SCAT is short for Scope Controlled Data. It is intended to be an extensible format for data files. It is intended to be less verbose, more flexible, and more readable than XML. For more info, read the intro to SCAT. This is a very preliminary draft of what a SCAT file should be like, and what the special headers and objects consist of. scat headers The beginning of a scat file must contain headers, with no blank lines between them. The first few lines are read in, and the first blank line seperates the scat header with the scat file. The scat headers contain information about how the scat file is encoded, how characters should be displayed in a browser or text editor, information about boundaries, and about the public key that the scat file was encoded with.
scat.encoding=iso-8859-15 (default), or stuff like UTF-8. Also
supports zip, gzip, or encryption protocols (pgp), or
multiple encodings ("uu zip pgp" for a file that was
pgp encoded, then zip encoded, then uu encoded)
scat.encoding.magic= here goes a 'magic string' which is encoded
uniquely for each supported encoding. This magic string will
validate that the encoding claimed above is correct.
scat.charset=
scat.pgp.public-key=
scat.boundary=
scat.user=
scat.password=
scat.password.encoding=
scat objects All items in a SCAT file are SCAT objects, which are similar to objects in a scripting language. Such as the Zend object in PHP, or the VARIANT object in VB Script. This SCAT object can have several types, with several default attributes, described below: scat.DUMP scat.DUMP.boundary scat.DUMP.content-type scat.DUMP.content-length scat.DUMP.content-disposition scat.DUMP.encoding scat.TABLE scat.TABLE.boundary scat.HASHTABLE scat.HASHTABLE.boundary scat.LIST scat.LIST.boundary scat.TEXT scat.TEXT.content-disposition scat.ID scat.LINK scat.DATE scat.LONG scat.FLOAT scat.CLASS All objects have the concept of a boundary, which happens on both sides of a dump. It is usually desirable to use a large boundary for DUMP objects, which contain random and unpredictable binary data. Boundaries for TABLE, LIST, or TEXT objects can be smaller, as long as they dont exist in the text. In general, if a computer is generating the scat file, it should generate large boundaries for all things. If a use is making his own scat file by hand, small boundaries can be used. A hashtable that only has name-value pairs can be very easily generated with this system. If a more exotic object is included in the hashtable, the LINK and ID mechanism can be used to reference any other object in the SCAT file. scat syntax The basic syntax is one of name-value pairs seperated by equals signs '=', each on their own line. If the line starts with a hash '#' it is ignored as a comment. Blank lines are also ignored. The key to SCAT is the scoping of objects to parent objects. This is done with the dot '.', which is a fairly common scoping mechanism in programming languages. Back-scoping can be done with double dots '..', as well as forward slashes '/'. This kind of scoping should be familiar with anybody who uses a file system. An example SCAT file is below: # no '=' sign, so its an object bla.foo.bar #scoped to last object, 'bla.foo.bar' .a1=x1 .a2=x2 #back scoped to make object 'bla.foo.bar2' ..bar2 .b1=y1 .b2=y2 # back scoped to make FILE object 'bla.foo2', with a content # type, and a boundary ../..foo2=scat.FILE .content-type=text/plain -----12345 some data -----12345 # back scoped to make TABLE object 'bla.foo3', with a boundary. # the first line in the table is the number of columns ..foo3=scat.TABLE -----12345 2 a1 a2 b1 b2 c1 c2 -----12345 |