Re: Loss of information going from SGML to XML

Dave Hollander wrote:
> 
> Len,
> 
> That Peter MR is an early indicator of how XML will be received by the
> SGML audience, is a point well taken. Perhaps we should consider a "Guide to
> Moving from SGML to XML" to help prevent surprise and confusion.

Yes.  It should be printed and given out at the XML GCA Meeting.

> Befor we consider changing the design based on one person's reaction we
> should first understand the nature of the reaction which the wg list
> did. Then, we should consider if this case is compatible with the
> design goals.

I think it is compatible.  Again, something to be fixed with software.
Where we should be stirring up interest is in the universities:  iow, 
put those mythical CS/BS students to work making some applets and 
perl scripts.  Hey, there is a fellow in the UK building a MIDWriter, 
so they must have time on their hands.  :-)
 
> As I recall Peter's initial dismay/confusion, it was that he would have
> to make changes, not the nature of them.  The design never assumed that
> existing SGML applications would be XML complient, just that it would be
> straight forward to make the application complient.

Right.  But he is a great bellweather.
 
> Since Peter's case is not really what we were designing for, then we
> should consider how XML is described and what types of support various
> audiences will need. 

Hmm.  I think he is a good exemplar.  He has an application for 
which he used SGML and TCL/TK as I recall.  In fact, his interface 
is very similar to the kind of editors I advocate for SGML (wysiwyg and 
SGML are a tough marriage).  So from my perspective at least, his 
application is ideal.  It has a narrow domain of application, a well 
thought out interface, a good grasp of SGML, yet isn't hard over 
into the "SGML Way" which IMO, is what holds us back.  We spend too
much time being sheepdogs nipping at the heels of the developers.
For good or evil, at least Andreesen et al had the good sense to 
tell us to go to hell over that.

> Here, Peter's case has really helped. Not only
> should the nature of the transform be described, there needs to be work
> with various vendors and standards bodies to address the issues with
> entities. Given the nature of the group, we must rely on the market to
> address these needs.

I disagree just a bit.  A lot of us ARE the vendors, writers,
marketeers.
What we should note is the bellweather.  How could the FAQ and addenda 
be improved to help someone making the transition?  What are the cases 
where that transition would be desirable (e.g, want to use my SGML 
production tools but deliver in XML)?  What pieces of software make 
that transition more productive?  What is the effect of the crabwalk 
on the production cycle?   I know it is still early, but with a 
conference coming up in San Diego, it's not too early to talk 
strategies for XML developers.  Who are they?  The mythical 
CS grad is too nebulous a target.  Who is actually out there and 
what do they have to work with right now?

Here is one:  I think we will find that in many cases, 
the same people who use Visual Basic IV to develop applications, then 
use say, Active X Web components, may be the ideal candidates for 
XML developers if they just had the components.  I say again, that 
tree object in VB IV looks a lot like the TCL/TK object Peter used.
So, what is the case for an XML component that interfaces to the 
AddItem method? (providing they fix the security hole of course).

These are just suggestions.  The market may provide, but we can 
tell them a lot about ingenious cheap ways to do that.

XML must be easy and cheap.  Paoli wasn't wrong.

len

Received on Friday, 21 February 1997 18:06:43 UTC