In our case, we routinely used Near & Far, now XML Spy or even oXygen, to show schemas to users (surrogates for patent examiners or trademark examiners), primarily to verify the business logic schemas embedded. This is during the design phase, which can take months, even years when other industrial property offices are involved. Right now, biotech examiners are revamping the XML for sequence listings, replacing a decades old international standard. Element name readability is indispensible. Readability is paramount when troubleshooting an error in a process that produces the ~10,000 XML instances of patent grants and applications we publish every week. The developers doing this must either themselves be business experts (rare, but priceless when it happens), or able to work with business experts, to detect the errors and then correct them correctly. The patent grants and applications are exchanged with EPO and JPO. Examiners don’t look at the XML, but those who build search systems for examiners do, and being able to read the schemas and contents with the business process in mind is essential for useful indexing. Another class of users here are the editors of the Manual of Patent Examining Procedure (three attorneys and about six clerks). They have learned enough XML in the past year to be able to manage about 3,000 pages of some fairly complex content. They use oXygen to modify XML instances of chapters. They generally prefer to work in text mode, rather that Author mode (wysiwyg). They’re content with camel case. Where they stumble is when an element name or the logic of a content model are unobvious. Draft versions of chapters are distributed for review in PDF with comments then incorporated back into the XML by the editors. Editors of the Trademark Manual of Examining Procedure (three attorneys), on the other hand, prefer to export the XML to MS Word, have their reviewers edit in Word, and then hand it back to a clerk to manually modify the XML source in oXygen. The old process for the MPEP involved converting draft Word documents to something and then to something and then to SGML in Frame Maker where page layout was finalized for printing. When we started the project to replace that system with XML, we ruled out any conversion to or from Word as being highly unreliable and essentially forced the editors to work in oXygen. Two years ago, they hated it. Now, they have ceased the burnings in effigy, and are all eager for the next round of training in XML. They love being in control, even though it means they have to get their fingernails dirty in ways they didn’t have to in the past. From the CIO’s perspective, it’s a big win in that producing a new edition does not involve anyone other than the content owners (no CIO contractors, no CIO staff), unless there is a problem. And finally, a few years ago, some developers did actually threaten to add hundreds of thousands of dollars to a major project of ours so that they could develop a method of working around the dashes in the element names from WIPO Standard ST.36 that were so inconvenient in Java. For various other reasons, that project was suspended. Bruce B Cox USPTO/OCIO/AED/SAED 571-272-9004 From: Alex Muir [mailto:alex.g.muir@gmail.com] On Mon, Feb 6, 2012 at 4:36 PM, Costello, Roger L. <costello@mitre.org> wrote:
Alex Muir
|