Reasons to Structure

[Marcus Carr]

Jeremy H. Griffith wrote:

> Isn't that a tad harsh, Russ?  My point, which you appear to have 
> missed, is that (as Richard said) semantic markup is good, *and*
> that you can do it in unstructured Frame.  Do you deny this fact?

Wholeheartedly. Semantic markup only exists if it is expressed in a way 
that a computer can make use of it - structure exists expressly for that 
purpose. Considering a document to be semantically rich when the 
semantics cannot be easily exposed is a bit like writing the world's 
greatest novel in a language that only you understand.

I understand how the focus on this group is about how structure impacts 
on the authors and editors of data, but in fact structure wasn't created 
to make the lives of those people easier or more difficult. Structure 
was created to make information more useful, and people who create that 
information are simply along for the ride.

That's why I advocate the structural design being done by an information 
architect, because in the big picture it matters not a whit how the 
imposition of structure impacts those people, despite the fact that it 
may make for interesting discussion.

> I also said that for small groups, "the setup costs (time and 
> consultants) are likely to exceed the benefits".  I'll stand by
> that assessment, based on using Frame in both its unstructured 
> *and* structured (formerly known as "FrameBuilder") forms over
> many, many years, originally on a Sun 2...  I didn't say there
> are *no* benefits, just that the costs may be greater.  Do you
> assert that the costs are always insignificant, then?

The costs and benefits are at least partially unrelated to tasks of 
creating and editing data. The cost and the learning curve can look 
high, but if it's a corporate decision driven by IT needs, chances are 
those costs have been justified in another part of the organisation.

I do agree that if people are doing structure for the sake of it, or 
because they think that it will make their editing easier, they may be 
barking up the wrong tree. If you don't need structure, the cost of it 
may be prohibitive, though that just sounds like a truism.

> Assuming, that is, that you *have* the time.  Many of our
> colleagues, having survived downsizing from ten writers to
> two with no decrease of workload, do not.  And if you do,
> is that time better spent on learning nifty new tools, or
> on improving the docs you're paid to write?  One size does
> *not* fit all.  If you have a genuine *business* case for
> going to structured Frame (or if you are a hacker at heart, 
> like you and I), go for it.  ;-)

I agree with that. I'd add that if you can get your employer to pay for 
you to learn structure, then take advantage of it. In years to come, 
structure will become more prevalent - it has to as the semantic web 
emerges.

> The Web?  You don't consider HTML an example of structured
> content, do you?  It qualifies in only the most technical 
> sense... and most pages violate even its simple DTDs grossly.
> Or maybe it's not recent enough for you?

Yep, HTML was developed as a profile of SGML. Tag omission was perfectly 
valid in SGML, as long as the processor could infer the element 
boundaries. The fact that the browser makers were in a race to see who 
could accept the crappiest data isn't a reflection on HTML, it's a 
reflection on the browser makers. Besides, with XSLT being applied to 
XML to create HTML (and just the fact that people are getting used to 
XML) I suspect that the quality of HTML data on the web has improved 
over the past few years.

> However, more to the point, unlike the typewriter salesman
> I make *nothing* when people stay with unstructured Frame.
> You, OTOH, make your living from people who go structured.
> Perhaps it's the *computer* salesman you need to watch?  ;-)

My company hasn't done a structured FrameMaker application for a good 
few years, but I still get lumped with the odd support call. I certainly 
wouldn't say that I make money out of structured FrameMaker, though 
virtually all of our revenue comes from structured data.


-- 
Regards,

Marcus Carr                      email:  mcarr at allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
        - Einstein