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