RE: Structured stuff for the beginner

[<mbaker -at- analecta -dot- com>]

Hi Rick,

This is what I mean when I talk about constraints: A schema is a set of constraints. You must use these structures in this order. You impose the constraints so that you can write algorithms to process the content knowing exactly what structures you will find and what they are supposed to mean. 

An off the shelf DTP system is a closed structured writing system. The constraints and the algorithms are all written for you and can't be changed. 

We create custom schemas to implement custom constraints so we can write custom algorithms. A structured editor like Oxygen or Structured Frame can read a schema and impose those custom constraints on authors. If those constraints are in the document domain, it can also create a WYSIWYG display, so that you are then essentially building your own custom DTP system. 

That can be a good thing, because off the shelf DTP and generalized XML schemas like DocBook and DITA are both highly complex and loosely constrained, which makes them difficult to use, and difficult to write algorithms for. So, creating a custom DTP system with Structured Frame or Oxygen as your front end is a good fit for many applications. Similarly, MarkDown, which is an extremely simple document domain system is a good fit for many applications. 

But creating custom DTP systems is only part of what structured writing can do, and development of those capabilities and their use has been stalled for a long time because of lack of tools and support from consultants. 

While you are right the demand comes from customers, companies only strive to meet that demand when there is a model that allows them to make money doing so. I once worked for a company that made a programming language. It was licensed using server tokens, so you could only have as many local running instances as you had server tokens. This was at a time before it was routine for companies to have corporate-wide networks and when processors and I/O were still pretty slow. So as use of the product scaled up, demand for server tokens scaled up proportionately. But once processor and I/O speeds picked up and networks became ubiquitous the model no longer worked. An entire multinational company could have met all its needs with one server token. 

There needs to be proportionality between payment and usage or you can only sell to clients of one size.  The demand may be there, but there is no economic incentive to meet it, at least not in the commercial model. This is why much of the infrastructure of the net and of software development is open source. There is no commercial model for it. 

Mark 

-----Original Message-----
From: Rick Quatro [mailto:rick -at- rickquatro -dot- com] 
Sent: Wednesday, April 26, 2017 7:33 AM
To: mbaker -at- analecta -dot- com; 'Tech Writing' <techwr-l -at- lists -dot- techwr-l -dot- com>
Subject: RE: Structured stuff for the beginner

Hi Mark,

I am afraid you have lost me somewhere along the way. I am not sure where the constraints are with structured FrameMaker. I can use DITA, DocBook, or any other DTD, in structured FrameMaker. I prefer custom DTDs for most of my clients because, in many cases, it is better for them to design the structure around their content than forcing their content to fit an existing DTD like DITA. But of course once they have the DTD/schema they can use any editor they want. In FrameMaker you could even use a plain template for content authoring that may not remotely reflect your output at all. I sometimes call these "data entry" templates because it focuses the user on the content and structural development and not the ultimate presentation.

Also, your economic model is a little bit backwards. Ultimately it is not vendors who drive the market, it is customers. Vendors may slow things down by being slow to respond to client desires, but sooner or later customers get more choices and the slow vendors lose out. The success of Linux and open source tools in the internet world proves that.

While it makes a good story line to portray this as a "protracted and bitter ground war," I don't think this is about enemies and winners and losers. It is about different approaches and tools for meeting a huge variety of documentation needs that exist in the world. While I have an informed bias towards structured content, I gladly serve clients that are content using unstructured tools like FrameMaker and InDesign for their documentation.

Respectfully,
Rick


-----Original Message-----
From: mbaker -at- analecta -dot- com [mailto:mbaker -at- analecta -dot- com] 
Sent: Tuesday, April 25, 2017 1:48 PM
To: 'Rick Quatro'; 'Tech Writing'
Subject: RE: Structured stuff for the beginner

Rick,

What you describe is exactly how structured writing got stalled. WYSIWYG editors work by creating an abstract model of a document to which styles can be applied (either directly or through style sheets), plus some management domain structure to support management features. This is, in fact, a structured writing technique. It constrains the writer to write in the structures that the editors provide. 

Those structures are more or less consistent across all editors, but each has it individual features as well. With each, there always seemed to be one things or another you could not do, and you were dependent on the vendor to add support for that thing if you wanted to. This created a desire to escape vendor lock-in.

DocBook and DITA each follow the exact same model as the DTP tools: a set of abstract document structures to which styles can be applied for publishing, plus some management domain structures to support management features. Thus they do not break with the structural paradigm of WYSIWYG, they simply separate the structures it uses from the generation of the WYSIWYG display. (Thus you can generate a WYSIWYG display of DocBook in any of several different XML editors.)

This separation had an important effect. I moved control over fundamental structure and capability away from vendors towards standards committees. Now we are more and more seeing the vendors boasting about their implementation of standard capability rather than advertising their unique capability.

This is something we have seen before in the browser wars. Standards committees have succeeded almost completely in getting browser vendors to stop competing by adding new capabilities and structures that only worked on their browser, and to start competing to be the best and most compliant implementation of the HTML standard. 

This is a much bigger win for browsers than it is for content development systems, but it is a significant development in the market nonetheless. But it does not change the fundamental nature of the structures writers are working with or the constraints and capabilities of their tools. The model is still very much the same document domain model we had from the dawn of the DTP revolution. And it very much supports the current economic model of vendors and consultants. 

But structured writing can be about so much more than a vendor neutral document model. It can be about rhetoric and subject matter, and about constraining the rhetoric of a particular subject matter. This is what I called the subject domain. Structured writing in the subject domain is not about creating a vendor neutral document model. It is about divorcing the content from the document model altogether and tying it to a model of the subject matter and the specific rhetorical strategies of the subject matter. There is no WYSIWYG formatting of subject domain content because it structures are subject structures, not document structures. 

This approach to structured writing has been known and practiced for just as long as the document domain approaches. It can be far more effective in enhancing both content quality and process efficiency. But since it does not require either complex editors or complex live CMS connections, it does not present an attractive economic model for vendors, who therefore don't support it. This is where the advance of structured writing techniques has stalled. 

DITA, to its credit, did try to move structured writing in this direction a little. It's approach to information typing, based on generic concept/task/reference types, was at least an attempt to bring rhetorical structure into the picture, and its specialization mechanism was at least an attempt to support subject-specific structures. The problem with specialization, though, is it ties subject structures back to document structures, with which they are actually quite orthogonal. But the core of DITA's success has come from its reuse features, which is functionality that goes way back in the DTP era, and we are now seeing the emergence of reuse systems that ditch DITA information typing in the name of greater simplicity and ease of use. 

Though some people have certainly built subject domain systems with DITA, it has not achieved a breakthrough in this area, and doing it in DITA is much harder than it should be. So here we are with the advance stalled again.  

What has been achieved to date, I think, could reasonably be called distributed DTP, which is a definite advance on undistributed DTP, and DITA deserves a lot of credit for it. 

But distributed DTP is not the promise of structured writing. Subject domain structured writing is capable of achieving so much more, and with much greater simplicity. But without an economic model that is attractive to vendors, it is hard to move things in this direction. 

Mark





-----Original Message-----
From: techwr-l-bounces+mbaker=analecta -dot- com -at- lists -dot- techwr-l -dot- com [mailto:techwr-l-bounces+mbaker=analecta -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of Rick Quatro
Sent: Tuesday, April 25, 2017 12:55 PM
To: 'Tech Writing' <techwr-l -at- lists -dot- techwr-l -dot- com>
Subject: RE: Structured stuff for the beginner

Hi Mark,

I am not sure that the structured "revolution" is stalled in any way. I see more and more of my clients moving toward structured authoring in various forms. Some of them are doing it in environments that are familiar to them (like FrameMaker) and others are moving to desktop- or browser-based XML editors. 

I also don't see that structured and WYSIWYG writing are always mutually exclusive. FrameMaker has supported structured authoring at least since the mid-90s. In my opinion, they have merged structured and WYSIWYG authoring very well. FrameMaker's EDD model of applying formatting based on structure was brilliant and ahead of its time and still works well. FrameMaker is a "commercial solution" and a "true structured writing solution" at the same time.

I look at it this way: sooner or later, your structured content has to be "composed" for presentation to users, perhaps on paper or in a browser. In some systems, the composition is done at the end of the line and is mainly hands-off. Structured FrameMaker does its composition at the authoring state. Admittedly, this can cause problems when authors are distracted by the presentation rather than the content, but I don't see this as a major hindrance. And you still are working with vendor-neutral XML. 

I would be interested in what you think it would look like to "break out of this stalemate." In my opinion, there will continue to be a move to structure in various forms, but there will always be a market for WYSIWYG editors.

Rick Quatro
Carmen Publishing Inc.
rick -at- frameexpert -dot- com
585-366-4017


-----Original Message-----
From: techwr-l-bounces+rick=rickquatro -dot- com -at- lists -dot- techwr-l -dot- com [mailto:techwr-l-bounces+rick=rickquatro -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of mbaker -at- analecta -dot- com
Sent: Tuesday, April 25, 2017 12:23 PM
To: 'Dave C'; 'Tech Writing'
Subject: RE: Structured stuff for the beginner

The structured revolution is actually stalled in a protracted and bitter ground war against the forces of WYSIWYG. Structured writing is about writing in a way that conforms to a prescribed structure. Structures may be prescribed for many different reasons, but the key point is that if you want writers to conform to a structured, you have to show them the structure, not a preview of a particular output. 

The partisans of WYSITYG (which is to say, most of the large vendors) fight back against this by aggressively wrapping WYSIWYG shells over any structured format that is propose, and by preferring and championing any structured format that is easier to mask behind WYSIWYG, or is so complicated that it is indecipherable without some kind of interface over it.  DITA happens to be a format that meets both these criteria, which is why so many vendors are pushing it now. 

The reason for this is very simple: tools need a viable economic model, a way to sell you something that is proportional to the size of your operation and the extent of your usage. Pure structured writing tends not to do this. It supports writing in pretty simple and inexpensive editors, does not require a live connection to a repository, and performs publishing in batch. There is no way for a vendor to make money off that (and only limited ways for a consultant to make money off it). DITA, on the other hand, provides a viable economic model for vendors and consultants.

Thus if an organization insists on a commercial solution, they are unlikely to get a true structured writing solution. They are likely to get a solution that requires the use of an expensive proprietary editor with a live connection to an expensive proprietary CMS, because this model allows vendors to sell more seats as the client expands. Thus the structured writing revolution is kind of stalemated, except for those willing to use more open-source solutions and do a little thinking and building for themselves. 

What this means on the tools front is that you have another kind of stalemate between the traditional WYSIWYG kind of tools trying to bring the structured formats (largely DITA) under their traditional interfaces, and the structured tools (mostly XML editors) trying to create interfaces that look as much like Word as possible. There are certainly people in the industry that would like to break out of this stalemate, but the economics of the thing make it difficult. 

I have a book on this subject that will be coming out later in the year. 

Mark

-----Original Message-----
From: techwr-l-bounces+mbaker=analecta -dot- com -at- lists -dot- techwr-l -dot- com [mailto:techwr-l-bounces+mbaker=analecta -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of Dave C
Sent: Monday, April 24, 2017 11:39 PM
To: Tech Writing <techwr-l -at- lists -dot- techwr-l -dot- com>
Subject: Structured stuff for the beginner

Jumping back into the tech-wr âsoupâ again, I find I missed the whole structured revolution.

Some basic questions: what authoring tools are being used to generate, for example (for no particular reason), DITA?

Are word processors like Word now going by the way in favor of structured authoring tools? Is MS upping Wordâs game to join the structured fray?

Any pointers to web sites you can recommend?

Thanks,
Dave
(running before he hits the groundâ)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as mbaker -at- analecta -dot- com -dot- 

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications?  Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions?  Search our public email archives @ http://techwr-l.com/archives

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as rick -at- rickquatro -dot- com -dot- 

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications?  Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions?  Search our public email archives @ http://techwr-l.com/archives

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as mbaker -at- analecta -dot- com -dot- 

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications?  Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions?  Search our public email archives @ http://techwr-l.com/archives


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications?  Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions?  Search our public email archives @ http://techwr-l.com/archives