When writing my first draft of this project, I used the major titles in the schema mainly as a checklist of things that I needed to include in my public initiative proposal. I gathered all the information that I potentially wanted to use and made a big bullet list of things that I could use to support my argument. From there it was easy to peg where all my points would best fit into the schema. It was interesting building a writing assignment around the existing schema rather than developing both a piece of writing and a schema simultaneously. I kind of kept bullet points under each of the headers and filled in more with details and sentences until I felt like I had a sufficient argument/content to satisfy the requirements of each section. However, there were definitely drawbacks to this method. I really think I put way too much information and lost focus; my plan is to go back and trim everything that is extraneous and nail down a focus for the proposal. I got distracted using the schema in my brainstorming basically. However, having the schema in front of me helped me to figure out what kind of information I needed.
The schema definitely fit the proposed rhetorical situation, however it was next to impossible to come up with a rhetorical situation that made sense for me to explore. I guess anyone could be involved in proposing ideas for a city development project, but I can’t think of any real situations in which a mechanical engineer would be involved. I have no education or background in city/land development, construction, or addressing social issues. So this was a little bit of stretch from the project prompt.
From peer reviewing with my group, I noticed that there were a few sub elements and attributes that I didn’t use correctly or didn’t realize were in the markup. Not that this would change too much about my proposal, but it would have been helpful in constraining my writing enough to have kept me more on track.
Aside from these few confusions, the schema was very well set up and easy to use. I think my whole group could have benefitted from additional documentation of all the elements and organization of the markup, but this was only an issue in a few places (like the purpose section). I couldn’t find any definitions for attributes to elements; this could have been helpful in the scope and introduction sections as well.
Overall, it felt a little more constricting using someone else’s schema because I was assuming the whole time that the schema had to be completely correct, so I had to work my writing around the schema. In project two this wasn’t the case because while I was writing my first draft for my cover letter, we were still making changes to the mark up, so if I noticed something that made writing our cover letters difficult, we could just adjust the schema instead of adjusting what we were writing.
