[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Please stop writing specifications that cannot beparsed/pr

• From: Marcus Reichardt <u123724@gmail.com>
• To: Roger L Costello <costello@mitre.org>
• Date: Fri, 26 May 2023 11:51:01 +0200

Dear colleagues, dear Roger,

I don’t want to interrupt your preaching to the choir ;) but Word *IS* XML since .docx about A.D. 2007 or so.

I’d say It being XML in itself didn’t necessarily improve the semantic qualities and machine readability of typical documents.

I have a hard time imagining "standard writers“ (if there’s such a species) who haven’t heard of XML at this point. I guess the problem, if there is indeed one, is more one of tooling and availability of editors. Since I personally am a VI type of person ;) let me suggest SGML as a way to make editing XML documents bearable with plain text editors, relying on well-known (or maybe not so well-known) features such as tag inference and short references (markdown!), the latter being rediscovered as Invisible XML these days though I’m still awaiting a formal mapping/alignment statement to SGML SHORTREF considering XML was designed as a proper subset of SGML on this very list many years ago.

Is there maybe interest for an SGML for dumm…^H^H^H^H XMLers tutorial in an upcoming markup conference where we can battle it out?

Have a nice weekend,
Marcus Reichardt
sgml.io

> Am 25.05.2023 um 21:57 schrieb Roger L Costello <costello@mitre.org>:
> 
> Dear Specification Writer,
> 
> Please stop writing specifications that cannot be parsed/processed by software. Please stop formatting your specifications as Word and PDF. Instead, use a format that is amenable to machine processing. The XML format is ideal. We want to analyze your specifications. We don't want to spend dozens of hours screen-scraping your Word/PDF documents.
> 
> If you simply must persist in writing Word/PDF documents, then please write in a consistent way so that we can screen-scrape without having to write special case code. To illustrate, in one of your specifications you provide a bunch of tables with data; each table has many rows. In some tables you reference a note. Here's a row with a note reference:
> 
> 119 Approach Route (1) Note 1 5.7
> 
> Here's another row with a note reference:
> 
> 52 SID Ident (1) (Note 1) 5.78
> 
> Why did you embed Note 1 within parentheses in the second case but not the first? That's an example of not being consistent. Such inconsistencies make it difficult to do screen-scraping. Please be consistent. If at all possible, write a parser to parse the data that you embed in your specification. This will immediately inform you of any inconsistencies.
> 
> Thank you,
> From the people who must read, understand, and analyze your specifications
> 
> _______________________________________________________________________
> 
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> 
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> 

• Follow-Ups:
  • Re: Please stop writing specifications that cannot beparsed/processed by software
    • From: B Tommie Usdin <btusdin@mulberrytech.com>

• References:
  • Please stop writing specifications that cannot be parsed/processed bysoftware
    • From: Roger L Costello <costello@mitre.org>