[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 FORMATAND 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
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]