XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] Who Is Teaching XML To Technical Writers?

But I did.  "Fail." ;)

Good point about the toolkit.  

The editor does note the duplicates.  It doesn't stop the print or
display processors or prompt the writer immediately. It puts the errors
in a list that the writer has to look at to know they exist.  If they
aren't trained to look, they hit the Compose button and the PDF maker
does its work without caring because the Print process is oblivious.  I
guess the schizophrenia is in treating it as XML for some processes and
XML + DTD for others.  As long as the ids are near each other in the
tree, a linked reference still appears to work unless the composer is
returning an item such as a title.

The rest of the processes are organizational.  If they all share the
same toolkits (and they do because they rely on the processing
instructions to get certain layout constraints to work such as keeping
all of a note on the same page), then these errors can travel a goodly
process distance and in fact may even round trip several times.  In
which case, they may not matter until they hit the one case where they
do, and intra-organizational competence may be at an all time low (say
waterfall).

Training:  knowing XML, the application, the toolkit and the secret
decoder ring stuff beyond the toolkit, is the one thing that might save
the organization money.  DTD knowledge is increasingly obscure and FOSI
knowledge even more so.  Are there new editors available that support
FOSIs?

This is also why I asked about MicroXML.  Knowing which features fall
away is critical to some applications with big expensive legacy.
Further, as these fall away in a subset as was the case with SGML to
XML, when should large organizations make the investment to move on
given other impending changes such as new platforms as was the case with
the typesetters, word processors, the web, and so on.  If they do,
should they change the underlying technology (eg, drop XML support) or
justify it? 

Legacy training is figured against the cost of hiring old people if
there is still a supply and they don't impact the insurance pool.

len

-----Original Message-----
From: Michael Kay [mailto:mike@saxonica.com] 
Sent: Monday, August 13, 2012 9:06 AM
To: Len Bullard
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Who Is Teaching XML To Technical Writers?


On 13/08/2012 14:21, Len Bullard wrote:
> If IDs are a problem for the technical writers/taggers, one might
assume
> DTDs are in the mix.  Yet even as one of the world's very top experts,
> you didn't.
I certainly wouldn't assume that an attribute called "id" is declared as

an ID unless I have evidence that this is the case, especially if the 
information about the XML comes from one of the world's very top
experts.

But more importantly, I still think that seeing two duplicate IDs is not

evidence of a problem with the way the technical writers/taggers have 
been trained, it is a problem with the tools they are using. The tools 
should stop it happening.

Michael Kay
Saxonica


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS