[
Lists Home |
Date Index |
Thread Index
]
Working with US Federal Government clients, I am constantly reminded
that information captured in XML has not always initiated in an XML
realm - that is, it could have initiated (for example) in a non-XML
registry (such as an ISO/IEC 11179 registry) and the processing stream
of the information eventually involves XML at some point but not at all
points.
For example, the US Environment Protection Agency (EPA) utilizes an
ISO/IEC 11179 registry called the Environmental Data Registry (EDR).
This registry is based on a standard that existed way before XML was
born. There is often a need to tie back elements in XML
schemas/documents to their equivalent entries in the EDR, which is the
considered a "master" (using term loosely) registry of data element
names and definitions. There has been, and will continue to be, a great
need among all who interact with XML in such an agency to be able to tie
back the information in XML schemas/documents to the "master" registry,
in terms of element names, datatypes, formats, etc. This requires (in my
opinion) a large degree of human interaction with XML.
Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
"Simon St.Laurent" wrote:
>
> I spent a lot of May at XML-related conferences, first XML Europe and
> then Open Source Content Management (OSCOM, http://oscom.org). Both
> conferences assembled a diverse group of people, from programmers to
> managers to users looking around. Both conferences explored a lot of
> things that have been done with XML and could be done with it, and I was
> surprised by how XML seems pretty well assumed in presentations at
> OSCOM.
>
> Something seems to be changing, though, at least in the questions and
> conversations I'm hearing, not to mention the occasional keynote. XML
> has succeeded in becoming ubiquitous, but a lot of people are looking
> for better ways to deal with the vast volumes of information that are
> now accessible to them.
>
> For some projects, the XML processor + application consumer combination
> is all they'll ever need, and I think the original "XML spec -> XML
> processors, XSLT spec -> XSLT processors" kind of vision has mostly
> given us results that make people working on these projects happy.
>
> There seems to be a lot more concern expressed recently about projects
> where people need to interact with information on a regular basis, and
> where processing may be a multi-step mix of automation and human
> interaction. Some of the issues are pretty plain, things like the need
> for a DocBook editor, while others come from people who want to do
> things like intervene in automated processing under certain (sometimes
> error, sometimes not) conditions.
>
> These concerns seem to apply to development at pretty much all levels of
> work. I had a long conversation about character entities and XInclude
> at OSCOM, as well as conversations with people longing for friendlier
> human interfaces to RDF, SOAP, DocBook, and XSL-FO. The frustrations
> seem to lie in the gap between the computer-to-computer communications
> that have become a staple of XML processing and the continued desire of
> humans to play roles in that process - as information creators,
> consumers, editors, and mediators.
>
> I didn't hear tremendous outrage - it was more like growing frustration.
> People have grown comfortable enough with their tools that they know
> their limitations now, and there's a blessed absence of "I expected XML
> to magically solve my problems". A lot of people looking for tools
> hadn't heard of particular solutions, but there are still a lot of times
> when I certainly didn't have an answer for a problem.
>
> At any rate, it seems like we could enter a new phase in xml-dev's
> mission of "supporting XML implementation and development." Perhaps it's
> time to look around at how this list can help developers with their
> current interaction problems, much as it helped earlier developers with
> their needs for parsers, processors, and explanations.
>
> Personally, I'm going to spend what time I can this summer focused on
> the many problems of entities, and building tools which help users cope
> with things like missing entity declarations and the need to preserve
> (or re-insert) entitity references when processing is complete. I have
> a program-accessible foundation and a workable command line, but feel
> that more user friendly approaches are necessary. While I'm still
> working in the plumbing, I'm hoping to make plumbing a more pleasantly
> interactive business.
>
> Maybe focusing more on human interactions with XML could let us leave
> behind some of the permathreads centered on automated processing,
> notably the namespace ones.
>
> --
> Simon St.Laurent
> Ring around the content, a pocket full of brackets
> Errors, errors, all fall down!
> http://simonstl.com -- http://monasticxml.org
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
begin:vcard
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard
|
