- From: Jon Bosak <bosak@atlantic-83.Eng.Sun.COM>
- Date: Wed, 5 Mar 1997 22:29:44 -0800
- To: opentag@ile.com
- cc: bosak@atlantic-83.Eng.Sun.COM, w3c-sgml-wg@w3.org
As the chairman of the committee developing XML, I'd like to thank you for your attempts at XML compliance. However, analysis shows that the claim to conformance with WD-xml-961114 as currently stated in opentag.dtd Draft version 3 is false (see below). Until you make the changes needed to bring OpenTag into compliance with the XML specification, I strongly suggest that you drop the claim, as it can only reflect badly on your expertise and credibility. I welcome your participation in the XML effort and hope that you will soon be able accurately to claim XML compliance for OpenTag. Sincerely, Jon ---------------------------------------------------------------------- Jon Bosak, Online Information Technology Architect, Sun Microsystems ---------------------------------------------------------------------- 2550 Garcia Ave., MPK17-101, | Best is he that inuents, Mountain View, California 94043 | the next he that followes Davenport Group::SGML Open::ANSI X3V1 | forth and eekes out a good ::ISO/IEC JTC1/SC18/WG8::W3C SGML ERB | inuention. ---------------------------------------------------------------------- Date: Wed, 05 Mar 1997 11:45:10 -0500 To: w3c-sgml-wg@w3.org From: "Eve L. Maler" <elm@arbortext.com> Subject: Re: Kind of surprising commercial XML application In case anyone is curious, here are the ways in which the opentag.dtd isn't XML compliant (some of the ways are trivial, some not): - #PCDATA must come at the beginning of a content model (%paratxt;, u, ...) - #PCDATA must always use * occurrence indicator (u, ...) - #PCDATA can't be in a model with pernicious mixed content (lvl) - Exceptions not allowed (b, ...) - OMITTAG specifications not (yet :-) allowed - NUMBER declared value not allowed (p, ...) - Comments not <!--* *--> (but this isn't in the spec version they used) Designing and implementing DTDs according to the XML constraints is a new discipline... Eve Date: Thu, 06 Mar 1997 00:14:02 -0500 To: w3c-sgml-wg@w3.org From: Harvey Bingham <hbingham@ACM.org> Subject: Re: Kind of surprising commercial XML application (long) Executive Summary: The primary connection to this wg is their marketing hype, claiming they do XML. The novel idea for natural language processing is that text zones can be extracted from a word-processing proprietary format and tagged to the opentag DTD, manipulated (natural language translation of those text zones), and then restored to the places where the original text zones were, yielding the same formatting for a new document in the different natural language. Custom translators to and from the proprietary format are needed for the 25 elements of the OpenTag DTD. ---- 1. Analysis: OpenTag focuses on localization (natural langage processing, NLP) of text in documents in any proprietary formatting text processor. It uses its standard DTD that will support open data encoding methods during the localization process. It provides a 25-element DTD that assertedly preserves the significant clues useful for producing natural language translation of each text object. Presumably translation is easier using the opentag markup. When the translation is complete, the reverse process occurs: it substitutes the translated text objects back into the corresponding places in the original formatted document, so all the original formatting markup is reused. The SGML version is only the intermediary. It need not persist beyond the translation process. They assert "XML compliant (and therefore SGML compliant as well)". They aren't there yet. [See Eve's message as well.] The OpenTag DTD preserves a few styles that might provide aids to translation [but not font, face, pointsize information, that might convey hierarchy or captioning]. Presumably a human translator would have the original formatted document to work with that could convey this other information. A tagged instance has sequential numeric ids assigned to paragraphs in a document and again ordered sequential numeric ids to each inline textual object in each paragraph. As the content model includes tags for inlines in a paragraph, the mixed content #PCDATA parts would remain in the same order separated by injections of inlines. A generic x in-line code tag is available, that might be used to surround #PCDATA. It handles footnotes, index terms, and bibliographic references. It preserves column breaks and table cell breaks. They allow (character) codeset change within a document from that specified in an initial PI. Comparing different localizations for the same formatting language X of the same original would all share the ordered ids. Transformation to a different target formatting language Y, such as RTF, HTML, Wordperfect, etc. would not generally be possible, unless there were a richer way to assign corresponding style recognizers and generators. Some formatting languages such as MicroSoft Powerpoint scramble object order. There is no implicit left-to-right, top-down text progression as is true for western languages in most word-processing format languages. (Even in those, table cell line-wrapping can break that model.) I believe the opentag document instances will lose much information in the translation process of mapping everything onto their 25 generic elements, nine of which are EMPTY. The consequence is that they will not be able to generally go from X to different formatting language Y. 2. The DTD -- opentag.dtd The OpenTag DTD claims conformance with "XML, Extensible Markup Language, working draft 11-14-96". The assertion of compatiblity with XML is commendable, but overstated. Omissible tag indicators should not be present. Or, if they are, the omissible endtag on a content model is improper: <!ELEMENT P - O ...> is inconsistent with XML. All hierarchic structures are flattened into a sequence of paragraphs P. Self-exclusion exceptions occur, on b,i,u,d bold, italics, underline, doubleunderline) indicate a style attribute on something -- but why stop with those few? smallcaps, overbar, strikethrough, subscript, superscript, etc.] <!ELEMENT so - - RCDATA> RCDATA is disallowed in XML. There is no element declaration for level, used in the ixd content model. Instead there is a lvl element, with pernicious mixed content, ((%paratxt;)*,so) that is illegal in XML. The PB tag semantics refer to an otherwise undefined definition group. 3. The OpenTag Format Specifications -- otspecs.htm This includes a markup reference to XML, character entities (either SGML &name;, or Unicode &#xxxx;), a file header, and a tag description table, providing some semantics. An initial PI file header describes version, type, encoding, locale, and original. This suggests document==file. There is no mention of external entities. No attributes are on the base document element, opentag. Almost universal is an id NUMBER attribute. Few other attributes exist. The element type distinguishes use: target or reference for the id value. The example for paragraph (which has a content model) "<p id=1/>" is inconsistent with SGML. It uses the XML empty tag variant "/>" in place of tagc, not now present in SGML. I am confused by the use of id as a numeric (not ID) attribute. It is appropriate for the textual definitions of footnotes, index terms, and (biographic) references -- FND, IXD and RFD, but also in their EMPTY points of reference in FN, IX, and RF. As the latter are actually references, in SGML I believe it would be better with a distinguishing attribute name, possibly "idr", rather than overload id. I see no reason why the "idr" need to be unique in the file. Several references to the same object should be allowed. [The end of the RFD semantics seems in error, referring to footnote definition, rather than reference definition.] The use of sequential integers starting from 1 at each <p> for each in-line makes any use of the id values during language processing awkward. Since each paragraph has its own sequence, presumably the paragraph ids, unique to the document, also a set of sequential numbers starting at 1 as qualifiers to disambiguate the ids of the in-line children. But since the inline id values are reused, they are not sufficientby themselves to locate any object, other than indirectly through its ancestors. The generic inline group can be arbitrarily moved in a P. That seems to means that all id values in that P need to be adjusted after such movement. [Any editing to add, reorder, or delete objects in a P has the same problem.] Perhaps this is ruled out in the localization NLP. Revisions across a set of localized versions of a document could use opentag versions to linearize the structure and provide some degree of common navigation to common places. There are no attributes that would indicate any revision control. From this cursory look, I believe OpenTag still needs significant work. Regards/Harvey Bingham mailto:hbingham@acm.org
Received on Thursday, 6 March 1997 01:29:43 UTC