These are strategies which are unlikely to work out for us, stored here for reference and inspiration. Go back to Talk:Table.
Unlikely: Tables by separated lists whose relationship is defined by matching names
Looking at the problem from the point of view of requiring named semantics makes the old strategy of having several lists look not so bad after all. We need to define dependencies between lists so that deleting the uniform from the _list_members also deletes all the extra information from depending lists like avatars, speak actions and moderator rights. So the approach could be to have the structure implicit, by defining a psycmatch relationship between the lists. We have a list of uniforms in _list_uniform_members, we have a _list_action_speak_members and a _list_moderation_members. We can define that the psycmatching _members actually brings all these lists together. By deleting a uniform from _list_uniform_members we also delete the same row from all other lists. We can even delete all member using a certain speakaction, or remove all passive listeners of a moderated chat at the end of the event, possibly like this:
-_list_voice_members _listener
Advantages:
- No new syntaxes necessary
- / and * operators not necessary as + and - already provide that
- psycmatch is probably simpler than a special syntax (see below)
Disadvantages:
- Adding a new row to the table is cumbersome as you have to send a + for each list (each table columns) rather than having a unified + syntax as full-blown table syntaxes would permit.
- Also, if the actual creative part of the variable names is somewhere in the middle, the keyword _members hardly ever has a chance to be compacted, even if it normally would.
<fippo>: i highly dislike psycmatch. Sleeping does not help. It is just a broken concept. _list_members and _list_members:attribute are much more readable.
How does it look like, when you need to change a particular field of a particular member?
- A mess. You probably need to delete her entry, then reassign it with a whole bunch of plusses. Alternatively we introduce a syntax to both add a row to all lists at once, and potentially reset all or some when necessary. Ideas?
<fippo>: it is just a mess because you insist on _list. For example I have told you in-chat that you could use a reference element. Selective listing of arguments is clearly non-scientific...
Unlikely: Multiple lists with same name plus attribute separator glyph
:_list_members |psyc://goodadvice.pages.de/~heldensaga|psyc://psyced.org/~el :_list_members:_nick |heldensaga|el
This syntax produces a non-obvious change in the variable syntax to do a semantic separation that reminds me of the type vs name discussion - only that this time we are separating an entity list from a type and name.
Advantages:
- No psycmatch necessary to connect lists
- Advantage, but complicated: The : allows for a restart of compact method logic, as in the example lm_alternate:a_speak for _list_members_alternate:_action_speak
- / and * operators not necessary as + and - already provide that.
Disadvantages:
- Weird special case in variable naming and protocol syntax
- psycmatch may be more generic and easier than looking for colons in var mappings
- Adding a new row to the table is still too cumbersome (see above)
How does it look like, when you need to change a particular field of a particular member?
- A mess. You probably need to delete her entry, then reassign it with a whole bunch of plusses. Alternatively we introduce a syntax to both add a row to all lists at once, and potentially reset all or some when necessary. Ideas?
Unlikely: Enumerated table templates
Coming from structure templates discussed on Talk:Structure - let's use the strict templates. How do we enumerate? We can use the good old PSYC simple lists described above, and put as many items in them as the enumeration requires. This avoids ugly numbering and results in a structure that looks very much like group communication is being practiced already.
:_list_uniform_members psyc://beta.ve.symlynx.com/~fippo : psyc://beta.ve.symlynx.com/~agos : psyc://beta.ve.symlynx.com/~20after4 : psyc://beta.ve.symlynx.com/~derimperator :_list_nick_members fippo : agos : 20after4 : DerImperator
This gives us the chance to parse-time check the sanity of all elements (_uniform and _nick being variable type hints that let the parser automatically check legal uniforms and legal nicknames before letting this code into the privileged zone of the inner application core, where no unnecessary checks are made), next we get to the template which allows us to check the data's sanity in its entirety. What could it look like, maybe like this:
:_enumerate_members _nick_members:_uniform_members
This would specify the structure itself to be a hash mapping nicknames to uniforms. You could re-use the same data to provide multiple sortings or approaches, as in the obviously useful variant that maps uniforms to nicknames, like this:
:_enumerate_members_nicks _uniform_members:_nick_members
Here's a variant with the hash mapping nicknames to an array of attributes, just as an example, not for practical use:
:_enumerate_members_aged _nick_members:_uniform_members,_time_age_members,_degree_credibility_members
Note how the new variant of _enumerate_members is merely a prolongation of the existing template, thus the compatibility with the original can be checked by an abbrev-comparison of the templates.
Depending on the needs of the application, a structure renderer could interpret the commas either as an array, resulting in _members_aged["DerImperator"][1] to return DerImperator's age, or to make use of the implicit knowledge of field names and produce a hash which allows for access as _members_aged["DerImperator"][_time_age].
Unfortunately most programming languages do not provide the means to fully preserve the semantics of this syntax, which is both mapping and order. So to achieve this, the API would have to create both an array and a hash, or to populate the hash additionally with the indexes of the array, so that both access syntaxes are available, even if the array is technically a hash now doubled in size.
Then a way to foreach yourself through the structure could also be provided starting at _members_aged[0][0] with indices rising. Probably we should be starting at [1][1] instead, as we need the [0]-indices to tell us how many elements are available.
Unlikely: Tab Seperated Tables
Remember how popular, ubiquitious and actually easier to use CSV files where? This is essentially a tab-seperated-values syntax with a few extensions:
- the first line contains the names of the vars
- subsequent lines contain values for each record
- empty tabs at the end of the line MUST be omitted
- you can rearrange the order of vars in order to optimize the free cells to the back where they are omitted
- alternatively, you can make use of the semantics of order which or otherwise lost in a hash encoding
- optional: if there is extra data, then it defines a local extra variable using variable=value syntax
- newlines are escaped as before (by newline and tab)
- tab characters are escaped by tab and newline (this sounds like a joke but since tabs at the end are otherwise forbidden, a tab at end of the line designates an escaped tab). having tabs in table data is an uncool thing to do anyway, but if you insist it still can be done.
And here is an example, where whitespace is supposed to be tabs.
_identification _name _availability _mood _location psyc://example.org/~jack Jack psyc://example.org/~joe Joe 7 psyc://example.net/~pepi Peter Piperman 4 psyc://1.0.0.1:3232 psyc://psyced.org/~lynX the evangelist _nick_alternate=symlynX
Btw, the http://perl.pages.de feature a ppl database tool which keeps its data in files formatted in a similar way, and Mr. Hobbs wrote relational database management tools for databases kept in such files, including the very useful etbl editor.
This suggestion has been sitting here for very long, and the tab-based syntax doesn't fit into our current specification ideas at all, but imagine pipes instead of tabs, then this looks like a collection of lists sideways. I like the idea of being able to optimize cells, and to have optional additional fields, but this can only work if there is a row-separating character like the newline in this case. So far our list syntaxes are not intended to deal with anything but the pipe glyph. There is a possibility to shape this strategy up, but is it worth the hassle? Who needs optimizable empty fields? Hardly anyone. Who needs hash extensions that make rendering a nightmare? I guess that wraps it up.
Obsolete: JSON for Tables
This is a variant where Tables and Lists would share the same syntax:
[
{ _identification: "psyc://example.org/~jack", _name: "Jack" },
{ _identification: "psyc://example.org/~joe", _name: "Joe", _mood: 7 },
{ _identification: "psyc://example.net/~pepi", _name: "Peter Piperman", mood: 4},
{ _identification: "psyc://psyced.org/~lynX", _name: "the evangelist", _nick_alternate: "symlynX"}
]
But you could aswell use a format optimized for Tables (with similar semantics as the TST example above):
[
[ "_identification", "_name", "_mood", "_location" ],
[ "psyc://example.org/~jack", "Jack" ],
[ "psyc://example.org/~joe", "Joe", 7 ],
[ "psyc://example.net/~pepi", "Peter Piperman", 4 ],
[ "psyc://psyced.org/~lynX", "the evangelist", null, null, { _nick_alternate: "symlynX" } ]
]
Superceded by Spec: Length-prefixed tables
All syntaxes need to be length-prefix capable. This could only serve as an example, but we have better ones in the specification now.
Require length prefixes on a variable level and in-depth in complex data structures, completely avoiding extra syntax tokens like the { ( ) } used in the case above. Here's a prototype python program to produce some, written by fippo & lynX:
uniforms = ['psyc://psyced.org/~lynx', 'psyc://goodadvice.pages.de/~fippo', 'xmpp:elmor@jabber.org']
nicks = ['lynX', 'fippo', 'elmOr']
def ser2(u, n):
s = ""
members = zip(u, n)
for member in zip(u, n):
uniform = member[0]
nick = member[1]
s += " %d %s %d %s" % (len(uniform), uniform, len(nick), nick)
# lists are generic: #items data
return "%d%s" % (len(members), s)
def lm():
s = ser2(uniforms, nicks)
return "_table_members %d %s" % (len(s), s)
print lm()
The output of this program is such a serialization. It looks like this:
_table_members 113 3 23 psyc://psyced.org/~lynx 4 lynX 33 psyc://goodadvice.pages.de/~fippo 5 fippo 21 xmpp:elmor@jabber.org 5 elmOr
(Please ignore the uniforms getting linked by wiki...)
This is very flexible as every element can have any binary data content, but it also misses information on structure and meaning. Of course we can tie both signature and meaning to the variable type, but this syntax could prove difficult to extend by inheritance as it is not self-explanatory were rows and columns or any other sort of structure are. In this case there is some structure syntax: the 3 says how many entries there are in this table. Should be more useful if we output the width of each element instead (in this case being 2). Anyhow, having that kind of extra information makes this a _table rather than a _list. Other notations to be able to handle other structure formats need other types and signatures.