Hi Jack - Here's feedback on the functional spec.
1.4.3 Would it be appropriate to mention some of the xml parsers that fit these dependencies? That was my immediate question when I read the first paragraph in this section. When I google xml parsers, there are a lot of them out there. Include a pointer to or describe what the Manifest Inter-File Organization effort is (perhaps in the Definition of Terms). Someone outside of our group might not know what it is. 1.6 I would add the following definitions: Distribution Constructor lxml Python Manifest Inter-File Organization 2009.06 (I don't think it's good to assume that everyone reading the doc will know what that means) 2. Functional Overview 1. At the end of the first paragraph, you repeat the comment about semantic validation. I think since you mentioned this at the beginning in the Scope of Product, you don't really need to repeat it here. 2. In the second paragraph, the first sentence talks about data modeled in memory as a tree. This implies a requirement for a specific type of parsing model that might need to be explicitly stated. 3. In the second sentence, beginning " The parser will take a path..." I would add after that "using an XPath format as input" or something to that affect, if that is the intended meaning. The way it is worded is confusing. Also in the second paragraph, where the differences from 2009.06 are listed, I don't think it adds anything to note that this is different functionality than that found in 2009.06. 2.1 I wouldn't repeat the last paragraph about the dynamic default setting/semantic validation, for the same reason I mentioned previously. 5.1.3 The last sentence starting with XXX....does that need to be deleted? 6. What about a use case for the remote consumer scenario.
