After a career as a librarian (Linda Hall Library, one of the Patent & Trademark Depository Libraries) and now with 21 months to retirement from the USPTO, I’ve often had to invent a title for what I do. To avoid alarming either the business folks or the developers, I recently have usually called myself “Senior Advisor for Information Standards.” We treat a schema or DTD as a “standard” in the sense that when information is exchanged internationally between IPO’s or internally between systems, we expect (sometimes “require”) that it will be encoded using a specific schema or set of components designed for that purpose. I’ve chaired the “Information Standards Technical Working Group” for many years, where the problems of “integration” are resolved and the schemas revised as needed. What has been especially useful about this WG is that it includes representation from the entire pipeline for the information, from receipt at the door, pre-examination processing, examination, post-examination, publishing, and dissemination to the public. Having everyone in on the development of the schema, and on the issues that various stages of processing have to address, has proven invaluable. I’m often referred to as the “XML expert,” but that’s a default position, meaning that for most of my career, my knowledge has been a step or two ahead of the others in the working group. That’s no longer the case, these days. In fact, I rely more and more on others for the details of the XML technologies as my attention moves higher and higher in the stack of abstractions that constitute a kind of OSI of information. I can read a style sheet, but please don’t ask me to write one. I’ve been reasonably successful in using “information” to mean the content, the stuff that the business pays attention to, and leaving the term “data” for the raw stuff in databases or otherwise unrecognizable to the business folks. If I were looking for my replacement, I’d be looking for a philosopher, and if one with the necessary interest can’t be found, then perhaps an English major. If you can organize your own thoughts, then you have the most important tool needed for creating a schema: a sense of orderliness sufficient for the task at hand. Of course, the business itself has to hold your attention to some degree. While anyone can learn the syntax, it takes a special kind of creative impulse to make the code sing, one of the reasons I don’t write code. I’m fortunate to have a few contractors at hand that can do that. Still, they need a score, and that’s what I provide. Someone has to understand the purpose and value of the content AND the method of encoding the information to ensure that the two together produce the desired result. You have to have sufficient XML and sufficient love of the business. Bruce B Cox OCIO/AED/Software Architecture and Engineering Division 571-272-9004 From: Len Bullard [mailto:Len.Bullard@ses-i.com] Those are popular phrases but largely meaningless unless further defined by the processes and kinds and types of data to be integrated. For example, how much analysis is required of the integrated sources, how are they QA’d and does that occur before or after the XML is created given that XML is the final format for delivering an integrated product? len From: Michael Hopwood [mailto:michael@editeur.org] So the problem space is…? How does “information integration” or “data integration” sound? That is one of the phrases I hear bandied around at lot at present. From: Michael Kay [mailto:mike@saxonica.com]
It’s a general qualifications question: do you expect an XML professional to: There's no such thing as an XML professional, any more than you can be a screwdriver professional or a fork-lift truck professional. People who define their abilities by the tools they can use proficiently are not professionals, they are technicians; professionals define their capabilities in terms of the problem space, not the solution space. |