Have a look at the XML equivalents - XLink and Xpointer. I am not aware as
to their state of readiness but this effort has been underway for at least
if I am not mistaken.
-----Original Message-----
From: Rachel Foerster [SMTP:[EMAIL PROTECTED]]
Sent: Tuesday, September 05, 2000 11:55 AM
To: [EMAIL PROTECTED]
Subject: RE: XML Schemas/DTD for HealthCare Industry
James,
Thanks for the pointer to HyTime. I plan to fetch that document and
become
more familiar with it. A quick review of the abstract leads me to
believe
that it was developed as part of the SGML family of standards. On
the other
hand, it's my understanding that XML was developed to address the
complexity
of SGML and to address the barriers to its further implementation
and
deployment. In other words, SGML-lite???
Both traditional EDI (whether X12 or EDIFACT) and SGML suffer from
some of
the same challenges to implementation: complexity and cost. And both
appeared to have plateaued in their rate of implementation and
deployment.
It is for this reason that many believe/hope that XML will offer a
less
complex, less costly solution to automated electronic data
exchanges. Let us
hope so. Only time will tell. Right now it's a Tower of Babel with
nothing
interoperating. This is the core issue that the ebXML Initiative is
addressing in developing a standard global framework to enable
interoperable
XML-based document exchange over the Internet - and most
importantly, to
enable the development of affordable plug and play solutions so that
the
small organizations can also get in the game with the big guys.
Rachel
-----Original Message-----
From: james anderson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 05, 2000 5:21 AM
To: [EMAIL PROTECTED]
Subject: Re: XML Schemas/DTD for HealthCare Industry
My original note (please see below) was intended to address Ms
Foerster's argument, that one of XML's features would likely
confound
the difficulties inherent in information exchange rather than
alleviate
them. I attempted to suggest that one feature to which Ms Foerster
drew
attention (independent tag selection), when taken together with
certain
techniques established as an aspect of HyTime (that is, ISO
10744:1997
-- Hypermedia/Time-based Structuring Language)[1], as described in
the
chapter "A.3 Architectural Form Definition Requirements (AFDR)"
under
the name of "enabling architectures"[2], would permit the
formulation of
automated techniques to perform the requisite translations,
transliterations, transcodings, and/or transformations. The
techniques
were developed in relations to SGML, but have been demonstrated to
be
just as applicable to XML. XSL, as alluded to by Mr Kammerer, can be
used to effect equivalent transformations.
These techniques, and similar ones not yet developed, which take
advantage of the meta-information intrinsic to XML-related
standards,
permit interchange mechanisms which alleviate the noted problems
rather
than exacerbating them.
I made, and make, no attempt to address the larger process issues.
Neither transactional and workflow aspects of the automated
processes,
nor the political and social issues concerning reaching semantic
agreements. My note neither implied nor stated that "it should just
all
work." It stated just that original message implied a conclusion
which
was incorrect.
I've spent my time with COBOL. Don't go there. That one can is the
limiting case for that one should.
[1] HyTime: http://www.oasis-open.org/cover/hytime.html
[2] Enabling Architectures:
http://www.ornl.gov/sgml/wg8/docs/n1920/html/clause-A.3.html
----------------------------------------------------------------------------
----
"William J. Kammerer" wrote:
>
> David RR Webber chided Rachel Foerster: "I believe what James
[Anderson]
> was trying to tell you was that the W3C Schema has this all solved
> already with their datatyping and structure methods based on an OO
> approach. All we have to do is get everyone using this
consistently and
> the parsers upgraded and it should just all work."
>
> Rachel retorted "...you know as well I as that the W3C has not yet
> approved an XML Schema Recommendation."
>
> Dear David:
>
> Nobody is arguing that XML isn't an "enabling architecture," to
use
> James' words. I assume, as Rachel may have, that with whatever
XML
> schema is eventually birthed by the W3C we'll pretty much be able
to
> describe and constrain the syntax of any XML document. And with
XSLT, we
> can pretty much transform anything that looks like XML into
something
> else that looks like XML. I guess that's what James meant by
"enabling
> architecture." But, so what? COBOL and flat files can do all
that
> stuff already; so can EDI and translators (or COBOL programs).
>
> In any case, "it should just all work" simply ignores the effort
that
> goes into getting two or more organizations interested in a
message
> domain to agree on the formats, tags, structure, etc. to convey
> agreed-upon business semantics. Rachel pointed out ebXML, but the
same
> give and take (and politics) goes on in the vertical groups like
OTA,
> RosettaNet, etc. etc. Once you have two or more organizations
that need
> to talk, some necessary sclerosis sets in and you can no longer
move at
> "Internet speed."
----------------------------------------------------------------------------
----
my original note:
james anderson wrote:
>
> The argument below is spurious. XML with schema supports value
domain
> specifications. It also supports tag specifications. XML with
"enabling
> architecture" techniques also allows automated tr[a]nslation
between tag
sets.
>
> Rachel Foerster wrote:
> >
> >
> > Lastly on the issue of using XML -- since XML is extensible that
means
that
> > the originator of the XML document gets to choose the tag names.
Just
> > imagine if you would, a situation where each provider generating
a
health
> > care claim chose not only their on tags but data content along
with the
data
> > attributes. We'd be even worse off then now, with only (!) 450
+/-
> > proprietary formats!
> >
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
