Proposal for src files

[W. Eliot Kimber]

At 08:51 AM 4/2/98, Peter Murray-Rust wrote:
>At 11:22 01/04/98 -0600, W. Eliot Kimber wrote:
>
>>But maybe I'm just a crank.
>
>No. But you have a level of vision and understanding that makes it
>difficult for others like me to follow. This is a recurring theme in the
>whole of current  IT/CS - there are 'right' solutions that people simply
>are not able to comprehend or find too difficult to adopt.  In those cases
>one ends up with a small number of people who provide a solution (often at
>high cost) to a large number of people who don't understand an don't own
>it. IMO the single most important thing about XML is that it makes things
>accessible to at least a hundred times more people than other technologies.
>We are seeing this debate frequently now - 'what does XML do that XYZ
>doesn't?' My answer is that it can relate to ordinary hackers - and
>possibly even to inspired management.

I certainly appreciate Peter's comments here--he's 100% correct. The
distinction I try to make is this: a relatively small number of enterprises
have serious problems that can only be solved by things like full SGML, the
whole of the HyTime standard, the DSSSL transformation language, and other
"big" solutions to hard problems. That's the environment I like to work in.
But not everyone needs this level of solution. Thus XML and its related
specifications.

At the same time, I know that most enterprises' challenges are more
involved then they may think or may want to admit, which means that in many
cases, the simpler solutions provided by XML will not be sufficient, which
means that they'll need to start using some parts of the more complete
solutions--not all of them, just those parts they need. The challenge is to
bridge the conceptual gap between the entry level of XML and the full
solution provided by the big standards. I certainly agree that saying "just
read ISO/IEC 10744" is not a productive way to do it. But the problems are
real, solutions have been thought out and, to some degree, implemented
already, so there is value there once you're ready to go get it. But until
you're ready, it's just noise. I appreciate that.  I see my job as helping
people to bridge that gap.

I think the real problem is that complex information management challenges
are complex--there are no simple solutions. Complexity conserves. The best
you can do is concentrate the complexity so that it can be hidden from
those who are not responsible for managing it. But the complexity has to go
somewhere.

Look at automobiles. Twenty years ago, anyone who could read could fix
their new car--all it took was a shop manual, a few tools, and some
patience.  Cars were simple, but they failed to address a number of
problems, like fuel efficiency, safety, emissions. They needed to be tuned
every few thousand miles. Today, you cannot do more than change your oil
unless you are a factory-trained mechanic with lots of expensive tools. But
cars are much more fuel efficient, safe, and clean. They can go 50 or 100
thousand miles without a tune up.  The complexity has been concentrated
where before it was distributed.

There's a place for both. I have a car I can fix and car I can't. I use
HTML for quick fun and full SGML for more involved fun. I wouldn't drive
across the country in my MGB and I wouldn't entrust my business-critical
data to HTML.  

>>except in the most trivial way (a direct transliteration of DTD syntax)
>
>I was thinking of something very trivial (you didn't expect anything else
>from me, surely :-) - a lossless translation of DTD to XML format (and vice
>versa) without any inheritance, mapping, etc. I thought this was
>uncontroversial - but maybe I haven't got my point over.

>>unless it is *explicitly* defined as a base architecture with very clear
>>rules for specialization. And even then, developing that architecture will
>>be difficult at best.
>>
>>The reason it's practically impossible is because getting agreement among a
>>community of interest as wide and varried as the XML community on a subject
>>of such importance as how to represent the definitions of document types is
>>one of the hardest types of things there is to do. There are simply too
>
>I wasn't trying to tackle this. We already *have* a definition of document
>types - it's XML 1.0. I was simply suggesting we standardised an XML-based
>syntactic representation of this.

Ah. My point is that, if that's all it is, why bother? If you can parse
DTDs sufficiently to generate XML versions, why bother generating the XML
version? You've already parsed the thing the data's already yours to
manipulate.  If you do want the XML version, then go back into the c.t.s
archives and find Wayne Wohler's posting (I'm sure he posted something
about it). In any case, it's a pretty obvious design effort and the result
should be uncontroversial except for some arbitrary design choices (use
attributes? etc.). 

>>The minimum abstractions needed to define element types are already defined
>>by the SGML property set--if your schema language can get you to these
>>abstractions, fine.  
>
>Perhaps all we need is a representation of the property set in XML format.
>Would *that* be controversial?

I've created it. Check out "http://www.hytime.org/materials/hi2pssgm.xml"
(created from the SGML property set definition document published in
ISO/IEC 10744 using SX).  I believe there is work to define an XML-specific
version of the property set that is organized and presented in a way that
is more appropriate for the XML audience (I would not, by any stretch,
pretend that the property set document is an accessible document as
currently formulated--it's very useful as a formal specification, not too
useful as a tutorial introduction to the SGML data abstraction.).  However,
a tree view of the document goes a long way toward making it easier to work
with. I'm developing a tool that will, among other things, provide
navigable tree views of property set documents. Watch this space.

I also appreciate Tim's disagreement with my position. It is a subject on
which reasonable people can disagree [I'm reminded here of the excellent
childrens' book *The Phantom Tollbooth*, where the main character does the
impossible because no-one told him he couldn't do it.]. If the effort
succeeds, that's good.  But my experience suggests that it's going to be a
lot harder than it might look at first. I also feel that it's too early in
the day to start standardizing--we need more experience. There's a lot of
good thinking on schemas in general that needs to be examined and
synthesized. 

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
Highland Consulting, a division of ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 95202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)