I think I can promise that we are mostly done with the HTML/CSS segue for now

So, I think I am almost finished with the html and css design. If it were not just for my personal use, I'd have a few more things to fix, but for now, it looks pretty close to my original design in my main browser, Firefox, with a few small, but pretty bad glitches in Internet Explorer. So let's step through a few of the interesting things I found while working the css and html.

First off, I added the tablecloth background that was seen in the first mockup, which was pretty easy. I had to move the Header tag outside of the recipe body for it to display correctly. I used information from this article to get it to display right. I then followed some information from Web Designer Wall to get the gradient that I wanted in the mockup. Notably, because the tab and the recipe body are in two pieces, I had to break up the flow of the gradient into two sections to get the gradient to go over both, so I have some css that does this:

Notably, and the only thing you need to see is that one gradient stops where the next starts. I have three different statements for cross browser compatibility because gradients are still experimental. Next, for the rounded corners I needed this:

Found that information on a blog all about CSS3 features, so again, this is not a mainstream ability yet, but some browsers support it. This is where my big Internet explorer problem comes in. IE9 will round the corners and will do gradients, but it can't do both correctly at the same time, so I have the corners sticking out from the borders, but maybe they will fix it soon? Next is the shadow, which, is another nifty css3 trick, I added it only to the main body of the recipe, because I was having some difficulty getting it to work with the tab, and it really isn't noticed (until pointed out.) but for that, I did:

I liked the effect so much, I replaced the pseudo-shadow on the image tags with this shadow effect as well. My vertical rule in the top section and the horizontal rule are kinda hacks right now created by adding borders to some elements on some sides, but they meet my needs and I'll fix them later.

Next post, I believe, I will start on XSL transformation, and then it might become apparent why I made the mockup.

Recipe Web Page Design: Choosing Fonts

Confession: I don't know much about aesthetic appeal. I delegate the task of finding what might look nice to people online. So, for fonts, I did a search on google for "popular typewriter fonts in web design," because I kinda want to model the look of an old style typewriter, and this article, which seems like a good start. The recommended font for plain text purposes seemed to be "Another Typewriter,"

Which can be seen in the example, or could be, if my site didn't have such a dark theme, but you can still kinda see it. I found a download link here for it. A word of caution is that embedding fonts can be kinda difficult for web developers, but standards for CSS3 are close to being finalized, so now we do have a way to embed a font if desired, so says this page. The page also links this tool which generates some css and some html examples so that you can just cut and paste to your desired pages and css documents. This is what I added to the top of mine (after the import for the reset, mind you!)

This says that all fonts in the body tag should use this font, which is named up above. Now I am going to play around with giving the text some space so that it flows a little better. Here are some tags I added... I don't want to repost my html again, but I am noting that I moved the header outside of the body:

And a few screenshots. I think the shape is starting to come along well now... just need to get the rounded corners, and add some pictures to bring it full circle. Below are screenshots of what it looks like in both firefox and internet explorer. It is always a good idea to try looking at a website in at least internet explorer and in one other browser to make sure that it will work for most visitors.

XML: Recipe Document (part 7)

Ok, haven't had much time for this recently, but let's skip a bit ahead. I have put the following into a css file:

I have retooled my HTML document like so:

First, I want to start off with one statement: I feel like I cheated a little bit by using the clear class. Right now I need it to keep the procedure picture elements from not overflowing the bottom of the entire recipe document section. I hope to get rid of that later. Generally, the HTML document should have as little information about form as possible; this should be left up to the CSS. Second, You might notice I put some weird background colors to each section. It helps me while playing around with css to be able to picture each of the different blocks of text and see quickly where things move. In my css document, I have separated out temporary information towards the bottom. I added a right and bottom border, but no other borders to the image divs to give it the feel of a drop shadow. I am happy to see that I kinda have all the text sections in the right place in the document now compared to my earlier mock up image, but there is still a lot of fine tuning to do in terms of aesthetic improvements, but the shape is starting to come together.

XML: Recipe Document (part 6)

Next, let's work on something that is personally a weakness of mine: cascading style sheets. Cascading style sheets, (commonly css) are what give shape and form and visual appeal to a page. If you take the html example from the previous post, and take a text editor, save it as an *.htm or *.html file, you can open it in a browser, and see a very plain web page. That is ok, and expected, because the html is only supposed to carry information about what kind of information is being displayed; that is it, is kinda like a model for information. CSS is a kinda view, something that makes that information look appealing. So let's get started.

First thing, I recommend getting a css reset sheet to help, here is a reset sheet that will probably work for most of our needs. A reset sheet makes it so that no elements of your document have any style at all; why do we want that? Because most browsers have subtle nuanced differences in the way they present certain elements; if we start off by removing everything, then it is more reasonable to guess that perhaps we will be producing something that looks the same in most browsers. I saved it as reset.css in the same folder as the html mockup I am working on. Then I created my own recipe.css file. Now add this to your <head> tag in your html:

The only line we want to put in recipe.css so far is the following:

Reminder, I have added a <div> tag with an id="Recipe" right inside the body tag of the html between now and the last example. If you open the html file in a browser now, the text is going to look really boring, but that is what we are trying to do with the first step. Let's open up the css document and add the following:

Save your css, and refresh the html file, and you will see that each of the sections named in this file will have the garish colors encoded in those values. I do this because I think visually, and seeing all the sections colored like this helps me place them where I want. Looking back at my mockup, I notice that most of the recipe card's color is actually #eedc5b, so I'll put that in the css for background-color for Recipe, also the recipe card has small margins on each side of the card, and a three pixel black outline, so let's try making the card with some margins on the left and right, giving it a black outline, and giving it a small margin from the top. We will make the #Recipe tag thusly:

Starting to get somewhere now, I'm going to take a break from this and hack at it again later, but as you can see, most of what is listed is kinda self explanatory. We set the border color to black, and made it a solid 3 pixel line, we made the card 80% of the width, and gave it a 20 pixels margin from the top, and automatic left and right margins. This centered it horizontally and moved it down from the top. Next I will arrange the text to flow into their appropriate areas.

XML: Recipe Document (part 5)

Now we need to make a mockup web page taking the design and breaking it down into its constituent parts. I haven't discussed HTML yet, but if you are completely unfamiliar with it, it is a markup language, much like XML with similar tag syntax. It it also not necessarily XML in that tags don't necessarily need to be opened and closed depending on which standard you are using. For me, I decided to use XHTML arbitrarily, which does treat HTML like XML in that it does need matching tags. I validated the document using an online validation service to tell me if all the tags matched and the like. If you want to set up your document to run according to a particular specification, this is helpful for getting the correct document definitions.

So the first thing is to organize the content in the web page according to definition of information and where it might be located. Keep in mind accessibility while you design your HTML. Content in the plain document should run from beginning to end in a logical order which you would read it regardless of where you want to eventually put that information using cascading style sheets. So at a high level the document is like this:

We have split the document into three parts, header, preamble and the procedure. Now we flesh those out with the parts contained inside of them.

Now we have named all the parts of the document that were labeled in the previous image, let's add some Lorem ipsum text and filler so that we have something that might resemble the HTML with content of a complete recipe.

Though it is all nonsense information for now, it will help us decide how to write the cascading style sheets in the next part.

XML: Recipe Document (part 4)

Now I am working on mocking up a display for a recipe in my xml format. I wanted something that looked like an old fashioned recipe card, and then thought that a checkered tablecloth background would work with the theme. Found the texture on this guy's profile, and it seemed that people were free to use it. Right now, it is a little imperfect, you might notice, for example uneven font sizes and things not lining up, but I was just trying to make something that might look decent inside a nominally small 800x600 limit, and I think for that, it came out all right. I also used some Lorem Ipsum text, a common place holder for where one might eventually put a lot of text. At the end of a first try, I made this:

I used Inkscape for mocking up the image.

XML: Recipe Document (part 3)

Now that we know what kind of information belongs to a recipe, and we have an XSD schema, we can test if it meets our needs in being able to represent a recipe. I saved the XSD from the previous post as recipe.xsd and put it in a folder in which I created the file we will work on today, first_recipe.xml. For this example, I decided to use toast as my recipe. Now, let's start with the basics, open up a text editor and add the following:

This tells our xml file that this recipe is going to follow the definition of a recipe according to the xsd schema file. Now that we have the root element and we have the definition, let's build up the metadata element of the toast recipe.

Nothing here is really surprising, I made sure to use a public domain image, just so everyone knows. All right, the next element. You will notice that my ingredients element looks different than the definition from the previous post, and this is because I discovered some shortcomings in its design yesterday, so let's take a look at the new schema for an ingredient, and then the ingredients for toast:

Ok, notice the attribute element in the new definition. An attribute is a value that is described inside the actual opening tag instead of being defined between the tags. The attribute is the same as the previously defined optional element, same idea, but now it is an attribute. Also, notice that instead of this design being an xsd:sequence, it is now an xsd:all. Sequence forces order; all does not, but when using all, elements may not repeat inside of the complexType. It just so happens that this works for my purposes anyway since all the values have a minimum of 0 (now a minimum of 1) and a maximum of 1. So now let's look at the list of ingredients for toast:

Again, this is pretty straight forward, the recipe requires one slice of bread, and optionally, you may have some butter. The optional tag is itself optional, so we could omit it, for example from the bread, and maybe assume that means that the bread is not optional. Alternatively, we might omit it from the butter, and assume that its absence implies that is optional. In my opinion, since most ingredients are not optional in most recipes, the assumption should be that if the tag is omitted, that it is a required ingredient. Next, is the tiny list of equipment this recipe requires:

Yep, a toaster. Nothing extraordinary to point out about that. Next, we need to look at the procedure node, which it itself remains unchanged, but the definition of the step node has changed, so lets look at the schema for the step node:

Notice, I turned number and image into attributes, also notice that changed the type from sequence to choice, and that choice has minimum and maximum occurrence; This means I can choose to have as many occurrences as I want of first ingredients, then temperatures, followed again by more if I choose. Going back to the discussion on context free grammars and languages from before, we could represent this situation as saying that we want our language to have the following tokens, and the following rules:

Token	Can Become
STEP	CHOICE
CHOICE	CHOICE CHOICE | INGREDIENT | TEMPERATURE | T
INGREDIENT	NAME QTY UNIT | NAME UNIT QTY | QTY NAME UNIT | QTY UNIT NAME | UNIT NAME QTY | UNIT QTY NAME
NAME	T name T
QTY	T quantity T
UNIT	T unitofmeasure T
TEMPERATURE	unsigned integer
T	any string, including the empty string

In this example, all terminating tokens are written in lowercase, and any expandable tokens are written in uppercase, and it can be shown now that any reasonable ordering of elements is possible, such as saying "Set oven to <temperature>300</temperature> degrees and prepare <ingredient>[...]</ingredient>," or "Put <ingredient>[...]</ingredient> into oven when it pre-heats to <temperature>300</temperature> degrees," or indeed any arbitrary ordering and quantity of either set of elements. Now, let's get back to looking at the procedure element:

Notice that the optional tag, which is optional again, was only used on step number 5; the other steps are implied to be mandatory for this recipe, so it isn't necessary to include the optional tag for each of them. Also, most of these steps seem easy to read and write, save for the first step that appears off-puttingly verbose. Realize this: For almost all desired purposes, XML is machine generated. Right now, we are testing the flexibility of the design, so we are more hands on then usually necessary. It does not make it easy to type recipe steps that might include several ingredients right now, (consider what it would look like in a recipe that said "mix flour, eggs, milk, and sugar in a bowl.") But this inconvenience is not a concern, because generally, as said earlier, a program makes an xml document automatically for people, and these fields are also important for demarcating important chunks of information. Say, for example, you decide you would like to write a program that converts a recipe with an arbitrary number of servings to a recipe for specifically 1 or 2 servings? The computer immediately knowing where to look for quantities in the procedure will make writing this software a snap. Or you could use it to convert between metric and imperial measurements, for example, and that is just the tip of the iceberg.

Aside from that, now that we have completely written the recipe for toast, let's take a look at the complete xml document for a toast recipe:

If you are using a text editor with special features, you can probably validate the xml document inside of your editor. Try using Notepad++ and then downloading the xmltools from the built in plugin manager. Then you can do Plugins | XML Tools | Validate Now, and it will tell you if the recipe has any format errors. There are other tools that can work as well. For reference, the current modification of the XSD after the modifications made today is as follows:

Incremental improvements are normal going through the development process, much in the same way I discover every once and again a better way to organize the schema. Now to take a break.

XML: Recipe Document (part 2)

With the diagram now established it is a lot easier to begin working on the schema document, the XSD file. A schema file basically tells what the expectation for a document are supposed to be, what the names of particular tags are for example and what values are allowed for particular tags. For this part of the project, I am kinda shaky, and I depended a lot on XML Schema Part 0: Primer, a guide to the basic syntax of an XSD document. So, check out the diagram from part 1, and then go on to the next paragraph.

First thing to do is take a look at the tree diagram. A tree diagram starts at the root (like a tree) and from there goes to branches and leaves (like a tree.) My tree has the root on the left side, and the leaves on the right side. The root is the "Recipe" box. Now let's set up the xsd document.

First open a text editor and add the following to our document:

Now, what does this all say? The first tag says this is an XMLSchema; an XSD file, with more information about it with all the tag definitions at the given url. The next tag is an annotation, with a documentation tag. The documentation tag tells us it is written in English, and gives us an idea of what to expect from the rest of the document. This is similar to a comment. After that, we have the matching closing tags and the like to completely close the XSD. Much like XML, XSD needs matching opening or closing tags, or a tag marked especially as being empty instead of a pair by typing a '/' before the last angle bracket. Ok, so that was easy, what next?

We see that the root is a recipe, and that a recipe has, or may contain a metadata section, a list of ingredients, a list of equipment, and a procedure. Because of the large complexity of the Recipe type and some of the children it contains, the recipe should be defined as a complexType, that is, it is made out of a bunch of small parts. For people familiar with OO it is similar to stating that you are creating an object, as opposed to a simple type. So, let's define the Recipe type, and what it contains now.

All right, this says that our defined document is going to have recipe tags, and that the recipe tags are going to require a metadata section and an ingredients section, because there needs to be a minimum of 1 of each, and a max of 1 of each. The metadata is a custom type, but the Ingredients is a set of custom types; a list of singular Ingredient nodes. the equipment and procedure sections are optional, because some recipes don't require anything but the ingredients, and some recipes don't even have steps. (In the case of eating raw foods for example.) Now let's define the Metadata Type.

A few new things. Name is notably defined as a string. In most languages, a string means a group of letters, numbers, and various other characters, as it also does in XML. so we can now type a name like "Cherry Pie" as the name of the recipe. author is also a string, but it can have many 0 or many (unbounded) occurrences. So you can add as many author tags as you like to a single recipe. Servings is defined as a positive integer, that is any counting number starting at one (no decimal places; this might be a weakness in some people's eyes, because some recipes sometimes don't make an even amount of servings. Let's pretend they all do.) the mealtime value is a construct called an enumeration, meaning it can only be one of any of the specifically listed values. You might notice that if that is the case, this design does not let us have recipes for brunch items, or for tea time, a flaw certainly, but there is a benefit in terms of searching and indexing of data. When someone wants to create a recipe, they might decide to create a "dinner" recipe. Someone else might decide to create a "supper" recipe. Semantically, they are the same thing to you and I, but to a computer it is very difficult to understand that they might be the same. After a while, if you find you are too limited by the range of options in the enumeration, you can always just add the extra line in there for Party time recipes if you so desire. Preparation time is a duration type, which is a way of writing how long something takes, exactly what it says, and the last one image is a URI. We can use a URI for storing the web address of an image of what the completed recipe might look like. Although it is possible to embed an image into the xml directly it is not exactly the best possible choice for my purposes.

Next, we will define the ingredient node. The ingredient has a number, in case the order it is used in is important, it has a name, a quantity, a unit of measure, and a value indicating whether or not the ingredient is optional. The ingredient node definition looks like the following:

Interesting things to point out about the definition of an ingredient are the quantity and the optional fields. Quantity is a double type. a double is a double precision floating point number, or a number that allows a decimal, that is, a rational number. Optional is a boolean value. This means it can either be true or false, or if you like, 1 or 0. Also, note that the body of the Ingredient field has the attribute mixed = "true" this means that one can type free flowing text around the fields.

Finally, we define the Step type nodes, which also needs the mixed attribute so that we can organize text around the important parts of an ingredient and temperature. This gives us the following:

No big new surprises here, except it is interesting to note that we can reuse the defined ingredient type from before inside of the free form text. This is a demonstration of reusability, an important idea in software engineering that we should design things to be reused as often as possible. It saves time, and makes fixing potential problems easier, so it is nice to see that XSD files allow this.

Surprisingly, I never knew about this mixed tag until reading the documentation on how to make an XSD file today. Cool stuff. Here is the complete, head to tail version of the XSD file now that it is completely written. Note that I fixed a few mistakes from previous sections as I noticed things were not needed anymore, like getting rid of the ingredient number and so on:

Whew, fun stuff.

XML: Recipe Document (part 1)

So, in order to teach myself XML, this is the situation I have come up with in order to create and use all the files and techniques described in the previous post. The situation is we would like to create a datatype that stores the information about a recipe. Now, first we should try to think of the things that a recipe might contain, and we should probably also decide the cardinality of these things, that is, how many of each are needed.

First things first, A recipe should have a name. That is a definite must. Since this is a must, we say that there is a 1:1 relationship between the two (As an aside, there is technically a Many:One relationship from Name:Recipe. It is possible, for example, to find many different recipes online for Apple Pie, but each recipe only has one name... unless we would like to be pedantic and say, for example, the name is different depending on where you are from... For example a recipe with a name of French Fries might have a name of Chips in different parts of the English speaking world, or Pomme Frites where French is the native language. For our purposes, we will say that there is only one name for every recipe for now.)

What about an Author? Some recipes have one author; some recipes have many authors, some recipes have no Author. Some people that are authors have written no recipes, some people have written one recipe, and some have written many recipes. What we have is a Many:Many relationship between Authors and Recipes.

Going along, we might say that a recipe has a preparation time, it might have a list of tools we need, sometimes recipes have illustrations if they are more difficult. In terms of defining an XML document, it is important to decide which of these details about a recipe for example, or any other piece of interesting information is important to keep, what is its relationship to other interesting or important pieces of information, and what is the cardinality of that relationship.

Cardinality of relationships is how much of something is related to something else. For example, how many ingredients do recipes have? Do any recipes have 0 ingredients? No, I can't think of any recipes that contain 0 ingredients. Do Any recipes have 1 ingredient? If you want, you could say that the recipe for toast has one ingredient. Do some recipes have more than one ingredient? I can think of many recipes that have more than one ingredient; most do. So, for the sake of this document, we could say that a recipe requires at least one ingredient and can have many more.

For each of the basic cardinal relationships there is generally a short hand symbol for the amount required on each side of the relationship. The table below summarizes most of these shorthands.

Symbol	Cardinality	Optionality
1,2,3, etc...	Specified by the number	Mandatory
*	0 or more	Optional
+	1 or more	Mandatory
?	0 or 1	Optional

Additionally, these can be combined in ways that make sense, for example, if it makes sense to require two or more references on a application for a job, you might describe this as "2+"

After spending a little bit of time coming up with what might be a reasonable amount of information to want to store about a particular recipe, pretty much following the above process, I used erviz to make a diagram. (As of the time of my writing of this post, it seems the main erviz website is down, not sure where you might be able to get the software currently.) You can see what I have with the below link

This will be the reference document I will use to define the Schema of the final recipe XML document.

EDIT: This is why the planning process and having a diagram can be helpful. After taking a break from the brainstorming process, I realized an oversight, the oversight being that some recipes sometimes have optional ingredients, and sometimes they have ingredients that are added "to taste." Also, for a certain purpose, it seems like a good idea to optionally relate steps to ingredients, for example when not all of a particular ingredient is used at a certain step (for example, using some eggs in step one, some eggs in step five.) The chart looks a tiny bit more complicated, but it does allow me to learn an additional element of XSD design down the way. New Diagram below.

XML Self Learning Start

In order to get the ball rolling on this thing, I decided a skill that might be useful that I kinda have, kinda don't have is XML. XML is an abbreviation for eXtensible Markup Language, and it is exactly that; extensible because the definition of an XML document can be changed to meet a particular user need; markup language meaning it is a language for describing information (as opposed to a programming language which is used for automating the problem solving process on a computer.)

Most XML documents are, in the study of formal languages called a Context Free Language, which, if it helps one to visualize, can be thought of as a Tree, in the sense that every piece of information has a singular parent, (save for the parent of the document) and can have none, one, or many children.

Under what circumstances does one generally use XML? XML is used mostly for storing information that will be read again, at some point, by some application. The application might be the same application; it might be an entirely different application. Because of the rules that define XML, it is extremely portable. Because of its portability, it is used often in web applications for sending and receiving information (Another competing format that is growing popular that is used in the same problem space is JSON which I might discuss later.)

In programming, XML is often created through serialization, a process that can be automated to take all the important information of a runtime object and save it into a file. This process is called serialization because it takes information that might be in any particular location and order in memory, and forces it to all be in one location in a specific order (That is serialized). Most programming languages also have deserialization facilities as well, allowing one to instantly put information back into a program from an XML file.

Another advantage to XML is that it can be easy for people to read if they need to read it, allowing software developers and testers to easily spot mistakes, for example, and seeing what might need to be fixed. This is called validation. However, even better than that, XML has built in support for validation through XSD, or XML Schema Document. Using an XSD, one is able to decide what is allowed in a particular document, and what is not allowed. Most XML programming language libraries and several IDEs and enhanced text editors can report if an XML document does not subscribe to noted preconditions, such as missing particular required values, having words in a spot where only numbers should be, or a mistyped phone number, for example. There are some criticisms to XSD and some short comings, but it can be used as a good first step to ensure meeting most preconditions.

In addition to XSD, we can also use XSLT or eXtensible Stylesheet Language Transformations to transform data from one format to another. For example, if information in one program is expected in one format, but the output from another particular program is not in that same format, an XSLT document can be used to automate the process of converting the output into the expected input of another program.

For now, I am going to use Serna Free as my XML editor because it is free and open source and runs on Windows, Mac, and Linux. I have not used it before, but it seemed to have respectable support from a precursory search. Other good editors that may work just as well are Notepad++ or the editors included in your IDE of choice. I chose to try this software because it looks like it might ease the testing of XSD and XSLT along with an XML document. I hope to learn something from this project, and I hope that this will help others as well. If anyone would like to recommend a particularly good free XML editor with built in validation and XSLT testing, please feel free to comment (says I to my absolute zero readership.)

A blog.

I have free time; I have creative energy; I don't know what to do with it. I feel pretty pretentious saying things like that. I have ideas for what I want to say here; maybe I can use this to store my rants that will be read by no one in particular. Maybe I should try to use this for a place to write creatively. Maybe I should comment on news articles. Maybe I should use this as a place to post funny pictures I find on the internet. Maybe I should use this to talk about programming in a professional capacity. Maybe I should use this to talk about programming in a hobbyist aspect.

I think for now, I'll write whatever is interesting to me.