[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [oic] state-of-interop-cd-03 - AGREEMENT ON TC DOCUMENT FORMAT ANDTOOLS
Thanks for the background, Robin. You give me some things to think about.
I agree that organizationally it would be impossible to mandate this at
OASIS. Organizations move at different speeds. For example ISO just
recently accepted the telephone, and now allows WG's to meet by telephone.
It can take a while, but we'll get there eventually.
-Rob
Robin Cover <robin@oasis-open.org> wrote on 02/11/2010 09:23:22 AM:
>
> RE: [oic] state-of-interop-cd-03 - AGREEMENT ON TC DOCUMENT FORMAT AND
TOOLS
>
> On Wed, 10 Feb 2010, robert_weir@us.ibm.com wrote:
> http://lists.oasis-open.org/archives/oic/201002/msg00019.html
>
> > Btw, I hear rumors over the years of something like a "Spec ML" for
> > standards. Anything ever come of that?
> >
> > -Rob
>
> Sorry to have left the conversation dangling, Rob. It's a good
> question. You probably recall rumors correctly about creation
> of a specialized markup vocabuary with some DTD or schema(s) and
> transform tools from 'specification XML' to XHTML, PDF, and
> other useful formats. Mary mentions "wildest dreams" because
> the vision for this at OASIS seems to grow dimmer each year.
>
> Here's a summary of what I think I know, probably forgetting
> much:
>
> 1. If by fiat we had such a "Spec ML" with XSLTs and editing
> support in free authoring/editing tools, some TC editors
> would still prefer to use a favorite word processor. At
> OASIS we're not set up (by ethos) to require hardly anything.
>
> 2. We have some (now unsupported?) tools for use of DocBook to
> produce OASIS-style specifications. See [1] below. I don't
> know whether many OASIS TCs use this tool chain.
>
> 3. W3C has made considerable investment in what's called the
> 'xmlspec' tool chain that includes schemas in several
> schema languages, with transform sheets to produce the
> required W3C XHTML and other formats. My summary is outdated,
> but here's an overview:
>
> The XML Spec Schema and Stylesheets
> http://xml.coverpages.org/specProduction.html#xmlspec
>
> W3C XML Specification DTD ('xmlspec')
> http://xml.coverpages.org/specProduction.html#W3C-xmlspecDTD
>
> I think these DTDs/schemas/XSLTs are supported by a number
> of document-production software tools like 'oXygen/',
> RenderX, and others.
>
> One can see the use of 'xmlspec' at work in the W3C
> XML source files, for example (use browser 'View Source')
> in:
>
> http://www.w3.org/XML/2010/01/xml-model/xml-model.xml
>
http://www.w3.org/TR/2005/REC-xml-id-20050909/REC-xml-id-20050909.xml
>
> But again: W3C does not require WG editors to use the 'xmlspec'
> tool chain. Other tools like 'ReSpec' are also popular [2]
>
> 4. Kudos to Norm Walsh and Eve Maler (among others) who pioneered
> a lot of this work in the OASIS and W3C context.
>
> 5. Despite minimal interest in (or energy for) development of
> a "Spec-ML" at OASIS, I think it would provide rich rewards in
> terms of supporting high-quality specification production
> that allows myriad QA processes, automated generation of
> citations in proper format, and so forth. The POC model for
> this is IETF, where many kinds of automated checking are
> made possible [3] as a specification progresses in the IETF
> review and publication workflow. The irony (IMO) is that
> this is mostly accomplished on the platform of line-oriented
> text, not descriptive markup-structured text; processing
> the latter for these QA/metadata/workflow operations should
> be a lot easier than for plain text. On the other hand,
> the IETF 'xml2rfc' tools can produce very nice, highly
> functional, high-performance HTML documents, supported by
> 'Citation Libraries' automation:
>
> http://xml.resource.org/
> http://xml.resource.org/experimental.html
>
> That's it for now... maybe a new grass roots effort will spring
> up in the OASIS context someday to move beyond "Spec-ML" rumors
> and wild dreams.
>
> ** References:
>
> [1] "Specification Template Instructions"
>
> "OASIS standards-track documents encoded in DocBook can
> be styled with an XSLT processor to produce HTML or
> XSL versions. The HTML versions are styled by the appropriate
> OASIS CSS stylesheet. The XSL versions can subsequently
> be styled with an XSL Formatter to produce PDF and other
> hardcopy formats."
> http://www.oasis-open.org/spectools/docs/wd-spectools-
> instructions-01.html#s.docbook
> and see:
> http://www.oasis-open.org/spectools/docs/
>
> [2] http://dev.w3.org/2009/dap/ReSpec.js/documentation.html
>
> [3] http://xml.coverpages.org/specProduction.html#ietf
>
> Cheers,
>
> -rcc
>
> Robin Cover
> OASIS, Director of Information Services
> Editor, Cover Pages and XML Daily Newslink
> Email: robin@oasis-open.org
> Staff bio: http://www.oasis-open.org/who/staff.php#cover
> Cover Pages: http://xml.coverpages.org/
> Newsletter: http://xml.coverpages.org/newsletterArchive.html
> Tel: +1 972-296-1783
>
> >
> > Robin Cover <robin@oasis-open.org> wrote on 02/10/2010 02:22:53 PM:
> >
> >>
> >> Subject:
> >>
> >> RE: [oic] state-of-interop-cd-03 - AGREEMENT ON TC DOCUMENT FORMAT
AND
> > TOOLS
> >>
> >>> The version approved as CD04 was approved with the ODF version as
> >>> authoritative.
> >>
> >> I'm not sure whether I'm agreeing with Rob in this message, but here
> >> goes, FWIW:
> >>
> >> [Dennis]
> >>> It is startling when I
> >>> see .doc files, especially as authoritative sources, from other TCs.
> >>
> >> I don't understand the basis for the startlement: I would (and do)
> >> recommend that TCs designate the editable source as the authoritative
> >> format. XML, HTML, DITA-format, ODF, Word, whatever.
> >>
> >> If some TC uses Word as a word processor in document production,
> >> then the obvious format for "authoritative" reference (IMO)
> >> should be the original Word editable source -- not some
> >> secondary, derivative, possibly "corrupted" PDF, resulting
> >> from an approximate machine transform. Changes (viz., corruptions)
> >> introduced in (some) PDF generation transforms are widely
> >> attested. Not always, but too frequent for comfort.
> >>
> >> So I have noted on several fora that the OASIS provision to
> >> allow production of derivative works *should* imply that
> >> the editable source be nominated as the authoritative
> >> format. If not, then someone wanting to create a
> >> derivative work would potentially have to start work from
> >> a PDF -- transforming that "authoritative" PDF back into
> >> some useful editable format, for re-use in an editing
> >> framework suitable for creating derivative works. And the
> >> PDF-to-editable-text transform is known to be hazardous, at best,
> >> often leading to predictable classes of corruptions. It
> >> would not be safe to begin work with the original editable
> >> format if the PDF is authoritative, because changes in the
> >> PDF not detected (initially) by human inspection would
> >> lead to a derivative work based upon a non-authoritative
> >> document.
> >>
> >> Declaring the secondary generated PDF to be authoritative
> >> seems to me quite questionable if fidelity to the author's
> >> or editor's intent (in the editable source) is important.
> >>
> >> So I would recommend, if asked, that the TC use ODF as
> >> the authoritative format.
> >>
> >> YMMV.
> >>
> >> -rcc
> >>
> >> Robin Cover
> >> OASIS, Director of Information Services
> >> Editor, Cover Pages and XML Daily Newslink
> >> Email: robin@oasis-open.org
> >> Staff bio: http://www.oasis-open.org/who/staff.php#cover
> >> Cover Pages: http://xml.coverpages.org/
> >> Newsletter: http://xml.coverpages.org/newsletterArchive.html
> >> Tel: +1 972-296-1783
> >>
> >> --
> >>
> >> On Wed, 10 Feb 2010, robert_weir@us.ibm.com wrote:
> >>
> >>> The version approved as CD04 was approved with the ODF version as
> >>> authoritative.
> >>>
> >>> Of course, we are free to make a different choice if/when we make a
> > post
> >>> public review revision.
> >>>
> >>> And remember, just because there are known bugs in the ODF rendering
> > does
> >>> not mean that there are not also bugs in the HTML or PDF exports.
I've
> >>> certainly seen my share of those. I'll take an obvious but benign
> >>> rendering error over a subtle but pernicious one any day.
> >>>
> >>> -Rob
> >>
> >>
> >> Robin Cover
> >> OASIS, Director of Information Services
> >> Editor, Cover Pages and XML Daily Newslink
> >> Email: robin@oasis-open.org
> >> Staff bio: http://www.oasis-open.org/who/staff.php#cover
> >> Cover Pages: http://xml.coverpages.org/
> >> Newsletter: http://xml.coverpages.org/newsletterArchive.html
> >> Tel: +1 972-296-1783
> >>
> >>
> >>>
> >>>
> >>> "Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 02/10/2010
> >>> 01:19:07 PM:
> >>>>
> >>>> Subject:
> >>>>
> >>>> RE: [oic] state-of-interop-cd-03 - AGREEMENT ON TC DOCUMENT FORMAT
> > AND
> >>> TOOLS
> >>>>
> >>>> This is a work-process issue. We have no agreement on what version
> > and
> >>>> specific tool we share in common in order to be able to produce and
> > work
> >>> on
> >>>> (authoritative) documents of the OIC TC, and ones the TC
> > Administrator
> >>> can
> >>>> manipulate in order to produce the OASIS Standard version (if she
is
> > the
> >>> one
> >>>> who needs to be able to do that).
> >>>>
> >>>> It is an interoperability issue for ourselves in our own work.
> >>>>
> >>>> I notice that the proposed solution to the immediate issue involves
> >>>> proposing that a specific product release be used with, I suppose,
a
> >>> prayer
> >>>> that the builds for different platforms don't have interop problems
> > too.
> >>>>
> >>>> So, when we go to Public Review, how do we deal with this? That we
> >>> identify
> >>>> the document as one supported by a specific product version?
> >>>>
> >>>> I recommend that we avoid this by making the PDF be the
authoritative
> >>>> version. Whatever fears there are of an unfaithful PDF result, I
> > think
> >>> the
> >>>> odds of successful consumption by reviewers and user are clearly
> > better
> >>> than
> >>>> what we are dealing with as a certainty. Also, the PDFs that are
> >>> relatively
> >>>> small, easy to review, and for the State of Interoperability, we
have
> > no
> >>>> concern about some normative text being corrupted in the PDF.
> >>>>
> >>>> - Dennis
> >>>>
> >>>> PS: Rob quipped that a committee can use any document format it
> > wants,
> >>> even
> >>>> Microsoft Word .doc. If I'd been on my toes, I would have offered
to
> >>> second
> >>>> that were it to be made as a motion. (It would be ironic if the
ODF
> >>> exports
> >>>> to .doc were more reliable than what we are seeing in ODF
> > interchange.)
> >>>> I am now accustomed to OASIS TCs that use ODF. It is startling
> > when
> >>> I
> >>>> see .doc files, especially as authoritative sources, from other
TCs.
> > I
> >>> want
> >>>> us to have a reliable way to use ODF Text documents on the OIC TC.
It
> >>> is an
> >>>> obvious dog-food issue. What can we do to achieve that
successfully?
> >>>>
> >>>> PPS: Out of curiosity, I noticed that CD03 itself was identified
with
> >>>> office:version="1.2" and
> >>>> <meta:generator>OOo-dev/3.2$Win32
> >>>> OpenOffice.org_project/320m6$Build-9459</meta:generator>. This
opens
> >>> just
> >>>> fine in OpenOffice.org 3.0.1 and (after ignoring the warning)
> >>> OpenOffice.org
> >>>> 2.4.1.
> >>>>
> >>>> PPPS: Since this is not about producing reports about specific
> > products
> >>> but
> >>>> figuring out a way to use an interoperable set of tools for our own
> >>> document
> >>>> production, I tried Windows 7 WordPad on cd03. It doesn't handle
> >>> numbers on
> >>>> the headings and doesn't handle ToCs. On the other hand, Word 2007
> > SP2
> >>>> opens all three of CD03, CD03-wd01 and CD03-wd02 and shows the ToC
> > and
> >>>> in-body headings correctly EXCEPT that, for all three documents,
the
> >>>> level-two headings all have page breaks in front of them and, with
> > wd02
> >>>> only, the Section numbering starts over at 1 with the Conclusions
> >>> section.
> >>>>
> >>>> -----Original Message-----
> >>>> From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be]
> >>>> Sent: Wednesday, February 10, 2010 08:30
> >>>> To: dennis.hamilton@acm.org; oic@lists.oasis-open.org
> >>>> Cc: Rob Weir
> >>>> Subject: RE: [oic] Groups - state-of-interop-cd-03-wd02.odt
uploaded
> > -
> >>>> NUMBERING
> >>>>
> >>>> Well, we actually shouldn't comment on implementations per charter,
> > but
> >>> I
> >>>> guess it's related to
> >>>>
> >>>> http://qa.openoffice.org/issues/show_bug.cgi?id=106218
> >>>>
> >>>> Should be fixed when opening in 3.2 and resaving again, I'll do
that
> >>> when
> >>>> updating to cd4.
> >>>>
> >>>>
> >>>> Bart
> >>>>
> >>>> ________________________________________
> >>>> From: Dennis E. Hamilton [dennis.hamilton@acm.org]
> >>>> Sent: Wednesday, February 10, 2010 4:58 PM
> >>>> To: oic@lists.oasis-open.org
> >>>> Cc: Hanssens Bart; Rob Weir
> >>>> Subject: RE: [oic] Groups - state-of-interop-cd-03-wd02.odt
uploaded
> > -
> >>>> NUMBERING
> >>>>
> >>>> OK, I didn't look closely enough.
> >>>>
> >>>> When I opened this document in OpenOffice 3.0.1, I did see the TOC
> > with
> >>>> proper subsections, and I saw section numbers on the headings in
the
> >>> body of
> >>>> the document.
> >>>>
> >>>> However, numbering is not maintained properly in the body. There
are
> >>>> several section 0.1, for example.
> >>>>
> >>>> E.g., 2.2 is numbered 0.1, 2.3 is numbered 0.1 also, section 3 is
> > number
> >>> as
> >>>> section 1, 3.2 is numbered 0.1, section 4 is numbered as section 1,
> > etc.
> >>>>
> >>>> SO, I tried the OpenOffice 2.4.1, Sun Distribution.
> >>>>
> >>>> It has the TOC right and it has the subsections being in the same
> >>> section.
> >>>> But the subsections are all numbered *.1. That is, Section 4 has
two
> >>>> subsections each numbered 4.1.
> >>>>
> >>>> FINALLY, I opened the package in WinZip and confirmed that
> >>>> <office:document-content> office:version="1.1". And also, in
> > meta.xml,
> >>>> <meta:generator>OpenOffice.org/3.1$Unix
> >>>> OpenOffice.org_project/310m19$Build-9420</meta:generator>
> >>>>
> >>>> Yes, I would say that this is a big deal for the State of
> >>> Interoperability.
> >>>>
> >>>> -----Original Message-----
> >>>> From: bart.hanssens@fedict.be [mailto:bart.hanssens@fedict.be]
> >>>> Sent: Wednesday, February 10, 2010 07:02
> >>>> To: oic@lists.oasis-open.org
> >>>> Subject: [oic] Groups - state-of-interop-cd-03-wd02.odt uploaded
> >>>>
> >>>> The document revision named state-of-interop-cd-03-wd02.odt has
been
> >>>> submitted by Mr. Bart Hanssens to the OASIS Open Document Format
> >>>> Interoperability and Conformance (OIC) TC document repository. This
> >>>> document is revision #1 of state-of-interop-cd-03-wd01.odt.
> >>>>
> >>>> Document Description:
> >>>>
> >>>>
> >>>> View Document Details:
> >>>> http://www.oasis-open.org/committees/document.php?document_id=36343
> >>>>
> >>>> Download Document:
> >>>>
> >>>
> >
http://www.oasis-open.org/committees/download.php/36343/state-of-interop-cd-
> >
> >>>
> >>>> 03-wd02.odt
> >>>>
> >>>> Revision:
> >>>> This document is revision #1 of state-of-interop-cd-03-wd01.odt.
The
> >>>> document details page referenced above will show the complete
> > revision
> >>>> history.
> >>>>
> >>>>
> >>>> PLEASE NOTE: If the above links do not work for you, your email
> >>> application
> >>>> may be breaking the link into two pieces. You may be able to copy
> > and
> >>> paste
> >>>> the entire link address into the address field of your web browser.
> >>>>
> >>>> -OASIS Open Administration
> >>>>
> >>>>
> >>>>
---------------------------------------------------------------------
> >>>> To unsubscribe from this mail list, you must leave the OASIS TC
that
> >>>> generates this mail. Follow this link to all your TCs in OASIS at:
> >>>>
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >>>>
> >>>
> >>>
> >>>
---------------------------------------------------------------------
> >>> To unsubscribe from this mail list, you must leave the OASIS TC that
> >>> generates this mail. Follow this link to all your TCs in OASIS at:
> >>>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this mail list, you must leave the OASIS TC that
> >> generates this mail. Follow this link to all your TCs in OASIS at:
> >>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]