[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]