Another dream I had

It was another school regret dream, with a few massive Dalek invasions thrown in. (my my, the panicky crowds of people scrambling to get away!) But it had a couple decent ideas for paintings.

Choose a book, paint a fictional landscape based on that book. But paint it flat first, just flat colors as the sketch.- Then paint it onto an image of a book, such that it appears like the landscape is extending out of the book- 3 dimensionally. Kind of like a pop up book. The process is to copy the flat sketch onto the book first- and then project the dimensional extension out of that.

The other project was kind of strange- It had to do with fictional pop culture characters placed twice across a cloudscape. (Alphred E. Newman, The Simpsons) One pose is large enough to see facial expressions, the other small enough to see body pose. The challenge is to compose it all into a single painting.


I'm not quite sure what the educational purpose of either of these projects were meant to be, but for some reason I felt quite guilty about not being able to do them properly. We'll see about that.

Bouncy Pixelly Creature

This makes me happy.
Pixels make me happy.

Thus, I wanna make a bouncy pixely creature person thing, made from good ol fashioned homegrown pixels, CSS sprites, and javascript. But the road would not be easy going.

Step #1.

Design, using pencils, the creature that I want to create

Step #2.

Break the thing down into seperate individual movable body parts, that can be animated

Step #3.

Model the parts in 3D and render from all angles that will be visible, 360 degrees around, above and below at some reasonable interval, (say, 8*8?)

Step #4.

Trace over the renders to give the parts some hand drawn pixelly juice.

Step #5.

create dom elements for each body part.
create javascript routines to move a body part to any arbitrary on screen coordinate, and switch the frame to any arbitrary frame in its body party category.

Step #6.

Create springs for each limb

Step #7.

Figure out how ventrella did the upright stance for his creatures. Creatures need balance!

Helma's documentation is confusing. Here's what _parent really means.

helma's documentation has this to say about _parent

The _parent entry contains a comma-separated list of properties of objects of this type to be used as parent. Objects must know their parent in order to generate correct URLs in their href() function.

_parent = property1, property2.collectionX, root.collectionY

If an entry in the _parent item does not contain a dot, it is interpreted as an object property of the current object that acts as the object's parent. If an entry contains a dot character, the part after the dot is interpreted as a collection in the parent object in which the current object is contained. If the _parent is specified as "root", it is not interpreted as a property of the current object. Instead, the application's root object is used as parent object.

Hrrrwhat?

This is confusing, because _parent is a very specific and tacked on solution to a very specific problem with how helma is architected.

Helma works by mapping a javascript object graph to a url space. Helma lets you map the same object or collection of objects to more than one part of the URL space. There frequently comes a situation where you'll want to generate a link on an html page to a specific object: Say you have a wiki page with a link, and an object representing the page it links to. You'd want to be able to generate the URL to that linked to page on the fly.

Helma provides a function on each object: the href function. This href automatically generates a URL which points at the object that it's called on. So for instance, root.wiki.pages[547].href() may return the url /wikiprogram/wiki/pages/547/. The problem is that an object has no way of knowing which url you want, if it can be accessed by more than one url.

The problem comes when that page 547 is also in another collection. Say, root.wiki.history.pages[547]

Which url should href return? /wikiprogram/wiki/pages/547/ or /wikiprogram/wiki/history/pages/547/ ?

What helma does is pick whichever url that you access the object from *first*, after the application is started, and use that URL henceforth. That is, unless you specify _parent in type.properties.

So, in the page prototype's type.properties file you can add


_parent = root.wiki

and the href function for that object will always return /wikiprogram/wiki/pages/547/

if instead you specify

_parent = root.wiki.history

then the result will always be /wikiprogram/wiki/history/pages/547/

Thus, _parent lets you choose the canonical URL for an object.

The documentation quoted above appears to indicate that _parent can do more than this, but that is something that will have to wait for another post, since I have not yet deduced what that is.

JSON, XML and the Relational Model part 3

Okay, let's talk XML. What is XML in terms of the set theory concepts from the last part.


Let's start with an element. An element in XML looks like this:

<element 
  attribute1="value" 
  attribute2="value" 
  attribute3="value"> 
  Content 
</element>

Okay, so an element consists of a few parts. We have the element name "element". we have a set of attribute names {attribute1, attribute2, attribute3}. The set of attribute names has all the properties of a set that I laid out in part 2. Each attribute forms one half of an ordered double. Finally we have content, which ultimately, is a tuple of nodes, with all the properties of a tuple discussed previously.

A node can be an ordinary text string, a cdata section or another element. Thus, we come full circle, and demonstrate how xml nests.

The key point here is that in XML you cannot nest in a set. To put another way, an attribute value cannot contain an element, or a tuple of elements. The only opportunity for nesting in XML is nesting a tuple of nodes in the content of an element.

What this ultimately means for XML and JSON together, is that JSON ends up slightly more expressive than XML, since it places no such restriction on data structures. Any of the JSON elements (object, array, string, number, etc) can be placed in either an object value, or an array value. (Set and tuple)

There are many approaches to conversion of XML to a JSON notation, or Javascript object. The following article on XML.com describes one approach:

converting between xml and json

One thing you may notice in that article, is that the approach taken is generally insensitive to whether an aspect of JSON or XML is a set or a tuple. The goal appears largely to be a conversion that produces the most aesthetically pleasing example code. No attempt seems to be made at understanding either format, or their logical differences and similarities.

In that mapping scheme, The attributes of an element become JSON object properties, and an @ is prefixed to the property names. This runs into no difficulty, since as I've covered, attribute names in XML are a set, just like property names in JSON. There is no mismatch here. Also, the names of that element's child elements become JSON object properties on that very same object. This will run into problems. In fact, the author of that article encounters the problem on page 2:

An attempt to map a structured XML element...

<e>
  <a>some</a>
  <b>textual</b>
  <a>content</a>
</e>

...to the following JSON object:

"e": {
  "a": "some",
  "b": "textual",
  "a": "content"
}

yields an invalid result, since the name "a" is not unique in the associative array.

Indeed, it is not a valid conversion. The author is mapping an XML tuple, to a JSON set, but a set is not a tuple. Does the author then conclude that it is an invalid approach, scrap it, and try and think of something better?

So we need to collect all elements of identical names in an array. Using the patterns 5 and 6 above yields the following result:

"e": {
  "a": [ "some", "content" ],
  "b": "textual"
}

Now we have a structure that doesn't preserve element order. This may or may not be acceptable, depending on whether the above XML element order matters.

Oof. Nope. Instead, this approach scrambles the data even further, in an attempt to preserve those pretty code samples on the first page of the article. The author then goes on to conclude:

This example demonstrates a conversion that does not preserve the original element order. Even if this may not change semantics here, we can do the following:

1. state that a conversion isn't sufficiently possible.
2. tolerate the result if order doesn't matter.
3. try to make our XML document more JSON-friendly.

The first conclusion is assuming that this arbitrary scheme the author has devised is the only *Possible* way to convert from XML to JSON. The second conclusion is assuming that there are situations in software design where you can get away with bad logical mistakes. And the third conclusion is strangest of all. He is concluding the problems with the conversion are not due to logical mistakes in the scheme, but are due, he believes, to JSON being inherently *less* expressive than XML. I hope that I have already demolished that conclusion at the start of this blog post.

However, if you are still not convinced, stay tuned for my alternate conversion scheme in part 4.

Another dream I had

a 3d video game with a vast world, with many realms. Each realm has a race of people, who are either helped by, or under the tyranny of some flying demon. Each realm also has a "Flying Demon", whom you can ride, but only if you solve some riddle, or defeat them in battle, or solve some other puzzle.

from that point forward you can summon a flying demon to ride. Each one will have some unique ability, such as speed, stamina, altitude, tight handling, transportation, transformation, and so on.

There is an over arching goal, in that the entire world is under threat by a species of what may be called "Gaia parasites", who feed directly off the planet's life energy. As you travel the planet, the previous realms you encountered may become infected, and mutate the creatures there. The goal would be to revisit every realm, and find the solution to this global menace.

why were you traveling in the first place? You are an alien, and you are trying to find the uberdemon that can travel between planets, so you can go home.

The dream I had

JSON, XML and the Relational Model part 2

In math, there is something called set theory.

In set theory, there is something called a set.

A set is simply a list of items with two rules. One of the rules is that order is not significant:

{1,3,2,4} is the same set as {3,4,2,1}

The other rule is that repeats are not significant:

{1,1,2,3,4,3} is the same set as {1,2,3,4}

A set can contain more than just numbers. It can contain anything, such as words:

{Julie, Bob, George, Ringo}

and even other sets:

{{5,3,1},{7,9,2},{3,2,1}}

In set theory, there's another concept called a tuple. A tuple is basically the same as a set, except that the two rules above do not apply. For a tuple, order does matter, and you can have repeats.

These two concepts: sets, and tuples, are the basic building blocks for the three popular data formats listed in the title of this series (And many more). There are plenty of other useful concepts in math for data structures. However, computer languages seem to stick mostly to these two for structured data.

Since JSON is essentially a javascript object, it follows javascript's rules. Here's an example of JSON:

{ 
  example:"Object", 
  name:"bob", 
  array:["George","Ringo","Paul"]
}

As you can see, this is basically a set, with the members

example:"Object"

,

name:"bob"

and

array:["George","Ringo","Paul"]

each of these members is a double: a tuple with two members. For instance, the first member is the tuple

{example, "Object"}

. The array tuple,

(array:["George","Ringo","Paul"])

is also a tuple with two members.

{array, ["George","Ringo","Paul"]}

. The second member of this tuple, is also a tuple.

{array, {"George", "Ringo", "Paul"}}

So we can see that JSON is composed rather simply of nested sets, tuples, and values. Tuples can contain other tuples, tuples can contain sets, sets can contain tuples, and sets can contain sets.