Primarily, I appreciated having the schema for my individual writing for project 2 because it kept me focused and kept my whatever I was writing more relevant to my topic. I didn’t have a place to include tangential information, so I had less of it. That is something that I always struggle with when I write letters or assignments. I relied heavily on the schema and it kept me from having to think too hard about what I wanted to include in my letter and how I wanted it to flow; that work was already done for me. So all I had to focus on was what content I wanted to include and how my language was going to flow.
My only gripe with writing in XML is the lack of formatting. I understand why it is the way that it is, but its difficult to write in Oxygen and then all your text goes off the page because every line is so long. So I’m constantly hitting Ctrl+Shift+P and that got kind of annoying. I ended up making all my edits in my second draft in a word doc and then copying and pasting it into my XML. This is what I would have done for the first draft too, except I wanted to have the schema laid out in front of me to make sure that I was utilizing it.
Our genre was difficult to nail down to a specific format. It was evident through our research that a lot of people felt very strongly about how cover letters should and shouldn’t be. There were a lot of cases where reputable resources disagreed with something about how a cover letter should be. We tried to rely most heavily on feedback from our co-op advisors because we trust their experience the most. All the readings that they trusted and used in their classes and all the feedback they gave us from asking them questions was particularly helpful in nailing down what we wanted our schema to be.
I think that discussing things in our group made me realize just how different people can understand a certain piece of writing. I thought I knew most of the conventions of a cover letter before this. I thought most of our research was going to be focused on smaller details of it that make the difference between a good and a bad cover letter. There was one day when we split up our resources and each did our own research and talked about it the next day. I realized that what I understood from our research was completely different than what my team understood from our research. All our examples were relatively similar, but we took completely different things from them. It forced me think in a way that I wouldn’t normally in order to understand where my group mates were coming from.
I think our schema came out quite well. I think that we left it vague enough that it is not restrictive, but specific enough that it isn’t confusing. It was difficult, again, agreeing between our group because when we put together our schema the first time, I thought we were all on the same page. Then when we all made our first drafts, we didn’t really implement the schema in the same way as each other, so obviously we weren’t on the same page. It was difficult hashing out these differences, but I think it made our schema more understandable to a third party. If I could, I would have tried to find a way to add like a ‘preparation’ section to our schema. This wouldn’t be anything for the cover letter, but more of a way for the writer to organize their thoughts and goals for the cover letter. I think it is important for any writer to specify key requirements or values called out in a job listing that they are writing a cover letter in response to. I don’t know what XML’s limitations are, but it would be cool if we could have the reader call out skills from the job listing and then require at least half those skills to be repeated in the “experience” paragraphs in the cover letter.
