[austechwriter] Re: I'm not sure how well a strict XML structure would work in the real world
- From: "Steve Hudson" <cruddy@xxxxxxxxxxxxxxxx>
- To: <austechwriter@xxxxxxxxxxxxx>
- Date: Wed, 28 May 2003 09:04:43 +1000
3) A couple of examples of stuff I am pretty sure we can do in XML but not
in HTML.
Date tags with the date format tagged as well
Prices tagged with whether it includes GST.
4a) I meant turning a set of delimited data constructs into a nicely ruled
up column and row layout effect :-) It's a table of data that needs to be
laid out as a human-viewable table.
E1) LOL.
Steve Hudson
Word Heretic, Sydney, Australia
Tricky stuff with Word or words for you.
Email: word_heretic@xxxxxxxxxxxx
Products: http://www.geocities.com/word_heretic/products.html
Spellbooks: 735 pages of dump left and dropping...
The VBA Beginner's Spellbook: For all VBA users.
-----Original Message-----
From: Tony Cusack
Hi Steve,
2) I'll be distributing some standard XSLTs 'sometime' this year.
3) As I say DTDs are for me highly desirable but not essential. So far as
coming up with a generic doc model is concerned my argument is that it's
already here by way of HTML. HTML is the lingua franca of electronic
publishing - just about everything will pass through that filter at some
stage in its life cycle. So why not adopt it as the bottom line model. I'd
love to hear some ifs and buts on this.
4) Not sure what you mean by table tables. But given an XML structure to
begin with I don't believe there's any other structure (ie whacky exceptions
excepted) that can't be derived from it with XSLT. There are of course other
transformation languages re which I know next to nothing.
4a) Yeh, again I know little about typesetting. But XSLT:FO works a treat
for the kind of hard copy that you or I might be asked to produce on a
techwriting gig.
4b) Whew a litany of dunnos. But, to change tack a little - my beef is with
the perception that DTDs are essential to XML. Its designers did the world a
big service by providing the less demanding rules of well-formedness, and my
criticism is that that fact is often overlooked. But I'm not blind to the
fact that the additional functional they support will be essential in many
contexts and highly desirable in others.
An Essential context is web-services - a topic which doesn't seem to have
got much of a trot on this list although I'm pretty sporadic in
monitoring-participating. A highly desirable context is drop downs in
editing interfaces such as you mention in 1).
Main point: the DTD syntax is itself pretty simple. They shouldn't be an
issue in a well established production process. But they can be a pain in
the neck when you're developing, so baste before you garnish.
E1) For my sins I got to be the writer for the Solution 6 Tax package a few
years back. So tell me about ELF ('though we called it ELS for service). All
this (yr trade eg too) will be defined as web services in the next couple of
years.
ciao,
Tony.
----- Original Message -----
From: "Steve Hudson" <cruddy@xxxxxxxxxxxxxxxx>
To: <austechwriter@xxxxxxxxxxxxx>
Sent: Tuesday, May 27, 2003 10:48 AM
Subject: [austechwriter] Re: I'm not sure how well a strict XML structure
would work in the real world
> Dear Tony,
>
> some excellent points here, a few very close to my heart.
>
> 1) Agreed, and nice howevers.
>
> 2) Totally agreed, I have been raving about, and pushing developers for
> ages, providing some gorgeous XML tools that build DTDs from a simple GUI
> (hand tweak if you want finesse, most of us want simple, repeatable
stuff).
> Standard XSLTs could also be built - and even integrated into the provided
> toolset. A simple example, the HATT systems could have a dropdown with
> audiences listed that would change the provided content. Skins could be
> modified on the fly for those people with visual difficulties and so on.
> <Rave mode detected, autoshutdown commencing in 3 words. Three, two one.
> CARRIER DROPPED>
>
> 3) Something addressable by said tools in 2). Problem is, most developers
> are waiting for MS to take a direction :-( After all, they are the boys
with
> the big bucks right? And whoever develops these tools will sure as shit
see
> MS rip them off. Not good. Time for another HotDog I think, the current
> organisations seem too complacent and cautious. I might have to start
> looking further afield into hackerdom <shudders>. Man, if you want to
<Rave
> mode detected, autoshutdown commencing in 3 words. Three, two one. CARRIER
> DROPPED>
>
> 4) Disagree. Tables are structured data and fit neatly into an XML schema.
> However, the presentation transform then needs to convert them into table
> tables.
>
> 4a) AFAIAC, the most difficult problem for XML is flowing into print. Each
> hand-setup we see in books is monstrously difficult and forbiddingly
> time-consuming to perform for each possible combination of tags when we
are
> talking about very rich, highly structured data. However, auto-setting
> technology is improving slowly and given the proliferation of unset type
> this may not be such an issue to the next generation. Other than myself -
an
> observably insane person anyway - who cares about auto-hyphenation under
the
> age of 40 anyway? :-)
>
> 4b) You then raise the insurance form thingy. This is, unfortunately for
> your argument, an excellent example of why business needs XML. Don't
forget
> Tony, Big Business made COBOL. At least the XML principle is
understandable,
> but the DTD looks like COBOL won again. LOL!
>
> Lets take a few existing, simple examples. I know I repeat, but history
> points to our future.
>
> E1) The ATO introduced a little thing known as an ELF back in the early
> eighties. It revolutionised the tax industry. It facilitated the
> streamlining of returns from many months to a few weeks. It's an
Electronic
> Lodgement Form. You can now generate these direct from software and send
> them in by the net. My old man was doing it for his clients as he owned
and
> operated a small accountancy business using mini computers. He was pleased
> as well, profits grew and he took on more staff and partners.
>
> E2) The shipping and customs industries internationally have used a
> standardised EXIT form from the late eighties. It revolutionised
> international shipping, reducing error rates, delivery times and
processing
> inefficiencies whilst increasing the control and flexibility. Governments
> and businesses alike were able to exchange meaningful information with a
> minimum of fuss on a global scale.
>
> So, the very bottom line of business requires the use of standardised data
> exchange on many levels. Business requires control. In the real business
> world, a strict XML structure for data components is almost a certainity.
> What we need is the tools to make it happen. At the present point the best
> tool is the human mind version 2003 through Notepad. The tool needs
training
> and the best place in Aus for that is the AODC.
>
> Steve Hudson
>
> Word Heretic, Sydney, Australia
> Tricky stuff with Word or words for you.
> Email: word_heretic@xxxxxxxxxxxx
> Products: http://www.geocities.com/word_heretic/products.html
> Spellbooks: 735 pages of dump left and dropping...
>
> The VBA Beginner's Spellbook: For all VBA users.
>
>
> -----Original Message-----
> From: Tony Cusack
>
> Hello all,
> This is my second attempt to post this, so apologies if you've seen it
> before.
>
> But following on from last week's discussion re Word & Frame and 'font
> fondling' vs structured and all that, I (as unabashed XML proselytizer)
feel
> I have to draw attention to a couple of facts.
>
> First is this: YOU DO NOT NEED A DTD TO RUN XML
> Sorry about the caps, but it's such a widespread misconception that the
> contrary is true. Certainly if you want to validate the XML file then you
> must have a DTD (or other rules file). But XML has so much to offer apart
> from validation that it's a shame to see techwriters dismissing it on
> account of a complication that isn't relevant to 90% of the work that they
> do. Sure if you're in Bill Hall's situation (Defence, stringent content
> control, high volumes) then you'll be buying into the full catastrophe.
But
> others should be aware that XML has introduced (as a qualification to the
> stricter, more complex & powerful SGML) what could be described as an
'entry
> level grammar' . The so called rules of WELL-FORMEDNESS prescribe a very
> simple structure that a document must have in order to be processable by
an
> XML aware application.
>
> This fact qualifies the following Mike Buckler statements.
>
> Authoring XML/SGML is definitely slower. There are several reasons.
>
> 1) Using a DTD as complex as Docbook requires many hours of study.
> True, but why a DTD? And even if you're using one, why DocBook. My point
is
> that the questions should be put - there are of course good reasons for
> both, in some circumstances.
>
> 2) The current crop of XML/SGML aware tools are not particularly user
> friendly.
> This is off the present topic but I'd have to differ again: XML Spy is the
> goods IMHO; I can't comment on others 'cause I haven't seriously tried
them
> (no need to :-)
>
> 3) If the DTD doesn't fit the type of document exactly, then you can
> spend as much time revising the DTD and style rules as actually
> writing the document.
> As for 1 above. And Spy (and other tools) will reverse engineer a DTD from
> an XML document.
>
> 4) Things like tables do not fit into the classic XML/SGML model. This
> is where presentation (column and row layout) comes into play and
> messes up the whole point of using XML/SGML in the first place.
> I'm at a loss to understand where this comment is coming from, but venture
> the following. I suspect that Mike has formed his opinion under the
> influence of DocBook. DocBook is a very rich DTD and will save lots of DTD
> developers lots of work over the long term. But its default table model is
> CALS which (I believe) is of longstanding use in the defence/aerospace
SGML
> community. CALS is somewhat more complex than the much more widely
> understood HTML model, and translation between the two is less than
> straightforward (but no more than a few hours work for a competent XSLT,
> Perl, whatever, scripter).
>
> But for most techwriters most of the time this is all pretty esoteric.
There
> is no 'classic model'. Describe your table as you would in HTML and worry
> about more complex models as and when the need arises.
>
> The current hype around XML is mainly to do with data interchange
> between application that do data processing. For example an insurance
> claim form where a set number of fields must be completed in order to
> create a "valid document".
>
> I don't know that the hype is quite current (I thought it peaked a couple
of
> years back, but maybe that's just me) - but the distinction between data
> centric and document centric XML is important. It's true that most of the
> XML development focus through the e-commerce period has been on data
centric
> forms such as Mike cites. But SGML was designed for narrative style
> documents and XML is only slightly less capable in that regard. For myself
> I've spent a good deal of time figuring out the XSLT necessary to navigate
> narrative style doc structures, wondering all the while what the much
> vaunted implementation of XML in Word would mean. Well now that it's here
> (in beta) I can say that the good news (and fact number two in this little
> spiel) is
>
> WORD 2003'S XML FUNCTIONALITY IS NOT PROPRIETARY
> How so? Because the standards bar is actually quite low. As I've pointed
out
> earlier an XML doc need only conform with well-formedness rules to 'be'
XML.
> It's true that Word 2000's Save as Web Page conversion introduced some
> shonky syntax. But that's all gone in the 2003 save as XML functionality.
> What you get is pretty much what you always got in RTF, a complete
> description of the doc with content and formatting closely juxtaposed,
> except that it's now expressed in XML. The 'close juxtaposition' makes it
a
> bit laborious to step around all the formatting tags (when XSLT
processing),
> but it's quite doable.
>
> Fact number three: INTERNET EXPLORER AND NOTEPAD ARE ALL YOU NEED TO DO
XML
> Well, if we're talking 'real world' then it's unlikely that you'd limit
> yourself to these. I guess my point is to urge writers such as Elizabeth
who
> are wondering what the go is with XML to start experimenting. The outlay
> isn't financial it's time spent learning the standards, namely XML, XSLT
and
> CSS/HTML. XSLT is the most difficult of these but by no means the
proverbial
> rocket science. I'd rate it about 60% the difficulty of VBA.
>
> Is it worth it? There will always be a fair degree of subjectivity in that
> assessment but I'm confident that the coming together of public standards
> and Microsofts's implementations in IE and Office means that these skills
> will increasingly become 'core' for techwriters.
>
> Hello all,
> the operative word in Elizabeth's question is 'strict'.
> Forgive me for chasing the train well after it's departed the station. But
> following on from last week's discussion re Word & Frame and 'font
fondling'
> vs structured and all that, I (as unabashed XML proselytizer) feel I have
to
> draw attention to a couple of facts.
>
> First is this: YOU DO NOT NEED A DTD TO RUN XML
> Sorry about the caps, but it's such a widespread misconception that the
> contrary is true. Certainly if you want to validate the XML file then you
> must have a DTD (or other rules file). But XML has so much to offer apart
> from validation that it's a shame to see techwriters dismissing it on
> account of a complication that isn't relevant to 90% of the work that they
> do. Sure if you're in Bill Hall's situation (Defence, stringent content
> control, high volumes) then you'll be buying into the full catastrophe.
But
> others should be aware that XML has introduced (as a qualification to the
> stricter, more complex & powerful SGML) what could be described as an
'entry
> level grammar' . The so called rules of WELL-FORMEDNESS prescribe a very
> simple structure that a document must have in order to be processable by
an
> XML aware application.
>
> This fact qualifies the following Mike Buckler statements.
>
> Authoring XML/SGML is definitely slower. There are several reasons.
>
> 1) Using a DTD as complex as Docbook requires many hours of study.
> True, but why a DTD? And even if you're using one, why DocBook. My point
is
> that the questions should be put - there are of course good reasons for
> both, in some circumstances.
>
> 2) The current crop of XML/SGML aware tools are not particularly user
> friendly.
> This is off the present topic but I'd have to differ again: XML Spy is the
> goods IMHO; I can't comment on others 'cause I haven't seriously tried
them
> (no need to :-)
>
> 3) If the DTD doesn't fit the type of document exactly, then you can
> spend as much time revising the DTD and style rules as actually
> writing the document.
> As for 1 above. And Spy (and other tools) will reverse engineer a DTD from
> an XML document.
>
> 4) Things like tables do not fit into the classic XML/SGML model. This
> is where presentation (column and row layout) comes into play and
> messes up the whole point of using XML/SGML in the first place.
> I'm at a loss to understand where this comment is coming from, but venture
> the following. I suspect that Mike has formed his opinion under the
> influence of DocBook. DocBook is a very rich DTD and will save lots of DTD
> developers lots of work over the long term. But its default table model is
> CALS which (I believe) is of longstanding use in the defence/aerospace
SGML
> community. CALS is somewhat more complex than the much more widely
> understood HTML model, and translation between the two is less than
> straightforward (but no more than a few hours work for a competent XSLT,
> Perl, whatever, scripter).
>
> But for most techwriters most of the time this is all pretty esoteric.
There
> is no 'classic model'. Describe your table as you would in HTML and worry
> about more complex models as and when the need arises.
>
> The current hype around XML is mainly to do with data interchange
> between application that do data processing. For example an insurance
> claim form where a set number of fields must be completed in order to
> create a "valid document".
>
> I don't know that the hype is quite current (I thought it peaked a couple
of
> years back, but maybe that's just me) - but the distinction between data
> centric and document centric XML is important. It's true that most of the
> XML development focus through the e-commerce period has been on data
centric
> forms such as Mike cites. But SGML was designed for narrative style
> documents and XML is only slightly less capable in that regard. For myself
> I've spent a good deal of time figuring out the XSLT necessary to navigate
> narrative style doc structures, wondering all the while what the much
> vaunted implementation of XML in Word would mean. Well now that it's here
> (in beta) I can say that the good news (and fact number two in this little
> spiel) is
>
> WORD 2003'S XML FUNCTIONALITY IS NOT PROPRIETARY
> How so? Because the standards bar is actually quite low. As I've pointed
out
> earlier an XML doc need only conform with well-formedness rules to 'be'
XML.
> It's true that Word 2000's Save as Web Page conversion introduced some
> shonky syntax. But that's all gone in the 2003 save as XML functionality.
> What you get is pretty much what you always got in RTF, a complete
> description of the doc with content and formatting closely juxtaposed,
> except that it's now expressed in XML. The 'close juxtaposition' makes it
a
> bit laborious to step around all the formatting tags (when XSLT
processing),
> but it's quite doable.
>
> Fact number three: INTERNET EXPLORER AND NOTEPAD ARE ALL YOU NEED TO DO
XML
> Well, if we're talking 'real world' then it's unlikely that you'd limit
> yourself to these. I guess my point is to urge writers such as Elizabeth
who
> are wondering what the go is with XML to start experimenting. The outlay
> isn't financial it's time spent learning the standards, namely XML, XSLT
and
> CSS/HTML. XSLT is the most difficult of these but by no means the
proverbial
> rocket science. I'd rate it about 60% the difficulty of VBA.
>
> Is it worth it? There will always be a degree of subjectivity in that
> assessment. But I'm confident that the coming together of public standards
> and Microsoft implementations in IE and Office mean that these skills will
> increasingly become 'core' for techwriters.
>
> rgds,
> Tony Cusack,
> www.textology.com.au
>
>
> **************************************************
> To post a message to austechwriter, send the message to
austechwriter@xxxxxxxxxxxxxx
>
> To subscribe to austechwriter, send a message to
austechwriter-request@xxxxxxxxxxxxx with "subscribe" in the Subject field.
>
> To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx with
"unsubscribe" in the Subject field.
>
> To search the austechwriter archives, go to
www.freelist.org/archives/austechwriter
>
> To contact the list administrator, send a message to
austechwriter-admins@xxxxxxxxxxxxx
> **************************************************
**************************************************
To post a message to austechwriter, send the message to
austechwriter@xxxxxxxxxxxxxx
To subscribe to austechwriter, send a message to
austechwriter-request@xxxxxxxxxxxxx with "subscribe" in the Subject field.
To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx with
"unsubscribe" in the Subject field.
To search the austechwriter archives, go to
www.freelist.org/archives/austechwriter
To contact the list administrator, send a message to
austechwriter-admins@xxxxxxxxxxxxx
**************************************************
**************************************************
To post a message to austechwriter, send the message to
austechwriter@xxxxxxxxxxxxxx
To subscribe to austechwriter, send a message to
austechwriter-request@xxxxxxxxxxxxx with "subscribe" in the Subject field.
To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx with
"unsubscribe" in the Subject field.
To search the austechwriter archives, go to
www.freelist.org/archives/austechwriter
To contact the list administrator, send a message to
austechwriter-admins@xxxxxxxxxxxxx
**************************************************
Other related posts:
