« January 14, 2003 | Main | January 16, 2003 »
January 15, 2003
BlueOxide Collaborator Registry
I wrote about BlueOxide's XML Collaborator tool yesterday. I missed part of it. The tool's core functionality is an XML registry. The XML editing tools are support structures for the registry itself.
One of the things Kevin (BlueOxide CTO) just said is that there are collaboration features built into the tool. In general, that's a good thing, but I hear more and more people talking about their tool having collaboration features (@Task was another one. I'd rather they use something like Groove's web service API to get this functionality. Of course there are a lot of tools, and integrating to all of them is difficult, but I hate to see the collaboration be liked to a tool. An enterprise needs general collaboration tools that work with multiple products, not multiple, product specific collaboration tools.
03:14 PM | Recommend This | Print This
DLA Logistics Metadata Registry
This afternoon I'm attending a meeting of the XML registry project team. The first speaker is Jim Keppler, talking about an integrated repository for logistics metadata. The work was done for the Defense Logistics Agency. The system is a registry for DLA data elements. In addition to allowing these data element schemas to be registered, the system also supplies tools for creating and managing the metadata. Some features:
- Core data element administration
- Metadata management support
- SOAP inteface to core data element metadata
- JDBC interface to data source metadata
- Web browser interface
The motivation behind the registry is fairly simple: DLA had created lots of XML documents and schemas. They were using these internally and with external customers. As the number of XML documents and schemas grew, it became difficult to know what the current version of the document was, where it was located, etc. This system allows applications on both sides of the transaction to ensure they have the latest copy of the XML.
02:06 PM | Recommend This | Print This
PDF and eGovernment
Adobe is presenting. So far, its been the standard "PDF is great and the government should use it" kind of sales talk, but they're starting to talk about the document server. Sounds remarkably like Cocoon, but with only a PDF output capability. He refered to this as "document and bill presentment."
Next topic is form entry. They apparently can do two things that are interesting: The first is pulling data out of the completed form. I've always thought of PDF forms as static things that people filled out by hand and sent in by snail mail. The second is archival storage. This, of course, raises the question of what represents the official record. There is a version of PDF called PDF/A that is specifically for archives. For example, the archival version doesn't contain executable javascripts.
XML is used in a variety of ways inside PDF:
- PDF's form syntax is based on XML in Acrobat 5.
- Data objects, based on XML, can be inserted into the PDF and retrieved later (using Javascript, for example).
- PDF metadata is XML based (and maybe RDF).
- Tagged content, based on XML, in Acrobat 5 provides document structure. This allows reflowing, for example.
Form features are turned on in Reader when the form is served from Adobe's Document Server. This means that form users aren't required to have a special reader, just the normal free reader they already have.
As of now, there is no way to integrate PDF into workflows nicely, but XML workflow support is, apparently, coming. It takes the form of XML on the outside of the PDF with the PDF file base64 encoded inside the XML. Adobe sells a workflow server right now. I wonder how it, plus PDF, compare to eWork (Metastorm) or Savvion.
11:51 AM | Recommend This | Print This
Federal XML Working Group
This morning, I'm attending the monthly meeting of the federal XML working group. Unfortunately, there's no Wi-Fi (or any other net connections I can see) so this will be posted later.
First up is John Dodd talking about connecting XML with the Federal Enterprise Architecture. John is with Computer Sciences Corp. and working with the IAC (Industry Advisory Council). The focus is" cross government information sharing." Gee, where have I heard that before? Interestingly, one of the first things that John brings up is that the introduction of web services to government will cause people's roles to change and that is going to cause angst.
One of the suggestions John has is that technology working groups (like the one I'm attending) ought to spend some time each year creating a roadmap to serve as guides for others looking at deploying the technology. The second half of this suggestion is that this roadmap needs to be effectively communicated. I think NASCIO, for example, could play an important role in this area for the states. Frequently you go to a NASCIo conference and almost every state is working on the same technology vision, but the group, with its authority and trustworthiness, doesn't communicate that vision to others in state government.
John thinks the most important business case to be made for using web services is interoperability. He mentioned Governor Leavitt specifically saying he'd read some quotes from him over the weekend where he used the word "interoperability." John was surprised (and scared) to hear a Governor use the work. I'm not.