Hello Bruce, thanks for the reply:
> > That's obvious to us at least. We want a two way process, where we have > > "Test Script" writer documents and XML test scripts, where you can create > > one from another. Think of the writer document as a rich annotated form, > > where things can be bold, footnoted, etc. free form WYSIWYG (ODF format > > is supposed to translate that, right?). > > I'm still having a hard time understanding the use case. What kind of > content are the users dealing with? In our test scripts, we have a test name, a revision number, a date, an author, the basic things, mostly stuff that should get a layout automatically via fields. Further we have references to requirements in other documents which the test covers. For these we must later build table mapping tests to requirements. Then we have test steps, some of which have one or more standard form of execution that could be pointed to in footnotes or text. And we have expected results for each test step. Ideally such a result will refer clearly to an observation made and named in one of the test steps, or to simply the output as must be expected from requirements. Like starting the system, leads to the system actually starting. We have systems that automate test executions, and systems that automate test creation. We have users that need to do special stuff, that only free text can explain. We will always want to include nice tables with expected results, corporate identity, and stuff. And we have important use cases, where for fabric acceptance testing, massive amounts of tests must be copied together into one document, and presented as such to customers, together with documents that detail statistics, etc. For the automation to work nicely with the users, a common, identical file format must be created. We thought this should be XML. Imagine our surprise to discover that at least MS Word which outputs terrible-but-still XML will play absolutely nice with our schema. Imagine my complete surprise that OOs won't (yet?). > Some of this "custom schema" sort of stuff might be covered by the new > metadqta support in ODF 1.2. There you can attach RDF statements to > pretty much any content node, including a new generic field. This meta data stuff sounds like inventing the ability to attach things. But I don't really want any of our tools to actually deal with ODF itself. Our schema is to be understood or generated, and that should be it. A step that would translate would introduce loss. Any tool of ours to work on the test scripts should "only" be able to ignore the ODF tags and keep them intact, et voila, everything would be fine. > But a) as I said, I'm not sure of your use case, so it might not be > relevant, and b) ODF 1.2 isn't yet implemented. See it this way: Our approach doesn't mind of it's WordML (Office 2003 XML) or OOXML or ODF 1.0, 1.1, 1.2 or anything else that is mixed in. It should be considered a good thing. Another topic is of course, if it makes sense for OOo to read, present and edit beyond the ODF schema. I think it does. Yours, Kay --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
