SPUG: SGML the past language of..

Fred Morris m3047 at inwa.net
Fri Dec 13 21:33:05 CST 2002


Michael Wolf writes:
>m3047 at inwa.net (Fred Morris) writes:
>
>> SGML has been
>[...]
>> commercial companies won't be cashing in on XML without really
>> telling it like it is.
>
>What do you mean "really telling it like it is"?  How is it?

How it is, is that XML is an offshoot of SGML.

SGML has been utilized for some time now in mechanical systems design and
documentation. Additionally, there are large government-sponsored research
and development activities, and in some cases deployments, which have gone
on in parallel but overlapped; working groups have gotten together to
define basically XML, the common metadata, to describe and integrate these
domains of knowledge.

It's a management issue. There's a records management issue which plays
large in this, too. Some of this information is very sensitive. Some of it
some people would like to see destroyed; other people would like to see it
preserved; often, the motivations are entirely disjoint.

In any case, most of this is happening out of the public eye. But a great
deal of work has been done on it, at public expense.


What I mean by "cashing in" is largely monetizing. You may or may not be
aware of a recent MITRE Corporation study on "FOSS" which put Microsoft in
a snit. Come on Michael, you've been in this racket long enough to see all
of the bad patents, and the attempts to sell us what we already paid for as
taxpayers, and the recycled concepts and technologies sold as "new". This
applies not only to the technology for manipulating the data, but to the
data as well. Why are these entities working so diligently to describe
common metadata? Because it makes the information more valuable, and more
accessible.

>> None of this invalidates
>[...]
>> but you ought to know about its origins.. or at least know enough to
>> ask.
>
>OK, I'll bite.  How is it?  What are its origins?  I don't see the
>dark side you appear to be pointing to.

Well it is "dark"; I'll grant you that. If you mean "sinister", I never
claimed that. "Monetization" is oftentimes odious, when new "rights" are
created in something which abrogate other established rights. This doesn't
apply just to the technologies for managing data, but to the data itself;
and "valuable and accessible" may mean that that value and accessibility
accrues to the common good, or it may be that that enhanced access is
concentrated among a select few and more accessible and valuable to them.

Now, it's not all monetization. Records management is an interesting
discipline in its applications, although the stuff of it is as dry as tax
law. One of the more intriguing aspects of records management is retention
guidelines: the notion that you have to preserve records for a certain
period of time, and that all of the records have to be destroyed when that
period of time expires. This is an important notion in a litigous society
such as ours, as if you can prove that you have and adhere to good records
management practices you're not likely to find all of your information
systems sequestered and a gaggle of auditors looking at every scrap of
paper in your organization as a result of a discovery motion predicated on
your sloppy records management practices: if there's nothing to find,
there's no reason to look. And, you're not not likely to find yourself
liable simply for destroying the records in accordance with your
established records management guidelines.


I'm looking at this in a much larger context, I suppose, than mapping of
the human genome. It's fine and good for people to develop tools to
manipulate a large body of information; but should part of that be enough
of a sense of social responsibility to ask whether it is foreseeable that
the tools developed will be utilized for purposes far beyond your own
little playpen? Given the large expenditure of effort which has gone into
records management in an XML-like argot, isn't it likely that those tools
will be applied to new domains, and isn't it the whole point of XML-like
definitions to make it easy to do so?

With better records management, might we have a better idea exactly what's
bubbling in those tanks at Hanford? Perhaps. But would we have ever learned
about the Green Runs? Would we ever have learned about the syphilis
experiments on poor black men? The conflict-of-interest cancer treatment
scandal at The Hutch? Would we have learned as much as we have about Enron?

I don't know the answers; I'm asking. The genome project has a downside,
including but not limited to the possibility that analyzing individuals'
genetic code will be the phrenology of the 21st century, or how about
tailored bioweapons, and my greater question parallels the whole genome
issue, I suppose: are people thinking about the greater ramifications of
the information analysis and management tools they're creating? Nor am I
entirely convinced that all of these tools are being created afresh, as
fruits of the genome project; and are people thinking "where did this come
from, and why"? Everybody knows that the technology which makes the
Internet go was instigated by the Department of Defense as a research
project into survivable networks, and that this technology was deployed by
government agencies in order to (surprise!) share and manage information
and information processing resources.

>> The bureaucracy which usually goes along with it is a large part of
>> the process.
>
>Agreed.  You mention the down side, Bureaucracy.

I didn't see "bureaucracy" as inherently a "down side". I do think it is
worth asking: is bureaucracy a downside? What kind of bureaucracy is it?
Can we have a bureaucracy which has an upside? Can we discover things about
our bureaucracy by examining the fruits of its labors? Will we and do we
have the freedom and access and ability to do so?

The "bureaucracy", or at least the government, created the Internet. Why?

>I'll hilight the
>flip side.  Perl is as interesting to me for the culture as it is for
>the technology.  To quote Larry's wife (sorry, I forgot her name) when
>I asked her about language and culture (specifically Perl), she
>replied (as a linguist, and right-hand partner of Larry, and
>therefore, very much, a pillar in the design of Perl6) "you can't
>separate language from culture".
>

That makes it true? That makes it more than a factoid? Does one determine
the other?

Granted, there are a lot of interesting characters in the Perl culture. ;-)
But is it really because of Perl, or because of Ingy's leather pants?

If the bureaucracy uses Perl, then is it a Perl culture?

>
>> Why is it that the cart before the horse doesn't work?  Ducks fly
>> fine, seems to me.
>
>Is this some "center of force vs. center of resistance" analogy, or
>have I missed the Flying Walinda duck-horse cart act?

I apologize, that was obtuse. I assert that this notion that XML "comes
first" or is "new" is a canard. But I was pointing out that canards fly
just fine that way, and that sometimes it is easier to push a cart uphill
than to pull it (it also maneuvers better, at the loss of some directional
stability).

Just be aware of what you're doing, is all. XML may not be "better", it may
just be what the bureaucracy already understands. I count myself as
profoundly underwhelmed, and my experience with gene jockeys is that
they're probably more interested in your knowledge of primers and dimers
than regular expressions.

--

Fred Morris
m3047 at inwa.net



 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://seattleperl.org




More information about the spug-list mailing list