OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

chairs message

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


Subject: RE: [chairs] Practical considerations and impacts of mandated editing formats /tools


Jacques and David,

I agree with you both.  I am already in the situation where the editable
form of specifications that are developed on projects I'm in can't be
maintained by anyone but a select number of participants because they use
tools off-line to do the final document production or provide specialized
content.  While the result is in an open-standard format, it is not anything
I could replicate or maintain using well-known open-standard-supporting
products alone.  So when said individuals stop performing their interesting
technical incantations, we are left helpless or need to find some XSLT
wizard to perpetuate the magic touch-up and content-incorporation
processing.

Also, I don't think it is meaningful to call styles as they are setup in
word processors equivalent to a style sheet as I think of it (sorry
Patrick).  In addition, while I see editable forms that make use of styles,
I have not yet seen any guidance on what they are and how they are to be
used to maintain a document properly.  It is all ad hoc mystery meat from my
perspective.  Even a pseudo-DTD would be more helpful.

We do have a problem with regard with the target forms that are turned over
to the TC Adminstrator however. Even if the editable forms are in some
XML-based open-standard format, tooling differences arise between what the
authors used and what the TC Administrator uses for any necessary touch-ups.
Also, the derivative forms (assuming that PDF and [X]HTML versions are
derivatives) tend to have questionable fidelity depending on the tooling
used to derive them, and that reflects on the tools used by the TC
Administrator as well as the TC submitters.  It gets messy even when the TC
Administrator and submitters from TCs use different versions of the same
standards-supporting product.  (And I don't want to think about what happens
when your normal.dot is different than my normal.dot or the equivalent in
other tool sets.)

With regard to some sort of semantic review, it seems like we are back to a
wished-for higher-level (abstract) schema that requires a conceptual
template (which we have), far more guidance on what is called for and what
the quality must be (no broken links, all external links in the references,
not in the text, no broken internal cross-reference links, some spelling and
grammar checking, etc.) and some tool-level templates that establish the
styles, layout, and schema if at all possible, and then some way to
mechanical checking that the delivered form of a specification passes the
semantic review in form if not content, at a minimum.  I am not optimistic.
Eyeballs and someone clicking on things is probably the best we will have
for a long time.  

One thing that seems to work, even though these seem to be quite superficial
checks in the current practice, is that when a defect is found, don't waste
serious effort finding more (easy extra-effort OK).  Send it back at once.
When the next defect is found, send it back again.  I know of no other way
to require TCs to improve the quality of what is delivered to the TC
Administration.  Relying on the TC Administration and Public Reviewers to
catch that stuff strikes me as comparable to the worst software-development
practices we already suffer the consequences of.


 - Dennis

Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability 
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 


-----Original Message-----
From: Jacques R. Durand [mailto:JDurand@us.fujitsu.com] 
Sent: Thursday, April 22, 2010 18:58
To: David RR Webber (XML); chairs@lists.oasis-open.org
Subject: RE: [chairs] Practical considerations and impacts of mandated
editing formats /tools

+1
I just do not see at this point a strong enough reason to coerce everyone
into using the same source format.
If that is desirable from an OASIS  house-keeping viewpoint, getting there
should just be a gradual, voluntary process - the carrot, not the stick... 
 
jacques

________________________________

From: David RR Webber (XML) [mailto:david@drrw.info] 
Sent: Thursday, April 22, 2010 2:11 PM
To: chairs@lists.oasis-open.org
Subject: [chairs] Practical considerations and impacts of mandated editing
formats /tools


My experience with this in the past is that this imposes an unacceptable
barrier to the volunteers who do the hard work of actually editing and
completing the specifications.

Once you start needing to install add-ins and scripts and all kinds of
non-default pieces into editing tools things rapidly get out of control.
What one person sees in their environment is not what someone else has.

I always hear "well it works wonderfully for our TC" - but then those same
people are not the ones responsible for fixing your PC and editor and
documents and providing support to your deadlines.   Or working with a TC
member who is likewise being challenged sending in edits.  Training is
another issue.

I'd strongly prefer to not open this whole can of worms - and allow TCs to
continue tp decide - as now - what tools they are most comfortable with
using for developing their specifications.  If something is suggested and
provided to assist - that's fine - but that's not the same as mandating
something.

DW







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