[austechwriter] Re: I'm not sure how well a strict XML structure would work in the real world

Can anyone recommend a good XML book for beginners? (A timely question =
from one of my business analysts - and it's probably not a bad idea for =
me to start looking at one, either).




-----Original Message-----
From: tcusack@xxxxxxxxxxxxxxx [mailto:tcusack@xxxxxxxxxxxxxxx]
Sent: Wednesday, 28 May 2003 10:54 AM
To: austechwriter@xxxxxxxxxxxxx
Subject: [austechwriter] Re: I'm not sure how well a strict XML
structure would work in the real world


Quoting Steve Hudson <cruddy@xxxxxxxxxxxxxxxx>:

> 3) A couple of examples of stuff I am pretty sure we can do in XML but =
not
> in HTML.

Sure, so far as XML tags & attributes are concerned: <myDate =
fmt=3D"sensible">28=20
May 2003</myDate>. But XSL doesn't include any date functions so you'd =
have to=20
build your own.

>=20
> Date tags with the date format tagged as well
> Prices tagged with whether it includes GST.
>=20
>=20
> 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.

Oh, that's what I meant as well, so I don't see the problem. Any =
technology=20
that includes a text source for the formatting device to read is =
amenable to=20
XML-XSL. Currently this means HTML, PDF via XSLT:FO and now that MS have =
come=20
to the party, Word docs. Not suggesting that the transformations are =
easy, but=20
they will become widely available over the next 18 mths or so.

ciao,
TC.

>=20
> E1) LOL.
>=20
>=20
> Steve Hudson
>=20
> 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...
>=20
> The VBA Beginner's Spellbook: For all VBA users.
>=20
>=20
> -----Original Message-----
> From: Tony Cusack
>=20
> 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.
>=20
> 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).
>=20
> 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.
>=20
> 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.
>=20
> ciao,
> Tony.
>=20
>=20
> ----- 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
>=20
>=20
> > 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
> > **************************************************
>=20
> **************************************************
> To post a message to austechwriter, send the message to
> austechwriter@xxxxxxxxxxxxxx
>=20
> To subscribe to austechwriter, send a message to
> austechwriter-request@xxxxxxxxxxxxx with "subscribe" in the Subject =
field.
>=20
> To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx =
with
> "unsubscribe" in the Subject field.
>=20
> To search the austechwriter archives, go to
> www.freelist.org/archives/austechwriter
>=20
> To contact the list administrator, send a message to
> austechwriter-admins@xxxxxxxxxxxxx
> **************************************************
>=20
> **************************************************
> To post a message to austechwriter, send the message to
> austechwriter@xxxxxxxxxxxxxx
>=20
> To subscribe to austechwriter, send a message to
> austechwriter-request@xxxxxxxxxxxxx with "subscribe" in the Subject =
field.
>=20
> To unsubscribe, send a message to austechwriter-request@xxxxxxxxxxxxx =
with
> "unsubscribe" in the Subject field.
>=20
> To search the austechwriter archives, go to
> www.freelist.org/archives/austechwriter
>=20
> To contact the list administrator, send a message to
> austechwriter-admins@xxxxxxxxxxxxx
> **************************************************
>=20





------------------------------------------------------------
This email was sent from Netspace Webmail: http://www.netspace.net.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
**************************************************

Other related posts: