Date: Wed, 16 Oct 1996 20:41:10 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Fresh activity page The W3C Generic SGML activity page has been updated. See http://www.w3.org/pub/WWW/MarkUp/SGML/Activity Jon Date: Thu, 17 Oct 96 11:01:39 CDT From: Michael Sperberg-McQueen Subject: some ERB decisions To: W3C SGML Working Group The SGML ERB met Wed. Oct 16th and voted on several items already submitted to the SGML WG. Participating: Bosak, Bray, Clark, Maler, Paoli, Sperberg-McQueen, and Sharpe. Absent: DeRose, Hollander, Kimber, Magliery, and Connolly. All decisions were by consensus of all those participating in the call, and thus carry a majority of the membership of the ERB. Several issues were left unresolved at the end of the meeting; the ERB will be meeting today and Saturday to discuss them further and resolve them. A.20 XML will retain the notion and syntax of comments (= 8879's 'comment declarations') (7.6, 10.3), but comment declarations will contain at most one comment: comments will take the form '' or else will begin with '' (no space allowed), and may not contain '--'. Comments will take the form '', no internal '--' is allowed and no white space between the final '--' and the final '>'. Empty comments () will not be allowed in XML. B.1 What should XML's character-set rules be? Should conforming XML documents be restricted to particular character sets? Should conforming XML processors be required to be able to parse all conforming XML documents (13.1)? Agreed: - the character repertoire of XML documents is that of ISO 10646 - conforming XML documents may be in UTF-8 or UCS-2 form - all XML processors must accept documents in UTF-8 and UCS-2 (or optionally UTF-16) form - XML processor may provide a user option which causes them to accept documents in other coded character sets (e.g. ISO 8859 or JIS 0208) or other encodings of 10646 or other coded character sets (e.g. Extended Unix Code) -- this behavior must be optional (i.e. the user must be able to turn it off, so that documents not in UTF-8 or UCS-2 raise errors). Still open: details of the mechanism to be used for signaling the encoding and/or coded character set in use. B.2 Should XML require each document instance to have a DTD or not (7.1)? XML will not require each document instance to have a DTD. Open question: details of partial DTDs or DTD summaries, if any, and possible declarations indicating whether the correct ESIS is derivable for a document its DTD is not read. B.4 Should XML forbid comments and processing instructions in mixed content, as a way of simplifying RE handling (7.6)? Assuming that a satisfactory RE rule can be agreed on, XML will not forbid comments and processing instructions in mixed content. B.5 Should XML restrict the use of the PCDATA token in content models, to simplify RE handling or eliminate the Mixed Content Problem? (7.6.1, 11.2.4) * B.5 restrict PCDATA to models of the form (#PCDATA) No. * B.6 restrict PCDATA to models of the form (#PCDATA | x ... | z)* Yes. B.8 Should XML use MSOCHAR, MSSCHAR, and MSICHAR strings (9.7)? No. B.11 Should XML forbid, allow, or require empty end-tags (7.5)? Forbid. -C. M. Sperberg-McQueen University of Illinois at Chicago Date: Thu, 17 Oct 96 13:32:02 CDT From: Michael Sperberg-McQueen Subject: C.13 Multiple ID and NOTATION attributes? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the ERB is leaning to no. C.13 Should XML remove SGML's prohibition on multiple ID or NOTATION attributes on the same element (11.3.3)? Date: Thu, 17 Oct 96 13:32:27 CDT From: Michael Sperberg-McQueen Subject: C.14 Enumerations in attribute declarations? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the question needs further discussion in the work group. Possible positions are to remove 8879's restriction (at the cost of more complex XML-to-SGML DTD translation), to retain it, to eliminate enumerated values entirely in the hope that WG8 will relax the restriction, or to retain the restriction but make it a non-reportable error. C.14 Should XML allow more than one enumerated type (name-group declared value) to contain the same possible value (11.3.3)? From: lee@sq.com Date: Thu, 17 Oct 96 16:10:01 EDT To: w3c-sgml-wg@w3.org, U35395@UICVM.CC.UIC.EDU Subject: Re: C.13 Multiple ID and NOTATION attributes? > On 23 October 1996, the ERB will vote to decide the following > question. A straw poll indicates the ERB is leaning to no. > > C.13 Should XML remove SGML's prohibition on multiple ID or NOTATION > attributes on the same element (11.3.3)? Yes. Without a DTD, you can't detect it anyway. In fact, without a DTD, the only attribute type that makes any sense to me at all is Lee Date: Thu, 17 Oct 96 14:10:29 CDT From: Michael Sperberg-McQueen Subject: B.1 and B.2 results To: W3C SGML Working Group The SGML ERB met today, Oct 17th, and voted on several items already submitted to the SGML WG. Participating: Bosak, Clark, Maler (in part), Magliery (in part), Paoli, Sperberg-McQueen, and Sharpe. Absent: Bray, DeRose, Hollander, Kimber, and Connolly. All decisions were by consensus of all those participating in the call, and thus carry a majority of the membership of the ERB. The text below is substantially the same as the drafts discussed by the ERB, but was edited after the meeting to reflect the ERB's decisions; the ERB has thus not seen and approved the precise wording given, and may choose to correct any editorial errors made in the revision. -C. M. Sperberg-McQueen ----------------------------------------------------------------------- B.1 What should XML's character-set rules be? Should conforming XML documents be restricted to particular character sets? Should conforming XML processors be required to be able to parse all conforming XML documents (13.1)? It had already been agreed that: - the character repertoire of XML documents is that of ISO 10646 - conforming XML documents may be in UTF-8 or UCS-2 form - all XML processors must accept documents in UTF-8 and UCS-2 (or optionally UTF-16) form - XML processors may provide a user option which causes them to accept documents in other coded character sets (e.g. ISO 8859 or JIS 0208) or other encodings of 10646 or other coded character sets (e.g. Extended Unix Code) -- this behavior must be optional [at least in validating processors, we decided today] (i.e. the user must be able to turn it off, so that documents not in UTF-8 or UCS-2 raise errors). In discussing the mechanism to be used for signaling the encoding and/or coded character set in use, the ERB decided the following. [Editorial note: if the ERB decides that XML will have external text entities, then everything said below about documents will also apply to all external text entities.] The character repertoire of XML documents is that of ISO 10646. All XML processors are required to accept documents in the UTF-8 and UCS-2 encodings of 10646. It is recognized that accepting documents in the UTF-16 variant would be desirable. Documents encoded in UCS-2 must begin with the Byte Order Mark described by ISO 10646 Annex E and Unicode Appendix B (the ZERO WIDTH NO-BREAK SPACE character, U+FEFF) -- this is an encoding signature, and not (for SGML purposes) part of the document. XML processors must be able to use this character to differentiate between UTF-8 and UCS-2 encoded documents. XML does not explicitly sanction the use of any other encodings. It is recognized, however, that many documents exist in other encodings. To support processors in dealing with this situation, an XML document may contain at its beginning, before any other text, markup, PIs, or white space, an Encoding Declaration PI matching EncDecl ::= '' An XML processor may choose to read Encoding Declaration PIs and accept nonstandard encodings so declared. In validating processors such behavior must be at user option. An XML document which lacks both the Byte Order Mark and an Encoding Declaration PI must be in the UTF-8 encoding. It is an error for a document to be in an encoding other than that declared in its Encoding Declaration PI. The XML specification shall include (possibly by reference to relevant IETF documentation) a list of standard declarations for the nonterminal "Encoding" in the above production, to support interoperability, including names for at least ISO-Latin-X and the JIS family. ----------------------------------------------------------------------- B.2 Should XML require each document instance to have a DTD or not (7.1)? In discussing this item, the ERB made the following decisions: 1. Well-formedness The XML spec shall define two characteristics which an XML document may possess, called "well-formedness" and "validity". A well-formed document, informally, is one for which no content model checking has been done, but which can be read by an XML processor with confidence in producing a correct ESIS. Questions remaining open include: (a) the specific definition of well-formedness -- it is expected to include at least least (1) a containing root element with no text outside it, (2) properly nested elements, (3) properly structured tags, and possibly other constraints on entity references, empty elements, etc. (b) whether two distinct levels of well-formedness (e.g. strong and weak) are necessary (c) the nature of well-formedness when there is no DTD or a partial DTD remains open. 2. Required Markup Declaration (votable Y/N) XML markup declarations are divided into DTDs pointed-at by the ' The RMD PI must appear after the Encoding Declaration PI, if any, and before the document type declaration itself, if any. Should the RMD state that the DTD is required ('DTD' or 'ALL'), it is a reportable error if the DTD cannot be retrieved. 3. Interpretation of Required Markup Declaration If no RMD PI is given, then - if a document type declaration is given, an XML processor must assume that the DTD is required, and read and process both the internal subset and the external DTD; it is a reportable error if the external DTD cannot be retrieved. This is as if had been specified. - if no document type declaration is given, an XML processor may do as it likes. For example, (a) signal an error, (b) behave as if were declared, (c) guess, on the basis of the root element's GI, and retrieve the appropriate well-known DTD if possible or act on hard-coded knowledge of the DTD (e.g. HTML). If an RMD PI is given, then - for the value NONE, a validating processor may check the DTD and/or instance to verify that in fact the DTD is not necessary to the correct construction of the ESIS; it's an error if the DTD is necessary but is specified. - for the value INTERNAL, a validating processor may check the accuracy of the RMD PI; a non-validating processor may read the internal subset and skip the external DTD. If the RMD PI is correct, the non-validating processor can construct the same parse as a validating parser. - for the value ALL, an XML processor must read and process the entire DTD, and construct the ESIS accordingly. (The DTD may be skipped only by applications which don't construct an ESIS in any meaningful sense.) A processor may issue an informational message if in fact the DTD could have been skipped, for this instance or for all documents in using the given DTD. ----------------------------------------------------------------------- Date: Thu, 17 Oct 96 13:23:55 CDT From: Michael Sperberg-McQueen Subject: C.12 types of declared values for attributes? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the ERB is leaning to keeping NAME(S) and NMTOKEN(S) but losing NUMBER(S) and NUTOKEN(S). C.12 Should XML change the set of types available for attributes? E.g. by suppressing NAME(S), NUMBER(S), NMTOKEN(S), NUTOKEN(S) and adding constraints in the form of regular expressions, ISO dates, language-code, external-id, type IDREF, ... (7.9.4, 11.3.3) From: Ken Holman To: "'w3c-sgml-wg@w3.org'" Subject: RE: some ERB decisions REF: A.20 Comments Date: Thu, 17 Oct 1996 16:36:44 -0400 I could not tell from the post if that which is said about A.20 is a consensus decision or an unresolved issue. >---------- >From: Michael Sperberg-McQueen[SMTP:U35395@UICVM.CC.UIC.EDU] >Sent: Thursday, October 17, 1996 12:01 >To: W3C SGML Working Group >Subject: some ERB decisions > > >The SGML ERB met Wed. Oct 16th and voted on several items already >submitted to the SGML WG. Participating: Bosak, Bray, Clark, Maler, >Paoli, Sperberg-McQueen, and Sharpe. Absent: DeRose, Hollander, >Kimber, >Magliery, and Connolly. All decisions were by consensus of all those >participating in the call, and thus carry a majority of the membership >of the ERB. > >Several issues were left unresolved at the end of the meeting; the ERB >will be meeting today and Saturday to discuss them further and resolve >them. > > > A.20 XML will retain the notion and syntax of comments (= 8879's > 'comment declarations') (7.6, 10.3), but comment declarations > will contain at most one comment: comments will take the form > '' or else will begin with '' (no > space allowed), and may not contain '--'. > >Comments will take the form '', no internal '--' is >allowed >and no white space between the final '--' and the final '>'. > >Empty comments () will not be allowed in XML. If this issue is still open as unresolved, I find that the empty comment is very useful and I feel that it should be retained. ......... Ken -- G. Ken Holman Tel: +1 613 596-CADE(2233) /\ /\ Chief Technology Officer Fax: +1 613 596-5934 \/ \/ Computer Microstar Software Ltd. WATS: 1 800 267-9975 /\ /\ Aided 3775 Richmond Road Mail: gkholman@microstar.com \/ \/ Document Nepean Ontario Info: cade@microstar.com /\ /\ Engineering CANADA K2H-5B7 Web: http://www.microstar.com \/ \/ -- G. Ken Holman Phone: +1 613 489-2987 P.O. Box 266 Street: 1605 Mardick Court Kars, Ontario CANADA KOA-2E0 E-mail: ab945@freenet.carleton.ca -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAjHOimAAAAEEAK47HbDtZZB8hJBk+r9Zh7m7QxdFHTaz/m200QQ7J9XX4QYs h6hsuP6ZqBJXyLdmIVMEwR6Ry6oxjKMd6BRJ8OGScD89eIghgbrpMX+900NxM0x2 v3yWO9ki2gKRPrn4vlCXznnmcmsyke0G02T2LefXbgZHyVSqDSOLy8nwuN7dAAUR tClHLiBLZW4gSG9sbWFuIDxhYjk0NUBmcmVlbmV0LmNhcmxldG9uLmNhPg== =IN3T -----END PGP PUBLIC KEY BLOCK----- > Date: Thu, 17 Oct 96 17:27:26 CDT From: Michael Sperberg-McQueen Subject: Re: some ERB decisions To: Gavin Nicol , W3C SGML Working Group On Thu, 17 Oct 1996 14:40:06 -0400 Gavin Nicol said: >> - all XML processors must accept documents in UTF-8 and UCS-2 (or >> optionally UTF-16) form > >I'm not a great fan of UTF-16, and am worried about the connotations >of "accept". Does that mean parse, process, or just accept and die? I think it means parse successfully. Some processing may involve resources (e.g. fonts) over which neither an XML implementor nor a user may have control, so it'd be hard to guarantee or require that. (Users at my university, for example, do not control which X11 fonts are available on our Unix systems. I'm not sure our staff does either, but that's another question.) Accept-and-die doesn't fall within the range of meanings I associate with 'accept', but if there's any doubt the spec should make it clear. >> - XML processor may provide a user option which causes them to accept >> documents in other coded character sets (e.g. ISO 8859 or JIS 0208) >> or other encodings of 10646 or other coded character sets (e.g. >> Extended Unix Code) -- this behavior must be optional (i.e. the user >> must be able to turn it off, so that documents not in UTF-8 or >> UCS-2 raise errors). > >OK. I can live with this, but am not overly happy about the "must be >optional" clause. Motivation is simple: if I want to ensure that document D is in a form that all XML processors can parse, then I need a way, using the processor in front of me, to check that. It's the same idea as in the Pascal spec: conforming Pascal implementations *must* provide a user option turning off all local extensions and flagging as errors anything the spec says is an error. There was some sentiment, when we discussed the topic again this morning, to restrict this rule to validating processors, and allow non-validating processors to do it whether the user likes it or not. This seems to me a pointless complication of a simple rule, but it may go into the spec. -C. M. Sperberg-McQueen Date: Thu, 17 Oct 96 18:41:49 CDT From: Michael Sperberg-McQueen Subject: RE: some ERB decisions REF: A.20 Comments To: Ken Holman , W3C SGML Working Group On Thu, 17 Oct 1996 16:55:33 -0400 Ken Holman said: >I could not tell from the post if that which is said about A.20 is a >consensus decision or an unresolved issue. > >> ... >> A.20 XML will retain the notion and syntax of comments (= 8879's >> 'comment declarations') (7.6, 10.3), but comment declarations >> will contain at most one comment: comments will take the form >> '' or else will begin with '' (no >> space allowed), and may not contain '--'. >> >>Comments will take the form '', no internal '--' >>is allowed and no white space between the final '--' and the >>final '>'. >> >>Empty comments () will not be allowed in XML. > >If this issue is still open as unresolved, I find that the empty comment >is very useful and I feel that it should be retained. Sorry for the confusion. Both of the flush-left paragraphs are reports of decisions: is in and is out. The motive for omitting was that its most frequent function, namely the escaping of delimiters (e.g. to type an SGML example showing the use of the <p> tag and the </p> tag) is no longer applicable since < and & are always recognized as delimiters in XML unless escaped by < and &. Its other uses (escaping record ends and decoration in a simple ASCII-art style are those that come to my mind) were not felt critical enough to justify retaining it and its attendant complications to the grammar of XML. -C. M. Sperberg-McQueen Date: Thu, 17 Oct 1996 22:07:59 -0400 From: gtn@ebt.com (Gavin Nicol) To: U35395@UICVM.CC.UIC.EDU CC: w3c-sgml-wg@w3.org Subject: Re: some ERB decisions >>OK. I can live with this, but am not overly happy about the "must be >>optional" clause. > >Motivation is simple: if I want to ensure that document D is in a >form that all XML processors can parse, then I need a way, using the >processor in front of me, to check that. OK. I can accept that. Let's hope XML doesn't go the same way as PASCAL though... Date: Thu, 17 Oct 1996 22:04:31 -0400 From: gtn@ebt.com (Gavin Nicol) To: U35395@UICVM.CC.UIC.EDU CC: w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results >XML does not explicitly sanction the use of any other encodings. It is >recognized, however, that many documents exist in other encodings. To >support processors in dealing with this situation, an XML document may >contain at its beginning, before any other text, markup, PIs, or white >space, an Encoding Declaration PI matching > >EncDecl ::= > '' > >An XML processor may choose to read Encoding Declaration PIs and accept >nonstandard encodings so declared. In validating processors such >behavior must be at user option. ... >An XML document which lacks both the Byte Order Mark and an Encoding >Declaration PI must be in the UTF-8 encoding. It is an error for a >document to be in an encoding other than that declared in its Encoding >Declaration PI. This CANNOT be REQUIRED behaviour. This is a gross hack!!! I also cannot condone the clause "does not explicitly sanction". Seems to me like here is another mailing list that I've wasted a lot of time on... Date: Thu, 17 Oct 1996 22:53:54 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.11 Multiple declarations for attributes? At 1:23 PM 10/17/96, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to yes. > >C.11 Should XML retain SGML's prohibition on multiple attribute-list >declarations for the same element (11.3.1) or on multiple >declarations for the same attribute (11.3.2)? 11.3.1 no. I still think that this simple mechanical DTD transform would be staggeringly useful. 11.3.2 yes. I can't even tell what 2 delcarations for one attribute would mean. I wish that I could declare one model for an attribute on one element and a different model for the same attribute on another element, but the language surgery would be too intense even for me to advocate it in XML. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:53:46 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.8 Prohibit reference to undeclared elements? At 1:21 PM 10/17/96, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to no (i.e. to >retaining the rules in 8879). > >C.8 Should XML prohibit content-model references to undeclared >elements (11.2.4)? Yes. All we get from this is a bunch of "clever coding tricks" == "weird, hard-to-understand hacks". It's much easier, and moer natural, to go with the first commandment of every other language in the world except SGML: 1.0 "you must define what you reference" Languages differ on when and how and what you declare, but few have this feature. If we allow reference to undefined elements, they should be legal. In addition, if we retain this distinction, we can't tell the difference between an "elephant's child" hack and an "incomplete DTD". -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:52:59 -0400 To: W3C-SGML-WG@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: A17: keep or drop entities? After reflection, I think we should keep external entities. FPIs and FSIs should be syntactically reserved, with pointers to the relevant SGML material as an explanation, but they themselves should not be part of XML 1.0. This _commits_ us to an XML 2.0. If such a commitment is not plausible, we should bite the bullet and put it all in now. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:53:06 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.9 Forbid & connector? At 1:22 PM 10/17/96, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to yes. > >C.9 Should XML forbid use of the '&' connector in content models >(11.2.4.1)? Well, this is a peculiar reversal for me, but since we are going to keep the weird semantics of SGML content models, & does not seem too burdensome. And it is useful in some contexts. I don't feel strongly about it, but we've already given up the hope that anyone can apply well known theory, or common knowledge in implementing the feature, and & is easy when you just parse against the parse tree (which is what people will do). Maybe that's an instance of another straw for the implementor's back, but since we're throwing in a brick, I don't see that baking the brick with straw in it is going to make that much difference. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:53:03 -0400 To: W3C-SGML-WG@w3.org From: "David G. Durand" (David G. Durand) Subject: a comment on comments (meta-comment comment?) I'm sorry that we are trying to disallow "--" in comments. No browser vendor has implemented the standard correctly in this regard, because it is too unnatural to fly in the internet. Some of us -- I am one! -- are addicted to em-dashes. This will be a common (and intentional) mis-implemented feature of XML. --> should be the only string to terminate a comment and the end of it. In XML the distinction is particularly unmotivated because we don't even have the (bad) syntactic justification of multiple comments. We are requiring every XML processor to implement special code to barf on user input -- where it causes no parsing or semantic ambiguity. People on the internet at large already think SGML is stupid. We need not feed their misconceptions. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:53:43 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.10 Allow nondeterministic content models? At 1:23 PM 10/17/96, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the question needs further >discussion in the work group. > >C.10 Should XML allow nondeterministic content models (11.2.4.3)? Yes, but if we do that, why not full regular expressions? We trashed that (unwisely) in the name of SGML compatibility. I don't understand the reasoning here. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:52:55 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: B.10 Empty elements? I think empty elements are needed, and that the syntax is unnacceptable. I think we should ignore the BUGs in ESIS that reflect the view that empty elements are useful containers that _cannot contain anything_. Empty elements are useful for _point_ phenomena in a text. They identify a position in the text and attach properties to it (a good example being TEI milestones). This is an important kind of thing to describe, and is accordingly common. I think that in this case we can diverge to one of the NET syntaxes (I like myself). We are already going to have to explain that without a fixed DTD (like HTML has) we need end tags; given that we are already violating people's HTML expectations for an explainable reason, we can use the same grounds to justify self-revealing "EMPTY" tags. I tend to agree with the opinion of some that a partial DTD gets us into a hard place: now we don't just have maybe a DTD, maybe not a DTD, but perhaps an incomplete DTD. Conformance will be too hard to specify, and people will be confused. Since the NET solutions are at least nominally SGML (if uncommon SGML that most editors cannot generate), they even pass the hard SGML compatibility test we have saddled ourselves with. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:54:00 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.16 Behavior when DTD is incomplete? At 1:35 PM 10/17/96, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to not >prescribing any particular behavior. > >C.16 When given an incomplete DTD, should XML parsers assume all >attributes are implicity declared CDATA, or should some attribute >names cause other assumptions (e.g. attributes with the same name as >some type of declared value might be assumed to have that declared >value)? Implicit CDATA. There's no benefit in leaving this undefined, and being smart about it will just make worse trouble. Of course, "id" will already be a fixed, undeclared, universally accessible attribute anyway; so the "smartness" doesn't get you much. Anyway, even if we make the mistake of cluttering XML with NMTOKEN and its ilk, the parser must assume CDATA absent a declaration. Otherwise we will be annoying the user with errors (they may not be able to get rid of) to the effect that "you meant this to be an NMTOKEN, and it's not". That's the kind of error message that makes me give my monitor the finger. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:53:50 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.7 inclusions and exclusions? At 1:21 PM 10/17/96, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to eliminating >both inclusion and exclusion exceptions. > >C.7 Should XML prohibit the use of inclusion and exclusion exceptions >in element declarations? (11.2.4, 11.2.5)? No. The only problem I ever saw with them was the whitespace stuff, and we're going to fix that otherwise anyway, right? Inclusions can make things hard to format, but what is the problem with exclusions? I think we should have both, or maybe just exclusions, but not none. What I'd really like is a "one-level" inclusion so that I could declare an element and say that it should be included anywhere in the immediate content of another element. I _know_ we're not going to do that one. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:53:57 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.5 hexadecimal character references? At 1:20 PM 10/17/96, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the question needs further >discussion in the work group. > >C.5 if XML uses ISO 10646, should there be a special form of >character reference using hexadecimal, not decimal, numbers, since >most references to ISO 10646 and Unicode use hex, not decimal (9.5)? The function character solution proposed by Gavin, I think, is perfect. Either that or a special set of predeclared entities: but case-sensitivity gets you in trouble there. We need an easy way to do this, and unless we're going to give away hex calculators to every user, they should be able to use hex. I suppose another possiblity would be to use a 2-level lexer like Java does, but that's not easy to understand. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:52:49 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: B.9 Formal system, public identifiers? At 3:21 PM 10/16/96, Charles F. Goldfarb wrote: >The FSI design effectively treats an informal system identifier (i.e., an >ordinary string) as a default storage object specification. The usual >default is >OSFILE. For XML, we could let the default be URL. In other words, for a URL you >could enter either: > >http://www.exasperated.org > >or > >http://www.exasperated.org > >For other storage managers that XML supports in future versions, the normal FSI >syntax would be used. This is a pretty decent solution. I'd like the option to use FSI's and FPI's since I think I can implement the few kinds I would want in _much_ less than 5000 lines of code. We can handle this like the alternate character sets: implementations are allowed to support it, but need not. Network publication should _not_ use FSIs or FPIs until XML 2.0 defines exactly how they should work. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 23:16:11 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: B.1 and B.2 results At 10:04 PM 10/17/96, Gavin Nicol wrote: >>XML does not explicitly sanction the use of any other encodings. It is >>recognized, however, that many documents exist in other encodings. To >>support processors in dealing with this situation, an XML document may >>contain at its beginning, before any other text, markup, PIs, or white >>space, an Encoding Declaration PI matching >> >>EncDecl ::= >> '' >> >>An XML processor may choose to read Encoding Declaration PIs and accept >>nonstandard encodings so declared. In validating processors such >>behavior must be at user option. >... >>An XML document which lacks both the Byte Order Mark and an Encoding >>Declaration PI must be in the UTF-8 encoding. It is an error for a >>document to be in an encoding other than that declared in its Encoding >>Declaration PI. > >This CANNOT be REQUIRED behaviour. This is a gross hack!!! I also cannot >condone the clause "does not explicitly sanction". > >Seems to me like here is another mailing list that I've wasted a lot >of time on... Well, I hope you won't leave, until we've all decided to stop wasting time! I agree with Gavin however that this is not good behavior: The most likely transport method for XML will be HTTP or one of it's replacements. HTTP _has_ proper metatdat facilities. If the MIME stuff isn't good enough, we can define our own MIME header for character encodings. I don't have a problem with allowing hacks to determine the character set (but we can't use character definitions we must say that the initial bytes must be read as Latin-1 characters, say, to determine the encoding. We also need to talk about pad bytes, if needed for some encodings. BUT these hacks must apply if the encoding is not given in metadata. Metadata could be the command-line, a catalog, or the MIME header. The old TEI assumption that we've got just a lump of bytes is not so common any more. By having the "hack" version of the spec as the fallback, we have an easy way of handling things properly whether are users are smart: MIME headers rule! or not-so-smart: "I've got a floppy disk, can you help me read the document?" I hate character set issues, but I have to agree with Gavin that explicitly ignoring the main protocol of the Web is a loser, especially when it has the potential for a nice solution of the problem. We can even explicitly define acceptable channels for metadata. Ignoring the FEFF at the beginning should be required when the metadata is present, as should be ignoring the hack. It should be legitimitate not to add this information at all, if transmitting over a channel that can convey encoding information (like HTTP). A user's save-to-disk option might well have to add on a yucky header of the sort Gavin deplores (because most filesytems lack metadata, and probably will forever). Is this sort of a compromise reasonable? -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 20:05:22 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: gtn@ebt.com CC: U35395@UICVM.CC.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results | This CANNOT be REQUIRED behaviour. This is a gross hack!!! I also cannot | condone the clause "does not explicitly sanction". That's odd. We went waaaaay out of our way to accommodate alternative character encodings. Maybe when you've had a little time to consider this you can explain the problem in more detail. Jon Date: Thu, 17 Oct 96 13:23:04 CDT From: Michael Sperberg-McQueen Subject: C.10 Allow nondeterministic content models? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the question needs further discussion in the work group. C.10 Should XML allow nondeterministic content models (11.2.4.3)? Date: Thu, 17 Oct 96 13:22:35 CDT From: Michael Sperberg-McQueen Subject: C.9 Forbid & connector? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the ERB is leaning to yes. C.9 Should XML forbid use of the '&' connector in content models (11.2.4.1)? Date: Thu, 17 Oct 96 13:21:04 CDT From: Michael Sperberg-McQueen Subject: C.6 multiple declarations of same element? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the ERB is leaning to retaining the prohibition. C.6 Should XML retain SGML's prohibition on multiple declarations for the same element (11.2.1)? Date: Thu, 17 Oct 96 13:21:54 CDT From: Michael Sperberg-McQueen Subject: C.8 Prohibit reference to undeclared elements? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the ERB is leaning to no (i.e. to retaining the rules in 8879). C.8 Should XML prohibit content-model references to undeclared elements (11.2.4)? Date: Thu, 17 Oct 1996 23:35:39 -0400 To: W3C SGML Working Group From: Arjun Ray Subject: Re: C.14 Enumerations in attribute declarations? At 01:32 PM 10/17/96 CDT, Michael Sperberg-McQueen wrote: >C.14 Should XML allow more than one enumerated type (name-group >declared value) to contain the same possible value (11.3.3)? Yes. 1. The restriction has to do with minimization rules and the SHORTTAG feature being an omnium gatherum. 2. Not allowing this fails the Stoopid Test when attribute specifications will be in the canonical NAME="VALUE" form anyway. Order of preference (most to least desirable): - remove 8879's restriction - eliminate enumerations - nonreportable error - retain Arjun -- "Features whose purpose is to cause errors should be removed" -- Erik Naggum Date: Thu, 17 Oct 96 13:21:38 CDT From: Michael Sperberg-McQueen Subject: C.7 inclusions and exclusions? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the ERB is leaning to eliminating both inclusion and exclusion exceptions. C.7 Should XML prohibit the use of inclusion and exclusion exceptions in element declarations? (11.2.4, 11.2.5)? Date: Thu, 17 Oct 1996 18:35:29 +0100 From: Lou Burnard To: W3C-SGML-WG@w3.org Subject: reb B.10 empty elements [sorry this was delayed by typo in address] From: OXVAXD::LOU "Lou Burnard" 15-OCT-1996 22:51:43.84 To: WRC-SGML-WG@W3.ORG CC: LOU Subj: re: B.10 empty elements I still like best the option, with the option of an additional PI to specify that it's not worth looking for a following for the benefit of those who cannot be bothered to maintain a stack in their code. Just thought I'd mention it. Lou Date: Thu, 17 Oct 96 13:19:23 CDT From: Michael Sperberg-McQueen Subject: C.3 text entities as values of ENTITY attributes? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the ERB is leaning to retaining the prohibition. C.3 should XML retain or relax SGML's prohibition on ENTITY attributes referring to SGML text entities (7.9.4.3)? Date: Thu, 17 Oct 96 13:20:43 CDT From: Michael Sperberg-McQueen Subject: C.5 hexadecimal character references? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the question needs further discussion in the work group. C.5 if XML uses ISO 10646, should there be a special form of character reference using hexadecimal, not decimal, numbers, since most references to ISO 10646 and Unicode use hex, not decimal (9.5)? Date: Thu, 17 Oct 96 13:23:31 CDT From: Michael Sperberg-McQueen Subject: C.11 Multiple declarations for attributes? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the ERB is leaning to yes. C.11 Should XML retain SGML's prohibition on multiple attribute-list declarations for the same element (11.3.1) or on multiple declarations for the same attribute (11.3.2)? Date: Thu, 17 Oct 96 13:18:48 CDT From: Michael Sperberg-McQueen Subject: C.2 prescribed implementation of ENTITY-END signal? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the ERB is leaning to leaving this question to the implementors. C.2 should XML prescribe the use of an ENTITY-END character as the canonical method of handling entity boundaries, as a way of simplifying exposition and implementation (6.2.2)? Date: Thu, 17 Oct 96 13:17:56 CDT From: Michael Sperberg-McQueen Subject: C.1 synchronous or asynchronous entities? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the ERB is leaning to requiring all text entities -- certainly external ones -- to be synchronous (if text entities exist at all in XML, which has not yet been decided). C.1 should XML require all entities to be synchronous with the document's logical structure? Date: Thu, 17 Oct 96 13:20:13 CDT From: Michael Sperberg-McQueen Subject: C.4 Undeclared entities? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the ERB is leaning to declaring only lt, gt, and amp automatically and making references to undeclared entities be a reportable error. C.4 if XML makes DTDs optional and allows partial DTDs, what must or may a parser do when it encounters references to undeclared entities (9.4)? Should XML declare any set of entities automatically? Date: Thu, 17 Oct 96 13:35:11 CDT From: Michael Sperberg-McQueen Subject: C.16 Behavior when DTD is incomplete? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the ERB is leaning to not prescribing any particular behavior. C.16 When given an incomplete DTD, should XML parsers assume all attributes are implicity declared CDATA, or should some attribute names cause other assumptions (e.g. attributes with the same name as some type of declared value might be assumed to have that declared value)? Date: Fri, 18 Oct 1996 00:00:24 -0400 To: W3C SGML Working Group From: Arjun Ray Subject: Re: C.12 types of declared values for attributes? At 01:23 PM 10/17/96 CDT, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to keeping >NAME(S) and NMTOKEN(S) but losing NUMBER(S) and NUTOKEN(S). > >C.12 Should XML change the set of types available for attributes? >E.g. by suppressing NAME(S), NUMBER(S), NMTOKEN(S), NUTOKEN(S) and >adding constraints in the form of regular expressions, ISO dates, >language-code, external-id, type IDREF, ... (7.9.4, 11.3.3) /* suppressing strong urge to blast SGML's "typing" of attributes */ If an att spec is going to have the lexical form name="value", and a XML parser (as opposed to a validator) won't have a DTD, aren't we left with just ? For a XML validator (which presumably will need a DTD), the issue becomes one of a meaningful/useful set of "data types". If regexps and such are within scope, then considerations such as keeping names and losing numbers is missing the forest for the trees. Just use regexps and be done with it. OTOH, if the choice is restricted to which out of the original set to retain, then losing all of them except CDATA (perhaps renamed to RCDATA??;-)) is the logical choice: an inadequate and overlapping set of alternatives is just needless complexity. Pass detailed validation to the application -- since it's the app's bailiwick to grok the attribute semantically. Arjun -- "Features whose purpose is to cause errors should be removed" -- Erik Naggum Date: Thu, 17 Oct 96 13:34:45 CDT From: Michael Sperberg-McQueen Subject: C.15 New methods for attribute defaults? To: W3C SGML Working Group On 23 October 1996, the ERB will vote to decide the following question. A straw poll indicates the ERB is leaning to no, on the grounds that this can be done with architectural forms. C.15 Should XML define new specific methods of inferring values for attributes with no attribute-value specifications (11.3.4)? E.g. INHERITED, to signify that the value is taken from the attribute of the same name (and type) on the smallest enclosing element with such an attribute. From: lee@sq.com Date: Thu, 17 Oct 96 23:47:54 EDT To: dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: C.7 inclusions and exclusions? > What I'd really like is a "one-level" inclusion so that I could declare an > element and say that it should be included anywhere in the immediate > content of another element. I agree strongly. David, I am not picking on you in what follows -- I agree with all of your remarks, I think.... > I _know_ we're not going to do that one. Yeah, it would be too useful :-) But the way things are going, XML isn't going to be used very widely anyway. It's accumulating too many of the things that, in practice, have made SGML unpopular with those people whose favour we now seek to curry. Or so it seems to me. We have multiple syntaxes for representing structure, "justified" by nonsense about what is or isn't a document; if your language isn't good enough to represent non-document objects, fix it, don't switch to another language mid-stream. We have arcane whitespace rules (well, it comes and goes). We have content models that are not standard regular expressions -- if we end up with only or groups, though, that's not so bad. Especially if we lose inclusions, exclusions and "&". We have comments that "don't work properly". We have (or am I wrong here?) marked sections and verbatim elements, in which the parsing rulles suddenly change, and which are delimited by a strange syntax. It's idiosyncratic. It's irregular. It's ugly. It needs more work. Well, that's OK, that's what we're here for. But let's not lose sight of the goal of wide deployment. Someone very close to the development of SGML once told me that a reason not to simplify SGML by allowing end tags on EMPTY elements was that it would allow "amateurs" to write SGML parsers. But the SGML language itself was designed by people who were experts in their own fields, but amateur language designers, as it seems to me. (I know I don't know them all, so if there were some domain experts in parser theory on the committee who weren't sufficiently influential, sorry.) Let's not repeat that mistake. Listen to the experts when they speak. There are good reasons for terms like LALR and LR(1).... :-) Few drivers want a car with two brake pedals, one for speeds of less than 45 MPh and one for greater speeds, nor a separate steering wheel for turning left when in third gear going downhill. Different road conditions do not merit different kinds of controls. Perhaps this is just my frustrations, in which case I apologise for wasting your time. Maybe other people don't feel the way I do. Imagine if the Unix C compiler output its parse tree in SGML, and so did the Pascal compiler, sharing the same code generation algorithm. Imagine if they output SGML to the assembler, so that you could insert an SGML-based code optimiser. Imagine if you could use the SGML-awk to write a little peephole optimiser (in the sense of Thomson & Ritchie). Or monitor the stream going through the compiler to generate a cross-reference code listing. What if database schemas were written in SGML? Spreadsheets? But right now, even XML is dangerously arcane. Take a big step back and imagine (if you will) that you had never seen SGML, and approached the XML specification. Would it seem easier to you to adopt it unchanged, to adopt a subst of it that suited youm, or to go off and do your own thing untrammelled by its complexities? Compared to a full SGML parser, maybe it's a breeze. Compared to learning to recite the entire Vedic literatire in sanskrit, writing an XML parser is also going to be easy, I suppose :-) Sorry for a long rant. But I really do think we need to keep reminding ourselves of this stuff. Lee From: lee@sq.com Date: Fri, 18 Oct 96 00:24:34 EDT To: w3c-sgml-wg@w3.org Subject: Re: C.11 Multiple declarations for attributes? > On 23 October 1996, the ERB will vote to decide the following > question. A straw poll indicates the ERB is leaning to yes. > > C.11 Should XML retain SGML's prohibition on multiple attribute-list > declarations for the same element (11.3.1) or on multiple > declarations for the same attribute (11.3.2)? I would say no. In the case of multiple attribute definitions for a given element type, there are two (I think) plausible interpretations: (1) merge the definitions, so that for the element boy now has three attributes (2) replace the definitions, so that the element boy has only two attributes (Name and HairColour). The former of these is the one I consider to be sensible and useful. If you have control of DTD & documents, you don't need (2). If you don't have control, (2) doesn't help you enough to be worth while. A third possibility would of course be but this involves adding reserved keywords, and I don't think the extra power is worth it. SGML lets you have repeated declarations for some things but not others, although I don't know why. The TEI DTD would be simplified slightly if you could have multiple definitions for element content models, with the first definition seen winning (as per entities)....! Lee [PS: I don't believe we have discussed NAMECASE, so I am free to use mixed case in my examples and assume they are case sensitive :-) The recent discussion of attribute values in Unicode points out that converting to upper case is not in fact straight forward, and that Unocode suggests that lower case be used if normalisation is required, e.g. so you don't have to decide whether the upper-case version of e-acute is E (France) or E-acute (Quebec). XML should be case sensitive for ease of internationalisation, and since entities are already usually case sensitive there is precedent. But I am putting too much into a footnote. ] Date: Fri, 18 Oct 1996 00:33:16 -0400 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu CC: w3c-sgml-wg@w3.org Subject: Re: B.10 Empty elements? > I think empty elements are needed, and that the syntax >is unnacceptable. I think we should ignore the BUGs in ESIS that reflect >the view that empty elements are useful containers that _cannot contain >anything_. Empty elements are useful for _point_ phenomena in a text. They >identify a position in the text and attach properties to it (a good example >being TEI milestones). This is an important kind of thing to describe, and >is accordingly common. > >I think that in this case we can diverge to one of the NET syntaxes (I like > myself). We are already going to have to explain that without I am 100% in agreement here. I am another one that would like to see regexps allowed for content models, though I'd go further, and hope to be able to use regexps for content and attribute value validation as well. Still, given the SGML compatability rule, I guess this is out of the question.... Date: Fri, 18 Oct 1996 00:51:49 -0400 From: gtn@ebt.com (Gavin Nicol) To: bosak@atlantic-83.eng.sun.com CC: U35395@UICVM.CC.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results >| This CANNOT be REQUIRED behaviour. This is a gross hack!!! I also cannot >| condone the clause "does not explicitly sanction". > >That's odd. We went waaaaay out of our way to accommodate alternative >character encodings. Maybe when you've had a little time to consider >this you can explain the problem in more detail. The PI hack is gross, and the wording used to describe it basically makes it the primary promoted mechanism. This flies in the face of both common sense, and the current extant meta-data mechanisms. Date: Fri, 18 Oct 1996 00:49:47 -0400 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu CC: w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results >I don't have a problem with allowing hacks to determine the character set I have no problem with *allowing* them, but I have a very large problem with *requiring* or *promotong* them, to the point of basically excluding anything more reasonable. I think your compromise is reasonable, and I am willing to compromise. I am not willing to give into the ERB deciding to *promote* a hack when more suitable mechanisms exist, *and* are widely deployed. Date: Fri, 18 Oct 1996 00:54:50 -0400 From: gtn@ebt.com (Gavin Nicol) To: U35395@UICVM.CC.UIC.EDU CC: w3c-sgml-wg@w3.org Subject: Re: C.2 prescribed implementation of ENTITY-END signal? >C.2 should XML prescribe the use of an ENTITY-END character as the >canonical method of handling entity boundaries, as a way of >simplifying exposition and implementation (6.2.2)? As ENTITY-END is not really a character (like the infamous RE/RS pair) I'd lean to leaving this out. From: lee@sq.com Date: Fri, 18 Oct 96 00:50:44 EDT To: U35395@UICVM.CC.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? > C.4 if XML makes DTDs optional and allows partial DTDs, what must or > may a parser do when it encounters references to undeclared entities > (9.4)? Should XML declare any set of entities automatically? I would like to suggest -- at least briefly :-) -- a model in which entities can be expanded by a (conceptual) preprocessor. By conceptual, I mean that it doesn't need to be a separate physical process or a separate pass -- it could all be handled within a single program. SGML reinvented the C preprocessor with entities, but added some features... It seems that XML has only three kinds of entity: [1] parameter entities in the DTD (possibly) [2] entities for text substitution [3] entities for referring to and including external files Now, entities of type [1] and [2] are the same as each other, except for the different scopes and permitted contexts. That is, they do essentially the same thing. Entities of type 3 may be general or parameter entities, and may be used in one of three ways: [a] as an in-place inclusion . . . &Simon; [b] as a reference to a different kind of information . . . &Simon; [c] as a delayed reference Case [a] can be handled before the parser ever sees the data, just as the C preprocessor handles #include. For error handling, C allows #line 45 "filename" so that the C preprocessor can tell the C compiler what line number to put out on errors. (apologies to all those to whom this is blindingly obvious). Without a DTD you can't distinguish [a] and [b] until you actually fetch the data -- you then either inspect the data stream or use the MIME media type to determine how to handle the data. In a WWW environment, the actual declared notation (if you had a DTD) should of course be overridden by the MIME media type. In general, the media type may vary depending on the time of day -- for example, a server might have access to the same information in multiple formats, and prefer to serve up the most appropriate version (given the list that the browser said it handles) that is in the cache. I suppose a notation of "DYNAMIC" would be appropriate for that. At any rate, in XML we can't handle case [b] without a DTD. If there was no DTD, where did the entitiy definition come from? So there could always be a NOTATION, although we wouldn't know that it was right without fetching the data. It's a hint, if you will. Case [c], an entity-valued attribute, can't be handled at all without a DTD. With a DTD, the behaviour is implementation defined even in SGML (as I understand it). You can get even more undefined by having an NDATA attribute -- the standard and the handbook are hard to follow on this, as I and several others have found, especially when used without conref. But I digress. Entities for text substitution and for file inclusion can without loss of generality be expanded as the text is read over the network (say). Entities that have an associated notation must be passed on to the client of the parser. Does that sound reasonable? If we can phrase it in that way, it is just a sort of brain-dead cpp, or m4 with most of the features removed :-), and is easy to write and understand. You are then amenable, however, to evil tricks which must be firmly discouraged: '> &x; "> and so on. The only complication I see is that %entity; is not allowed after the start of the document, and &entity; is not expanded in the DTD itself. This does not quite work correctly with the current SGML rules on attribute values, where a CDATA attribute, despite being declared as CDATA, is actually RCDATA. Hence, would expand to and break. Is that a problem? My feeling is yes, it's a problem, although I have encountered more than one commercial parser that did indeed have problems with this sort of thing, especially with nested parameter entities. Lee Date: Fri, 18 Oct 1996 01:02:01 -0400 From: gtn@ebt.com (Gavin Nicol) To: lee@sq.com CC: dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: C.7 inclusions and exclusions? >Yeah, it would be too useful :-) But the way things are going, XML isn't >going to be used very widely anyway. It's accumulating too many of the >things that, in practice, have made SGML unpopular with those people whose >favour we now seek to curry. Or so it seems to me. Hmm. I tend to agree... >Imagine if the Unix C compiler output its parse tree in SGML, and so did >the Pascal compiler, sharing the same code generation algorithm. Imagine >if they output SGML to the assembler, so that you could insert an >SGML-based code optimiser. Imagine if you could use the SGML-awk to write >a little peephole optimiser (in the sense of Thomson & Ritchie). >Or monitor the stream going through the compiler to generate a >cross-reference code listing. > >What if database schemas were written in SGML? Spreadsheets? I imagined, and I saw LISP.... but you are right, these are all things that SGML *could* be useful for, or perhaps *should* be useful for, and it shouldn't take 40,000+ lines of code to write a validating parser for it. Date: Thu, 17 Oct 1996 14:40:06 -0400 From: gtn@ebt.com (Gavin Nicol) To: U35395@UICVM.CC.UIC.EDU CC: w3c-sgml-wg@w3.org Subject: Re: some ERB decisions > - the character repertoire of XML documents is that of ISO 10646 Good. > - conforming XML documents may be in UTF-8 or UCS-2 form Good. > - all XML processors must accept documents in UTF-8 and UCS-2 (or > optionally UTF-16) form I'm not a great fan of UTF-16, and am worried about the connotations of "accept". Does that mean parse, process, or just accept and die? > - XML processor may provide a user option which causes them to accept > documents in other coded character sets (e.g. ISO 8859 or JIS 0208) > or other encodings of 10646 or other coded character sets (e.g. > Extended Unix Code) -- this behavior must be optional (i.e. the user > must be able to turn it off, so that documents not in UTF-8 or > UCS-2 raise errors). OK. I can live with this, but am not overly happy about the "must be optional" clause. >Still open: details of the mechanism to be used for signaling the >encoding and/or coded character set in use. 3 methods: 1) MIME headers for HTTP/email/filesystem (via *.mim) 2) FSI attributes 3) Catalog parameters Date: Thu, 17 Oct 1996 22:53:21 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.3 text entities as values of ENTITY attributes? At 1:19 PM 10/17/96, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to retaining the >prohibition. > >C.3 should XML retain or relax SGML's prohibition on ENTITY >attributes referring to SGML text entities (7.9.4.3)? Why should we retain it, it's an arbitrary restriction that requires extra code and can't be justified as adding any advantage to XML. relax. (I know I should). -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:53:34 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.13 Multiple ID and NOTATION attributes? At 1:32 PM 10/17/96, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to no. > >C.13 Should XML remove SGML's prohibition on multiple ID or NOTATION >attributes on the same element (11.3.3)? NO. As I said before, I also think we should hardwire the attribute name "id" to mean "The ID attribute". Maybe we should do the same for notation, though that usage is much less common, so maybe we should keep our "notation" unpolluted. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:53:09 -0400 To: W3C-SGML-WG@w3.org From: "David G. Durand" (David G. Durand) Subject: SDATA entities A last _plea_ for their inclusion. Using strings to identify system dependent content (we could even require that SDATA always be a glyph, though I think that is excessive) is far better than using numerical codes. Let's not make any prescription about the use of square brackets in general entities, for pity's sake. SDATA will make a lot of things easier, and it's _easy_ to implement and explain. We need no convention for display of SDATA -- We could declare SDATA strings with "[]" to always be glyph identifications: only those in ISO standards are guaranteed to be available to all XML processing systems. -- David Later, we could even define a protocol (or application convention) to ask a server to resolve one of its SDATA strings to whatever is appropriate. RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:53:18 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.2 prescribed implementation of ENTITY-END signal? At 1:18 PM 10/17/96, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to leaving this >question to the implementors. > >C.2 should XML prescribe the use of an ENTITY-END character as the >canonical method of handling entity boundaries, as a way of >simplifying exposition and implementation (6.2.2)? I don't see suggestions for kludgey implementations of a feature as easing either exposition or implementation. If we simply disallow lexing of entity references between unescaped < and > characters, we can solve all the Ee problems. An implementation then must be able to resolve entities when an attribute value is examined. Clean, and I think it's even easy to do with LEX. I'd rather not mention the Ee strategy, and certainly would not require it. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:53:29 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.12 types of declared values for attributes? At 1:23 PM 10/17/96, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to keeping >NAME(S) and NMTOKEN(S) but losing NUMBER(S) and NUTOKEN(S). > >C.12 Should XML change the set of types available for attributes? >E.g. by suppressing NAME(S), NUMBER(S), NMTOKEN(S), NUTOKEN(S) and >adding constraints in the form of regular expressions, ISO dates, >language-code, external-id, type IDREF, ... (7.9.4, 11.3.3) We should either expand the space as originally suggested; I like regexp myself, and it's a drop-in in any language I can imagine people using for an XML parser (C, C++, Java). Otherwise, we should just go for CDATA, IDREF, and enumerated attributes and bag the rest (ID should always be legal, and always be an attribute called "id", I think). We're not allowing the unquotedness that NAME gets you, so we might as well make it as easy as possible for each application to reinvent the wheel of attribute subtyping without any interference from us. I find the built-in attribute types almost useless, myself. -- David RE delenda est. Some namespace pollution is your friend! _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:53:25 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.4 Undeclared entities? At 1:20 PM 10/17/96, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to declaring >only lt, gt, and amp automatically and making references to >undeclared entities be a reportable error. > >C.4 if XML makes DTDs optional and allows partial DTDs, what must or >may a parser do when it encounters references to undeclared entities >(9.4)? Should XML declare any set of entities automatically? All the ISO Latin-1 entities should be declared, as should any of the entities curently in HTML (even ones we think are stupid, if there are any such). People think this is a part of SGML anyway, and the names are well known. Compatibility with the general public's expectations dictates this answer. People _like_ namespace pollution when it meets their expectations (otherwise why would people like PERL?). This is a case where the anti-CS viewpoint should win out. What does reportable error mean for netscape? I think that, at the least, we should suggest non-bindingly that display applications treat undefined entities as "broken text" -- similarly to the current broken image strategy (which could also be viewed as a reportable error). -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:53:38 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.14 Enumerations in attribute declarations? At 1:32 PM 10/17/96, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the question needs further >discussion in the work group. Possible positions are to remove >8879's restriction (at the cost of more complex XML-to-SGML >DTD translation), to retain it, to eliminate enumerated values >entirely in the hope that WG8 will relax the restriction, or >to retain the restriction but make it a non-reportable error. > >C.14 Should XML allow more than one enumerated type (name-group >declared value) to contain the same possible value (11.3.3)? We _MUST_ remove this restriction. It's annoying even to SGML users of the minimization hack it enables. We can never sell it as a reasonable syntactic restriction. A reportable error should reflect something the user did that might cause a problem. This attribute value restriction, like the -- in comment restriction, no longer has any function in XML but to annoy the user. We don't want to annoy our users, especially when trying to get them to do something new. I can't imagine what a non-reportable error even is. If it's an error, it should be reported, if it shouldn't be reported, then that is prima facie evidence that it should _not_ be an error. Enumerated values are too well entrenched in HTML (as well as damned damned useful) to be eliminated. -- David RE delenda est. -- A few other things delenda est, as well. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 17 Oct 1996 22:53:14 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.1 synchronous or asynchronous entities? At 1:17 PM 10/17/96, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to requiring all >text entities -- certainly external ones -- to be synchronous (if >text entities exist at all in XML, which has not yet been decided). > >C.1 should XML require all entities to be synchronous with the >document's logical structure? Yes. As I said, I just can't see living without entity management. However, we must make whatever restrictions are necessary to ensure that a client _need not_ follow all entity references to get a parse. ==> An external entity must contain a forest of data and element trees, with _no_ incomplete markup. At first I thought that internal entities need no such restrictions, since they are already present, so we might as well allow entity markup hacking where it won't impair implementation. But this is wrong: if a reference to an asynchronous internal entity is found in an external entity, that external entity will not be independently parseable, due to the asynchrounous markup that cannot be resolved at that time. This is unacceptable. No asynchronous entitites of any kind. I want to imagine a smart client getting an XML entity representing a book and determining that the introduction entity is small enough to put inline, but that the chapters1-100 entities should be made into links that will expand at the user's choice. The above is separate from user links to external entities of any sort, but rather a decision that in implementation should be able to make about how much data is appropriate to parse at one time. The entity restriction will also let smart clients (of any sort) cache parsed entity bodies, since they will be complete, and a DTD is not required. This may prove to be quite useful. This means that if you want to cache parsed document fragments they may have "holes" for undefined entities, but that is pretty doable. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html >Received: by chuckd.allette.com.au.allette.com.au id AA04785 (5.65/IDA-1.5 for w3c-sgml-wg@w3.org); Fri, 18 Oct 1996 18:20:29 +1000 Date: Fri, 18 Oct 1996 18:20:27 +1000 (EST) From: Rick Jelliffe To: "David G. Durand" Cc: w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results On Thu, 17 Oct 1996, David G. Durand wrote: > I hate character set issues, but I have to agree with Gavin that > explicitly ignoring the main protocol of the Web is a loser, especially > when it has the potential for a nice solution of the problem. Yes, but from what Aladdin's cave does this information come from when it becomes time to transmit the data? Does the XML document get stored with a complete MIME header, is it maintained in some registry, is some extension to the filename used, or does the webserver autodetect, or does the webserver guess based on its own locale and OS, or what? I think the most practical thing is for the XML rules to state that it is the Webserver software's task to figure out the encoding (given that most sites this can be done from locale and OS, or from configuration files on a per file or per directory basis) but allow an override for documents that use some other encoding, in the form of PIs (that keep SGML compatibility). Character set should be an website administrator's task, not any business of Hiroshi Homepage (let alone Heinrich Heimblatt), as far as possible. It should be the Webservers responsibility to detect an overriding PI at the head of an XML document and to generate the appropriate MIME header information for transmission. So if people need to have foreign encoded documents on their site, they can readily mark them as such. In other words: SGML markup for storage, Web protocols for interchange. Rick Jelliffe http://www.allette.com.au/allette/ricko email: ricko@allette.com.au ================================================================ Allette Systems http://www.allette.com.au email: info@allette.com.au 10/91 York St, 2000, phone: +61 2 9262 4777 Sydney, Australia fax: +61 2 9262 4774 ================================================================ From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: C.15 New methods for attribute defaults? Date: Fri, 18 Oct 1996 11:48:25 GMT On Thu, 17 Oct 96 13:34:45 CDT, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to no, on the >grounds that this can be done with architectural forms. > >C.15 Should XML define new specific methods of inferring values for >attributes with no attribute-value specifications (11.3.4)? E.g. >INHERITED, to signify that the value is taken from the attribute of >the same name (and type) on the smallest enclosing element with such >an attribute. > I support the NO vote. Note also that HyTime default value lists do the same job. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: C.14 Enumerations in attribute declarations? Date: Fri, 18 Oct 1996 11:48:23 GMT On Thu, 17 Oct 96 13:32:27 CDT, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the question needs further >discussion in the work group. Possible positions are to remove >8879's restriction (at the cost of more complex XML-to-SGML >DTD translation), to retain it, to eliminate enumerated values >entirely in the hope that WG8 will relax the restriction, or >to retain the restriction but make it a non-reportable error. > >C.14 Should XML allow more than one enumerated type (name-group >declared value) to contain the same possible value (11.3.3)? WG8 has agreed to remove this restriction in SGML97. However, I think the right solution for XML is to eliminate enumeration on the grounds of simplifying attribute definitions. I'd dump all of the tokenized values for the same reason, except those that have SGML semantics that we are retaining in XML (possibly ID, IDREF, IDREFS, ENTITY, ENTITIES, and NOTATION). The SGML Extended Facilities, which WG8 have voted to incorporate in SGML97, have a lexical typing facility for data content and attribute values using regular expressions and other goodies. Why burden XML with the existing half measures? Keep things simple for XML 1.0 by sticking to CDATA and add clean lexical typing later. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: C.4 Undeclared entities? Date: Fri, 18 Oct 1996 12:01:20 GMT On Thu, 17 Oct 96 13:20:13 CDT, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to declaring >only lt, gt, and amp automatically and making references to >undeclared entities be a reportable error. > >C.4 if XML makes DTDs optional and allows partial DTDs, what must or >may a parser do when it encounters references to undeclared entities >(9.4)? Should XML declare any set of entities automatically? Questions like this are more easily analyzed if we avoid the confusing term "optional DTD". A missing DTD is really an implied DTD (like SGML's implied SGML Declaration) in which all element types have mixed content consisting of "(#pcdata | any element type)*" and all attributes are CDATA #REQUIRED (except for special conventions for ID, etc. that we might adopt). So there is always a DTD. Now the question is: what does a parser do with references to undeclared entities? There is no reason to do anything different >from what is done in SGML. As for declaring entities automatically, I assume that means there will be a piece of public text containing the "automatic" declarations that is considered to be referenced by all DTDs (including the implied one). Or, to put it another way, all DTDs are partial; the "automatic" entity declarations are the other part. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: C.12 types of declared values for attributes? Date: Fri, 18 Oct 1996 12:09:33 GMT On Thu, 17 Oct 96 13:23:55 CDT, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to keeping >NAME(S) and NMTOKEN(S) but losing NUMBER(S) and NUTOKEN(S). > >C.12 Should XML change the set of types available for attributes? >E.g. by suppressing NAME(S), NUMBER(S), NMTOKEN(S), NUTOKEN(S) and >adding constraints in the form of regular expressions, ISO dates, >language-code, external-id, type IDREF, ... (7.9.4, 11.3.3) I agree with David and Arjun. We only need CDATA and ID (which should always be named ID). With a DTD, IDREF(S), ENTITY(S), and NOTATION can be useful as well. SGML97 will have "regexp" and then some. The SGML Extended Facilities already has it. WG8 has not yet designed a revised ATTLIST syntax to incorporate it properly, though, so it is premature to include it in XML 1.0. (We'll have a mailing list for SGML97 so all of you will be able to participate in the design.) -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: C.3 text entities as values of ENTITY attributes? Date: Fri, 18 Oct 1996 12:14:45 GMT On Thu, 17 Oct 96 13:19:23 CDT, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to retaining the >prohibition. > >C.3 should XML retain or relax SGML's prohibition on ENTITY >attributes referring to SGML text entities (7.9.4.3)? Actually, this may not be an issue for XML, since any XML entity can be parsed as an XML document conforming to the implied DTD (which is what it means to say "there is no DTD"; see my other posting on this point). -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: C.6 multiple declarations of same element? Date: Fri, 18 Oct 1996 12:18:43 GMT On Thu, 17 Oct 96 13:21:04 CDT, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to retaining the >prohibition. > >C.6 Should XML retain SGML's prohibition on multiple declarations for >the same element (11.2.1)? Yes. XML DTDs should be really, really simple. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: C.7 inclusions and exclusions? Date: Fri, 18 Oct 1996 12:19:17 GMT On Thu, 17 Oct 96 13:21:38 CDT, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to eliminating >both inclusion and exclusion exceptions. > >C.7 Should XML prohibit the use of inclusion and exclusion exceptions >in element declarations? (11.2.4, 11.2.5)? Yes. SGML DTDs should be really, really simple. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: C.11 Multiple declarations for attributes? Date: Fri, 18 Oct 1996 12:25:12 GMT On Thu, 17 Oct 96 13:23:31 CDT, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to yes. > >C.11 Should XML retain SGML's prohibition on multiple attribute-list >declarations for the same element (11.3.1) or on multiple >declarations for the same attribute (11.3.2)? Yes, both for simplicity in teaching about and reading DTDs, and for conformance with 8879. We already have some of this stuff for meta-DTDs, and it seems clear that stuff like it will be in SGML97 (named attribute lists, etc.), but this kind of complexity has no place in a simplified SGML. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: C.3 text entities as values of ENTITY attributes? Date: Fri, 18 Oct 1996 11:48:21 GMT On Thu, 17 Oct 96 13:19:23 CDT, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to retaining the >prohibition. > >C.3 should XML retain or relax SGML's prohibition on ENTITY >attributes referring to SGML text entities (7.9.4.3)? If we're conforming to 8879, this question shouldn't even come up. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: C.16 Behavior when DTD is incomplete? Date: Fri, 18 Oct 1996 12:32:43 GMT On Thu, 17 Oct 96 13:35:11 CDT, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to not >prescribing any particular behavior. > >C.16 When given an incomplete DTD, should XML parsers assume all >attributes are implicity declared CDATA, or should some attribute >names cause other assumptions (e.g. attributes with the same name as >some type of declared value might be assumed to have that declared >value)? In every document processing system, SGML or not, there is always a full DTD. If the user isn't allowed to specify it (as he can in SGML), the implementors create it for him (usually without documenting it). XML should always have a full DTD, even though it should not be necessary to specify it completely for an individual document. Otherwise you have tag salad (with attribute dressing), and you lose SGML tool compatibility as well. It should be a straightforward job to define the omitted element types and attributes. I've made some suggestions in other postings as a starting point for discussion. "Incomplete DTD" should only mean "Incompletely-specified DTD". -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: lee@sq.com Date: Fri, 18 Oct 96 10:26:26 EDT To: dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: C.12 types of declared values for attributes? David G. Durand wrote: > We should either expand the space as originally suggested; I like regexp > myself, and it's a drop-in in any language I can imagine people using for > an XML parser (C, C++, Java). > > Otherwise, we should just go for CDATA, IDREF, and enumerated attributes > and bag the rest (ID should always be legal, and always be an attribute > called "id", I think). [...] I agree with you about regexp. Few people today would design a language with anything other than POSIX-style internationalised regular expressions (e.g. they have [:lower:], which refers to all lower case letters where [a-z] doesn't, as it omits AE-ligature, edh, e-acute, etc., used even in English outside certain countries...). You're also correct that there are regexp drop-ins for C, C++, Java and most other programming languges. Heck, even for FORTRAN probably :-) Non-standard regexps -- the defacto standard is significantly more influential than ISO, and has been for over 15 years, to the extent that even applications such as Microsoft Word use "standard" regular expression semantics int he Advanced Search -- non-standard regexps are a curse and and cannot be justified. But this applies to content models as well as recognition of attributes. * > Otherwise, we should just go for CDATA, IDREF, and enumerated attributes > and bag the rest (ID should always be legal, and always be an attribute > called "id", I think). [...] I would rather see every attribute called ID or beginning with ID. be an ID, and allow multiple ones -- the SGML restriction makes no sense to me at all, and in any case can't be enforced without a DTD. But you can always use CDATA for all except one (or all) of the ID attributes you want, and check them with application-level code, which is what people do today with SGML, whilst they are wondering why they have to do that :-) SO I could live with just ID. If people can't accept the use of fixed attribute names, a prefix would probably work: xml.id for example. The same sort of convention is needed for IDREF, and xml.idref is more appealing to me, as it's easy to explain tht attribute names starting with xml. are reserved. Lee To: W3C SGML Working Group From: Martin Bryan Subject: Re: C.13 Multiple ID and NOTATION attributes? Date: Fri, 18 Oct 1996 15:12:05 +0100 At 07:32 PM 17/10/96 +0100, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the ERB is leaning to no. > >C.13 Should XML remove SGML's prohibition on multiple ID or NOTATION >attributes on the same element (11.3.3)? Note that a Yes vote for this would clash with the idea of a fixed name for ids. I think this one has to be No for consistency, even though I hate the idea of having to force Tamils to using a rude word to identify anything in XML! ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Fri, 18 Oct 1996 10:59:46 -0400 To: Charles@sgmlsource.com, Michael Sperberg-McQueen From: "Eve L. Maler" Subject: Re: C.12 types of declared values for attributes? Cc: W3C SGML Working Group At 12:09 PM 10/18/96 GMT, Charles F. Goldfarb wrote: >On Thu, 17 Oct 96 13:23:55 CDT, Michael Sperberg-McQueen > wrote: > >>On 23 October 1996, the ERB will vote to decide the following >>question. A straw poll indicates the ERB is leaning to keeping >>NAME(S) and NMTOKEN(S) but losing NUMBER(S) and NUTOKEN(S). >> >>C.12 Should XML change the set of types available for attributes? >>E.g. by suppressing NAME(S), NUMBER(S), NMTOKEN(S), NUTOKEN(S) and >>adding constraints in the form of regular expressions, ISO dates, >>language-code, external-id, type IDREF, ... (7.9.4, 11.3.3) > >I agree with David and Arjun. We only need CDATA and ID (which should always be >named ID). With a DTD, IDREF(S), ENTITY(S), and NOTATION can be useful as well. With NMTOKEN(S), you not only retain case insensitivity, but have an up-front way to delimit multiple values. So I think we should at least consider keeping it, too. It's not too hard to come up with reasons to have multiple ID attributes on one element. I'd like to see SGML97 remove this restriction, and until then, retain the restriction. Making "id" the canonical name for XML ID attributes, while intuitive in the framework of SGML86 and very attractive all around, unfortunately wouldn't provide an easy path for allowing multiple IDs. Eve Date: Fri, 18 Oct 1996 10:56:40 -0400 To: Rick Jelliffe From: "David G. Durand" (David G. Durand) Subject: Re: B.1 and B.2 results Cc: w3c-sgml-wg@w3.org At 6:20 PM 10/18/96, Rick Jelliffe wrote: >Yes, but from what Aladdin's cave does this information come from when it >becomes time to transmit the data? Does the XML document get stored with a >complete MIME header, is it maintained in some registry, is some extension >to the filename used, or does the webserver autodetect, or does the >webserver guess based on its own locale and OS, or what? It's the webserver's business. If people don't like the standard HTTP header directories, or server extension configurations, they can use the "self-detecting character hacks" (the PI). Parsers, on the other hand are what we are specifying. And parsers only need to say what they do given some input. We can define a "metadata channel" -- additional input to the parser, determined as reasonable; we will provide two bindings: Command line option, for command-line parsers, and HTTP header policies for HTTP stream parsers. Other channels will have to define how they will transmit or use meta-data, as appropriate. If they don't have meta-data, they can use the hack. > >I think the most practical thing is for the XML rules to state that it is >the Webserver software's task to figure out the encoding (given that most >sites this can be done from locale and OS, or from configuration files on >a per file or per directory basis) but allow an override for documents >that use some other encoding, in the form of PIs (that keep SGML >compatibility). Character set should be an website administrator's task, >not any business of Hiroshi Homepage (let alone Heinrich Heimblatt), as >far as possible. XML is not defining server behavior, but client behavior. The server will have two options: metadata, or PI. We should declare that metadata is preferred over PI, if the channel provides metadata. >In other words: SGML markup for storage, Web protocols for interchange. This falls out of my proposal, if that's the way the server wants to work: no metatdata in, but metadata required to go out because HTTP has the metadata channel. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Fri, 18 Oct 1996 10:56:34 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Hear, Hear! Lee's and Gavin's comments all deserve close attention. They do a better job of arguing than I do. But I like to flame anyway: A few of Lee's points that I'd like to highlight: Case sensitivity (normalized case is lower case). Reading any Unicode case rules is a good argument for this, as he notes. merging ATTLISTs (This has been needed for a decade, I don't see why we shoule keep on waiting; let's do it!) The only point I'd differ with Lee on is the preprocessor idea. I prefer my late-binding solution to entities in attribute values; we lose a whole class of possible bugs, and the preprocessing part of the lexical analyzer only needs two modes: In-tag (between <>) and out-of-tag (everywhere else). This is the same as the CPP being able to not expand macros in strings, limited knowledge of the embedded language to make things work nicely. Gavin's point about metadata is important; we should not reinvent wheels in an oval shape and then fix the suspension on the car. However, the SGML traditionalists have a point as to the potential unavailability of metadata. Given that, we need some hacks for character encoding. I think that channel-dependent metadata should always take precedence over "hack metadata". That means that people can do what they need to, but will be under some pressure to do things right. That should be the philosophy of XML. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Fri, 18 Oct 96 10:28:48 CDT From: Michael Sperberg-McQueen Subject: Re: C.10 Allow nondeterministic content models? To: W3C SGML Working Group On Thu, 17 Oct 1996 22:50:14 -0400 David G. Durand said: >At 1:23 PM 10/17/96, Michael Sperberg-McQueen wrote: >> >>C.10 Should XML allow nondeterministic content models (11.2.4.3)? > >Yes, but if we do that, why not full regular expressions? We trashed >that (unwisely) in the name of SGML compatibility. I don't understand >the reasoning here. My sense of the ERB's intention is that there is some desire to reopen that question and to consider changing the earlier decision, at least in individual cases (which include general regular expressions and determinism in content models). I should probably have said that explicitly; sorry. -C. M. Sperberg-McQueen Date: Fri, 18 Oct 96 10:07:47 CDT From: Michael Sperberg-McQueen Subject: Re: C.14 Enumerations in attribute declarations? To: W3C SGML Working Group On Thu, 17 Oct 1996 22:50:07 -0400 David G. Durand said: >I can't imagine what a non-reportable error even is. If it's an >error, it should be reported, if it shouldn't be reported, then that >is prima facie evidence that it should _not_ be an error. Apologies for my careless phrasing. 'Non-reportable error' is not expected to be a technical term in the XML spec; what I meant in my posting by it is an error which is not a reportable error, where 'error' means a violation of the spec the results of which are typically undefined, and 'reportable error' means an error which a conforming processor is required to detect and report (unless the user has turned off error reporting -- to answer David's acute query, I suspect 'no error reporting' would be the default in a Netscape implementation of XML, and probably in most browsers). 'Non-reportable error' does NOT mean 'error which a conforming application is not *allowed* to detect or report' -- though there might be some sentiment for introducing such a concept precisely for cases like this one of enumerated types in attribute values. Defining double use of a name token to be an error ensures that SGML parsers can read XML DTDs without modification, which is clearly a Good Thing. Not requiring XML parsers to report it ensures that an XML parser can 'recover' from the error in an obvious way, which is also (I think) a Good Thing. We have a stated goal of ensuring that SGML processors should be able to read XML instances without modification, if the XML instances are provided with a suitable prolog. This is not at all the same thing as agreeing to burden XML processors with every rule, complication, exception, and restriction in the syntax of SGML prologs, in order to ensure that the XML prolog itself is suitable for SGML tools. Any restriction, complication, or oddity to be built into XML should pass the same test: is it essential, is it a good idea, is it worth the cost? At the very least, when we adopt rules not on their technical merits but solely to preserve compatibility with 8879, even in cases where 8879's rule is now generally conceded to be a Bad Thing, I think the spec should introduce the feature with the phrase "For compatibility reasons ... " -- as in "For compatibility reasons, the string '--' (double hyphen) is not allowed within comments." WG8 members can then read the XML spec with a clear idea of where an XML rule was adopted because it seemed a good one, and where it was adopted solely for the sake of compatibility with 8879:1986 and will gladly be changed when the revision sets things right. -C. M. Sperberg-McQueen Date: Fri, 18 Oct 1996 11:23:08 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.12 types of declared values for attributes? Cc: W3C SGML Working Group I never understood why I needed more than one unique identifier for an element: that's why the SGMl syntax never bothered me. If Eve and Lee both think it's useful, I'll defer to their judgement (though I'd love an example). If we are going to do that, I like Lee's prefix proposal: We could have attributes named id.attrname and idref.attrname. Making ID attributes self-identifying in this way, and turning them into an application convention, removes another problem from ID as specified: the restricted syntax. We can declare XML IDs as CDATA "with an interpretation" and make users much happier. Martin's comment about rude words is a problem, but not one that I can see how to solve, as we will need _some_ fixed string. ensuring non-rudeness in any natural language would proabably also insure meanininglessness all around, too. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html From: R A Milowski Subject: Re: A17: keep or drop entities? To: w3c-sgml-wg@w3.org Date: Fri, 18 Oct 1996 10:57:42 -0500 (CDT) > After reflection, I think we should keep external entities. FPIs and > FSIs should be syntactically reserved, with pointers to the relevant SGML > material as an explanation, but they themselves should not be part of XML > 1.0. This _commits_ us to an XML 2.0. If such a commitment is not > plausible, we should bite the bullet and put it all in now. After being quite silent for awhile, this is a statement I could agree with on external entities. Creating generic publishing systems for use over the web is going to demand more complex features. These features are not going to be trivial to solve and implement--but they will not be impossible either. At some point it time we are going to have to say: "We've done all the easy stuff, and its not enough to solve our problems." We should outline what we think should be in or considered in 2.0 if we are not allowing these things now. We don't want to go through the same discussion about character encodings, RS/RE, etc. again if we aren't going to change them in 2.0. We should have an additive process. ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@copsol.com Copernican Solutions Incorporated (612) 379 - 3608 Date: Fri, 18 Oct 1996 12:37:10 -0400 From: gtn@ebt.com (Gavin Nicol) To: ricko@allette.com.au CC: dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results >> I hate character set issues, but I have to agree with Gavin that >> explicitly ignoring the main protocol of the Web is a loser, especially >> when it has the potential for a nice solution of the problem. > >Yes, but from what Aladdin's cave does this information come from when it >becomes time to transmit the data? Does the XML document get stored with a >complete MIME header, is it maintained in some registry, is some extension >to the filename used, or does the webserver autodetect, or does the >webserver guess based on its own locale and OS, or what? Any of the above, and others possibilities too (fields in a database etc.) The very fact that you have so many options should make it obvious that this is meta-data, not data, and does not belong *in* the document. >a per file or per directory basis) but allow an override for documents >that use some other encoding, in the form of PIs (that keep SGML >compatibility). Character set should be an website administrator's task, I have no problem with *allowing* PI's (I personally would never use them, or write software that did), but I cannot condone *requiring* them or *promoting* them. >In other words: SGML markup for storage, Web protocols for >interchange. In that case, why not just use catalogs and FSI's for storage? I cannot see *why* we need markup to describe meta-data that also applies to the markup describing the meta-data. This seems to be to be logically inconsistant. Date: Fri, 18 Oct 1996 12:18:33 -0500 From: Len Bullard To: R A Milowski CC: w3c-sgml-wg@w3.org Subject: Re: A17: keep or drop entities? R A Milowski wrote: > > > After reflection, I think we should keep external entities. FPIs and > > FSIs should be syntactically reserved, with pointers to the relevant SGML > > material as an explanation, but they themselves should not be part of XML > > 1.0. This _commits_ us to an XML 2.0. If such a commitment is not > > plausible, we should bite the bullet and put it all in now. I think the commitment to XML 2.0 is invitable if we want to stick to the schedule and get a revenue stream started to support the effort. The most serious mistake we can make is to treat this as an academic exercise and hope that freeware will appear from the universities. The WWW is a wheel in motion, going somewhere fast, and to influence that direction in any way at this late date, we must run alongside until we can get inside. So, it is not possible to consider 1.0 as a complete XML. It is a version designed to get products in the pipeline of framework handlers. Once a sustainable product line is established, it is possible to consider features that add power/complexity. Don't try to do it in a day. > After being quite silent for awhile, this is a statement I could > agree with on external entities. Creating generic publishing systems > for use over the web is going to demand more complex features. These > features are not going to be trivial to solve and implement--but they > will not be impossible either. True, but if the bar is raised too high, too many jumpers fail on the first try and the sport is considered harmful or *only for the gifted*. > At some point it time we are going to have to say: "We've done all the > easy stuff, and its not enough to solve our problems." True. Let's figure out what the problems are by experience. > We should outline what we think should be in or considered in 2.0 if > we are not allowing these things now. We don't want to go through the > same discussion about character encodings, RS/RE, etc. again if we > aren't going to change them in 2.0. We should have an additive process. I agree, Alex, but I have the VRML 1.0/2.0 experience in mind as I watch this process. From a standing start, they got products in the pipeline less than three months after spec completion. They did not start fresh; they hacked Open Inventor ruthlessly, taking away features until they had an initial design that could be built quickly, would work in the Internet environment, could be supported by existing code (e.g, Renderware). In VRML 2.0, the same process was repeated. We knew we needed motion and extensibility. Frame interpolators were put in the language and protos (internal and external). In 2.0, the syntax was improved. To get this, SGI had to sign up to provide a reference implementation free and clear of encumbrance. I believe such requirements may be necessary for complex features one wants to add to XML. A script node is included, but no script language is required. An external interface is being outlined now. VRML 2.0 must be the last major shock to the syntax because too much software had to be rewritten. We might better that achievement, but 2.1 and up to 3.0 are considered improvements to capabilities such as the scripting and multi-user support. So, while I agree with what you are proposing, I expect that it will be hard without experience with 1.0 to precisely define the problems. We may want to do as the VRML community did, and provide a list of capabilities we want to have in place at each version level. Goals must ensure stability of product development. I also keep the HyTime experience in mind. IMO, it could have achieved more if we had spec'd a little, implemented a little, fielded a little, and spec'd a little more. It might have taken just as much time, but it would have had a product line and revenue stream in place when completed. Len Bullard Lockheed Martin To: W3C SGML Working Group Subject: Re: C.9 Forbid & connector? Date: Fri, 18 Oct 1996 11:46:24 -0700 From: Joe English David G. Durand wrote: > >C.9 Should XML forbid use of the '&' connector in content models > >(11.2.4.1)? > > Well, this is a peculiar reversal for me, but since we are going to keep > the weird semantics of SGML content models, & does not seem too burdensome. > And it is useful in some contexts. I don't feel strongly about it, but > we've already given up the hope that anyone can apply well known theory, or ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ?!? > common knowledge in implementing the feature, [...] > [...] > Maybe that's an instance of another straw for the implementor's back, > but since we're throwing in a brick, I don't see that baking the brick with > straw in it is going to make that much difference. I don't recall seeing this resolution passed by the ERB, did I miss something :-)? What "brick" are you talking about? Since we've dropped OMITTAG, and will probably drop inclusion and exclusion exceptions, '&' groups are the only feature remaining that are beyond the scope of what anyone with a copy of the Dragon Book can handle in a day's work. (The ambiguity restriction does not matter here: unambiguous content models are a strict subset of regular expressions; any algorithm for matching against general REs will also work for unambigous ones. In fact, the ambiguity rule can make things *easier* for implementors.) > and & is easy when you just > parse against the parse tree (which is what people will do). I don't see that '&' is _easy_, but as long as we keep the ambiguity restriction it's at least tractable. --Joe English jenglish@crl.com From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: C.14 Enumerations in attribute declarations? Date: Fri, 18 Oct 1996 19:46:57 GMT On Fri, 18 Oct 96 10:07:47 CDT, Michael Sperberg-McQueen wrote: >At the very least, when we adopt rules not on their technical merits but >solely to preserve compatibility with 8879, even in cases where 8879's >rule is now generally conceded to be a Bad Thing, I think the spec >should introduce the feature with the phrase "For compatibility >reasons ... " -- as in "For compatibility reasons, the string '--' >(double hyphen) is not allowed within comments." WG8 members can then >read the XML spec with a clear idea of where an XML rule was adopted >because it seemed a good one, and where it was adopted solely for >the sake of compatibility with 8879:1986 and will gladly be changed >when the revision sets things right. I think this is an excellent idea. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- Date: Fri, 18 Oct 1996 16:09:35 -0400 To: w3c-sgml-wg@w3.org From: Arjun Ray Subject: Re: B.10 Empty elements? At 12:33 AM 10/18/96 -0400, Gavin Nicol wrote: >> I think empty elements are needed, and that the syntax >>is unnacceptable. I think we should ignore the BUGs in ESIS that reflect >>the view that empty elements are useful containers that _cannot contain >>anything_. Empty elements are useful for _point_ phenomena in a text. They >>identify a position in the text and attach properties to it (a good example >>being TEI milestones). This is an important kind of thing to describe, and >>is accordingly common. >> >>I think that in this case we can diverge to one of the NET syntaxes (I like >> myself). We are already going to have to explain that without > >I am 100% in agreement here. >I am another one that would like to see regexps allowed for content >models, though I'd go further, and hope to be able to use regexps for >content and attribute value validation as well. Still, given the SGML >compatability rule, I guess this is out of the question.... Indeed. The SGML compatibility rule [*] is the real problem, in that the (core) concrete syntax (actually, even the abstract syntax) is *lexically* inadequate. The issue has always been one of tokenization. The denotation of an empty element is indistinguishable from the start tag of an element with content: in SGML systems the DTD has always been present to resolve the ambiguity on what from a lexical point of view are essentially "semantic" grounds. Without a DTD, the alternatives are restricted to either disallowing empty elements altogether or disambiguating them *lexically*. If a NET variant can be made to work (I still don't see how, though), that's fine. Otherwise, IMHO, since the need for empty elements is clear cut, it's time to bite the bullet and seriously consider a syntax that requires preprocessing before it can be accepted by, ah, legacy SGML processors. (For instance, the STAGC proposal discussed a few months back on CTS.) [*] This rule tends to be invoked much more often in the interests of *forwards* compatibility of legacy systems [will old tools grok new stuff?] than the backwards compatibility of new specs [will new tools grok old stuff?] Arjun -- "Features whose purpose is to cause errors should be removed" -- Erik Naggum Date: Fri, 18 Oct 1996 16:44:39 -0400 From: gtn@ebt.com (Gavin Nicol) To: aray@nmds.com CC: w3c-sgml-wg@w3.org Subject: Re: B.10 Empty elements? >Indeed. The SGML compatibility rule [*] is the real problem, in that >the (core) concrete syntax (actually, even the abstract syntax) is >*lexically* inadequate. The issue has always been one of >tokenization. The denotation of an empty element is indistinguishable >from the start tag of an element with content: in SGML systems the >DTD has always been present to resolve the ambiguity on what from a >lexical point of view are essentially "semantic" grounds. Without a >DTD, the alternatives are restricted to either disallowing empty >elements altogether or disambiguating them *lexically*. Yes. This is the conflusion of syntax and semantics that I refer to: SGML has too many things in the parser that are really interpreted based on a semantic decision. Date: Fri, 18 Oct 1996 17:21:00 -0500 To: Joe English , W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.9 Forbid & connector? At 11:46 10/18/96, Joe English wrote: >David G. Durand wrote: > >> >C.9 Should XML forbid use of the '&' connector in content models >> >(11.2.4.1)? >> >> Well, this is a peculiar reversal for me, but since we are going to keep >> the weird semantics of SGML content models, & does not seem too burdensome. >> And it is useful in some contexts. I don't feel strongly about it, but >> we've already given up the hope that anyone can apply well known theory, or > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >?!? > >> common knowledge in implementing the feature, [...] >> [...] >> Maybe that's an instance of another straw for the implementor's back, >> but since we're throwing in a brick, I don't see that baking the brick with >> straw in it is going to make that much difference. > > > >I don't recall seeing this resolution passed by the ERB, >did I miss something :-)? What "brick" are you talking about? Way back when, Tim Bray posted the following, in the "Report from the SGML ERB meeting of Oct. 9th": >>A.27 XML will behave like SGML as regards behavior and precedence >>of occurrence indicators and connectors in content models (11.2.4.1, >>11.2.4.2). (Whether to abolish the AND connector will be decided >>separately.) >Passed, Unanimous. That means the whole ball of wax, to me. If I had to implement SGML's ambiguity I'd implement and ambiguity check and match against the parse tree for the model. If I'm parsing that way, what's a single bit of additional state per moel token? As I say, I'm not emotional about kereping &, just don't see why not. >(The ambiguity restriction does not matter here: unambiguous content models >are a strict subset of regular expressions; any algorithm for matching >against general REs will also work for unambigous ones. In fact, >the ambiguity rule can make things *easier* for implementors.) Yeah, once the check is over. It's doing the check that is unpleasant and non-standard. Still, your point about hust using RE is a good one. >> and & is easy when you just >> parse against the parse tree (which is what people will do). > >I don't see that '&' is _easy_, but as long as we keep the >ambiguity restriction it's at least tractable. You just keep a flag as to whether the & group is used up yet or not. Gross, but servicable and easy.... -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Fri, 18 Oct 1996 18:20:26 -0400 To: W3C SGML Working Group From: Arjun Ray Subject: Re: C.10 Allow nondeterministic content models? At 01:23 PM 10/17/96 CDT, Michael Sperberg-McQueen wrote: > >C.10 Should XML allow nondeterministic content models (11.2.4.3)? Yes. (I assume that "determinism" -- or the complementary "ambiguity" -- here pertains to the sense clarified in Anne Bruggemann-Klein's work: that the Glushkov NFA is also a DFA.) Strictly speaking, this is an issue of validation, not parsing, i.e. the software involved need only be a recognizer, not necessarily a parser. (A similar comment applies to "syntax directed translation" via attribute or transduction grammars, where the need to preserve the semantic content -- or intent -- can introduce tradeoffs in algorithms between scope and efficiency.) AFAIK, most recognition algorithms actually exploit nondeterminism in the sense that they work as NFAs rather than DFAs (sometimes even constructing states and transitions on the fly), because the problem is to validate an instance as an admissible member of a class without necessarily preserving a parse tree (like a non-constructive existence proof.) Annex H notwithstanding, the only advantage of "deterministic" content models is forwards compatibility with unreviewed 8879. Arjun -- "Features whose purpose is to cause errors should be removed" -- Erik Naggum Date: Fri, 18 Oct 1996 21:43:26 -0400 To: W3C SGML Working Group From: Arjun Ray Subject: Re: C.7 inclusions and exclusions? At 01:21 PM 10/17/96 CDT, Michael Sperberg-McQueen wrote: >C.7 Should XML prohibit the use of inclusion and exclusion exceptions >in element declarations? (11.2.4, 11.2.5)? No. There is no impact on DTD-less parsing either way (OK, OK, I'm aware of the RS/RE complications and sundry other esoterica, but the operative assumption is that those gotchas will be resolved adequately.) It's a validation issue. I see no reason to require that a validator be a parser, so the considerations reduce to (a) whether the presence of inclusions and exclusions make the recognition problem inherently more difficult for implementors, and (b) whether the absence of inclusions and exclusions make the structure definition problem inherently more difficult for users. Ad a) the difficulties for parsers stem from inclusions and exclusions being shorthand for an otherwise factorially larger set of rules. But I'm not convinced that this is a show-stopper for recognizers. Ad b) given that users will find the need for floating elements and to prohibit (indirect) recursion, the utility of inclusions and exclusions shouldn't be in doubt. So it boils down to whether the technical reasons to prohibit them are sufficiently severe. Arjun From: lee@sq.com Date: Fri, 18 Oct 96 22:40:51 EDT To: Charles@sgmlsource.com, U35395@UICVM.UIC.EDU Subject: Re: C.6 multiple declarations of same element? Cc: w3c-sgml-wg@w3.org > >C.6 Should XML retain SGML's prohibition on multiple declarations for > >the same element (11.2.1)? > > Yes. XML DTDs should be really, really simple. I'm not sure that any significant complexity is added, especially since the only content model allowed is a repeatable or group (right?). A second declaration merrely adds to the or-group. If my understanding on this is right, by the way, then the non-determinisitic content models have already become a non-issue. You can't have ambiguity in a model of the form (#PCDATA|a|b|c....) Lee From: lee@sq.com Date: Fri, 18 Oct 96 22:35:35 EDT To: Charles@sgmlsource.com, U35395@UICVM.UIC.EDU Subject: Re: C.4 Undeclared entities? Cc: w3c-sgml-wg@w3.org Charles Goldfarb argued: > Questions like this are more easily analyzed if we avoid the confusing term > "optional DTD". > A missing DTD is really an implied DTD (like SGML's implied SGML > Declaration) in which all element types have mixed content consisting of > "(#pcdata | any element type)*" and all attributes are CDATA #REQUIRED > (except for special conventions for ID, etc. that we might adopt). I am not sure where this comes from -- are you saying that this is the current state of ISO8879, or that you would like to propose this for XML? > So there is always a DTD. Now the question is: what does a parser do with > references to undeclared entities? > There is no reason to do anything different > from what is done in SGML. This is invidious, but fallacious, reasoning. That there is always a DTD does not mean that there is always a user-supplied DTD. If your implied DTD declares all the elements, it could also declare all the entities just as easily. > As for declaring entities automatically, I assume that means there will be a > piece of public text containing the "automatic" declarations that is > considered to be referenced by all DTDs (including the implied one). It is sufficient to specify an algorithm by which such entities cn be constructed. For example, a language such as XML could accept an entyt of the form base - diacritic [- diacritic ]* and construct the appropriate sequence correctly and automatically: &a-acute-cedilla; might be an a with both an acute accent and a cedilla mark. A public text containing all such possible definitions might be very large, but this would not matter in practice, as they do not need to be enumerated. > Or, to put it another way, all DTDs are partial; the "automatic" > entity declarations are the other part. I for one would find it helpful if you could mark proposals as that, and statements of how ISO8879 works today as such -- I recognise that this is a weakness in my understanding of SGML, but I didn't understand ISO8879 as specifying anything about implied DTDs. But you cannopt possibly be talking about XML, because no consensus has been reached about implied or partial DTDs, so one cannot say of XML that `all DTDs are partial'. Or are you hoping we will accept your proposal as a fact and not question it?? that can't be right, sorry. I'm missing something. Lee Date: Fri, 18 Oct 1996 19:45:33 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Address change: Nancy Paisner The following WG member address has changed: nancy@hi.com is now npaisner@oec.com (OEC is a subsidiary of Borland.) Jon To: W3C SGML Working Group Subject: Re: C.2 prescribed implementation of ENTITY-END signal? Date: Fri, 18 Oct 1996 12:01:02 -0700 From: Joe English > On 23 October 1996, the ERB will vote to decide the following > question. A straw poll indicates the ERB is leaning to leaving this > question to the implementors. > > C.2 should XML prescribe the use of an ENTITY-END character as the > canonical method of handling entity boundaries, as a way of > simplifying exposition and implementation (6.2.2)? My inclination would be leave it out of the XML spec. (I didn't really understand "Ee" until almost two years of working with SGML and studying the Handbook; I don't think it simplifies the exposition at all, rather quite the reverse...) --Joe English jenglish@crl.com Date: Fri, 18 Oct 1996 20:42:30 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: C.4 Undeclared entities? [Charles Goldfarb:] | Questions like this are more easily analyzed if we avoid the confusing | term "optional DTD". A missing DTD is really an implied DTD (like | SGML's implied SGML Declaration) in which all element types have mixed | content consisting of "(#pcdata | any element type)*" and all | attributes are CDATA #REQUIRED (except for special conventions for ID, | etc. that we might adopt). There is no "implied DTD" of this nature in XML. It is possible for a well-formed XML document to be parsed in the absence of a DTD. In such a case, the DTD does not maintain a noumenal existence; it just really isn't there at all. Jon Date: Sat, 19 Oct 1996 02:25:53 -0400 To: Charles@sgmlsource.com From: Harvey Bingham Subject: Re: C.4 Undeclared entities? [CDATA #REQUIRED?] Cc: w3c-sgml-wg@w3.org At 12:01 1996-10-18 GMT, Charles wrote: >On Thu, 17 Oct 96 13:20:13 CDT, Michael Sperberg-McQueen > wrote: > >>On 23 October 1996, the ERB will vote to decide the following >>question. A straw poll indicates the ERB is leaning to declaring >>only lt, gt, and amp automatically and making references to >>undeclared entities be a reportable error. >> >>C.4 if XML makes DTDs optional and allows partial DTDs, what must or >>may a parser do when it encounters references to undeclared entities >>(9.4)? Should XML declare any set of entities automatically? > >Questions like this are more easily analyzed if we avoid the confusing term >"optional DTD". A missing DTD is really an implied DTD (like SGML's implied SGML >Declaration) in which all element types have mixed content consisting of >"(#pcdata | any element type)*" and all attributes are CDATA #REQUIRED (except >for special conventions for ID, etc. that we might adopt). How can all attributes be CDATA #REQUIRED, when I suspect that many tags will omit attributes for some occurrences, and include them for others. In most SGML applications I believe #IMPLIED is the most common default. An implied DTD can provide minimum semantic interpretation of any attribute, unless the attribute name suggests its semantics, such as ID would, or possibly the form of the attribute value, such as a valid URL might. So, the other attributes whether present or omitted can have effect on some associated style sheet, where an implied action would be overridden by an explicit attribute value. > >So there is always a DTD. Now the question is: what does a parser do with >references to undeclared entities? There is no reason to do anything different >from what is done in SGML. > An undeclared entity could be passed on to the application, and possibly retained as such when part of #PCDATA. >As for declaring entities automatically, I assume that means there will be a >piece of public text containing the "automatic" declarations that is considered >to be referenced by all DTDs (including the implied one). Or, to put it another >way, all DTDs are partial; the "automatic" entity declarations are the other >part. That "automatic" set of entity declarations is open-ended, effectively any apparent entity should be in it. Regards/Harvey Bingham Date: Sat, 19 Oct 1996 08:30:22 +0000 To: W3C SGML Working Group From: Tim Bray Subject: Re: C.9 Forbid & connector? David G. Durand wrote: >>> since we are going to keep the weird semantics of SGML content models... >>> we've already given up the hope that anyone can apply well known theory, or >Joe English wrote: >>?!? David G. Durand wrote: >Way back when, Tim Bray posted the following, in the >"Report from the SGML ERB meeting of Oct. 9th": >>>A.27 XML will behave like SGML as regards behavior and precedence >>>of occurrence indicators and connectors in content models >That means the whole ball of wax, to me. No. It means that to the extent that we have () and | and , and * and PCDATA and so on in XML content models, they mean the same thing as they mean when they appear in SGML content models. Between the things that we've turfed and the things that we're going to turf, there is going to be A LOT LESS allowed in XML content models. With the explicit aim, as reflected in our design goals, of making parsers easy and in particular susceptible to standard formal methods. And specifically, let's lose the &. Not that it isn't useful... but the ROI is negative. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Sat, 19 Oct 1996 08:19:57 +0000 To: W3C SGML Working Group From: Tim Bray Subject: Internationalization The ERB has received a certain amount of grousing from people disappointed at XML's not using MIME or FSI machinery to specify language encoding. The reasons for this are twofold: 1. Non-network access [This is obvious] a lot of XML files are going to be stored in files and accessed by means other than HTTP, and some encoding signalling mechanism is obviously required. Also, we wanted something that was simple, easy to explain, and could be done by anyone with whatever editor they were using. 2. Distrust There is, on the ERB, a pervasive lack of trust in the reliability of Mime and other external/metadata encoding signaling devices. This is felt particularly intensely by me, based on my experience in processing many millions of HTML pages for the Open Text Index, and by Michael Sperberg-McQueen, based on his years of work in a highly heterogeneous networked computing environment. I, and I'm sure many of the rest of us, have enjoyed the beneficial effects of Mime technologies in recent years; but if you're doing anything large-scale on the Web, if you rely on external metadata/signalling in general, you're dead - or more formally, your receiving application will suffer an unreasonable number of failures due to various botches and bogosities. The reasons for this are, in my experience, a combination of incompetence in website administrators and lack of education in document authors. Personally, I think that with a *combination* of mime, metadata, and careful examination of the first few bytes of the file to see if any reasonable interpretation of the bit patterns generates something like ' From: Tim Bray Subject: Re: C.10 Allow nondeterministic content models? At 11:46 AM 18/10/96 -0700, Joe English wrote: > >In fact, >the ambiguity rule can make things *easier* for implementors.) Say what? The algorithms necessary to detect ambiguity are not typically within the repertoire of the hypothetical CS bachelor's-degree type that we'd like to be able to construct a validating parser. Furthermore, with the parser generators that I have to hand, in no case does an ambiguous content model complicate the task. Furthermore, since we've lost the tag miminization that opens the trap that I have been told the ambiguity exclusion exists to patch, I can't imagine why an XML parser author would *want* thus to constrain DTD authors, aside from a desire to comply with a non-useful clause in a standard that is there only to ensure compliance with another standard, which in any case is likely to be amended soon to remove this problem. If it's not obvious, I am deeply unhappy with the prospect of the restriction on so-called "ambiguous" grammars making it into XML. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Sat, 19 Oct 1996 12:54:18 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: B.1 and B.2 results In answering a long private email to Michael Sperberg-McQueen on the topic of character encodeing and metatdata, I had a revelation as to the correct way to do this, without blowing our compatibility with the rest of the world. First a few premises of my reasoning: 1: Character set declaration data must be parseable by everyone. "Bad File Format" is an unacceptable error if what it _really means_ is "Character set 'Bill's Cyrillic' unknown". Any character-set determining prefix to a file must be a parseable series of bytes that everyone can read. 2: compatibility with HTTP's transport functionality is essential. We should not talke the time, or the risk, of reinventing yet another way to handle character sets. So, I suggest that we have the following problems: STEP 1: determine number of bytes in a character code (bit-combination). The possiblities are 1 and 2 bytes/character (UTFs count as 8-bit codes for our purposes). I don't remember if '\0' avoidance is still an issue. I'd prefer to that we define it as a non-issue, and look at the first 2 bytes of the input. Presence of a null indicates a 2-byte character set, and its position indicates the endianity of the data, if we decide to allow this option (I'd prefer to big-endian, and lose a case). (STEP 1'): Or we can use the FFFE hack, if that will have wider support. STEP 2: now we have a standard MIME-header, encoded in Latin1, using the byte coding as determined in step 1 (i.e., 1-byte, big-endian, or little-endian). We will define the fields that we _require_ (charset, only, I hope). We will ignore, but permit, others. The CRLFCRLF sequence that terminates the header will start the XML instance. This header will be optional for channels (like HTTP) where the header information can be preserved, and required for all others. This means any XML processor can produce the needed tagging information, and it can always be parsed. If we go further, we could eliminate STEP 1, and parser the header in 8-bit mode always. Then people can use their standard codebase to parse the headers, but 2-byte systems might show the header as garbage (proabably a _bad thing_). -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html To: W3C SGML Working Group Subject: Re: C.9 Forbid & connector? Date: Sat, 19 Oct 1996 09:51:31 -0700 From: Joe English David G. Durand wrote: > At 11:46 10/18/96, Joe English wrote: > >(The ambiguity restriction does not matter here: unambiguous content models > >are a strict subset of regular expressions; any algorithm for matching > >against general REs will also work for unambigous ones. In fact, > >the ambiguity rule can make things *easier* for implementors.) > > Yeah, once the check is over. It's doing the check that is unpleasant and > non-standard. You don't have to perform the check though, even in a validating parser: "4.329 validating SGML parser: A conforming SGML parser that can find and report a reportable markup error if (and only if) one exists. 4.267 reportable markup error: A failure of a document to conform to this International Standard [...] other than a semantic error [...] or: a) an ambiguous content model b) [...]" [ 9.3, "Conforming Systems", p. 215] In other words, 8879 (for better or worse) places the burden of ensuring non-ambiguity on the DTD designer, not the parser. Also note that checking for ambiguity is straightforward -- as long as there are no '&' groups. > >> and & is easy when you just > >> parse against the parse tree (which is what people will do). > > > >I don't see that '&' is _easy_, but as long as we keep the > >ambiguity restriction it's at least tractable. > > You just keep a flag as to whether the & group is used up yet or not. > Gross, but servicable and easy.... That only works if the content model is unambiguous: consider '( (a,(b|c)) & (a,(b|d)) )' after seeing 'ab...' > [earlier] > That means the whole ball of wax, to me. If I had to implement SGML's > ambiguity I'd implement and ambiguity check and match against the parse > tree for the model. If I'm parsing that way, what's a single bit of > additional state per moel token? As I say, I'm not emotional about kereping > &, just don't see why not. Since '&' groups are the only feature that makes the ambiguity restriction difficult to test for, and it's also the only feature (other than OMITTAG [1]) that makes the restriction desirable from the implementor's point of view, the logical conclusion would be to drop '&' groups. (Not that I am advocating that position -- I think XML should keep both '&' groups and the ambiguity restriction, but should not require validating parsers to check the latter.) [1] Final note: OMITTAG, in particular start-tag omission, *cannot work* unless content models are unambiguous and deterministic. This is because of the way "contextually require element" is defined in the standard. --Joe English jenglish@crl.com Date: Sat, 19 Oct 1996 13:17:15 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.9 Forbid & connector? At 9:51 AM 10/19/96, Joe English wrote: >You don't have to perform the check though, even in >a validating parser: > > "4.329 validating SGML parser: A conforming SGML parser > that can find and report a reportable markup error if > (and only if) one exists. > > 4.267 reportable markup error: A failure of a document > to conform to this International Standard [...] other > than a semantic error [...] or: > a) an ambiguous content model > b) [...]" > > [ 9.3, "Conforming Systems", p. 215] > >In other words, 8879 (for better or worse) places the >burden of ensuring non-ambiguity on the DTD designer, >not the parser. I don't think we should emulate the policy of having errors that may break some parsers and documents, but are not reportable. >Also note that checking for ambiguity is straightforward -- >as long as there are no '&' groups. I agree. But it's not something you can look up in a book. >That only works if the content model is unambiguous: >consider '( (a,(b|c)) & (a,(b|d)) )' after seeing 'ab...' This seems to me to support removing the unambiguity distinction. >Since '&' groups are the only feature that makes the ambiguity >restriction difficult to test for, and it's also the only feature >(other than OMITTAG [1]) that makes the restriction desirable from >the implementor's point of view, the logical conclusion would >be to drop '&' groups. (Not that I am advocating that position -- >I think XML should keep both '&' groups and the ambiguity restriction, >but should not require validating parsers to check the latter.) > >[1] Final note: OMITTAG, in particular start-tag omission, >*cannot work* unless content models are unambiguous and deterministic. >This is because of the way "contextually require element" is defined in >the standard. More reason to drop unambiguity, as that feature died an unlamented death practically at the inception of the project. You have convinced me though, that both features should be dropped, & and unambiguity. We should take advantage of the slack allowed in the standard, and hope that SGML parser writers who care about XML will adapt. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Sat, 19 Oct 1996 13:17:22 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: Internationalization At 4:19 AM 10/19/96, Tim Bray wrote: >1. Non-network access > >[This is obvious] a lot of XML files are going to be stored in files >and accessed by means other than HTTP, and some encoding signalling >mechanism is obviously required. Also, we wanted something that was >simple, easy to explain, and could be done by anyone with whatever >editor they were using. ] MIME headers would meet this requirements, if they are allowed in the file. See my earlier posting for an elaboration of this proposal. >2. Distrust > >There is, on the ERB, a pervasive lack of trust in the reliability >of Mime and other external/metadata encoding signaling devices. This >is felt particularly intensely by me, based on my experience in processing >many millions of HTML pages for the Open Text Index, and by Michael >Sperberg-McQueen, based on his years of work in a highly heterogeneous >networked computing environment. I, and I'm sure many of the rest of us, >have enjoyed the beneficial effects of Mime technologies in recent years; >but if you're doing anything large-scale on the Web, if you rely on >external metadata/signalling in general, you're dead - or more formally, >your receiving application will suffer an unreasonable number of failures >due to various botches and bogosities. The reasons for this are, in my >experience, a combination of incompetence in website administrators and >lack of education in document authors. Personally, I think that with >a *combination* of mime, metadata, and careful examination of the first >few bytes of the file to see if any reasonable interpretation of the >bit patterns generates something like 'place for XML processors to offer more reliable access to heterogeneous >multilingual distributed data than anything else I'm aware of. We can make the metadata in the document supersede the data in the HTTP header, if that will improve reliability. Then people will stop using the internal headers for HTTP delivery, once they are no longer needed to make things work because of improved HTTP implementation and practice. >We're just specifying the language. Although the ERB hasn't voted on this, >it seems self-evident that a good XML processor should make use of whatever >information might be available external to the language [be it a resource >fork or an HTTP header or whatever] to do the right thing. I no longer trust in self-evidence. Let's make a (simple) rule. Good sense and character set issues never seem to go together. I'm sure people will implement naming conventions for XML file suffixes and the like, and we need not worry about that, but we're talking about data that is _essential_ for the document to be processed. That cannot be left to the implementers ingenuity. (They'll be far to ingenious for their own good!) Neither of these arguments will fly in the Web technical community, unless they can see that we are not tromping on the (sensible) infrastructure that is already defined. A brand new character set syntax and self-identification technique tromps, in my opinion. >Cheers, Tim Bray >tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Sat, 19 Oct 96 12:33:48 CDT From: Michael Sperberg-McQueen Subject: ERB decisions on A.17, B.9, and other questions To: W3C SGML Working Group The SGML ERB met today, Saturday Oct. 19th, and voted on several items already discussed by the SGML WG. Participating: Bosak, Clark, Kimber, Maler, Paoli, Sharpe, Sperberg-McQueen. Absent: Bray (represented in part by written votes on open issues), DeRose, Hollander, Magliery. All decisions were by consensus of all those participating in the call, and thus carry a majority of the membership of the ERB. I should note that the wording of the rationales given below reflects the understanding, and is the responsibility, of the author. The rationales have not been reviewed or approved by the ERB; they are thus subject to correction when I have misunderstood or misstated the ERB's intention. The ERB agreed on the following position statements: * We will maintain a list of topics to be addressed in future revisions of XML. * We will include some version of this list in the specification itself. The rationale for the list and for its inclusion in the specification is to allow some topics to be postponed until there is more time for their resolution, and to inform users of XML of the expected lines of development. In the light of these agreements, the ERB reconfirmed its earlier decision that XML 1.0 will not have SDATA entities. It is thought that most uses of SDATA entities are adequately served by character references to Unicode characters (see example below). Techniques for dealing with non-Unicode characters, specification of glyphs rather than characters, and related topics (such as possible mechanisms for document private agreements governing the ISO 10646 Private Use Areas) will be addressed in future revisions. Instead of a declaration like any XML processor can work properly with a declaration of the form On question A.17 (Should XML have entities or not?), the ERB had already decided that XML would have internal entities (either text or CDATA, not both). Today we decided further: * XML will have external NDATA entities. * XML will have internal text entities. The rationale for allowing internal text entities was this: CDATA entities are very easy to implement (because they need not be expanded at parse time, but can be expanded later without changing the structure of the parse tree); text entities are more complex (if they are synchronous, they may require the replacement of a leaf node with an arbitrarily complex subtree; if they are asynchronous, they *must* be expanded at parse time and complicate the parser). Nevertheless, internal text entities are so useful to the user that they justify the cost of implementation. Whether XML will have external text entities remains an open question. On question B.9, the ERB decided: * In version 1.0, XML will not have public identifiers, only system identifiers. * In version 1.0, system identifiers will be URLs. * In version 1.0, URLs need not carry the FSI-style label. Whether system identifiers in XML 1.0 will be *allowed* to carry the label remains an open question. Addition of public identifiers and extension of system identifiers to other formats will be taken up in preparation of future versions of XML. The rationale for these decisions was that URLs are well understood and well established, and can handle both remote and local addresses. Restricting external identifiers to URLs helps keep the specification simple. In the long run, however, public identifiers are desired by many users and may provide solutions to the well known fragility problems associated with URLs. Better infrastructure, in the form of catalog management tools and http-based catalog resolution services, would help make the introduction of public identifiers into XML smoother. -C. M. Sperberg-McQueen Date: Sat, 19 Oct 1996 12:54:01 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: C.4 Undeclared entities? [CDATA #REQUIRED?] Cc: w3c-sgml-wg@w3.org At 2:25 AM 10/19/96, Harvey Bingham wrote: >>So there is always a DTD. Now the question is: what does a parser do with >>references to undeclared entities? There is no reason to do anything different >>from what is done in SGML. >> >An undeclared entity could be passed on to the application, and possibly >retained as such when part of #PCDATA. I think Harvey has this exactly right. Making this unbound entities visible to the application, taken together with the synchrounous markup restriction, means that parsing document fragments becomes trivially similar to parsing a document without a DTD; the only difference is the possiblity that the entity might not be a single element. This lets us solve several problems at once, in a pretty clean general way. And certainlty, at least for external entities, we will need to let an application control when and whether they are resolved. Imagine a browser where you couln't stop it from going out to the net for embedded files. >>As for declaring entities automatically, I assume that means there will be a >>piece of public text containing the "automatic" declarations that is >>considered >>to be referenced by all DTDs (including the implied one). Or, to put it >>another >>way, all DTDs are partial; the "automatic" entity declarations are the other >>part. > >That "automatic" set of entity declarations is open-ended, effectively any >apparent entity should be in it. > >Regards/Harvey Bingham Not true. Some names will be predeclared to have fixed meanings, rather than representing "free variables." Any entity currently in the HTML declaration should be automatically declared with its current value. We may also need entities for hexadecimal character codes, if Gavin's function character proposal does not fly. These are essentially hard requirements for acceptance. People get these "features" for free to day, telling them that they have to add declarations for the obvious and useful will, fail the "Stooopid" test. The user-hostility of requiring a new convention for character references that is different form the stadard reference material, and requires a numberical base conversion ought to be evident on the face of it. -- David RE delenda est. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Sat, 19 Oct 1996 15:01:39 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: ERB decisions on A.17, B.9, and other questions I'mna afraid most of my reactions to the following are rather flamish. Apologies, but no regrets for that fact. At 12:33 PM 10/19/96, Michael Sperberg-McQueen wrote: > >The ERB agreed on the following position statements: > > * We will maintain a list of topics to be addressed in > future revisions of XML. > * We will include some version of this list in the specification > itself. >In the light of these agreements, the ERB reconfirmed its earlier >decision that XML 1.0 will not have SDATA entities. It is thought that >most uses of SDATA entities are adequately served by character >references to Unicode characters (see example below). Techniques for >dealing with non-Unicode characters, specification of glyphs rather than >characters, and related topics (such as possible mechanisms for document >private agreements governing the ISO 10646 Private Use Areas) will be >addressed in future revisions. > >Instead of a declaration like > > How do I declare a character like "TENGWAR VOWEL LETTER A" or "ME GLYPH GARDINER 201" (Middle Egyptain). It's just 宊 or something. My gut reaction to that is #$*#&$#?! > >any XML processor can work properly with a declaration of the form > > These declarations must be included automatically, if we hope to have anyone _use_ XML. (Which does not seem to be a major concern, as far as I can tell). >On question B.9, the ERB decided: > > * In version 1.0, XML will not have public identifiers, only > system identifiers. > * In version 1.0, system identifiers will be URLs. > * In version 1.0, URLs need not carry the FSI-style label. > >Whether system identifiers in XML 1.0 will be *allowed* to carry the > label remains an open question. > >Addition of public identifiers and extension of system identifiers >to other formats will be taken up in preparation of future versions >of XML. > >The rationale for these decisions was that URLs are well understood >and well established, and can handle both remote and local addresses. >Restricting external identifiers to URLs helps keep the specification >simple. In the long run, however, public identifiers are desired by >many users and may provide solutions to the well known fragility >problems associated with URLs. Better infrastructure, in the form >of catalog management tools and http-based catalog resolution >services, would help make the introduction of public identifiers into >XML smoother. We should specify and reserve the syntax for Public Identifiers now. It's not like we don't know what they will be. We should certainly _accept_ the prefix, so that those of us who are interested in doing things right will be able to. Come on, test URN deployments are already taking place -- must we repeat the mistakes of the past HTML's location-only syntax has already set the world back 10 years by spreading a bad model into millions of minds, just as SGML has failed to move the world forward 20 years, by cloaking good ideas in crappy syntax. I'd like that the end of this process will be something that can be endorsed instead of inveighed against. I'm starting to worry. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Sat, 19 Oct 96 14:56:12 CDT From: Michael Sperberg-McQueen Subject: Re: ERB decisions on A.17, B.9, and other questions To: W3C SGML Working Group cc: David Durand On Sat, 19 Oct 1996 15:15:27 -0400 David G. Durand said: >>Instead of a declaration like >> >> > >How do I declare a character like "TENGWAR VOWEL LETTER A" or "ME >GLYPH GARDINER 201" (Middle Egyptian). It's just 宊 or >something. > >My gut reaction to that is #$*#&$#?! I'm not sure what you're arguing here. Would be (a) equally likely to be understood by all XML processors and (b) materially less likely to elicit the reaction &expletive;? If the ERB decides question C.5 the way I hope we will, then we can at least say which I, for one, prefer, since I don't have to be logged on to a system with a shell-level hex-to-decimal calculator, and it's easier to proofread the declarations against Unicode documentation. (But to be honest I suspect that a.teng belongs at 57344 (U+E000) or thereabouts in the Private Use Area.) >>any XML processor can work properly with a declaration of the form >> >> > >These declarations must be included automatically, if we hope to have >anyone _use_ XML. (Which does not seem to be a major concern, as far as I >can tell). Come on, now. The question of including some entities automatically is on the table, and has been addressed by several postings, most in favor, as far as I can remember. The proposals I've heard so far are (a) just lt, gt, and amp (possibly augmented by declarations for ' and "), (b) the above plus ISOLat1, and (c) everything in HTML (which version?). If you are hoping for automatic inclusion of Tengwar and other similar scripts, I predict disappointment. Or even Middle Egyptian, for that matter. If you think we should decide to include them automatically without worrying about the form of their declaration, then I respectfully but vigorously disagree. On the whole, I don't see how retaining or excising SDATA has any effect on the ease or difficulty of declaring things like TENGWAR VOWEL A and ME GLYPH GARDINER 201 in useful ways. And so I don't see how these examples bear upon the decision to do without SDATA in version 1.0 of XML. > I'd like that the end of this process will be something that can be >endorsed instead of inveighed against. I'm starting to worry. The further XML takes us toward the Promised Land, the better. But I hope it will be endorsed for bringing us closer to it, rather than inveighed against simply because it doesn't airdrop us down in the middle of it. Those who first approached the Promised Land, let us remember, did so at the pace of the slowest animal or child in the caravan. Some of us would like to go faster, or farther. Some would like to go slower, and not so far. Whatever speed we go, whatever distance, will be right for some and uncomfortable for others. Whatever decisions we make, some of us will be unhappy. But we won't get to the Promised Land by breaking up the caravan. The right speed is the one that keeps us moving together, and more or less in line. (Hint to those lagging behind: some people want to go faster. Hurry up, OK? Hint to those way out in front: some people's feet hurt. Cool yo' jets!) -C. M. Sperberg-McQueen Date: Sat, 19 Oct 1996 17:55:12 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: ERB decisions on A.17, B.9, and other questions At 2:56 PM 10/19/96, Michael Sperberg-McQueen wrote: >On Sat, 19 Oct 1996 15:15:27 -0400 David G. Durand said: >>>Instead of a declaration like >>> >>> >> >>How do I declare a character like "TENGWAR VOWEL LETTER A" or "ME >>GLYPH GARDINER 201" (Middle Egyptian). It's just 宊 or >>something. >> >>My gut reaction to that is #$*#&$#?! > >I'm not sure what you're arguing here. Would > > > > > >be (a) equally likely to be understood by all XML processors and (b) >materially less likely to elicit the reaction &expletive;? Yes, because I can be told, by the application, that "An unknown character was found in the data stream, here's its name." Otherwise, I get the information from the application: "An unknown character was found, here's its number (in an officially undefined section of unicode)". In one case, the name may help me to understand the reference, or at least give me a starting point for research, in the other, I have no further recourse. >If the ERB decides question C.5 the way I hope we will, then we can >at least say > > > Something like this is essential, but it addresses a different problem. The problem with the above is that hiding critical information in comments is not a good prescription for portability. >which I, for one, prefer, since I don't have to be logged on to a >system with a shell-level hex-to-decimal calculator, and it's >easier to proofread the declarations against Unicode documentation. > >(But to be honest I suspect that a.teng belongs at 57344 (U+E000) or >thereabouts in the Private Use Area.) (Sure, I just made the number up by hitting my numeric keypad) That sure doesn't help. U+E000 is almost, but not quite, utterly uninformative. Tengwar vowel mark A, may help a human, ig not an application. > >Come on, now. The question of including some entities automatically >is on the table, and has been addressed by several postings, most in >favor, as far as I can remember. The proposals I've heard so far are >(a) just lt, gt, and amp (possibly augmented by declarations for ' and >"), (b) the above plus ISOLat1, and (c) everything in HTML (which >version?). If you are hoping for automatic inclusion of Tengwar and >other similar scripts, I predict disappointment. Or even Middle >Egyptian, for that matter. If you think we should decide to include >them automatically without worrying about the form of their declaration, >then I respectfully but vigorously disagree. No, my point was that the set of possible character references is an open set, and that numbers are never preferable to names, absent a well-defined place to look up the number. (Private use does not solve that problem, since all I can do is look it up and be told that it's officially undefined.) Hey, I can point you to a unicode definition of where TENGWAR LETTER A might appear in the private use set. But even if I knew nothing of unicode that description is a lot more useful than any arbitrary code value. If we applied the proposed SDATA removal policy to programming languages we could replace annoying variable names with convenient numbers, and improve the bandwidth of programmers. If we have unique labels for things, why bother to make them meaningful? >On the whole, I don't see how retaining or excising SDATA has any >effect on the ease or difficulty of declaring things like TENGWAR >VOWEL A and ME GLYPH GARDINER 201 in useful ways. And so I don't >see how these examples bear upon the decision to do without SDATA >in version 1.0 of XML. A comment that the parser strips that tells me the name of a character is measurably less useful that an application available string containing the same information. And a lot more For instance, I might put URLs of .gif renditions of characters in my SDATA entities, instead of character names. I don't think that we should standardize the meaning of SDATA strings, but that we need the hook to attach meaningful data to undefined refrences. For instance, many of the less-common Asian characters might have meaningful string that could document the ideogram, even for someone who only has a JIS font. > extended metaphor about the promised land deleted... This is all very well but we do have to get to the promised land. I don't want to end up like the Red 'Lectroids in Buckaroo Banzai, whose triumphal return home was terminated with the words: "We are not in the eighth dimension. We are over New Jersey." If we could at least make it to Seattle, I'd be happier. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html From: lee@sq.com Date: Sat, 19 Oct 96 18:29:59 EDT To: dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results > So, I suggest that we have the following problems: > > STEP 1: determine number of bytes in a character code (bit-combination). [...] > > (STEP 1'): Or we can use the FFFE hack, if that will have wider support. Probably, since it is explicitly suggested by Unicode. Whether you call it a hack or not depends on how you feel abut it, I think :-) > STEP 2: now we have a standard MIME-header, encoded in Latin1, using the > byte coding as determined in step 1 (i.e., 1-byte, big-endian, or > little-endian). Not yet. We have looked at the first two bytes of the file and determined whether they are using the Unicode/10646 EFFF/FFFE option. We have yet to determine (1) that the files are in XML at all and not HTML or SGML or GENCODE... (2) if they are in XML, what version of XML do they use? with talk of an XML 2.0, this is important. > We will define the fields that we _require_ (charset, only, > I hope). We will ignore, but permit, others. The CRLFCRLF sequence that > terminates the header will start the XML instance. This header will be > optional for channels (like HTTP) where the header information can be > preserved, and required for all others. OK, I see now. You are suggesting that we put a MIME header in the document in all cases. I think this is an excellent suggestion. Note that many existing web servers (including Apache) cope with files containing MIME headers, and may even emit those headers in response to an HTPP HEAD request. Apache is said (independently) to represent over 30% of all running web servers. > If we go further, we could eliminate STEP 1, > and parser the header in 8-bit mode always. Then people can use their > standard codebase to parse the headers, but 2-byte systems might show the > header as garbage It's always a little tricky to talk about mixing character sets within a single file. However, since MIME headers are in US ASCII (or is Latin 1 allowed now?), the headers must be in the subset common to both. As long a you don't include people's names, filenames, document titles or other displayable information in the MIME header in an XML file, though, I don't imagine it would be a problem. James? Gavin? Martin? At a minimum, you would need Mime-version: 1.0 Content-type: text/x-xml;version=1.0;charset=utf-8? If we get text/xml registered as MIME content type, it can be text/xml instead of text/x-xml, which would be good (I assume the leading x is OK!). Instead of requiring the full MIME CR-LF at the end of each line (which is a pain to mantain on some platforms, e.g. Mac and Unix), I would suggest documenting a format in which * The lines are terminated by either NL or CR * Lines longer than 72 characters may be continued by starting the next line with spaces or tabs (HT) (as per RFC 822) * The header is terminated by CR LF CR LF CR CR or LF LF i.e. you must have two of the same kind. You then get a header format which can easily and reliably be edited on multiple platforms -- e.g. you can upload a file from your PC to a Unix, NT or Mac server, and make a quick change in Notepad, Sam, or whatever, without trashing the file header. Of course, the editor has to be able to write out the body of the file correctly! (note that ftp in text mode will silently transform line endings into the format preferred on the destination platform, RS/RE rules notwithstanding; when you receive a file of format text/plain (e.g. 'cos the web server isn't set up to recognise some content type or other), the same transformation is made, which is why images don't transfer correctly if they have odd filenmes or are in new formats the server doesn't grok; it would be useful if XML were robust against such things as much as possible) Lee From: lee@sq.com Date: Sat, 19 Oct 96 18:44:37 EDT To: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions > In the light of these agreements, the ERB reconfirmed its earlier > decision that XML 1.0 will not have SDATA entities. It is thought that > most uses of SDATA entities are adequately served by character > references to Unicode characters (see example below). Techniques for > dealing with non-Unicode characters, specification of glyphs rather than > characters, and related topics (such as possible mechanisms for document > private agreements governing the ISO 10646 Private Use Areas) will be > addressed in future revisions. Sorry to quote all that... If I want to put my transcription of bits of Bailey's 18th C. dictionary on the web (actually it's already there in fairly grotty SGML), I will want to refer to some glyphs not in unicode. Would I do and hope that a style sheet could map this to (say) the font Adobe Caslon Alternates, using an embedded OpenType font? HTML will let me do this next year, using MSIE or Netscape, according to the respective vendors. There are many other characters not (or not yet) in 10646 or Unicode, some of which can be handled by floating diacriticals -- e.g. see http://www.portal.ca/~tiro/ for an analysis of character sets required for current, modern languages. There are others that are incorrectly identified in Unicode (it was made by humans...). In the case where no glyph exists on the targent system, I obviously want something mnemonic to appear -- I can live with [tall-s] or [r-cedilla-acute] but not with � or the equivalent � (ISO 10646 user space character numbers are all that long, right?) As long as a mnemonic string is used, I don't care whether it is called SDATA or PRISCILLA.... :-) Lee From: lee@sq.com Date: Sat, 19 Oct 96 19:07:31 EDT To: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions Cc: DGD@cs.bu.edu > Would > > > > > be (a) equally likely to be understood by all XML processors and (b) > materially less likely to elicit the reaction &expletive;? For me, only the 2nd of these makes any sense at all. > If the ERB decides question C.5 the way I hope we will, then we can > at least say > > Please let's not require the use of "significant comments". If the parser can't throw away comments, they are not comments. There are several pieces of information that one needs to know about a glyph, at various times. One could write a little document about it: The pre-defined standard ISO10646 code point, if one exists A suggested typeface to use for rendering the symbol (e.g. Lucida Mathematics Bold Extensions 13) The name or position within that face (e.g. LeftBraceExtender, or 0xF7) A human-readable description of the glyph, for the purposes of * people editing documents referring toit * editing software (the Insert Elephant menu) How to sort the glyph (unless it is forbidden to use XML for telephone directories, dictionaries, indexes, bibliographies...) Some glyphs are made up by overstriking or composing several others, in which case (as a minumum) it must be possible to say 1. sequence: use this glyph followed by this glyph 2. overstrike: use this glyph and this glyph Optionally, one could choose to represent piles: 3. verticality: use this glyph over this glyph This lets you build up diacriticals, e.g. for mathematical discourse, but is not essential. (in maths, "a acute bar" is an a with an acute accent and then with a macron accent or bar placed above the acute accent. The bar must be moved up to avoid overstriking the acute accent. This sort of positioning is also needed for Ancient Greek and Hebrew, for example, neither of which I consider to be very obscure...) If only we had a language for representing such short documents. Note that few applications use all of this information; it does not add significant complexity, but it _does_ add significant value. See reference [1] for some further discussion of these issues (Michael, Lou, I know you're familiar with this already). Neither Unicode nor ISO10646 removes the need for user-defined glyphs. They enable one to insert glyphs into the encoding, just as today on some systems I can put a meta-control-a in my file and hey, look!, on my screen it's an OE ligature. On yours it's a picture of Bill Gates, but who's to know? Again, I don't care about the word SDATA, but I do care about losing the representation of meaning. Would you be happy with ? It is bad enough that there is no standard place to put an element or entity description in SGML, so that we are faced with crypticisms like e4 or %m.pz.x; with no guidelines when we're building a style sheet. Lee Reference: [1] Harry Gaylord, _Character Representation_ in ``Text Encoding Initiative: Background and Context'', Ed. Nancy Id and Jean Véronis, Kluwer, 1995 From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Joe English Cc: W3C SGML Working Group Subject: Re: C.9 Forbid & connector? Date: Sat, 19 Oct 1996 23:42:52 GMT On Sat, 19 Oct 1996 09:51:31 -0700, Joe English wrote: >In other words, 8879 (for better or worse) places the >burden of ensuring non-ambiguity on the DTD designer, >not the parser. Not exactly. The standard just doesn't require ambiguity checking as a requirement of every validating parser. We expected that products would differentiate themselves in this (and other) respects, as indeed they have. But it is true that, with or without parser assistance, a document type can't have any ambiguous content models. (Even without start-tag omission, unambiguous content models are typically easier for a user to understand, and therefore to determine which element types are allowed at a given juncture.) -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: lee@sq.com Cc: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Date: Sat, 19 Oct 1996 23:42:50 GMT On Fri, 18 Oct 96 22:35:35 EDT, lee@sq.com wrote: >Charles Goldfarb argued: >> Questions like this are more easily analyzed if we avoid the confusing term >> "optional DTD". >> A missing DTD is really an implied DTD (like SGML's implied SGML >> Declaration) in which all element types have mixed content consisting of >> "(#pcdata | any element type)*" and all attributes are CDATA #REQUIRED >> (except for special conventions for ID, etc. that we might adopt). > >I am not sure where this comes from -- are you saying that this is the >current state of ISO8879, or that you would like to propose this for XML? I thought that was what was being proposed for XML. I'm not proposing it, just trying to put it in context. Sorry for the confusion. >> So there is always a DTD. Now the question is: what does a parser do with >> references to undeclared entities? >> There is no reason to do anything different >> from what is done in SGML. > >This is invidious, but fallacious, reasoning. >That there is always a DTD does not mean that there is always a >user-supplied DTD. > >If your implied DTD declares all the elements, it could also declare >all the entities just as easily. I guess you are right on that point, which to me shows the fallacy of implying a DTD. > >> As for declaring entities automatically, I assume that means there will be a >> piece of public text containing the "automatic" declarations that is >> considered to be referenced by all DTDs (including the implied one). > >It is sufficient to specify an algorithm by which such entities cn >be constructed. Unfortunately, not in 8879 as it exists today. WG8 has proposed something similar for character references in SGML97. >> Or, to put it another way, all DTDs are partial; the "automatic" >> entity declarations are the other part. > >I for one would find it helpful if you could mark proposals as that, >and statements of how ISO8879 works today as such -- I recognise >that this is a weakness in my understanding of SGML, but I didn't >understand ISO8879 as specifying anything about implied DTDs. It doesn't. I was trying to characterize what I thought was a proposal for XML (non-existent DTDs) in terms of SGML. >But you cannopt possibly be talking about XML, because no consensus has >been reached about implied or partial DTDs, so one cannot say of >XML that `all DTDs are partial'. I was referring to a proposal for XML which would have the effect of making all DTDs partial. >Or are you hoping we will accept your proposal as a fact and not >question it?? that can't be right, sorry. I'm missing something. As I said above, I was referring to a proposal made on this list. It is not my proposal. In fact, I don't like it at all, Lee. Your note has revealed even more problems with it. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: bosak@atlantic-83.eng.sun.com (Jon Bosak) Cc: w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com Subject: Re: C.4 Undeclared entities? Date: Sun, 20 Oct 1996 00:12:23 GMT On Fri, 18 Oct 1996 20:42:30 -0700, bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) wrote: >[Charles Goldfarb:] > >| Questions like this are more easily analyzed if we avoid the confusing >| term "optional DTD". A missing DTD is really an implied DTD (like >| SGML's implied SGML Declaration) in which all element types have mixed >| content consisting of "(#pcdata | any element type)*" and all >| attributes are CDATA #REQUIRED (except for special conventions for ID, >| etc. that we might adopt). > >There is no "implied DTD" of this nature in XML. Good. >It is possible for a well-formed XML document to be parsed in the >absence of a DTD. In such a case, the DTD does not maintain a >noumenal existence; it just really isn't there at all. Now you've got an implied DTD again. Here is the full set of SGML possibilities: 1. Full internal: A DTD for the type of document exists and all the declarations that define it are in the internal subset of the DOCTYPE declaration. 2. Full external: A DTD for the type of document exists and all the declarations that define it are in the external subset of the DOCTYPE declaration. That is, they are in an external SGML text entity that is automatically declared and is automatically referenced at the end of the DOCTYPE declaration (just before the MDC). 3. Partial internal: A DTD for the type of document exists. Some of the declarations that define it are in the external subset of the DOCTYPE declaration. That is, they are in an external SGML text entity that is automatically declared and is automatically referenced at the end of the DOCTYPE declaration (just before the MDC). The remainder of the declarations are in the internal subset of the DOCTYPE declaration. They are parsed before the external subset. In nature, a document is ALWAYS an instance of a document type, even if it is the only instance. SGML recognizes this fact and allows the DTD to be represented explicitly. (That is what makes SGML usefully different from word processors, because it permits rule-based processing.) Therefore, an XML document with no declarations in the internal subset, is really an example of case 2 (full external) in which the DTD has only one instance. Now, a DTD with only one instance is, quite literally, meaningless. That is, it can add no meaning that is not already determinable from the instance. So the notion is essentially fatuous as well. Postulating, as has been done on this list, that the "style sheet" will know what to do with unspecified attributes or references to undeclared entities JUST MEANS THAT THE DTD IS IN THE STYLE SHEET rather than in the standardized declarations used in SGML (and XML). I believe it would be useful (perhaps essential) for an XML document to be parsable without *reference* to its DTD, or with reference only to the internal subset, or both. But that is very different from saying that the DTD "just really isn't there at all". There is always a DTD, it is a law of nature. The issue is whether the DTD is represented by standardized declarations, or in a proprietary style sheet, or (as with HTML "extensions"), buried in the browser code. For XML, a standardized representation of DTDs is the only way to go. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com Subject: Re: C.4 Undeclared entities? Date: Sun, 20 Oct 1996 02:46:08 GMT *** This is a repost in which, for clarity, I've changed "one instance" to "one possible instance" . *** On Fri, 18 Oct 1996 20:42:30 -0700, bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) wrote: >[Charles Goldfarb:] > >| Questions like this are more easily analyzed if we avoid the confusing >| term "optional DTD". A missing DTD is really an implied DTD (like >| SGML's implied SGML Declaration) in which all element types have mixed >| content consisting of "(#pcdata | any element type)*" and all >| attributes are CDATA #REQUIRED (except for special conventions for ID, >| etc. that we might adopt). > >There is no "implied DTD" of this nature in XML. Good. >It is possible for a well-formed XML document to be parsed in the >absence of a DTD. In such a case, the DTD does not maintain a >noumenal existence; it just really isn't there at all. Now you've got an implied DTD again. Here is the full set of SGML possibilities: 1. Full internal: A DTD for the type of document exists and all the declarations that define it are in the internal subset of the DOCTYPE declaration. 2. Full external: A DTD for the type of document exists and all the declarations that define it are in the external subset of the DOCTYPE declaration. That is, they are in an external SGML text entity that is automatically declared and is automatically referenced at the end of the DOCTYPE declaration (just before the MDC). 3. Partial internal: A DTD for the type of document exists. Some of the declarations that define it are in the external subset of the DOCTYPE declaration. That is, they are in an external SGML text entity that is automatically declared and is automatically referenced at the end of the DOCTYPE declaration (just before the MDC). The remainder of the declarations are in the internal subset of the DOCTYPE declaration. They are parsed before the external subset. In nature, a document is ALWAYS an instance of a document type, even if it is the only possible instance. SGML recognizes this fact and allows a DTD to be represented explicitly. (That is what makes SGML usefully different from word processors, because it permits rule-based processing.) Therefore, an XML document with no declarations in the internal subset, is really an example of case 2 (full external) in which the DTD has only one possible instance. Now, a DTD with only one possible instance is, quite literally, meaningless. That is, it can add no meaning that is not already determinable from the instance. So the notion is essentially fatuous as well. Postulating, as has been done on this list, that the "style sheet" will know what to do with unspecified attributes or references to undeclared entities JUST MEANS THAT THE DTD IS IN THE STYLE SHEET rather than in the standardized declarations used in SGML (and XML). I believe it would be useful (perhaps essential) for an XML document to be parsable without *reference* to its DTD, or with reference only to the internal subset, or both. But that is very different from saying that the DTD "just really isn't there at all". There is always a DTD, it is a law of nature. The issue is whether the DTD is represented by standardized declarations, or in a proprietary style sheet, or (as with HTML "extensions"), buried in the application code. For XML, a standardized representation of DTDs is the only way to achieve our objectives. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- Date: Sat, 19 Oct 1996 22:14:49 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: Charles@sgmlsource.com CC: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? [Charles Goldfarb:] | In nature, a document is ALWAYS an instance of a document type | [...] | There is always a DTD, it is a law of nature. This assertion (upon which most of your argument seems to hinge) is so strange that I hardly know how to approach it. Documents do not exist in nature. They are human constructions. Whether they have a DTD or not depends on whether a human being has constructed one. If we substitute "C program" for "document" then your argument would be that every C program implies a DTD. There may be some very odd sense in which this is true, but that doesn't make an implied DTD part of the ANSI C language specification. It doesn't make it part of the XML specification, either. If what you are saying is that for every document, you can imagine a DTD to which that document conforms, then you are understating the case. For any document, one can imagine an infinite number of DTDs to which it conforms. You are free to imagine as many of these DTDs as you like. That still doesn't make any of them part of the XML specification. Even if we grant for purposes of argument that the infinite number of DTDs to which any document is conformant have some kind of existence (in the mind of God, say), their ontological status is equal; there is nothing to distinguish any one of this infinitude as more real than the rest of them. It may be that there is a practical purpose to be served by inventing the idea of an implied DTD and specifying rules whereby it is to be constructed from the document, but you can't make such a thing pop out of the void by saying that nature will provide it every time a document is created. Jon Date: Sun, 20 Oct 1996 02:57:23 -0400 To: W3C SGML Working Group From: Arjun Ray Subject: Caveat Tag Salad (Was: some ERB decisions) At 11:01 AM 10/17/96 CDT, Michael Sperberg-McQueen wrote: > >The SGML ERB met Wed. Oct 16th and voted on [...] > B.11 Should XML forbid, allow, or require empty end-tags (7.5)? > >Forbid. The DPH and "graceful recovery" arguments seem to have carried the day. Yet, I'd like to point out (at the risk of bothersome repetition) that the *real life* experience of HTML suggests that we ignore the possibility of tag salad at our peril. Requiring GIs in end-tags is not enough. Leaving "graceful recovery" to parser implementations is not enough. Not only should an unexpected endtag be a "reportable error" (assuming we have an adequate definition of this), but some normative statement (even if it's a non-binding "should") regarding the forms of error recovery would be the better part of wisdom. For instance: the error is not "unexpected endtag" but "endtag missing" (implying "forced" closure of open subelements.) Otherwise, given some fragment blah yada mumble it becomes easy for a parser implementor to give the user "what he wants": overlapping elements. The lesson, historically proven: Tag Salad is **EASY**. Simply assuming that it's "obvious" people will get their nesting right, when explicit labelling of endtags makes the error particularly *non*-obvious, is *very* unwise, IMHO. Arjun -- "Features whose purpose is to cause errors should be removed" -- Erik Naggum Date: Sun, 20 Oct 1996 10:06:53 +0000 To: lee@sq.com From: James Clark Subject: Re: ERB decisions on A.17, B.9, and other questions Cc: w3c-sgml-wg@w3.org At 18:44 19/10/96 EDT, lee@sq.com wrote: >> In the light of these agreements, the ERB reconfirmed its earlier >> decision that XML 1.0 will not have SDATA entities. It is thought that >> most uses of SDATA entities are adequately served by character >> references to Unicode characters (see example below). Techniques for >> dealing with non-Unicode characters, specification of glyphs rather than >> characters, and related topics (such as possible mechanisms for document >> private agreements governing the ISO 10646 Private Use Areas) will be >> addressed in future revisions. > >Sorry to quote all that... > >If I want to put my transcription of bits of Bailey's 18th C. dictionary >on the web (actually it's already there in fairly grotty SGML), I will >want to refer to some glyphs not in unicode. Let me reiterate: XML 1.0 is not addressing this problem. A future version of XML will address this problem. We haven't decided whether or not internal SDATA entities will be part of the solution. >Would I do > >and hope that a style sheet could map this to (say) the font >Adobe Caslon Alternates, using an embedded OpenType font? Typically, use of internal text entities wouldn't be apparent in the grove that style sheet works off. If I had to do this, I would use somthing like s' > if it's appropriate to regard the tail-s as an alternative presentation form of the letter s. If it's better to think of it as just a glyph, I might use something like ' > In either case I would also have a DSSSL style-sheet to specify the appropriate presentation of the element. James To: Michael Sperberg-McQueen , W3C SGML Working Group From: Martin Bryan Subject: Re: ERB decisions on A.17, B.9, and other questions Cc: David Durand Date: Sun, 20 Oct 1996 09:10:21 +0100 At 08:56 PM 19/10/96 +0100, Michael Sperberg-McQueen wrote: >>These declarations must be included automatically, if we hope to have >>anyone _use_ XML. (Which does not seem to be a major concern, as far as I >>can tell). > >Come on, now. The question of including some entities automatically >is on the table, and has been addressed by several postings, most in >favor, as far as I can remember. The proposals I've heard so far are >(a) just lt, gt, and amp (possibly augmented by declarations for ' and >"), (b) the above plus ISOLat1, and (c) everything in HTML (which >version?). If you are hoping for automatic inclusion of Tengwar and >other similar scripts, I predict disappointment. Or even Middle >Egyptian, for that matter. If you think we should decide to include >them automatically without worrying about the form of their declaration, >then I respectfully but vigorously disagree. I have one small problem here with the decision to drop FPIs. If we expect people to include their own sets a simple way of identifying well known sets of useful characters, such as the sets identified in 10646, would be useful. If we have to use system identifiers to do this then everyone is going to assign his own name to these sets. If we were able to use FPIs we could at least point people to a file containing FPIs for each of the sets in 10646 so that they could have a common starting point for including these standardized sets of useful characters. How do you envisage people identifying which character sets they have used as the basis for their numeric SDATA specifications? ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ To: W3C SGML Working Group Subject: Re: C.9 Forbid & connector? Date: Sun, 20 Oct 1996 05:42:18 -0700 From: Joe English David G. Durand wrote: > At 9:51 AM 10/19/96, Joe English wrote: > > I don't think we should emulate the policy of having errors that may break > some parsers and documents, but are not reportable. Agreed. There is another option though: XML could enforce a stricter -- and easier to implement -- ambiguity restriction than 8879. (Removing the restriction altogether would make XML incompatible with SGML, so that is not an option as I see it.) The main difficulty in testing content models with AND groups for ambiguity comes from (pathological?) cases like: ((foo & bar), foo), i.e., AND groups whose first- and follow- sets are not disjoint. If XML extends the notion of "ambiguity" to include these cases as well, then AND groups can be treated just like repeatable OR groups for purposes of detecting violations of the rule. (This might be a good idea in any case, based on the primary rationale behind the ambiguity restriction in the first place: "human beings must also perform context checking when creating the document, and they are more likely to do this successfully if the regular expressions are kept simple." [Annex H] I realize that many people disagree with this rationale, but keep in mind that those of us who understand the issue well enough to disagree with it are not the sort of human beings that Annex H is talking about in the first place.) > >Also note that checking for ambiguity is straightforward -- > >as long as there are no '&' groups. > > I agree. But it's not something you can look up in a book. So we put it in the XML spec. A formal definition of what isn't allowed should suffice, as long as the language is mathematical in nature (a la 10179) and not legalese (a la 8879). * * * > >That only works if the content model is unambiguous: > >consider '( (a,(b|c)) & (a,(b|d)) )' after seeing 'ab...' > > This seems to me to support removing the unambiguity distinction. I think you misunderstood. The algorithm you suggested for parsing AND groups -- set a flag after matching each subgroup -- only works for non-ambiguous content models. Otherwise you can't tell "which" subgroup was matched ("which" in quotes since the question is meaningless for general regular expressions). To me that suggests that the ambiguity restriction should be _retained_: it makes AND groups easier to handle. * * * > >[1] Final note: OMITTAG, in particular start-tag omission, > >*cannot work* unless content models are unambiguous and deterministic. > >This is because of the way "contextually require element" is defined in > >the standard. > > More reason to drop unambiguity, as that feature died an unlamented death > practically at the inception of the project. > > You have convinced me though, that both features should be dropped, & and > unambiguity. I really must work on my exposition then, since that's the exact opposite of what I had hoped to convince you :-) I think XML should keep '&' (since it's useful, despite being hard to implement); and it must keep the ambiguity restriction (for compatibility with 8879). OMITTAG means that 8879:199X will most likely not be able to allow ambiguity either, so XML can't even remove the restriction in anticipation of a revised standard. --Joe English jenglish@crl.com To: W3C SGML Working Group Subject: Re: C.10 Allow nondeterministic content models? Date: Sun, 20 Oct 1996 06:50:08 -0700 From: Joe English Tim Bray wrote: > At 11:46 AM 18/10/96 -0700, Joe English wrote: > > > >In fact, the ambiguity rule can make things *easier* for implementors.) > > Say what? The algorithms necessary to detect ambiguity are not typically > within the repertoire of the hypothetical CS bachelor's-degree type that > we'd like to be able to construct a validating parser. True: the ambiguity restriction makes it harder to validate DTDs. However, it can make it considerably easier to validate *instances*, if the parser is allowed to assume a DTD with no nondeterminstic content models (i.e., that the DTD has already been validated). How much easier depends on the algorithm you use, of course, but for many automata-based algorithms the savings are considerable. The "run it through perl and feed it to yacc" algorithm on the other hand does not benefit from the restriction at all (modulo potential exponential blowups in pathological cases); but I've never found this to be a particularly efficaceous way to process SGML... --Joe English jenglish@crl.com Date: Sun, 20 Oct 96 08:25:01 CDT From: Michael Sperberg-McQueen Subject: Re: ERB decisions on A.17, B.9, and other questions To: W3C SGML Working Group Both David Durand and Lee Quin seem to be interpreting SDATA entities as things which provide a system-independent specification of characters or glyphs, in particular full names of the character or glyph, in the style familiar from ISO character-set standards. Since I had understood SDATA to be intended to hold system-*de*pendent specifications (such as the elaborate escape sequence needed to produce a given glyph on some particular device or system -- say, an IBM ProPrinter or an HP LaserJet III, or ...), this notion confuses me. Can you point to any passages in 8879 that prescribe, or even allow, the usage you are foreseeing? Can you explain how the use of the SDATA keyword helps build a framework superior to what can be built without it? So far, the argument appears to be that providing the name of a character, without any information about its position in 10646 if any, or any information about an appropriate glyph in the AFII glyph registry if any, is superior to providing its position in 10646, with name etc. in a comment. In what way does the SDATA keyword affect this tradeoff? Lee provides a useful list of the kinds of information it's good to have about characters not known to the application a priori and says >If only we had a language for representing such short documents. We do have such a language, namely the TEI's Writing System Declaration, though it doesn't now include all of Lee's information items. (Sorting behavior is not a function of the glyph or character but of the language and application. So the TEI Writing System Declaration doesn't have an element for describing sorting behavior: it's not part of the writing system.) When we return to this topic in preparing future revisions, perhaps the TEI WSD can be considered as a mechanism for documenting and making out-of-band agreements for the private use area of 10646. For now, XML leaves this problem where we found it: private use areas, and privately created character sets or glyph sets, require private agreement out of band. If SDATA provided a readymade method of handling this problem, then I'd be happy to keep it. But it doesn't seem to me that it does. -C. M. Sperberg-McQueen Date: Sun, 20 Oct 1996 16:13:56 +0000 To: Joe English From: James Clark Subject: Re: C.10 Allow nondeterministic content models? Cc: W3C SGML Working Group At 06:50 20/10/96 -0700, Joe English wrote: > >Tim Bray wrote: > >> At 11:46 AM 18/10/96 -0700, Joe English wrote: >> > >> >In fact, the ambiguity rule can make things *easier* for implementors.) >> >> Say what? The algorithms necessary to detect ambiguity are not typically >> within the repertoire of the hypothetical CS bachelor's-degree type that >> we'd like to be able to construct a validating parser. > >True: the ambiguity restriction makes it harder to validate DTDs. If you don't have &-groups, detecting non-determinism (I think that's a much less confusing term than ambiguity) is pretty trivial. In fact it you use one obvious algorithm for checking instances, non-determinism checking can be done in, I would guess, less than 10 lines of code. The obvious algorithm I have in mind is a simplification of Algorithm 3.5 in the Dragon Book (p140 in my copy), which is the algorithm for constructing a DFA from a regexp. The simplification is that instead of the complicated final step where you do the subset construction, you simply read off the DFA directly >from the followpos() sets. While you're doing that, all you have to do to check non-determinism is to check each followpos set to see if it includes two distinct positions labeled with the same symbol (ie generic identifier). James From: lee@sq.com Date: Sun, 20 Oct 96 14:03:41 EDT To: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions > Both David Durand and Lee Quin seem to be interpreting SDATA > entities as things which provide a system-independent specification > of characters or glyphs, in particular full names of the character or > glyph, in the style familiar from ISO character-set standards. > > Since I had understood SDATA to be intended to hold system-*de*pendent I am actually not so interpreting SDATA entities, which is why I pointed to TEI WSDs and Harry Gaylord's article in my message. I care not one whit about SDATA, as I have said. What I do care about is retaining the ability to give a human-readable description of a character or glyph in such a way that an application can be expected to present it to the user, rather like the ALT attribute to an image in HTML. SDATA entities give you a way of doing that today -- if you like, you can do The ISO 10646 user space alone does not do that. James' suggestion of the form W'> is a good one and I could live with it, but would like it explicitly mentioned somewhere in the Famous Twenty Pages. James mentioned the use of DSSSL, but I have not been assuming that every XML implementation would be required to support DSSSL. If they are, I'm out of here right now. > When we return to this topic in preparing future revisions, perhaps > the TEI WSD can be considered as a mechanism for documenting and > making out-of-band agreements for the private use area of 10646. > For now, XML leaves this problem where we found it: private use > areas, and privately created character sets or glyph sets, require > private agreement out of band. If SDATA provided a readymade > method of handling this problem, then I'd be happy to keep it. But > it doesn't seem to me that it does. Again, I'm not arguing for keeping SDATA, but only for having a mnemonic string. The WSD would be a good way to do it, but I can live with James' hack if necessary. I gree with you that SDATA doesn't handle all of te problem either. Lee From: lee@sq.com Date: Sun, 20 Oct 96 13:56:01 EDT To: jenglish@crl.com, w3c-sgml-wg@w3.org Subject: Re: C.10 Allow nondeterministic content models? > The "run it through perl and feed it to yacc" algorithm on the > other hand does not benefit from the restriction at all (modulo > potential exponential blowups in pathological cases); but I've > never found this to be a particularly efficaceous way to process > SGML... That is _exactly_ what we have to fix in XML. XML must be amenable to bison and yacc, or similar tools. (in practice you'd have to use flex or otherwise avoid lex, I suspect, because of character set issues -- most implementations of lex are not fully 8-bit clean, in that they swallow NUL) The perl hacker's voice is loud. If & prevents that, drop &. If OMITTAG prevents that, drop OMITTAG (done already). Lee From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Arjun Ray Cc: W3C SGML Working Group Subject: Re: Caveat Tag Salad (Was: some ERB decisions) Date: Sun, 20 Oct 1996 18:30:39 GMT On Sun, 20 Oct 1996 02:57:23 -0400, Arjun Ray wrote: >At 11:01 AM 10/17/96 CDT, Michael Sperberg-McQueen wrote: >> >>The SGML ERB met Wed. Oct 16th and voted on >[...] >> B.11 Should XML forbid, allow, or require empty end-tags (7.5)? >> >>Forbid. > >The DPH and "graceful recovery" arguments seem to have carried the day. > >Yet, I'd like to point out (at the risk of bothersome repetition) that the >*real life* experience of HTML suggests that we ignore the possibility of >tag salad at our peril. >Simply assuming that it's "obvious" people will get their nesting right, >when explicit labelling of endtags makes the error particularly >*non*-obvious, is *very* unwise, IMHO. Arjun, Is it accurate to conclude from your argument that: 1) It would be best to have *only* empty end-tags as that would guarantee proper nesting in all cases (although not necessarily the nesting intended by the author). 2) If we allow (or require) named end-tags, we must also allow end-tags to be omitted when the named end-tag of a containing element occurs (at least as the required form of error recovery). -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: bosak@atlantic-83.eng.sun.com (Jon Bosak) Cc: w3c-sgml-wg@w3.org, lee@sq.com Subject: Re: C.4 Undeclared entities? Date: Sun, 20 Oct 1996 18:30:36 GMT On Sat, 19 Oct 1996 22:14:49 -0700, bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) wrote: >[Charles Goldfarb:] > >| In nature, a document is ALWAYS an instance of a document type >| [...] >| There is always a DTD, it is a law of nature. > >This assertion (upon which most of your argument seems to hinge) is so >strange that I hardly know how to approach it. > >Documents do not exist in nature. They are human constructions. >Whether they have a DTD or not depends on whether a human being >has constructed one. O.K. "In nature" *was* a bit poetic, but my assertion is still true. However, I should clarify that by "DTD" I mean the abstraction called a "document type definition", not SGML's declarations that describe the portion of a DTD that SGML knows how to deal with. (Most SGML practitioners use "DTD" to mean what I called the "external subset" in my posting.) In other words, every object is an instance of a class; therefore, every document is an instance of (at least one) class of documents, known as a "document type". A DTD is the description of the properties of members of that class. The foregoing statements are true even in the absence of SGML. SGML, however, provides a declaration syntax for making a portion of the DTD explicit and processable. >If we substitute "C program" for "document" then your argument would >be that every C program implies a DTD. There may be some very odd >sense in which this is true, but that doesn't make an implied DTD part >of the ANSI C language specification. It doesn't make it part of the >XML specification, either. Actually, the DTD for C programs is *explicit* in the ANSI C language specification -- it is the rules for a well-formed C program. To me, "C programs" is a particular document type (i.e., a particular class of documents) and "C program" is an instance of that type. >If what you are saying is that for every document, you can imagine a >DTD to which that document conforms, then you are understating the >case. For any document, one can imagine an infinite number of DTDs to >which it conforms. You are free to imagine as many of these DTDs as >you like. That still doesn't make any of them part of the XML >specification. That's true. I was referring to the DTD that most closely accounts for the particular instance. For want of a better term, let's call it the "maximally precise" DTD. For example, if an instance were:

data

data

The SGML representation of the maximally precise DTD would be: not The latter would be just one of an unbounded set of guesses, as you say. The former has the property that it describes this instance exactly, and no other. Note: I am aware that the SGML representation of the DTD allows the data to vary, but that is just a weakness in the current syntax. When lexical modeling is used, the maximally precise DTD could be represented as: >Even if we grant for purposes of argument that the infinite number of >DTDs to which any document is conformant have some kind of existence >(in the mind of God, say), their ontological status is equal; there is >nothing to distinguish any one of this infinitude as more real than >the rest of them. The maximally precise DTD is more real than the rest of them because it is the only one that can be justified. In the above example, we can't use p+ because there is no evidence that a "doc" exists with other than two "p"s in its content. >It may be that there is a practical purpose to be served by inventing >the idea of an implied DTD and specifying rules whereby it is to be >constructed from the document, but you can't make such a thing pop out >of the void by saying that nature will provide it every time a >document is created. My point is stronger than that, Jon. The maximally precise DTD is the one that pops out of the void. If XML wants something different, it had better spell out the rules for constructing it, rather than leaving it to the application or stylesheet or browser to do so. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- Date: Sun, 20 Oct 1996 15:18:56 -0400 (EDT) To: w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions From: John_Lavagnino@Brown.edu Michael writes: | Both David Durand and Lee Quin seem to be interpreting SDATA | entities as things which provide a system-independent specification | of characters or glyphs, in particular full names of the character or | glyph, in the style familiar from ISO character-set standards. | | Since I had understood SDATA to be intended to hold system-*de*pendent | specifications (such as the elaborate escape sequence needed to | produce a given glyph on some particular device or system -- say, an | IBM ProPrinter or an HP LaserJet III, or ...), this notion confuses | me. | | Can you point to any passages in 8879 that prescribe, or even allow, | the usage you are foreseeing? Surely there is no question that it is allowed. Just because one "normally" redefines SDATA for "different applications, systems, or output devices" (in the words of definition 4.304) doesn't mean you have to. (Are you suggesting that an SGML system should prohibit Unicode values as SDATA text, because they're not application-dependent enough?) And common practice (as has been previously noted on this list) is to treat the SDATA replacements printed in Appendix D as symbol names to be translated into escape sequences or whatever at a later stage. There are fewer reasons to do that today than there used to be: catalog files, for instance, make it much easier to change from one set of entity definitions to another in a standard way than was once the case. But I still feel, and apparently others do too, that it is highly desirable to keep system-dependent stuff even out of the DTD, and to convert some name into the system-dependent stuff. | Can you explain how the use of the SDATA keyword helps build a | framework superior to what can be built without it? So far, the | argument appears to be that providing the name of a character, | without any information about its position in 10646 if any, or any | information about an appropriate glyph in the AFII glyph registry if | any, is superior to providing its position in 10646, with name etc. | in a comment. | | In what way does the SDATA keyword affect this tradeoff? As Lee explained, you aren't necessarily talking about a character that exists in any kind of glyph registry anywhere. It's a fact of life that people invent new characters all the time; in this case, is it preferable to provide an essentially random number or something that can at least say what is desired? And if you are in a situation where you've got a list of standard numbers and standard names, as in 10646, why do you need both, and why is the number preferable? The SDATA keyword, in very common practice, means "This is a name for the character, a name that needs conversion for whatever output device you've got at hand." The prescribed effect (at least in the ESIS world) is to mark that name as distinct from ordinary document content. You can certainly live without that distinction if you don't mind unreliable hacks like saying "anything in square brackets is really a character name". I haven't seen a convincing response to Lee's comment: | Would you be happy with | | ? John Lavagnino Date: Sun, 20 Oct 96 15:41:22 CDT From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions > Date: Sat, 19 Oct 96 12:33:48 CDT > From: Michael Sperberg-McQueen > > On question B.9, the ERB decided: > > * In version 1.0, XML will not have public identifiers, only > system identifiers. > * In version 1.0, system identifiers will be URLs. > * In version 1.0, URLs need not carry the FSI-style label. > > Whether system identifiers in XML 1.0 will be *allowed* to carry the > label remains an open question. > > Addition of public identifiers and extension of system identifiers > to other formats will be taken up in preparation of future versions > of XML. > > The rationale for these decisions was that URLs are well understood > and well established, and can handle both remote and local addresses. > Restricting external identifiers to URLs helps keep the specification > simple. Pardon my ignorance about the details of URLs. What I'm wondering is, as defined above, does XML allow the use of simple local file names as external identifiers? Can I have declarations such as: given the ERB's decision on external identifiers? If not, and without public identifiers either, how would I make references to files on my local file system as typified by the above? (I realize if we decide not to have external text entities in XML, then the first example above would have to be an NDATA, but that's irrelevant to my question.) From: Charles@sgmlsource.com (Charles F. Goldfarb) To: paul@arbortext.com (Paul Grosso) Cc: w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions Date: Sun, 20 Oct 1996 22:00:05 GMT On Sun, 20 Oct 96 15:41:22 CDT, paul@arbortext.com (Paul Grosso) wrote: > > >(I realize if we decide >not to have external text entities in XML, then the first example above >would have to be an NDATA, but that's irrelevant to my question.) I realize that Paul was asking about URL syntax, but his last remark deserves remarking on. Adding "NDATA SGML" to the declaration makes it a data entity, even though it is in SGML notation. Data entities are not parsed in context, so if we don't allow external SGML text entities, "chapter.sgm" could not be a chapter in the element structure of the document containing this entity declaration. It would have to be an independently parsable document. (And "NDATA SGML" is an oxymoron; can't we have CDATA as well?) -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: John_Lavagnino@Brown.edu Cc: w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions Date: Sun, 20 Oct 1996 22:00:01 GMT On Sun, 20 Oct 1996 15:18:56 -0400 (EDT), John_Lavagnino@Brown.edu wrote: >The SDATA keyword, in very common practice, means "This is a name for >the character, a name that needs conversion for whatever output device >you've got at hand." The prescribed effect (at least in the ESIS >world) is to mark that name as distinct from ordinary document >content. You can certainly live without that distinction if you don't >mind unreliable hacks like saying "anything in square brackets is >really a character name". I'm not necessarily disagreeing with you, John, but I would like to point out that "[name]" doesn't have to be a hack. We could have an XML notation, declared formally for all element types with data content, in which "[name]" was *always* a character name. As long as the ESIS content is unchanged for all systems, there is no need for text to be declared to the parser as SDATA. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- Date: Sun, 20 Oct 1996 19:23:44 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: C.4 Undeclared entities? At 2:30 PM 10/20/96, Charles F. Goldfarb wrote: >O.K. "In nature" *was* a bit poetic, but my assertion is still true. However, I >should clarify that by "DTD" I mean the abstraction called a "document type >definition", not SGML's declarations that describe the portion of a DTD that >SGML knows how to deal with. (Most SGML practitioners use "DTD" to mean what I >called the "external subset" in my posting.) Your Platonic idealism is quaint, but the nominalists among us will disagree. At any rate, these (putative) philosophical entities _need_ not be addressed in the XML standard. >In other words, every object is an instance of a class; therefore, every >document is an instance of (at least one) class of documents, known as a >"document type". A DTD is the description of the properties of members of that >class. There is an infinite set of such classes. >That's true. I was referring to the DTD that most closely accounts for the >particular instance. For want of a better term, let's call it the "maximally >precise" DTD. For example, if an instance were: >example deleted... >The latter would be just one of an unbounded set of guesses, as you say. The >former has the property that it describes this instance exactly, and no other. To make a statement like this, you need to define a well-founded ordering on DTDs, with the property that any set of DTDs has one and only one least upper bound. You need to prove that these properties hold. Once you have, then you can talk about _the_ minimal DTD. This is not a case where handwaving will do. A book on denotational semantics of programming languages might clarify these issues. >The maximally precise DTD is more real than the rest of them because it is the >only one that can be justified. In the above example, we can't use p+ because >there is no evidence that a "doc" exists with other than two "p"s in its >content. First you have to prove that such an object exists. Pardon the philosophical note, but how else should one respond to syntaxt-definition discussions where the mind of God plays a significant role! -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Sun, 20 Oct 1996 18:43:33 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: ERB decisions on A.17, B.9, and other questions At 6:00 PM 10/20/96, Charles F. Goldfarb wrote: >On Sun, 20 Oct 1996 15:18:56 -0400 (EDT), John_Lavagnino@Brown.edu wrote: > >>The SDATA keyword, in very common practice, means "This is a name for >>the character, a name that needs conversion for whatever output device >>you've got at hand." The prescribed effect (at least in the ESIS >>world) is to mark that name as distinct from ordinary document >>content. You can certainly live without that distinction if you don't >>mind unreliable hacks like saying "anything in square brackets is >>really a character name". > >I'm not necessarily disagreeing with you, John, but I would like to point out >that "[name]" doesn't have to be a hack. We could have an XML notation, >declared >formally for all element types with data content, in which "[name]" was >*always* >a character name. As long as the ESIS content is unchanged for all systems, >there is no need for text to be declared to the parser as SDATA. Yes, but adding yet another special delimiter with a unique new syntax seems to be making things worse, and not better. Doing that introduces a new limitation (as square brackets now need to be escaped, and a whole new kind of error [undefined character code encountered]. We're better off with a new (pre-reserved) tagname, or even better, sticking with the tried and true SDATA solution. It's new to the HTML folx, but familiar to SGMLers and their parsers. -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Sun, 20 Oct 1996 18:43:27 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: ERB decisions on A.17, B.9, and other questions At 8:25 AM 10/20/96, Michael Sperberg-McQueen wrote: >Both David Durand and Lee Quin seem to be interpreting SDATA >entities as things which provide a system-independent specification >of characters or glyphs, in particular full names of the character or >glyph, in the style familiar from ISO character-set standards. > >Since I had understood SDATA to be intended to hold system-*de*pendent >specifications (such as the elaborate escape sequence needed to >produce a given glyph on some particular device or system -- say, an >IBM ProPrinter or an HP LaserJet III, or ...), this notion confuses >me. > >Can you point to any passages in 8879 that prescribe, or even allow, >the usage you are foreseeing. John Lavagino has already pointed out that it _is_ allowed. That's all I care about. Actually, I don't even care that much about that. What I _do_ care about is that this usage is _already implemented_, and is widely understood in the SGML community. I don't care about the original intent of the standard. This feature was used to meet a key need. That's good! There's no other way to do it in ESIS-based applications. Currently there is _no_ implementation of WSDs. They are a thing of beauty, but they solve too much for the Web audience. We should follow in the ways of our ancestors, and use strings. And the usage is sufficient for future expansion. If a miracle happens and people use XML, then we have at least an easy hook for referencing undefined characters. We could reserve all braketed SDATA sequences for future expansion, and later have then encode IDREFS into WSDs. James' method (as quoted by Lee; I don't remember seeing it), is rather heavyweight. Only someone committed to 8879 as a bible would see the point in defining an entity, to include a tag, to bracket a letter, just to include a reference to the XEROX logo. If we just want to create an empty undefined-glyph tag, and put the SDATA equivalent into an attribute, and then redefine #PCDATA to always include the glyph tag as part of the SGML content model, that is acceptable, though inventing something new seems irrational to me, when a serviceable, well-understood tool already exists. I am not a number, I am an non-standard character! >Can you explain how the use of the SDATA keyword helps build a >framework superior to what can be built without it? So far, the >argument appears to be that providing the name of a character, >without any information about its position in 10646 if any, or any >information about an appropriate glyph in the AFII glyph registry if >any, is superior to providing its position in 10646, with name etc. >in a comment. I am not a number, I am an non-standard character! >In what way does the SDATA keyword affect this tradeoff? I am not a number, I am an non-standard character! _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Sun, 20 Oct 1996 19:39:32 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: Caveat Tag Salad (Was: some ERB decisions) At 7:04 PM 10/20/96, Arjun Ray wrote: >Not necessarily, or rather, this is *not* an argument for OMITTAG. It's >actually a new kind of minimization (isn't SHORTTAG up for review >anyway?:-)), i.e. a named endtag is shorthand for all, er, contextually >required endtags and "expands" to the necessary number of anonymous endtags. >With this rule, error recovery doesn't apply at all! We old lisp hackers knew these as "super-parens". They never caught on, though. I don't feel strongly about this, though you have some good points. The major problem with empty end-tags is that they change people's habits from HTML, which is not a big win. It also makes implementing Emacs modes slightly less simple, I think. I must say that after experience with SGML minimization, even this small convenience makes me nervous. Given the nerves and the difference from existing practice, I have to throw in a _no_ vote on empty end tags. Anyway tag salad can be very satisfying if the chef is good! -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Sun, 20 Oct 1996 19:04:00 -0400 To: W3C SGML Working Group From: Arjun Ray Subject: Re: Caveat Tag Salad (Was: some ERB decisions) At 06:30 PM 10/20/96 GMT, Charles F. Goldfarb wrote: >On Sun, 20 Oct 1996 02:57:23 -0400, Arjun Ray wrote: > >>Yet, I'd like to point out (at the risk of bothersome repetition) that the >>*real life* experience of HTML suggests that we ignore the possibility of >>tag salad at our peril. > >>Simply assuming that it's "obvious" people will get their nesting right, >>when explicit labelling of endtags makes the error particularly >>*non*-obvious, is *very* unwise, IMHO. > >Arjun, > >Is it accurate to conclude from your argument that: > >1) It would be best to have *only* empty end-tags as that would guarantee proper >nesting in all cases (although not necessarily the nesting intended by the >author). Yes, that's been my preference all along (see #195 on this list, from Sept 15.) I have considerable sympathy for the DPH argument (having done quite a lot of such quick-and-dirty stuff myself), but it's based on a *historical* lack of tools, in turn attributable to SGML parsing packages being extremely non-trivial to develop. In the long run, reliance on the DPH's talents doesn't bode well for system robustness; nor does ease of ad-hacking strike me as a particularly meritorious design principle. In contrast, I have no sympathy for the "graceful recovery" argument, because "graceful" is in the eyes of the beholder, and if (or when) a particular form of gracefulness becomes popular, usage will converge to a de facto standard rather than what RTFM might say. I am not at all sanguine that such a de facto standard will be what seems "obvious" to people who think nesting is "obvious". Moreover, whatever form of error recovery does get implemented in a parser, I have yet to see an argument that explicitly named endtags actually make parsing algorithms easier. >2) If we allow (or require) named end-tags, we must also allow end-tags to be >omitted when the named end-tag of a containing element occurs (at least as the >required form of error recovery). Not necessarily, or rather, this is *not* an argument for OMITTAG. It's actually a new kind of minimization (isn't SHORTTAG up for review anyway?:-)), i.e. a named endtag is shorthand for all, er, contextually required endtags and "expands" to the necessary number of anonymous endtags. With this rule, error recovery doesn't apply at all! Arjun Date: Sun, 20 Oct 1996 19:08:08 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.10 Allow nondeterministic content models? At 12:13 PM 10/20/96, James Clark wrote: >If you don't have &-groups, detecting non-determinism (I think that's a much >less confusing term than ambiguity) is pretty trivial. In fact it you use >one obvious algorithm for checking instances, non-determinism checking can >be done in, I would guess, less than 10 lines of code. The obvious >algorithm I have in mind is a simplification of Algorithm 3.5 in the Dragon >Book (p140 in my copy), which is the algorithm for constructing a DFA from a >regexp. The simplification is that instead of the complicated final step >where you do the subset construction, you simply read off the DFA directly >from the followpos() sets. While you're doing that, all you have to do to >check non-determinism is to check each followpos set to see if it includes >two distinct positions labeled with the same symbol (ie generic identifier). > >James This is OK. But it still fails a few crucial tests for me. I've never seen a beginning DTD designer fail to create an ambiguous content model in their first 2 projects. And it takes some time to understand why this is an error, since everyone know the rules for regexps and thus that it _need not_ be an error. I am actually more symathetic to & groups than ambiguity because one is a pain (in several parts of the anatomy, including the neck), and the other is useful. So I'd rather XML admitted ambiguous models and broke SGML parsers (a minority of the users will have those, if we're successful), than retained an odd syntactic restriction that breaks users (and drives them away). What is the justification for unambiguity, independent of SGML compatibility? I don't see a very good one. That is the kind of justification we will have to offer the world at large, and be evaluated on. Asking that question of XML features pretty much determines my positions on a number of these seemingly minor issues. -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Sun, 20 Oct 1996 19:08:13 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: ERB decisions on A.17, B.9, and other questions At 2:03 PM 10/20/96, lee@sq.com wrote: >> Both David Durand and Lee Quin seem to be interpreting SDATA >> entities as things which provide a system-independent specification >> of characters or glyphs, in particular full names of the character or >> glyph, in the style familiar from ISO character-set standards. >> >> Since I had understood SDATA to be intended to hold system-*de*pendent > >I am actually not so interpreting SDATA entities, which is why I pointed >to TEI WSDs and Harry Gaylord's article in my message. Nor am I, exactly. I can put system independent data in my system dependent string, if I want. No harm, and much good results. The XML convention should be that SDATA (or whatever other mechanism we choose) information should be _preferably_ machine-processable, and _certainly_ human-meaningful. With an open set we can do little more. I agree that full WSDs would be nice, but I can live without that a lot easier than I can live with magic numbers. >I care not one whit about SDATA, as I have said. >What I do care about is retaining the ability to give a >human-readable description of a character or glyph in such >a way that an application can be expected to present it to the user, >rather like the ALT attribute to an image in HTML. Yes. Exactly. >SDATA entities give you a way of doing that today -- if you like, >you can do > >The ISO 10646 user space alone does not do that. Yes, exactly! >James' suggestion of the form >W'> >is a good one and I could live with it, but would like it explicitly >mentioned somewhere in the Famous Twenty Pages. If we go this route, it must not _require_ declarations in the DTD, though a user might prefer to create entoties to reference common "glyph tags". We need a built-in mechanism to solve this. We can reserve some syntactic form to accomodate ISO-standard WSDs or whatever in the next revision. >James mentioned the use of DSSSL, but I have not been assuming that >every XML implementation would be required to support DSSSL. >If they are, I'm out of here right now. A good point. We are going to have to specify (yechhhh!) how we (*shudder*) will attach cascading style sheets (^blarg^) to our XML documents. We may not ever get anything better in wide use. >> When we return to this topic in preparing future revisions, perhaps >> the TEI WSD can be considered as a mechanism for documenting and >> making out-of-band agreements for the private use area of 10646. >> For now, XML leaves this problem where we found it: private use >> areas, and privately created character sets or glyph sets, require >> private agreement out of band. If SDATA provided a readymade >> method of handling this problem, then I'd be happy to keep it. But >> it doesn't seem to me that it does. > >Again, I'm not arguing for keeping SDATA, but only for having a >mnemonic string. The WSD would be a good way to do it, but I >can live with James' hack if necessary. I gree with you that >SDATA doesn't handle all of te problem either. But it does solve an important part of the problem. >Lee -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Sun, 20 Oct 1996 20:59:49 -0400 To: W3C SGML Working Group From: Arjun Ray Subject: Re: Caveat Tag Salad (Was: some ERB decisions) At 07:39 PM 10/20/96 -0400, David G. Durand" (David G. Durand wrote: >I don't feel strongly about this, though you have some good points. The >major problem with empty end-tags is that they change people's habits from >HTML, which is not a big win. >From what I've seen, people's habits are strongly influenced by the software they work with. Even more so in environments where binaries without source code are the rule (the PC/Mac world.) Assuming the software is good enough, there's every reason to have some distinction from HTML. (Grandfathering HTML du jour should be the least of our concerns.) >It also makes implementing Emacs modes slightly less simple, I think. Would some other error recovery method (as a candidate for a rule) be simpler? >I must say that after experience with SGML minimization, even this small >convenience makes me nervous. Given the nerves and the difference from >existing practice, I have to throw in a _no_ vote on empty end tags. A datapoint from, er, existing practice. (http://home.netscape.com/comprod/products/navigator/version_3.0/layout/colu mns_spacing/index.html) = Font styles - The MULTICOL tag recognizes current font status. = So if you begin a bold section before the multicolumn, the text = in the columns will be bold, and if you close the bold in the = middle of the multicolumn, this nonbold status will continue = after the multicolumn ends. Arjun Date: Sun, 20 Oct 1996 19:40:38 -0700 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: C.4 Undeclared entities? The existence of an "induced" DTD when one is not provided has been a source of much lively discussion, on the WG, the ERB, and between XML's co-editors. There are two questions that are material in the context of non-provided DTD's: 1. Is there in fact an induced DTD which can be said to control or even affect the behavior of an XML processor? 2. Does such an induced DTD serve a useful didactic purpose in explaining the behavior of an XML processor.? The answer to #1 is clearly "no". Charles provided an example that exactly matched , but unless there have been some huge advances in tree simplification theory that I haven't heard about, deriving the minimal DTD [for any useful definition of minimal] for most nontrivial real-world documents proves in practice to be horribly difficult and not all that useful. Obviously, a DTD that declares all elements to be ANY and all attributes to be CDATA fills the bill, but it's hard to see how that controls or even affects the behavior of an XML processor. #2 is more arguable, but to a person who is still learning what a DTD is and means, the didactic value is probably negative; to a person who does understand, it's easier to explain well-formedness with assertions such as "There is a root element. Tags balance. EMPTYs are declared." The reason why this debate is worth having is practical: should the XML spec contain any discussion of induced DTD's, yes or no? I think not. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Sun, 20 Oct 1996 19:56:35 -0700 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: ERB decisions on A.17, B.9, and other questions At 07:08 PM 10/20/96 -0400, David G. Durand" (David G. Durand wrote: >RE delenda est. >I am not a number. I am an undefined character. His first concern is valid, since files come in lines, and since RE's are arguably one of SGML's stickiest tar-pits. His second concern is vastly overblown. Given the use of the 10646 repertoire, the population of characters that are needed but undefined falls dramatically - those that do appear are either a) so exotic that a bit of extra work in encoding them seems a minor concern, or b) really graphics in disguise, like for example a Xerox trademark. I have no problem acknowledging that XML may not make it particularly easy or natural to deal with characters outside of the hundred thousand or so that 10646 provides. Why is this problem important? [Not being sarcastic, I'd really like to get some input on this]. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Sun, 20 Oct 1996 20:09:22 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: C.4 Undeclared entities? [Charles Goldfarb:] | My point is stronger than that, Jon. The maximally precise DTD is the | one that pops out of the void. If XML wants something different, it | had better spell out the rules for constructing it, rather than | leaving it to the application or stylesheet or browser to do so. David Durand has already pointed out some problems inherent in this notion of "maximally precise". Until you provide a determinate mechanism for generating one and only one maximally precise DTD for an arbitrary instance, prove that the maximally precise DTD is unique for that instance, and prove that the procedure will always produce the maximally precise DTD from any instance, then I don't think that "maximally precise" really means anything. Beyond the formal problems, however, I cannot see any reason to introduce this concept into XML. The whole idea of XML is that any CS graduate can construct a parser for it from the BNF grammar set forth in the specification without knowing anything at all about SGML. This notion of a maximally precise DTD does not appear to me to aid such a person in performing this task. Jon Date: Sun, 20 Oct 1996 21:30:54 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: Caveat Tag Salad (Was: some ERB decisions) [Arjun Ray:] | A datapoint from, er, existing practice. | | (http://home.netscape.com/comprod/products/navigator/version_3.0/layout/colu | mns_spacing/index.html) | | = Font styles - The MULTICOL tag recognizes current font status. | = So if you begin a bold section before the multicolumn, the text | = in the columns will be bold, and if you close the bold in the | = middle of the multicolumn, this nonbold status will continue | = after the multicolumn ends. This Netscape abomination is not accepted by the W3C and has been explicitly condemned by Microsoft's Internet Explorer designers, who (it is now clear) will end up owning the browser. (See Netscape's latest news releases regarding their current browser strategy if you doubt that statement.) So going forward, this is not even standard HTML practice. Jon Date: Sun, 20 Oct 1996 21:39:47 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: ERB decisions on A.17, B.9, and other questions [David Durand, beginning with a quote from Lee Quin:] | >James mentioned the use of DSSSL, but I have not been assuming that | >every XML implementation would be required to support DSSSL. | >If they are, I'm out of here right now. | | A good point. We are going to have to specify (yechhhh!) how we (*shudder*) | will attach cascading style sheets (^blarg^) to our XML documents. We may | not ever get anything better in wide use. CSS is not on the XML agenda. There is no requirement that every XML application support stylesheets, but ones that do support stylesheets are expected to be using DSSSL for this purpose. See http://www.w3.org/pub/WWW/MarkUp/SGML/Activity where "public text and extensions needed to apply the DSSSL stylesheet language" is listed as the third phase of this activity, scheduled for completion in November 1997. Jon Date: Sun, 20 Oct 1996 22:34:51 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Batch C questions: now's the time The ongoing discussion of the questions from batch A and batch B already decided by the ERB is interesting and useful, but please don't forget that the ERB is going to be deciding Wednesday on the questions in batch C. If you wish to give input on those questions and haven't already, please do so as soon as possible. Jon From: lee@sq.com Date: Mon, 21 Oct 96 01:50:26 EDT To: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions > [...] There is no requirement that every XML application support > stylesheets, Thanks for the clarification. > but ones that do support stylesheets are expected to be > using DSSSL for this purpose. See > http://www.w3.org/pub/WWW/MarkUp/SGML/Activity > where "public text and extensions needed to apply the DSSSL stylesheet > language" is listed as the third phase of this activity [...] That the XML list is scheduled to discuss how to use DSSSL with XML does not in and of itself preclude the use of other style sheet or formatting mechanisms with XML, though. Which is not to say that I am suggesting that CSS be used particularly. Let's note that style sheets are optional (good!) and move on... :-) Lee Date: Sun, 20 Oct 1996 23:21:37 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: ERB decisions on A.17, B.9, and other questions [Lee Quin:] | That the XML list is scheduled to discuss how to use DSSSL with XML | does not in and of itself preclude the use of other style sheet | or formatting mechanisms with XML, though. Very true. CSS is so inadequate to the applications for which XML is designed, however, that it has explicitly been omitted from the activities for this group from the very beginning. I can imagine this group, in the interest of formal completeness, defining a method for associating stylesheets in any arbitrary notation with an XML document, but I can't at this time imagine that we will be spending any significant time on CSS in particular. Jon Date: Mon, 21 Oct 96 09:07:58 CDT From: Michael Sperberg-McQueen Subject: Re: ERB decisions on A.17, B.9, and other questions To: W3C SGML Working Group If I am reading the postings from David Durand, Lee Quin, and John Lavagnino correctly, it seems that my earlier note embodied a large misconception. I had asked for references to 8879 to explain the behavior they seem to be associating with SDATA entities; they seem, if I understand correctly, to be unanimous in saying that 8879 does not in fact define the desired behavior at all, but that it's widely implemented and well understood (and, I assume, should be incorporated into XML 1.0). So what seems to be at issue is *not* whether XML 1.0 should retain the SGML 'SDATA' keyword, but whether it should retain that keyword and prescribe some particular behavior for processors encountering it. Here's a confession that if this behavior is widely implemented, I haven't seen it in the software I use most frequently. Perhaps I just don't read the manuals carefully enough, but the only program that comes to mind as describing any behavior like this is Panorama, and its functionality (rendering correctly all the characters in the ISO entity sets for which the local system has font resources) can be done with character references to ISO 10646, since all the characters in the ISO entity sets are in 10646 (some glyphs representing ligatures are missing). As to the other proposition, that it is widely understood, I can only say that if it is widely understood, then surely someone can be found to describe the behavior on this list explicitly enough that the rest of us can also understand it. I for one do not understand the behavior, and would really like a description, preferably with reference to some documentation. -C. M. Sperberg-McQueen Date: Mon, 21 Oct 1996 11:08:24 -0400 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@w3.org Subject: Re: Internationalization >1. Non-network access > >[This is obvious] a lot of XML files are going to be stored in files >and accessed by means other than HTTP, and some encoding signalling >mechanism is obviously required. Also, we wanted something that was >simple, easy to explain, and could be done by anyone with whatever >editor they were using. That is still insufficient justification for the PI hack. You could have just as easily recommended the *.mim format. I am vehemently against *data* sniffing. If the PI is a header, say so, and then give it a different syntax. >networked computing environment. I, and I'm sure many of the rest of us, >have enjoyed the beneficial effects of Mime technologies in recent years; >but if you're doing anything large-scale on the Web, if you rely on >external metadata/signalling in general, you're dead - or more formally, >your receiving application will suffer an unreasonable number of failures >due to various botches and bogosities. The reasons for this are, in my >experience, a combination of incompetence in website administrators and >lack of education in document authors. I cannot see this as justification for the PI hack either. Broken software is just that: broken. I know, probably better than anyone on this entire list, what the exact dangers are with WWW content labelling mechanisms. I also know what the potential is for correctness, and how to overcome a lot of the bogosity/idiocy. I do not see the PI hack as a necessary part of this solution, though I agree with the overall *concept* of having a header (which is what it really is). I understand the problem you are trying to solve, and understand how your answer tries to solve it. I do not think that the problem gives sufficient justification for the answer proposed, though, and think that cleaner mechanisms, both semantically, and syntactically, and both preferrable, and likely to be widely used *irrespective* of XML adoption. Let's not repeat the idiocy here. Date: Mon, 21 Oct 1996 11:22:28 -0400 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu CC: w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results >STEP 2: now we have a standard MIME-header, encoded in Latin1, using the >byte coding as determined in step 1 (i.e., 1-byte, big-endian, or MIME headers are always ASCII. BTW. My preferred solution for local access (ie. access in a filesystem) is to use attributes in catalog entries or FPI's to indicate encoding information. Date: Mon, 21 Oct 1996 11:48:48 -0400 From: gtn@ebt.com (Gavin Nicol) To: U35395@UICVM.UIC.EDU CC: w3c-sgml-wg@w3.org, DGD@cs.bu.edu Subject: Re: ERB decisions on A.17, B.9, and other questions > Or perhaps: > Date: Mon, 21 Oct 1996 11:52:52 -0400 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu CC: w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions >No, my point was that the set of possible character references is an open >set, and that numbers are never preferable to names, absent a well-defined >place to look up the number. (Private use does not solve that problem, >since all I can do is look it up and be told that it's officially >undefined.) Hey, I can point you to a unicode definition of where TENGWAR >LETTER A might appear in the private use set. But even if I knew nothing of >unicode that description is a lot more useful than any arbitrary code >value. This is an important point: too many applications treat characters as numbers, instead of as characters. One of the most important properties of a character is it's name... Date: Mon, 21 Oct 1996 12:05:39 -0400 From: gtn@ebt.com (Gavin Nicol) To: lee@sq.com CC: dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results >OK, I see now. You are suggesting that we put a MIME header in the >document in all cases. I think this is an excellent suggestion. .... this is *precisely* what my *.mim file format (suggested to HTML-WG and also out in an expired RFC) *is*. >Note that many existing web servers (including Apache) cope with >files containing MIME headers, and may even emit those headers in >response to an HTPP HEAD request. Apache is said (independently) to >represent over 30% of all running web servers. Right, but the *.mim file format is different to Apache (or at least the last version I looked at) in that Apache sends the file *verbatim* and does not necessarily add missing headers... which means that the author must understand the entire set of required headers. The proposal I put forth only requires headers that will be overriding those generated by the server. As I noted before on this list, and also in HTML-WG, most software that will be dealing with the WWW will *already* have MIME header parsers built into them.... probably as a message stream module, so you can *reuse* that code for the local and distributed case. Again, I seem to be talking to myself. >It's always a little tricky to talk about mixing character sets within >a single file. However, since MIME headers are in US ASCII (or is >Latin 1 allowed now?), the headers must be in the subset common to >both. The headers are in US-ASCII, which is a nuisance of your file is UCS-2 (your editor would need to have MIME parsing capabilities built in), which is a boundary case, but an important one. This is one reason I prefer catalog or FSI based solutions. In most practical situations, this will not be an overly large concern though. >At a minimum, you would need > Mime-version: 1.0 > Content-type: text/x-xml;version=1.0;charset=utf-8? In the *.mim file format, the minimum you would need would be CRLF, and for non-ISO-8859-1 documents Content-type: text/x-xml;charset=shift-jis >Instead of requiring the full MIME CR-LF at the end of each line (which >is a pain to mantain on some platforms, e.g. Mac and Unix), I would >suggest documenting a format in which ... I would just reference the HTTP specs (though HTTP 1.1 is becoming more restrictive), though I could easily be convinced that strict MIME compatability be preserved. >You then get a header format which can easily and reliably be edited >on multiple platforms -- e.g. you can upload a file from your PC to >a Unix, NT or Mac server, and make a quick change in Notepad, Sam, or >whatever, without trashing the file header. Of course, the editor >has to be able to write out the body of the file correctly! The point I've tried to make before!!! The PI hack is a HACK. It is a header hiding under syntax that will confuse everyone, or at least cause people to assume that you could do something clever like: .... .... and we all know *that* is totally bogus. From: Anders Berglund Date: Mon, 21 Oct 96 12:01:24 EDT To: w3c-sgml-wg@w3.org Subject: SDATA entities Cc: alb@ebt-inc.ebt.com >-C. M. Sperberg-McQueen writes: > >If I am reading the postings from David Durand, Lee Quin, and John >Lavagnino correctly, it seems that my earlier note embodied a large >misconception. I had asked for references to 8879 to explain the >behavior they seem to be associating with SDATA entities; they >seem, if I understand correctly, to be unanimous in saying that >8879 does not in fact define the desired behavior at all, but that >it's widely implemented and well understood (and, I assume, should >be incorporated into XML 1.0). > >So what seems to be at issue is *not* whether XML 1.0 should retain >the SGML 'SDATA' keyword, but whether it should retain that keyword >and prescribe some particular behavior for processors encountering >it. > >Here's a confession that if this behavior is widely implemented, I >haven't seen it in the software I use most frequently. Perhaps I >just don't read the manuals carefully enough, but the only program >that comes to mind as describing any behavior like this is Panorama, >and its functionality (rendering correctly all the characters in the >ISO entity sets for which the local system has font resources) can >be done with character references to ISO 10646, since all the >characters in the ISO entity sets are in 10646 (some glyphs >representing ligatures are missing). This is unfortunately a totally incorrect statement. The ISO entity sets contain a LARGE number of entities for which there are NO CHARACTERS in 10646. The ISO entity sets for maths and science (currect versions in 9573-13 published in '92) have several hundred entities that are not in 10646. The current working draft of 9573-15 (entities for non-latin alphabets - which includes a number of sets for scholarly usage) has an entity repertoire where maybe half are in 10646. Revision of 10646 is progressing very slowly - ISO/IEC JTC1/SC18 requested the addition of the characters for maths and science from 9573-13 on both DIS 1 and 2 (4 years ago) and so far there is no sign of any addition. Some standards bodies have suggested creating a "competitor" standard in ECMA and then "fast-tracking" that as additions to 10646. Thus I belive that it is higlhly important that XML includes SDATA entities and in a way that is decoupled from 10646. Use of "private use" areas in 10646 I believe will lead to the same mess as eg IBM ended up with EBCDIC. At the recent SGML Asia Pacific conference it was very interesting to hear the complaints from "CJK" representatives on 10646. >As to the other proposition, that it is widely understood, I can >only say that if it is widely understood, then surely someone can be >found to describe the behavior on this list explicitly enough that >the rest of us can also understand it. I for one do not understand >the behavior, and would really like a description, preferably with >reference to some documentation. In DSSSL the following approach was taken, based on the observation that most applications/implementations use common NAMES for the SDATA entities (mainly those in the ISO entity sets) and either totally ignore the SDATA replacement text (eg FrameMaker SGML) or have some system specific syntax in the replacement text (eg DynaText) in the implementation specific files that use the common NAMES: - a DSSSL character is named and you have an infinitely large name space. A character is decoupled from the encoding BUT some specification shortcuts are possible for those characters that are in 10646 (especially useful for the character properties) - a coded input character (eg ISO 8859-x, ISO/IEC 10646, EBCDIC) is mapped to a DSSSL character - an SDATA entity is mapped to a DSSSL character, primarily based on the entity name (or on the replacement text for systems where the entity name is not available) - a DSSSL character is mapped to a glyph identifier This approach has the following advantages: - decoupling from the input character code - you may mix and match input encodings - decoupling from existing coding standards that are ALL inadequate - infinite character repertoire - very important for publishing and scholarly applications One should note that the DSSSL approach is "equivalent" to mapping an input character in a particular encoding to a particular glyph in a font. Anders Berglund Editor ISO/IEC 9573 Techniques for Using SGML where the (revised) ISO entity sets are included Member of the ISO/IEC JTC1/SC18/WG8 RG on DSSSL Date: Mon, 21 Oct 1996 12:00:53 -0700 (PDT) From: Bill Smith Subject: Re: C.4 Undeclared entities? To: w3c-sgml-wg@w3.org Charles Goldfarb wrote: > My point is stronger than that, Jon. The maximally precise DTD is the one that > pops out of the void. If XML wants something different, it had better spell out > the rules for constructing it, rather than leaving it to the application or > stylesheet or browser to do so. Actually, I would expect nothing to pop out of the void. In my opinion, DTDs *must* not required to process XML (version 1.0) documents. If we state the opposite, we're left with SGML and this discussion has been for naught. Worse, we could state that "the maximally precise DTD" is used. This introduces a level of ambiguity that even SGML has managed to avoid. We should as well. Date: Mon, 21 Oct 1996 12:11:18 -0500 From: Len Bullard To: Jon Bosak CC: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Jon Bosak wrote: > Beyond the formal problems, however, I cannot see any reason to > introduce this concept into XML. The whole idea of XML is that any CS > graduate can construct a parser for it from the BNF grammar set forth > in the specification without knowing anything at all about SGML. This > notion of a maximally precise DTD does not appear to me to aid such a > person in performing this task. I am missing the point of this debate. I understand the need for the mythical undergrad to construct a parser in a week with the Dragon book in one hand and the BNF grammar in the other (typing with his nose, I guess). 1. What exactly will the XML parser do? What is it's output? 2. Does this preclude the use of the DTD? Even in IADS and IDE/AS where we do not use the DTD anywhere in the rendering pipeline because we simplified the SGML requirements first, and the application parser is using stylesheet declarations, we still found in production, we needed SGMLS and a DTD for validation. As long as a DTD is not precluded and one can be required based on the user's needs and decisions by the user, XML can safely say it is "SGML without DTDs". I can tell you from real experience, experienced SGML users will snicker while the HTML users will go on using HTML oblivious to the whole debate. So DeadGreekPoets aside, what feature cannot be provided with XML and No DTD? len Date: Mon, 21 Oct 1996 16:00:12 -0400 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions >I have no problem acknowledging that XML may not make it particularly easy >or natural to deal with characters outside of the hundred thousand or so >that 10646 provides. > >Why is this problem important? [Not being sarcastic, I'd really like >to get some input on this]. Take a trip to Taiwan, get married, and then have a child. While you are there, study the ancient buddhist texts. You might then be on the path to enlightenment. Date: Mon, 21 Oct 1996 15:41:59 -0400 From: gtn@ebt.com (Gavin Nicol) To: lee@sq.com CC: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions >What I do care about is retaining the ability to give a >human-readable description of a character or glyph in such >a way that an application can be expected to present it to the user, >rather like the ALT attribute to an image in HTML. Yes, this is the key point. The neat little trick James shows is interesting, but does require that your DTD (if you have one) have such a beast (I guess you could add it as an inclusion). What we really want is a way of saying something about what the entity reference is (kind of attributes of the entity as it were) that you could use to switch on for special processing, and then some way of passing the extra information along. Date: Mon, 21 Oct 1996 17:34:04 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: ERB decisions on A.17, B.9, and other questions At 11:48 AM 10/21/96, Gavin Nicol wrote: >> > >Or perhaps: > >> Gavin omitted to mention that the nice thing about the function character solution is that SGML already folds the case, so we don't need to prescribe a case, whereas entity names are (and should remain) case sensitive. This would be a non-issue if we do the right thing and make things case sensitive (and define all keywords, etc. as lower case). But I expect that people are too used to their preferred case conventions for this to fly. -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Mon, 21 Oct 1996 18:33:48 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: B.1 and B.2 results At 12:05 PM 10/21/96, Gavin Nicol wrote: >>OK, I see now. You are suggesting that we put a MIME header in the >>document in all cases. I think this is an excellent suggestion. > >.... this is *precisely* what my *.mim file format (suggested to >HTML-WG and also out in an expired RFC) *is*. Well, my suggestion is that we put a MIME header when we can't transmit the MIME header information over the channel. We don't want to have to send 2 headers to be XML conformant when going over HTTP. >>Note that many existing web servers (including Apache) cope with >>files containing MIME headers, and may even emit those headers in >>response to an HTPP HEAD request. Apache is said (independently) to >>represent over 30% of all running web servers. > >Right, but the *.mim file format is different to Apache (or at least >the last version I looked at) in that Apache sends the file *verbatim* >and does not necessarily add missing headers... which means that the >author must understand the entire set of required headers. The >proposal I put forth only requires headers that will be overriding >those generated by the server. This would be essential for XML, as we don't want to force applications to maintain HTTP specific information like Content-length, et. al. >As I noted before on this list, and also in HTML-WG, most software >that will be dealing with the WWW will *already* have MIME header >parsers built into them.... probably as a message stream module, so >you can *reuse* that code for the local and distributed case. > >Again, I seem to be talking to myself. Well, perhaps to only a few people. >The headers are in US-ASCII, which is a nuisance of your file is UCS-2 >(your editor would need to have MIME parsing capabilities built in), >which is a boundary case, but an important one. This is one reason I >prefer catalog or FSI based solutions. In most practical situations, >this will not be an overly large concern though. I think we are better off defining our own convention for "self-indetifying files", as there is none in common use. If a common, robust, convention for metadata is implemented, then systems that implement it are entitled to the same slack (omission of redundant header) that we should afford HTTP. Given the facts of life with multibyte encoding, and the desire that files be maximally self-revealing, we should probably use the character-length determination hack I suggested, ratehr than put 8-bit characters at the front of multibyte files. >>At a minimum, you would need >> Mime-version: 1.0 >> Content-type: text/x-xml;version=1.0;charset=utf-8? > >In the *.mim file format, the minimum you would need would be CRLF, >and for non-ISO-8859-1 documents > > Content-type: text/x-xml;charset=shift-jis > >>Instead of requiring the full MIME CR-LF at the end of each line (which >>is a pain to mantain on some platforms, e.g. Mac and Unix), I would >>suggest documenting a format in which >... > >I would just reference the HTTP specs (though HTTP 1.1 is becoming >more restrictive), though I could easily be convinced that strict MIME >compatability be preserved. This is a minor issue. Implementations will implement the "all three conventions" version for a long time, as it's so easy, and implementations are so bad about linenends generally. > >The PI hack is a HACK. It is a header hiding under syntax that will >confuse everyone, or at least cause people to assume that you could do >something clever like: > > >.... > >.... > > >and we all know *that* is totally bogus. Because you can't parse the character set specification, without knowing what character set to parse in... This is the most infamous of the SGML declaration's problems with automatic processing: why revisit it on XML users? -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Mon, 21 Oct 1996 18:21:31 -0400 From: gtn@ebt.com (Gavin Nicol) To: alb@kirk.mit.edu CC: w3c-sgml-wg@w3.org, alb@ebt-inc.ebt.com Subject: Re: SDATA entities >to 10646. Thus I belive that it is higlhly important that XML >includes SDATA entities and in a way that is decoupled from 10646. >Use of "private use" areas in 10646 I believe will lead to the same >mess as eg IBM ended up with EBCDIC. Agreed. >At the recent SGML Asia Pacific conference it was very interesting to >hear the complaints from "CJK" representatives on 10646. If you feel it is negative now, imagine a few years ago. At least now I get a more positive feeling from Japanese factions that were rabidly against it a few years ago. Date: Mon, 21 Oct 1996 17:33:24 -0700 (PDT) From: Bill Smith Subject: Re: C.4 Undeclared entities? To: w3c-sgml-wg@w3.org Len Bullard wrote: > I am missing the point of this debate. I understand the need for > the mythical undergrad to construct a parser in a week with the > Dragon book in one hand and the BNF grammar in the other (typing > with his nose, I guess). It seems there is disagreement over whether a DTD (real or imagined) is required in order to process XML documents. From my perspective, we can not require DTDs in XML 1.0 and have any chance of acceptance. > 1. What exactly will the XML parser do? What is it's output? I'm more concerned with applications and how they are used - either by a machine or a human. > 2. Does this preclude the use of the DTD? Even in IADS and > IDE/AS where we do not use the DTD anywhere in the rendering > pipeline because we simplified the SGML requirements first, and > the application parser is using stylesheet declarations, we still > found in production, we needed SGMLS and a DTD for validation. Let the application (user) dictate whether a DTD is required. > As long as a DTD is not precluded and one can be required based > on the user's needs and decisions by the user, XML can safely say it is > "SGML without DTDs". I can tell you from real experience, > experienced SGML users will snicker while the HTML users > will go on using HTML oblivious to the whole debate. What occurs between consenting users is not my concern. However, requiring DTDs, especially from the void, is of concern to me. Let (some) "experienced SGML users" snicker. I for one will not because document structure and tag extensibility, whether enforced or not, are powerful concepts that will be understood if properly presented. HTML users may in fact be oblivious to this debate - that is their gain. However, they won't ignore the issue that HTML is not sufficient for their needs. Solutions to their problems will be found, and they will look far more like VisualBasic or JavaScript than any markup language we have devised. > So DeadGreekPoets aside, what feature cannot be provided with > XML and No DTD? Validation. Date: Mon, 21 Oct 1996 21:27:32 -0400 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu CC: w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results >Well, my suggestion is that we put a MIME header when we can't transmit the >MIME header information over the channel. We don't want to have to send 2 >headers to be XML conformant when going over HTTP. I have appended the text for the RFC. This is much what I propose in the section dicussing protocols other than HTTP. >maximally self-revealing, we should probably use the character-length >determination hack I suggested, ratehr than put 8-bit characters at the >front of multibyte files. Nope. I would prefer to always have US-ASCII headers. Date: Mon, 21 Oct 1996 22:16:00 -0400 From: gtn@ebt.com (Gavin Nicol) To: gtn@kirk.mit.edu CC: dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results here is the promised text.... --- INTERNET-DRAFT G. Nicol MIME Header Supplemented File Type EBT, Inc draft-nicol-mime-header-type-00.txt Expires in 6 months October 19, 1995 MIME Header Supplemented File Type Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract One of the problems encountered in serving documents over the WWW is the correct generation of the MIME fields required by the HTTP protocol, and in particular, generating the correct MIME type for body content. This memo defines a file format that can be used to aid in the correct generation of such fields, and how servers should interpret the file format. Use of this file format can also benefit other protocols such as FTP. 1. Introduction The HTTP protocol [1] requires a number of MIME fields to be sent to the client. Some of these fields specify per-file information that cannot be easily generated by HTTP servers from the information available in the file system of the host operating system. One good example is the MIME content type field, which not only specifies the content type of the message sent to the client, but also additional data such as the encoding of the character set used. For example, a typical specification might look like: Content-type: text/html for HTML files that use the ISO-8859-1 encoding. However, if the HTML file uses a different encoding, for example ISO-2022-JP, then the field should look like this: Content-type: text/html; charset=ISO-2022-JP However, most servers cannot readily generate the extra parameter from the information in the filesystem, and in fact do not, leading to many interoperability problems. As such, some method of supplementing the file system information is required. This memo outlines one such method. 2. Current practise To date, various means have been used to supply such additional information. Some of the current methods of supplying additional data to the server are: The tag. The HTML 2.0 DTD [2] specifies a tag with an HTTP-EQUIV attribute that can be used to specify HTTP response field content. To date this has not been widely adopted by servers, mainly because it requires parsing the HTML in order to get the field values. This method is also flawed in that one cannot parse the HTML file without first knowing the coded character set and encoding used, so for certain field types (the Content-Type field as shown above, for example), it is either impossible to use, or redundant. The ASIS file type. The Apache server [2] specifies a special file type called ASIS. ASIS (for as-is) files are sent directly to the client, and are expected to contain all the fields required by the HTTP protocol. Specifying all fields can be somewhat cumbersome, and error-prone. External file information databases. Various servers implement a system where a file in the filesystem supplies information about the files being sent to clients. Such files are generally used for security, and other such things, rather than aiding in HTTP MIME field generation. 3. The MIME Header Supplemented File Type In order to make it practical (from both an implementation, and management viewpoint) to supplement the information available to servers, this memo defines a new file type, called the MIME Header Supplemented File Type, or MIM for short. It is recommended that files of this type have either a ".mime" or ".mim" extension, though this is very much affected by the requirements of the native operating system. The MIM file type shares much in common with the ASIS file type, in that HTTP MIME fields appear at the top of the file. Unlike the ASIS file type, the MIM file type does not require all fields to be present. An example MIM file might be: Content-type: text/html; charset=ISO-2022-JP . . . Where the exact field syntax can be found in the HTTP 1.0 specification [1], with the difference that all fields are optional. When an HTTP server recieves a request for a MIM file, it should generate the HTTP fields as best it can, and then parse the field definitions of the MIM file to supplement the fields it has generated. If the MIM file contains a field definition for a field the server has already generated, the value of the MIM field should be used to override the value generated by the server. The server should parse all the header fields of a MIM file, and in doing so, will parsed to the position in the file which contains the actual message body, which should be sent verbatim. This leads to a general requirement that all MIM files contain a Content-Type field definition, as the server cannot know the correct label for the content as MIM files can be used to encapsulate many different data types. For example, when the server sees a MIM file, it might generate a content header like: Content-type: text/plain but if a file like that shown earlier was requested, the server would first parse the MIME fields at the top of the file, use the field specified therein to override, or generate fields, so that the response sent to the client would contain a content type specification of: Content-type: text/html; charset=ISO-2022-JP providing a simple way of correctly labelling all HTML documents sent across the WWW. It is believed that the MIM file type represents a very easy way of supplementing the data a server has so that it can generate appropriate field values for content it sends out. 7. Limitations While the MIM type can be used to specify any MIME header, or value for a MIME header, a MIM file should not specify headers that the server can generate correctly, or which might hinder interoperability. For example, Content-Length is best left to the server to generate. 8. Applicability to protocols other than HTTP For protocols other than HTTP, it is recommended that the MIME headers be sent along with the message body, thereby allowing client-side processing of the headers. For example, if FTP is being used, the MIME headers will still provide an easy way for the content type to be correctly labelled: a client can see that the file is a MIM file, and process the headers supplied with the message body. 8. Security considerations Certain headers, such as WWW-Authenticate, hold information regarding security. Specifying such fields in the MIM file could lead to security breaches, or interoperability problems. Servers should ignore definitions of values for such fields. 9. References [1] T. Berners-Lee, R. T. Fielding, and H. Frystyk Nielsen. "Hypertext Transfer Protocol -- HTTP/1.0." Work in Progress (draft-ietf-http-v10-spec-00.ps), MIT, UC Irvine, CERN, March 1995. 2] T. Berners-Lee and D. Connolly, "Hypertext Markup Language - 2.0", Work in progress (draft-ietf-html-spec-05.txt), MIT/W3C, August 1995. [3] The Apache HTTP server documentation at http://www.apache.org/apache/ 10. Authors Address Gavin Thomas Nicol Technical Consulting Manager Electronic Book Technologies, KK 4-1-8 Kudan-minami, Chiyoda-ku, 102 Tokyo, Japan Tel: +81-3-3230-3861 Fax: +81-3-3230-3863 Email: gtn@ebt.com Date: Tue, 22 Oct 1996 00:22:59 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: B.1 and B.2 results At 9:27 PM 10/21/96, Gavin Nicol wrote: >>maximally self-revealing, we should probably use the character-length >>determination hack I suggested, ratehr than put 8-bit characters at the >>front of multibyte files. > >Nope. I would prefer to always have US-ASCII headers. Well, the question that I have is whether the character length determination trick is a show-stopper for you. I think that knowing that might help people make up their minds, assuming anyone else is even noticing this discussion. I like US-ASCII myself, from a programmer's point of view, but I can see several factors that argue against it: + FFFE is already established in Unicode, so many multi-byte systems will have text-editors that can deal with the initial FFFE. + Generic text-editing tools will almost certainly turn the user's view of a US-ASCII header into garbage on multibyte systems, but would not turn ISO character codes <127 into garbage. + Many people will want to edit XML with generic text-editors on their systems in their native character codes. Given the foregoing, the loss of elegance might pay off in a real gain in utility. An XML parser could even just cast the characters read into 8 bits to use a legacy HTTP header parser. So even the programmer isn't too inconvenienced. Notice that with a MIME-header we also get a convenient place to specify an XML version, and anything else we might need. I can agree with Gavin that catalogs are more elegant, but in some contexts they may not be more convenient. And as Tim and Michael note, a header that is integral is less likely to be lost... -- David PS does anyone else have an opinion on this? RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Tue, 22 Oct 1996 00:23:04 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: A modest proposal (DTD for DTDs revisited) I'd like to propose what I take to be an improved approach to the syntax of such things (taking into account some of the decisions already taken). I am also putting in the things that I think we should have, that I don't expect some people to like. I'm also going to just give examples, rather than a grammar. If the examples aren't clear enough to make sense, then that's useful data itself. The lack of formal semantics also reinforces the notion that this is a preliminary proposal, not a hard and fast prescription. I hope that it may be a wooden (or at least wicker)-man, but even if only a strawman, it may serve a purpose. The syntax is not defined because it will be whatever syntax we finally choose for document instances. I have used the proposed empty tag syntax, as a shining example of syntactic disambiguation.

This is the way comments should really be done.

We can even add a way to define a dtd fragment for the dtd-doc >contents. To do this we need to find a way to define the DTD for the >contents without preventing the DTD itself from serving as an >instance

Other syntactic options might also make sense: We should probably use an ID attribute instead of the name attribute in the above defining forms (to aid in cross-references, and the like). The Even with the fixed name, it doesn't look too bad: On the other hand, since attributes, content-models, tags, and attlists all havewe should perhaps allow multiple ID attributes per element, and vary the name of the attribute for the item being defined, to make DTD processing and cross-referencing with XML tools easier. I abandoned SGML technical terms for common parlance in the definition syntax. This could create some confusion for SGML geeks, but removes a significant barrier to initial understanding (and hence enthusiasm) for the HTML user in the street. The distinction between tag and element is useful, but can be pretty well approximated by "tag" and "tag and its contents." I think I went a bit too far in simplifying things, but if it would increase the user-base that would be a net gain. This contains just about everything I would want in a DTD language, in a syntax that I would prefer. I didn't include entity declaration syntax, but you can imagine. I would (of course) include a "new-character" declaration that give an entity name, and descriptive text, and would map to an SGML SDATA entity. Apologies for any infelicities or typos in the above, but I am in need of rest now. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Tue, 22 Oct 1996 00:33:55 -0400 To: w3c-sgml-wg@w3.org From: Arjun Ray Subject: Re: Caveat Tag Salad (Was: some ERB decisions) Cc: bosak@atlantic-83.eng.sun.com At 09:30 PM 10/20/96 -0700, Jon Bosak wrote: >[Arjun Ray:] > >| A datapoint from, er, existing practice. >| >| [explicit support for overlapping elements] > >This Netscape abomination is not accepted by the W3C and has been >explicitly condemned by Microsoft's Internet Explorer designers, > >So going forward, this is not even standard HTML practice. It's never been part of standard practice. OTOH, would anyone care to estimate how much of *existing* practice in "HTML" is *not* tag salad? :-) At any rate, I'd still prefer a relatively strong way to obviate tag salad. To my mind, empty endtags as an instance of minimization has always been the wrong way to look at it, official terminology notwithstanding. Empty endtags should be the rule, and named endtags the optional extra (with a clearcut syntactic purpose.) But with the ERB vote, I'll just say that IMHO expecting tag salad not to happen regularly in popular usage is myopic, and drop the subject. Arjun Date: Tue, 22 Oct 1996 01:01:45 -0400 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu CC: w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results > + FFFE is already established in Unicode, so many multi-byte systems >will have text-editors that can deal with the initial FFFE. Right, but it's not necessary for the header. I can agree to using this *after* the header has been stripped off... > + Generic text-editing tools will almost certainly turn the user's view >of a US-ASCII header into garbage on multibyte systems, but would not turn >ISO character codes <127 into garbage. Well, given that ISO and US-ASCII share most of the same code points, it seems that this is unlikely. As I noted, the only problem is for pure 16-bit encodings, which are reasonable scarce. > + Many people will want to edit XML with generic text-editors on their >systems in their native character codes. Most of which use 8 bit multibyte encodings that are ASCII compatible. I could be convinced that allowing 16bit header encodings makes sense, as I don't feel *too* strongly about it. However, losing MIME compatability seems a waste. To: "David G. Durand" (David G. Durand), w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: B.1 and B.2 results Date: Tue, 22 Oct 1996 08:12:02 +0100 At 05:22 AM 22/10/96 +0100, David G. Durand" (David G. Durand wrote: >PS does anyone else have an opinion on this? > Yes, but note the time: some of us sleep during the period between midnight and 6am! You have to wait for us to catch up with the arguments, by which time you and Gavin have normally exhausted them. One thing that worries me is that any decisions taken by the XML community are likely to be valid for less than one week! On 20th November the i18n community is going to discuss internationalization of MIME headers. If they decide that MIME headers need extending, and we have said that they should be codes <127 then we might have egg on our faces. Incidentally note the use of "codes less than <127". US-ASCII does not fly over this side of the pond. ISO-646:1991 might be more acceptable (this is the ASCII conformant variant rather than the 1983 version referenced by 8879). If you want 8-bit code then it has to be LATIN-1 so that it is compatible with the first 255 characters of 10646. I would suggest we hold off on making a decision until we know the outcome of the i18n meeting. Martin Bryan PS I am a well defined character known by different numbers that have allocated by a wide range of commercial, government and social organizations! ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Tue, 22 Oct 1996 07:30:34 -0500 From: Len Bullard To: Bill Smith CC: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Bill Smith wrote: > It seems there is disagreement over whether a DTD (real or imagined) is required > in order to process XML documents. From my perspective, we can not require DTDs > in XML 1.0 and have any chance of acceptance. I agree that we should not require them, but not because of acceptance. It is an issue of existing code and the goal of simplifying the processing requirements of SGML. We know it can be done because it has been done. We seem to be horsetrading features at the moment. > > 1. What exactly will the XML parser do? What is it's output? > > I'm more concerned with applications and how they are used - either by a machine > or a human. Fine. I think this working group should do a better job of defining the mythical parser and output as well as who is building it. Is an XML parser SP minus n lines of code? > > 2. Does this preclude the use of the DTD? Even in IADS and > > IDE/AS where we do not use the DTD anywhere in the rendering > > pipeline because we simplified the SGML requirements first, and > > the application parser is using stylesheet declarations, we still > > found in production, we needed SGMLS and a DTD for validation. > > Let the application (user) dictate whether a DTD is required. Laissez faire communications. How do database users feel about non-normalized databases without a schema? I agree, they should decide, but they should also be aware of the consequences of the decisions. That IEEE article Michael Leventhal quoted makes me aware that the lack of such knowledge goes high in the hierarchy of users. > > As long as a DTD is not precluded and one can be required based > > on the user's needs and decisions by the user, XML can safely say it is > > "SGML without DTDs". I can tell you from real experience, > > experienced SGML users will snicker while the HTML users > > will go on using HTML oblivious to the whole debate. > > What occurs between consenting users is not my concern. However, requiring DTDs, > especially from the void, is of concern to me. Let (some) "experienced SGML > users" snicker. I for one will not because document structure and tag > extensibility, whether enforced or not, are powerful concepts that will be > understood if properly presented. I think it was the experience of the HTML users that HTML plus DOCTYPE was a better document. > HTML users may in fact be oblivious to this debate - that is their gain. Come again? When HTML moves to the server, relational schema are simply replacing the DTD. Dr. Goldfarb is right though, in some form, one is always there. > However, they won't ignore the issue that HTML is not sufficient for their > needs. Solutions to their problems will be found, and they will look far more > like VisualBasic or JavaScript than any markup language we have devised. It just pushes the work back to the mythical programmer writing the exception handlers for badXML. It seems the theory here is, one can't write bad XML. > > So DeadGreekPoets aside, what feature cannot be provided with > > XML and No DTD? > > Validation. Agreed. Len Bullard Date: Tue, 22 Oct 1996 09:48:09 -0400 From: gtn@ebt.com (Gavin Nicol) To: mtbryan@sgml.u-net.com CC: dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results >One thing that worries me is that any decisions taken by the XML community >are likely to be valid for less than one week! On 20th November the i18n >community is going to discuss internationalization of MIME headers. If they >decide that MIME headers need extending, and we have said that they should >be codes <127 then we might have egg on our faces. They will always be 7 bit clean, I believe. Mechanisms exist *now* for larger coded character sets. Date: Tue, 22 Oct 96 08:25:14 CDT From: Michael Sperberg-McQueen Subject: Re: C.4 Undeclared entities? To: W3C SGML Working Group [Medium-long note. Executive summary: the discussion of 'implicit' DTDs has served its purpose and can be ended without damage to the process of designing and documenting XML 1.0.] The discussion of explicit and implicit DTDs has confused me a lot, mostly because the replies seem to be about topics very different from the postings to which they are ostensibly replying. A few rounds back, Len Bullard asked about the point of this debate. For what it's worth, this is my understanding of the original point: - the ERB asked what to do about references to undeclared entities. - Charles Goldfarb suggested they should be treated as in 8879, i.e. as errors. Along the way, he referred to the fact that any document can be viewed as being of some type, and that if that document type is not explicitly defined, one can nevertheless regard it as having some definition implicit in its usage. Unfortunately, Charles used the term 'DTD' for the set of rules governing the use of a document type -- not surprising, since that is how 8879 defines it -- and many others interpreted it as referring to the set of explicit declarations provided -- again not surprising, since that is a very widespread usage despite what 8879 says. The difference between the set of rules governing X and the set of explicitly formulated rules governing X is, needless to say, the set of implicit rules governing X. And that's the beginning of our rabbit trail. Implicit declarations are a reasonably common phenomenon in many formal languages (the rule in C that an undeclared identifier is assumed to be a variable or a function of type int is an easy example); the charges that they involve mysticism or magic seem way overblown to me. It is easy to define the behavior of an XML processor working with an empty or incomplete set of declarations as being governed by an *implicit* set of declarations -- I can say that, because I have already sketched out language that does so. An XML processor which has no explicit markup declarations has no warrant to flag any errors except those which violate some basic rule of XML, like element nesting or attribute quoting. That is, an XML processor which has no explicit markup declarations must behave pretty much identically to an XML processor which has explicit markup declarations in which every element is declared and every attribute is declared ATTNAME CDATA #IMPLIED. (This is the form which Lou Burnard and I call the Waterloo DTD, in honor of the Waterloo Centre for the Oxford English Dictionary, though Tim Bray has pointed out with some edge that no such DTD was ever used at Waterloo. The responsibility for the name must be borne by Lou and myself.) Note that here I part company with Charles, since he posits a maximally constraining DTD and I posit a maximally permissive DTD. As will be seen below, this turns out to make no difference at all. It seems to me that the only point of interest here is whether explicit reference to some notion of an implicit DTD is useful or not, in explaining the behavior of a processor faced with incomplete or nonexistent declarations. It seems Charles and I agree in our instincts that it is, or could be. It seems clear from the confused reactions of others that our instincts are wrong in this case: the idea is simple, but the obvious way of expressing it conveys something other than that simple idea to many readers who ought, if possible, to be able to read the XML spec with comprehension, if not always with the highest pitch of aesthetic pleasure. That's an argument against using the notion in the documentation. David Durand also pointed out to me that *requiring* a processor to construct, or behave as if it had constructed, element declarations of the form could be construed as *forbidding* processors from generating a more constraining, and thus more useful, DTD. If we want XML processors to be able to generate DTDs from sets of instances (the way OCLC's Fred does), and to compete on the quality of the DTDs they can generate (and I certainly want that), then we don't want to forbid such competition. And competition is indeed a good idea here, since as has been pointed out it's not always clear which of the many possible explicit DTDs is the most useful for further work with the document in question, or other documents. David (and, independently, Jon Bosak) also pointed out that if an XML processor is required to treat a well-formed XML document with no explicit DTD as legal, then (a) it doesn't matter whether it generates, internally, a maximally constraining DTD, or a maximally permissive DTD such as the Waterloo DTD described above, or some intermediate DTD, or even whether it generates an identifiable DTD data structure at all, and (b) we couldn't tell what it does even if it did matter, because the resulting behavior (accept a well-formed document as legal) is the same in all cases. So it's misleading to *define* the particular implicit DTD which a processor is supposed to assume. These arguments, coupled with the fact that no one but Charles and I seem to think the appeal to an 'implicit' DTD makes any sense, have led me to conclude that there is no gain in using the concept of an implicit DTD in describing XML processor behavior. Since no one seems to be arguing the contrary (Charles is arguing, quite rightly, that the notion itself is not internally contradictory, but that's not in itself an argument for using it in the documentation), the question of implicit DTDs can, I think, be put to rest. As an editorial, not a technical matter, the editors of the XML spec have no intention of appealing to the notion of an implicit DTD. The technical aspects of the question are not relevant, since the required behavior can be explained with or without such an appeal, and it's clear that the notion of implicit DTDs will confuse, not clarify, the issues for some readers. -C. M. Sperberg-McQueen Date: Tue, 22 Oct 1996 10:40:58 -0400 To: "David G. Durand" (David G. Durand) From: Murray Maloney Subject: Re: A modest proposal (DTD for DTDs revisited) Cc: w3c-sgml-wg@w3.org Many thanks to David, I like this! I can't say that I like the specific syntax that much, but the general idea of being able to simply declare element types and "attribute types" is very appealing. David has very succesfully reduced this to the point that a non-wizard like me can immediately see the value and merit. Frankly, I would not go so far on terminology, but I think that will be a matter of finding a common ground between the vocabularies of the SGML literati and the "great unwashed" -- to borrow an endearment from an unnamed technical committee. :-) Here, we have a meta-language in which one can declare element types and their content models, modify those content models by providing additional declarations (but without the hackery of parameter entities), and attach attributes to element types at will. This is fabulous! I don't really see the value in losing the "|" connector in expressing content models, but I guess that it does make things a bit simpler. The element type is a handy shorthand that is, I assume, a useful replacement for parameter entities -- but much clearer. I agree that one should be able to declare that a given attribute or attribute list applies to a named/ID'd element type, but I also think that an element type declaration needs to be able to declare that an attribute or attribute list applies to itself. Finally... There have been numerous fragments of discussions that have suggested that it might be useful to have multiple IDs on a single SGML object -- an element, for most purposes. David has suggested the same again. I don't understand why this would be helpful. Is there some suggestion that an object's identity should be, somehow, context-sensitive? That addressing an object by one name means one thing, but that addressing it by another name might mean another thing? And if that is the issue, isn't it better to let the object have only one identity and to rely on other methods to assign aliases and to express additional layers of semantics? Help me with this -- I just don't get it. Regards, Murray At 12:23 AM 22-10-96 -0400, David G. Durand" (David G. Durand wrote: >I'd like to propose what I take to be an improved approach to the syntax of >such things (taking into account some of the decisions already taken). I am >also putting in the things that I think we should have, that I don't expect >some people to like. I'm also going to just give examples, rather than a >grammar. If the examples aren't clear enough to make sense, then that's >useful data itself. > >The lack of formal semantics also reinforces the notion that this is a >preliminary proposal, not a hard and fast prescription. I hope that it may >be a wooden (or at least wicker)-man, but even if only a strawman, it may >serve a purpose. The syntax is not defined because it will be whatever >syntax we finally choose for document instances. I have used the proposed > empty tag syntax, as a shining example of syntactic disambiguation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > extending="highlighted"/> >

This is the way comments should really be done.

>

We can even add a way to define a dtd fragment for the dtd-doc >>contents. To do this we need to find a way to define the DTD for the >>contents without preventing the DTD itself from serving as an >>instance

> > > > > > > > > > > > > legal-anywhere-within="p" illegal-anywhere-within="footnote"/> > > > > > >Other syntactic options might also make sense: > > We should probably use an ID attribute instead of the name attribute in >the above defining forms (to aid in cross-references, and the like). The > > Even with the fixed name, it doesn't look too bad: > > > On the other hand, since attributes, content-models, tags, and attlists >all havewe should perhaps allow multiple ID attributes per element, and >vary the name of the attribute for the item being defined, to make DTD >processing and cross-referencing with XML tools easier. > > I abandoned SGML technical terms for common parlance in the definition >syntax. This could create some confusion for SGML geeks, but removes a >significant barrier to initial understanding (and hence enthusiasm) for the >HTML user in the street. The distinction between tag and element is useful, >but can be pretty well approximated by "tag" and "tag and its contents." I >think I went a bit too far in simplifying things, but if it would increase >the user-base that would be a net gain. > > This contains just about everything I would want in a DTD language, in >a syntax that I would prefer. I didn't include entity declaration syntax, >but you can imagine. I would (of course) include a "new-character" >declaration that give an entity name, and descriptive text, and would map >to an SGML SDATA entity. > > Apologies for any infelicities or typos in the above, but I am in need >of rest now. > > -- David > > >_________________________________________ >David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com >Boston University Computer Science \ Sr. Analyst >http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams >--------------------------------------------\ http://dynamicDiagrams.com/ >MAPA: mapping for the WWW \__________________________ >http://www.dynamicdiagrams.com/services_map_main.html > > > > ************* NOTE NEW ADDRESS AND PHONE NUMBER ***************** Murray Maloney murray@sq.com Technical Director http://www.softquad.com SoftQuad Inc. P.O. Box 2025 Phone: +1 416 544-3010 20 Eglinton Avenue West, 12th Floor Fax: +1 416 544-0300 Toronto, Ontario, Canada M4R 1K8 From: lee@sq.com Date: Tue, 22 Oct 96 12:14:37 EDT To: dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results > I can agree with Gavin that catalogs are more elegant, but in some contexts > they may not be more convenient. And as Tim and Michael note, a header that > is integral is less likely to be lost... > > PS does anyone else have an opinion on this? Of course :-) Yes, I think the header should be inside the document, not in a separate file, since for internet work, the CATALOG file might not even be accessible. We had to deal with this for Panorama -- consider the case where the SGML is the result of a database query you just paid $.5 for. You don't really want Panorama probing around in the database trying to find a file called CATALOG or catalog (it searches for both -- our nod towards the unfortunate wording of the TR which says the name of the file must be case insensitive). Each probe might cost money, and in any case the resulting error messages aren't always distinguishable from text. Panorama understands some processing instructions to find the DTD, style sheet, etc. and to suppress searching for the catalog. Recently, we even added another processing instruction to let Panorama know a URL for the document it's viewing, to work around deficiencies in Unix Netscape. Allowing a MIME-style header in XML will make all that much simpler. Requiring a MIME-style header in XML files will allow them to be identified reliably, rather like a DOCTYPE line in SGML. The header could also specify the XML version, for which we will be very grateful when we are working on XML 2.0. I still have email messages from 1983 and earlier; they are still valid. Where the meaning of headers has been changed, it has only done so in the presence of a Mime-version header. There is no "implied MIME header" :-) -- if a mail message has no Mime-version, it is not MIME-compliant, and must be treated as per RFC 822. In the same way, XML-Version could be required, and, if not present, the file is either taken to be XML 1.0 or plain text, at pleasure. This sort of use of headers allows forwards compatibility and a great deal of interoperability with existing systems. It will also be a lot easier to get acceptance in the IETF world if XML integrates with and builds on existing IETF international standards such as MIME. The ISO is not the only international standards body in the world :-) Lee Date: Tue, 22 Oct 1996 12:39:17 -0400 From: gtn@ebt.com (Gavin Nicol) To: U35395@UICVM.UIC.EDU CC: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? As a note on undelcared entities. I proposed a while back on this list that XML processors provide a fallback resolution mechanism: namely that of trying to find an entity of the same same within a catalog etc., and if found, treat it as being declared. My prime motivation is that with this mechanism, it is easy to use XML within realtime systems, and without it, close to impossible. It also seems to be intuitively correct. Date: Tue, 22 Oct 1996 12:20:18 -0500 From: Len Bullard To: Michael Sperberg-McQueen CC: W3C SGML Working Group Subject: Re: C.4 Undeclared entities? Michael Sperberg-McQueen wrote: > > [Medium-long note. Executive summary: the discussion of 'implicit' > DTDs has served its purpose and can be ended without damage to > the process of designing and documenting XML 1.0.] > > The discussion of explicit and implicit DTDs has confused me a > lot, mostly because the replies seem to be about topics very > different from the postings to which they are ostensibly replying. Thank you, Michael. These summaries do much to keep me focused and others, I suspect, who are reading 200 plus email messages a day. For me, the appeal to the DeadPoetsSociety is too much like my own appeals to Chaos Theory: they make sense to me but are a clear indicator that the thread is tired. > - the ERB asked what to do about references to undeclared entities. > - Charles Goldfarb suggested they should be treated as in 8879, > i.e. as errors. This appears correct. It can be debated where they should be declared. Could an XML instance without *some mechanism* for declaring an entity do otherwise? > Along the way, he referred to the fact that > any document can be viewed as being of some type, and that > if that document type is not explicitly defined, one can > nevertheless regard it as having some definition implicit in > its usage. Having a document declared as a type and having an entity declared to exist and having a mechanism for resolving its location do not seem to be the same of necessity. > Unfortunately, Charles used the term 'DTD' for the set of rules > governing the use of a document type ... Use? I won't argue 8879 legalese, but that is a strong term that to me, implies, semantics. A DTD can't do that. It can tell me if a production is valid with respect to hierarchy, occurrence, frequency, id/idref, etc., but says next to nothing, ye, nothing, about semantic use. That is, in classical data structure fundamentals, the operations that can be applied formally. > Implicit declarations are a reasonably common phenomenon in many > formal languages (the rule in C that an undeclared identifier is > assumed to be a variable or a function of type int is an easy > example); the charges that they involve mysticism or magic seem way > overblown to me. That is not mysticism. It is behavior defined externally to the document instance. It is defined in the C standard. XML can easily do this. Gavin Nicol has made a suggestion regarding the catalog. We use a *domain* file in IDE/AS for this. Same thing more or less. The application chokes if this does not exist. > It is easy to define the behavior of an XML > processor working with an empty or incomplete set of declarations as > being governed by an *implicit* set of declarations -- I can say > that, because I have already sketched out language that does so. Are they implicit? Or are they explicitly declared in an external document. What I am asking is, resolved by rule or by mechanism? Rule is the standard (XML spec). Mechanism is a catalog, etc. explicitly defined as extant or an error is issued. > An XML processor which has no explicit markup declarations has no > warrant to flag any errors except those which violate some basic rule > of XML, like element nesting or attribute quoting. That is, an XML > processor which has no explicit markup declarations must behave > pretty much identically to an XML processor which has explicit markup > declarations in which every element is declared > > > > and every attribute is declared ATTNAME CDATA #IMPLIED. (This is the > form which Lou Burnard and I call the Waterloo DTD, in honor of the > Waterloo Centre for the Oxford English Dictionary, though Tim Bray > has pointed out with some edge that no such DTD was ever used at > Waterloo. Ok. I thought Waterloo was the title of a country song by George Hamilton IV. Silly me. > It seems to me that the only point of interest here is whether > explicit reference to some notion of an implicit DTD is useful or > not, in explaining the behavior of a processor faced with incomplete > or nonexistent declarations. I think it beside the point. I agree that in some sense, an explicit DTD of some form does exist be it as an 8879 DTD, or in the form of structures or classes in the application. I think it desirable, even mandatory, that some form of DTD must be able to exist for validation. My experience with large ASCII files of markup tells me without it, it is deuce difficult to chase down errors. But, this is not the same as saying an entity has to be declared in the DTD. This is inconvenient because then the DTD must be transmitted with the document, or the record of declaration must exist and be accessed. We ran round this with the MID. Notation declarations with attributes are also inconvenient. That lead to xenoforms. I can only quote Lee: "ugly". It's very hard to get around the definition of a formal data structure as having data and operations declared. > It seems Charles and I agree in our instincts that it is, or could > be. It seems clear from the confused reactions of others that our > instincts are wrong in this case: the idea is simple, but the > obvious way of expressing it conveys something other than that simple > idea to many readers who ought, if possible, to be able to read the > XML spec with comprehension, if not always with the highest pitch of > aesthetic pleasure. That's an argument against using the notion in > the documentation. Ummm, with my preference for pop lyrics over dead poets, I will fail to meet the aesthetic requirements of this list. I am not qualified to comment on the pleasures of others unless they paid their cover at the door and send up their requests clearly written on a tenner, (Feelings or Sweet Home Alabama: $100). >... it's not > always clear which of the many possible explicit DTDs is the most > useful for further work with the document in question, or other > documents. No, but I charge the author with that task by putting a ... the resulting behavior (accept a well-formed > document as legal) is the same in all cases. So it's misleading > to *define* the particular implicit DTD which a processor is supposed > to assume. The issue was, is an instance with an undeclared entity legal. Is it? Can it be? > As an editorial, not a technical matter, the editors of the XML spec > have no intention of appealing to the notion of an implicit DTD. > The technical aspects of the question are not relevant, since the > required behavior can be explained with or without such an appeal, > and it's clear that the notion of implicit DTDs will confuse, not > clarify, the issues for some readers. It will confuse them because it assumes the beast is in the pen. Still, the entity is undeclared. That seems to be a reportable error. Len Bullard Date: Tue, 22 Oct 96 11:49:51 CDT From: Michael Sperberg-McQueen Subject: Re: B.1 and B.2 results To: W3C SGML Working Group On Tue, 22 Oct 1996 00:18:54 -0400 David G. Durand said: >PS does anyone else have an opinion on this? It seems to me that David and Lee have put the case for internal headers fairly well. And as they and Gavin have pointed out, there's a strong case for MIME compatibility; at the very least, XML should not require external metadata to be ignored. (The decision as announced never did require that, but perhaps the spec should say explicitly that it's *allowed*, or even *recommended*, to use standard metadata channels like MIME where applicable, in order to avoid a repetition of the explosive misunderstandings demonstrated on this list.) The proposal for in-file MIME headers strikes me as having all the problems David suggested, most significantly the incompatibility between the ASCII of the MIME header and the character set which may be used in the rest of the file. This is not an issue for some coded character sets, but certainly is for others, including the canonical forms of ISO 10646. I cannot conveniently, in a UCS-2 editor, generate a file part in ISO 646 and part in UCS-2. The biggest drawback I see, however, is that defining XML entities as beginning with a MIME header means that no existing SGML parser can be used as is on XML documents. Every parser will require either a prosthetic filter to strip the MIME header off, or a modification to make it understand and handle the MIME header as a packaging device. Every one. That, for me, is a show-stopper. If there is an in-file header, I think it needs to be in a format SGML processors can now handle; hence the idea of using PI syntax for it. I also think it needs to be in a form that users can produce using their normal tools, without jumping through hoops; that seems to mean it needs to be in the same character set it's declaring. The main arguments against the PI format appear to be (a) that, in Gavin's words, "it is a hack", which I take to mean, in neutral terms, that Gavin does not approve of it, and (b) that it cannot be read successfully without external knowledge. Against the first argument, no rejoinder is possible. Against the second, it may be pointed out that the claim is false. Gavin, and now David, have repeatedly claimed that the PI label relies on a vicious circle: you have to know what it says to read it. When I first described the PI-form internal label, I took pedantic care to show that this is not true: the PI label is unambiguous for a variety of existing coded character sets (including all the ones people had suggested for XML use, plus a few more including EBCDIC). Gavin and David have pointed out, correctly, that it is possible to construct a coded character set for which the PI label is not unambiguous. This would involve an encoding for which some, but not all, of the characters A to Z and a to z would share positions with ASCII or EBCDIC or ISO 10646, while the rest would be rearranged so as to render it possible to misread an XML character-encoding declaration without detecting the misreading. This strikes me as a low-probability development, given the importance of ASCII (er, I mean ISO 646!), but it is indubitably possible. It seems to me that it's more useful to ask whether the internal PI label will be ambiguous for any character set now in reasonably wide use or likely to be developed by anyone not seeking specifically to undermine the use of internal labels. Gavin has suggested that it *is* ambiguous in this way, but has not named any particular pair of encodings for which the PI label does not work successfully. When he first made this claim, I went back to check the JIS X 0208, Shift-JIS, and EUC encodings, to see whether they would work with the internal PI label, as well as the ASCII, ISO 8859-*, EBCDIC, UCS-2, UCS-4, and UTF-8 encodings already examined. They do. As Gavin has pointed out (in support of ASCII MIME headers), *all* the major East Asian encodings will work, for the same reason: they all read and produce ISO 646 / ASCII text in forms identical to ISO 646. So it seems to me that in all foreseeable practical cases, an in-file PI character set label is (a) parseable, (b) compatible with existing SGML processors, and (c) not inherently incompatible with the use of external metadata channels. If the fact that it is not MIME is a show-stopper for enough of us, then we can consider other alternatives. An in-file MIME header would be (a) parseable, (b) compatible with external metadata, (c) incompatible with existing SGML processors, and (d) in some cases hard or impossible to create using standard text editing tools. Losing the entire notion of in-file labels would (a) expose XML processors to undetectable errors when external metadata is faulty or missing, (b) allow the user of arbitrary character encodings (implementor is responsible for getting it right, it's not our problem), (c) allow us to end this discussion before it crosses the boundary from the laughable to the intolerable. -C. M. Sperberg-McQueen Date: Tue, 22 Oct 1996 12:54:04 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: A modest proposal (DTD for DTDs revisited) At 10:40 AM 10/22/96, Murray Maloney wrote: >Many thanks to David, > >I like this! Thanks. >I don't really see the value in losing the "|" connector in >expressing content models, but I guess that it does make >things a bit simpler. I didn't intend to lose it. (A problem with definition by example), but to show that if #PCDATA is only allowed in models like (#PCDATA | x | y | z)*, we might just a specail syntax for that case, nipping in the bud the obvious, but illegal, (#PCDATA, foo, #PCDATA, bar, bletch). By having "#PCDATA-containing" models have a special format, we elimiate a source of possible confusion. models like "(a|b)+, c" should still be allowed. We should remove SGML's funky paren rules as well, and go for a standard operator-precedence syntax. Pulling together adjacent like operators is easy to do for a computer, and a potential source of error for a user. >The element type is a handy shorthand that is, >I assume, a useful replacement for parameter entities -- >but much clearer. I actually think we should keep parameter entities, but have built in notation to eliminate some of their idiomatic uses -- cases where by definition we are synthesizing useful abstractions that SGML lacks. >I agree that one should be able to declare that a given attribute >or attribute list applies to a named/ID'd element type, but I also >think that an element type declaration needs to be able to declare >that an attribute or attribute list applies to itself. yes. Incomplete again. > >Finally... There have been numerous fragments of discussions >that have suggested that it might be useful to have multiple IDs >on a single SGML object -- an element, for most purposes. David >has suggested the same again. I don't understand why this would >be helpful. Is there some suggestion that an object's identity >should be, somehow, context-sensitive? That addressing an object >by one name means one thing, but that addressing it by another >name might mean another thing? And if that is the issue, isn't >it better to let the object have only one identity and to rely >on other methods to assign aliases and to express additional layers >of semantics? Help me with this -- I just don't get it. Well, I didn't get it either. But I was thinking that in this case we have namespaces for elements, attributes, content models, and attribute lists, and unique IDs (_within_ each namespace). If we wanted to use the ID/IDREF mechanism to implement these references, however, we would have to add an extra parameter for the Unique_id, because there is only _one_ global namespace for ID and IDREF. So I can see the use for several namespaces, each with a parser-enforced uniqeness and reference semantics. This is not a must-have for me, but I now see why people would want it. -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Tue, 22 Oct 1996 11:33:08 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com, dgd@cs.bu.edu Subject: DTD markup decision (Was: Re: A modest proposal...) Dave Durand is to be commended for the effort and thought that went into his plan. However, we already covered this ground at length and in great detail when we considered Tim Bray's DSD proposal. The question that was finally placed before the ERB was as follows: Shall XML use a markup declaration syntax based on a simplification of ISO 8879 clauses 10-11? This was put to a mail vote, which under our rules takes a week to complete. One of the ERB members has been unable to reply for most of that period due to family matters. He has finally registered his vote, and I can now report that the proposition above has been unanimously approved by the ERB. However disappointed some of us may feel about this, the decision has been made and it's time to move on. Please take any further discussion of this point off the list so that we can continue to meet our deadlines. I will be happy to answer any further questions you may have about this through private correspondence. Jon Date: Tue, 22 Oct 1996 15:05:25 -0500 To: Michael Sperberg-McQueen , W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: B.1 and B.2 results At 11:49 10/22/96, Michael Sperberg-McQueen wrote: >On Tue, 22 Oct 1996 00:18:54 -0400 David G. Durand said: >>PS does anyone else have an opinion on this? >The biggest drawback I see, however, is that defining XML entities as >beginning with a MIME header means that no existing SGML parser can >be used as is on XML documents. Every parser will require either a >prosthetic filter to strip the MIME header off, or a modification to >make it understand and handle the MIME header as a packaging device. >Every one. > >That, for me, is a show-stopper. We need to remember that most of the individuals in the world are not using SGMl software, and that the processing required to strip the header is a 3 line perl hack. Anyway, since SGML has the general notion of an entity manager, the notion of an entity header on the storage object fits right into the SGML model. >If there is an in-file header, I think it needs to be in a format >SGML processors can now handle; hence the idea of using PI syntax for >it. I also think it needs to be in a form that users can produce >using their normal tools, without jumping through hoops; that seems >to mean it needs to be in the same character set it's declaring. It needs to have, at least, the same encoded character length -- as I have already argued. >The main arguments against the PI format appear to be (a) that, in >Gavin's words, "it is a hack", which I take to mean, in neutral >terms, that Gavin does not approve of it, and (b) that it cannot >be read successfully without external knowledge. A hack (among many other things) is something that is not dependable, or that relies on tricky relationships between differing interpretations of the same data or code. (If you accept (b), as Gavin does), these two facts alone imply (a). PIs are a hack, that depend on epiphenomena of current coding sets. Here's a similar hack, that I take as a cononical example of the "character set hack" genre. You can change the case of letters pretty portably by XOR-ing them with a space. This works in EBCDIC and ASCII. >Against the first argument, no rejoinder is possible. It was so self-evidently a hack to me that I had trouble thinking how to explain it. The partial attempt above shows at least two properties that I deem undesirable, and contributory to its hack-nature. > Against the second, it may be pointed out that the claim is false. The claim as you have repeated it is false. The claim that I have made is not false (I can't speak for Gavin, but I suspect he agrees): You cannot recognize the PI, _without having a list of the magic numbers for legal PI definitions_. If a user attempts to use a PI that does not exactly match one of the "the magic number formulas," then the processor may not even be able to recognize that a PI was present. So the apparent _self-descriptive_ aspect of the data is _not_ there. I want internal headers so I can tell what data is -- If I can't dependably tell if there's a new kind of header that I don't recognize, it's a much less useful header. We should at least be able to have the equivalent of a tape "standard label". Wasn't there a field in there to tell you if it was a "weird" "ASCII" coded tape? Another of the factors that shows that the PI hack is a hack and not a solution is that it _looks_ extensible, but extending it for a new encoding will, in fact, break existing software so that it can't even use the header to explain the problem. >Gavin, and now David, have repeatedly claimed that the PI label >relies on a vicious circle: you have to know what it says to read >it. When I first described the PI-form internal label, I took >pedantic care to show that this is not true: the PI label is >unambiguous for a variety of existing coded character sets (including >all the ones people had suggested for XML use, plus a few more >including EBCDIC). This is true only for all the character sets that _we precode into XML_. It does not work for any new character set names. The PI looks like it has a parameter, but in fact the PI, and its parameter, constitute a magic string of bytes with no internal structure. This is a bit counterintuitive. >Gavin and David have pointed out, correctly, that it is possible to >construct a coded character set for which the PI label is not >unambiguous. This would involve an encoding for which some, but not >all, of the characters A to Z and a to z would share positions with >ASCII or EBCDIC or ISO 10646, while the rest would be rearranged so >as to render it possible to misread an XML character-encoding >declaration without detecting the misreading. This strikes me as a >low-probability development, given the importance of ASCII (er, >I mean ISO 646!), but it is indubitably possible. This is part, but not all of the objection. See preceding. >It seems to me that it's more useful to ask whether the internal PI >label will be ambiguous for any character set now in reasonably wide >use or likely to be developed by anyone not seeking specifically >to undermine the use of internal labels. It's a tempting item to devise, but _I_ would restrain myself. >So it seems to me that in all foreseeable practical cases, an in-file >PI character set label is (a) parseable, (b) compatible with existing >SGML processors, and (c) not inherently incompatible with the use of >external metadata channels. If the fact that it is not MIME is a >show-stopper for enough of us, then we can consider other >alternatives. And also: A reinvention of the wheel Less flexible than MIME headers Does not take advantage of the existing MIME header-parsing facilities already in every browser on the Web. (I guess this is follow on to reinventing the wheel. Now we'll need a new kind of axle to spin it on...) Is an unfamiliar syntax, compared to headers that everyone has been seeeing on e-mail for the last 20 years (or whatever)... Also note that it is "(a) parseable" only if the character set is one of the ones wired into your parser. >An in-file MIME header would be (a) parseable, (b) compatible with >external metadata, (c) incompatible with existing SGML processors, >and (d) in some cases hard or impossible to create using standard >text editing tools. (d) is not true. I explained how we could use the "multibyte-mode" determination trick proposed for the PI to make the header readable on all the existing systems. And the header would enterable as a native sequence of characters for any one or two-byte character code. These characters would be user-readable in the existing codings, though not perhaps in some weird new one (these are the only people for whom creating the header might be "hard". The header would be machine-readable regardless of encoding. >Losing the entire notion of in-file labels would (a) expose XML >processors to undetectable errors when external metadata is faulty or >missing, (b) allow the user of arbitrary character encodings >(implementor is responsible for getting it right, it's not our >problem), (c) allow us to end this discussion before it crosses the >boundary from the laughable to the intolerable. I do not advocate losing the notion. But if it gets intolerable enough, maybe we can do the right thing after all! -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Tue, 22 Oct 1996 15:59:20 -0400 To: Michael Sperberg-McQueen From: masonjd@ornl.gov (James David Mason) Subject: Re: C.14 Enumerations in attribute declarations? Cc: W3C SGML Working Group At 01:32 PM 10/17/96 CDT, Michael Sperberg-McQueen wrote: >On 23 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the question needs further >discussion in the work group. Possible positions are to remove >8879's restriction (at the cost of more complex XML-to-SGML >DTD translation), to retain it, to eliminate enumerated values >entirely in the hope that WG8 will relax the restriction, or >to retain the restriction but make it a non-reportable error. > >C.14 Should XML allow more than one enumerated type (name-group >declared value) to contain the same possible value (11.3.3)? > > > I always thought this was a dumb restriction in SGML; I wasn't fond of the particular bit of minimization it was needed for, either. Let's ditch it here and see whether WG8 can do likewise. Jim Mason Dr. James D. Mason (ISO/IEC JTC1/SC18/WG8 Convenor) Lockheed Martin Energy Systems Information Management Services SGML Systems Development 1060 Commerce Park, M.S. 6480 Oak Ridge, TN 37831-6480 U.S.A. Telephone: +1 423 574-6973 Facsimile: +1 423 574-0004 Network: masonjd@ornl.gov Date: Tue, 22 Oct 1996 17:34:59 -0400 From: gtn@ebt.com (Gavin Nicol) To: U35395@UICVM.UIC.EDU CC: w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results >The biggest drawback I see, however, is that defining XML entities as >beginning with a MIME header means that no existing SGML parser can >be used as is on XML documents. Every parser will require either a >prosthetic filter to strip the MIME header off, or a modification to >make it understand and handle the MIME header as a packaging device. >Every one. > >That, for me, is a show-stopper. This depends on whether this will be a generally useful (ie. widely used) feature in the future. >I also think it needs to be in a form that users can produce >using their normal tools, without jumping through hoops; that seems >to mean it needs to be in the same character set it's declaring. Coded character set *and* encoding. >Gavin, and now David, have repeatedly claimed that the PI label >relies on a vicious circle: you have to know what it says to read >it. It's true. You have to sniff at the data, and the sniffing may not always succeed. That's reason #1 for calling it a hack. A more objectional one is that you will *require* people for add to their data (a header pretending to be data). This may seem pedantic, but I find this *semantically* objectionable, or counterintuitive. >Gavin and David have pointed out, correctly, that it is possible to >construct a coded character set for which the PI label is not >unambiguous. This would involve an encoding for which some, but not >all, of the characters A to Z and a to z would share positions with >ASCII or EBCDIC or ISO 10646, while the rest would be rearranged so >as to render it possible to misread an XML character-encoding >declaration without detecting the misreading. This strikes me as a >low-probability development, given the importance of ASCII (er, >I mean ISO 646!), but it is indubitably possible. You miss one important case: the case where there is no ASCII compatability area in the lower 127 code points. This will also fail in that you will be unable to parse it. I forget what exactly they are, but there *are* such encodings in existance (Rick. do you remember of JOHAB is one?) Another case (also of low probability) is having a file that is encoded in a manner that might confuse the sniffing logic (eg. a compressed file who's header looks like the signature for UCS-2). >Losing the entire notion of in-file labels would (a) expose XML >processors to undetectable errors when external metadata is faulty or >missing, (b) allow the user of arbitrary character encodings >(implementor is responsible for getting it right, it's not our >problem), (c) allow us to end this discussion before it crosses the >boundary from the laughable to the intolerable. If you replace "in-file" with "in-data", this is my preferred method. Meta-data should live *beside* the data, not *inside* it. Let's a header a header. A PI by any other name would parse as well... Date: Tue, 22 Oct 1996 14:50:03 -0700 To: W3C SGML Working Group From: Tim Bray Subject: Non-Unicode characters, SDATA, etc. It has been argued convincingly on this group that the use of SDATA entities provides a high-value way of including some extra information for a receiving application, to the effect that this is more than just a private-area Unicode number. My position, and I'm not speaking for the ERB but I suspect that they would agree, has been that XML should be happy to do a good job dealing with what Unicode already defines, and accept that particular 80-20 tradeoff, and perhaps fail to be the ideal tool for those who deal with particularly exotic species of scripture. Anders surprised some of us by pointing out that there are a large number of ISO entities that are not in ISO 10646 at all. So I'd like to request input >from the WG on this. In my personal experience, all the applications I've built and delivered, based on SGML, HTML, and what would have been XML if it'd been defined, could have lived perfectly happily using just the repertoire offered by 10646; the number of non-standard characters was so small that doing some extra work to package them up would have been a very minor irritation indeed. On the other hand, Anders' posting makes it clear that [particularly in the area of mathematics] there are routinely a substantial number of non-10646 characters available [in theory at least] to technical publishers; who have been a mainstay of SGML support over the years. So: what applications are going to become severely XML-impaired if we lack the nice out-of-band SDATA signaling mechanism? Concrete examples would be the most valuable input. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Tue, 22 Oct 1996 14:51:47 -0700 To: W3C SGML Working Group From: Tim Bray Subject: Re: B.1 and B.2 results At 03:05 PM 10/22/96 -0500, David G. Durand" (David G. Durand wrote: >At 11:49 10/22/96, Michael Sperberg-McQueen wrote: >>The biggest drawback I see, however, is that defining XML entities as >>beginning with a MIME header means that no existing SGML parser can >>be used as is on XML documents. >> >>That, for me, is a show-stopper. > >We need to remember that most of the individuals in the world are not using >SGMl software Clearly, Michael and David are not going to convince each other on this. More generally, it seems unlikely that David/Gavin and the SGML ERB are going to convince each other on this. To reiterate, the ERB feels that: o XML parsers should make an aggressive effort to use the right encoding to process text entities. o To do so, they should of course use mime headers, resource forks, docman metadata, smoke signals, whatever they have o It is valuable to include a way for a document, in its own syntax and in its own encoding, to signal what that encoding is; as a reminder to the author, as self-defence against incompetent webmasters and overaggressive conversion services. o we should not gratuitously put things in XML files that will make them unreadable by SGML parsers [the smokescreen about "it's the entity not the file" is just that] As for the argument as to whether picking apart the You cannot recognize the PI, _without having a list of the magic numbers >for legal PI definitions_. If a user attempts to use a PI that does not >exactly match one of the "the magic number formulas," then the processor >may not even be able to recognize that a PI was present. So the apparent >_self-descriptive_ aspect of the data is _not_ there. Thank you David. This is a point I have felt, but been unable to articulate. >This is true only for all the character sets that _we precode into XML_. It >does not work for any new character set names. The PI looks like it has a >parameter, but in fact the PI, and its parameter, constitute a magic string >of bytes with no internal structure. This is a bit counterintuitive. As is explaining to people that you can do: ..... but not .... .... >I do not advocate losing the notion. But if it gets intolerable enough, >maybe we can do the right thing after all! I agree with the notion of keeping "in-file" labels, but simply cannot accept "in-data" labelling, or anything that pretend to be like it. Date: Tue, 22 Oct 96 17:28:21 CDT From: Michael Sperberg-McQueen Subject: Re: B.1 and B.2 results To: W3C SGML Working Group On Tue, 22 Oct 1996 17:57:14 -0400 Gavin Nicol said: >>You cannot recognize the PI, _without having a list of the magic >>numbers for legal PI definitions_. If a user attempts to use a PI >>that does not exactly match one of the "the magic number formulas," >>then the processor may not even be able to recognize that a PI was >>present. So the apparent _self-descriptive_ aspect of the data is >>_not_ there. >Thank you David. This is a point I have felt, but been unable to >articulate. I'm not sure what David means by 'magic numbers' here, but if he means the IETF-defined values for the MIME charset field (or, XML Encoding attribute), I don't think this is true at all. Any XML processor will know what character sets (by which, for now, I mean 'coded character sets and/or encodings thereof') it can handle. When it encounters one it doesn't handle, I believe it's likely to fall into a case like the following: A. The processor accepts ISO 8859, UTF-8, and UCS-2. It gets a Shift-JIS entity, and says "Sorry; this entity is in a character encoding called 'Shift-JIS' which I don't handle." It was able to read and parse the PI, because in Shift-JIS all the characters in are bit-identical to ISO 8859-*. B. The processor accepts EBCDIC, UTF-8, and UCS-2. It gets a Shift-JIS entity, and says "Sorry; this entity is in a character encoding called 'Shift-JIS' which I don't handle." It was able to read and parse the PI, because in Shift-JIS all the characters in are bit-identical to UTF-8. C. The processor accepts Shift-JIS, UTF-8, and UCS-2. It gets an EBCDIC entity, and says "Sorry; this entity is in a character encoding which I don't handle. (There is also a chance that the entity has been trashed, or isn't in XML.)" The salient fact about the entity, which is that it's in an unknown character set or otherwise unprocessable, can be reliably detected, although the EBCDIC-encoded string 'ebcdic-cp37' cannot be deciphered. N.B. David is right to point out that labels can only be read by those capable of reading them. This is clearly a drawback, compared with a system in which they are always readable, even by those not capable of reading them. But the key fact here seems to me very simple, and accurately conveyed: this-entity-not-readable. Quick quiz: out of the members of the WG currently reading this (both of you!), how many might be able to tell their browser how to take corrective action if they knew the unreadable material was in something called 'ebcdic-cp37'? How about 'JOHAB'? >>This is true only for all the character sets that _we precode into >>XML_. It does not work for any new character set names. The PI looks >>like it has a parameter, but in fact the PI, and its parameter, >>constitute a magic string of bytes with no internal structure. This >>is a bit counterintuitive. I hope the examples above make clear why I think the limits on a processor's ability to identify the name of the encoding in use are a function NOT of the character set names precoded into XML, but of (a) the families of character sets the processor recognizes and (b) the family of character sets to which the particular entity in question actually belongs. >As is explaining to people that you can do: > > > ..... > >but not > > > .... > > .... Well, I may be excessively idealistic, but I had thought "you can't change character encodings in the middle of a file" would do it for most readers, with an occasional "Because the software can't handle it" for the insistent few. For those of us with jaded stylistic palates and too many technical standards under our belts, it might be necessary to have a footnote saying something like "That is, Code extension functions for the ISO 2022 code extension techniques (such as designation escape sequence, single shift and locking shift), and character-encoding labeling functions as defined above, may not be used within the body of XML entities." >>I do not advocate losing the notion. But if it gets intolerable enough, >>maybe we can do the right thing after all! Judging by the response of the WG as a whole, they have already decided the 'right thing' involves installing bozo filters with our names on them. We haven't had a new argument in this discussion for some time, you're not persuading me, I'm not persuading you, and no one in their right mind is listening. Perhaps we should call it a thread and stop. Michael Date: Tue, 22 Oct 1996 19:03:00 -0400 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@w3.org Subject: Re: Non-Unicode characters, SDATA, etc. >So: what applications are going to become severely XML-impaired >if we lack the nice out-of-band SDATA signaling mechanism? Concrete >examples would be the most valuable input. While you could argue that gaiji are not really our concern, it is important to note that in Japan, many, many gaiji exist. As such, many/most publishers will be unable to use XML. Anyway, as I said before, I would prefer attributed entities to SDATA. Date: Tue, 22 Oct 1996 19:07:35 -0400 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results As you rightly noted, you'll not convince me on this: > o It is valuable to include a way for a document, in its own syntax and > in its own encoding, to signal what that encoding is; as a reminder to > the author, as self-defence against incompetent webmasters and > overaggressive conversion services. This is the thing I find to be BAD (Broken As Designed). >But I don't think this makes up for the irritation of having to insert >a header that's in a different syntax and encoding from the rest of the >file. Obviously, external information should be in the correct format >for the external delivery vehicle. Internal information should be in >the syntax and encoding of the document. If it's a header, it should look and act like one, and should *not* be part of the data. Again, let's not revisit the idiocy in , or . Date: Tue, 22 Oct 1996 16:28:54 -0700 (PDT) From: "Deborah A. Lapeyre" Subject: Re: C.15 New methods for attribute defaults? To: Michael Sperberg-McQueen cc: W3C SGML Working Group > > C.15 Should XML define new specific methods of inferring values for > attributes with no attribute-value specifications (11.3.4)? E.g. > INHERITED, to signify that the value is taken from the attribute of > the same name (and type) on the smallest enclosing element with such > an attribute. I have always wanted INHERITED, dreamed of real container-contained database-style inheritance, cursed #CURRENT (now gone!) as much worse than useless. But I vote "no" here, abandoning rather *old* dreams. a) In the interests of reuse, never build in more sequential dependencies that are absolutely necessary. b) This would need more specification than seems wise to prevent really ugly abuses. c) Architectural forms are much cleaner! --Debbie Lapeyre Date: Tue, 22 Oct 1996 21:22:59 -0400 To: w3c-sgml-wg@w3.org Sperberg-McQueen on Sat, 12 Oct 96 15:09:33 CDT) Subject: Re: B.10 Empty elements? From: John_Lavagnino@Brown.edu | B.10 What form should EMPTY elements take, if there are EMPTY elements | in XML: , (where '/' is assumed the NET string) | (7.3, 11.2.3)? Since this question remains open, as far as I can tell, let me just log another favorable response to the idea, which I think was originally advanced by James Clark. It looks and feels more natural than , while also containing the / which suggests end-ness to us all; it doesn't make the user feel irritated the way is going to do; and by differentiating the EMPTY elements even without a DTD it tidily resolves the problem of knowing what's going to have an end-tag and what ain't. John Lavagnino Date: Tue, 22 Oct 1996 21:41:06 -0400 To: w3c-sgml-wg@w3.org Sperberg-McQueen on Thu, 17 Oct 96 13:32:27 CDT) Subject: Re: C.14 Enumerations in attribute declarations? From: John_Lavagnino@Brown.edu | C.14 Should XML allow more than one enumerated type (name-group | declared value) to contain the same possible value (11.3.3)? The enumerated type strikes me as an easy-to-use construct that helps make the act of validation look useful to people; it's natural to use it in a lot of situations, and the only thing that has been a big problem with it in SGML is this prohibition against reusing the values. I think all the other available declared value parameters for special lexical types are of less value than this, especially in an SGML-for-the masses. I can't see the logic of dropping enumerated types entirely on the principle that we want to be absolutely compliant with SGML. Those who want to retain absolute compliance can write XML DTDs that meet the SGML rule---this feature of XML would not create a second of new work for those requiring SGML interoperability. XML DTDs that do exploit this feature are pretty easily converted to SGML, by transforming the lists of enumeration values to NAME. I doubt if that's the hardest task we'll be creating for such XML-to-SGML conversions. John Lavagnino Date: Tue, 22 Oct 1996 22:04:05 -0400 To: w3c-sgml-wg@w3.org Sperberg-McQueen on Mon, 21 Oct 96 09:07:58 CDT) Subject: Re: ERB decisions on A.17, B.9, and other questions From: John_Lavagnino@Brown.edu Michael wrote, regarding suggestions about the handling of SDATA entities: | As to the other proposition, that it is widely understood, I can | only say that if it is widely understood, then surely someone can be | found to describe the behavior on this list explicitly enough that | the rest of us can also understand it. I for one do not understand | the behavior, and would really like a description, preferably with | reference to some documentation. If you encounter an SDATA entity, you: --- take the entity text --- look it up in a table of SDATA-to-local-rendition conversions --- output the string that the table supplies, if there is one --- if not, complain (or not; this part is indeed undefined, but it is possible to mandate some particular behavior) I feel constrained to point out that the approach of using private values from 10646 to denote characters not in this standard set obliges the processor to implement an almost identical procedure. If you encounter such a value, you: --- take the number --- look it up in a table of number-to-local-rendition conversions --- output the string that the table supplies, if there is one --- if not, complain (or not) The idea behind the existence of the private values in the standard is that in your local system you know what they mean and can take appropriate action. Perhaps you've even got a system that uses 10646 as its native character set. But if we're designing a language that is to be used on the net, for which a basic assumption has to be that you don't know much in advance about the capabilities of the target system, then you have to assume that a quite different character set may be used for rendition there; and certainly they can't know about your private use of the private values. As has been said here before, the difference between these two approaches is in what happens if you haven't managed to communicate your eccentric private practices to the document's recipient. In the first case, you might have something of the form "LOOKS LIKE A Q BUT WITH THREE TAILS". In the second, you have a number that is by definition undefined. John Lavagnino Date: Tue, 22 Oct 1996 23:01:47 -0400 To: masonjd@ornl.gov (James David Mason), Michael Sperberg-McQueen From: "David G. Durand" (David G. Durand) Subject: Re: C.14 Enumerations in attribute declarations? Cc: W3C SGML Working Group At 3:59 PM 10/22/96, James David Mason wrote: >I always thought this was a dumb restriction in SGML; I wasn't fond of the >particular bit of minimization it was needed for, either. Let's ditch it >here and see whether WG8 can do likewise. Hear hear! _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Tue, 22 Oct 1996 22:53:09 -0500 From: Len Bullard To: John_Lavagnino@brown.edu CC: w3c-sgml-wg@w3.org Subject: Re: C.14 Enumerations in attribute declarations? John_Lavagnino@brown.edu wrote: > > | C.14 Should XML allow more than one enumerated type (name-group > | declared value) to contain the same possible value (11.3.3)? > > The enumerated type strikes me as an easy-to-use construct that helps > make the act of validation look useful to people; it's natural to use > it in a lot of situations, and the only thing that has been a big > problem with it in SGML is this prohibition against reusing the > values. > > John Lavagnino Also agree. This restriction is the first thing programmers and DTD designers find that fails the stoopid test (yes | no). Change this, please. len Date: Tue, 22 Oct 1996 22:49:15 -0500 From: Len Bullard To: John_Lavagnino@brown.edu CC: w3c-sgml-wg@w3.org Subject: Re: B.10 Empty elements? John_Lavagnino@brown.edu wrote: > > | B.10 What form should EMPTY elements take, if there are EMPTY elements > | in XML: , (where '/' is assumed the NET string) > | (7.3, 11.2.3)? > > Since this question remains open, as far as I can tell, let me just > log another favorable response to the idea, which I think was > originally advanced by James Clark. It looks and feels more natural > than , while also containing > the / which suggests end-ness to us all; it doesn't make the user feel > irritated the way is going to do; and > by differentiating the EMPTY elements even without a DTD it tidily > resolves the problem of knowing what's going to have an end-tag and > what ain't. > > John Lavagnino Of the solutions proposed, this one seems the tidiest. It's disadvantage is it confuses the SGMLer and the HTMLer but it is minor confusion. confuses them a bit let. confuses the parser and slows down the system. Is that about it? len len Date: Tue, 22 Oct 1996 21:57:11 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: Non-Unicode characters, SDATA, etc. Oh yes, Dr. (not Mr.) Poppelier also said: | What we also need is a consistent naming scheme, similar to the SGML | entity sets in ISO Technical Report 9573 (part 13), for the symbols | needed in scientific and technical publishing. Jon Date: Tue, 22 Oct 1996 21:54:09 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: Non-Unicode characters, SDATA, etc. [Tim Bray:] | Anders surprised some of us by pointing out that there are a large | number of ISO entities that are not in ISO 10646 at all. So I'd like | to request input from the WG on this. | | In my personal experience, all the applications I've built and | delivered, based on SGML, HTML, and what would have been XML if it'd | been defined, could have lived perfectly happily using just the | repertoire offered by 10646; the number of non-standard characters was | so small that doing some extra work to package them up would have been | a very minor irritation indeed. | | On the other hand, Anders' posting makes it clear that [particularly | in the area of mathematics] there are routinely a substantial number | of non-10646 characters available [in theory at least] to technical | publishers; who have been a mainstay of SGML support over the years. With some embarrassment (because, like Tim, I have never run into this problem myself, and therefore argued the 80-20 angle when this was before the ERB), I must report that Tim's question has suddenly made an obviously very weak synapse finally fire and retrieved the memory of some correspondence on this very subject that I had mentally misfiled in the garage among the old copies of Harper's and the cabinet full of Canadian barley statistics. I refer specifically to an interchange that I had with Nico Poppelier of Elsevier, the well-known scientific pulishers. I had ignorantly said something to the effect that the math and technical symbols in Unicode appeared to be about all that were needed (which it seems I'm still ignorantly saying; at least I'm consistent on this), to which he replied: | I disagree: the set definitely needs extending. My reference is The | Unicode Standard (Version 1.0, Volume 1), published by the Unicode | Consortium. If I look in the range 2100-26FF I see a lot of symbols | for scientific publishing, but that set is insufficient. A lot of | symbols are missing. Our working group will compile a more or less | comprehensive list from the AMS font set, the Elsevier font set, and | the Mathematica font set, and will compare that against the Unicode | offering. The Elsevier font set is described, including pictures, in | the document | | ftp://ftp.elsevier.nl/pub/sgml/artdoc.ps.gz | | The working group has agreed that scientific and technical publishing | requires | | 1. all openface lowercase letters, uppercase letters and numerals | (Unicode offers only a few commonly used ones) | 2. all fraktur lowercase letters and uppercase letters | (Unicode offers only a few commonly used ones) | 3. all calligraphic lowercase letters and uppercase letters | (Unicode offers only a few commonly used ones) | 4. a large set of symbols as described above. I haven't checked with Mr. Poppelier, but I'm sure that the gentleman won't mind being quoted in a forum where this information might do some good. Jon From: lee@sq.com Date: Wed, 23 Oct 96 01:21:47 EDT To: John_Lavagnino@Brown.edu, w3c-sgml-wg@w3.org Subject: Re: B.10 Empty elements? John_Lavagnino@Brown.edu wrote: > Since this question remains open, as far as I can tell, let me just > log another favorable response to the idea, which I think was > originally advanced by James Clark. It looks and feels more natural > than , while also containing > the / which suggests end-ness to us all; it doesn't make the user feel > irritated the way is going to do; I agree. I admit I still like <@this> best, but would work as well. As would I suppose, which hass a nice imperative feel to it... > and by differentiating the EMPTY elements even without a DTD it tidily > resolves the problem of knowing what's going to have an end-tag and > what ain't. All except the partial-or-implied-but-included DTD suggestions have that property, I think. If there were no attributes, a syntax would be possible like

emphasised text in it.> which gets dangerously close to LISPing to be accepted by the Agnosticks. Similarly, good old Scribe with @nostalgic{stuff like this}. Erik Naggum once sent me an SGML declaration to make @begin(x) ... @end(x) legal, but couldn't also allow @c{....} in the same declaration, I think. But if we change to something too craftily-fashioned, it won't look like SGML or even the SMLG that's used by so many in the congregation, and we shall all be shunned like a Welsh pub during Evensong.

So we look like this.

And then our syntax has a problem with empty elements (that the others I showed needn't have),
/; so we compromise. It's important to try and see where compromise is acceptable, and where it will lead to failure. If the drummer is in 2, the sax is in Gflat m, and the violin is doing a waltz in A, we can all compromise on a tango in D flat minor, but we can't compromise on 2/3 in Gflat-and-a-half, and we all have to end up playing the same tune. Modulo counterpoint, OK. So we can use and understand that existing SGML parsers will break, but w'll try and fix that by changing SGML and hope that at least some of the commercial SGML parsers are updated -- maybe most of them. (or can this be done without breaking things? I don't see how, although if James said it could, he is right, and I have just forgotten!) (oh, OK, a shortref or datatag mapping to > perhaps?) Any of <@emp>, /, , require at the very least a change to the SGML declaration, but as we've already increased NAMELEN that's probably OK. Not all things can be changed in today's commercial SGML parsers; some of them are more flexible than others. Some basically ignore the SGML declaration altogether (e.g. Panorama), although I shouldn't be surprised if we modify Panorama to handle XML in some way anyway. You could say that if a given product doesn't support all of whatever one thinks of as the basic set of SGML features (e.g. if its SGML feature set number has too few bits set) tht it isn't an SGML application. If SGML were simpler, more applications would conform -- hence the need for XML. It's thus not clear to me -- and has never been clear to me in these discussions -- how much importance to give to "existing SGML applications can read the data" vs. "existing sGML applications can be tweaked or modified to read the data". If you need to change the SGML declaration, chances are you'll break most of the different existing SGML parsers in use today -- although not most installations, a a few parsers count for most installations -- James' SP and SoftQuad's (in HoTMetaL and A/E) might be the most widespread, with Synex (ViewPort) -- although Synex don't claim to use a validating parser -- probably next. Those numbers are high because of the web; I'd put EBT up there except that I think most of the DynaBooks out there are reading the compiled format, and of course several other vendors are represented on this list, or are well known in the SGML community. So maybe all those parsers can be changed, where they don't already handle changing delimiters (they certainly don't all handle SHORTREF, DATATAG, SUBDOC, CONCUR and LINK). Michael, John (if you're still here after so much incoherence) -- is that a fair question? I'm not sure if it's appropriate for this list, but presumably no-one in the SGML world is yet committed to doing any implementation work for XML. Is it worth investigating who is prepared to do (very roughly) how much? I'd rather not do that, since I'm not exactly independent from SGML vendors...! Lee -- Liam Quin, lee@sq.com | lq-text freely available Unix text retrieval Senior Technical Consultant | FAQs: Metafont,OPEN LOOK UI,OpenWindows SoftQuad Inc. +1 416 544-9000 | xfonttool (Unix xfontsel in XView) http://www.softquad.com./ http://www.softquad.co.uk./ From: lee@sq.com Date: Wed, 23 Oct 96 01:43:46 EDT To: John_Lavagnino@brown.edu, cbullard@HiWAAY.net Subject: Re: B.10 Empty elements? Cc: w3c-sgml-wg@w3.org > Of the solutions proposed, this one seems the tidiest. > It's disadvantage is it confuses the SGMLer and the HTMLer > but it is minor confusion. confuses them a bit > let. confuses the parser and slows down the system. > > Is that about it? Thre's also or <@whimper>. Oh, I see -- is done by changing the net delimiter and only needing one of them, and the asumption is that the SGML application will have a pre-processor to generate the DTD and SGML declaration at the same time. OK. That pre-processor could just as easily change the instance to I suppose, though. Clearly without a DTD an SGML parser is going to lie on its back and wiggle its poor deranged paws in the air or wet itself, so people will have to use programs to make DTDs from XML documents -- there is zero (nil) hope that an unmodified SGML application can read an XML file. Lee Date: Wed, 23 Oct 1996 02:27:19 -0500 To: "David G. Durand" (David G. Durand) From: Robert Streich Subject: Re: C.16 Behavior when DTD is incomplete? Cc: W3C SGML Working Group At 10:54 PM 10/17/96 -0400, David G. Durand" (David G. Durand wrote: >Implicit CDATA. There's no benefit in leaving this undefined, and being >smart about it will just make worse trouble. Of course, "id" will already >be a fixed, undeclared, universally accessible attribute anyway; so the >"smartness" doesn't get you much. I agree with the CDATA default. Because ID/IDREF is an important concept, I would like to see default names for them so that they could be processed as something other than CDATA. I don't care too much about the names, but brevity would be preferred. Even NAME and HREF work for me. bob Robert Streich streich@slb.com Schlumberger voice: 1 512 331 3318 Austin Research fax: 1 512 331 3760 Date: Wed, 23 Oct 1996 02:28:06 -0500 To: "David G. Durand" (David G. Durand) From: Robert Streich Subject: Re: C.12 types of declared values for attributes? Cc: W3C SGML Working Group , W3C SGML Working Group At 11:23 AM 10/18/96 -0400, David G. Durand" (David G. Durand wrote: >I never understood why I needed more than one unique identifier for an >element: that's why the SGMl syntax never bothered me. If Eve and Lee both >think it's useful, I'll defer to their judgement (though I'd love an >example). I agree wholeheartedly with Eve and Lee--multiple IDs are useful. I can't remember what I needed them for the last time, I guess it's past my bedtime. I rememember that I was trying to duplicate the linkages that a DMS used between its records because it was very easy to generate the SGML from the report generator. In the end, I didn't use any IDs anyway since I couldn't assure that they would be valid NAMEs anyway. Didn't matter, the browser allowed me to make the links anyway. But, I bet you like symbolic links, don't you? Same principles. With current SGML implementations, an ID is best if the name is meaningful, but names are only appropriate to a given context. If you can have two meaningful names, you can address the needs of two discrete contexts. bob Robert Streich streich@slb.com Schlumberger voice: 1 512 331 3318 Austin Research fax: 1 512 331 3760 Date: Wed, 23 Oct 1996 02:26:58 -0500 To: Tim Bray From: Robert Streich Subject: Re: ERB decisions on A.17, B.9, and other questions Cc: w3c-sgml-wg@w3.org At 07:56 PM 10/20/96 -0700, Tim Bray wrote: >His second concern is vastly overblown. Given the use of the 10646 >repertoire, the population of characters that are needed but undefined >falls dramatically - those that do appear are either > > a) so exotic that a bit of extra work in encoding them seems a minor > concern, or > b) really graphics in disguise, like for example a Xerox trademark. Hmmm, how can I sum up my feelings for this comment in a nice polite manner.... Ahhh, BULL! As Anders has pointed out, there is rather poor support in Unicode for Math. I don't yet have all of the details as I haven't gotten my Unicode books yet, but from what I have seen so far, it isn't adequate for the relatively simple yet extensive math that we have in our docs. The one obvious one that jumped out at me was that there didn't seem to be any way to differentiate script, open face, and Fraktur letters. By the way, I concur wholeheartedly with the opinions expressed by David and Lee. There are plenty of times when I could predict that the receiving system will not be able to render the character that I want them to see. Given that, a reasonable description of the character *could* suffice. Some meaningless number, would be just that-- meaningless. bob Robert Streich streich@slb.com Schlumberger voice: 1 512 331 3318 Austin Research fax: 1 512 331 3760 Date: Wed, 23 Oct 1996 02:27:09 -0500 To: Michael Sperberg-McQueen From: Robert Streich Subject: Re: ERB decisions on A.17, B.9, and other questions Cc: W3C SGML Working Group At 09:07 AM 10/21/96 CDT, Michael Sperberg-McQueen wrote: >Here's a confession that if this behavior is widely implemented, I >haven't seen it in the software I use most frequently. Perhaps I >just don't read the manuals carefully enough, but the only program >that comes to mind as describing any behavior like this is Panorama, >and its functionality (rendering correctly all the characters in the >ISO entity sets for which the local system has font resources) can >be done with character references to ISO 10646, since all the >characters in the ISO entity sets are in 10646 (some glyphs >representing ligatures are missing). Since I don't know what tools you use, Michael, I can't contradict you, but I can say that the replacement text is used with all the tools that I use daily, including the ones that I wrote. For a transform to Interleaf, the replacement text is the necessary Interleaf markup for that character; for a transform to HTML, it is an IMG tag with the URL to a library of GIF images that I created from TeX. >As to the other proposition, that it is widely understood, I can >only say that if it is widely understood, then surely someone can be >found to describe the behavior on this list explicitly enough that >the rest of us can also understand it. I for one do not understand >the behavior, and would really like a description, preferably with >reference to some documentation. The behavior is really up to the application: it is system data, thus essentially the same as a system identifier. It is up to the system to determine what to do with it. bob Robert Streich streich@slb.com Schlumberger voice: 1 512 331 3318 Austin Research fax: 1 512 331 3760 Date: Wed, 23 Oct 1996 02:27:14 -0500 To: Tim Bray From: Robert Streich Subject: Re: Non-Unicode characters, SDATA, etc. Cc: W3C SGML Working Group At 02:50 PM 10/22/96 -0700, Tim Bray wrote: >So: what applications are going to become severely XML-impaired >if we lack the nice out-of-band SDATA signaling mechanism? Concrete >examples would be the most valuable input. 95% of the documents that I deal with now have extensive math in them. If I had the right tables I could tell you more specifically how many of them contain characters not in Unicode. I have to admit that I could continue to do the same thing with them as I do now: run them through TeX (I still find it hard to believe how dependent I am on that wonderful life saver) and render them as GIF, but if I'm stuck with that then there's one more thing that I don't get from XML that it seems HTML will provide for....hmmmmm. bob Robert Streich streich@slb.com Schlumberger voice: 1 512 331 3318 Austin Research fax: 1 512 331 3760 Date: Wed, 23 Oct 1996 02:28:53 -0500 To: Michael Sperberg-McQueen From: Robert Streich Subject: Re: C.14 Enumerations in attribute declarations? Cc: W3C SGML Working Group At 10:07 AM 10/18/96 CDT, Michael Sperberg-McQueen wrote: >At the very least, when we adopt rules not on their technical merits but >solely to preserve compatibility with 8879, even in cases where 8879's >rule is now generally conceded to be a Bad Thing, I think the spec >should introduce the feature with the phrase "For compatibility >reasons ... " -- as in "For compatibility reasons, the string '--' >(double hyphen) is not allowed within comments." WG8 members can then >read the XML spec with a clear idea of where an XML rule was adopted >because it seemed a good one, and where it was adopted solely for >the sake of compatibility with 8879:1986 and will gladly be changed >when the revision sets things right. I agree. Although I very much want this behavior so that I don't have to explain to people why they have to use 1s and 0s in CALS table markup, I think we should defer it to a future version of XML once the SGML revision has been completed. Robert Streich streich@slb.com Schlumberger voice: 1 512 331 3318 Austin Research fax: 1 512 331 3760 From: "Henry S. Thompson" Date: Wed, 23 Oct 96 09:54:51 BST To: Michael Sperberg-McQueen Subject: Re: B.1 and B.2 results Cc: W3C SGML Working Group Well, I HAVE been listening, and although a bit impatient with the testiness on both sides from time to time, think there is a real point on both sides, and that by simply proceeding (and implicitly ignoring David and Gavin) the ERB would be making a technical as well as a strategic error. In particular, I think Tim is at least misleading to say 'the smokescreen about "it's the entity not the file" is just that'. David's observation that "[Since] SGML has the general notion of an entity manager, the notion of an entity header on the storage object fits right into the SGML model" seems to me to be exactly right. Step back a minute and think what you expect the command line argument to a Unix-based XML tool to be -- a filename? a filename or a URL? a filename or a URL or an FPI? Well obviously, it's going to be, implicitly or explicitly, just as for SP-based applications already, an SGML Open entity specifier, that is, any of the above. Which means that rudimentary entity access management is a necessary part of any XML application, and for entities of type OSFILE that means finding the header information on the front thereof. Is that really so bad? ht From: "Henry S. Thompson" Date: Wed, 23 Oct 96 10:00:28 BST To: lee@sq.com Subject: Re: B.10 Empty elements? Cc: W3C SGML Working Group I have to say I think in the context of the decisions about valid vs. [whatever -- my archive is temporarily inaccessible -- you know, processable] XML, there is no reason not to say that empty elements are notated exactly as they are in SGML, i.e. , and that w/o (partial) DTD information, empty elements will cause errors, i.e. empty elements are allowed iff the necessary declaration fragment is present. ht Reference concrete syntax means just that: NO NEW SYNTAX Date: Wed, 23 Oct 1996 12:29:57 +0100 To: Michael Sperberg-McQueen From: haitto@synex.se (Hasse Haitto) Subject: Re: B.1 and B.2 results Cc: W3C SGML Working Group , mail@synex.se Michael Sperberg-McQueen wrote: ... >Quick quiz: out of the members of the WG currently reading this >(both of you!), how many might be able to tell their browser how to >take corrective action if they knew the unreadable material was in >something called 'ebcdic-cp37'? How about 'JOHAB'? I'm not sure what you mean by 'corrective action', but using our toolkit engine Synex ViewPort you can integrate a notation processor, and process the data--assuming its type and extent are known and, as I recall, the notation being an external entity, but don't quote me on that ;-). Inline integration of the notation (using ViewPort widgets, a general plug-in architecture) is possible. You cannot however toggle the parser processing from the SGML declaration. Cheers, Hasse -- Synex Information AB Phone: +46 8 791 88 81 Stora Nygatan 20, 1tr Fax: +46 8 791 88 89 111 27 Stockholm Internet: haitto@synex.se Sweden WWW: http://www.synex.se Date: Wed, 23 Oct 96 08:46:06 CDT From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results > From: "Henry S. Thompson" > Date: Wed, 23 Oct 96 09:54:51 BST > > David's observation that "[Since] SGML has the general notion of an > entity manager, the notion of an entity header on the storage object > fits right into the SGML model" seems to me to be exactly right. Step > back a minute and think what you expect the command line argument to a > Unix-based XML tool to be -- a filename? a filename or a URL? a > filename or a URL or an FPI? Well obviously, it's going to be, > implicitly or explicitly, just as for SP-based applications already, an SGML > Open entity specifier, that is, any of the above. Which means that > rudimentary entity access management is a necessary part of any XML > application, and for entities of type OSFILE that means finding the > header information on the front thereof. Is that really so bad? I must be in possession of a different set of data. In my book, "osfiles" have no header information, and the "storage object identifier" on the right hand side of an SGML Open TR9401 catalog is the name of a file, all bytes of which gets sent to the SGML parser. So, I would expect most existing SGML systems would need to be modified to process files that are "headed" by data that are not supposed to be sent to the SGML parser. From: Anders Berglund Date: Wed, 23 Oct 96 10:05:22 EDT To: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org Subject: Re: Non-Unicode characters, SDATA, etc. Cc: alb@ebt-inc.ebt.com Addition to Jon's quote from Elsevier: And to make matters worse - 9573-13 contains a few hundred symbols on top of the Elsevier set that are used by other scientific publishers... Anders Date: Wed, 23 Oct 1996 08:51:11 -0700 (PDT) From: "Deborah A. Lapeyre" Subject: Re: C.12 types of declared values for attributes? To: Robert Streich cc: "David G. Durand" , W3C SGML Working Group , W3C SGML Working Group IFF Decalred Value ID is retained, please yes to multiple IDs for a single element. --dal ======================================================================= Deborah A. Lapeyre Phone: 301-231-6933 Mulberry Technologies, Inc. Fax: 301-231-6935 6010 Executive Blvd. Suite 608 E-mail: dlapeyre@mulberrytech.com Rockville, MD USA 20852 ======================================================================= Date: Wed, 23 Oct 1996 11:34:15 -0400 (EDT) To: w3c-sgml-wg@w3.org Subject: Re: B.10 Empty elements? From: John_Lavagnino@Brown.edu Since the question has come up about how to get the notation for EMPTY elements to work in SGML, here is the example I wrote when I was wondering the same thing. (This allows /> to close start-tags even if they're not EMPTY, of course; restricting it to EMPTY tags would have to be an XMLism.) The crucial points are changing NET in the DELIM section, and using SHORTTAG YES. John Lavagnino " SHORTREF SGMLREF NAMES SGMLREF QUANTITY SGMLREF FEATURES MINIMIZE DATATAG NO OMITTAG YES RANK NO SHORTTAG YES LINK SIMPLE NO IMPLICIT NO EXPLICIT NO OTHER CONCUR NO SUBDOC NO FORMAL NO APPINFO NONE> ]> Here's an ordinary empty tag: , and then one with a tricky NET: , as a test. Date: Wed, 23 Oct 1996 08:45:27 -0700 (PDT) From: "Deborah A. Lapeyre" Subject: Re: B.10 Empty elements? To: Len Bullard cc: John_Lavagnino@brown.edu, w3c-sgml-wg@w3.org 1) I still prefer and have seen no logical arguments to convince me otherwise. Yes, it makes it impossible to distinguish between events and lack of content. That is NOT a showstopper for me. 2) Failing that, ANY system that marks them, and is internally symetrical will do. By symetry, I mean that it starts and ends with the same character. I mean that , , , and #r# are fine and " To: "Deborah A. Lapeyre" CC: John_Lavagnino@brown.edu, w3c-sgml-wg@w3.org Subject: Re: B.10 Empty elements? Deborah A. Lapeyre wrote: > > 1) I still prefer and have seen no logical arguments to > convince me otherwise. Yes, it makes it impossible to distinguish > between events and lack of content. That is NOT a showstopper > for me. Nor I. This is one that comes down to taste, speed and difficulty to code. So, pick one and move on. I accept the will of the programmers (like we have a choice, ya know). len Date: Wed, 23 Oct 96 10:14:33 CDT From: Michael Sperberg-McQueen Subject: Re: ERB decisions on A.17, B.9, and other questions To: John Lavagnino , W3C SGML Working Group [Summary: John Lavagnino's note clarifies some SDATA issues but also illustrates variations in descriptions of the right SDATA behavior. Discussion of four cases: character in / not in ISO 10646, character known/not known to application. SDATA seems to offer some (small) advantages for unknown characters, text entities some (small) advantages for known characters. Reference to 8879.] On Tue, 22 Oct 1996 22:05:04 -0400 John Lavagnino said: >If you encounter an SDATA entity, you: > >--- take the entity text >--- look it up in a table of SDATA-to-local-rendition conversions >--- output the string that the table supplies, if there is one >--- if not, complain (or not; this part is indeed undefined, but it is > possible to mandate some particular behavior) This is a very clear account, and I thank John for providing it. It should be noted, however, that this is not quite the same as what has been described to me in private mail by other proponents of SDATA, who say when you encounter an SDATA entity you: --- inform the application that an SDATA entity is beginning --- pass the application the entity text (and perhaps its name) --- inform the application that the SDATA entity is ending I.e. you perform *no* lookup, you merely provide the application with the power to perform lookup. (I'm assuming that 'you' is the XML processor; if John is assuming it's the client application, the two views are compatible. On this interpretation, John's account of application behavior does assume that SDATA entity boundaries are visible to applications, which is a common usage but not one required by 8879, as far as I can tell.) If we assume that 'including SDATA in XML' means specifying the behaviors above for the XML processor (normatively) and XML applications (informatively), plus defining some convention for specifying the replacement text so as to ensure it's not just another character number, then it seems to me the cost/advantage tradeoff has four cases, depending on whether the character is or is not in ISO 10646, and whether the application does or does not understand it. 1. An ISO 10646 character known to the application: vs. or The text entity provides all the information a conforming application needs. Applications which display text must maintain a Unicode-to-local mapping table, unless they have Unicode display drivers (which effectively embody such tables). The SDATA method requires each application to maintain a table of SDATA-entity-text to character value or display value, or both. Since the application must accept Unicode directly, it must also maintain the same tables as for the text entity. 2. An ISO 10646 character unknown to the application: The text entity provides only a Unicode code point; the SDATA entity provides either a quasi-mnemonic identifier or a full SC2-style character name. For fallback processing, the text-entity user must rely on display-specific sets of entity declarations -- unfortunately, without public identifiers these cannot be reliably labeled. The SDATA user can use the entity text (or name, if provided) to generate fallback display text. Text-entity applications must either provide less informative error (or I-can't-display-this) messages, or else maintain a table mapping Unicode code points to names. SDATA applications can use the entity text to provide an error message referring to "auml" or "latin small letter a with diaeresis", which is at least as informative as "character U+00E4". mapping table. 3. A non-ISO-10646 character known to the application: vs. or In both cases, private arrangements of a form not covered by the XML spec are required. In the SDATA case, these might take the form of the user modifying the application's local lookup table to add the desired characters; in the text entity case, they might take a similar form, though the lookup table might look different. The SDATA method seems to involve a slightly lower chance of accidental collisions arising when private agreements inadvertently use the same name or character position, and thus may have less need of mechanisms to signal the applicability of this or that private agreement. 4. A non-ISO-10646 character unknown to the application: Same as case 2, except that the user presented with only a code point cannot find out, by consulting ISO 10646 or Unicode documentation, what character is involved. ----- On the whole, it seems to me that SDATA provides some advantages over text entities in cases 2 and 4; this is what I understand David and Lee and John to be arguing as well. It seems to me that text entities have the advantage in cases 1 and 3; I don't know if the other participants in the discussion will take this view or not. In neither case do the advantages seem to me to be extremely large; they could easily be outweighed by other considerations (as indeed they were, in the ERB discussion). The key points appear to be - is the advantage in various cases large or small? - which cases are more important for the design of XML? For what it's worth, here is the only passage I've found in 8879 which seems to bear on this issue (clause 8): A processing instruction that returns data must be defined as an "SDATA" entity and entered with an entity reference. One that does not return data should be bedfined as a "PI" entity. >From this (and from no other passage) I infer that SDATA entities can 'return data' -- this seems an apt description of the SDATA behavior being described by John Lavagnino and others, except that in his commentary, Charles Goldfarb seems to be assuming that the SGML parser is to do the lookup, while in current practice SGML parsers do no such lookup, but provide enough information to allow a downstream application to do the lookup. The text of 8879 seems (to this reader) not to specify who does the lookup. -C. M. Sperberg-McQueen Date: Wed, 23 Oct 1996 11:08:31 -0700 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: B.10 Empty elements? At 08:45 AM 10/23/96 -0700, Deborah A. Lapeyre wrote: >3) Far last choice is the current SGML situation, which confuses >new users, is hard to teach, and (stack or no stack) is not pretty to parse. 18 months ago, I would have agreed. Now, there are many millions of people who have got used to and
and
and so on. Technically, I *prefer* . But I'm going to vote for SGML/HTML interoperability. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Wed, 23 Oct 1996 11:13:04 -0700 To: gtn@ebt.com (Gavin Nicol) From: Tim Bray Subject: Re: Non-Unicode characters, SDATA, etc. Cc: w3c-sgml-wg@w3.org At 07:03 PM 10/22/96 -0400, Gavin Nicol wrote: >>So: what applications are going to become severely XML-impaired >>if we lack the nice out-of-band SDATA signaling mechanism? > >While you could argue that gaiji are not really our concern, it >is important to note that in Japan, many, many gaiji exist. Footnote: gaiji are ad-hoc kanji; that is to say, brand-new Chinese-style characters created for proper name or corporate use. [Why can't we do this in English? Just 26 characters is so, y'know, pedestrian, and limits *my* creative expression every day.] Gaiji are not exactly ubiquitous, but quite commercially important. Sigh. Date: Wed, 23 Oct 1996 15:14:48 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: B.10 Empty elements? At 11:08 AM 10/23/96, Tim Bray wrote: >18 months ago, I would have agreed. Now, there are many millions of >people who have got used to and
and
and so on. > >Technically, I *prefer* . But I'm going to vote for SGML/HTML >interoperability. HTML compatibility is a very good argument. (close to knock-down, drag-out, to me). What I don't like is that the format requires a DTD for XML processing (or partial DTD, which seems confusing to me), and does not. I think the foreign syntax is easy to justify given the elimination of the need for any DTD information. Easier than the explanation that you have to declare "just one little thing" if you don't have a DTD, but do use empty elements. Your mileage may vary. -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Wed, 23 Oct 1996 15:14:52 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: non-reportable errors I haven't gotten a rise out of anyone with this, but I will make a last try. Several people have told me off-list that the reason for non-reportable errors is so people who don't care about SGML compatibility need not implement it. If this is the case, I would rather that we add an explicit notion of an "SGML compatibility warning." XML parsers would be recommended, but not required, to issue these for things like -- in comments and ambiguous content models. I would rather have plain language that reflects out intent, than language which, when properly decoded, reflects our intent. The terms error and warning are well established in the compiler community (as is the fact that ignoring warnings can cause you real trouble). Let's use them. -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html From: lee@sq.com Date: Wed, 23 Oct 96 15:31:18 EDT To: John_Lavagnino@brown.edu, w3c-sgml-wg@w3.org, U35395@UICVM.UIC.EDU Subject: Re: ERB decisions on A.17, B.9, and other questions > (I'm assuming that 'you' is the XML processor; if John is assuming > it's the client application, the two views are compatible. On this > interpretation, John's account of application behavior does assume > that SDATA entity boundaries are visible to applications, which is a > common usage but not one required by 8879, as far as I can tell.) None of ESIS is mandated by 8879 as far as I know. I have generally assumed that the XML specification will go much further than specifying just the syntax of the language, and hence (in any normal non-SGML terminology) will affect more than just the parser. > 1. An ISO 10646 character known to the application: > > vs. > > or > The following two make more sense to me: and I'd hope XML could allow both of them. > Applications which display text must maintain a > Unicode-to-local mapping table, unless they have Unicode display > drivers (which effectively embody such tables). Or they can use the numbers, if they are more useful. But they will still need to cope with �x4486;�x030C;, which is OLD HANGUL SYLLABLE MIEUM-ALAE A-GIYEOG LIEUL with a CARON accent over it, if they're going for strict conformance. So the application at least needs to know which code points are to be treated as non-spacing accents. > 2. An ISO 10646 character unknown to the application: > > The text entity provides only a Unicode code point; the SDATA entity > provides either a quasi-mnemonic identifier or a full SC2-style > character name. > > For fallback processing, the text-entity user must rely on > display-specific sets of entity declarations -- unfortunately, > without public identifiers these cannot be reliably labeled. If there were public identifiers for the unknown glyphs, they probably wouldn't need to be unknown! Ask someone like Glenn Adams or bc Krishna of FutureTense about this... > The > SDATA user can use the entity text (or name, if provided) to > generate fallback display text. Yes. This is the difference -- whether you get meaningless in the failure case or whether you get something you can use. A [less than with tilde under it] B can be read immediately and understood by milions of people the world over. A &0x60000020; B cannot be read by anyone. (this is character 0x20 (32 decimal) in row 0 of plane 0 in group 0x60, the first Private Use group; this is the lowest code point that is generally available, unless you use the 8192 positions in plane 0 of group 0 that are in the R-zone.) > 3. A non-ISO-10646 character known to the application: > > vs. > > or > > > In both cases, private arrangements of a form not covered by the XML > spec are required. Not if the XML spec handles this case. > The SDATA method seems to involve a slightly lower chance of > accidental collisions arising when private agreements inadvertently > use the same name or character position, and thus may have less need > of mechanisms to signal the applicability of this or that private > agreement. Yes. > 4. A non-ISO-10646 character unknown to the application: > > Same as case 2, except that the user presented with only a code > point cannot find out, by consulting ISO 10646 or Unicode > documentation, what character is involved. Yes. > On the whole, it seems to me that SDATA provides some advantages > over text entities in cases 2 and 4; this is what I understand David > and Lee and John to be arguing as well. Yes. The whole system becomes completely unusable with just numbers, if you are working with anything outside the spec. Latin scribal abbreviations might be too obscure to bother with, as might mathematical symbols, since mathematicians will continue to use TeX, I expect. > In neither case do the advantages seem to me to be extremely large; Well, when a system can't do what you need it to do at all, you don't use it. If we restrict ourselves to a subset of those documents that can be handled by HTML, the advantages are vanishingly small. But why not just use HTML for that? Lee Date: Wed, 23 Oct 1996 15:34:27 -0400 From: gtn@ebt.com (Gavin Nicol) To: streich@slb.com CC: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: Non-Unicode characters, SDATA, etc. >I have to admit that I could continue to do the same thing with them as I >do now: run them through TeX (I still find it hard to believe how >dependent I am on that wonderful life saver) and render them as GIF, but >if I'm stuck with that then there's one more thing that I don't get from >XML that it seems HTML will provide for....hmmmmm. HTML doesn't do anything at all here, because it doesn't have subdecl's and the character repertoire is the same - ISO 10646. I guess what you mean is that this is another problem that XML will not solve any better than current HTML - based solutions. BTW. SDATA, or something like it, is crucial to the idea for font services that I have -- we do need a way of specifying "type" for entities. Date: Wed, 23 Oct 1996 15:30:25 -0400 From: gtn@ebt.com (Gavin Nicol) To: streich@slb.com CC: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions >By the way, I concur wholeheartedly with the opinions expressed by >David and Lee. There are plenty of times when I could predict that >the receiving system will not be able to render the character that I >want them to see. Given that, a reasonable description of the character >*could* suffice. Some meaningless number, would be just that-- >meaningless. People other than David and Lee have this viewpoint. The problem above is what led me to the GCR and GGR ideas a couple of years ago. Date: Wed, 23 Oct 1996 20:23:38 +0000 To: Michael Sperberg-McQueen From: James Clark Subject: Re: ERB decisions on A.17, B.9, and other questions Cc: John Lavagnino , W3C SGML Working Group At 10:14 23/10/96 CDT, Michael Sperberg-McQueen wrote: > Applications which display text must maintain a >Unicode-to-local mapping table, unless they have Unicode display >drivers (which effectively embody such tables). I think it's worth noting that both Windows 95 and Windows NT have such a driver (ie you can feed Unicode characters to TextOut). >2. An ISO 10646 character unknown to the application: >Text-entity applications must either provide less informative error >(or I-can't-display-this) messages, or else maintain a table mapping >Unicode code points to names. SDATA applications can use the entity >text to provide an error message referring to "auml" or "latin small >letter a with diaeresis", which is at least as informative as >"character U+00E4". mapping table. An XML parser could report to an application the starts and ends of entities together with the entity name. When an application encounters an unknown character occuring in a text entity whose content is a single character, it could use the name of that entity in the error message. In other words given an intelligent XML-based application could give an error message referring to character entity "auml". James From: "Henry S. Thompson" Date: Wed, 23 Oct 96 20:59:18 BST To: paul@arbortext.com (Paul Grosso) Subject: Re: B.1 and B.2 results Cc: w3c-sgml-wg@w3.org paul@arbortext.com (Paul Grosso) writes > > ... > > rudimentary entity access management is a necessary part of any XML > > application, and for entities of type OSFILE that means finding the > > header information on the front thereof. Is that really so bad? > > I must be in possession of a different set of data. > > In my book, "osfiles" have no header information, and the "storage > object identifier" on the right hand side of an SGML Open TR9401 catalog > is the name of a file, all bytes of which gets sent to the SGML > parser. So, I would expect most existing SGML systems would need to > be modified to process files that are "headed" by data that are not > supposed to be sent to the SGML parser. Sorry, I was too elliptical It would make sense to have a new type, for the sake of argument HOSFILE, which would be the default if you didn't provide a type, meaning OSFILE with prefix header to be processed and NOT set to the XML application as data. The option to provide an explicit type would allow you to use OSFILE as you point out it is specified, with the additional requirement for XML that the default encoding is implied for type OSFILE (and any other type without provision for out-of-band meta information). ht Date: Wed, 23 Oct 1996 16:01:24 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: ERB decisions on A.17, B.9, and other questions At 10:14 AM 10/23/96, Michael Sperberg-McQueen wrote: >[Summary: John Lavagnino's note clarifies some SDATA issues but >also illustrates variations in descriptions of the right SDATA >behavior. Discussion of four cases: character in / not in ISO >10646, character known/not known to application. SDATA seems to >offer some (small) advantages for unknown characters, text entities >some (small) advantages for known characters. Reference to 8879.] [summary: Apparent variation in behavior probably not intended by Lavagnino, confirming alternate intepretation mentioned by Michael. Re-analysis of the four cases in terms of when SDATA should sensibly be used. Advantages now considered only for non ISO-10646 characters. In reply to Michael's two mentions of 8879 on SDATA, I cite the ESIS proposal, the most-widely implemented model of what an SGML implementation returns, and its definition of SDATA processing.] >This is a very clear account, and I thank John for providing it. > >It should be noted, however, that this is not quite the same as what >has been described to me in private mail by other proponents of >SDATA, who say when you encounter an SDATA entity you: > > --- inform the application that an SDATA entity is beginning > --- pass the application the entity text (and perhaps its name) > --- inform the application that the SDATA entity is ending > >I.e. you perform *no* lookup, you merely provide the application >with the power to perform lookup. >(I'm assuming that 'you' is the XML processor; if John is assuming >it's the client application, the two views are compatible. On this >interpretation, John's account of application behavior does assume >that SDATA entity boundaries are visible to applications, which is a >common usage but not one required by 8879, as far as I can tell.) I talked with John the other day, and he was describing, I think, what a reasonable application does, lumping parser and application behavior together as you note inyour parenthesis. XML should prescribe a lookup table as described by John. SGML does not. As for the point that SDATA entities should be visible to the application, I will cite the ESIS spec, in Goldfarb, Appendix B, on page 592, point "j)" I know that ESIS is not normative text, but it is very widely viewed as the _minimal_ information available to an SGML-driven application. " j) References to internal entities The information passed to the application depends on the entity type: SDATA Replacement text, identified as an individual SDATA entity. PI Replacement text, identified as a processing instruction, but not as an entity. For other references, nothing is passed to the application." I think this supports my contention that SDATA entities are application visible, and among the few entities that are application visible at all, excepting external SUBDOC and DATA entities. > ....the cost/advantage >tradeoff has four cases, depending on whether the character is or is >not in ISO 10646, and whether the application does or does not >understand it. >Cases 1 + 2 (The ones concerning known ISO 10646 characters deleted) SDATA usage could not be prevented for such characters, if SDATA entities are available, but it should be deprecated and never implemented. _I_ am certainly not proposing that SDATA should ever be used for any character that has an ISO 10646 code outside of the private use area. It is the application's job to handle 10646, and we should keep that in their ballpark. >3. A non-ISO-10646 character known to the application: > > vs. > > or > >In both cases, private arrangements of a form not covered by the XML >spec are required. In the SDATA case, these might take the form of >the user modifying the application's local lookup table to add the >desired characters; in the text entity case, they might take a >similar form, though the lookup table might look different. >The SDATA method seems to involve a slightly lower chance of >accidental collisions arising when private agreements inadvertently >use the same name or character position, and thus may have less need >of mechanisms to signal the applicability of this or that private >agreement. Michael lists this as a case where character codes have an advantage. I'm not sure why. To me using mnemonic names to identify things is always better than using numbers to identify things. I think the chance of collisions between private use character codes are relatively high, since the simplest approach is to start with the first private use character and go up from there. I think private use always requires an explicit notification of convention, unless we assume that groups of individuals only process documents by others who use the same private character sets. >4. A non-ISO-10646 character unknown to the application: > >Same as case 2, except that the user presented with only a code >point cannot find out, by consulting ISO 10646 or Unicode >documentation, what character is involved. >In neither case do the advantages seem to me to be extremely large; >they could easily be outweighed by other considerations (as indeed >they were, in the ERB discussion). What were these other considerations? >The key points appear to be > > - is the advantage in various cases large or small? I think seeing an unknown character number message will be as annoying as seeing an image with no "alt" tag is on the web. > - which cases are more important for the design of XML? Mathematics, Asian Literary texts, and Asian commercial texts all seem to have this problem with 10646. Are these imporatant cases? -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Wed, 23 Oct 1996 16:10:43 -0400 From: gtn@ebt.com (Gavin Nicol) To: paul@arbortext.com CC: w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results >In my book, "osfiles" have no header information, and the "storage >object identifier" on the right hand side of an SGML Open TR9401 catalog >is the name of a file, all bytes of which gets sent to the SGML >parser. So, I would expect most existing SGML systems would need to >be modified to process files that are "headed" by data that are not >supposed to be sent to the SGML parser. I would say that most, if not all parsers actually have the SO passing through an entity manager before it get's passed on to the parser. From: lee@sq.com Date: Wed, 23 Oct 96 16:27:43 EDT To: U35395@UICVM.UIC.EDU, jjc@jclark.com Subject: Re: ERB decisions on A.17, B.9, and other questions Cc: John_Lavagnino@brown.edu, w3c-sgml-wg@w3.org > I think it's worth noting that both Windows 95 and Windows NT have such a > driver (ie you can feed Unicode characters to TextOut). True -- does it handle the combining characters now? > In other words given > > > > an intelligent XML-based application could give an error message referring > to character entity "auml". Also true, although given what does it do? Unknown character 246 in entity Jakob is better than Unknown character 246 I agree, just as unknown image: jakob.gif is better than Unsupported image type or file not found but both are worse than missing image file jakob.gif [box of cream crakckers] HTML wins here with ALT for images. Let's follow that lead with ALT for images of characters. Lee Date: Wed, 23 Oct 1996 17:02:15 -0400 From: gtn@ebt.com (Gavin Nicol) To: lee@sq.com CC: John_Lavagnino@brown.edu, w3c-sgml-wg@w3.org, U35395@UICVM.UIC.EDU Subject: Re: ERB decisions on A.17, B.9, and other questions >Yes. The whole system becomes completely unusable with just numbers, >if you are working with anything outside the spec. Lee is 100% correct here. Unless you have some mechanism for reolving that number to a *character*, you can't process it in any meaningful manner (except parse it). This was one of my objections to the BCTF approach expounded by WG8: it emphasises the *codes*, not the *characters*, and the *characters* are what most applications will be dealing with. We need SDATA, or typed entities, so that we can associate some processing with them based on type. For SDATA, that will generally mean resolving a name, or some other data, to a *character* and/or to a glyph(image). As we've already seen, there is a large number of cases where this is needed: 1) Family names in Taiwan 2) Ancient Buddhist Texts (talk to the Buddhist Text Initiative folk). 3) Gaiji 4) Scientific publications there are many others. >From a practical viewpoint, there are many things that you can do once you have type information for an entity (including ignore it). If you don't have the information, you can't do any of them. Isn't that one of the great advantages of SGML? Date: Wed, 23 Oct 1996 14:12:03 -0700 From: lauren@sqwest.bc.ca (Lauren Wood) To: w3c-sgml-wg@w3.org Subject: documentation for UA interoperability One of the things we haven't yet discussed (or did I miss something?) is the interaction between different XML systems and what this might necessitate in terms of documentation. Since I've spent a large amount of time worrying about reverse-engineering the HTML DTD, this is something I'd like to get clear from the beginning in XML. In HTML, there is no need for documentation on elements, as long as all UAs read and implement the HTML spec. This is not necessarily the case for XML, where UAs will need documentation on elements to enable interoperability. I don't know whether this should be in the XML spec itself, or in ancillary documentation covering UA conformance. It seems pretty obvious that this has to be documented, but I think it also needs to be specified how, and what level of documentation is enough. Note that when I say "DTD fragment", I mean "in whatever syntax". If I'm too early in bringing this up now, just tell me and I'll repost at a more suitable stage. There are two major cases that I have in mind, that could be expanded to cover other UAs. The words "browser" and "editor" should be taken as meaning generic applications that have the same requirements. 1) Browser X has special handling capabilities for element YY, and therefore users who wish to take advantage of these capabilities should author their documents appropriately. The developers of browser X should write documentation stating effectively what the expected DTD fragment for element YY is - with allowed content model, where the element is allowed, and attributes and allowed ranges for CDATA attribute values. This doesn't mean that the developers of browser A would have to supply element declarations, just that they could be trivially written from their documentation. 2) User A has been using element ZZ and wants browser A to do something with it, e.g. show the content. Style sheets go a long way here, but we also need a fallback position, much like HTML has, in case there is no information in the style sheet that refers to element ZZ. In HTML it is stated that UAs should ignore unknown tags but show the content - we should specify something similar. The content could be shown according to the style sheet attached to the nearest ancestor element, or the nearest ancestor that the browser recognises (see documentation the browser should supply under 1) above). Comments? Lauren -- Lauren Wood, SoftQuad, Inc. From: lee@sq.com Date: Wed, 23 Oct 96 17:09:44 EDT To: w3c-sgml-wg@w3.org, dgd@cs.bu.edu Subject: Re: non-reportable errors > I haven't gotten a rise out of anyone with this, but I will make a last > try. Several people have told me off-list that the reason for > non-reportable errors is so people who don't care about SGML compatibility > need not implement it. It seems to me that from a CS point of view, a non-reportable error sounds like an error in the specification! If you mean `it is optional that an XML application detect this as an error', say that. > I would rather have plain language that reflects out intent, than > language which, when properly decoded, reflects our intent. > > The terms error and warning are well established in the compiler > community (as is the fact that ignoring warnings can cause you real > trouble). Let's use them. Agreed. We already have obfuscatory language in the SGML spec! XML must use the kind of language (whether or not one considers it to be English) that is used in programming language specifications, and not the kind of language that is used in legal briefs, legal opinions, political statements or, for that matter, Sunday Morning Homilies :-) Lee Date: Wed, 23 Oct 1996 16:50:23 -0400 From: gtn@ebt.com (Gavin Nicol) To: U35395@UICVM.UIC.EDU CC: John_Lavagnino@brown.edu, w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions >It should be noted, however, that this is not quite the same as what >has been described to me in private mail by other proponents of >SDATA, who say when you encounter an SDATA entity you: > > --- inform the application that an SDATA entity is beginning > --- pass the application the entity text (and perhaps its name) > --- inform the application that the SDATA entity is ending > >I.e. you perform *no* lookup, you merely provide the application >with the power to perform lookup. This is closer to my model of SDATA processing. It just allows the processor to do something based on the content of the entity based on it's type. As I said earlier, SDATA, or some form of entity typing mechanism, seems to me to be crucial to building a good distributed character/glyph/font registry/resolution mechnism. I wish to be able to do something like: and to be able to resolve/process that on my local system. Date: Wed, 23 Oct 96 16:23:01 CDT From: Michael Sperberg-McQueen Subject: Re: ERB decisions on A.17, B.9, and other questions To: Liam Quin , W3C SGML Working Group On Wed, 23 Oct 96 15:31:18 EDT Liam Quin said: >> For fallback processing, the text-entity user must rely on >> display-specific sets of entity declarations -- unfortunately, >> without public identifiers these cannot be reliably labeled. >If there were public identifiers for the unknown glyphs, they probably >wouldn't need to be unknown! Sorry to be unclear. The antecedent of 'these' was intended to be 'display-specific sets of entity declarations', not 'unkown glyphs'. That is, what I meant was "without formal public identifiers being part of XML, there will be no public text display version field in the external identifier for an entity set; it will thus be impossible (by which I meant: I don't know how) to select automatically the specific version of the entity set which should be used by a system with the display characteristics of the current application; since the public text display version field can be used to identify device-specific versions of entity sets and handle some sophisticated fallback schemes, this means that XML may have no standard way of handling fallback information via device-specific and generic entity sets." >> 3. A non-ISO-10646 character known to the application: >> >> In both cases, private arrangements of a form not covered by the XML >> spec are required. >Not if the XML spec handles this case. Possible forms of private arrangements are indeed on the list of topics to be addressed in future revisions. I don't think there are proposals on the table to address it in version 1.0. Sorry; my obscurity; I should have said XML 1.0. -C. M. Sperberg-McQueen Date: Wed, 23 Oct 1996 22:36:39 +0000 To: gtn@ebt.com (Gavin Nicol) From: James Clark Subject: Re: ERB decisions on A.17, B.9, and other questions Cc: w3c-sgml-wg@w3.org At 16:50 23/10/96 -0400, Gavin Nicol wrote: >As I said earlier, SDATA, or some form of entity typing mechanism, >seems to me to be crucial to building a good distributed >character/glyph/font registry/resolution mechnism. I wish to be >able to do something like: > > > >and to be able to resolve/process that on my local system. Why can't you build your mechanism using normal elements '> ? I don't find the argument that "my DTD may not have a glyph element" very convincing: most SGML DTDs are certainly going to need modifying to support XML. James Date: Wed, 23 Oct 96 17:07:51 CDT From: Michael Sperberg-McQueen Subject: Re: non-reportable errors To: W3C SGML Working Group On Wed, 23 Oct 1996 17:10:52 -0400 said: >> I haven't gotten a rise out of anyone with this, but I will make a last >> try. Several people have told me off-list that the reason for >> non-reportable errors is so people who don't care about SGML compatibility >> need not implement it. > >It seems to me that from a CS point of view, a non-reportable error >sounds like an error in the specification! If you mean `it is optional >that an XML application detect this as an error', say that. Does this mean that a condition which (a) is certainly unintended except in cases of deliberate sabotage, (b) will likely or possibly produce erroneous results, or (c) however else you wish to say 'mistaken, wrong, bad, glitch, snafu, ...' but which cannot reliably be detected by software, or which can be detected only at great cost, cannot be described as an error? In C, is it an 'error' or only a situation with 'undefined results' when I allocate memory, free it, and then try to write to it with a pointer that wasn't updated? I don't think this is reliably detectable, and the C standard certainly doesn't require compilers or runtime systems to detect it. But it's clearly an error in my book. It certainly isn't correct! My proficiency in English has limits, like anyone's, but to me 'error' means 'something wrong'. It has nothing to do with whether the something wrong can be reliably detected. Conforming processors should be required to report any error they can reasonably be expected to detect (unless of course they die immediately -- does sudden death count as an error message?) So I'd like to call it an error when (for example) a document declares List as containing (head?, item+) and the instance has a list with two Head elements. This is an error, but I do *not* want all XML parsers to be required to read the DTD and validate the document against its content models. It is (or, I think, should be) an error if a metadata header says that a data stream is ISO 8859-1 when in fact it's ISO 8859-2. A MIME processor cannot reasonably be expected to detect such an error; does that mean it's not going to lead to erroneous results? If most readers share the notion that something becomes non-erroneous by virtue of being not reliably or cheaply detectable, then certainly a term other than 'error' must be found. I hope never to fly in an airplane designed on that principle, though. -C. M. Sperberg-McQueen Date: Wed, 23 Oct 96 17:39:24 CDT From: Michael Sperberg-McQueen Subject: ERB decisions, 23 October 1996 To: W3C SGML Working Group The ERB met today, 23 October 1996, and decided a number of questions. All members of the ERB were present (Bosak, Bray, Clark, DeRose, Hollander, Kimber, Magliery, Maler, Paoli, Sharpe, Sperberg-McQueen); decisions were taken by consensus except as noted. As usual, summaries of the rationale for the decisions made have not been reviewed by the ERB and are thus subject to correction and further explanation. A.17 Should XML have entities, or not? The ERB had already agreed that XML should have internal text entities and external NDATA entities. Today, after discussion, we agreed that support for external text entities would be an optional feature of XML 1.0 (dissenting: Clark, Paoli, Sharpe). The rationale for the decision was that support for external entities is (a) essential if XML is to be useful as an authoring language, but (b) a heavy burden for network-based client software. A proposal to define XML in such a way that external text entities were legal only if in local files (and thus not legal in network use of XML) attracted some support, but not enough. The dissenting view on this decision was that allowing an optional feature and losing the monolithic definition of XML was too high a cost; the dissenters all also felt that external text entities should be disallowed unconditionally. External text entities will be placed on the list of topics to be reviewed in preparing future versions of XML. This topic may also be revisited in the near future (i.e. before version 1.0), depending on reports on the progress and status of W3C-based work on this and related topics. The question of SDATA entities will be taken up again before XML 1.0 is published. C.1 should XML require all entities to be synchronous with the document's logical structure? Agreed unanimously that XML will require all entities to be synchronous with the document's element structure. The rationale is that this simplifies parsing somewhat, allows entity expansion to be delayed if the implementation desires to do so, and makes possible simple checks for the well-formedness of external (and internal) entities. C.2 should XML prescribe the use of an ENTITY-END character as the canonical method of handling entity boundaries, as a way of simplifying exposition and implementation (6.2.2)? Agreed unanimously not to prescribe any particular method of handling entity ends; rationale: the proposal would tend to confuse, not simplify, the issue. C.3 should XML retain or relax SGML's prohibition on ENTITY attributes referring to SGML text entities (7.9.4.3)? Agreed unanimously to retain the prohibition. Rationale: compatibility. C.4 if XML makes DTDs optional and allows partial DTDs, what must or may a parser do when it encounters references to undeclared entities (9.4)? Should XML declare any set of entities automatically? Agreed unanimously that reference to an entity not declared and not included in the list of 'automatic' declarations is a reportable error. No particular error recovery strategy will be prescribed. Rationale: defining this as a non-error would weaken validation too much; error recovery should be left to the implementation, as different strategies are appropriate for different purposes. Agreed unanimously to define automatically the entities lt, gt, amp, and two entities for double and single quotation (for use in attribute value literals), names to be determined in separate discussion. Proposals to declare other sets of entities automatically (e.g. all of ISO Latin 1 or all entities declared in HTML 3.2) remain open questions. C.5 if XML uses ISO 10646, should there be a special form of character reference using hexadecimal, not decimal, numbers, since most references to ISO 10646 and Unicode use hex, not decimal (9.5)? Agreed (Clark dissenting) to specify that XML documents may refer to characters in ISO 10646 using the form '&u-' or '&U-' followed by four hexadecimal digits, followed by semicolon. Rationale: Unicode and ISO 10646 documentation is in hexadecimal, not decimal, so this constitutes a small but important convenience and aid to reliability. The proposal to use '&u' was preferred to the '&#u' proposal since it is believed to allow SGML systems to handle these references (which appear to an SGML parser to be general entity references) using a default entity declaration. (Consult James Clark for details.) C.6 Should XML retain SGML's prohibition on multiple declarations for the same element (11.2.1)? Agreed unanimously to retain the prohibition. Rationale: compatibility. (Some ERB members may also apply the same rationale as for the dissent on question C.8.) C.7 Should XML prohibit the use of inclusion and exclusion exceptions in element declarations? (11.2.4, 11.2.5)? Agreed unanimously to prohibit their use in XML 1.0, and (with dissents from Bray, Magliery, and Sperberg-McQueen) to place them on the list of topics to be considered in preparing future versions. Rationale: simplification of validation and harmonization of XML parsing model with standard formal-language theory and practice. C.8 Should XML prohibit content-model references to undeclared elements (11.2.4)? Agreed (Bray, DeRose, and Sharpe dissenting) to allow such references. Rationale: this is a useful technique in the construction of large public DTDs which may be subsetted locally or document-by-document. Rationale for the dissent: clean grammars are easier to process and parse than dirty grammars. (N.B. 'clean' and 'dirty' here have the technical senses usual in discussions of formal grammars.) C.9 Should XML forbid use of the '&' connector in content models (11.2.4.1)? Agreed unanimously to forbid use of the '&' connector in XML. Rationale: harmonization with conventional regular expressions. C.11 Should XML retain SGML's prohibition on multiple attribute-list declarations for the same element (11.3.1) or on multiple declarations for the same attribute (11.3.2)? Agreed unanimously to retain the prohibition. Rationale: compatibility. (Some ERB members may also apply the same rationale as for the dissent on question C.8.) C.12 Should XML change the set of types available for attributes? E.g. by suppressing NAME(S), NUMBER(S), NMTOKEN(S), NUTOKEN(S) and adding constraints in the form of regular expressions, ISO dates, language-code, external-id, type IDREF, ... (7.9.4, 11.3.3) After discussion, agreed unanimously that XML should have the following attribute types: ID, IDREF, IDREFS, ENTITY, ENTITIES, CDATA, enumerated attribute types, NOTATION attribute type, NMTOKEN and NMTOKENS. The types NUMBER(S), NUTOKEN(S), AND NAME(S) are to be dropped. Rationale: the distinctions among the lexically defined types are not useful enough to justify retaining all of them, but they do provide convenient case-folding and white-space normalization. If just one is to be kept, it should be NMTOKENS, since it subsumes all the others and the other lexical types of SGML can be translated into XML by retyping them as NMTOKENS and adding an application-level check on the specific type of token required. Such application-level checks are in any case common among users of these types. The type NMTOKEN was retained in order to preserve the singular/plural symmetry with IDREF and ENTITY. Extensions to the set of declared-value types in ISO 8879, though supported by Sperberg-McQueen, commanded no support for inclusion in XML 1.0. Other decisions in batch C are still pending. -C. M. Sperberg-McQueen From: lee@sq.com Date: Wed, 23 Oct 96 19:31:36 EDT To: w3c-sgml-wg@w3.org, U35395@UICVM.UIC.EDU Subject: Re: non-reportable errors > >It seems to me that from a CS point of view, a non-reportable error > >sounds like an error in the specification! If you mean `it is optional > >that an XML application detect this as an error', say that. > > Does this mean that a condition which (a) is certainly unintended > except in cases of deliberate sabotage, (b) will likely or possibly > produce erroneous results, or (c) however else you wish to say > 'mistaken, wrong, bad, glitch, snafu, ...' but which cannot reliably > be detected by software, or which can be detected only at great cost, > cannot be described as an error? No. > > In C, is it an 'error' or only a situation with 'undefined results' > when I allocate memory, free it, and then try to write to it with a > pointer that wasn't updated? It is a situation with undefined behaviour, not an error. An implementation may flag it at runtime; we have at least three such implementations here, maybe more, and they are very useful for detecting and fixing such errors. Don't leave home without them. It is possible to prove mathematically that there are cases that no C compiler can detect, that many people would consider errors -- for example, a program that under some inputs goes into an infinite loop. This, of course, is called the Halting Problem. > I don't think this is reliably > detectable, and the C standard certainly doesn't require compilers or > runtime systems to detect it. But it's clearly an error in my book. > It certainly isn't correct! The program that does this is probably not correct. It is a bug to rely on undefined behaviour, and the program is in error. If that is what you mean by a non-reportable error, fine. The phrase to me means `an error that must not be reported to the user', and I don't like that. All I was complaining about was the wording. > My proficiency in English has limits, like anyone's, but to me > 'error' means 'something wrong'. In compiler practice, an error is something that prevents successful compilation. If there was an error, processing did not complete. If there was a warning, you should fix it, but you will still get an output file that you can try to run. In English, Entity and element have meanings, but in SGML they're jargon. Error and Warning are jargon to computer programmers. > Conforming processors > should be required to report any error they can reasonably be > expected to detect Assuming that they are running in an environment in which there is a back-channel to get messages to a human who can reasonably be expected to deal with the error. For example, a web crawler might write to a log file, but it might well be run with parsing warnings/errors turned off, so that when it examines 1,000,000 web pages, the person running it (who doesn't care about parse errors, and can't fix them as he doesn't own them) doesn't see the messages. > (unless of course they die immediately -- does > sudden death count as an error message?) No. > So I'd like to call it > an error when (for example) a document declares List as containing > (head?, item+) and the instance has a list with two Head elements. > This is an error, but I do *not* want all XML parsers to be required > to read the DTD and validate the document against its content models. The error here is that the DTD does not correctly describe the instance. Whethere the DTD or the instance is at fault, it is only an error if you have both the DTD and the document. > It is (or, I think, should be) an error if a metadata header says > that a data stream is ISO 8859-1 when in fact it's ISO 8859-2. > A MIME processor cannot reasonably be expected to detect such an > error; does that mean it's not going to lead to erroneous results? It will lead to undefined results. They may happen to be correct (e.g. there are only ASCII/646 chraracter codes in the file) When the XML spec is written, it should define error cases where applicable. The simpler the language, the fewer kinds of error there should be. Every XML implementation will need to implement code to check for, report, and handle, every error case that is described in the spec. And no others. A good implementation might handle many more cases, of course. Never call something undetectable an error. Instead, design the system so that it is not an error. For example, your DTD example is made tractable by saying that a DTD, when supplied, must match the instance. This is much better than saying that every instance must match a DTD even if one was not supplied. If something need not be reported, ask why. If it is because fixing the "problem" does not affect the document's meaning, portability or longevity, maybe it is a pointless error. If there is something that may reduce document portability, but is still within the spec, the spec might suggest a warning. for example, in C, unsigned long ul = 12; . . . if (ul < 0) { printf("not reached\n"); } some compilers will warn that the comparison (ul < 0) can never be true, by definition, so that the printf is never executed. It's not illegal C, but it is odd C,and the warning often catches a bug. Similarly, char c; while ((c = getchar()) != EOF) { } is a common bug (a char variable can't represent EOF, so the comparison will always fail on some systems; on other systems, c is sign extended, and character 255 (y dieresis in Latin 1) will be treated as EOF. Oops) This is a case for a warning, not an error. It is not the compiler's job to second-guess the programmer (except in PL/1 maybe!). Sorry for the extended programming language example to non-programmers! Lee Date: Wed, 23 Oct 1996 17:21:54 -0700 (PDT) From: Bill Smith Subject: Re: ERB decisions, 23 October 1996 To: w3c-sgml-wg@w3.org > A.17 Should XML have entities, or not? > > The ERB had already agreed that XML should have internal text entities > and external NDATA entities. Today, after discussion, we agreed that > support for external text entities would be an optional feature of XML > 1.0 (dissenting: Clark, Paoli, Sharpe). I find the introduction of "optional features" in XML most unfortunate - at least I don't remember anything else that has been decided as optional. The camel's nose is now in the tent and a ready mechanism is at hand to render our efforts wasted. It is now impossible to ensure that an XML 1.0 application can reliably process an XML 1.0 document - without first determining the document's flavor. Add a few more optional features and we will have feature stew to go along with our tag salad. If entities are essential for XML to be useful as an authoring language, than entities should be in XML 1.0. I don't subscribe to that belief since I know of several "useful editors" that do not support entities. I hope that this decision is revisited. The ERB's decision to permit optional features in XML 1.0 is, in my opion, a fatal flaw. A monolithic specification is imperative. Whatever happened to as simple as possible? Date: Wed, 23 Oct 1996 18:18:23 -0400 From: gtn@ebt.com (Gavin Nicol) To: jjc@jclark.com CC: w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions >Why can't you build your mechanism using normal elements > >'> > >? I don't find the argument that "my DTD may not have a glyph element" very >convincing: most SGML DTDs are certainly going to need modifying to >support XML. You *could* do this, but it is semantically incorrect in my books. It is also a less interoperable solution (all systems would know that SDATA was something special, but not all would necessarily know that was to be replaced by characters). Also, the *requirement* of DTD changes/additional is not one to be ignored either. To: w3c-sgml-wg@w3.org Subject: Re: B.10 Empty elements? Date: Wed, 23 Oct 1996 17:16:27 -0700 From: Joe English lee@sq.com wrote: > So we can use and understand that existing SGML parsers will break, > but w'll try and fix that by changing SGML and hope that at least some > of the commercial SGML parsers are updated -- maybe most of them. > (or can this be done without breaking things? I don't see how, although > if James said it could, he is right, and I have just forgotten!) > (oh, OK, a shortref or datatag mapping to > perhaps?) Full-featured SGML parsers (i.e., SP) can be tricked into accepting that syntax by specifying "/>" as the NET delimiter and setting SHORTTAG YES in the SGML declaration. Thus this: gets parsed as STAGO, generic identifier, NET, and since 'e' is (presumably) an EMPTY element the next NET's not necessary. I think the syntax is OK from an aesthetic standpoint, but there are a *lot* of things that can go wrong.... First off it requires SHORTTAG YES, which means that all the other SHORTTAG features (that we have already decided we do *not* want) get enabled. More importantly, if somebody feeds an XML document to an SGML parser and forgets to supply the right SGML declaration -- or tries to use SGMLS for that matter, which won't let you change the RCS delimiter strings -- she'll end up with a spurious ">" after every EMPTY element. Or if somebody (naively or accidentally) types for an element that is not in fact EMPTY, his parser stack will get severely out of whack. My current preference is <@e>, which requires @ being added to NMSTART and an XML application convention for naming EMPTY elements. This would be much more robust. (SGMLS won't let you do this either, but it could be hacked to do so more easily than it could the "NET=/>" trick. SP can handle either solution. I don't know about other parsers.) --Joe English jenglish@crl.com Date: Wed, 23 Oct 1996 21:40:18 -0400 To: bosak@atlantic-83.eng.sun.com (Jon Bosak) From: Harvey Bingham Subject: Re: Non-Unicode characters, SDATA, etc. Cc: w3c-sgml-wg@w3.org At 21:54 1996/10/22 -0700, Jon Bosak wrote: >[Tim Bray:] > >| Anders surprised some of us by pointing out that there are a large >| number of ISO entities that are not in ISO 10646 at all. So I'd like >| to request input from the WG on this. >| >| On the other hand, Anders' posting makes it clear that [particularly >| in the area of mathematics] there are routinely a substantial number >| of non-10646 characters available [in theory at least] to technical >| publishers; who have been a mainstay of SGML support over the years. > >With some embarrassment (because, like Tim, I have never run into this >problem myself, and therefore argued the 80-20 angle when this was >before the ERB), >... >I haven't checked with Mr. Poppelier, but I'm sure that the gentleman >won't mind being quoted in a forum where this information might do >some good. > >Jon > > I quote Ken Iverson [the inventor of the mathematical programming language APL, some 35 years ago] about the inadequate extent of the glyph set available for mathematicians, and its cause: "The reason mathematicians have used every character in every language, living and dead, is that they chose to elide the multiply sign between such characters." That shorthand mistake of omitted multiply sign [or in other areas of math some other infix operator symbol] prevented the mathematician from using multi-character names. Since a mathematician feels free to define a private self-consistent world, there need be no constraint to using a limited choices of printable glyphs. In the language for a self-defined world, any "squiggle" can have arbitrary semantic meaning. Anyone who chooses to learn the language of that world needs to learn the mathematician's chosen meaning. In general, any squiggle can substitute for any other, so long as the choice has attached its semantics. >From this perspective, the measure of the set of squiggles is unbounded. For that reason I continue to argue that an unrecognizable character entity name should be passed on as-is to the application, which may well be written by that mathematician in a private world. Little harm will be done, and perhaps some education, if in fact the mathematian may learn to use multi-character names! But that may constrain the academic freedom to define a private world and be the gatekeeper for the few who seek to enter into such a world. Technology today makes it possible to create glyphs to represent those squiggles. The mathematician who chooses to use squiggles should supply their names and the desired glyphs for them, in an acceptible means, such as truetype. Then the publishers will have less need for an ever-growing character repertoire with corresponding glyphs in an ever-growing set of font families. I do not believe it is up to XML to try to close the set, nor prescribe the actions of an application in which arbitrary squiggles may occur and be meaningful to the mathematician's private world. Regards/Harvey > Date: Wed, 23 Oct 1996 23:57:01 +0000 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Optional features considered harmful At 05:21 PM 23/10/96 -0700, Bill Smith wrote: >I find the introduction of "optional features" in XML most unfortunate Me too - I've been feeling bad ever since the vote. Maybe the WG can help us out here. Where we got to on the ERB was: 1. external text entities are a basic necessity for authoring (I want to validate my 700-page book without having to have it in a file) and they're not even that hard to do [once you've limited the system identifier repertoire, which we've done]. Arguably, without them, XML is a delivery-only toy language 2. external text entities are big-time bad news for a browser - particularly since browsers are moving in the direction of exposing the document structure to client-side logic. And in fact the jam-it-in-the-parse-tree semantic of text entities is not really the kind of transclusion you want in a browser. So what we REALLY WANT is to say "Here is a feature that is intended for authoring and document management but look, boyo, don't you go asking client programs to do this!" I had proposed a side-step by saying you could only use system identifiers for text entities, but this kind of smells like a kludge. Bob Streich had earlier spoken about server-mode vs. client-mode XML; is this anything more than an option by another name? I think I speak for the ERB when I say that we would welcome a way to throw out the optional bathwater without losing the text entity baby, and cheerfully reconsider the vote of the 23rd. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 To: lee@sq.com, John_Lavagnino@Brown.edu, w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: B.10 Empty elements? Date: Thu, 24 Oct 1996 10:40:23 +0100 >I agree. I admit I still like <@this> best, but would work as well. >As would I suppose, which hass a nice imperative feel to it... The difference between these two is that the use of @ is simply applying an application convention to naming of elements while the / implies a new type of delimiter to complement TAGC, or a remapping of NET which requires NET to have a different behaviour in SGML and XML. In SGML NETs always occur in pairs. You cannot have should become the NET delimiter. >Any of <@emp>, /, , require at the very least a >change to the SGML declaration, but as we've already increased NAMELEN >that's probably OK. The <@emp> solution does not need to change the delimiter set or the behaviour of any existing tools other than an extension to the default name character set. To me this means that it represents the smallest amount of work for existing tool changes, and the seems to provide something our mythical CS grad can cope withe easily. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Thu, 24 Oct 1996 11:02:07 +0000 To: Martin Bryan From: James Clark Subject: Re: B.10 Empty elements? Cc: w3c-sgml-wg@w3.org At 10:40 24/10/96 +0100, Martin Bryan wrote: > >>I agree. I admit I still like <@this> best, but would work as well. >>As would I suppose, which hass a nice imperative feel to it... > >The difference between these two is that the use of @ is simply applying an >application convention to naming of elements while the / implies a new type >of delimiter to complement TAGC, or a remapping of NET which requires NET to >have a different behaviour in SGML and XML. In SGML NETs always occur in >pairs. You cannot have element. Yes, you can. Using . James Date: Thu, 24 Oct 1996 11:34:41 +0000 To: Tim Bray From: James Clark Subject: Re: Optional features considered harmful Cc: w3c-sgml-wg@w3.org At 23:57 23/10/96 +0000, Tim Bray wrote: > Where we got to on the ERB was: > >1. external text entities are a basic necessity for authoring (I want to > validate my 700-page book without having to have it in a file) and > they're not even that hard to do [once you've limited the system > identifier repertoire, which we've done]. Arguably, without them, > XML is a delivery-only toy language I would like to point that at least one person on the ERB (me) passionately believes that this viewpoint is totally misguided. If you do large-scale authoring with nothing more than a parser, a simple file-based entity manager, a text editor and the filesystem, then, yes, you would have problems managing without external text entities. If that's what you want to do, author in SGML: you have all the authoring tools you need already. The focus in XML should be on enabling the development of authoring environments, and it is certainly possible to build a fine authoring environment without any use of external text entities. James Date: Thu, 24 Oct 1996 06:54:24 +0000 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: Optional features considered harmful At 11:34 AM 24/10/96 +0000, James Clark wrote: >At 23:57 23/10/96 +0000, Tim Bray wrote: >>1. external text entities are a basic necessity for authoring ... >I would like to point that at least one person on the ERB (me) passionately >believes that this viewpoint is totally misguided... >... it is certainly possible to build a fine authoring >environment without any use of external text entities. James is correct; it is certainly possible to do this. But SGML provides a built-in, standard, nonproprietary way to go about it. The way I sell SGML in the corporate world is: SGML gives you: 1. a way to model the structure of your documents, and 2. a way to control the authoring so they come out right, and 3. a way to modularize documents for re-use and management, and 4. ALL OF THIS IS STANDARDIZED AND NON-PROPRIETARY It seems to me that if XML loses text entities, then #4 no longer applies to #3. I don't know - is this a fair price to pay for making XML lightweight and easy to adopt? At the same time, James is correct that it is unreasonable and wrong to expect render-mostly network browsers to use the SGML transclude-and-parse semantics. Is there an option-free way to reconcile our goals? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Thu, 24 Oct 1996 15:13:58 +0000 To: Tim Bray From: James Clark Subject: Re: Optional features considered harmful Cc: w3c-sgml-wg@w3.org At 06:54 24/10/96 +0000, Tim Bray wrote: >At 11:34 AM 24/10/96 +0000, James Clark wrote: >>At 23:57 23/10/96 +0000, Tim Bray wrote: >>>1. external text entities are a basic necessity for authoring ... > >>I would like to point that at least one person on the ERB (me) passionately >>believes that this viewpoint is totally misguided... >>... it is certainly possible to build a fine authoring >>environment without any use of external text entities. > >James is correct; it is certainly possible to do this. But SGML provides >a built-in, standard, nonproprietary way to go about it. The way I sell >SGML in the corporate world is: > >SGML gives you: > 1. a way to model the structure of your documents, and > 2. a way to control the authoring so they come out right, and > 3. a way to modularize documents for re-use and management, and > 4. ALL OF THIS IS STANDARDIZED AND NON-PROPRIETARY > >It seems to me that if XML loses text entities, then #4 no longer applies >to #3. I think you can get 3 and 4 without external text entities by using transclusion via link semantics, which are going to be standardized in a later phase of XML. James Date: Thu, 24 Oct 1996 08:30:29 -0900 To: Tim Bray , w3c-sgml-wg@w3.org From: "W. Eliot Kimber" Subject: Re: Optional features considered harmful At 06:54 AM 10/24/96 +0000, Tim Bray wrote: >At 11:34 AM 24/10/96 +0000, James Clark wrote: >>At 23:57 23/10/96 +0000, Tim Bray wrote: >James is correct; it is certainly possible to do this. But SGML provides >a built-in, standard, nonproprietary way to go about it. The way I sell >SGML in the corporate world is: > >SGML gives you: > 1. a way to model the structure of your documents, and > 2. a way to control the authoring so they come out right, and > 3. a way to modularize documents for re-use and management, and > 4. ALL OF THIS IS STANDARDIZED AND NON-PROPRIETARY But note that general text entities *don't actually do point 3*. General text entities *ARE NOT REUSABLE*. In fact, the only way to have re-usable SGML documents, as James has pointed out, is to make them documents syntactically (even if the objects may be semantically subparts of documents). While external text entities are a useful convenience for single-person authoring, they are not useful as a general mechanism for managing SGML data as re-usable objects. Cheers, E. -- W. Eliot Kimber (kimber@passage.com) Senior SGML Consultant and HyTime Specialist Passage Systems, Inc., (512)339-1400 10596 N. Tantau Ave., Cupertino, CA 95014-3535 (408) 366-0300, (408) 366-0320 (fax) 2608 Pinewood Terrace, Austin, TX 78757 (512) 339-1400 (fone/fax) http://www.passage.com (work) http://www.drmacro.com (home) "If I never had existed, would you still remember me?..." --Austin Lounge Lizards, "1984 Blues" Date: Thu, 24 Oct 1996 12:32:54 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: ERB decisions on A.17, B.9, and other questions At 6:36 PM 10/23/96, James Clark wrote: >At 16:50 23/10/96 -0400, Gavin Nicol wrote: > >>As I said earlier, SDATA, or some form of entity typing mechanism, >>seems to me to be crucial to building a good distributed >>character/glyph/font registry/resolution mechnism. I wish to be >>able to do something like: >> >> >> >>and to be able to resolve/process that on my local system. > >Why can't you build your mechanism using normal elements > > '> > >? I don't find the argument that "my DTD may not have a glyph element" very >convincing: most SGML DTDs are certainly going to need modifying to >support XML. This will only be useful if we pre-wire a tag into XML. I'm not averse to this, really, as I agree that existing DTDs will be reworked. However, it is a new mechanism, and it adds a funky tag that can't be redefined (if this were not so a processor without a DTD might get a redefined tag of the name "glyph," and choke). People are already used to the syntax &mystery-glyph; The use of that syntax would now be an option that they have to brew up themselves after understanding a new tag. These are not fatal objections, but I still prefer SDATA to this. Also defining the tag, would mean defining the attributes for character meta-data. I don't think we should enter that den of snakes now. Let's reserve the [] syntax in SDATA entities for the future, and finish solving the problem in XML 1.1 or 2.0. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 24 Oct 1996 12:32:45 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: Optional features considered harmful At 7:57 PM 10/23/96, Tim Bray wrote: >At 05:21 PM 23/10/96 -0700, Bill Smith wrote: > >>I find the introduction of "optional features" in XML most unfortunate > >Me too - I've been feeling bad ever since the vote. Maybe the WG can help >us out here. Where we got to on the ERB was: Yes, options are not a good thing. Let us rinse the taste of option stew >from out mouths (Thanks for the metaphor, Bill!). >1. external text entities are a basic necessity for authoring (I want to > validate my 700-page book without having to have it in a file) and > they're not even that hard to do [once you've limited the system > identifier repertoire, which we've done]. Arguably, without them, > XML is a delivery-only toy language While James' point that entities are not necessary is valid, I agree with Tim's (later post) that they provide the "vendor-independent" way to do doc management. Pace, Eliot, I think that with the synchrony restriction they could prove to be a lot more useful than SGML entities have proven to be. >2. external text entities are big-time bad news for a browser - > particularly since browsers are moving in the direction of exposing > the document structure to client-side logic. And in fact the > jam-it-in-the-parse-tree semantic of text entities is not really > the kind of transclusion you want in a browser. I think the problem here is the assumption that the browser _must_ expand the entity if it _can_ expand the entity. I advocate a different approach, where a browser would have "transclude-if-convenient" semantics. So an external entity reference might be rendered as an expandable link, like the links in the old OWL product. The browser could automatically follow small external entities, and link-ify large ones. This behavior is incompatible with validation, but a non-validating parser would not care about this. Since documents are parseable without a DTD, entities are too, so it's easy to resolve an entity even after you have finished your first parse. You will get better formatting if you retain the element stack + formatter state variables in effect before unexpanded references, but even that is a luxury. >So what we REALLY WANT is to say "Here is a feature that is intended >for authoring and document management but look, boyo, don't you go >asking client programs to do this!" I had proposed a side-step by >saying you could only use system identifiers for text >entities, but this kind of smells like a kludge. Is letting the client program do what it wants (including just popping up a link) enough freedom to make browsers easy? >Bob Streich had earlier spoken about server-mode vs. client-mode >XML; is this anything more than an option by another name? No, it's not, I'm afraid. >I think I speak for the ERB when I say that we would welcome a way to >throw out the optional bathwater without losing the text entity baby, >and cheerfully reconsider the vote of the 23rd. You've got my idea, for what it's worth. >Cheers, Tim Bray >tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Thu, 24 Oct 96 13:02:11 CDT From: Michael Sperberg-McQueen Subject: ERB decisions, 24 October 1996 To: W3C SGML Working Group The ERB met today, 24 October 1996, and decided a number of questions. Present: Bosak, Clark, Kimber, Magliery, Maler, Paoli, Sharpe, Sperberg-McQueen; absent: Bray (represented in part by proxy votes), DeRose, Hollander. Decisions were taken by consensus except as noted. As usual, summaries of the rationale for the decisions made have not been reviewed by the ERB and are thus subject to correction and further explanation. A.15' XML will use a sort of 'formal processing instruction': the first token of the PI's system data will be a Name (e.g. or ) (7.6, 8) Should the Name be required to be the name of a declared NOTATION? Agreed unanimously that the Name need not be that of a declared NOTATION; if it is, however, the spec should state that the meaning is that the PI in question is in the notation (or: appertains to the notation processor) indicated. Rationale: making the association explicit is a useful semantic clue, but requiring it is excessively burdensome. A.18' Should XML have declarations for notations (11.1)? Agreed unanimously that it should. Rationale: needed for NDATA entities (and PIs). B.12 Should XML retain SGML's prohibition on multiple declarations for the same notation (11.4)? Agreed unanimously to retain the prohibition. Rationale: compatibility. B.13 Should XML remove SGML's prohibition on ENTITY attributes for notations (11.4.1)? Agreed unanimously to retain the prohibition. Rationale: compatibility. B.13 bis. Should XML allow any attributes at all for notations (11.4.1)? Agreed (EK dissenting) to drop attributes on notations in XML 1.0. Agreed (MSM and EM dissenting) to place this topic on the list of topics to be (re-)considered in the preparation of future revisions of XML. C.13 Should XML remove SGML's prohibition on multiple ID or NOTATION attributes on the same element (11.3.3)? Agreed unanimously to retain the prohibition. Rationale: compatibility. C.15 Should XML define new specific methods of inferring values for attributes with no attribute-value specifications (11.3.4)? E.g. INHERITED, to signify that the value is taken from the attribute of the same name (and type) on the smallest enclosing element with such an attribute. Agreed (MSM dissenting) to define neither INHERITED nor any other new method of value-inference. Rationale: this topic will be treated in the second stage of the project. Several other topics were discussed without achieving consensus. The ERB will meet again Saturday to continue these discussions. -C. M. Sperberg-McQueen Date: Thu, 24 Oct 1996 14:44:09 -0400 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@w3.org Subject: Re: Optional features considered harmful >2. external text entities are big-time bad news for a browser - > particularly since browsers are moving in the direction of exposing > the document structure to client-side logic. And in fact the > jam-it-in-the-parse-tree semantic of text entities is not really > the kind of transclusion you want in a browser. Why are they so bad for clients? The ERB has decided that enternal text entities must be strictly synchronous with the document structure after all, which would be one of the major hurdles. Without the possibility of asynchronous nodes, it the purely linear parsing model still required? I think it's possible to work around the issues. Date: Thu, 24 Oct 96 14:08:08 CDT From: Michael Sperberg-McQueen Subject: D.1 Distinguish partial and full DTDs? To: W3C SGML Working Group On 30 October 1996, the ERB will vote to decide the following question. A straw poll indicates the question needs further discussion in the work group. D.1 What behavior should XML systems exhibit if no DTD, or only a partial DTD, is given with a document? In particular, should there be a way to distinguish a document instance for which a DTD exists but is not given from an instance for which no DTD exists? Date: Thu, 24 Oct 96 14:09:41 CDT From: Michael Sperberg-McQueen Subject: D.3 ANY-ELEMENT element-declaration keyword? To: W3C SGML Working Group On 30 October 1996, the ERB will vote to decide the following question. A straw poll indicates the question needs further discussion in the work group. D.3 Should XML specify short-hand element declaration keywords (e.g. %ANY-ELEMENT;) for element content in which any element in the DTD is legal (same as ANY, but element not mixed content)? Date: Thu, 24 Oct 1996 15:13:10 -0400 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@w3.org Subject: Re: Optional features considered harmful >lightweight and easy to adopt? At the same time, James is correct that it >is unreasonable and wrong to expect render-mostly network browsers to use >the SGML transclude-and-parse semantics. Is there an option-free way to >reconcile our goals? Assuming that we do not have asynchronous nodes, can't the transclude-parse model be replaced by parser-transclude-parse? Validation would complicate it somewhat, but not overly much. Date: Thu, 24 Oct 96 14:09:05 CDT From: Michael Sperberg-McQueen Subject: D.2 DTD summaries (a la NSGML)? To: W3C SGML Working Group On 30 October 1996, the ERB will vote to decide the following question. A straw poll indicates the question needs further discussion in the work group. D.2 Should XML provide shorthand ways of summarizing the salient points a document's DTD? * empty elements * mixed-content or element-content elements * required attributes * default attribute values * identity of ID and IDREF(S) attributes * identity of CONREF attributes (if allowed) * other? If so, * D.2 a. Should such short-hand summaries be required? * D.2 b. Allowed in place of DTDs? * D.2 c. Allowed in addition to DTDs? * D.2 d. If so, is inconsistency between the DTD and the summary an error? * D.2.e. A reportable error? Date: Thu, 24 Oct 96 14:10:18 CDT From: Michael Sperberg-McQueen Subject: D.4 parameter entities? To: W3C SGML Working Group On 30 October 1996, the ERB will vote to decide the following question. A straw poll indicates the question needs further discussion in the work group. D.4 Should XML allow parameter entities and parameter-entity references? * D.4 a. internal parameter entities? * D.4 b. external parameter entities? Date: Thu, 24 Oct 1996 15:04:31 -0400 From: gtn@ebt.com (Gavin Nicol) To: ricko@allette.com.au CC: w3c-sgml-wg@w3.org Subject: Re: Characters and SDATA entities >Using elements or entities for characters is completely possible of >course, but I think represents a poor analysis of the problem, and >XML (& SGML) would be better without it. The WWW is one big system, >and so there should be no need to use SDATA entities, as such. Well, actually, I agree with you. I find using entities *less* objectionable than elements, though not entirely pleasant either. If we treated characters as characters and had a more flexible mechanism for defining the repertoire, we'd be a lot better off. >2) The real answer to a lot of the character problems is to >have a WWW glyph service mechanism: if someone has a strange Agreed!! You and I have talked about this for more than a year now. I think we also need to have a gloabl character repository to get the best effect though. >So I agree with Gavin that what is needed is a mechanism where >characters/glyphs can be marked up richly. However, I don't think >anything less than markup to URLs of some glyph server is good >enough. Yes. We do need a resolution mechanism. I have a design that does not reqwuire that you point to a *single* glyph repository, or a single glyph image though. The resolution is performed via various channels, the most fundamental of which is the character *name*. >I guess I am falling into the same trap here as I accuse Gavin of >in the area of the dreaded encoding PIs: he thinks it is better >in the long run to create a new file format (new except for Macintoshes >of course!) rather than extend the meaning of PI to do double duty >as an in-data notation of encoding or charset. I think it is >better to create a new type of markup to handle characters/glyphs >rather than make entities or elements do double duty :-) For this, you'll only hear violent agreement from me! The SDATA entity mechanism is not elegant, though slightly better than a hack (and typed entities are useful in the general sense anyway). >As an alternative: at the SGML Asia pacific confence, some Japanese WG8 >people presented a scheme for encoding a bitmap glyph into the >minimum literal of an entity sothat the document can cart around >the glyph itself: they could get 32x32 bitmaps this way. A size >of 48x48 would be better for this: if XML's imagined SGML declaration >has a longer LITLEN than this, it is a feasible method for >worst-case (e.g. to screen) imaging. Interesting, but impractical for many important cases. >4) On the subject of names and numbers, most characters in the >world don't have useful roman names. The idea of using the >SDATA entity default value as an ALT attribute for characters >seems based on the idea that the characters in that field would >be displayable on my browser anyway in characters and a language I'd >understand. I'd like to have them solely for lookup purposes. I have been dying to get a global glyph repository together for a long time now. Date: Thu, 24 Oct 1996 15:15:38 -0400 From: gtn@ebt.com (Gavin Nicol) To: jjc@jclark.com CC: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: Optional features considered harmful >I think you can get 3 and 4 without external text entities by using >transclusion via link semantics, which are going to be standardized in a >later phase of XML. Right. Can't we treat external entities as a special case of that given the synchronous structure of them? Date: Thu, 24 Oct 1996 20:45:52 +0000 To: gtn@ebt.com (Gavin Nicol) From: James Clark Subject: Re: Optional features considered harmful Cc: w3c-sgml-wg@w3.org At 15:15 24/10/96 -0400, Gavin Nicol wrote: >>I think you can get 3 and 4 without external text entities by using >>transclusion via link semantics, which are going to be standardized in a >>later phase of XML. > >Right. Can't we treat external entities as a special case of that >given the synchronous structure of them? I think you may be right. An XML parser intended for Web browsers wouldn't resolve an external text entity immediately itself but rather would return a transclude event to the application and keep going. This would make it hard for a Web browser to do validation, but that may not be a problem. It would be easier to make this work if we disallowed references to external text entities in attribute values, but hopefully people can live without those. James Date: Thu, 24 Oct 1996 16:06:02 -0400 From: gtn@ebt.com (Gavin Nicol) To: jjc@jclark.com CC: w3c-sgml-wg@w3.org Subject: Re: Optional features considered harmful >An XML parser intended for Web browsers wouldn't resolve an external text >entity immediately itself but rather would return a transclude event to the >application and keep going. This would make it hard for a Web browser to do >validation, but that may not be a problem. Yes, that's the idea. In some code I wrote a long time ago, I had a smart pointer that would resolve nodes as needed. I imagine an entity (transclusion event) would basically become a smart pointer. From: streich@austin.sar.slb.com Date: Thu, 24 Oct 96 14:52:56 CDT To: w3c-sgml-wg@w3.org, dgd@cs.bu.edu Subject: Re: Optional features considered harmful > I think the problem here is the assumption that the browser _must_ expand > the entity if it _can_ expand the entity. I advocate a different approach, > where a browser would have "transclude-if-convenient" semantics. So an > external entity reference might be rendered as an expandable link, like the > links in the old OWL product. The browser could automatically follow small > external entities, and link-ify large ones. This behavior is incompatible > with validation, but a non-validating parser would not care about this. I like this approach. The only problem with it that I can see is that you would have to parse the external piece in order to get the formatting straight since you don't know what the missing siblings/children are. There is also the issue of missing IDs. I really don't see any significant difference between entities and other forms of transclusion--the semantics are the same only the syntax is different. bob Date: Thu, 24 Oct 1996 21:32:46 +0000 To: Michael Sperberg-McQueen From: James Clark Subject: Re: Optional features considered harmful Cc: W3C SGML Working Group At 15:23 24/10/96 CDT, Michael Sperberg-McQueen wrote: >>It would be easier to make this work if we disallowed references to >>external text entities in attribute values, but hopefully people can >>live without those. > >Er, I'm sorry if I'm missing something, but doesn't clause 7.9.4.2 >(p. 335 of Handbook) restrict ENTITY/ENTITIES attributes to >data and SUBDOC entities? I.e. isn't your conditional already met? I'm talking about *references*; for example, James Date: Thu, 24 Oct 96 15:23:31 CDT From: Michael Sperberg-McQueen Subject: Re: Optional features considered harmful To: James Clark , W3C SGML Working Group On Thu, 24 Oct 1996 15:52:21 -0400 James Clark said: >At 15:15 24/10/96 -0400, Gavin Nicol wrote: >>Right. Can't we treat external entities as a special case of that >>given the synchronous structure of them? > >I think you may be right. > >An XML parser intended for Web browsers wouldn't resolve an external >text entity immediately itself but rather would return a transclude >event to the application and keep going. This would make it hard for >a Web browser to do validation, but that may not be a problem. > >It would be easier to make this work if we disallowed references to >external text entities in attribute values, but hopefully people can >live without those. Er, I'm sorry if I'm missing something, but doesn't clause 7.9.4.2 (p. 335 of Handbook) restrict ENTITY/ENTITIES attributes to data and SUBDOC entities? I.e. isn't your conditional already met? (I think we reaffirmed that XML will work the same way, on question C.3 the other day.) I hope so, because anything that would make this work more easily while allowing external text entities is a good thing in my book. -Michael Sperberg-McQueen Date: Thu, 24 Oct 96 16:04:12 CDT From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: D.2 DTD summaries (a la NSGML)? > Date: Thu, 24 Oct 96 14:09:05 CDT > From: Michael Sperberg-McQueen > > D.2 Should XML provide shorthand ways of summarizing the salient > points a document's DTD? ^ of > > * empty elements > * mixed-content or element-content elements > * required attributes > * default attribute values > * identity of ID and IDREF(S) attributes > * identity of CONREF attributes (if allowed) > * other? > > > If so, > * D.2 a. Should such short-hand summaries be required? > * D.2 b. Allowed in place of DTDs? > * D.2 c. Allowed in addition to DTDs? > * D.2 d. If so, is inconsistency between the DTD and the summary > an error? > * D.2.e. A reportable error? > > I can't tell if the question is asking if we should consider partial DTDs using the syntax of 8879 DTDs or if it is asking if we should develop another syntax for partial DTDs. I'm assuming the former. I think we should allow partial DTDs using the syntax of 8879 DTDs. They should not be required, since we seem bent on allowing at least some processing of XML without any DTD. For me, it doesn't make sense to talk of partial DTDs in addition to (full) DTDs, since for me a full DTD is just a partial DTD that has declarations for all markup in the given instance. Either a tool insists on declarations for everything and complains when it encounters some markup for which there is no declaration, or it manages to silently plug along when it encounters something for which there is no declaration. So, I go for D.2.b. provided the syntax for our "shorthand ways of summarizing" is 8879 declarations. (If my assumption about syntax is wrong, let me know, and I'll re-evaluate my response.) Date: Thu, 24 Oct 96 15:51:46 CDT From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: D.1 Distinguish partial and full DTDs? > From w3c-sgml-wg-request@w3.org Thu Oct 24 15:11:24 1996 > Date: Thu, 24 Oct 96 14:08:08 CDT > > D.1 What behavior should XML systems exhibit if no DTD, or only a > partial DTD, is given with a document? In particular, should there > be a way to distinguish a document instance for which a DTD exists > but is not given from an instance for which no DTD exists? > First, I assume that the question is talking about a way to say "a DTD does exist" (i.e., a boolean), rather than a way to say "the DTD for this instance is ..." (where ... provides enough information to access the wayward DTD). (For the latter, I'd use a doctype declaration with a reference to the DTD, in other words, a valid 8879 doctype decl.) First of all, it seems to me that there is no qualitative difference between a partial and no DTD. The options seem to be (1) being in possession of a set of declarations (henceforth called DTD) that cover all of the markup in the document instance in question, (2) being in possession of the best DTD (if any) available that, however, still leaves some markup in the instance in question undeclared, (3) being in possession of the fact that some DTD exists, but you don't have it. Being in possession of no DTD because there is none available is a degenerate case of (2). What one does about declarations missing >from a partial DTD and what one does about a completely missing DTD seem to be the same problem. The above issue doesn't ask what to do when given a complete DTD, so we're down to whether XML should define some way for an XML document user/tool to distinguish between a subset of (2) above (the degenerate case of there being no DTD available) and case (3). What are the possible responses in those two cases: 1. the tool/user doesn't need a DTD. In this situation, there is no difference in the response in the two cases. 2. to tool/user needs a DTD. Then we have: a. the tool/user has the capacity to create/intuit a DTD so it does so. In this situation, there is no difference in the response in the two cases. b. the tool/user doesn't have the capacity to create/intuit a DTD so it would need to access the DTD before it can continue. Only in this situation would the response be different in the two cases: if there is a DTD, it would access it, and if not, it would give an apologetic error message and quit. Only in case 2b is there a difference in behavior, and this only if it can, in fact, access the existing DTD which it currently does not possess. But, it can only access the DTD if it's told where it is, and by my initial assumption, the original question is only talking about a boolean which does not give enough information for the tool to be able to access the DTD. So I end up saying that there is no reason to distinguish an instance with no DTD from one with an absent DTD, because with only the knowledge that an absent DTD exists (but without a pointer to it), there can be no difference in tool behavior. Date: Thu, 24 Oct 1996 17:28:35 -0500 From: Len Bullard To: Michael Sperberg-McQueen CC: W3C SGML Working Group Subject: Re: D.1 Distinguish partial and full DTDs? Michael Sperberg-McQueen wrote: > > On 30 October 1996, the ERB will vote to decide the following > question. A straw poll indicates the question needs further > discussion in the work group. > > D.1 What behavior should XML systems exhibit if no DTD, or only a > partial DTD, is given with a document? Separate these. A partial DTD sounds like a way to return errors if the instance contains undefined markup. An with no In particular, should there > be a way to distinguish a document instance for which a DTD exists > but is not given from an instance for which no DTD exists? No. Len Bullard Date: Thu, 24 Oct 1996 16:40:52 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: lauren@sqwest.bc.ca CC: w3c-sgml-wg@w3.org Subject: Re: documentation for UA interoperability | One of the things we haven't yet discussed (or did I miss something?) | is the interaction between different XML systems and what this might | necessitate in terms of documentation. Since I've spent a large amount | of time worrying about reverse-engineering the HTML DTD, this is | something I'd like to get clear from the beginning in XML. In HTML, | there is no need for documentation on elements, as long as all UAs | read and implement the HTML spec. This is not necessarily the case for | XML, where UAs will need documentation on elements to enable | interoperability. | | I don't know whether this should be in the XML spec itself, or in | ancillary documentation covering UA conformance. It seems pretty | obvious that this has to be documented, but I think it also needs to | be specified how, and what level of documentation is enough. Note that | when I say "DTD fragment", I mean "in whatever syntax". If I'm too | early in bringing this up now, just tell me and I'll repost at a more | suitable stage. This is an entirely legitimate concern, but one that probably belongs to a later stage of the effort. Maybe in Phase II (December-March) we can spin this off as a parallel project. Jon From: Charles@sgmlsource.com (Charles F. Goldfarb) To: gtn@ebt.com (Gavin Nicol) Cc: streich@slb.com, tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions Date: Fri, 25 Oct 1996 03:36:58 GMT On Wed, 23 Oct 1996 15:30:25 -0400, gtn@ebt.com (Gavin Nicol) wrote: >>By the way, I concur wholeheartedly with the opinions expressed by >>David and Lee. There are plenty of times when I could predict that >>the receiving system will not be able to render the character that I >>want them to see. Given that, a reasonable description of the character >>*could* suffice. Some meaningless number, would be just that-- >>meaningless. > >People other than David and Lee have this viewpoint. The problem >above is what led me to the GCR and GGR ideas a couple of years ago. Since you mention history, you might find it interesting that "the problem above" is what caused me to create SDATA in the first place. It happened during a phone conversation with Joan Knoerdel, who was creating the DTD for the AAP (which eventually became ISO/IEC 12083). The character entity sets in the standard were designed so that the replacement text would be a meaningfull character name in the cases where a renderable system-specific string wasn't provided in the entity declaration. I wanted to make my views clear because I've been suggesting techniques to make XML work, and be conforming to SGML, on both sides of this issue (and other issues). I personally believe that a user should be able to see the name, or description, of the character that the system couldn't render for him -- a number alone is useless without access to the appropriate character set standard. On the other hand, even if that name or description is in the DTD rather than the instance, some piece of software should be able to find it and give a useful error message. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: "Henry S. Thompson" Cc: Michael Sperberg-McQueen , W3C SGML Working Group Subject: Re: B.1 and B.2 results Date: Fri, 25 Oct 1996 03:36:55 GMT On Wed, 23 Oct 96 09:54:51 BST, "Henry S. Thompson" wrote: >In particular, I think Tim is at least misleading to say 'the >smokescreen about "it's the entity not the file" is just that'. Actually, it's the storage object, not the entity, and it isn't a smokescreen. The parser sees *everything* in the entity, but several entities can be stored in a single storage object. The storage object can contain things that aren't in any SGML entities. None of this is new; FSIs are just a new formalism for something we've always had. See notes 1 and 2 in clause 6.1 of ISO 8879. [295:2-8] -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: cbullard@HiWAAY.net Cc: Michael Sperberg-McQueen , W3C SGML Working Group Subject: Re: C.4 Undeclared entities? Date: Fri, 25 Oct 1996 03:36:47 GMT On Tue, 22 Oct 1996 12:20:18 -0500, Len Bullard wrote: >> Unfortunately, Charles used the term 'DTD' for the set of rules >> governing the use of a document type ... >Use? I won't argue 8879 legalese, but that is a strong >term that to me, implies, semantics. A DTD can't do that. >It can tell me if a production is valid with respect >to hierarchy, occurrence, frequency, id/idref, etc., >but says next to nothing, ye, nothing, about semantic use. >That is, in classical data structure fundamentals, the >operations that can be applied formally. > Just for the record, I never said any such thing. I just equated "DTD" to "document type definition" to disambiguate the prevalent misuse of DTD to refer to the external subset of the DOCTYPE declaration. In 8879, the term "document type" refers to semantics; a document type definition only deals with the application of SGML to the markup of documents of a particular type. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: B.10 Empty elements? Date: Fri, 25 Oct 1996 03:36:45 GMT On Sat, 12 Oct 96 15:09:33 CDT, Michael Sperberg-McQueen wrote: >On 16 October 1996, the ERB will vote to decide the following question. >A straw poll indicates the question needs further discussion in the work >group. > >B.10 What form should EMPTY elements take, if there are EMPTY elements >in XML: , (where '/' is assumed the NET string) >(7.3, 11.2.3)? > requires no changes to the SGML declaration. The DTD will need to contain (have I got this right, Michael) an "elephant's child" content model instead of the declared content EMPTY, but that won't break any SGML tools at all. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: gtn@ebt.com (Gavin Nicol) Cc: U35395@UICVM.UIC.EDU, John_Lavagnino@brown.edu, w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions Date: Fri, 25 Oct 1996 03:37:00 GMT On Wed, 23 Oct 1996 16:50:23 -0400, gtn@ebt.com (Gavin Nicol) wrote: >As I said earlier, SDATA, or some form of entity typing mechanism, >seems to me to be crucial to building a good distributed >character/glyph/font registry/resolution mechnism. I wish to be >able to do something like: > > > >and to be able to resolve/process that on my local system. That is what SDATA was designed for. But, you don't need the square brackets. I put those in the ISO character entity sets so that the replacement text would stand out in the processed output, as a convention to indicate that a glyph should be there instead. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: James Clark Cc: Michael Sperberg-McQueen , W3C SGML Working Group Subject: Re: Optional features considered harmful Date: Fri, 25 Oct 1996 03:37:06 GMT On Thu, 24 Oct 1996 21:32:46 +0000, James Clark wrote: >At 15:23 24/10/96 CDT, Michael Sperberg-McQueen wrote: > >>>It would be easier to make this work if we disallowed references to >>>external text entities in attribute values, but hopefully people can >>>live without those. >> >>Er, I'm sorry if I'm missing something, but doesn't clause 7.9.4.2 >>(p. 335 of Handbook) restrict ENTITY/ENTITIES attributes to >>data and SUBDOC entities? I.e. isn't your conditional already met? > >I'm talking about *references*; for example, > > > > Maybe that's the problem. In order for an external SGML entity to be ignored safely by the parser, it has to be a document entity (or subdoc, which for our purposes is the same thing). Therefore, if we restrict external SGML/XML entities to being referenced from attribute values, we can have reusable objects (as Eliot has pointed out) and we don't have to redefine the meaning of an entity reference.

As is shown in the following text: ...

Of course, "quoteref" is really a typed hyperlink, as is any "entity reference" that a parser can safely ignore. My conclusion: drop the optional entity references. We'll get them back in a robust and fully conforming form when we add hyperlinking. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: gtn@ebt.com (Gavin Nicol) Cc: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Date: Fri, 25 Oct 1996 03:36:48 GMT On Tue, 22 Oct 1996 12:39:17 -0400, gtn@ebt.com (Gavin Nicol) wrote: >As a note on undelcared entities. I proposed a while back on this >list that XML processors provide a fallback resolution mechanism: >namely that of trying to find an entity of the same same within >a catalog etc., and if found, treat it as being declared. > >My prime motivation is that with this mechanism, it is easy to >use XML within realtime systems, and without it, close to >impossible. > >It also seems to be intuitively correct. > If the entity is an SGML text entity, the declaration *must* be in the document or else different systems will produce a different ESIS from the same document. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Robert Streich Cc: "David G. Durand" (David G. Durand), W3C SGML Working Group , W3C SGML Working Group Subject: Re: C.12 types of declared values for attributes? Date: Fri, 25 Oct 1996 03:36:51 GMT On Wed, 23 Oct 1996 02:28:06 -0500, Robert Streich wrote: > >I agree wholeheartedly with Eve and Lee--multiple IDs are useful. Multiple IDs for an element would be nice to have in SGML97, but they are hardly essential for XML 1.0 and they would break SGML conformance. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: C.4 Undeclared entities? Date: Fri, 25 Oct 1996 03:36:49 GMT On Tue, 22 Oct 96 08:25:14 CDT, Michael Sperberg-McQueen wrote: >[Medium-long note. Executive summary: the discussion of 'implicit' >DTDs has served its purpose and can be ended without damage to >the process of designing and documenting XML 1.0.] O.K. It is now clear that in XML a document "without a DTD" means literally that, and not just "parsable without reference to its DTD". I think this is unfortunate because I believe it will render XML a non-starter in the marketplace. I hope someone can prove me wrong by rebutting the following proposition (formal mathematical proof not required): XML without a DTD is no different from HTML extended by the ability to "add tags and attributes" just by defining processing for the additions in a style sheet (cascading or otherwise). -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: gtn@ebt.com (Gavin Nicol) Cc: jjc@jclark.com, w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions Date: Fri, 25 Oct 1996 03:37:02 GMT On Wed, 23 Oct 1996 18:18:23 -0400, gtn@ebt.com (Gavin Nicol) wrote: >>Why can't you build your mechanism using normal elements >> >>'> >> >>? I don't find the argument that "my DTD may not have a glyph element" very >>convincing: most SGML DTDs are certainly going to need modifying to >>support XML. > >You *could* do this, but it is semantically incorrect in my books. It >is also a less interoperable solution (all systems would know that >SDATA was something special, but not all would necessarily know that > was to be replaced by characters). Also, the *requirement* of >DTD changes/additional is not one to be ignored either. I agree with Gavin: glyphs aren't elements. A better approach would be to define a "GetGlyph" storage manager with unicode, glyphid, and charid attributes: '> -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Robert Streich Cc: Michael Sperberg-McQueen , W3C SGML Working Group Subject: Re: C.14 Enumerations in attribute declarations? Date: Fri, 25 Oct 1996 03:36:54 GMT On Wed, 23 Oct 1996 02:28:53 -0500, Robert Streich wrote: > >Although I very much want this behavior so that I don't have to explain >to people why they have to use 1s and 0s in CALS table markup, I think we >should defer it to a future version of XML once the SGML revision has >been completed. I agree with Robert -- multiple enumerations are desirable, but not worth breaking conformance for. Another option would be to use the General Architecture "Lextype" declaration, which is standardized: where "YesOrNo" is a lexical type name for which a model is defined in a separate "lexical definition document". -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- Date: Fri, 25 Oct 1996 00:04:30 -0400 From: gtn@ebt.com (Gavin Nicol) To: Charles@sgmlsource.com CC: ht@cogsci.ed.ac.uk, U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results >>In particular, I think Tim is at least misleading to say 'the >>smokescreen about "it's the entity not the file" is just that'. > >Actually, it's the storage object, not the entity, and it isn't a >smokescreen. > >The parser sees *everything* in the entity, but several entities can >be stored in a single storage object. The storage object can contain >things that aren't in any SGML entities. > >None of this is new; FSIs are just a new formalism for something >we've always had. See notes 1 and 2 in clause 6.1 of ISO >8879. [295:2-8] Thank you Charles. This is a good clarification and is the way I understand things (the best kind of clarification is one that agrees with your position ;-)). I should note that a *further* reason for both FSI's and MIME-based storage managers is that email will potentially be an important delivery mechanism for XML. Both FSI's and MIME are perfectly suited for this. Date: Thu, 24 Oct 1996 23:57:46 -0400 From: gtn@ebt.com (Gavin Nicol) To: Charles@sgmlsource.com CC: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? >If the entity is an SGML text entity, the declaration *must* be in >the document or else different systems will produce a different ESIS >from the same document. I'd appreciate some more detailed explanation of the reasons for the ESIS differences, if you wouldn't mind. Date: Thu, 24 Oct 1996 22:06:23 -0700 (PDT) From: Bill Smith Subject: Re: C.4 Undeclared entities? To: w3c-sgml-wg@w3.org Charles Goldfarb wrote: > O.K. It is now clear that in XML a document "without a DTD" means literally > that, and not just "parsable without reference to its DTD". I think this is > unfortunate because I believe it will render XML a non-starter in the > marketplace. Yes without means as if it didn't exist - because it might not. As for XML being a non-starter as a result, I'd have to take the other side of the argument. DTDs add complexity and formalism where it isn't required. Useful applications based on extensible markup can be developed and successfully marketed without requiring DTDs. I and others have been there. It works. This doesn't mean that DTDs and formalism aren't useful or required in many applications. Quite the opposite is true and I would argue for the inclusion of DTDs for those applications. Strategically, DTDs are an essential part of XML but tactically, their inclusion at present is not timely. For those that require them now, ISO 8879 tools provide excellent support. > XML without a DTD is no different from HTML extended by the ability to "add > tags > and attributes" just by defining processing for the additions in a style sheet > (cascading or otherwise). Actually it would be slightly different. Structure would be explicit and obvious. HTML's ill-conceived constructs/quirks wouldn't be there. But other than that, the statement is accurate. XML would be a simple, extensible markup language. I won't attempt to rebut the proposition since I happen to agree with it. This is what XML 1.0 should be - perhaps with a few well-chosen additions. XML 2.0 should be where we bring in more of SGML's "useful" features. I suspect I'm alone in this opinion but I take "as simple as possible" quite literally. We can make XML a clean, simple, extensible markup language, HTML++ or we can turn it into something else, SGML--. To the masses, XML will need to be positioned as HTML++. Perhaps we should think that way too so that we can stop lamenting all those great SGML features that won't be included in XML 1.0. But they will be in XML 2.0. Date: Thu, 24 Oct 1996 17:04:58 -0500 From: Len Bullard To: James Clark CC: Tim Bray , w3c-sgml-wg@w3.org Subject: Re: Optional features considered harmful James Clark wrote: > > At 06:54 24/10/96 +0000, Tim Bray wrote: > >At 11:34 AM 24/10/96 +0000, James Clark wrote: > >>At 23:57 23/10/96 +0000, Tim Bray wrote: > >>>1. external text entities are a basic necessity for authoring ... > > > >>I would like to point that at least one person on the ERB (me) passionately > >>believes that this viewpoint is totally misguided... > >>... it is certainly possible to build a fine authoring > >>environment without any use of external text entities. > > > >James is correct; it is certainly possible to do this. But SGML provides > >a built-in, standard, nonproprietary way to go about it. The way I sell > >SGML in the corporate world is: > > > >SGML gives you: > > 1. a way to model the structure of your documents, and > > 2. a way to control the authoring so they come out right, and > > 3. a way to modularize documents for re-use and management, and > > 4. ALL OF THIS IS STANDARDIZED AND NON-PROPRIETARY > > > >It seems to me that if XML loses text entities, then #4 no longer applies > >to #3. > > I think you can get 3 and 4 without external text entities by using > transclusion via link semantics, which are going to be standardized in a > later phase of XML. > > James Agreed. When explaining external text entities to new SGML users, they invariably leap to the conclusion these are hypertext links. They are usually disappointed when I explain these are not. They then ask, why the extra features. We dropped these from the IADS and IDE/AS designs for precisely this reason: we were getting this functionality from the hyperlinks. Wouldn't an independent link with a semantic of do this job? len bullard To: James Clark From: Martin Bryan Subject: Re: B.10 Empty elements? Cc: w3c-sgml-wg@w3.org Date: Fri, 25 Oct 1996 06:54:55 +0100 At 11:02 AM 24/10/96 +0000, James Clark wrote: >Yes, you can. Using but does not require it. If emp is declared as EMPTY, then no end tag is >allowed whether you use . > But it still only works if you specifically restrict the use of NETs to EMPTY elements. How does an SGML system impose this constraint? ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Fri, 25 Oct 1996 10:39:50 +0000 To: Martin Bryan From: James Clark Subject: Re: B.10 Empty elements? Cc: w3c-sgml-wg@w3.org At 06:54 25/10/96 +0100, Martin Bryan wrote: >At 11:02 AM 24/10/96 +0000, James Clark wrote: > >>Yes, you can. Using >but does not require it. If emp is declared as EMPTY, then no end tag is >>allowed whether you use . >> >But it still only works if you specifically restrict the use of NETs to >EMPTY elements. How does an SGML system impose this constraint? It doesn't, but it doesn't matter to an SGML parser since it must have the DTD. It is the same situation as with other cases where XML imposes restrictions beyond those in SGML: an SGML parser will be able to parse the XML document, but will not be able to enforce the XML restrictions. James From: lee@sq.com Date: Wed, 23 Oct 96 22:47:15 EDT To: bill.smith@Eng, w3c-sgml-wg@w3.org Subject: Re: ERB decisions, 23 October 1996 > I find the introduction of "optional features" in XML most unfortunate I agree. This was a major issue for HTML. Content Negotiation for HTML variants is not generally available today, two and a half years after the first HTML working group meeting. Clearly you can't use any optional feature in a document to be published on the web if you have no control over the browser. If you have control over the browser and are starting with SGML, you can call +1 416 544 9000 and ask for Panorama OEM licensing :-) If you can't use optional XML features, they are better off not being there. > If entities are essential for XML to be useful as an authoring > language, than entities should be in XML 1.0. I don't subscribe to > that belief since I know of several "useful editors" that do not > support entities. Agreed on both counts (assuming you mean external entities) > Whatever happened to as simple as possible? That got thrown away with the decision to be SGML compatible :-) Lee Date: Fri, 25 Oct 1996 10:23:30 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: D.3 ANY-ELEMENT element-declaration keyword? At 2:09 PM 10/24/96, Michael Sperberg-McQueen wrote: >On 30 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the question needs further >discussion in the work group. > >D.3 Should XML specify short-hand element declaration keywords (e.g. >%ANY-ELEMENT;) for element content in which any element in the DTD >is legal (same as ANY, but element not mixed content)? This does not seem extremely useful to me... We allowed ANY, partly to ease the job of XML DTD generators. This does not server that purpose, as far as I can tell, nor does it lead to better DTDs, as far as I can tell. I say let users make this if they need it. -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html From: lee@sq.com Date: Wed, 23 Oct 96 23:53:32 EDT To: w3c-sgml-wg@w3.org Subject: Re: documentation for UA interoperability Lauren wrote: > One of the things we haven't yet discussed (or did I miss something?) is the > interaction between different XML systems and what this might necessitate in > terms of documentation. [...] > [...] In HTML, there is no need for documentation on elements, > as long as all UAs read and implement the HTML spec. This is not necessarily > the case for XML, where UAs will need documentation on elements to enable > interoperability. I would very much like to see a formal way of describing elements. At the very least, a short readable string. When a DTD is something private, used only within a department, the names don't matter too much. If I am publishing a DTD worldwide, people are going to create style sheets to view it, or set up conversion tables to filter it into porridge, and they need to know what the elements mean. I rule out the possibility of "put it in comments", as those are not normally fed back to a client of a parser. So it can go in an element or an entity. If we have entities in XML, you could do Lauren's examples seem closer to architectural forms, though. Will XML have architectural forms? I didn't think we had #FIXED attributes any more... Without inheritance, arch forms are awfully inelegant, it seems to me, but they are a kludge I could live with. Lee Date: Fri, 25 Oct 1996 10:23:33 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: D.4 parameter entities? At 2:10 PM 10/24/96, Michael Sperberg-McQueen wrote: >On 30 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the question needs further >discussion in the work group. > >D.4 Should XML allow parameter entities and parameter-entity >references? > * D.4 a. internal parameter entities? Since we are not allowing any new convenience features in DTDs (like mix-in markup), we will continue to require the old parameter-entity methods for creating extensions. This is a requirement, now, in my opinion. > * D.4 b. external parameter entities? I think that this is far worse for processors than external text entities, because they must be followed for the DTD to be useful (i.e. we cannot remove the serial dependencies as we have for external text entities). While it is sometimes useful to have external parameter entities, for most projects one can live without them. On balance we should drop this, or reconsider it in 2.0 in light of how hard it was to live without (and for how many people it was hard). RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html From: lee@sq.com Date: Fri, 25 Oct 96 00:58:17 EDT To: w3c-sgml-wg@w3.org Subject: A note on case sensitivity Some notes on case sensitiveness, and arguing that XML should use one of (1) US ASCII for all SGML names and ID values, or (2) NAMECASE NO -- i.e., all names case to be sensitive. Note that URLs are case sensitive today, including (I think) the #Percy notation used in HTML to find an "id" such as . HTML users are thus used to case sensitive attributes. (some elements and other attributes used to be case sensitive because of Mosaic/Netscape bugs, by the way, but I think they are all fixed now). Now... Case insensitivity is not well defined for Unicode/ISO 10646 as a whole and really only makes sense when you have a specific language -- but cross references from a French section to a Swedish section of a document might then have different rules for case sensitivity (whether accents are retaind in upper case, for example). The POSIX model is being extended, but POSIX does not deal with multilingual documents or environments. For example, in a POSIX regular expression, [:lower:] matches lower case letters as determined by the current locale. The POSIX model does not address multilingual environments at all, and explicitly says so. Thus, if you are a Frenchman in Paris (say) reading a French document >from Quebec, you can only set LOCALE to one value, despite the different capitalisation rules in Quebec (accents are retained, E is not the same as E-acute) and France (accents are dropped, e and e acute map to E). So an id of "m&ehat;l&eague;e" maps to MELEE in France, but to ME^LE'E (I'll put the accents like this rather than using 8-bit characters) in Quebec, so that in France an ID of "MELEE" would be matched by the lower case IDREF I have given, but not in Quebec. So ISO 10646 values are best if they are case sensitive, so the parser does not have to understand the complex rules for mapping equivalence classes. There is a discussion of this right now on the www-internationalisation list, and also in www-style inasmuchas the HTML CLASS attribute may have to be case sensitive. In SGML, we have 13.4.5 Naming Rules, where the SGML process of case conversion is described. It doesn't work in the cases I have described, which are not uncommon, especially with distributed authoring over a network... In particular, you can specify an SGML declaration when you create the document, such that capitalisation works, as long as the entire document is authored in the same language. Worse, you are not allowed to include lower case letters or upper case letters in LCNMCHAR and friends, so you can't map e acute to E (or am I mistaken??). (LC Letter and UC Letter are defined in Figure 1 on p. 29 as a-z and A-Z; upper and lower case letters are defined in section 4; the restriction is in section 13.4.5 just after the NAMECASE definition) If name conversion can't be made to work correctly, don't do it at all. There are no surprises that way. SGML users may be confused, perhaps -- but no more so than with , which, although it has not been accepted (and I still prefer <@e>!!), is more incompatible with an unmodified SGML declaration. Lee From: lee@sq.com Date: Wed, 23 Oct 96 23:21:30 EDT To: gtn@ebt.com, jjc@jclark.com Subject: Re: ERB decisions on A.17, B.9, and other questions Cc: w3c-sgml-wg@w3.org There's a little proposal at the end of this message, don't blink! > >Why can't you build your mechanism using normal elements > >'> Before doing that, I'd much rather see XML use WSDs, with very little extra complexity. Once you have WSDs, you can do away with entities altogether, and use the (is it refloc?) idea of reusable parts of a document -- The hangars at Cardington are very large!

Later in our document, the intrepid hero says Now entities are subsumed in a more general mechanism that is no harder to implement -- anything with an id.reuse attribute gets squirreled away for later, and not shown. Then later you can reuse them all, just like entities. However, we now have entities with an obvious way to include < > & % " and ' all at the same time :-), and can edit the markup inside them. (assuming that's the right /> syntax -- it's going to be a little confusing for URLs in attributes: so I'll use <@image> instead for my examples, for now) In this case, you could have something like latin small letter a with acute accent

á
Here is an <@reuse ref.reuse="aacute" child="form"> priori example! I have gone one teensy step further and allowed a single child to be specified on the @reuse element; the idea is that you look for the id.reuse and then descend to the child. The ID could be on the
instead. (I've mangled the TEI WSD slightly for this example; you can ask me about that privately if you like!) So this is a two-part proposal: (1) build element reuse into XML. This is powerful & flexible, but no harder to implement (if I am not mistaken) than the entity syntax. (2) use this mechanism to provide textual descriptions for (the equivalent of) entities, in a manner similr to the TEI WSD. Note that this approach is compatible with existing SGML implementations; although not all SGML systems support element reuse, they do all support putting elements in your document and parsing them! Lee From: lee@sq.com Date: Fri, 25 Oct 96 00:39:26 EDT To: Charles@sgmlsource.com, streich@slb.com Subject: Re: C.12 types of declared values for attributes? Cc: dgd@cs.bu.edu, w3c-sgml-wg@w3.org > Multiple IDs for an element would be nice to have in SGML97, > but they are hardly > essential for XML 1.0 and they would break SGML conformance. I agree. You can always use CDATA instead and kludge it in the application. I would argue, in fact, that XML might as well not have an ID attribute type at all. Just CDATA. Then have an application convention that a string in an attribute of the form ref.xxx refers to a corresponding (case sensitive) string in an attribute of the form ref.xxx, where the xxx must be the same in both cases. When the arbitrary restriction is lifted in SGML 97, you can declare the IDs to be IDs instead of CDATA if you like. This proposal works without a DTD, and with a DTD gives documents that parse correctly in SGML. Note: I was going to write a short note on case sensitivity, but it grew too long to fit in the margin, and will follow. Lee From: lee@sq.com Date: Thu, 24 Oct 96 12:00:09 EDT To: jjc@jclark.com, tbray@textuality.com Subject: Re: Optional features considered harmful Cc: w3c-sgml-wg@w3.org > At 23:57 23/10/96 +0000, Tim Bray wrote: > >1. external text entities are a basic necessity for authoring [...] James wrote: > I would like to point that at least one person on the ERB (me) passionately > believes that this viewpoint is totally misguided. Well, I'm not on the ERB, but I do not believe that external text entities are essential for authoring. That there are people who rely on them shows how poor our SGML tools are right now, I suppose. A system like Astoria is (at least in principle -- I haven't used Astoria) far better for authoring. Or should be. You can do text entities server-side if you like using a short perl script. Some web servers do this already, with either procesing instructions or coments -- works in the Apache and (I think) NCSA servers today. Lee From: lee@sq.com Date: Thu, 24 Oct 96 17:37:24 EDT To: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: D.1 Distinguish partial and full DTDs? > D.1 What behavior should XML systems exhibit if no DTD, or only a > partial DTD, is given with a document? There are four cases worth considering for partial DTDs: (1) the DTD covers everything in the instance (e.g. it's a subset of DOCBOOK) This is a full DTD as far as the instance is concerned... (2) there are elements in the instance not in the DTD, or attributes, entities, or other wilde beasties. But at least some names in the DTD correspond to the instance. The DTD, in other words, is a strict subset of the one that an SGML parser would need to parse and accept this instance. In this case, there are two main possibilities. (2a) the undefined names are errors; the instance (or DTD) is invalid (2b) the undefined names are accepted, as if they were declared automatically and implicitly. I would strongly favour 2b. (3) there is a DTD, but no names in the instance are actually used in the document. This is indistinguishable from having the wrong DTD, and arguably could be an error. But in practice it is the same as having no DTD, for all the good it does. (4) there is no DTD. This is the case if a partial DTD is actually empty, for example. It seems to me that cases 2, 3 and 4 are all similar in that there are names in the instance that have not been explicitly declared in an actual manifestation of a DTD. If case (4) is supported, cases (2) and (3) also should be supported, and route (2b) should be taken. > In particular, should there > be a way to distinguish a document instance for which a DTD exists > but is not given from an instance for which no DTD exists? I think that's a question of philosophy. You can only distinguish between where you have or can get a DTD, and where you don't have one and can't get one. If you don't have a DTD, you're in the same position as if you had an empty DTD. You can read (as long as we don't screw up the XML definition) but not validate. If you work with SGML tools, you'll of course have a program to create an SGML DTD from an XML instance, as otherwise you couldn't use XML files with SGML tools. Lee Date: Fri, 25 Oct 1996 10:47:57 -0400 To: W3C SGML Working Group From: "David G. Durand" (David G. Durand) Subject: Re: C.4 Undeclared entities? At 11:36 PM 10/24/96, Charles F. Goldfarb wrote: >O.K. It is now clear that in XML a document "without a DTD" means literally >that, and not just "parsable without reference to its DTD". I think this is >unfortunate because I believe it will render XML a non-starter in the >marketplace. I'm dubious about this. See below. >I hope someone can prove me wrong by rebutting the following proposition >(formal >mathematical proof not required): > >XML without a DTD is no different from HTML extended by the ability to >"add tags >and attributes" just by defining processing for the additions in a style sheet >(cascading or otherwise). This is exactly correct, except that XML allows you to create a DTD, and HTML does not. Thus you have an opportunity to organize your tag salad, once you realize that you want to keep your Garbazos from getting mixed up with your Succotash. Given the relative success of HTML and SGML in the marketplace of the Web, I'll take my chances with a DTD-less option for XML. I also thing that automatic DTD generation will be a useful tool to help naive users develop DTDs by starting with example documents. -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html From: R A Milowski Subject: Re: Optional features considered harmful To: w3c-sgml-wg@w3.org Date: Fri, 25 Oct 1996 09:48:23 -0500 (CDT) W. Eliot Kimber (kimber@passage.com) wrote: > But note that general text entities *don't actually do point 3*. General > text entities *ARE NOT REUSABLE*. In fact, the only way to have re-usable > SGML documents, as James has pointed out, is to make them documents > syntactically (even if the objects may be semantically subparts of documents). > > While external text entities are a useful convenience for single-person > authoring, they are not useful as a general mechanism for managing SGML > data as re-usable objects. Although I would agree that external text entities have a whole host of problems and that hyper-link provides a better re-use model, external text entities can be managed quite well via a component model. If you can decide what your re-usable components are before you author them--which is necessary in a large authoring environment--you can setup systems for managing and validating these components. So, I wouldn't rule out external text entities for reuse unless we demanded HyTime and created a *required* application convention to handle inclusion of information. As an aside, according to Church's thesis and the Godel Incompleteness Theorems documents with external text entities that are variable are never verifiable. Documents with hyper-links to variable documents are, of course, verifiable. The argument goes something like this: 1. Those things that are computable in our sense are those things that are computable by humans or machines given that limitations on time and speed are overcome. (Church's Thesis) 2. Godel's theorem states: There is no consistent, complete, axiomatizable extension of Q--where Q is in our case the set of functions necessary to parse an SGML document. In our sense, extensions include asking the question "will this document parse under all instances of entity x that conform to constraints y". 3. If the constraints y on entity x allow x to have infinite variants, then proof (program) of the question of validation is not both complete and consistent at the same time. You can never validate an infinite number of variants but you could attempt to prove that the document will always be valid. 4. Thus, although one could be bright enough to prove that for all variants of a particular x, this particular document is valid, it is not necessary that such a proof exists or that such axioms that make up the proof will apply in all cases. 5. Hence, there is no program that can prove that a document containing a set of variant external entities can be proven, given a set of constraints on the external text entities, that the resultant document is valid. In a sense, the hyper-linked approach gets us closer to a verifiable system in that each component--variable or not--can be validated independent of each other. The approach would be simpler to saying: "You can either compile all your C++ code at once and, if everything compiles, you get your program, or you can break your code into verifiable modules and compile them separately. There is no guaranty that they will fix together or that the resultant program--while valid C++--will be semantically correct. Unfortunately, you will never be able to verify the semantics of your program unless you can get it compile and link!" See "Computability and Logic" by George S. Boolos and Richard C. Jeffrey for a much better description of the above. ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@copsol.com Copernican Solutions Incorporated (612) 379 - 3608 Date: Fri, 25 Oct 1996 10:48:03 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: C.12 types of declared values for attributes? >I agree. You can always use CDATA instead and kludge it in the application. > >I would argue, in fact, that XML might as well not have an ID attribute >type at all. Just CDATA. Then have an application convention that a >string in an attribute of the form ref.xxx refers to a corresponding >(case sensitive) string in an attribute of the form ref.xxx, where the xxx >must be the same in both cases. I prefer this to any of the options we have discussed. We should eliminate ID/IDREF altogether, add Lee's application convention, and generate warnings for attbitues called "ref.whatever" whose value does not occur on as the value of a "whatever" attribute elsewhere in the document. We can add ID/IDREF declarations once SGML97 comes out. XML need never have them, but the SGML import process will be able to create them automatically. >This proposal works without a DTD, and with a DTD gives documents that >parse correctly in SGML. Exactly! very nice! -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Fri, 25 Oct 1996 11:18:27 -0400 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: D.1 Distinguish partial and full DTDs? [Summary. Disagreement with case analysis. I see two cases: DTD given, in which case we can validate (if we can get the DTD), or not. DTD not given, in which case validation is never an option. No need to tell application about existence of DTDs absent some kind of access handle (agreement with Lee, I think).] At 5:37 PM 10/24/96, lee@sq.com wrote: >> D.1 What behavior should XML systems exhibit if no DTD, or only a >> partial DTD, is given with a document? > >There are four cases worth considering for partial DTDs: >(1) the DTD covers everything in the instance > (e.g. it's a subset of DOCBOOK) > > This is a full DTD as far as the instance is concerned... Sure. I wish we could complain about missing element declarations, but we can't so we might as well live with it. >(2) there are elements in the instance not in the DTD, or > attributes, entities, or other wilde beasties. But > at least some names in the DTD correspond to the instance. > The DTD, in other words, is a strict subset of the one that > an SGML parser would need to parse and accept this instance. > > In this case, there are two main possibilities. > (2a) the undefined names are errors; the instance (or DTD) is invalid > (2b) the undefined names are accepted, as if they were declared > automatically and implicitly. > > I would strongly favour 2b. I would strongly favor 2a. By making the DTD optional, we let people be lazy about declarations. But once they create declarations, they've made a commitment to structure, and should be (at least) of violations of that structure. A DTD is supposed to constrain documents. That's why we made it optional, but that's also why, if present, it should have teeth. That's also why I don't like the notion of "partial DTD" that creates a situation where I have to do 2b, because I'm lacking _some_ declarations. I guess that this means that it's a validation error, as we will not be able to prevent non-validating applications from implementing 2b. >(3) there is a DTD, but no names in the instance are actually used > in the document. This is indistinguishable from having the > wrong DTD, and arguably could be an error. But in practice it > is the same as having no DTD, for all the good it does. A validation error becuase of undeclared elements (in the presence of declarations). >(4) there is no DTD. This is the case if a partial DTD is actually > empty, for example. This is OK, because without a DTD, the notion of validation is vacuous. All instances are legal, if they meet instance syntax restrictions. >It seems to me that cases 2, 3 and 4 are all similar in that there are >names in the instance that have not been explicitly declared in an >actual manifestation of a DTD. If case (4) is supported, cases (2) and >(3) also should be supported, and route (2b) should be take. I lump them differently, into two basic cases: DTD given (and validation reports undeclared instance stuff) And partial DTDs are malformed if the instance refers to undeclared stuff. DTD not given: Anything goes, and validation errors are neve given (only basic XML instance syntax errors). >> In particular, should there >> be a way to distinguish a document instance for which a DTD exists >> but is not given from an instance for which no DTD exists? >I think that's a question of philosophy. You can only distinguish >between where you have or can get a DTD, >and where you don't have one and can't get one. I agree. If the DTD exists, you should have some kind of reference to it (that you may ignore, or that might be broken). >If you don't have a DTD, you're in the same position as if you had >an empty DTD. You can read (as long as we don't screw up the >XML definition) but not validate. Sure. >If you work with SGML tools, you'll of course have a program to >create an SGML DTD from an XML instance, as otherwise you couldn't >use XML files with SGML tools. Yep. I think this will be a useful XML tool, as well. So I think what we really have is a two phase process: Parse, which uses instance syntax, and produces a basic data structure. This can always be done with no DTD information. Validate, that takes a DTD and determines that the instance matches it. Only possible when the DTD exists and is accessible. Applications can't use information of the form there is a DTD, but I'm not giving you a chance to access it, so it should not be included. -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html From: lee@sq.com Date: Fri, 25 Oct 96 11:39:52 EDT To: bill.smith@Eng, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? > I suspect I'm alone in this opinion but I take "as simple as possible" quite > literally. No, you're not alone. > We can make XML a clean, simple, extensible markup language, HTML++ > or we can turn it into something else, SGML--. Well, I for one would vote for the cleam, simple extensible markup language rather than HTML++ or SGML--, out of the three options you give. Obviously HTML++ would have to build on the long-defunct HTML+ draft. I've just been working on a small CGI-based "database" (it uses perl and grep to do things like an address book). The internal files are all text files, and use things like contacts People in the SGML industry address multiline full There are no attributes, empty elements or entities, so that "parsing" in perl was a matter of if (// .. /<\/Database/) { if (/(.*)<\/name>/) { print "database name: $1\n"; } } Now, this isn't a major engineering project, and perhaps this isn't even a valid use of XML, and I should go back to the IAFA Template or RFC822 format that I would normally use: Database: { Name: contacts Description: People in the SGML industry } Fields: { Field: { Name: address type: multiline search: full } } which is just about as easy to parse, allows spaces in field names, and I'm less likely to be accused of abusing SGML :-) For me, that which I have just shown is as simple as possible. It is not internationalised. File: element_sequence ; element_sequence: | /* empty */ ; element : start_tag contents end_tag ; contents : element | text | contents | /* allowed to contain nothing */ ; This idea in itself is powerful. It is also sufficiently powerful to represent the same set of structures represented by SGML (with the exception of CDATA marked sections, unless you allow \< to escape a <) Anything else is syntactic sugar. yyy can be written as xxx yyy So the question is, how much sugar do we need? One step simpler for me is either the Fields: {} structure or a LISP-like syntax, but neither of those allows robust error-recovery, and since I consider that essential, what I have shown is for me minimal. The people who think more is needed probably aren't implementing it, or they already have 10,000+ lines of code to parse SGML, and don't mind if the language is the same. I'd really like to see a world in which most or all tools interoperated. I think we had an opportunity to start that here. But it won't happen with the XML I'm hearing about. Lee Date: Fri, 25 Oct 1996 08:43:16 -0700 To: W3C SGML Working Group From: Tim Bray Subject: Re: C.4 Undeclared entities? At 03:36 AM 10/25/96 GMT, Charles F. Goldfarb wrote: >O.K. It is now clear that in XML a document "without a DTD" means literally >that, and not just "parsable without reference to its DTD". I think this is >unfortunate because I believe it will render XML a non-starter in the >marketplace. ... >XML without a DTD is no different from HTML extended by the ability to "add tags Here's the problem. Our design goals say that you ought to be able to *process* an XML instance without a DTD. I think in these webful days, almost everyone agrees that this is useful and not intrinsically harmful. Given this, from the point of view of certain applications, the existence of the DTD becomes moot. If I am a browser and I want to display without parsing, and the says that I don't need any of the DTD to produce the correct ESIS, then I really don't care about the contents of the external or internal subset. If it didn't exist, I wouldn't notice. Whether in fact there is much, other than display, that you can usefully do to an SGML document without having a DTD, is something that only the market will decide. Since XML offers DTDs and validation, it is clearly more than "HTML with extra tags". Whether the market decides to use it mostly as SGML-- or HTML++ is a prediction I'm way too battle-scarred to even consider making. I am, however, pretty sure that it's probably wise to write the spec in such a way as to leave that choice up to the market. What we have to decide for now is what (if anything) we need to say in the XML spec to guide the actions of a browser or suchlike app that doesn't happen to be using a DTD. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 From: lee@sq.com Date: Fri, 25 Oct 96 11:47:12 EDT To: jjc@jclark.com, mtbryan@sgml.u-net.com Subject: Re: B.10 Empty elements? Cc: w3c-sgml-wg@w3.org > >How does an SGML system impose this constraint? > > It doesn't, but it doesn't matter to an SGML parser since it must have the > DTD. Doesn't anyone here use SGML editors? How is your unmodified SGML editor going to deal with this? Both Adept and A/E understand NET when they read SGML, and both products will normalise and write out SGML with no NET tags. My <@e> suggestion (adding @ as a UCNMSTRT or LCNMSTRT character) will at least let you create XML files with existing SGML tools. Although if the \< suggestion is adopted, RS/RE changed, and there is no DTD, and there are processing instructions at the start that tell you the character set, I expect you'll need a conversion program anyway. Lee From: streich@austin.sar.slb.com Date: Fri, 25 Oct 96 10:34:45 CDT To: w3c-sgml-wg@w3.org, dgd@cs.bu.edu Subject: Re: C.12 types of declared values for attributes? > >I agree. You can always use CDATA instead and kludge it in the application. > > > >I would argue, in fact, that XML might as well not have an ID attribute > >type at all. Just CDATA. Then have an application convention that a > >string in an attribute of the form ref.xxx refers to a corresponding > >(case sensitive) string in an attribute of the form ref.xxx, where the xxx > >must be the same in both cases. > > I prefer this to any of the options we have discussed. We should eliminate > ID/IDREF altogether, add Lee's application convention, and generate > warnings for attbitues called "ref.whatever" whose value does not occur on > as the value of a "whatever" attribute elsewhere in the document. Since a browser, search engine, etc. *shouldn't* validate and thus *can* do without the DTD, and since an editor *should* validate and thus *should* have the DTD, I don't see any benefit in having such a generalized application convention. I don't mind using a few key names which are already effectively linked to some semantic definition, but I'm uncomfortable with extending this to a generalized solution. I also don't really like the idea of partitioning the namespace. What I had in mind for XML was another attribute where you could specify additional IDs. This would be an application convention and you could retain SGML compatibility by using one of the tokenized data types like NAMES or NMTOKEN. The application convention would be that the values on this attribute would be added to the ID namespace. I don't feel too strongly about this feature, however, since any good browser should be able to join arbitrary namespaces in its stylesheet language. You don't have any assistance on the authoring side, but I've overcome this in the past. bob Date: Fri, 25 Oct 1996 08:55:40 -0700 To: lee@sq.com, jjc@jclark.com From: Tim Bray Subject: Re: Optional features considered harmful Cc: w3c-sgml-wg@w3.org At 12:00 PM 10/24/96 EDT, lee@sq.com wrote: >Well, I'm not on the ERB, but I do not believe that external text entities >are essential for authoring. I don't think anybody says SGML external text entities are essential for authoring. A method for modular construction of documents *is* essential for authoring, and SGML text entities provide a portable, vendor-independent method for doing this. Lots of other non-portable, proprietary methods could (and have been) thought of ("Master Document View", anyone?). >That there are people who rely on them shows how poor our SGML tools are >right now, I suppose. A system like Astoria is (at least in principle -- >I haven't used Astoria) far better for authoring. Or should be. 1. authoring tools could indeed be better 2. once they stop having to worry about a lot of the hard stuff we're cutting out of SGML, then they can focus more attention on basic things like modular document construction 3. last time I saw Astoria was a year ago, but I thought their approach [component management at the *element* level] was brutally difficult to accomplish and didn't offer any advantages over a slick entity-management system. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Fri, 25 Oct 1996 09:04:04 -0700 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: D.1 Distinguish partial and full DTDs? Right now, XML distinguishes "well-formed" and "valid" documents. "Well-formed" may require recourse to part of a DTD, for example entity declarations and [depending on EMPTY syntax] EMPTY declarations. However, If you ask an XML processor to validate an instance, that means that the appearance of an undeclared element is an error, period. An undeclared tag could be the result of (1) a typographical error while typing in XML source with Notepad [it *will* happen], or (2) a missing declaration in the DTD. It is not the job of an XML processor to intuit which is the case. More concisely, I do *not* favor partial DTD's in the context of validation. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 To: lee@sq.com, w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: A note on case sensitivity Date: Fri, 25 Oct 1996 17:12:50 +0100 At 12:58 AM 25/10/96 EDT, lee@sq.com wrote: >Case insensitivity is not well defined for Unicode/ISO 10646 as a whole >and really only makes sense when you have a specific language -- but >cross references from a French section to a Swedish section of a >document might then have different rules for case sensitivity >(whether accents are retaind in upper case, for example). This is one of the downsides of allowing ISO 10646 for attribute and element names that has to be faced: either you make naming conventions locale specific or you drop case matching. I feel that the advantages that XML could offer by providing for a full range of 10646 characters for naming, etc, more than outway the disadvantage of having to be case sensitive in element and attribute names, etc. For the ERN extensions for SGML another pair of classes, NAMESTRT and NAMECHAR, was introduced for languages where there is no equivalence between uppercase and lowercase (e.g. CJK languages). Whilst this covers a large number of languages it does not cover the Quebec/France variants lee mentioned. This example is one reason why the concept of document specific case rules becomes important in multilingual document sets. Swedisn and French, for example, should not be in the same "document" but should be separate linked segments of a document with their own character set case rules. The question is how do you link them together. In SGML they cannot be subdocuments of a master document because subdocs must share an SGML declaration with the calling document. This is one of the "unnecessary" restrictions that SGML97 should address. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Fri, 25 Oct 1996 09:30:29 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: C.4 Undeclared entities? [Charles Goldfarb:] | I hope someone can prove me wrong by rebutting the following | proposition (formal mathematical proof not required): | | XML without a DTD is no different from HTML extended by the ability to | "add tags and attributes" just by defining processing for the | additions in a style sheet (cascading or otherwise). A well-formed XML document without a DTD describes a logical tree of arbitrary depth. HTML does not, unless you overload the DIV tag in ways that are horrible to contemplate. This is a difference. [Tim Bray:] | Whether in fact there is much, other than display, that you can | usefully do to an SGML document without having a DTD, is something | that only the market will decide. Some of us have already decided. I put documents totalling hundreds of thousands of pages of SGML online using a tool in which the DTD was optional except for EMPTY elements and entity declarations. The result supported every operation that I wanted to perform on those documents, including a variety of rather complex structural queries. While there are no doubt many applications for which such a system would be inadequate, I found that SGML without a DTD provided me with everything that I wanted SGML to do as a publishing medium, with the single exception of validation. A lot of other DynaText/DynaWeb users found this out, too. I predict that a lot of XML users will come to the same conclusion. Jon Date: Fri, 25 Oct 1996 12:01:35 -0500 From: Len Bullard To: Jon Bosak CC: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Jon Bosak wrote: > > While there are no > doubt many applications for which such a system would be inadequate, I > found that SGML without a DTD provided me with everything that I > wanted SGML to do as a publishing medium, with the single exception of > validation. A lot of other DynaText/DynaWeb users found this out, > too. I predict that a lot of XML users will come to the same > conclusion. No quarrel. Just keep in mind that validatibility and parameterizing the editor are very powerful requirements in the minds and contracts of others who will be buying these systems. I noted this to Michael and I note it to the list, without provably correct well-formed instances where that correctness is tested under conditions of a formal agreement whose own validity is testable, XML is a non-starter. The PDF/Formal Fixed Non-Revisable guys will have a field day. Whether correct by test, or correct by construction, formal legal proof is required. A DTD is easier to build than a test script and much easier to share and interoperate. C'mon guys. You are screwing this pooch just to prove who has the smallest parser. Kind of macho in reverse. len Date: Fri, 25 Oct 96 15:13:25 CDT From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: A note on case sensitivity > From: Martin Bryan > > At 12:58 AM 25/10/96 EDT, lee@sq.com wrote: > > >Case insensitivity . . . > > I feel that the advantages > that XML could offer by providing for a full range of 10646 characters > for naming, etc, more than outway the disadvantage of having to be case > sensitive in element and attribute names, etc. > > . . . Make mine a vote against NAMECASE GENERAL NO. In fact, I would say that XML should allow only NAMECASE GENERAL YES. Much as I'm used to case sensitivity (e.g., on Unix), I think we'll be stepping into all sorts of problems with NAMECASE GENERAL NO. There are many tools out there that assume case insensitivity of element and attribute names as well as NAME-type attribute value tokens. Just stop and think of all the DTDs out there that use the lowercase "o" in the omitted tag minimization field of an element declaration--this won't parse with NAMECASE GENERAL NO in force. I bet a fair number of the style sheet processors out there that will find they run into subtle problems with NAMECASE GENERAL NO. And most SGML users will be very surprised with case sensitivity of element and attribute names. If we want to define XML so that it doesn't work with existing tools and doesn't work with existing DTDs and document instances and doesn't benefit from the knowledge base of the existing SGML users, then we can consider making elements, attributes, and name tokens in attribute values case sensitive. Case sensitivity in and of itself isn't bad. But given the context in which XML is being born, I'd recommend against NAMECASE GENERAL NO at least for XML 1.0. Date: Fri, 25 Oct 1996 13:04:38 -0400 From: Derek Denny-Brown To: w3c-sgml-wg@w3.org Subject: Re: documentation for UA interoperability From: lee@sq.com > Lauren wrote: > I would very much like to see a formal way of describing elements. This would be a *very good thing*, but it is just a subset of the problem of comments in a declaration. All that is really needed is a formal specification for relating comments in a declaration to some part of that declaration. The problem with SGML right now is that in the case of: it is unclear what the comment is meant to apply to. If there were a formal way of determining what part fo the declaration the comment applied to, it would be easy for the parser to return the comment, associated to it's context. This formal defintion could (easily?) be part of the parsing specification for the DTD. > I rule out the possibility of "put it in comments", as those are not > normally fed back to a client of a parser. The reason parser don't normally feed back the comments is because comments are ignored markup in SGML. The only way to return the comments is to return the markup, and even then, you are faced with the ambiguity question I raised above. > Will XML have architectural forms? > I didn't think we had #FIXED attributes any more... > > Without inheritance, arch forms are awfully inelegant, it seems to me, > but they are a kludge I could live with. I think it would be a mistake to define XML such that we lost architectural forms. I see architectural forms as realizing there potential in exactly such an environment as XML is being designed for (ie. dynamic data interchange between systems). -enjoy, derek --> Derek E Denny-Brown II <--- SGML/HyTime/DSSSL/WWW/C++/Perl/etc. "technical staff" @ TechnoTeacher, Inc. --> A smart cartoon never stagnates in one place long enough for a safe/piano/etc to fall from the sky and squash it. From: Charles@sgmlsource.com (Charles F. Goldfarb) To: gtn@ebt.com (Gavin Nicol) Cc: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Date: Fri, 25 Oct 1996 21:36:50 GMT On Thu, 24 Oct 1996 23:57:46 -0400, gtn@ebt.com (Gavin Nicol) wrote: >>If the entity is an SGML text entity, the declaration *must* be in >>the document or else different systems will produce a different ESIS >>from the same document. > >I'd appreciate some more detailed explanation of the reasons >for the ESIS differences, if you wouldn't mind. SGML text entities are parsed in the same context as the document that references them and the parsed replacement text becomes part of the ESIS. Within the ESIS, there is no indication that they existed as separate entities. If the declaration is not in the document, there is no way to identify the entity, and therefore no way to assure that two different systems will use the same replacement text. If they don't, there will be two different ESISs. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: bosak@atlantic-83.eng.sun.com (Jon Bosak) Cc: w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com Subject: Re: C.4 Undeclared entities? Date: Fri, 25 Oct 1996 21:36:52 GMT On Fri, 25 Oct 1996 09:30:29 -0700, bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) wrote: >[Charles Goldfarb:] > >| I hope someone can prove me wrong by rebutting the following >| proposition (formal mathematical proof not required): >| >| XML without a DTD is no different from HTML extended by the ability to >| "add tags and attributes" just by defining processing for the >| additions in a style sheet (cascading or otherwise). > >A well-formed XML document without a DTD describes a logical tree of >arbitrary depth. HTML does not, unless you overload the DIV tag in >ways that are horrible to contemplate. This is a difference. But not enough to win out against "HTML with user extensions via style sheet". To teach the value of "a logical tree of arbitrary depth" we need to teach the value of structure and document types. This case is weakened significantly if we don't require DTDs and offer the possibility of validation of all XML documents. We needn't (shouldn't) require validation at rendition time, but there should always be a DTD that can be accessed for editing and/or validation. Without it, XML won't be a sufficient improvement on HTML to win a significant market. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: D.2 DTD summaries (a la NSGML)? Date: Fri, 25 Oct 1996 21:36:58 GMT On Thu, 24 Oct 96 14:09:05 CDT, Michael Sperberg-McQueen wrote: >On 30 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the question needs further >discussion in the work group. > >D.2 Should XML provide shorthand ways of summarizing the salient >points a document's DTD? > > * empty elements > * mixed-content or element-content elements > * required attributes > * default attribute values > * identity of ID and IDREF(S) attributes > * identity of CONREF attributes (if allowed) > * other? No. Use the simplified markup declaration syntax. >If so, > * D.2 a. Should such short-hand summaries be required? No. The DTD can be used if they aren't present. > * D.2 b. Allowed in place of DTDs? Yes. If you must have them, they cannot coexist with DTDs for the reason given below. > * D.2 c. Allowed in addition to DTDs? No, because the two could conflict. > * D.2 d. If so, is inconsistency between the DTD and the summary > an error? Yes. > * D.2.e. A reportable error? Yes, which would require you to parse both of them, so why have the shorthand. Conclusion: Stick with DTDs, but allow the external subset or all of the DTD to be ignored if not needed to parse the document instance. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- Date: Fri, 25 Oct 1996 15:02:44 -0700 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: documentation for UA interoperability At 11:53 PM 10/23/96 EDT, lee@sq.com wrote: >Will XML have architectural forms? >I didn't think we had #FIXED attributes any more... I can't find the vote, but I'm pretty sure that XML *does* have #FIXED attributes. Someone else from the ERB shout if I'm wrong. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Fri, 25 Oct 1996 15:12:32 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: C.4 Undeclared entities? [Charles Goldfarb:] | >A well-formed XML document without a DTD describes a logical tree of | >arbitrary depth. HTML does not, unless you overload the DIV tag in | >ways that are horrible to contemplate. This is a difference. | | But not enough to win out against "HTML with user extensions via style | sheet". To teach the value of "a logical tree of arbitrary depth" we | need to teach the value of structure and document types. There is a difference between the concept of structure and the concept of document types. They are both valuable concepts, but they are not joined at the liver. | This case is weakened significantly if we don't require DTDs and offer | the possibility of validation of all XML documents. There is a difference between requiring DTDs and making it possible to validate XML documents. | We needn't (shouldn't) require validation at rendition time, but there | should always be a DTD that can be accessed for editing and/or | validation. Without it, XML won't be a sufficient improvement on HTML | to win a significant market. Based on my experience with the HTML market and the applications that HTML will soon be called upon to support, I disagree. Jon Date: Fri, 25 Oct 1996 15:26:01 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: documentation for UA interoperability [Derek Denny-Brown:] | I think it would be a mistake to define XML such that we lost | architectural forms. I see architectural forms as realizing there | potential in exactly such an environment as XML is being designed for | (ie. dynamic data interchange between systems). We're saving the discussion of architectural forms for Phase II (December 1996 through March 1997), in which we define the hypertext mechanisms for XML. Architectural forms have definitely not been ruled out, and XML is not being defined in a way that would preclude them. Jon Date: Fri, 25 Oct 1996 16:21:21 -0700 (PDT) From: Bill Smith Subject: Re: C.4 Undeclared entities? To: w3c-sgml-wg@w3.org Len Bullard wrote: > No quarrel. Just keep in mind that validatibility and parameterizing > the editor are very powerful requirements in the minds and contracts > of others who will be buying these systems. I noted this to Michael > and I note it to the list, without provably correct well-formed > instances > where that correctness is tested under conditions of a formal > agreement whose own validity is testable, XML is a non-starter. >urish The PDF/Formal Fixed Non-Revisable guys will have a field day. > Whether correct by test, or correct by construction, formal legal > proof is required. A DTD is easier to build than a test script > and much easier to share and interoperate. But for those applications that do not require formal legal proof, why insist on it? This thread began when it was asserted that XML without DTDs was a market non-starter. Stated bluntly, that isn't true. There are products (Jon has mentioned two) that do not require DTDs and by any reasonable definition these products are successful. > C'mon guys. You are screwing this pooch just to prove who has the > smallest parser. Kind of macho in reverse. Actually, this is something rather different for me. I have stated that validation and formalism are useful, in fact required in some applications. I do not object to validating applications nor do I contest that there is a market for those applications. Clearly a market exists - SGML tools sell. What I do object to are statements that no market exists for XML without formalism or validation. As there is an existance proof for formalism, there is one for the opposite. Let's come up with a specification that can allow both markets to flourish. Date: Fri, 25 Oct 1996 19:31:42 -0500 From: Len Bullard To: "David G. Durand (David G. Durand)" CC: W3C SGML Working Group Subject: Re: C.4 Undeclared entities? Yes, David, I am probably getting "testy" and I apologize for that. Very long days lately. For me, the case for DTDs is inarguable for practical reasons just as the case for enabling transmission, transport, and rendering without them is inarguable. I've done both for years and know the sense of it. In my experience, DTDs aren't hard to build, or hard to teach others to build but my experience is based on a system that already made most of the simplifying assumptions being made here. We found that it works, but that without the DTD it gets very messy and hard to manage. OTH, when used with a DTD sensitive editor or even simple batch parsing, it is very powerful, very cheap, and very easy to sell. We only hit one hitch: SGML experts and consultants who told everyone it wasn't SGML, and then went on to embrace HTML. Won't get fooled again. I will fight for the right to choose and validate my own structures. We need the ability to tune the system to the requirements of local events. Lack of freedom is a one size fits all DTD that for the sake of social good, a hopelessly inadequate network infrastructure and the "bedevilment of the many experts" on a mailing list, makes me or the information hostage to Dueling Dwarf corporations. Anyone read the latest from Microsoft: a set of object extensions to HTML presented privately to 75 vendors over the strong objections of Netscape? Sorry, folks, but I have no faith in the power of the W3C to hold the line. Let's keep in mind, this thing we are building is only as good as our power and speed to implement and sell, but that depends very much on what we CAN do with it, not what others can't. I work for a company that makes MS and NS look like storefronts. I want to sell XML and will, but not if the simple applications we already provide can do a better job. len From: lee@sq.com Date: Fri, 25 Oct 96 20:50:11 EDT To: Charles@sgmlsource.com, lee@sq.com Subject: Re: ERB decisions on A.17, B.9, and other questions Cc: gtn@ebt.com, jjc@jclark.com, w3c-sgml-wg@w3.org > >Once you have WSDs, you can do away with entities altogether, and use > >the (is it refloc?) idea of reusable parts of a document -- > > This approach totally confounds the element structure with the storage of a > document. Not at all. > Element types describe the role that abstract classes of information > play in the document. They can be used in that way if you wish, yes. > Whether a given instance is reusable is a low-level piece > of metadata having to do with the optimization of storage management. That is one possible view. You still need somewhere to keep that metadata. > Mixing the two is far worse than "tag salad", it is "tag compost". Sometimes good things grow out of compost. But then, I like eating salads. And quiche. Maybe I am not a Real SGML Hacker :-) Do you find the HTML methods of description and better? If so, why? Lee From: lee@sq.com Date: Fri, 25 Oct 96 21:14:24 EDT To: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Len: > C'mon guys. You are screwing this pooch just to prove who has the > smallest parser. Kind of macho in reverse. Bill: > What I do object to are statements that no market exists for XML > without formalism or validation. I share Bill's view. If it were not so, whence HTML? HTML validation came long after HTML was popular. SoftQuad Panorama, Inforium LivePage, EBT DynaText, and many other "SGML" applications can exist without doing full SGML validation. Panorama uses the DTD as a source of information about which elements and attributes exist, declared values for attributes, and which are id/idrefs or HyTime links, for example, and, above all, which elements are declared EMPTY. LivePage has a separate file listing which elements are declared EMPTY, and I think doesn't use the DTD at all. > Let's come up with a specification that can allow both markets to > flourish. I agree. If you want to make SGML significantly more widespread, you have to increase the number of ways in which it can be used. That involves getting less up-tight, if you will, about "misuse". I have heard SGMLers say that use of SGML to describe documents, instead of prescribing rules, is impossible or an error. But the TEI must surely count as one of the more successful SGML DTDs, and it is widely used in this way. I have heard SGMLers say that putting formatting information in SGML documents is so bad that anyone who does it will immediately become a capitalist, or something even less successful. Better not notice HTML... I have heard SGMLers say, unless you have a sufficiently rich DTD, you are not using SGML. (this is often aimed at the so-called Waterloo DTD). I have heard SGMLers say, If such-and-such an element has such-and-such a content model, it's not SGML. (said often of P as a separator in a very, very early version of HTML). I say, if it parses, quit moaning. You might not like it, but it's legal and valid according to the spec. I have heard HTMLers say, the SGMLers are too stuck up. I'd like to see XML used all over the place, so make it simple for programmers to sneak it into applications, and simple enough that deigners specify it without feeling guilty. It doesn't need to have morals. If it can do content validation, that's fine. I'd rather see that done with regular expressions matching both content and markup than partly done with DTDs that can't match on text and have bugs in the content model expression language, but if that's wht it takes to get acceptance from w3c, let's just make the ugly DTD be optional. Lee Date: Fri, 25 Oct 1996 21:51:29 -0400 From: gtn@ebt.com (Gavin Nicol) To: Charles@sgmlsource.com CC: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? >>>If the entity is an SGML text entity, the declaration *must* be in >>>the document or else different systems will produce a different ESIS >>>from the same document. >> >>I'd appreciate some more detailed explanation of the reasons >>for the ESIS differences, if you wouldn't mind. > >SGML text entities are parsed in the same context as the document that >references them and the parsed replacement text becomes part of the ESIS. Within >the ESIS, there is no indication that they existed as separate entities. > >If the declaration is not in the document, there is no way to identify the >entity, and therefore no way to assure that two different systems will use the >same replacement text. If they don't, there will be two different ESISs. OK. This is what I thought you meant. In the general case, this is certainly true. However, I think that as XML will have purely synchronous entities (or so it seems), that lazy parsing is perfectly possible, even if the entity has never been declared (though CDATA etc. would create problems I guess). Date: Fri, 25 Oct 1996 10:17:12 -0700 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: A note on case sensitivity I just about vomited when the toxic synergies between case-insensitivity and 10646 repertoire became clear. Making XML markup case-sensitive is clearly the *right* thing to do, but adds a lot of work for those who want to interoperate with SGML and especially HTML. Failing that, I don't suppose there's any support for going back to 7-bit characters, just for GI's and attribute names? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 From: Charles@sgmlsource.com (Charles F. Goldfarb) To: "David G. Durand" (David G. Durand) Cc: W3C SGML Working Group Subject: Re: D.3 ANY-ELEMENT element-declaration keyword? Date: Fri, 25 Oct 1996 21:37:00 GMT On Fri, 25 Oct 1996 10:23:30 -0400, "David G. Durand" (David G. Durand) wrote: >> >>D.3 Should XML specify short-hand element declaration keywords (e.g. >>%ANY-ELEMENT;) for element content in which any element in the DTD >>is legal (same as ANY, but element not mixed content)? > >This does not seem extremely useful to me... We allowed ANY, partly to ease >the job of XML DTD generators. This does not server that purpose, as far as >I can tell, nor does it lead to better DTDs, as far as I can tell. > I agree with David. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: D.4 parameter entities? Date: Fri, 25 Oct 1996 21:37:02 GMT On Thu, 24 Oct 96 14:10:18 CDT, Michael Sperberg-McQueen wrote: >On 30 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the question needs further >discussion in the work group. > >D.4 Should XML allow parameter entities and parameter-entity >references? > * D.4 a. internal parameter entities? > * D.4 b. external parameter entities? Parameter entities are SGML text entities. XML shouldn't have SGML text entities. It is now clear that (the recent TAG editorial to the contrary notwithstanding) XML is a conforming "profile" of SGML, which is as it should be. XML 1.0 should be as simple as possible to encourage rapid implementation. XML 2.0 can have a richer set of SGML features. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- Date: Fri, 25 Oct 1996 11:47:21 -0500 From: Len Bullard To: "David G. Durand (David G. Durand)" CC: W3C SGML Working Group Subject: Re: C.4 Undeclared entities? David G. Durand (David G. Durand) wrote: > Given the relative success of HTML and SGML in the marketplace of the Web, > I'll take my chances with a DTD-less option for XML. This argument by example holds very little water. The relative success of HTML and SGML in the market cannot be attributed to the DTDlessness of HTML. What it can or cannot be attributed to is a subject of endless debate, and success itself it relative to time, place, and the zeitgeist. This argument is FUD incarnate. > I also thing that automatic DTD generation will be a useful tool to help > naive users develop DTDs by starting with example documents. Probably so. Any example helps but a good example directed to the case at hand helps the most. The success of autogeneration depends much on the instance from which it is generated and this method can create as much superstition as competence, and like many autogenerated music, can create as much crap as quality. Users aren't idiots. Belief in the lowest common denominator made the mess we are trying to fix. That seems to be a real dividing belief in this group: some think we are fixing SGML, some think we are fixing HTML. I think we are trying to get our freedom back. Len Bullard From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Martin Bryan Cc: lee@sq.com, w3c-sgml-wg@w3.org Subject: Re: A note on case sensitivity Date: Fri, 25 Oct 1996 21:37:03 GMT On Fri, 25 Oct 1996 17:12:50 +0100, Martin Bryan wrote: > >Swedisn and French, for example, should not be in the same "document" but >should be separate linked segments of a document with their own character >set case rules. The question is how do you link them together. In SGML they >cannot be subdocuments of a master document because subdocs must share an >SGML declaration with the calling document. This is one of the "unnecessary" >restrictions that SGML97 should address. And as Martin well know, it will. We started working on it at the last WG8 meeting. However, the equivalent of "subdoc" with differing SGML declarations is easily obtainable for XML by simply declaring a data entity as "NDATA SGML", then linking to that entity via an attribute value. In my opinion, that is the *only* way that XML should reference external SGML entities. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: lee@sq.com Date: Fri, 25 Oct 96 22:40:21 EDT To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: A note on case sensitivity Tim Bray > just about vomited when the toxic synergies between case-insensitivity > and 10646 repertoire became clear. I just feel I should point out that this would be an issue with just about any textual representation I can think of -- not just ISO10646 and Unicode. Well, OK, I can imagine a representation where every character is an explicit member of a set... {B,b,B}{i,i,I}{g,g,G} files! > Making XML markup case-sensitive is > clearly the *right* thing to do, I agree. > but adds a lot of work for those who > want to interoperate with SGML and especially HTML. Well, the internationalised HTML working group is facing the same issue at exactly this moment, and seems to have reached the same conclusion: It looks like I18N HTML will have to have NAMECASE NO. > Failing that, I don't suppose there's any support for going back to > 7-bit characters, just for GI's and attribute names? If it would help, I would support it. However, you would need attribute values to be case sensitive -- both name groups and ID values. In fact, it is most serious for ID and IDREF. I would strongly suggest making all attribute values case sensitive, even if this means not using SGML ID, IDREF and name groups explicitly. Lee From: Charles@sgmlsource.com (Charles F. Goldfarb) To: lee@sq.com Cc: gtn@ebt.com, jjc@jclark.com, w3c-sgml-wg@w3.org Subject: Re: ERB decisions on A.17, B.9, and other questions Date: Fri, 25 Oct 1996 21:36:56 GMT On Wed, 23 Oct 96 23:21:30 EDT, lee@sq.com wrote: >There's a little proposal at the end of this message, don't blink! > >> >Why can't you build your mechanism using normal elements >> >'> > >Before doing that, I'd much rather see XML use WSDs, with very little >extra complexity. > >Once you have WSDs, you can do away with entities altogether, and use >the (is it refloc?) idea of reusable parts of a document -- This approach totally confounds the element structure with the storage of a document. Element types describe the role that abstract classes of information play in the document. Whether a given instance is reusable is a low-level piece of metadata having to do with the optimization of storage management. Mixing the two is far worse than "tag salad", it is "tag compost". -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: D.1 Distinguish partial and full DTDs? Date: Fri, 25 Oct 1996 21:36:57 GMT On Thu, 24 Oct 96 14:08:08 CDT, Michael Sperberg-McQueen wrote: >On 30 October 1996, the ERB will vote to decide the following >question. A straw poll indicates the question needs further >discussion in the work group. > >D.1 What behavior should XML systems exhibit if no DTD, or only a >partial DTD, is given with a document? In particular, should there >be a way to distinguish a document instance for which a DTD exists >but is not given from an instance for which no DTD exists? Every XML document should have a DOCTYPE declaration that specifies a DTD, just as in SGML. However, an XML PI or other means should be used to indicate whether the instance can be parsed without reference to the DTD. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@SGMLsource.com (Charles F. Goldfarb) To: gtn@ebt.com (Gavin Nicol) Cc: ht@cogsci.ed.ac.uk, U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: B.1 and B.2 results Date: Fri, 25 Oct 1996 21:36:54 GMT On Fri, 25 Oct 1996 00:04:30 -0400, gtn@ebt.com (Gavin Nicol) wrote: >>The parser sees *everything* in the entity, but several entities can >>be stored in a single storage object. The storage object can contain >>things that aren't in any SGML entities. >> >>None of this is new; FSIs are just a new formalism for something >>we've always had. See notes 1 and 2 in clause 6.1 of ISO >>8879. [295:2-8] > >Thank you Charles. This is a good clarification and is the way I >understand things (the best kind of clarification is one that agrees >with your position ;-)). > >I should note that a *further* reason for both FSI's and MIME-based >storage managers is that email will potentially be an important >delivery mechanism for XML. Both FSI's and MIME are perfectly suited >for this. Well, while I'm on a role, let me clarify things a bit further. MIME is a storage manager. FSIs are a means of identifying storage managers in an entity declaration. So the two work together; they are not alternatives. (Actually, the SGML Extended Facilities list two MIME-based storage managers: MIME is a "container" storage manager, like TAR, and is used for normal entity declarations. MIMETYPE is used to associate notations with processing, and occurs only in external identifiers in notation declarations.) -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: lee@sq.com Date: Fri, 25 Oct 96 22:54:51 EDT To: w3c-sgml-wg@w3.org Subject: Re: D.4 parameter entities? >>D.4 Should XML allow parameter entities and parameter-entity >>references? >> * D.4 a. internal parameter entities? >> * D.4 b. external parameter entities? > > Parameter entities are SGML text entities. In a restricted sense, yes. They are not identical in all resects, because they are used in different places and have a different name space (no?). Parameter entities and marked sections are the only way I have seen of making a modular DTD, short of using M4 or the C preprocessor. Actually, since the CPP has a syntax that's clearer and more familiar to programmers, perhaps you're right. A few people already use it with HTML. > XML shouldn't have SGML text entities. I am not sure I follow the reasoning behind this assertion. Why should XML not have text entities? > It is now clear that (the recent TAG editorial to the contrary > notwithstanding) XML is a conforming "profile" of SGML If Tag thinks otherwise, it isn't clear to everyone -- you refute your own assertion. For that matter, it isn't clear to me, either. (but I have not seen the Tag article; I don't receive it) We'll see whether it's a conforming profile or not when it's finished. > which is as it should be. If SGML is up for change, I can accept that XML should be a conforming profile of SGML++, SGML97, or whatever you end up calling it. Fine. It's not a bad goal, but if it ends up being too irregular, arcane, ugly or complex to get widely accepted, all in the name of compatibility, we all lose out. > XML 1.0 should be as simple as possible to encourage rapid implementation. Agreed. > XML 2.0 can have a richer set of SGML features. Or any other features you like -- it's undefined right now :-) Agreed. Lee Date: Fri, 25 Oct 1996 23:27:47 -0400 From: gtn@ebt.com (Gavin Nicol) To: cbullard@HiWAAY.net CC: dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? >Users aren't idiots. Belief in the lowest common denominator made >the mess we are trying to fix. That seems to be a real dividing >belief in this group: some think we are fixing SGML, some think >we are fixing HTML. I think we are trying to get our freedom back. Which is precisely why DTD's should be optional, but certainly allowable. As Len rightly notes, a large group of people will *need* validation. I can think of many examples in my own work where it would be at the very least useful, and I'm not under contract to myself ;-) Date: Fri, 25 Oct 1996 23:35:05 -0400 From: gtn@ebt.com (Gavin Nicol) To: lee@sq.com CC: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: A note on case sensitivity >and Unicode. Well, OK, I can imagine a representation where every >character is an explicit member of a set... {B,b,B}{i,i,I}{g,g,G} files! Hmm. Shades of lex.. >Well, the internationalised HTML working group is facing the same issue >at exactly this moment, and seems to have reached the same conclusion: >It looks like I18N HTML will have to have NAMECASE NO. Nah. The syntax character set for HTML should be ASCII (which is a reversal of a position I held a year or so ago). The issues are ugly. If it speeds adoption, I would be willing to go with 7 bit GI and attribute names, though it does run against what I feel to be correct. From: lee@sq.com Date: Sat, 26 Oct 96 00:09:05 EDT To: gtn@ebt.com, lee@sq.com Subject: Re: A note on case sensitivity Cc: tbray@textuality.com, w3c-sgml-wg@w3.org Gavin Nicol wrote: > The syntax character set for HTML should be ASCII (which is a > reversal of a position I held a year or so ago). > > The issues are ugly. If it speeds adoption, I would be willing to > go with 7 bit GI and attribute names, though it does run against > what I feel to be correct. I'm with you on that. The stumbling block for HTML and probably XML is the HTML case-insensitive CLASS attribute and also ID/IDREF. These are currently strings tht users enter and see. For XML, if you can invent your own element names, it may seem odd to be able to use your own language except for accents -- rather like the Swedish proposal for Unicode to delete the letter W, since it is really a VV ligature. I once wrote a small Unix email database that used | between the fields. Then one day I got mail from someone with a | in his name (it's used as an accented character in some of the national ASCII variants). If you use US ASCII, you may alienate some people, but they're pretty used to American Imperialism by now. If you use ASCII, you get [ ] \ | { and } being letters of the alphabet. If you use the Latin 1 part of ASCII, you have problems with upper/lower case, although you can at least have a fixed specification for it. I think this may be an acceptable compromise for now. If you use unrestricted Unicode or 10646, you have to forget about case insensitive things altogether, or go insane. Frankly, since this is the long-term direction, I'd rather that we did it now, unless someone can convince us that case folding can be done reasonably efficiently and effecively in a multi-lingual environment (include Quebec and Franc in your argument, please). Lee Date: Fri, 25 Oct 1996 21:20:38 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: C.4 Undeclared entities? [Gavin Nicol:] | Which is precisely why DTD's should be optional, but certainly | allowable. As Len rightly notes, a large group of people will *need* | validation. No one has suggested that DTDs would not be allowed. No one has suggested that anyone will be prevented from validating any document for which an author has specified a doctype. No one has suggested that any author will be prevented from specifying a doctype for any document. I'm not sure where these implications came from, but it would help keep the discussion on track if they went away. Jon To: lee@sq.com, tbray@textuality.com, w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: A note on case sensitivity Date: Sat, 26 Oct 1996 09:12:25 +0100 At 22:40 25/10/96 EDT, lee@sq.com wrote: >> Making XML markup case-sensitive is >> clearly the *right* thing to do, > >I agree. >> Failing that, I don't suppose there's any support for going back to >> 7-bit characters, just for GI's and attribute names? > >If it would help, I would support it. I would not, simply because I don't see why you can't name elements and attributes in Trench, Tamil, Japanese, etc. XML is always being quoted as being based on the ESIS representation. OK, why not adopt the approach that the names as used in XML must be as in ESIS, the capital representation of any lowercase characters in element and attributes being used (which is the default case in ESIS). This shifts the burden to the editor, but makes it clear to the client that any remaining name differences are significant. If you are entering words with accents that don't have case equivalents defined (as they are in NAMESTRT or NAMECHAR then those characters are always retained as entered, and no matching of your tag/attribute names is possible. I feel that a Frenchman might prefer to loose case sensitivity for the sake of being able to enter the names in the form he prefers, as long as he is warned of the consequences. As an aside, those of us like Lee and Gavin who are receiving the i18n material on this at the same time as the XML stuff have to look very hard at the messages to determine which camp they are coming from. The XML camp is only seeing a part of a three way conversation, so might miss out on some of the nuances of the situation, which includes the problem of sorting, matching characters that have been generated using accents + character pairs with accented characters, matching equivalents within 10646 code tables,.... ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Sat, 26 Oct 1996 03:54:05 -0500 From: Len Bullard To: lee@sq.com CC: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? lee@sq.com wrote: > > Len: > > C'mon guys. You are screwing this pooch just to prove who has the > > smallest parser. Kind of macho in reverse. > > Bill: > > What I do object to are statements that no market exists for XML > > without formalism or validation. > > I share Bill's view. > If it were not so, whence HTML? HTML validation came long after HTML > was popular. HTML is a single application. XML is a notation for multiple applications. Different requirements, up front. > SoftQuad Panorama, Inforium LivePage, EBT DynaText, and many other > "SGML" applications can exist without doing full SGML validation. How much an application does with SGML is and has always been the designers to choose. There are very simple and very complex applications of the standard. I agree and have said so. But XML is not an application. I agree with Charles. It should be a proper subset of SGML. Why lose the tools that already work and have a base of practice and in which both your company and mine and our community are heavily invested? I'd like a design that lets us harvest the investment. > > Let's come up with a specification that can allow both markets to > > flourish. > > I agree. > I have heard HTMLers say, the SGMLers are too stuck up. For the most part, we are simply an older community. but if the shoe fits... ... if that's wht it takes to get > acceptance from w3c, let's just make the ugly DTD be optional. Always has been. But not just RTFM: WTFM first. That's part of this effort: not just a language, but systems. We need a design that gives us validation in a formal way. How and when one uses it in XML is more optional, but not completely. Like VRML and all web technologies, we have to build and give away tools for it. Wouldn't it be smart to keep the cost as low as we can for XML 1.0? A DTD is a cheap way to use what we have in the barn. len From: "Henry S. Thompson" Date: Sat, 26 Oct 96 14:04:45 BST To: gtn@ebt.com (Gavin Nicol) Subject: Re: Optional features considered harmful Cc: w3c-sgml-wg@w3.org Gavin writes > James writes > >An XML parser intended for Web browsers wouldn't resolve an external text > >entity immediately itself but rather would return a transclude event to the > >application and keep going. This would make it hard for a Web browser to do > >validation, but that may not be a problem. > > Yes, that's the idea. In some code I wrote a long time ago, I had > a smart pointer that would resolve nodes as needed. I imagine an entity > (transclusion event) would basically become a smart pointer. That's the way the next release of NSGML will handle things, with the addition that the parser will provide an entry point to do the transclusion on demand, i.e. "Fill in the content of this element per its links", i.e. a sort of hyper-CONREF, but if the application doesn't care no extra work is done. I'd be perfectly happy to say "No external text entities in v1.0, subsumed by one of a range of link semantics envisioned for v2.0." ht Date: Sat, 26 Oct 1996 11:37:27 -0700 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: SGML ERB Meeting of October 26: RE's resolved! The ERB met on Saturday October 26. All members were present. As usual, summaries of the rationale for the decisions made have not been reviewed by the ERB and are thus subject to correction and further explanation. 1. Reservation of name space Agreed unanimously to add "." to the set of legal name-start characters for XML, and to reserve the portion of all name-spaces beginning ".XML." for the purposes of the language. This includes at least element GI's, attribute names, entity names, and element ID's. 2. RS/RE handling Executive summary: use HTML rules, but provide an escape to RE Delenda Est. Agreed unanimously, except for one sub-clause noted below, that: 2.1 There will be a mechanism, using a reserved attribute, to toggle, per element, between two modes of white-space handling. In "White Space Preservation" mode, all white space including RE is passed through to the application, with the exception of a single leading and trailing RE *if* they are alone on a line with the start- or end-tag. Note: "alone on a line with" assumes that comments have already been stripped. In "White Space Collapse" mode, all initial and trailing white space in an element is eaten by the parser, and all internal white space, including successive blank lines, is replaced by a single space character before passing to the application. 2.2 The setting of this toggle is by default inherited from the parent element. The root element of any document, by default, has the toggle set to "White Space Collapse" mode. 2.3 The White Space mode is orthogonal to the use of CDATA marked sections; that is to say, CDATA marked sections will still ignore markup delimiters, but will respect the current White Space mode. [On this decision, Bray, Sperberg-McQueen, and Sharpe dissented, preferring to have White Space Preservation mode built-in to CDATA Marked Sections]. Notes and Rationale: 1. A large part of the world builds and uses applications that generally collapse white space. The objective of causing the minimal number of surprises mandates this default behavior. 2. If XML is going to deviate from 8879 compatibility, it should be in a subtractive way; i.e., XML should eat at least as many RE's as SGML does. The HTML behavior seems the simplest way to achieve this. 3. James Clark feels that there is a slight 8879 incompatibility in that if there are comments or PI's in an element that has White Space Preservation set, SGML will eat some RE's that XML will pass through. Clearly, given the vote, this is felt to be liveable. 4. I have since discovered that beginning GI's with .XML. may cause massive incompatibility with CSS - we may end up having to reserve "-XML-". Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Sat, 26 Oct 1996 15:21:33 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Addition to the list New WG member representing a W3C member organization: Murray Altheim, Spyglass murray@spyglass.com Jon Date: Sat, 26 Oct 1996 16:08:17 -0700 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: A note on case sensitivity | As an aside, those of us like Lee and Gavin who are receiving the i18n | material on this at the same time as the XML stuff have to look very | hard at the messages to determine which camp they are coming from. The | XML camp is only seeing a part of a three way conversation, so might | miss out on some of the nuances of the situation, which includes the | problem of sorting, matching characters that have been generated using | accents + character pairs with accented characters, matching | equivalents within 10646 code tables,.... That's why WG participants were selected partly in order to maximize overlap with other standards efforts. We're counting on you guys to keep us informed. Jon Date: Sat, 26 Oct 1996 16:22:53 -0700 (PDT) From: "Deborah A. Lapeyre" Subject: Re: D.4 parameter entities? To: Michael Sperberg-McQueen cc: W3C SGML Working Group > > D.4 Should XML allow parameter entities and parameter-entity > references? > * D.4 a. internal parameter entities? Yes, please absolutely. This can be used as an organizing mechanism and is not a kludge. Consider the TEI... > * D.4 b. external parameter entities? > > We are still discussing. Answer later. -Debbie Lapeyre Date: Sat, 26 Oct 1996 16:28:16 -0700 (PDT) From: "Deborah A. Lapeyre" Subject: Re: Optional features considered harmful To: James Clark cc: Gavin Nicol , w3c-sgml-wg@w3.org > > XXX... would be easier to make this work if we > disallowed references to external > text entities in attribute values, > but hopefully people can live without those. We can live without them quite well, thank you. --dalapeyre From: Charles@sgmlsource.com (Charles F. Goldfarb) To: lee@sq.com Cc: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Date: Sun, 27 Oct 1996 01:03:57 GMT On Fri, 25 Oct 96 21:14:24 EDT, lee@sq.com wrote: >I have heard SGMLers say that ... I don't agree with what those "SGMLers" have said. I think HTML is a perfectly legitimate use of SGML and a brilliant accomplishment (see the Foreword to the forthcoming "SGML on the Web: Small Steps Beyond HTML" for further details). The real problem with DTD-less XML documents has nothing to do with validation. The problem is that an XML document without a DOCTYPE declaration will not only not be conforming SGML -- it will cause problems for XML users that don't affect HTML users. As Len Bullard has pointed out, HTML is one application of SGML. Browsers have the HTML DTD "built-in"; they don't need the DOCTYPE declaration. XML, however, allows many document types to be defined. A user will have a right to complain when one document that begins with a tag can't be processed by a style sheet that can handle his other document that begins with a tag. We'll then have to explain to him that these are are really documents of two different types, and that the style sheet was created for just one of the types. It's better that we bite that bullet up front and require a DOCTYPE declaration in the document always. However, we can also specify (through an XML PI), that the document can be processed without reference to the DTD. >I'd like to see XML used all over the place, so make it simple for >programmers to sneak it into applications, and simple enough that >deigners specify it without feeling guilty. > >It doesn't need to have morals. > >If it can do content validation, that's fine. I'd rather see that >done with regular expressions matching both content and markup than >partly done with DTDs that can't match on text and have bugs in the >content model expression language, but if that's wht it takes to get >acceptance from w3c, let's just make the ugly DTD be optional. > >Lee > -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: gtn@ebt.com (Gavin Nicol) Cc: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Date: Sun, 27 Oct 1996 01:03:56 GMT On Fri, 25 Oct 1996 21:51:29 -0400, gtn@ebt.com (Gavin Nicol) wrote: >>>>If the entity is an SGML text entity, the declaration *must* be in >>>>the document or else different systems will produce a different ESIS >>>>from the same document. >>> >>>I'd appreciate some more detailed explanation of the reasons >>>for the ESIS differences, if you wouldn't mind. >> >>SGML text entities are parsed in the same context as the document that >>references them and the parsed replacement text becomes part of the ESIS. Within >>the ESIS, there is no indication that they existed as separate entities. >> >>If the declaration is not in the document, there is no way to identify the >>entity, and therefore no way to assure that two different systems will use the >>same replacement text. If they don't, there will be two different ESISs. > >OK. This is what I thought you meant. In the general case, this is >certainly true. However, I think that as XML will have purely >synchronous entities (or so it seems), that lazy parsing is perfectly >possible, even if the entity has never been declared (though CDATA etc. >would create problems I guess). The lazy parsing would produce identical results. The non-lazy parsing, however, could produce differing results. For that reason, syntactic entity references should not be used for this purpose. Instead, the external SGML entities should be treated as independent documents and referenced via an ENTITY attribute. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: lee@sq.com Cc: w3c-sgml-wg@w3.org Subject: Re: D.4 parameter entities? Date: Sun, 27 Oct 1996 01:03:59 GMT On Fri, 25 Oct 96 22:54:51 EDT, lee@sq.com wrote: >> Parameter entities are SGML text entities. > >In a restricted sense, yes. >They are not identical in all resects, because they are used in >different places and have a different name space (no?). SGML text entities are entities that are parsed in context when referenced. There are two name spaces for SGML text entities: parameter and general. Parameter entity references are allowed only within markup declarations. General entity references are allowed only within document instances and default attribute value literals (since the latter are used only within instances). >Parameter entities and marked sections are the only way I have seen >of making a modular DTD, short of using M4 or the C preprocessor. True. But for simplicity, I don't think XML should have modular DTDs. SGML tools can be used to create (or generate) specific XML DTDs from modular SGML ones. >> XML shouldn't have SGML text entities. > >I am not sure I follow the reasoning behind this assertion. >Why should XML not have text entities? For the reasons that James Clark and Eliot Kimber pointed out in other postings: they complicate processing in a networked environment and they provide only an illusion of re-usability. HTML doesn't have SGML text entities; it has links between distinct SGML documents. That's what XML needs as well. >> It is now clear that (the recent TAG editorial to the contrary >> notwithstanding) XML is a conforming "profile" of SGML > >If Tag thinks otherwise, it isn't clear to everyone -- you refute your >own assertion. For that matter, it isn't clear to me, either. >(but I have not seen the Tag article; I don't receive it) The TAG article is anti-XML. It thinks that XML is a competitor to SGML and therefore divisive to the SGML community. I've never communicated with Brian about XML, so I don't know any more than I've read in TAG. However, I warned of this potential danger on this list several weeks ago. >If SGML is up for change, I can accept that XML should be a conforming >profile of SGML++, SGML97, or whatever you end up calling it. Fine. >It's not a bad goal, but if it ends up being too irregular, arcane, ugly >or complex to get widely accepted, all in the name of compatibility, >we all lose out. Given the timing, I think that SGML 1.0 needs to conform to SGML as-is. We can then make sure that SGML97 is designed so that XML 2.0 can have the other things it needs. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- Date: Sat, 26 Oct 1996 19:16:14 -0700 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: C.4 Undeclared entities? At 01:03 AM 10/27/96 GMT, Charles F. Goldfarb wrote: >It's better that we bite that bullet up front and require a DOCTYPE declaration >in the document always. However, we can also specify (through an XML PI), that >the document can be processed without reference to the DTD. Clearly XML document entities must have a then they can have no | tag can't be processed by a style sheet that can handle his other | document that begins with a tag. We'll then have to explain | to him that these are are really documents of two different types, and | that the style sheet was created for just one of the types. Including the doctype doesn't solve this problem. In practice, stylesheets for industrial DTDs like DocBook don't typically include all or even most of the possible tags defined by the DTD; they just cover the ones used for a particular set of documents under a particular set of circumstances. Different DocBook stylesheets don't resemble each other very strongly even within the same company, let alone in the world of DocBook users at large. And in delivery systems like DynaText/DynaWeb that support user selection of stylesheets, a given document or set of documents may be accompanied by several different stylesheets that address different subsets of the tag set. Doctype declarations aren't the way to associate stylesheets with documents. Jon From: lee@sq.com Date: Sun, 27 Oct 96 00:01:33 EDT To: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? > The lazy parsing would produce identical results. The non-lazy > parsing, however, could produce differing results. For that reason, > syntactic entity references should not be used for this purpose. > Instead, the external SGML entities should be treated as independent > documents and referenced via an ENTITY attribute. I'm not sure I follow the distinction here. That is, I understand the syntactic distinction. You are saying that we should not allow transclusion, ala , or in HTML, or for that matter ala the currently implemented , because the contents of the remote document may change. In general, what you get by resolving a URL into data may be a completely different object (possibly of a different content type) every time you fetch it. As an example, there are sites offering a "random URL"! This might point to an image one time, to an SGML document the next, and so on. But that doesn't make it always a bad thing. If you link to something for an embedded object in HTML, be it via or or the largely defunct
, it's up to you to make sure that you are linking to something stable. Don't avoid the general case because there happens to be a failure case that you don't like. Lee Date: Sun, 27 Oct 1996 01:13:10 -0400 To: lauren@sqwest.bc.ca (Lauren Wood) From: Harvey Bingham Subject: Re: documentation for UA interoperability Cc: w3c-sgml-wg@w3.org At 14:12 1996/10/23 -0700, Lauren Wood wrote: >One of the things we haven't yet discussed (or did I miss something?) is the >interaction between different XML systems and what this might necessitate in >terms of documentation. Since I've spent a large amount of time worrying about >reverse-engineering the HTML DTD, this is something I'd like to get clear from >the beginning in XML. In HTML, there is no need for documentation on elements, >as long as all UAs read and implement the HTML spec. This is not necessarily >the case for XML, where UAs will need documentation on elements to enable >interoperability. >... I worry that a dtd-less XML will be precluded from handling material that has multiple dimensions, each of which affect presentation. I think of tables and maths. I encourage a mechanism for identifying common DTD fragments that could provide the semantics for these. I hope we can avoid the long and hard SGML Open effort to find out in practice what the semantics of the CALS table model are. We also struggled to identify the interoperable Exchange table model subset. Since each dimension of a multi-dimensional table contributes to the cell meaning (through row- and column-captioning), the semantics associated with table tagging seem essential to reasonable presentation in tables. For a table model in row-major order, recognizing any columnar association for a cell does not fall into the normal grove representation. How does XML let us pick up the HTML table model? How does XML let us pick up a (partial) stylesheet that would substitute for a DTD fragment for the tables? Regards/Harvey Date: Sun, 27 Oct 1996 09:53:36 -0600 From: Len Bullard To: "Deborah A. Lapeyre" CC: Michael Sperberg-McQueen , W3C SGML Working Group Subject: Re: D.4 parameter entities? Deborah A. Lapeyre wrote: > > > > > D.4 Should XML allow parameter entities and parameter-entity > > references? > > > * D.4 a. internal parameter entities? > Yes, please absolutely. This can be used as an organizing mechanism and > is not a kludge. Consider the TEI... I'm not hot on this one because a define or any copy operation is assumed for most languages. Parameter entities done badly are a source of bad DTDs and we have a lot them. TEI also has TEI lite because as Michael has noted, some tools don't support it and some users don't understand it. It is not a kludge but as an organizing mechanism, it is easy to abuse. I don't see it as a performance hit unless the pipeline needs the DTD to perform an operation. Keep it. len bullard Date: Sun, 27 Oct 1996 08:34:46 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: documentation for UA interoperability [Harvey Bingham:] | I worry that a dtd-less XML will be precluded from handling material | that has multiple dimensions, each of which affect presentation. I | think of tables and maths. I don't understand this. A DTD consists of a machine-readable component and a human-readable component. It is well known that the machine-readable component can't convey semantics; that's a job for DSSSL or a set of standard application conventions. So I don't see how the omission of the machine-readable portion of the DTD can affect the application's ability to interpret tables. Correct me if I'm wrong, but my impression of the SGML Open tables activity is that it resulted in (1) a canonical or recommended form for the machine-readable component of the CALS table DTD fragment and (2) a set of human-readable application conventions setting forth the semantics of the DTD fragment. When we say that an XML application can optionally omit a DTD, what we mean, of course, is that it can function in some useful way without the machine-readable portion. How semantics get conveyed to the application seems to me to be an entirely separate question, one that we have scheduled for Phase II of this effort. | Since each dimension of a multi-dimensional table contributes to the | cell meaning (through row- and column-captioning), the semantics | associated with table tagging seem essential to reasonable | presentation in tables. For a table model in row-major order, | recognizing any columnar association for a cell does not fall into the | normal grove representation. I'm not following you here on the problem you seem to be describing. If there is a problem, how does providing the machine-readable portion of the DTD solve it? | How does XML let us pick up the HTML table model? How does SGML "let us pick up the HTML table model"? Let me ask this differently: Given the simplifications that we are making to XML, would the representation of a table that an XML application builds in memory be different with a DTD from what it would be without it? In what way? A clear answer to this question would aid the discussion considerably. | How does XML let us pick up a (partial) stylesheet that would | substitute for a DTD fragment for the tables? We haven't specified a mechanism for associating stylesheets with documents yet. Jon From: Charles@sgmlsource.com (Charles F. Goldfarb) To: lee@sq.com Cc: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Date: Sun, 27 Oct 1996 19:17:23 GMT On Sun, 27 Oct 96 00:01:33 EDT, lee@sq.com wrote: >> The lazy parsing would produce identical results. The non-lazy >> parsing, however, could produce differing results. For that reason, >> syntactic entity references should not be used for this purpose. >> Instead, the external SGML entities should be treated as independent >> documents and referenced via an ENTITY attribute. > >I'm not sure I follow the distinction here. That is, I understand >the syntactic distinction. You are saying that we should not allow >transclusion, ala , or in HTML, >or for that matter ala the currently implemented , >because the contents of the remote document may change. No. I am saying that there are two distinct cases: 1. The external object is parsed as though it were part of the referencing object. In this case, the external object is an SGML text entity and cannot be permitted to change. 2. The external object is *not* parsed as though it were part of the referencing object. In this case, the external object is a data entity or SGML document. It *can* be permitted to change. In SGML, the two cases are distinguished by the form of reference. Entity references are used for the first case (&entityname; or %entityname;) and ENTITY attributes are used for the second case. The first case should not be permitted in XML; there is no need for it. The second case is what allows "lazy" parsing without creating inconsistent ESISs. (It also supports what you call "transclusions", I think. My Shorter OED, with 98,600 entries, doesn't include the term.) -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: bosak@atlantic-83.eng.sun.com (Jon Bosak) Cc: w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com Subject: Re: C.4 Undeclared entities? Date: Sun, 27 Oct 1996 19:17:24 GMT On Sat, 26 Oct 1996 19:50:35 -0700, bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) wrote: >[Charles Goldfarb:] > >| The problem is that an XML document without a DOCTYPE declaration will >| not only not be conforming SGML -- it will cause problems for XML >| users that don't affect HTML users. As Len Bullard has pointed out, >| HTML is one application of SGML. Browsers have the HTML DTD >| "built-in"; they don't need the DOCTYPE declaration. >| >| XML, however, allows many document types to be defined. A user will >| have a right to complain when one document that begins with a >| tag can't be processed by a style sheet that can handle his other >| document that begins with a tag. We'll then have to explain >| to him that these are are really documents of two different types, and >| that the style sheet was created for just one of the types. > >Including the doctype doesn't solve this problem. In practice, >stylesheets for industrial DTDs like DocBook don't typically include >all or even most of the possible tags defined by the DTD; I'd like to see a clear statement of the user requirements that XML is supposed to address. Originally, it was supposed to be HTML++, introducing structure to the masses, which implies simple DTDs. Now, suddenly, it's industrial-strength document types, so complex that no stylesheet can address all of it -- and no HTML hacker would want any part of it.. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: bosak@atlantic-83.eng.sun.com (Jon Bosak) Cc: w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com Subject: Re: C.4 Undeclared entities? Date: Sun, 27 Oct 1996 19:17:26 GMT On Fri, 25 Oct 1996 15:12:32 -0700, bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) wrote: >[Charles Goldfarb:] > >| >A well-formed XML document without a DTD describes a logical tree of >| >arbitrary depth. HTML does not, unless you overload the DIV tag in >| >ways that are horrible to contemplate. This is a difference. >| >| But not enough to win out against "HTML with user extensions via style >| sheet". To teach the value of "a logical tree of arbitrary depth" we >| need to teach the value of structure and document types. > >There is a difference between the concept of structure and the concept >of document types. They are both valuable concepts, but they are not >joined at the liver. You're right, Jon. But if we only consider structure, then HTML's
provides all the structure that DTD-less XML would provide. In fact, it is probably superior to DTD-less XML for the same reason that Arjun's proposal for is superior: it provides for unambiguous termination of nested elements. Now, you will argue that XML will be better than HTML because it will have named, nestable element types. But as soon as you name element types, you have created a document type, even if the definition for it is only in your mind, the stylesheet, or wired into a browser, as in HTML. You aren't arguing for DTD-less XML, you are arguing for XML with undocumented or unstandardized DTDs. >| This case is weakened significantly if we don't require DTDs and offer >| the possibility of validation of all XML documents. > >There is a difference between requiring DTDs and making it possible to >validate XML documents. Tim Bray seems to disagree. I certainly do. What would you validate a document instance against if not a DTD? [Tim] >On Sat, 26 Oct 1996 19:16:14 -0700, Tim Bray wrote: >>Clearly XML document entities must have a 1. The external object is parsed as though it were part of the referencing > object. In this case, the external object is an SGML text entity and cannot > be permitted to change. Do you mean cannot be permitted to change during parsing, or cannot ever ever in the lifetime of the universe be revised? If the latter, on the internet, forget it. > 2. The external object is *not* parsed as though it were part of the > referencing object. In this case, the external object is a data entity > or SGML document. It *can* be permitted to change. But what if I _want_ to include changeable material in the body of an SGML document? Are you saying that it is illegal to include, for example, a fragment of a datbase in a document? Today's sales are as follows: [information suppressed due to wording of international standard] [please use HTML for this instead] > The first case should not be permitted in XML; there is no need for it. It's true that this is done today with server-side includes in HTML, using a syntax derived from the C pre-processor. > The > second case is what allows "lazy" parsing without creating inconsistent ESISs. > (It also supports what you call "transclusions", I think. My Shorter OED, with > 98,600 entries, doesn't include the term.) Transclusion is not my term -- Ted Nelson invented it, and it has become standard use for your case (1), with the possibility of being lazy about it -- only do the inclusion when the user asks for it. Did I miss a statment somwhere that there would be a meaningful equivalent of the ESIS representation defined for XML? I have seen no such statement. The coincidence that XML files can sometimes (if they have a complete DTD) by parsed by an SGML parser does not mean that the SGML ESIS is in any way binding on XML files. In any case, I had understood that the ESIS representation was not normative in ISO8879:1986, in which case your reasoning seems to me disingenious. The important questions are * what are the requirements? * how can they be met? Start with these, and not * how would one particular way of doing this affect one of the world's 15 SGML parsers before it has been modified if necessary to handle XML? If it turns out that the parsers don't need to be changed (although we already know that won't be so, of course, when there is no DTD), that's fine. But don't reject functionality based on that reasoning! Lee Date: Sun, 27 Oct 1996 11:54:33 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: C.4 Undeclared entities? [Charles Goldfarb:] | I'd like to see a clear statement of the user requirements that XML is | supposed to address. The design goals for XML are where they've been for the last two months: http://www.textuality.com/sgml-erb/dd-1996-0001.html I think that this is a clear statement. | Originally, it was supposed to be HTML++, introducing structure to the | masses, which implies simple DTDs. See the document above and also the activity page: http://www.w3.org/pub/WWW/MarkUp/SGML/Activity The activity page has been up since early June. This activity has never been described as HTML++. It has always been described as "Generic SGML over the Web." | Now, suddenly, it's industrial-strength document types, so complex | that no stylesheet can address all of it -- and no HTML hacker would | want any part of it.. I don't think that the complexity of the DTD is relevant to my assertion that doctypes are not the right way to associate stylesheets with documents. Jon Date: Sun, 27 Oct 1996 12:07:20 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: C.4 Undeclared entities? | You aren't arguing for DTD-less XML, you are arguing for XML with | undocumented or unstandardized DTDs. That is your version of my position. It is not my version of my position. | >| This case is weakened significantly if we don't require DTDs and offer | >| the possibility of validation of all XML documents. | > | >There is a difference between requiring DTDs and making it possible to | >validate XML documents. | | Tim Bray seems to disagree. I certainly do. What would you validate a | document instance against if not a DTD? If you wish to validate a document instance, you must have a DTD. If you don't wish to validate a document instance, there are very useful things you can do with it that do not require a DTD. If you need existance proofs of this, EBT should be able to provide you with a customer list. Jon Date: Sun, 27 Oct 1996 12:14:03 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Posters for SGML '96 While it's not approved policy to allow the WG list to be used for general announcements, the following request from the SGML '96 Conference Committee will be of interest to many members of the WG, and I have therefore agreed to forward it to the group. Jon ======================================================================== Date: Sun, 27 Oct 1996 11:36:24 -0800 (PST) From: "SGML'96 Conference Committee" To: Jon Bosak RE: Posters for SGML'96 Attention XML List: (I've been reading your posts...) You have proven you are *the* SGML literati. You have proven you are opinionated. You have proven you are both ingenious and stubborn. You have proven you have a lot to say and can say it in small, easily-digested chunks. Why not give a poster for SGML'96? It's not too late. If you don't know what a poster is or otherwise need more information, call me at USA (301)231-6933 or send to Posters . Please consider a poster! -- Debbie Lapeyre (SGML'96 Poster Chair) ______ How to Below , Skip if not interested---- ******** SGML'96 POSTER GUIDELINES ******** ---------------------------------------------------------------------- WHAT YOU SEND TO SGML'96 (for Poster Program) (Deadline November 8, 1996) (E-mail to : sgml96@netcom.com ) 1. Poster Title 2. Poster Abstract (1-3 short paragraphs) 3. Your name and address (including email) ---------------------------------------------------------------------- WHAT YOU BRING TO SGML'96 (Deadline November 17-20, 1996) 1. Poster(s) -- One to three poster-sized pages. Text big enough to read from 4 or 5 feet away. Size approximately 22 x 28" (56 by 71 cm). (22 x 26" is fine.) 2. Handouts (Optional) ---------------------------------------------------------------------- POSTER CATEGORIES 1. Technical poster (case study or technical topic) 2. Vendor posters (free advertising)) 3. Personal poster (who are you - limit one page) ---------------------------------------------------------------------- *** FREE ENLARGING *** (Deadline: Received BEFORE November 3, 1996) Send 8 1/2 x 11 or A4 paper to GCA and they will enlarge to poster size for free. GCA's address: Graphic Communications Association; Poster Submission; ATTN: Joy Blake; 100 Daingerfield Road; Alexandria, VA USA 22314-2888 ---------------------------------------------------------------------- Questions, Comments, Sending title/abstract/name by Mail Debbie Lapeyre; Mulberry Technologies, Inc.; Suite 608; 6010 Executive Blvd.; Rockville, MD USA 20852 PH: 301-231-6933 FAX: 301-231-6935 E-mail: sgml96@netcom.com ---- end ---- <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> SGML'96 Celebrating a Decade of SGML; But Wait ... There's MORE Technical Program email: sgml96@netcom.com Conference Co-Chairs: B. Tommie Usdin Deborah A. Lapeyre Mulberry Technologies, Inc. 301/231-6930 GCA Contact: Joy Blake; Graphic Communications Association 703/519-8177 <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Tim Bray Cc: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Date: Sun, 27 Oct 1996 21:41:55 GMT On Sat, 26 Oct 1996 19:16:14 -0700, Tim Bray wrote: >At 01:03 AM 10/27/96 GMT, Charles F. Goldfarb wrote: >>It's better that we bite that bullet up front and require a DOCTYPE declaration >>in the document always. However, we can also specify (through an XML PI), that >>the document can be processed without reference to the DTD. > >Clearly XML document entities must have a It is an interesting open question whether they require one to be well-formed. >Is it fair to say that if they have an then they can have >no Subject: Re: C.4 Undeclared entities? Cc: w3c-sgml-wg@w3.org I have read the contributions from Charles, Jon, Lee, et al, and they all seem to make some sensible points. However, I am completely baffled as to the point of this argument where the rubber meets the road, i.e. in the XML spec. Surely Charles is not arguing that the external subset pointed to by the To: "'w3c-sgml-wg@w3.org'" Subject: RE: A note on case sensitivity Date: Sun, 27 Oct 1996 19:22:15 -0500 [Martin Bryan] >Swedisn and French, for example, should not be in the same "document" >but >should be separate linked segments of a document with their own >character >set case rules. The question is how do you link them together. In SGML >they >cannot be subdocuments of a master document because subdocs must share >an >SGML declaration with the calling document. This is one of the >"unnecessary" >restrictions that SGML97 should address. I need to ask for something to be clarified, please. In the first part of the first sentence are you saying that "two languages should not be used in names the same document type definition (because case-folding rules that are significant to parsing markup may conflict)"? If so, I agree. As I understand, case-folding does not apply to any document data (that which isn't markup) unless the application wishes to do something about it after the data has been taken out of the document. =20 Case-folding conflicts aside, the topic of multilingual names (and, heaven forbid, claims of bias of precedence of one language over another in (very) long bilingual names) in DTDs is an issue that has been discussed with some of our Canadian Government customers, due to federally legislated bilingualism. Given that the bilingualism here is English/Qu=E9bequois, the case-folding issue (as deftly described by fello-canuck Liam) is not just an academic exercize. My concern is that the sentence as written gives the impression that an XML document (not just a document type) should not have multilingual content, but the adoption of ISO10646 will allow content to be in any language supported by the characters (and extension mechanisms) available in that standard. =20 Thanks ........... Ken -- G. Ken Holman Tel: +1 613 596-CADE(2233) /\ /\ Chief Technology Officer Fax: +1 613 596-5934 \/ \/ Computer Microstar Software Ltd. WATS: 1 800 267-9975 /\ /\ Aided 3775 Richmond Road Mail: gkholman@microstar.com \/ \/ Document Nepean Ontario Info: cade@microstar.com /\ /\ =20 Engineering CANADA K2H-5B7 Web: http://www.microstar.com \/ \/ -- G. Ken Holman Phone: +1 613 489-2987 P.O. Box 266 Street: 1605 Mardick Court Kars, Ontario CANADA KOA-2E0 E-mail: ab945@freenet.carleton.ca -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAjHOimAAAAEEAK47HbDtZZB8hJBk+r9Zh7m7QxdFHTaz/m200QQ7J9XX4QYs h6hsuP6ZqBJXyLdmIVMEwR6Ry6oxjKMd6BRJ8OGScD89eIghgbrpMX+900NxM0x2 v3yWO9ki2gKRPrn4vlCXznnmcmsyke0G02T2LefXbgZHyVSqDSOLy8nwuN7dAAUR tClHLiBLZW4gSG9sbWFuIDxhYjk0NUBmcmVlbmV0LmNhcmxldG9uLmNhPg=3D=3D =3DIN3T -----END PGP PUBLIC KEY BLOCK----- From: lee@sq.com Date: Sun, 27 Oct 96 19:45:14 EST To: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? > Surely Charles is not arguing that the external subset pointed to by > the be fetched by a browser-class application that has no need to look at it? I can't answer that, although I want to say that these ugly processing instructions have to go. What's wrong with starting a file with ? The doctype line can be implied. > Surely Lee is not arguing that we ought to brand browsers that refuse to > do dynamic run-time transclusion as non-compliant? As I have said, I don't have strong feelings on this, since an XML that is visibly less powerful than HTML is acceptable to me. I _do_ want to be able to distinguish an XML file from an SGML document, if it is possible, doing something better than the Mosaic/Navigator/MSIE algorithm of "if it contains in the first 400 bytes, it's HTML". (yes, really. Try it in MSIE 3.0; the others may believe mime types more readily now). > At the moment, the XML spec is going to define, very carefully, what a > <!DOCTYPE is, how it's used, what validity is, what well-formedness is, > then it's going to shut up and let the market decide how to use these > things. If any of you have some concrete suggestions as to other things > that should go in the spec, let's hear them. If we have to have DOCTYPE lines, I would say that you need to explain about PUBLIC and SYSTEM identifiers, and how they are resolved, with a PUBLIC identifier using the file "catalog.soc", or if that is not found, "CATALOG.SOC", or "catalog", or "CATALOG", in that order, and whether this is done in the presence of a SYSTEM identifier (formal or informal) or not. You also need to define * case sensitivity (is <!doctype allowed? what about in an fpi?) * character set and encoding of doctype line -- e.g. can the outermost doctype element have a Kanji name? If so, how is the doctype line parsed? Is the <?XML> hack in front of the doctype line? * what can go in the DOCTYPE declaration subset or whatever it's called -- the Square Bracket Place, in non-obfuscatory language! e.g. element declarations? Somewhere, it is worth specifying that if there is a DTD in an external file, it does not (or does) have a DOCTYPE line of its own, as in <!DOCTYPE x [ . . . ]> that many people use for storing DTDs. This is a cause of incompatibility between existing SGML software. However, I think that in practice it's as futile to require a doctype line for HTML as it is for HTML, and you (Tim) know as well as I do that there were well under 5% of HTML documents on the web that contained a DOCTYPE line, even though RFC1866 mandates one, last time we checked. 'cos you did the checking for me. One reason is probably the strange and (arguably) ugly syntax. Another bigger reason is that most of today's HTML software ignores the DOCTYPE line, except for a small percentage that goes wrong when it finds one. If the DOCTYPE line doesn't give an immediate benefit to the user, and the application doesn't need it, drop it! I don't consider 8879 conformance an immediate benefit to the user here, since if you are generating a DTD, you can generate a DOCTYPE line too, and almost vertainly have to replace the DOCTYPE line in the file. So the DOCTYPE line will actually make XML slightly harder for most people to use XML, with no benefit. There are simpler ways to tie a document to a DTD and style sheets, and we still need to specify the character set and encoding of the document before any DOCTYPE line could be parsed correctly, and we still need to say which version of XML is being used for a given document. Lee From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Tim Bray <tbray@textuality.com> Cc: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Date: Mon, 28 Oct 1996 01:54:53 GMT On Sun, 27 Oct 1996 14:03:09 -0800, Tim Bray <tbray@textuality.com> wrote: >Surely Charles is not arguing that the external subset pointed to by >the <!DOCTYPE, in the (very common, I predict) case of <?XML RMD='internal' >be fetched by a browser-class application that has no need to look at it? I am not. If the DTD isn't needed, it shouldn't be read (or fetched). >At the moment, the XML spec is going to define, very carefully, what a ><!DOCTYPE is, how it's used, what validity is, what well-formedness is, >then it's going to shut up and let the market decide how to use these >things. If any of you have some concrete suggestions as to other things >that should go in the spec, let's hear them. Otherwise let's drop this >thread. O.K., I'll skip the technical and philosophical arguments and get very precise. The following 25 characters or so, if omitted, will prevent a "DTD-less" XML document from being a conforming SGML document: <!DOCTYPE typename SYSTEM> I am arguing that every XML document should be a conforming SGML document, therefore this statement should be required for DTD-less documents. Of course, the other forms of DOCTYPE are preferable if there is a DTD. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: lee@sq.com Cc: lee@sq.com, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Date: Mon, 28 Oct 1996 01:54:56 GMT On Sun, 27 Oct 96 14:45:41 EST, lee@sq.com wrote: >> 1. The external object is parsed as though it were part of the referencing >> object. In this case, the external object is an SGML text entity and cannot >> be permitted to change. >Do you mean cannot be permitted to change during parsing, or cannot ever ever >in the lifetime of the universe be revised? > >If the latter, on the internet, forget it. That's my point. We shouldn't allow this in XML. >> 2. The external object is *not* parsed as though it were part of the >> referencing object. In this case, the external object is a data entity >> or SGML document. It *can* be permitted to change. > >But what if I _want_ to include changeable material in the body of >an SGML document? Are you saying that it is illegal to include, for >example, a fragment of a datbase in a document? > >Today's sales are as follows: > [information suppressed due to wording of international standard] > [please use HTML for this instead] No, of course not. That is case 2. You can do it via an attribute value because that is not *syntactic* content and isn't parsed in context. > >> The first case should not be permitted in XML; there is no need for it. > >It's true that this is done today with server-side includes in HTML, >using a syntax derived from the C pre-processor. The issue here is not functional; it is syntactic. Entity references are not the correct syntax for transclusions. > >> The >> second case is what allows "lazy" parsing without creating inconsistent ESISs. >> (It also supports what you call "transclusions", I think. My Shorter OED, with >> 98,600 entries, doesn't include the term.) > >Transclusion is not my term -- Ted Nelson invented it, and it has >become standard use for your case (1), with the possibility of being >lazy about it -- only do the inclusion when the user asks for it. Wrong. It is the standard use for my case (2), where the data is allowed to change. Transclusions should be done with attribute values only. Entity references are for constant data that is always parsed. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: bosak@atlantic-83.eng.sun.com (Jon Bosak) Cc: w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com Subject: Re: C.4 Undeclared entities? Date: Mon, 28 Oct 1996 01:54:55 GMT On Sun, 27 Oct 1996 14:34:17 -0800, bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) wrote: >[Charles Goldfarb:] > >| As input to an XML editor, I have no problem with a DTD-less >| "well-formed" document. The editor can create a DTD (a la Fred). >| >| For interchange, however, I believe an XML document must be valid. It >| must have a DTD identified in its DOCTYPE declaration, although a >| browser might be able to parse the document without referring to >| it. This rule would also assure that interchanged XML documents were >| valid SGML documents. > >I don't understand the last statement. How does the insertion of a >line containing a doctype declaration at the top of a file guarantee >that the rest of the file contains a valid document? Leaving it out makes the document invalid SGML. Inserting it gives the document a chance at being valid. >HTML 3.2 is a conforming SGML application. How many authors put HTML >doctype declarations at the top of their HTML documents? How many >HTML documents would be valid HTML if they did so? The error-handling behavior of HTML browsers is to ignore errors like that. >If we said in the specification that all XML documents had to have a >doctype declaration, how many major XML browser vendors of the future >would in fact make products that would reject well-formed XML >documents that didn't have doctype declarations? (If the answer is >greater than zero, please tell me which one and why. I would >sincerely like to know.) They wouldn't. The objective of requiring DOCTYPE is to allow XML documents to be valid SGML documents. >What mechanism would you use to force Microsoft and Netscape and >Spyglass and Sun to not build browsers that accepted documents without >doctype declarations? Dumb question. I favor the best possible error recovery. It is perfectly reasonable to assume that an XML document without a DOCTYPE declaration can be parsed successfully. >Why would this effort be more successful in enforcing the standard >than it has been so far in enforcing strict adherence to HTML 3.2? Again, it won't help enforcement of XML; it will allow conforming XML documents to be conforming SGML documents. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- Date: Sun, 27 Oct 1996 20:40:12 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray <tbray@textuality.com> Subject: Re: C.4 Undeclared entities? At 01:54 AM 10/28/96 GMT, Charles F. Goldfarb wrote: >O.K., I'll skip the technical and philosophical arguments and get very precise. >The following 25 characters or so, if omitted, will prevent a "DTD-less" XML >document from being a conforming SGML document: > ><!DOCTYPE typename SYSTEM> > >I am arguing that every XML document should be a conforming SGML document, >therefore this statement should be required for DTD-less documents. I welcome the arrival of a concrete proposal. If an XML document is to be valid, obviously there has to be a <!DOCTYPE. I think, within the conceptual framework of XML, Charles' proposal boils down to: A well-formed XML document must include a <!DOCTYPE At the moment, we *almost* have this - since part of being well-formed is not having any undeclared entities and defaulted attributes and so on. Now, suppose there *really* is no DTD - this is just some tag salad that has been cooked up for some specific task and fired off to the browser. It seems to me that putting a <!DOCTYPE in isn't going to make it into a valid SGML document, nor a valid XML document. Our design goals say: XML instances are SGML documents as they are, without changes to the instance. There is some wiggle room. At the time this was written, we hadn't formalized the concept of well-formedness. It is clear that for *valid* XML documents, this is true, modulo some grey areas about RE's and maybe enumerated-attribute-namespaces that I think we'll all be happy to work together to sort out. We could drop the concept of well-formedness - yet it seems to capture something of strong everyday utility. I'm not sure what the effect would be of asserting that to be an XML document of any class it must be valid, i.e. there must be a <!DOCTYPE and it must point to a real DTD and the instance must parse against the DTD. I fully expect that XML will capture a spectrum of documents ranging from things pumped out of a real SGML repository with no changes [except perhaps for moving some markup declarations from the external to the internal subset], to well-formed but unvalidated fragments generated on the fly from a database. It seems useful to me that XML should provide formal specification of validity [effectively identical to 8879], and also something that is less than validity, but is still highly constrained and guaranteed easy to parse - and still in some sense blessed by the XML spec. So, on balance, I would at the moment vote against requiring <!DOCTYPE as a condition of well-formedness. Even if it were desirable, it would be widely ignored, and I think that rules that aren't going to be obeyed shouldn't be made. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Sun, 27 Oct 1996 23:07:51 -0600 From: Len Bullard <cbullard@HiWAAY.net> To: Tim Bray <tbray@textuality.com> CC: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Tim Bray wrote: > > So, on balance, I would at the moment vote against requiring <!DOCTYPE > as a condition of well-formedness. Even if it were desirable, it would > be widely ignored, and I think that rules that aren't going to be > obeyed shouldn't be made. Sanity check: are you saying XML instance with DOCTYPE is a well-formed and valid XML document. XML instance without DOCTYPE may be well-formed but isn't valid. ??? len Date: Sun, 27 Oct 1996 21:13:35 -0800 To: cbullard@HiWAAY.net From: Tim Bray <tbray@textuality.com> Subject: Re: C.4 Undeclared entities? Cc: w3c-sgml-wg@w3.org At 11:07 PM 10/27/96 -0600, Len Bullard wrote: >Sanity check: are you saying > >XML instance with DOCTYPE is a well-formed and valid XML document. Depends on what you mean by "XML Instance". A piece of text purporting to be XML may in fact contain a <!DOCTYPE but not be valid at all. However, a *valid* XML instance obviously has to have a <!DOCTYPE; the concept of "validity" is meaningless in the absence of a DTD. >XML instance without DOCTYPE may be well-formed but isn't valid. It for sure is not valid. The controversial question at this point is, should the XML spec bless a state called well-formedness without requiring a <!DOCTYPE? Even though I think a <!DOCTYPE is a good idea, I think the XML spec *should* so bless XML fragments, because they're going to happen anyhow, blessed or unblessed; successful standards do not rule out typical everyday behavior. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Sun, 27 Oct 1996 23:24:50 -0900 To: w3c-sgml-wg@w3.org From: "W. Eliot Kimber" <kimber@passage.com> Subject: Re: C.4 Undeclared entities? At 08:40 PM 10/27/96 -0800, Tim Bray wrote: >At 01:54 AM 10/28/96 GMT, Charles F. Goldfarb wrote: >It seems useful to me that XML should provide formal specification of >validity [effectively identical to 8879], and also something that is >less than validity, but is still highly constrained and guaranteed >easy to parse - and still in some sense blessed by the XML spec. > >So, on balance, I would at the moment vote against requiring <!DOCTYPE >as a condition of well-formedness. Even if it were desirable, it would >be widely ignored, and I think that rules that aren't going to be >obeyed shouldn't be made. I think you're missing Charles' point: that one goal is for XML documents to *also* be SGML documents. To do that, they *must* have at least "<!DOCTYPE typename SYSTEM>" at their start. Note that any *existing* SGML processor can consider this to be valid by defining its algorithm for resolving the omitted SYSTEM identifier to be "parse the document--if all the start and end tags match and it otherwise parses ok, assume that the DTD is whatever what you got as an instance would parse against". In other words, call FRED, give it the tag salad, then use what you get back to parse it. We'll need to have DOCTYPE declarations at least for entity and notation declarations, so I don't see any great harm in requiring the minimal DOCTYPE shown above, especially if we define it to mean "all or most of the declarations have been omitted, you figure it out." Cheers, E. -- W. Eliot Kimber (kimber@passage.com) Senior SGML Consultant and HyTime Specialist Passage Systems, Inc., (512)339-1400 10596 N. Tantau Ave., Cupertino, CA 95014-3535 (408) 366-0300, (408) 366-0320 (fax) 2608 Pinewood Terrace, Austin, TX 78757 (512) 339-1400 (fone/fax) http://www.passage.com (work) http://www.drmacro.com (home) "If I never had existed, would you still remember me?..." --Austin Lounge Lizards, "1984 Blues" To: Ken Holman <gkholman@microstar.com>, "'w3c-sgml-wg@w3.org'" <w3c-sgml-wg@w3.org> From: Martin Bryan <mtbryan@sgml.u-net.com> Subject: RE: A note on case sensitivity Date: Mon, 28 Oct 1996 09:13:47 +0000 Ken: >[Martin Bryan] >>Swedisn and French, for example, should not be in the same "document" >>but >>should be separate linked segments of a document with their own >>character >>set case rules. The question is how do you link them together. In SGML >>they >>cannot be subdocuments of a master document because subdocs must share >>an >>SGML declaration with the calling document. This is one of the >>"unnecessary" >>restrictions that SGML97 should address. > >I need to ask for something to be clarified, please. > >In the first part of the first sentence are you saying that "two >languages should not be used in names the same document type definition >(because case-folding rules that are significant to parsing markup may >conflict)"? Among other things - there are other language related problems than case-folding. Identification of equivalence is dependent on case, the use of separate diacritics or combining characters, the character set being used (10646 h= as the same character at a number of code points for different language sets!),... So far the SGML ERB is only looking at the case-folding side o= f the question. Even then they have not looked beyond the existing SGML cas= e of 1:1 mapping. You only have to consider the mapping for ß to understand that 1:1 is not sufficient for 10646. In fact a general m:m solution is needed to cope with all the quirks of all languages. (But thi= s must wait for SGML97++ I suspect:-(...) >If so, I agree. As I understand, case-folding does not apply to any >document data (that which isn't markup) unless the application wishes to >do something about it after the data has been taken out of the document. Its not only data that the application may want to do something with, it = can be markup. What if the application wants to list IDs or name tokens in alphabetical order? Should this be dependent on the markup language? If a document contains fragments in different languages (in the European case = 11 of them, not just the 2 in Canada) should there be language specific list= s with different rules? >Case-folding conflicts aside, the topic of multilingual names (and, >heaven forbid, claims of bias of precedence of one language over another >in (very) long bilingual names) in DTDs is an issue that has been >discussed with some of our Canadian Government customers, due to >federally legislated bilingualism. Given that the bilingualism here is >English/Qu=E9bequois, the case-folding issue (as deftly described by >fello-canuck Liam) is not just an academic exercize. You guys only see part of the problem: I have Greek as one of my language= s! Our (more-or-less rural) local council publishes its documents in 5 languages, which include Gujarati and Chinese. Some UK councils publish i= n 15 languages, without meeting the needs of members of the European Union = as most of these languages are from the Near and Far East. I'm sure Vancouve= r publishes in Chinese as well. The need for multilingual documents is spreading like wildfire. Texas and California are classic cases in the States. Others will follow. We need to plan ahead for this. >My concern is that the sentence as written gives the impression that an >XML document (not just a document type) should not have multilingual >content, but the adoption of ISO10646 will allow content to be in any >language supported by the characters (and extension mechanisms) >available in that standard. =20 I intended it to have the reverse effect; oh well, so much for intentions= :-) The point is that we need to be able to build composite documents from entities that have their own language-sets. At present SGML does not allo= w for this because of the rules about shared character sets. HMTL forbids i= t due to character set restrictions and its inability to reference entities= . I would like those developing XML to consider the language question from da= y one, rather than as an add-on, and to consider it with respect to whether= we need a better way to intergrate data entities so that we can prepare compound multilingual documents logically. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK=20 Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ To: tbray@textuality.com, w3c-sgml-wg@w3.org From: Martin Bryan <mtbryan@sgml.u-net.com> Subject: Comments of 25/10 draft of XML Date: Mon, 28 Oct 1996 11:29:29 +0000 Congratulations on getting out an early draft of the XML specification. The following comments apply to the version of this document I picked up of 25th October. In the definition of letters: [#x0250-#x1FFF] /* IPA extensions, spacing modifiers, diacritics, Greek, Coptic, Cyrillic, Armenian, Hebrew, ... */ Not all characters in this range should be allowed as name characters as there are some numbers and punctuation characters in there (and some unused codes). As currently drafted numbers are both digits and letters, but it seems from the definition of Names that we want to restrict digits so that they cannot occur at the start of a name. The current definition of letters does not permit this. (If you want I will work out a more detailed definition for this section for you.) The definition used for Hex coding in <5 Character References>: CharRef ::= '&#' Number ';' | '&u-' Hex4 ' differs from that in <6 Trivial text grammar>: '&u' Hex4 ';' /* character references * in that it requires the use of a hyphen. (The version without the hyphen also appears in <27 Reference> so is presumably the correct form.) The definition of a DOCTYPE ('<!DOCTYPE' (Name | S)+ ('[') does not require a space between DOCTYPE and the following Name. Other definitions seem to require the S between the keyword and the name. The statement "If no RMD is provided, the effect is identical to an RMD with the value all" seems to conflict with the claims that a well-formed XML document should not need to have a DTD. Surely none would be a better default as this would allow XML files to be issued without a DTD or a XML RMD statement. In 3.1 the phrase "the descriptions of the logical structure in this section assume that if the text is distributed across multiple entries," the last word needs to be entities. There is currently a mismatch between the use of AttDefault in the definition of AttDef, and the definition of default in <25 Attribute defaults> QuotedPairs do not allow you to mix entries with single and double quotes in the same definition. Was this deliberate, or an oversight? There seems to be a need to extend the definitions relating to Literal for externaldef. the Extid definition and the fact that Qfsi does not seem to allow for IFSIs of the type defined in the preceding paragraph. Re: "If an XML processor encounters an entity with an encoding that it is unable to process, it must inform the application of this fact and allow the application to request either that the entity should be treated as an NDATA entity, or that processing should cease" we should allow the user the ability to indicate which of the known codings to try first, as there could be a corruption to just the start of the file that would not preclude reading of the rest of the file if one of the known options was selected. In 4.3 "which may be allow an XML processor" delete the "be". ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Mon, 28 Oct 1996 10:13:52 -0500 From: gtn@ebt.com (Gavin Nicol) To: Charles@sgmlsource.com CC: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? >The lazy parsing would produce identical results. The non-lazy >parsing, however, could produce differing results. For that reason, >syntactic entity references should not be used for this >purpose. Instead, the external SGML entities should be treated as >independent documents and referenced via an ENTITY attribute. While I can agree with this, I do not see how or why we should specify implementation behaviour as part of the syntax specification. People said that external text entities would cause problems in a distirbuted system. I showed one architecture in which a number of the difficulties are overcome. The decision of which should be used is a seperate issue. From: lee@sq.com Date: Mon, 28 Oct 96 10:31:14 EST To: kimber@passage.com, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? > I think you're missing Charles' point: that one goal is for XML documents > to *also* be SGML documents. To do that, they *must* have at least > "<!DOCTYPE typename SYSTEM>" at their start. They must also have a DTD to be valid SGML documents. > Note that any *existing* SGML processor can consider this to be valid by > defining its algorithm for resolving the omitted SYSTEM identifier to be > "parse the document Please name any existing SGML processor that works this way today. If you have to change the code, you're not talking about an existing parser. A modified parser could just as easily insert a DOCTYPE line. Lee Date: Mon, 28 Oct 1996 10:58:26 -0500 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: cbullard@HiWAAY.net, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? >It for sure is not valid. The controversial question at this point is, >should the XML spec bless a state called well-formedness without requiring >a <!DOCTYPE? Even though I think a <!DOCTYPE is a good idea, I think >the XML spec *should* so bless XML fragments, because they're going to >happen anyhow, blessed or unblessed; successful standards do not rule >out typical everyday behavior. The last sentence here is something we would all do well to remember. No matter what we do, users are the ones who have the last say, and one option they have is ognoring the spec, or walking away from it. Date: Mon, 28 Oct 1996 10:55:18 -0500 From: gtn@ebt.com (Gavin Nicol) To: Charles@sgmlsource.com CC: lee@sq.com, lee@sq.com, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? >Transclusions should be done with attribute values only. Entity >references are for constant data that is always parsed. Entity references can be (even often are) a form of transclusion. I cannot see why the XML syntax specification should have anything to say on the uses the market finds for the mechnisms defined. Date: Mon, 28 Oct 1996 11:08:01 -0500 From: gtn@ebt.com (Gavin Nicol) To: mtbryan@sgml.u-net.com CC: gkholman@microstar.com, w3c-sgml-wg@w3.org Subject: RE: A note on case sensitivity >Even then they have not looked beyond the existing SGML case >of 1:1 mapping. You only have to consider the mapping for ß to >understand that 1:1 is not sufficient for 10646. In fact a general m:m >solution is needed to cope with all the quirks of all languages. (But this >must wait for SGML97++ I suspect:-(...) The need to specify lexical equivalence of strings is an important capability missing from SGML. Rick and I've talked about this many times. >The point is that we need to be able to build composite documents from >entities that have their own language-sets. At present SGML does not allow >for this because of the rules about shared character sets. HMTL forbids it >due to character set restrictions and its inability to reference >entities. I would like those developing XML to consider the language >question from day one, rather than as an add-on, and to consider it >with respect to whether we need a better way to intergrate data >entities so that we can prepare compound multilingual documents >logically. This is why I suggested ISO 10646. using this we should be able to do something like: <XML> <DIV LANG="en.uk"> &english; </DIV> <DIV LANG="ja"> &japanese; </DIV> <DIV LANG="zh"> &chinese; </DIV> </XML> and even if the entities are in different encodings, parse, and process the document. Date: Mon, 28 Oct 1996 08:03:55 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: Comments of 25/10 draft of XML | Congratulations on getting out an early draft of the XML | specification. The following comments apply to the version of this | document I picked up of 25th October. That's not the draft spec, that's an ERB discussion document. It's still subject to major changes over the next few days as we decide the last batch of issues. Please don't waste your time and ours commenting on language that's in the process of being changed. The editors will have a draft out to the WG toward the end of this week (Thursday or Friday). At that time you will all be notified and we will be asking for everyone's help in going over the text. Thanks. Jon Date: Mon, 28 Oct 1996 11:58:18 -0600 From: Len Bullard <cbullard@HiWAAY.net> To: Gavin Nicol <gtn@ebt.com> CC: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Gavin Nicol wrote: > > >It for sure is not valid. The controversial question at this point is, > >should the XML spec bless a state called well-formedness without requiring > >a <!DOCTYPE? Even though I think a <!DOCTYPE is a good idea, I think > >the XML spec *should* so bless XML fragments, because they're going to > >happen anyhow, blessed or unblessed; successful standards do not rule > >out typical everyday behavior. > > The last sentence here is something we would all do well to remember. > No matter what we do, users are the ones who have the last say, and > one option they have is ognoring the spec, or walking away from it. Nope. Users use software provided by vendors that don't have the option to ignore the standard. Software makes or breaks the rules. Bad practice is bad practice. No undefined exceptions. The programmer can apply it as_is_sensible, but without agreements honored and a means to verify that, the situation becomes what it is for HTMLduJour. I can easily find out what is HTML and what is NetscapeToday. A fragment by definition is not a valid SGML document so why should an XML fragment be? Or is it? Can someone define "fragment"? I can reset the doctype and parse within a subtree of a DTD-constrained instance. So, is a fragment contiguous, or a set of disjunct elements? len Date: Mon, 28 Oct 1996 12:44:31 -0900 To: w3c-sgml-wg@w3.org From: "W. Eliot Kimber" <kimber@passage.com> Subject: Re: C.4 Undeclared entities? At 10:31 AM 10/28/96 EST, lee@sq.com wrote: >> I think you're missing Charles' point: that one goal is for XML documents >> to *also* be SGML documents. To do that, they *must* have at least >> "<!DOCTYPE typename SYSTEM>" at their start. > >They must also have a DTD to be valid SGML documents. > >> Note that any *existing* SGML processor can consider this to be valid by >> defining its algorithm for resolving the omitted SYSTEM identifier to be >> "parse the document > >Please name any existing SGML processor that works this way today. >If you have to change the code, you're not talking about an >existing parser. I didn't say existing processors *do* work this way, I said they *can* work this way--in other words, there's nothing in 8879 that prescribes *how* you get the data that makes up an entity or how you determine what the actual system identifier is (and therefore what the data is that is addressed by that system identifier) when you omit the system identifier. Therefore, *it is technically possible* to modify the entity manager of any SGML processor to behave as I've described. Remember too that one of the goals of XML is to define a syntax that doesn't require *explicit* declaration of element types. Therefore, by definition, you never have to resolve the omitted system identifier in order to parse the document (although you may need it for validation). In the context of document delivery, explicit document type declarations primarily serve the *information receiver* by letting them check to see whether or not the data they get meets whatever requirements they have. When a receiver has this requirement they can provide an explicit DTD (or architecture) and if any documents don't validate against it, kick it back. Or, they can choose to only accept documents with explicit DTDs. Most of the time, information receivers don't care (e.g., casual Web browsers). But when the information is really data involved in some controlled business process, you do care. Note that one thing we haven't yet discussed (as far as I know) is the concept of being able to say "I don't care what the element type declarations for the document are, but I *do* care what architecture it claims to conform to." By putting the schema rules at the architecture level, you can have a system that allows individual documents to be ideosyncratic while still keeping a measure of schema identification and validation. For example, if on your internet you want to manage "reports" but you don't want to define some all-encompasing DTD for report documents that will meet all the requirements of report writers (and the high maintenance cost that implies), you can define a general "report architecture" from which any report document must be derived. Validation of documents *without explicit document types* can be done *by the receiver* through a combination of defaulting and a simple explicit mapping, done either on elements or through some prolog (such as you can do in SGML with LINK process declarations--not that I'd suggest actually using LINK for XML). One problem with DTDs as defined in 8879 is *that they don't tell you anything* about a document except how to validate it. However, architectures, because they represent a stand-alone set of defined semantics and schema rules, *do* tell you something because the name of an architecture points back to a *fixed* set of definitions (unlike the name of a document type, which only tells you the element type of the document element). Or said more simply: the idea in SGML that document types tell you something more useful about documents than how to parse and validate them syntactically them is a Big Lie. One you remove from the syntax those things for which you *must* have explicit element type declarations, you don't need DTDs for parsing, only for validation. Cheers, E. -- W. Eliot Kimber (kimber@passage.com) Senior SGML Consultant and HyTime Specialist Passage Systems, Inc., (512)339-1400 10596 N. Tantau Ave., Cupertino, CA 95014-3535 (408) 366-0300, (408) 366-0320 (fax) 2608 Pinewood Terrace, Austin, TX 78757 (512) 339-1400 (fone/fax) http://www.passage.com (work) http://www.drmacro.com (home) "If I never had existed, would you still remember me?..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 28 Oct 1996 11:13:57 -0800 (PST) From: Bill Smith <bill.smith@Eng> Subject: Re: C.4 Undeclared entities? To: w3c-sgml-wg@w3.org Charles Goldfarb wrote: > For interchange, however, I believe an XML document must be valid. It must > have > a DTD identified in its DOCTYPE declaration, although a browser might be able > to > parse the document without referring to it. This rule would also assure that > interchanged XML documents were valid SGML documents. Stipulating that only valid XML documents may be interchanged is heavy handed and will limit acceptance. This requirement could preclude a variety of applications since it would effectively prevent the interchange of works-in-progress. Rather than exchanging documents in their "current state", some intermediate, "valid state" would have to be artifically created. We could specifiy mechanisms for going from invalid to valid and back again, or we could just let documents be exchanged. This level of formalism isn't needed. Date: Mon, 28 Oct 1996 14:30:02 -0500 To: <dgd@cs.bu.edu> (David G. Durand), w3c-sgml-wg@w3.org From: "Steven J. DeRose" <sjd@ebt.com> Subject: Re: B.10 Empty elements? David G. Durand wrote: > HTML compatibility is a very good argument. (close to knock-down, >drag-out, to me). What I don't like is that the <e> format requires a DTD >for XML processing (or partial DTD, which seems confusing to me), and <e/> >does not. I think the foreign syntax is easy to justify given the >elimination of the need for any DTD information. Easier than the >explanation that you have to declare "just one little thing" if you don't >have a DTD, but do use empty elements. The two aren't necessarily incompatible... If we allow <e/> we can also allow <e> for empties if and only if they are declared. This is fine in SGML too, since EMPTY elements can use NET-enabling start-tags just fine. This way we get some level of backward compatibility to everybody. The downside is that there are then two ways of saying the same thing; but it does let us support legacy HTML data (given that the HTML DTD does the right declarations), and let's us introduce the syntactic distinction for the benefit of our posterity. s To: gtn@ebt.com (Gavin Nicol) From: Martin Bryan <mtbryan@sgml.u-net.com> Subject: RE: A note on case sensitivity Cc: gkholman@microstar.com, w3c-sgml-wg@w3.org Date: Mon, 28 Oct 1996 20:08:28 +0000 At 11:08 28/10/96 -0500, Gavin Nicol wrote: >This is why I suggested ISO 10646. using this we should be able to >do something like: > > <XML> > <DIV LANG="en.uk"> > &english; > </DIV> > <DIV LANG="ja"> > &japanese; > </DIV> > <DIV LANG="zh"> > &chinese; > </DIV> > </XML> > >and even if the entities are in different encodings, parse, and >process the document. Exactly what I would like to do with one little extra, I would like (in an ideal world) to be able to have different namecase rules for each entity rather than have them share SGML declarations. I don't expect to get that in XML 1.0, or in any version of HTML this century, but would like people to bear it in mind as what we need to think of if we are ever going to develop an SGML-based solution that will work for multlingual compoud documents on a world-wide scale. Incidentally, to say this is all pie-in-the-sky is not the answer. I am reading a book on language development at present that has 74 sections, each written by a different author/set of authors, that cover different sets of languages, from heiroglyphics through to languages used only in remote areas of Indonesia. I would love to be able to search this as an electronic reference work to try to identify the relationships between languages better, but at present there is not electronic system that could cope with searching text of this complexity. Until there is the much muted Information Age will not replace the Age of the Printed Word in which I was happily brought up and in which I expect to finish my life! ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Mon, 28 Oct 1996 15:44:32 -0500 To: "David G. Durand" <dgd@cs.bu.edu> (David G. Durand), w3c-sgml-wg@w3.org From: "Steven J. DeRose" <sjd@ebt.com> Subject: Re: Optional features considered harmful At 12:32 PM 10/24/96 -0400, David G. Durand" (David G. Durand wrote: >While James' point that entities are not necessary is valid, I agree with >Tim's (later post) that they provide the "vendor-independent" way to do doc >management. Pace, Eliot, I think that with the synchrony restriction they >could prove to be a lot more useful than SGML entities have proven to be. Actually, I think we've already ruled out all or nearly all the details which make entities non-reusable: * asynchrony * #CURRENT * USEMAP * Certain cases of OMITTAG * certain details of declared content * certain details of RE-handling * inclusion and exclusion exceptions With these gone, what makes entities non-reusable any more? Obviously no entity can be referenced in a context that has already used a duplicate ID value, but that's a restriction on *use* in general, not particularly *re*-use. The synchrony constraint really does make a huge difference here. It's not hard for an implementation to create the right parse tree for all the document portions it *does* have, even if it's missing a sub-tree(s). If what's missing is not a subtree this would be far harder, but we've already made that restriction. So you put in a "I didn't load this thing" icon, and getch it later to paste in in the right place; in no case can it affect the well-formedness or structure of the rest of the document, right? (or don't, depending on your application, whether your modem is broken, or somehting). To me this is one of the biggest advantages of the synchrony restriction on entities. Steve Date: Mon, 28 Oct 1996 15:44:34 -0500 To: Tim Bray <tbray@textuality.com>, w3c-sgml-wg@w3.org From: "Steven J. DeRose" <sjd@ebt.com> Subject: Re: documentation for UA interoperability At 03:02 PM 10/25/96 -0700, Tim Bray wrote: >At 11:53 PM 10/23/96 EDT, lee@sq.com wrote: > >>Will XML have architectural forms? >>I didn't think we had #FIXED attributes any more... > >I can't find the vote, but I'm pretty sure that XML *does* have #FIXED >attributes. Someone else from the ERB shout if I'm wrong. Architectural forms have little to do with #FIXED attributes. We can have them if we want them, whether or not we keep #FIXED: *If* in some given architecture, all instances of a given element type must be members of the same architectural form (i.e., class), then #FIXED is an expressive way of enforcing that they all have the same value for the architectural-form-name attribute. However, this need not be true of all architectures, or of all elements in any given architecture. Even if it is, you can get much the same result in other ways, enforced either by human or machine, at the implementor's and customers' choice): a) Make sure you always put the right attribute on the instances. b) Never put the attribute on the instances, and set the default right. c) Use other ways to ensure it's always the right value, like give it only a single permissible enumerated value and let it default: <!ATTLIST mylink HyTime (clink) "clink"> S From: lee@sq.com Date: Mon, 28 Oct 96 15:48:31 EST To: w3c-sgml-wg@w3.org, bill.smith@Eng Subject: doctype & conformability [was: Re: C.4 Undeclared entities?] > Charles Goldfarb wrote: > > For interchange, however, I believe an XML document must be valid. It only needs to be well-formed. Note that the two leading SGML browsers today do not use fully validating SGML parsers. You can view a document over the internet with SoftQuad Panorama, even if it isn't valid according to ISO8879, as long as Panorama's parser can cope with it. Interchange is then occurring, no? Bill Smith wrote: > Stipulating that only valid XML documents may be interchanged is heavy handed > and will limit acceptance. I agree. > This level of formalism isn't needed. I would go further and say it would be harmful. Lee Date: Mon, 28 Oct 1996 15:31:23 -0900 To: "Steven J. DeRose" <sjd@ebt.com>, "David G. Durand" <dgd@cs.bu.edu> (David G. Durand), w3c-sgml-wg@w3.org From: "W. Eliot Kimber" <kimber@passage.com> Subject: Re: Optional features considered harmful At 03:44 PM 10/28/96 -0500, Steven J. DeRose wrote: >With these gone, what makes entities non-reusable any more? Obviously no >entity can be referenced in a context that has already used a duplicate ID >value, but that's a restriction on *use* in general, not particularly *re*-use. Or, you could argue that examining the first "<([namechar+])" in the document and then slapping "<!DOCTYPE $1 SYSTEM>" in front of it would get you the same thing *and* avoid name-collisions, which is the primary problem of re-use. Name collision *can't* be a problem for use because an entities first use is in a single document where you just make sure there are no colisions by validating the document (as opposed to validating an entity in *all possible* places it might be referred to). Cheers, E. -- W. Eliot Kimber (kimber@passage.com) Senior SGML Consultant and HyTime Specialist Passage Systems, Inc., (512)339-1400 10596 N. Tantau Ave., Cupertino, CA 95014-3535 (408) 366-0300, (408) 366-0320 (fax) 2608 Pinewood Terrace, Austin, TX 78757 (512) 339-1400 (fone/fax) http://www.passage.com (work) http://www.drmacro.com (home) "If I never had existed, would you still remember me?..." --Austin Lounge Lizards, "1984 Blues" From: Charles@sgmlsource.com (Charles F. Goldfarb) To: gtn@ebt.com (Gavin Nicol) Cc: lee@sq.com, lee@sq.com, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Date: Mon, 28 Oct 1996 22:43:45 GMT On Mon, 28 Oct 1996 10:55:18 -0500, gtn@ebt.com (Gavin Nicol) wrote: >>Transclusions should be done with attribute values only. Entity >>references are for constant data that is always parsed. > >Entity references can be (even often are) a form of transclusion. >I cannot see why the XML syntax specification should have anything to >say on the uses the market finds for the mechnisms defined. I think there is some confusion between the concept of referencing an entity, and the SGML syntactic construct called an "entity reference". SGML has two ways to reference entities: by entity references (&entname; or %entname;) and by attribute values. Each method is used for a different type of entity. Syntactic entity references refer only to integral and invariant parts of the *source* document (which means they are parsed). Attributes refer to data entities that an application can choose to include in the *output* document, but never the source document. Transclusions accessed via a general entity reference (meaning &entname;) violate 8879. Transclusions accessed through an attribute value do not violate 8879. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Bill Smith <bill.smith@Eng> Cc: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Date: Mon, 28 Oct 1996 22:43:47 GMT On Mon, 28 Oct 1996 11:13:57 -0800 (PST), Bill Smith <bill.smith@eng.sun.com> wrote: >Stipulating that only valid XML documents may be interchanged is heavy handed >and will limit acceptance. This requirement could preclude a variety of >applications since it would effectively prevent the interchange of >works-in-progress. Rather than exchanging documents in their "current state", >some intermediate, "valid state" would have to be artifically created. We could >specifiy mechanisms for going from invalid to valid and back again, or we could >just let documents be exchanged. > >This level of formalism isn't needed. > If we took your point literally, Bill, it would require an XML processor to accept any character string and make sense of it. There has to be some definition of "input that an XML processor is expected to handle". Tim has made the distinction between "valid", meaning "conforming to an explicit DTD", and "well-formed", meaning "processable without reference to an explicit DTD". An interchanged XML document has to be one or the other, not just an arbitrary string. For "valid" documents, there would be a DOCTYPE declaration with an explicit external and/or internal subset. Such a document would clearly conform to SGML as well. As Eliot has pointed out, merely "well-formed" XML documents could announce themselves and also be SGML conforming if they were introduced by the following declaration: <!DOCTYPE doctypename SYSTEM> -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Tim Bray <tbray@textuality.com> Cc: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Date: Mon, 28 Oct 1996 22:43:49 GMT On Sun, 27 Oct 1996 20:40:12 -0800, Tim Bray <tbray@textuality.com> wrote: > Charles' proposal boils down to: > > A well-formed XML document must include a <!DOCTYPE >So, on balance, I would at the moment vote against requiring <!DOCTYPE >as a condition of well-formedness. Even if it were desirable, it would >be widely ignored, and I think that rules that aren't going to be >obeyed shouldn't be made. I don't think I was as clear as I should have been. We seem to agree that only "valid" XML and "well-formed" XML are of interest. (Documents that are neither are broken.) We also agree that "valid" XML is just like valid SGML, with the same kind of DOCTYPE declaration. I am *not* proposing that there be an explicit "DTD" for merely "well-formed" XML. I am proposing, as Eliot has pointed out, that there is a legitimate 8879 DOCTYPE declaration for the case where there is no explicit DTD, viz: <!DOCTYPE DocumentTypeName SYSTEM> If XML uses this to introduce a well-formed DTD-less document, it will satisfy SGML conformance as well. Therefore, there is no reason to break SGML conformance for well-formed DTD-less XML documents. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- Date: Mon, 28 Oct 1996 17:41:14 -0600 From: Len Bullard <cbullard@HiWAAY.net> To: Charles@sgmlsource.com CC: Tim Bray <tbray@textuality.com>, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Charles F. Goldfarb wrote: > > I am *not* proposing that there be an explicit "DTD" for merely "well-formed" > XML. I am proposing, as Eliot has pointed out, that there is a legitimate 8879 > DOCTYPE declaration for the case where there is no explicit DTD, viz: > > <!DOCTYPE DocumentTypeName SYSTEM> > > If XML uses this to introduce a well-formed DTD-less document, it will satisfy > SGML conformance as well. Therefore, there is no reason to break SGML > conformance for well-formed DTD-less XML documents. Suppose the user doesn't include the DOCTYPE. The system implementor puts that on their list of exceptions to handle and either whacks the users kneecaps with a "Foreswear bad XML" or says nothing and goes on doing what they will do if it is there but no DTD is specified. What is the big deal? OTH, tell them that the DOCTYPE is optional and they will never do it. It isn't the laziness of the author that is at issue. It is the laziness of the programmer and the conformance of the system. Even HTML application users are learning it's a good idea to put the DOCTYPE in there. The large numbers that don't says more about the levels of practicioners out there and the systems they use, not the validity of the practice. What is the technical reason for optionality on this issue? len Date: Mon, 28 Oct 1996 19:25:27 -0500 To: cbullard@HiWAAY.net, Charles@sgmlsource.com From: "Eve L. Maler" <elm@arbortext.com> Subject: Re: C.4 Undeclared entities? Cc: Tim Bray <tbray@textuality.com>, w3c-sgml-wg@w3.org I've been just watching the tennis match on this issue, and my allegiance switches with every mail message. :-) Nonetheless, one small comment... At 05:41 PM 10/28/96 -0600, Len Bullard wrote: >Suppose the user doesn't include the DOCTYPE. The system implementor >puts that on their list of exceptions to handle and either whacks the >users kneecaps with a "Foreswear bad XML" or says nothing and goes on >doing what they will do if it is there but no DTD is specified. What >is the big deal? OTH, tell them that the DOCTYPE is optional and they >will never do it. It isn't the laziness of the author that is at issue. >It is the laziness of the programmer and the conformance of the system. >Even HTML application users are learning it's a good idea to put the >DOCTYPE in there. The large numbers that don't says more about the >levels of practicioners out there and the systems they use, not the >validity of the practice. Perhaps they're learning that it's a good idea to use the DOCTYPE declaration because they're pointing to various *different* HTMLs. A DOCTYPE declaration of <!DOCTYPE foo SYSTEM> tells you nothing other than (repetitiously) the root element's name, whereas an FPI at least points you to a specific intended DTD. Eve Date: Mon, 28 Oct 1996 20:57:47 -0600 From: Len Bullard <cbullard@HiWAAY.net> To: "Eve L. Maler" <elm@arbortext.com> CC: Charles@sgmlsource.com, Tim Bray <tbray@textuality.com>, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Eve L. Maler wrote: > > I've been just watching the tennis match on this issue, and my allegiance > switches with every mail message. :-) Nonetheless, one small comment... > > Perhaps they're learning that it's a good idea to use the DOCTYPE > declaration because they're pointing to various *different* HTMLs. A > DOCTYPE declaration of <!DOCTYPE foo SYSTEM> tells you nothing other > than (repetitiously) the root element's name, whereas an FPI at least > points you to a specific intended DTD. > > Eve I agree. But if a compromise is needed, that one at least preserves some form of compatibility even if only gestural. I don't understand this tennis match. It looks simple enough. Me, I prefer to point to a real DTD and receive an instance that tells me what is intended. Then at least I can crank up the right browser. len From: lee@sq.com Date: Mon, 28 Oct 96 23:04:35 EST To: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? This is a long article, but I hope that it will be a useful summary and reference, and will help those working on the XML specification. It relates to the information about a document and/or at the start of the document. We must remember, when deleting the SGML declaration and other goodies, that they serve multiple functions in SGML, and even if we can't use them as they stand, we still need some of the things that they do. The following information needs to be conveyed, and very preferably in a way that SGML can accommodate: (1) that this is an XML document and not a GIF image. This may come from a MIME-type or filename. This includes the version of the spec for which this document was written to conform. (2) the character set and encoding of what follows. This may come from a MIME header, if there is one. If not, it must be found very near to the beginning of the document. (3) if there is a DTD, what it is called and where to get it (4) if there are other auxiliary SGML files, such as SDATA entity definitions (if such things are permitted) or other included objects, where to get them (5) if there are other auxilliary application-specific files, such as style sheets, navigator/table-of-contents definitions, VRML mappings, odour personality packs, or whatever, what they are and how to get them. I know style sheet attachification is a later toic, but it is not (I think) entirely unrelated. (7) whether to expect the following data to be a complete document or an incomplete (unfinished partial) document or a reusable a fragment, and, if it is complete, whether to expect it to be valid or merely well-formed. (This last is not necessarily the same as having a DTD) Currently, for SGML, (1) is external to SGML, although once you've got an SGML document, if the SGML declaration says ISO8879-1986 you know you've got a pre-amendment SGML document, and if it says ISO8879:1986 you have a post-amendment pre-SML97 document, etc. (2) is derived from the SGML declaration; (3) is included in or pointed to (or both) by the document type wotsit; SGML uses the DOCTYPE external identifier to refer to an external file it then can't find, but see (4). (4) is outside the scope of SGML, but well within the scope of an application such as HTML or XML; SGML OPEN TR9501/CATLOG is one such mechanism. (5) is the same as (4) -- e.g., Panorama looks up th public identifier from the DOCTYPE wotsit in ENTITYRC, and Author/Editor uses a combination of the ${styles_path} preference and voodoo magick. (6) there isn't a 6. (7) SGML always expects a complete document; if the element given in the DOCTYPE declaration isn't the same as the first open tag encountered, an SGML application can go crazy if it likes (A/E reduces the strictness of parsing, and assumes that you simply haven't finished editing the document yet, for example). For XML, not all of these apply. (1) determining the document format is external to XML. I would suggest, however, that a MIME type be registered with iana and also that a file extension (.xml I suppose) be suggested. It's also worth adding XML to the Microsoft, Apple and OSF/CDE/Sun type registries. If you can't tell that a document is an XML file by looking at the start of it, so be it. Once you've determined it's an XML document, you need to know the version *before* anything else. Anything transmitted after THIS IS XML and before BUT IT's XML 3.1 can never, ever change. It is possible to say, if there is no version identifier it's XML 1.0, but that's a little dangerous. (2) the character set and encoding must be available by looking at the start of the document, just after the XML version. This can be a MIME header, or a processing instruction or a significant comment (I don't see much difference between the last two) or an attribute on a fixed element name (polluting the element namespace somewhat as has already been agreed, I think, for IDs) A DOCTYPE line doesn't do this. (this has to be after the version, so that if the meaning of an encoding is changed in some future revision of XML, the parser can understand in time) I have suggested combining (1) and (2) with <XML REV="1.0" encoding="xxx" charset="yyy"> but I accept that this means you can't use an element called XML. If @ is added as a namestart (until SGML can be changed to have a separate MDO for empty elements) then the element could be empty, and we could use <@XML REV="1.0" ....> Another way would be with a PROCINST, <?XML REV="1.0" encoding="xxx" charset="yyy"> This might not appeal to SGML users accustomed to thinking of processing instructions as a kludge for the things you couldn't see how to do properly (yes, there are many such people), but it has the advantage that it can precede a DOCTYPE line. (3) if there is a DTD, what it is called and where to get it If there is a DTD, I have no strong objection to a DOCTYPE line, even though it's not very pretty. If there is no DTD, there might as well be no DOCTYPE line, since it doesn't help SGML conformance in practice. In principle, I understand Charles' <!DOCTYPE XML SYSTEM> hack, and he has almost convinced me that this does not conflict with [110:37] (p. 403 I think in the handbook, I'm at home) A document type declaration must contain an element declaration for the document type name. on the grounds that in this case the application must invent a DTD that so conforms. But in practice I doubt that there are any SGML applications that cope with this. (4) how to get ancilliary files: HTML allows a base URL for the current document to be specified. This is necessary for use with databases and CGI scripts. SoftQuad Panorama allows processing instructions in the document to say * this is my URL (new in Panorama 2.0 because there were situations we absolutely couldn't cope with without it) (i.e. same as BASE) * this is the URL or a style sheet for me, and this is its name; * same for other associated files (e.g. navspec) (see (5) below for these) This is a minimum. For Panorama, system identifiers in the definitions of external identifiers are taken to be partial URLs and interpreted relative to the file containing their definition. XML could do this with a processing instruction, although note that since you can't easily put a > in there, there are some files that you can't access (name space pollution again!). In practice, an application can decide to recognise &#nnn; or > inside a PI if it likes (after ESIS, if you will), and thus allow a quoting mechanism. You have to have &l too in that case, of course. An attribute on the <@XML> element would be a more robust way to do this: <@XML REV="1.0" encoding="xxx" charset="yyy" base="http://where.you.com/and/get/me.xml" > This starts to look like the (very useful but problematic) HTML HEAD structure... (5) how to get smile-sheets This is a later topic, I know, but if we get rid of PIs for DTDs, we can no longer use the PI of a DTD to bind a document and its style sheet. The mechanism used has to be DTD-independent, and cn't rely on architectural forms in DTDs (since we might not have a DTD to put them in). It needs to occur before the first non-header element in the document (so we can display without backtracking). Again, a PROCINST could be used. (6) There is no 6. (7) whether to expect the following data to be a complete document or an incomplete (unfinished partial) document or a reusable a fragment... This function is normally served by the DOCTYPE. In <!Doctype boy system> <Simon> we do not have a complete document, since Simon and boy don't match. In XML, the functions of the DOCTYPE might be (a) confuse systems that use the contents of the file rather than an externally specified file type or extension into thinking that this is an SGML file and firing up Adept on it (say). I'm not sure this is a real problem in practice. (b) let us know whether the element named in the doctype matches the first element in the document. This information is not needed when there is no DTD, as we can't do anything useful with it. Can we? (c) if a system identifier is given, we know where we would fetch the DTD from if we chose to do so. A separate mechanism must indicate whether that is appropriate or not. ...and, if it is complete, whether to expect it to be valid or merely well-formed. I think that having the URL to a DTD is not the same as saying that this document must be valid according to that DTD. If that's so, we also need <?!@#validity: [valid|well-formed|broken]> Summary of fields: A: It's XML B: REV="1.0" C: encoding="xxx" D: charset="yyy" E: base="http://where.you.com/and/get/me.xml" F: style set: (style sheet, name, valid-devices) (or whatever, probably application-dependent, we'll see) G: DTD name and version and location H: conformance; validity Notes on all the fields together in XML: If you have field (B), you can assume that the document is intended to conform to the spec. -- that is, it is well-formed (or you can report an error and quit!) and may also be valid. Of course, all the other HTTP sorts of fields that one can specify with META, such as <META HTTP-EQUIV="Expires" Value="IETF standard format date+time"> <META HTTP-EQUIV="Pragma" Value="no-cache"> and so on, are also going to be issues for XML files, as are the metadata (such as the Dublin Core) for search engines and other uses. One way might simply be to have a surrogate document: <?XML:metadata "URL:xxx.html"> with much of this information in it. But id would be for the best if all these things can be included in an XML file, and in a stndard way, and in a way that does not conflict with SGML. Where there is a standard way of doing something, and that standard can be used, use it. Lee From: Charles@sgmlsource.com (Charles F. Goldfarb) To: "Eve L. Maler" <elm@arbortext.com> Cc: cbullard@HiWAAY.net, Tim Bray <tbray@textuality.com>, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Date: Tue, 29 Oct 1996 04:20:41 GMT On Mon, 28 Oct 1996 19:25:27 -0500, "Eve L. Maler" <elm@arbortext.com> wrote: >I've been just watching the tennis match on this issue, and my allegiance >switches with every mail message. :-) Nonetheless, one small comment... I don't know which end of the court your leaning toward at the moment, but here's another argument (in case conformance to 8879 isn't important enough :-). Consistent rules are better than inconsistent ones. We can simply say: A DOCTYPE declaration is always required. If there is a DTD, indicate that by locating the external subset and/or putting the declarations in the internal subset. If there is no DTD, indicate that by the word "SYSTEM" alone. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- Date: Mon, 28 Oct 1996 22:39:36 -0600 From: Len Bullard <cbullard@HiWAAY.net> To: lee@sq.com CC: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? lee@sq.com wrote: > Summary of fields: > > A: It's XML > B: REV="1.0" > C: encoding="xxx" > D: charset="yyy" > E: base="http://where.you.com/and/get/me.xml" > F: style set: > (style sheet, name, valid-devices) > (or whatever, probably application-dependent, we'll see) > G: DTD name and version and location > H: conformance; validity Just for comparison's sake, in IDE/AS: 1. We assume conforming SGML and allow a doctype. We don't use it for validation, unless the user calls the parser for batch validation. 2. We don't need the version number. We probably need something for XML. 3. Encoding and character sets are assumed to be ASCII. That will change in new products. 4. We get the base and stylesheet information from the <file tag or whatever the user specifies as it's surrogate in the config file. We support relative pathing and have a "domain" file which serves the same purpose as a catalog. 5. We use a variant of a clink to for linkends and linktypes in IDE/AS. This will be expanded in new products. 6. HTTP is not supported. It is in new products. No matter what, for XML, we get to write new code. In our framework, we assume XML is an SGML subset so unless that changes, support will mainly be some smaller versions of existing handlers. len bullard Date: Mon, 28 Oct 1996 22:50:39 -0600 From: Len Bullard <cbullard@HiWAAY.net> To: lee@sq.com, w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? Len Bullard wrote: > > In our framework, > we assume XML is an SGML subset so unless that changes, support will > mainly be some smaller versions of existing handlers. If there is no doctype, we default to a tag scanner. We note the solution is not robust when faced with infinite diversity in infinite combination... but it beats issuing a kneecap wedgie. In IDE/AS, if the user does not specify a stylesheet, we use a default stylesheet that is rather ugly to look at in all but the simplest cases. len Date: Mon, 28 Oct 1996 17:25:17 -0800 (PST) From: Bill Smith <bill.smith@Eng> Subject: Re: C.4 Undeclared entities? To: w3c-sgml-wg@w3.org Charles Goldfarb wrote: > If we took your point literally, Bill, it would require an XML processor to > accept any character string and make sense of it. There has to be some > definition of "input that an XML processor is expected to handle". In my opinion, a good XML processor would do just that. Other XML processors might choose some behavior just short of aborting. This is considerably less desirable in my opinion. But these decisions should be left to application developers and the market. I suspect that the XML standard, when written, will specify what an XML processor is *required* to handle. If we state that exchange of XML documents is limited to those that are valid in ISO 8879 terms, we are effectively stating that XML processors are required to handle only valid documents. We can and should be more flexible than that. > Tim has made the distinction between "valid", meaning "conforming to an > explicit > DTD", and "well-formed", meaning "processable without reference to an explicit > DTD". An interchanged XML document has to be one or the other, not just an > arbitrary string. Tim made an excellent distinction and it has been most helpful during our discussions. However, I've taken Tim's "well-formed" notion to mean without reference to *any* DTD - implied or otherwise. Of course, Tim may have meant something else but this was my interpretation. If we insist on a classification system for XML document interchange, we had better include a category for those that are neither valid, nor well-formed. They will surely exist, they will be interchanged, and we should have a name for them. I suggest that we label all of these documents as XML. A subset will be well-formed. A further subset will be valid. All can be interchanged. Some XML applications might accept only valid documents. Others might accept only well-formed documents. Yet others might accept any document purporting to be XML - an arbitrary string. Some of these applications will be successful, others will not. Let the market decide. > For "valid" documents, there would be a DOCTYPE declaration with an explicit > external and/or internal subset. Such a document would clearly conform to SGML > as well. Fine. > As Eliot has pointed out, merely "well-formed" XML documents could announce > themselves and also be SGML conforming if they were introduced by the > following > declaration: > > <!DOCTYPE doctypename SYSTEM> I haven't decided on this but at present I don't like it. The conformance argument alone isn't enough to sway me. I also don't see how we distinguish between an XML document that requires a DTD and one that doesn't - if both are required to have a DTD declaration. Date: Mon, 28 Oct 1996 23:21:31 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Applications of XML The first draft of a paper titled "SGML, Java, and the future of the Web" is now available at ftp://sunsite.unc.edu/pub/sun-info/standards/xml/why/xmlapps.htm The same file in PostScript format is available at ftp://sunsite.unc.edu/pub/sun-info/standards/xml/why/xmlapps.ps Zipped versions of both files are also available. Comments are welcome. Jon Date: Tue, 29 Oct 1996 09:44:59 -0500 From: gtn@ebt.com (Gavin Nicol) To: lee@sq.com CC: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? >The following information needs to be conveyed, and very preferably in >a way that SGML can accommodate: I'm not sure what "SGML can accomodate" means, but if this is used as a rationale for including meta-data in a document, I disagree. >(1) that this is an XML document and not a GIF image. >(2) the character set and encoding of what follows. >(3) if there is a DTD, what it is called and where to get it >(4) if there are other auxiliary SGML files, such as SDATA entity definitions >(5) if there are other auxilliary application-specific files, such as > style sheets, navigator/table-of-contents definitions, VRML mappings, >(7) whether to expect the following data to be a complete document or > an incomplete (unfinished partial) document or a reusable a fragment, >Where there is a standard way of doing something, and that standard >can be used, use it. Right. To me this means either MIME headers or catalogs, or a combination of them both. MIME headers are essentially arbitrarily extensible, and using them provides a mechanism for file system storage, email exchange, and HTTP transfer. Catalogs (as defined by TR 9401) are somewhat extensible, and with some *minor* syntax changes that I recommended long ago, would be arbitrarily extensible. Note that the only real difference between MIME and TR9401 is syntax: they are both essentially just a packing list. I would say that for the XL specification itself, we only need to document the *required* information (version, character set and encoding), and document the assumption that XML systems will provide some mechanism of tarnsmitting such data. In a seperate document, we can document the mechanisms used for transmitting such information (MIME, catalogs). Date: Tue, 29 Oct 1996 13:58:10 -0500 To: w3c-sgml-wg@w3.org From: "Steven J. DeRose" <sjd@ebt.com> Subject: Re: Transclusion At 10:43 PM 10/28/96 GMT, Charles F. Goldfarb wrote: >Transclusions accessed via a general entity reference (meaning &entname;) >violate 8879. >Transclusions accessed through an attribute value do not violate 8879. The Term transclusion comes from Nelson's seminal book Literary Machines, and refers to a characteristic at the user level, not the parser level. The interactional semantic called transclusion doesn't care whether you parse the referenced data in the referencing context or not. The notion of "parsing context" is SGML-specific, and is itself out of context when discussing transclusion. For many cases of transclusion, the referencing or the referenced data, or both, may be in media that have not even have an applicable notion of "parsing". The first statement quoted above amounts to saying "an SGML-based system must never display a referenced entity's content at the point of reference." I disagree; indeed, that's exactly what SGML systems do with data included via entity references all the time. It would instead be more correct to make the weaker claim that "entity reference is the only means of transclusion supported directly by a bare SGML parser": since the defined behavior is to go fetch the entity and deal with it right then, which not only gets the effect of transclusion but *prevents* any other effect (unless your parser tells your application non-ESIS information about where the entity reference occurered, so the application can hide it). In short, entity reference *is* transclusion, though of limited capability. SGML imposes limitations on what data you can transclude this way, and thus you cannot accomplish all the kinds of transclusion you want -- for example, if Charles means that referring to an entity in an invalid context for it is invalid, he's right -- but that's not what anyone has in mind, I think. If what Charles has in mind is that an SGML system cannot defer parsing the content of the referenced entity until later (say, when the user click on an icon), that is true, but is only a fact about *parsing*. An SGML system may choose to parse the data and then hide it until the click occurs -- lots of SGML systems do that every day. The SGML restriction does prevent a system >from optimizing its performance, but that has little to do with transclusion (if the data is hidden behind a link that must be manually activated, it is not textbook transclusion anyway). Obviously in SGML you don't *parse* <INCLUDE entity=foo> the same as you parse &foo;. But anyone who wants to is free to state that the intended semantics of their <INCLUDE> tag is transclusion, so you can get the same user-level effect from <INCLUDE> as from &foo;. An application sitting on top of an SGML parser can respond to an entity named on a ENTITY attribute any way it likes, from discarding it entirely, to fetching it and displaying it to the user in between where it displays the SGML data that occurred before and after the reference. It's semantics, not parsing. Scrapping entity references is thus preferable to scrapping ENTITY attributes, because with attributes you can handle more kinds of referenced data, and an implementation is not forced to fetch data that it may, in the end, not need. Style and other semantics can be defined to work across the entity boundary. So I agree with Charles, namely that we're better off with ENTITY attributes -- but I don't think the reasons have much to do with 8879 conformance. s From: lee@sq.com Date: Tue, 29 Oct 96 14:09:06 EST To: cbullard@HiWAAY.net, lee@sq.com Subject: Re: C.4 Undeclared entities? Cc: w3c-sgml-wg@w3.org Len wrote: > No matter what, for XML, we get to write new code. That's probably true for all SGML developers, which is why I am not too worried if processing is required to make an XML file be valid SGML (e.g. by adding a DOCTYPE header and SGL declaration and DTD). To me, the political issue of saying XML is an SGML application is different from the technical issue of achieving that in a way that is sufficiently palettable. Obviously, if it ends up being the case that the stream of bytes coming over the network (after removing the MIME header from the HTTP sequence) is SGML-conforming that's the simplest and most desirable all round. Any strict SGML implementation today will be unable to deal with DTD-less XML files, though, and processing is needed in that case. Putting <!Doctype xml SYSTEM "no dtd available, you lose!"> at the start doesn't help from the technical point of view. But if you examine the byte stream after the structovator has run & made a DTD, you may well have valid SGML. A philosopher might opine that For every DTD-less XML file There existeth a Document Divine, Which conformeth even to the uttermost mile Of Iso Eight Eight Seven Nine. Well it doesn't scan very well, but it parses :-) Lee Date: Tue, 29 Oct 1996 15:04:49 -0500 To: w3c-sgml-wg@w3.org From: "David G. Durand" <dgd@cs.bu.edu> (David G. Durand) Subject: Re: C.4 Undeclared entities? At 10:43 PM 10/28/96, Charles F. Goldfarb wrote: >On Mon, 28 Oct 1996 10:55:18 -0500, gtn@ebt.com (Gavin Nicol) wrote: > >>Entity references can be (even often are) a form of transclusion. >>I cannot see why the XML syntax specification should have anything to >>say on the uses the market finds for the mechnisms defined. > >I think there is some confusion between the concept of referencing an entity, >and the SGML syntactic construct called an "entity reference". SGML has >two ways >to reference entities: by entity references (&entname; or %entname;) and by >attribute values. Each method is used for a different type of entity. There is no confision, just a difference of opinion as to whether the SGMl semantics are useful. As long as we meet the syntactic restrictions of 8879, we are fine. As far as to _when_ an entity is parsed, the only reason it matters _in XML_ is when validating. Therefore we need not honor the restrictions on processing that you claim are mandated by 8879. (The preceeding convoluted sentence expresses my impression that 8879 does not mandate _when_ processing occur; In parallel, it asserts my opinion that _even if it did_ we should not care). >Syntactic entity references refer only to integral and invariant parts of the >*source* document (which means they are parsed). Attributes refer to data >entities that an application can choose to include in the *output* >document, but >never the source document. We need not honor these intentions of 8879. If we meet the simple condition that it is possible to generate a valid parse according to 8879, we have discharged our obligations. Entities that expand when you want them to are useful, so we need to address them on that basis. They do not, as far as I can tell, affect the validity of processing the same entities with an SGML processor, so we can do it if we want. Let's stick to the facts of syntax, and usefulness and stop trying to preserve the original SGML processing model, as opposed to the syntax (and as much of ESIS as we find useful). > >Transclusions accessed via a general entity reference (meaning &entname;) >violate 8879. Prose to support this contention please? That would be prose prohibiting _when the data can be parsed_. The validation conditions for XML and SGML are obviously already divergent, so that need not concern us unduly. >Transclusions accessed through an attribute value do not violate 8879. > ditto. -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Tue, 29 Oct 1996 15:04:53 -0500 To: w3c-sgml-wg@w3.org From: "David G. Durand" <dgd@cs.bu.edu> (David G. Durand) Subject: Re: C.4 Undeclared entities? At 10:43 PM 10/28/96, Charles F. Goldfarb wrote: >On Sun, 27 Oct 1996 20:40:12 -0800, Tim Bray <tbray@textuality.com> wrote: >> Charles' proposal boils down to: >> >> A well-formed XML document must include a <!DOCTYPE >> Some of Tim's prose deleted by Charles... >>So, on balance, I would at the moment vote against requiring <!DOCTYPE >>as a condition of well-formedness. Even if it were desirable, it would >>be widely ignored, and I think that rules that aren't going to be >>obeyed shouldn't be made. >casuistry deleted.... >I am *not* proposing that there be an explicit "DTD" for merely "well-formed" >XML. I am proposing, as Eliot has pointed out, that there is a legitimate 8879 >DOCTYPE declaration for the case where there is no explicit DTD, viz: ><!DOCTYPE DocumentTypeName SYSTEM> > >If XML uses this to introduce a well-formed DTD-less document, it will satisfy >SGML conformance as well. Therefore, there is no reason to break SGML >conformance for well-formed DTD-less XML documents. Bil gave a great reason: This will not, in fact, be put in by users, thus rendering the notion of well-formed XML documents irrelevant. Well-formed XML documents should, therefore, _not_ be SGML compatible in this way, as it will lead to a dearth of well-formed XML documents. We should not try to impose any conditions on well-formed documents that are not _REQUIRED IN ORDER FOR AN XML PROCESSOR TO PARSE IT_. The doctype is not needed for XML processing, so it should not be in well-formed XML. Valid XML arguably has a much greater claim on it for SGML compatibility, even for things that could be done automatically; well-formed XML does not. -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Tue, 29 Oct 1996 17:11:03 -0500 From: gtn@ebt.com (Gavin Nicol) To: sjd@kirk.mit.edu CC: w3c-sgml-wg@w3.org Subject: Re: Transclusion >So I agree with Charles, namely that we're better off with ENTITY attributes >-- but I don't think the reasons have much to do with 8879 conformance. Well, the point I was trying to make is that if we have synchronous entities, there is nothing *stopping* the parser from performing the nice optimisation of fetching the entity, and parsing it, only when needed. In other words, the application built on top of the parser may never even be aware of when the entities are resolved and parsed (a nice feature in some systems). On the other hand, using element + ENTITY attributes requires the application to resolve the entities as needed (a nice feature in other situations). I think there is room for *both* forms, but I cannot see why one is necessarily preferrable to the other for network use. For myself, I would very much like to use the lazy entity resolution model in an idea I have for realtime HTML (could be extended to realtime XML). As for SGML conformance. SGML is *supposed* to be parsed from head to tail, and entities resolved in the parsing process. This is actually a *requirement* because entities may be asynchronous with the document structure (ie. they can drastically alter the structure). Once this asynchronisity is removed, there is no need to enforce this rule because entity resolution cannot affect the document structure beyond the child list of the element in which the entity is being resolved. If we restricted entities even further to *requiring* that there be a single containing element for the entire content of the entity, then there are even fewer structural changes possible: indeed, in most implementations, you would have an object that would be almost identical to the element + ENTITY attribute object. From: "Henry S. Thompson" <ht@cogsci.ed.ac.uk> Date: Tue, 29 Oct 96 22:32:07 GMT To: "David G. Durand" <dgd@cs.bu.edu> (David G. Durand) Subject: Re: C.4 Undeclared entities? Cc: w3c-sgml-wg@w3.org OK, I'll bite. David is merely the last in a moderately long list (i.e. at least three people :-) who have asserted without any argument that "users won't include a <!DOCTYPE ...>, so we shouldn't require one for well-formedness." I have to say I just don't get it -- why ever not? They're going to have to do a lot of other, more substantial, things differently from what they are used to, if they are hope-to-die HTML mavens, who are the only group I can suppose David et al. have in mind. After all, both SGML fans and total newbies won't have any problem with following this rule. Why is it likely that HTML fans, who after all have at least HEARD of <!DOCTYPE ...>, will ignore this requirement but not, say, the requirement to provide explicit end tags? Or the requirement to quote all attribute values? Seems modest by comparison, and a small price to pay for SGML compatibility. ht Date: Tue, 29 Oct 96 17:23:42 CST From: Michael Sperberg-McQueen <U35395@UICVM.UIC.EDU> Subject: Re: D.1 Distinguish partial and full DTDs? To: W3C SGML Working Group <w3c-sgml-wg@w3.org> <tbray@textuality.com> On Fri, 25 Oct 1996 12:05:01 -0400 Tim Bray said: >Right now, XML distinguishes "well-formed" and "valid" documents. >"Well-formed" may require recourse to part of a DTD, for example entity >declarations and [depending on EMPTY syntax] EMPTY declarations. > >However, If you ask an XML processor to validate an instance, that means >that the appearance of an undeclared element is an error, period. An >undeclared tag could be the result of (1) a typographical error while >typing in XML source with Notepad [it *will* happen], or (2) a missing >declaration in the DTD. It is not the job of an XML processor to intuit >which is the case. > >More concisely, I do *not* favor partial DTD's in the context of >validation. It seems to me this means we need to know whether something is in fact a partial DTD, or is (intended to be) a full DTD. (I am using 'DTD' here in the sense of 'explicit markup declarations', not in the larger sense prescribed by 8879). Something intended to be a full DTD is in theory suitable for validation; something intended only to be a partial DTD (e.g. to provide declarations of external entities) is not suitable as the basis for validation. In the one case, having an element with an unknown GI is an error and should be flagged as such by any validating parser. In the other case, such an element is the normal state of affairs and it is senseless to try to validate the document: an ideally helpful system would say "Er, it's pointless trying to validate this, it only has a partial DTD" rather than issuing a few hundred error messages. But no system can know which to do unless it can distinguish a full DTD from a partial DTD, i.e. unless there is something in the document to say "This set of markup declarations is complete" or "This set of markup declarations is not complete". So, I think the answer to the original question is, Yes, there should be an XML parameter entity to indicate whether the DTD given is a full DTD (as for SGML) or a partial DTD not intended to make the document valid (probably, in practice, intended only to make it well-formed). -C. M. Sperberg-McQueen Date: Tue, 29 Oct 96 17:39:05 CST From: Michael Sperberg-McQueen <U35395@UICVM.UIC.EDU> Subject: Re: A note on case sensitivity To: W3C SGML Working Group <w3c-sgml-wg@w3.org> On Fri, 25 Oct 1996 22:41:12 -0400 <lee@sq.com> said: >Tim Bray >> Making XML markup case-sensitive is >> clearly the *right* thing to do, > >I agree. As do I. I also think it's the most practicable thing to do. We will never have less XML legacy data to worry about than we do now -- so it will never be easier to introduce case sensitivity throughout the markup language than it is now. >> but adds a lot of work for those who >> want to interoperate with SGML and especially HTML. > >Well, the internationalised HTML working group is facing the same issue >at exactly this moment, and seems to have reached the same conclusion: >It looks like I18N HTML will have to have NAMECASE NO. Let's go with them. >> Failing that, I don't suppose there's any support for going back to >> 7-bit characters, just for GI's and attribute names? > >If it would help, I would support it. If we *have* to have case folding, which I strenuously dispute, then the simplest fallback is to use the default case-folding tables of the Unicode Consortium, which are not hard to get (they come on the CD when you buy the book, nowadays, and I suspect they're even on the net somewhere). As the Unicode Standard Version 2.0 says (section 4.1, Case, p. 4-2): "In a few instances, upper- and lowercase mappings may differ from language to language between writing systems that employ the same letters. Examples include Turkish (... [dotted and dotless I]) and French (...). However, in general the vast majority of case mappings are uniform across languages." I don't think case-folding is essential to the utility or success of XML. Even if it is, though, I don't think it's more important than internationalization. Let's all take a deep breath. Case-sensitive element names, attribute names, attribute values. We can live with that. Element names restricted to a subset of the alphabet (say, A-J, all uppercase)? I couldn't live happily with that, and I can't see asking the native speakers of every language but English and Latin to do so. -C. M. Sperberg-McQueen Date: Tue, 29 Oct 1996 17:58:45 -0600 From: Len Bullard <cbullard@HiWAAY.net> To: lee@sq.com CC: w3c-sgml-wg@w3.org Subject: Re: C.4 Undeclared entities? lee@sq.com wrote: > > But if you examine the byte stream after the structovator has run & made > a DTD, you may well have valid SGML. A philosopher might opine that > For every DTD-less XML file > There existeth a Document Divine, > Which conformeth even to the uttermost mile > Of Iso Eight Eight Seven Nine. > > Well it doesn't scan very well, but it parses :-) No Lee, but it is excellent nonetheless! Someone put that in the spec footnotes or introduction. len From: Charles@sgmlsource.com (Charles F. Goldfarb) To: "Steven J. DeRose" <sjd@ebt.com> Cc: w3c-sgml-wg@w3.org Subject: Re: Transclusion Date: Wed, 30 Oct 1996 00:47:49 GMT On Tue, 29 Oct 1996 13:58:10 -0500, "Steven J. DeRose" <sjd@ebt.com> wrote: >The Term transclusion comes from Nelson's seminal book Literary Machines, >and refers to a characteristic at the user level, not the parser level. The >interactional semantic called transclusion doesn't care whether you parse >the referenced data in the referencing context or not. The notion of >"parsing context" is SGML-specific, and is itself out of context when >discussing transclusion. For many cases of transclusion, the referencing or >the referenced data, or both, may be in media that have not even have an >applicable notion of "parsing". Steve, thanks for clarifying this point. What the parser shows the application is standardized in 8879. What the application shows the user is not. In particular, text that is not in the SGML syntactic content could appear as semantic content in the application's presentation of the document. The point I was trying to make (which I see now has nothing to do with transclusion) does concern whether an entity referenced by a syntactic entity reference must be accessed and parsed. According to 8879, it must but, as Steve correctly points out, the application -- as with any pcdata -- may choose whether or not to show it to the user after parsing it. The only way to avoid this required access and parsing is to use an entity attribute. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: gtn@ebt.com (Gavin Nicol) Cc: sjd@kirk.mit.edu, w3c-sgml-wg@w3.org Subject: Re: Transclusion Date: Wed, 30 Oct 1996 00:47:52 GMT On Tue, 29 Oct 1996 17:11:03 -0500, gtn@ebt.com (Gavin Nicol) wrote: >>So I agree with Charles, namely that we're better off with ENTITY attributes >>-- but I don't think the reasons have much to do with 8879 conformance. > >Well, the point I was trying to make is that if we have synchronous >entities, there is nothing *stopping* the parser from performing the >nice optimisation of fetching the entity, and parsing it, only >when needed. I don't see any problem with this, as long as the external SGML text entity doesn't change the parsing state. As David pointed out, the standard doesn't address timing, just context. The external SGML text entity would have to be parsed as though it occurred as a replacement for the entity reference. The text following the entity reference has to be parsed as if it followed the replacement text. The challenge will be to define (and enforce?) the restrictions on a non-state-changing external entity. On the other hand, there is no reason why a smart parser can't do anticipatory fetching and parsing of entities invoked by an attribute value, just as easily. In fact, it should be easier, as such entities establish their own parsing context. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- Date: Tue, 29 Oct 1996 17:49:38 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray <tbray@textuality.com> Subject: The external text entity problem At 12:47 AM 10/30/96 GMT, Charles F. Goldfarb wrote: >The point... does concern whether an entity referenced by a syntactic entity >reference must be accessed and parsed. According to 8879, it must... > >The only way to avoid this required access and parsing is to use an entity >attribute. Hence the [entirely valid] concern on the WG & ERB about the use of external text entities in XML. They are highly useful for authoring, but given the requirements of 8879, if we include them we are in danger of requiring that, to be "XML compliant", any browser, no matter how lightweight, be required to pull in & interpolate text entities from all over creation. Which is kind of silly since it is clear that doing this is hard in modern browser architectures, and it is far from clear that this is the right semantic for providing access to distributed modular documents, and it is *extremely* clear that we'd like to make it easy for browsers to achieve XML compliance. And since the real reason for having external text entities is to support authoring anyhow. The first-cut solution was to make them optional, which carries its own set of costs. *BUT*, I think there's another way to avoid this required access. This tactic, independently proposed by several people, is to zero in on the word "parse" and say that an XML Processor is, in 8879 terms, a "parser" only when it's trying to validate against a real DTD. In which case, of course, it has to go pull in the entities. When it's just reading a document and checking for well-formedness not validity (the natural behavior of a client browser), we can say that it's not, in 8879 terms, "parsing", and is thus not required to interpolate external text entities. Authors will quickly learn to resolve external text entities before sending instances down network pipes. This works well in XML because the presence or absence of a text entity can never affect well-formedness - we've already decided they have to be element-synchronous. I see this as a solution that allows XML to standardize on SGML's management architecture at the authoring end, bless browsers as compliant without placing unreasonable demands on their authors, and remove optional features from XML. Also, it's easy to document in the spec. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 From: lee@sq.com Date: Tue, 29 Oct 96 22:27:30 EST To: Charles@sgmlsource.com, sjd@ebt.com Subject: Re: Transclusion Cc: w3c-sgml-wg@w3.org > The only way to avoid this required access and parsing is to use an entity > attribute. If XML is mostly for tools (as I hope) and not to be typed by Humans, it doesn't really matter what kind of syntax is used, as long as it's simple enough that people implement it without losing their dinners. In this case, SGML conformance is important, but so is having a respectable-looking syntax. I think it's very important to avoid syntax that is only for political reasons. And anything done for SGML conformance that wouldn't otherwise have been done that way had better be stated clearly, explicitly and firmly in ISO 8879. There is no point in conforming to unwritten assumptions. By definition, you can't. I'm not sure if this helps (I hoe it does) but I can see another way. Let's ask the question, when does the parse finish? A browser (let's say) is displaying the document as it receives it, and then goes back and deals with entities, and, when it has finished, it has perhaps also parsed the document and validated it. Part way through the process, perhaps it hasn't fetched that entity whose contents is to be include here. The order in which it does thigs with respct to time is not important. What is important is that it ends up with the correct result. If the browser is allowed to display data as it fetches it, it can also display the document before it's finished accessing included entities. Well, OK, I don't know if that argument is a little bit weasel-like. But if parsing of inline data is what you want, &this; is the way to get it, right now. It is true that there could be an "XML-INCLUDE" element type; <XML-INCLUDE file="http:/where/ever.xml"> description of contents for user to see until it's loaded, perhaps </XML-INCLUDE> is that really better? Perhaps it is -- you don't need to define an entity. On the other hand, we have another element in the namespace (XML-INCLUDE) and we've lost indirection, so we can't reuse links. If we have the entitity, we might as well &do; &this; &with; it. On the other hand, if there are no entities at all, & ceases to be a special character, which is neat. The very first SGML document I ever saw was abut R&D in Europe. It was created with an early SGML editor... that had conveniently put at the start of the document <!ENTITY D ""> so that the document ended up being about R in Europe... The fewer character sequences that are special in text, the fewer surprises you get. Quick quiz for troff users (but don't reply on the list!): after the book 'trouble in the antarctic' was mentioned in one troff document, the output seemed to turn into a foreign language. Why? Lee Date: Tue, 29 Oct 1996 20:33:32 -0800 (PST) From: Bill Smith <bill.smith@Eng> Subject: Re: C.4 Undeclared entities? To: w3c-sgml-wg@w3.org Henry Thompson wrote: > OK, I'll bite. David is merely the last in a moderately long list > (i.e. at least three people :-) who have asserted without any argument > that "users won't include a <!DOCTYPE ...>, so we shouldn't require > one for well-formedness." I have to say I just don't get it -- why > ever not? They're going to have to do a lot of other, more > substantial, things differently from what they are used to, if they > are hope-to-die HTML mavens, who are the only group I can suppose > David et al. have in mind. I won't speak for David but I for one would like to use XML without a DTD. I can imagine doing lot's of interesting (perhaps impromptu) work that would be difficult if a DTD were required. The proposition that only valid XML documents be interchanged precludes this type of work. Requiring a "dummy" DOCTYPE declaration raises the question - Why? I doubt that 8879 conformance will fly as an answer for all XML documents. Let 8879 conformance apply to *valid* XML documents and have somewhat more relaxed rules for well-formed and other XML documents. If an XML document contains a DOCTYPE, the receiving application would be expected to locate, obtain, and use the referenced DTD. Without the DOCTYPE, a generic XML application should assume well-formed input. Specific applications might assume something less than well-formed. What's wrong with this picture? Finally, I'll take a perhaps unpopular position and state that I doubt we have written the last chapter on document structure. I doubt we ever will. If we leave XML open-ended, someone might invent something that goes well beyond what is possible with a DTD while still remaining, even if tenuously, within the XML framework. To me, that is a very interesting possibility and I see no reason to discourage such activity. Requiring DTDs, dummy or otherwise, effectively limits XML's potential by stating that DTDs are the only mechanism by which document structure can be specified. > After all, both SGML fans and total > newbies won't have any problem with following this rule. Why is it > likely that HTML fans, who after all have at least HEARD of > <!DOCTYPE ...>, will ignore this requirement but not, say, the > requirement to provide explicit end tags? Or the requirement to quote > all attribute values? Seems modest by comparison, and a small price > to pay for SGML compatibility. While some HTML fans have heard of <!DOCTYPE ...>, I suspect that only a small percentage of HTML documents actually contain a DOCTYPE declaration. I've done a statistically insignificant, not even close to random survey, of some web sites to see who uses <DOCTYPE ...> on their home page. Here are the results: Sun no Spyglass yes JavSoft no Ebt yes Netscape no Softquad yes Microsoft no Textuality yes Ncsa no Passage yes Adobe no Arbortext yes Excite no W3c yes Yahoo no Gca yes Lycos no Isogen yes Verity no Fulcrum yes Sgmlsource yes I'll leave a detailed analysis of the pseudo-results to the individual but at the highest level, SGML literati use DOCTYPE and others don't. Explicit end tags will be forgotten or omitted. Attribute values won't be quoted. Countless "errors" will be found in XML documents, just as they are in HTML and SGML documents. In at least some applications, these errors will manifest themselves in obvious ways and authors will take corrective action. However, the absence of a dummy DOCTYPE in a well-formed XML document probably won't be obvious in many applications. Why? If my suspicion is correct I doubt that most developers will put in code to check for a condition that if encountered can cause no harm. In fact they would normally do something quite different - eliminate the condition. We can provide that service to all XML developers simply by stating that DOCTYPE is required only for XML documents that purport to be valid. Requiring that all XML documents carry <!DOCTYPE foo SYSTEM> in the name of 8879 conformance seems quite the hack to me. I and others have argued that it will be ignored by XML users. I doubt that existing SGML systems will be able to do much more than report an error upon encountering <!DOCTYPE foo SYSTEM>. Of course the void's entity manager could locate foo and return it but as I've stated before I have doubts about the void. So what is the practical purpose of requiring a DOCTYPE declaration in less-than-valid XML? Date: Tue, 29 Oct 1996 20:40:00 -0800 (PST) From: Bill Smith <bill.smith@Eng> Subject: Re: D.1 Distinguish partial and full DTDs? To: w3c-sgml-wg@w3.org Michael Sperberg-McQueen wrote: > So, I think the answer to the original question is, Yes, there > should be an XML parameter entity to indicate whether the DTD > given is a full DTD (as for SGML) or a partial DTD not intended > to make the document valid (probably, in practice, intended only > to make it well-formed). I think we should forgo partial DTDs. XML should be specified in such a way to permit (require) parsing of well-formed XML without reference to *any* DTD-like information. Of course, this would require that we revisit optional external text entities. Date: Tue, 29 Oct 1996 20:42:02 -0800 (PST) From: Bill Smith <bill.smith@Eng> Subject: Re: A note on case sensitivity To: w3c-sgml-wg@w3.org Michael Sperberg-McQueen wrote: > As do I. I also think it's the most practicable thing to do. We > will never have less XML legacy data to worry about than we do now > -- so it will never be easier to introduce case sensitivity > throughout the markup language than it is now. Well said. > Let's all take a deep breath. Case-sensitive element names, > attribute names, attribute values. We can live with that. Element > names restricted to a subset of the alphabet (say, A-J, all > uppercase)? I couldn't live happily with that, and I can't see > asking the native speakers of every language but English and Latin > to do so. Ditto. Date: Wed, 30 Oct 1996 09:14:32 -0500 To: Michael Sperberg-McQueen <U35395@UICVM.UIC.EDU>, W3C SGML Working Group <w3c-sgml-wg@w3.org> From: "Eve L. Maler" <elm@arbortext.com> Subject: Re: D.1 Distinguish partial and full DTDs? At 05:23 PM 10/29/96 CST, Michael Sperberg-McQueen wrote: >It seems to me this means we need to know whether something is in >fact a partial DTD, or is (intended to be) a full DTD. (I am using >'DTD' here in the sense of 'explicit markup declarations', not in >the larger sense prescribed by 8879). Something intended to be a >full DTD is in theory suitable for validation; something intended >only to be a partial DTD (e.g. to provide declarations of external >entities) is not suitable as the basis for validation. On the other hand, we could get right down to business and describe an XML document as claiming to be in a ready-to-validate state or not. The full/partial business makes me uncomfortable because the ends are just degenerate cases of the middle, but stating that you think something is ready to be validated is a useful piece of information. >... >So, I think the answer to the original question is, Yes, there >should be an XML parameter entity to indicate whether the DTD >given is a full DTD (as for SGML) or a partial DTD not intended >to make the document valid (probably, in practice, intended only >to make it well-formed). (PI, not parment, right?) People who are making ad hoc document structures will not want to add a PI saying that the structures are ad hoc. It would make more sense to require documents that are "complete" to have a PI saying so, since saying so would buy more useful processing -- namely, validation by recipients. And since much document exchange (I'm guessing) won't be for the purpose of validation by recipients, the PI can be left off a lot of the time. Eve Date: Tue, 29 Oct 1996 19:35:24 -0500 To: "Henry S. Thompson" <ht@cogsci.ed.ac.uk> From: Murray Maloney <murray@sq.com> Subject: Re: C.4 Undeclared entities? Cc: "David G. Durand" <dgd@cs.bu.edu> (David G. Durand), w3c-sgml-wg@w3.org At 10:32 PM 29-10-96 GMT, Henry S. Thompson wrote: >OK, I'll bite. David is merely the last in a moderately long list >(i.e. at least three people :-) who have asserted without any argument >that "users won't include a <!DOCTYPE ...>, so we shouldn't require >one for well-formedness." I have to say I just don't get it -- why >ever not? OK, I'll bite back... I don't get why I should have to include, at the top of a document, a statement that says: There is a formal grammar definition over yonder that can tell you what kinds of SGML elements and entities and attributes you might find in this document. I can deduce that all by myself -- whether I am me or a program. I don't so much need a way to tell someone what syntax they might encounter as I do a way to tell them what the darned processing expectations are. That is, how do I say: "This is a hypertext link or anchor?" This past weekend I consolidated about twenty different style sheets into one. I had had one stylesheet for each of twenty document types. Then I realized that the twenty doc types had a lot in common. I also noted that my stylesheet did not have to limit itself to a single DTD. In fact, I could include GIs in my stylesheet that might not even exist in most of my DTDs. So, now I wonder why I even need a DTD, except to tell my application -- through its own convention -- that certain element types are links or anchors. >They're going to have to do a lot of other, more >substantial, things differently from what they are used to, if they >are hope-to-die HTML mavens, who are the only group I can suppose >David et al. have in mind. I guess we can all imagine the world accepting some of the syntactic requirements of a useful document markup language. Since many of us are in the biz, I guess that we expect to deploy tools to make it all easy for Lois. >After all, both SGML fans and total >newbies won't have any problem with following this rule. Why is it >likely that HTML fans, who after all have at least HEARD of ><!DOCTYPE ...>, will ignore this requirement The thing is: As has been pointed out earlier, my document may properly be a valid document according to multiple DTDs. If I want my document to be maximally interoperable among my document types, I won't declare that it conforms to only one document type for perpetuity. I would rather simply have my document and use it as I, or my application, requires. >but not, say, the >requirement to provide explicit end tags? Or the requirement to quote >all attribute values? Seems modest by comparison, and a small price >to pay for SGML compatibility. I guess that I can see the value for processing tools to be able to parse documents unambiguously. To do that, we need a regular grammar that contains "no surprises". Explicit end-tags and quoted strings help reduce surprises. I don't see how a <!DOCTYPE helps an XML processor to reduce surprises at all. The argument that a doctype declaration can be provided by an upstream processor would seem to satisfy the desire for compatibility with SGML. There is no need to burden XML with <!DOCTYPE Regards, Murray ************* NOTE NEW ADDRESS AND PHONE NUMBER ***************** Murray Maloney murray@sq.com Technical Director http://www.softquad.com SoftQuad Inc. P.O. Box 2025 Phone: +1 416 544-3010 20 Eglinton Avenue West, 12th Floor Fax: +1 416 544-0300 Toronto, Ontario, Canada M4R 1K8 Date: Wed, 30 Oct 1996 10:05:55 -0500 From: gtn@ebt.com (Gavin Nicol) To: Charles@sgmlsource.com CC: sjd@ebt.com, w3c-sgml-wg@w3.org Subject: Re: Transclusion >The point I was trying to make (which I see now has nothing to do with >transclusion) does concern whether an entity referenced by a syntactic entity >reference must be accessed and parsed. According to 8879, it must >but, as Steve correctly points out, the application -- as with any >pcdata -- may choose whether or not to show it to the user after >parsing it. > >The only way to avoid this required access and parsing is to use an entity >attribute. If this is indeed the letter of the law, then the law is not very applicable to XML. As I pointed out before, once there are restrictions on the structure of entities, the *need* for accessing the entities is removed. Date: Wed, 30 Oct 1996 10:01:05 -0500 From: gtn@ebt.com (Gavin Nicol) To: Charles@sgmlsource.com CC: sjd@kirk.mit.edu, w3c-sgml-wg@w3.org Subject: Re: Transclusion >On the other hand, there is no reason why a smart parser can't do >anticipatory fetching and parsing of entities invoked by an attribute >value, just as easily. In fact, it should be easier, as such entities >establish their own parsing context. Sure, though I would say that for network usage, *delayed* parsing would be at least as common. I'm glad to see my point has gotten across. Date: Wed, 30 Oct 1996 12:08:25 -0500 To: w3c-sgml-wg@w3.org From: "David G. Durand" <dgd@cs.bu.edu> (David G. Durand) Subject: Re: C.4 Undeclared entities? At 5:32 PM 10/29/96, Henry S. Thompson wrote: >OK, I'll bite. David is merely the last in a moderately long list >(i.e. at least three people :-) who have asserted without any argument >that "users won't include a <!DOCTYPE ...>, so we shouldn't require >one for well-formedness." I have to say I just don't get it -- why >ever not? They're going to have to do a lot of other, more >substantial, things differently from what they are used to, if they >are hope-to-die HTML mavens, who are the only group I can suppose >David et al. have in mind. After all, both SGML fans and total >newbies won't have any problem with following this rule. Why is it >likely that HTML fans, who after all have at least HEARD of ><!DOCTYPE ...>, will ignore this requirement but not, say, the >requirement to provide explicit end tags? Or the requirement to quote >all attribute values? Seems modest by comparison, and a small price >to pay for SGML compatibility. > >ht I've not been explicit enough. I think people will not include the doctype when it _does not add value_. If I am not using a DTD, then a doctype is not valuable. For those people who can live with well-formed, rather than valid XML, the doctype will not add value and will not be included. A requirement that it must be included on well-formed, but invalid documents will be ignored. More people include the title tags than doctype tags in HTML becuase title tags add value, not because they care about conformance. They will do what is necessary to make things work, and resent requirements that are not necessary to make things work. The value of doctype for valid XML (with a DTD) is not a question in my mind, or I think anyone else's. Attempting to require people to say what they are _not_ using, when it has no effect on parsing seems like a losing proposition. End tags and attribute values have much better cases for the restrictions we're putting on them -- in terms of XML processing, as well as in terms of compatibility. I won't be surprised if many people start using DTDs in order to get default attribute values, rather than to get validation. We'll see. -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Wed, 30 Oct 1996 12:08:33 -0500 To: W3C SGML Working Group <w3c-sgml-wg@w3.org> From: "David G. Durand" <dgd@cs.bu.edu> (David G. Durand) Subject: Re: D.1 Distinguish partial and full DTDs? At 5:23 PM 10/29/96, Michael Sperberg-McQueen wrote: >On Fri, 25 Oct 1996 12:05:01 -0400 Tim Bray said: >>More concisely, I do *not* favor partial DTD's in the context of >>validation. > >It seems to me this means we need to know whether something is in >fact a partial DTD, or is (intended to be) a full DTD. >snip snip... >In the one case, having an element with an unknown GI is an error >and should be flagged as such by any validating parser. In the >other case, such an element is the normal state of affairs and it is >senseless to try to validate the document: an ideally helpful >system would say "Er, it's pointless trying to validate this, it >only has a partial DTD" rather than issuing a few hundred error >messages. But no system can know which to do unless it can >distinguish a full DTD from a partial DTD, i.e. unless there is >something in the document to say "This set of markup declarations is >complete" or "This set of markup declarations is not complete". > >So, I think the answer to the original question is, Yes, there >should be an XML parameter entity to indicate whether the DTD >given is a full DTD (as for SGML) or a partial DTD not intended >to make the document valid (probably, in practice, intended only >to make it well-formed). Or, we can avoid any feature that would make this distiction necessary. So we have _no declarations_ or a _full DTD_. This is why I favor some distinctive syntax for empty elements (any of the possibilities will do). I can't remember what other sticking points there are to eliminating the notion of partial DTDs. Oh, yes, entities. If we allow transclusion semantics, browsers can treat an undefined entity as a broken link, in the same way they treat a broken grapic now... This is another reason I think that unresolved entities are natural. Or undefined entities can be an error in a DTD- and subset-less document. BTW what is happening with the subset? If we need "partial DTDs" couldn't we implement them more nicely as subsets to empty doctypes (which in this case would add value for the user, by letting them declare entities). A subset without a DTD would be well-formed, whatever declarations it contained. -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Wed, 30 Oct 96 10:47:23 CST From: Michael Sperberg-McQueen <U35395@UICVM.UIC.EDU> Subject: Re: D.1 Distinguish partial and full DTDs? To: W3C SGML Working Group <w3c-sgml-wg@w3.org> <elm@arbortext.com> On Wed, 30 Oct 1996 09:14:24 -0500 Eve L. Maler said: >At 05:23 PM 10/29/96 CST, Michael Sperberg-McQueen wrote: >>So, I think the answer to the original question is, Yes, there >>should be an XML parameter entity to indicate whether the DTD >>given is a full DTD (as for SGML) or a partial DTD not intended >>to make the document valid (probably, in practice, intended only >>to make it well-formed). > >(PI, not parment, right?) People who are making ad hoc document Right. Processing instruction, not parameter entity. I shouldn't draft postings when I'm tired. Eve is surely right that claiming validity is probably more useful and to the point than saying 'DTD is complete/incomplete'; also right to suggest the default should be 'no validity claimed'. -Michael Sperberg-McQueen Date: Wed, 30 Oct 1996 12:20:17 -0500 To: w3c-sgml-wg@w3.org From: "David G. Durand" <dgd@cs.bu.edu> (David G. Durand) Subject: Re: A note on case sensitivity At 8:42 PM 10/29/96, Bill Smith wrote: >Michael Sperberg-McQueen wrote: > >> As do I. I also think it's the most practicable thing to do. We >> will never have less XML legacy data to worry about than we do now >> -- so it will never be easier to introduce case sensitivity >> throughout the markup language than it is now. > >Well said. > >> Let's all take a deep breath. Case-sensitive element names, >> attribute names, attribute values. We can live with that. Element >> names restricted to a subset of the alphabet (say, A-J, all >> uppercase)? I couldn't live happily with that, and I can't see >> asking the native speakers of every language but English and Latin >> to do so. > >Ditto. Yea, verily, yea! Now the agonizing part: are !element !attlist, etc. upper or lower case? I argue for lower case, given that studies of roman alphabet readability dhave shown mixed case to be more distinctive, legible, and easy to read than ALL CAPS TEXT. I have having to shout when I type tags.... -- David Since the religious aspect of this issue is very large, perhaps comments should be restricted to a single vote for preferred case... I could live will ALL CAPS BUT I FIND IT UGLY AND HARD TO READ. I WILL NOT POST FURTHER ON THE ISSUE OF WHICH CASE TO USE. I HAVE SAID MY PIECE. I'D STILL MUCH RATHER LIVE WITH UPPER CASE THAN TRY TO DEFINE CORRECT CASE FOLDING IN UNICODE, or implement it. RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Wed, 30 Oct 1996 12:20:07 -0500 To: W3C SGML Working Group <w3c-sgml-wg@w3.org> From: "David G. Durand" <dgd@cs.bu.edu> (David G. Durand) Subject: Re: D.1 Distinguish partial and full DTDs? At 10:47 AM 10/30/96, Michael Sperberg-McQueen wrote: >Eve is surely right that claiming validity is probably more >useful and to the point than saying 'DTD is complete/incomplete'; >also right to suggest the default should be 'no validity claimed'. And since valid documents will require a doctype, we don't need any extra flag at all! We expect that it is valid if it has a doctype, and well-formed if it has no doctype (or maybe a "<!doctype foo SYSTEM [ some dumb subset ]>" doctype, if we can't eliminate the notion of partial DTDs). --- David >-Michael Sperberg-McQueen RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ http://www.dynamicdiagrams.com/services_map_main.html Date: Wed, 30 Oct 1996 10:01:05 -0500 From: gtn@ebt.com (Gavin Nicol) To: Charles@SGMLsource.com CC: sjd@kirk.mit.edu, w3c-sgml-wg@w3.org Subject: Re: Transclusion >On the other hand, there is no reason why a smart parser can't do >anticipatory fetching and parsing of entities invoked by an attribute >value, just as easily. In fact, it should be easier, as such entities >establish their own parsing context. Sure, though I would say that for network usage, *delayed* parsing would be at least as common. I'm glad to see my point has gotten across. Date: Wed, 30 Oct 1996 12:56:42 -0500 To: Charles@sgmlsource.com, gtn@ebt.com (Gavin Nicol) From: "Steven J. DeRose" <sjd@ebt.com> Subject: Re: Transclusion Cc: sjd@kirk.mit.edu, w3c-sgml-wg@w3.org At 12:47 AM 10/30/96 GMT, Charles F. Goldfarb wrote: >I don't see any problem with this, as long as the external SGML text entity >doesn't change the parsing state. As David pointed out, the standard doesn't >address timing, just context. The external SGML text entity would have to be >parsed as though it occurred as a replacement for the entity reference. The text >following the entity reference has to be parsed as if it followed the >replacement text. The challenge will be to define (and enforce?) the >restrictions on a non-state-changing external entity. Exactly right. The good news is that there is a convenient source for that information: this information is exactly what the SGML Open fragment specification (TR9601) provides. It gives a plain-text way to encode the parsing context of a synchronous fragment, designed precisely so that the referenced entity's replacement text can indeed "be parsed as though it occurred as a replacement for the entity reference". Likewise, the restrictions we have already imposed in XML (on #CURRENT, OMITTAG, USEMAP, and so on) let us avoid residual effects ways the referenced entity to leave on the parsing context of the referencing entity. The only case I can think of that might not be fully covered is RE handling state, but our new rule on that almost certainly makes the differenc, if there is any, moot. Oh, I should note that for this purpose one must distinguish parsing context per se, from validation context: although one can parse correctly, one cannot in this case validate that IDs are unique. Obviously that would require sending a complete list of the IDs in every directly or indirectly referened entity, which would be a pretty high cost to gain the ability for every recipient to validate what was sent, which should have been validated by the sender ahead of time anyway. Steve Date: Wed, 30 Oct 1996 10:23:22 -0500 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@w3.org Subject: Re: The external text entity problem >>The only way to avoid this required access and parsing is to use an entity >>attribute. > >Hence the [entirely valid] concern on the WG & ERB about the use >of external text entities in XML. They are highly useful for authoring, >but given the requirements of 8879, if we include them we are in danger of >requiring that, to be "XML compliant", any browser, no matter how lightweight, >be required to pull in & interpolate text entities from all over creation. Can someone please prove that this is so? The distinction between an "SGML comformant parser" and an "XML parser" might be a good one to make. For the sake of argument, let's say we have an XML parser that parses entity references. Can anyone show me a case where it is absolutely necessary to resolve the entity before parsing can continue (especially considering that replacement text would become psuedo-elements and thereby not affect the structure much at all). To: w3c-sgml-wg@w3.org Subject: Re: A note on case sensitivity Date: Wed, 30 Oct 1996 10:26:18 -0800 From: Joe English <jenglish@crl.com> David G. Durand <dgd@cs.bu.edu> (David G. Durand) wrote: > >Michael Sperberg-McQueen wrote: > >> Let's all take a deep breath. Case-sensitive element names, > >> attribute names, attribute values. We can live with that. > [...] > > Yea, verily, yea! > > Now the agonizing part: are !element !attlist, etc. upper or lower case? I don't have the Handbook handy, but a quick test with SGMLS indicates that NAMECASE GENERAL NO requires keywords to be UPPERCASE. (This includes keywords like CDATA, NMTOKENS, ANY, and O, as well as <!ELEMENT...> <!ATTLIST...> <!ETCETERA...>). > I argue for lower case, given that studies of roman alphabet readability > dhave shown mixed case to be more distinctive, legible, and easy to read > than ALL CAPS TEXT. I have having to shout when I type tags.... For tags you can use whatever case you like; it's only the markup declarations that are affected. I'll vote "yes" to NAMECASE GENERAL NO (case-sensitivity). --Joe English jenglish@crl.com Date: Wed, 30 Oct 1996 11:00:23 -0800 (PST) From: Bill Smith <bill.smith@Eng> Subject: Re: The external text entity problem To: w3c-sgml-wg@w3.org Gavin Nicol wrote: > Can someone please prove that this is so? The distinction between an > "SGML comformant parser" and an "XML parser" might be a good one to > make. For the sake of argument, let's say we have an XML parser that > parses entity references. Can anyone show me a case where it is > absolutely necessary to resolve the entity before parsing can > continue (especially considering that replacement text would become > psuedo-elements and thereby not affect the structure much at all). The case I have in mind is one, for a valid XML document, where an external text entity contains markup that would change the content model of the document instance based on parse-time inclusion versus use-time inclusion. I'm not a parser expert but suspect that we may have a problem with delayed parsing of external text entities in valid XML even if we preclude asynchronous entities. Date: Wed, 30 Oct 1996 14:27:09 -0500 To: "David G. Durand" <dgd@cs.bu.edu> (David G. Durand), w3c-sgml-wg@w3.org From: "Eve L. Maler" <elm@arbortext.com> Subject: Re: A note on case sensitivity I strongly disagree about case sensitivity. We have zero XML legacy data, but a *ton* of HTML and SGML legacy data, as well as legacy coding experience (which weighs more heavily, I think). NAMECASE GENERAL should be YES in XML. I don't understand the A-J analogy. How can case insensitivity be like having a restricted alphabet, if the difference is only "case" (whatever that notion means) and not something more significant that makes the thing turn into another character entirely? Particularly considering that HyTime makes a distinction (if a weak and conventional one) between !element and !ELEMENT, but also on the other grounds Paul Grosso mentioned earlier, I'd hate to require a single case -- particularly lowercase -- for SGML keywords. Eve At 12:20 PM 10/30/96 -0500, David G. Durand" (David G. Durand wrote: >At 8:42 PM 10/29/96, Bill Smith wrote: >>Michael Sperberg-McQueen wrote: >> >>> As do I. I also think it's the most practicable thing to do. We >>> will never have less XML legacy data to worry about than we do now >>> -- so it will never be easier to introduce case sensitivity >>> throughout the markup language than it is now. >> >>Well said. >> >>> Let's all take a deep breath. Case-sensitive element names, >>> attribute names, attribute values. We can live with that. Element >>> names restricted to a subset of the alphabet (say, A-J, all >>> uppercase)? I couldn't live happily with that, and I can't see >>> asking the native speakers of every language but English and Latin >>> to do so. >> >>Ditto. > >Yea, verily, yea! > >Now the agonizing part: are !element !attlist, etc. upper or lower case? > >I argue for lower case, given that studies of roman alphabet readability >dhave shown mixed case to be more distinctive, legible, and easy to read >than ALL CAPS TEXT. I have having to shout when I type tags.... > > -- David > >Since the religious aspect of this issue is very large, perhaps comments >should be restricted to a single vote for preferred case... I could live >will ALL CAPS BUT I FIND IT UGLY AND HARD TO READ. I WILL NOT POST FURTHER >ON THE ISSUE OF WHICH CASE TO USE. I HAVE SAID MY PIECE. I'D STILL MUCH >RATHER LIVE WITH UPPER CASE THAN TRY TO DEFINE CORRECT CASE FOLDING IN >UNICODE, or implement it. > >RE delenda est. >I am not a number. I am an undefined character. >_________________________________________ >David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com >Boston University Computer Science \ Sr. Analyst >http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams >--------------------------------------------\ http://dynamicDiagrams.com/ >MAPA: mapping for the WWW \__________________________ >http://www.dynamicdiagrams.com/services_map_main.html > > > > Date: Wed, 30 Oct 1996 14:30:19 -0500 To: Joe English <jenglish@crl.com>, w3c-sgml-wg@w3.org From: "Eve L. Maler" <elm@arbortext.com> Subject: Re: A note on case sensitivity At 10:26 AM 10/30/96 -0800, Joe English wrote: >For tags you can use whatever case you like; >it's only the markup declarations that are affected. This isn't true. Element GIs are names, too, and if you have NAMECASE GENERAL NO and a declaration like the following (as DocBook does): <!ELEMENT FormalPara ...> ...your instance had better look like this: <FormalPara> ... </FormalPara> Eve Date: Wed, 30 Oct 96 13:34:02 CST From: Michael Sperberg-McQueen <U35395@UICVM.UIC.EDU> Subject: ERB meeting, 30 October 1996 To: W3C SGML Working Group <w3c-sgml-wg@w3.org> The ERB met this morning, 30 October 1996. Present: Bosak, Bray, Clark, DeRose, Hollander, Kimber, Maler, Paoli, Sharpe, Sperberg-McQueen. Absent: Magliery. The rationale given has not been checked by the ERB and is subject to correction and supplementation. B.10 What form should EMPTY elements take, if there are EMPTY elements in XML: <e>, <e/>, <e></e>, or <@e> (where the NET string is assumed to be '/>' and '@' is assumed to be an XML-specific flag for names of EMPTY elements; in SGML systems, '@' to be added to the set of name-start characters). Agreed unanimously: - to allow the form <e/> to be used in XML documents, with or without element declarations - to allow the form <e> to be used in XML documents, if and only if the elements are declared as EMPTY in some way (which ways are allowed or required depends on other open questions, such as D.2) - to use the string '/>' as the NET delimiter in the SGML declaration of XML documents - to specify that the <e> form is allowed for compatibility reasons Rationale: Allowing the form <e> simplifies learning and conversion for existing SGML and HTML documents and users -- one of the rare cases where these two populations seem to have the same requirement. Allowing some self-identifying form simplifies the parsing of documents significantly, and makes it much easier to work without explicit declarations. Allowing both forms was felt to be a useful compromise -- part of the committee would have preferred to allow only one form, but was evenly split between the 8879 form and the self-identifying form. The entire committee felt unanimously, however, that allowing both forms was workable, particularly if the spec makes reasonably clear that one is the preferred form and the other is included only for compatibility reasons. The choice among the proposed self-identifying form was motivated in part by pragmatic considerations and in part by aesthetics. If XML EMPTY elements carry end-tags then the EMPTY keyword will have different meanings to an XML and an SGML system; this was felt to entail too many complications, so <e></e> was ruled out. The form <@e> was not felt significantly easier or harder to implement than the form <e/>, though this may vary in different implementations. Both <@e> and <e/> may be compatible or incompatible with whatever delimiters for empty elements are present in SGML-97. There was a clear preference, however, for the form <e/>, based in part on the visual effect of the slash. -C. M. Sperberg-McQueen From: lee@sq.com Date: Wed, 30 Oct 96 15:11:29 EST To: w3c-sgml-wg@w3.org, elm@arbortext.com Subject: Re: A note on case sensitivity > I don't understand the A-J analogy. How can case insensitivity be like > having a restricted alphabet, if the difference is only "case" (whatever > that notion means) and not something more significant that makes the > thing turn into another character entirely? Because the SGML model for case sensitivity does not work in some languages if the full alphabet is used. If lower case v and w both turned into capital W in English, in a case insensitive system, v and w would not be distinguished, and vine and wine would map to the same string. Hence <P ID="wine"> and <P ID="vine"> would be illegal. Now, although v and w do not both map into W in English, e and e acute both map into E in French, but do not do so in Canadian French. Hence, it would either have to be an error to use an e acute in an ID in XML, or you'd have to face the situation that two words as different as wine and vine might end up being collated together and considered the same string after conversion to upper case. > Particularly considering that HyTime makes a distinction (if a weak and > conventional one) between !element and !ELEMENT Well, it shouldn't. > Element GIs are names, too, and if you have > NAMECASE GENERAL NO and a declaration like the following (as > DocBook does): > > <!ELEMENT FormalPara ...> > > ...your instance had better look like this: > > <FormalPara> > ... > </FormalPara> Yes. Thankfully. Let's get rid of this annoying case folding thing! Lee To: w3c-sgml-wg@w3.org Subject: Re: A note on case sensitivity Jeferences: <2.2.16.19961030193019.095f2b92@village.doctools.com> Date: Wed, 30 Oct 1996 12:27:56 -0800 From: Joe English <jenglish@crl.com> Eve L. Maler <elm@arbortext.com> wrote: > At 10:26 AM 10/30/96 -0800, Joe English wrote: > >For tags you can use whatever case you like; > >it's only the markup declarations that are affected. > > This isn't true. Element GIs are names, too, and if you have > NAMECASE GENERAL NO and a declaration like the following (as > DocBook does): > > <!ELEMENT FormalPara ...> > ...your instance had better look like this: > <FormalPara> > </FormalPara> Sorry, I should have phrased that better. What I meant was that NAMECASE GENERAL NO only forces you to use upper-case for SGML keywords; you can use whatever case you like for element type names _if you're writing your own DTD_ (of course, you have to use the same case in instances as in the document type definition.) --jenglish@crl.com Date: Wed, 30 Oct 1996 15:33:38 -0500 From: gtn@ebt.com (Gavin Nicol) To: bill.smith@Eng CC: w3c-sgml-wg@w3.org Subject: Re: The external text entity problem >The case I have in mind is one, for a valid XML document, where an >external text entity contains markup that would change the content >model of the document instance based on parse-time inclusion versus >use-time inclusion. I'm not a parser expert but suspect that we may >have a problem with delayed parsing of external text entities in >valid XML even if we preclude asynchronous entities. I cannot see any cases (with the API's I have in my head) when an application could ever even know if the entity occurred (ie. the tree the application accessed would be identical for all practical purposes). I could see some differences in RE/RS recognition if we follow SGML's recognition rules, which would lead to some differences in tree structure, and this is another reason why I prefer the "no such thing as RE/RS" approach... To: W3C SGML Working Group <w3c-sgml-wg@w3.org> Subject: Re: ERB meeting, 30 October 1996 Summary: No stupid NET tricks! Date: Wed, 30 Oct 1996 18:49:41 -0800 From: Joe English <jenglish@crl.com> Michael Sperberg-McQueen <U35395@UICVM.UIC.EDU> wrote: > On Wed, 30 Oct 1996 14:59:04 -0500 I said: > > ... > >Agreed unanimously: > > ... > > - to use the string '/>' as the NET delimiter in the SGML > > declaration of XML documents I strongly urge the ERB to reconsider this. The /> NET trick is extremely fragile. Most current SGML parsers cannot even implement it, and those that do cannot enforce its proper usage. If a user forgets to supply the correct SGML declaration, SGML parsers will still accept XML documents *but will interpret them incorrectly without even issuing a warning.* Omitting the XML SGML declaration is the *first thing* most SGMLS users will try when they receive an XML document and find that the parser can't handle it. We're just asking for trouble if we adopt this solution. Another problem with the /> NET trick is that it's *still impossible for a structure-controlled application to create a parseable instance from ESIS*. This is one of the more serious problems with ISO 8879 from a tool-writer's standpoint; this is an issue that XML *must* address for it to satisfy design goal #9: "XML documents shall be easy to create." --Joe English jenglish@crl.com From: lee@sq.com Date: Wed, 30 Oct 96 23:14:13 EST To: jenglish@crl.com, w3c-sgml-wg@w3.org Subject: Re: ERB meeting, 30 October 1996 Michael Sperberg-McQueen <U35395@UICVM.UIC.EDU> wrote: > Agreed unanimously: > - to use the string '/>' as the NET delimiter in the SGML > declaration of XML documents Joe English wrote: > I strongly urge the ERB to reconsider this. > > The /> NET trick is extremely fragile. Most current > SGML parsers cannot even implement it, and those that do > cannot enforce its proper usage. Agreed. Note also that allowing <e> means that either (1) every XML parser has to be able to cope with parsing a DTD, merely to deal with <e>, or (2) sending an XML file without a DTD is an error if it contains an element that was declared with content model EMPTY. However, an XML parser that doesn't handle a DTD won't be able to cope with this error easily -- it will simply assume containment, and get to the end of the document. Probably it will then close all open elements, maybe issue a "document may have been truncated' error, and cheerfully continue, with a *completely wrong* interpretation of the document. Or, if you prefer, with a dramatically different ESIS. This is unacceptable. I realise <@e> wasn't very popular. But it has neither of these failure cases, and, unlike the NET proposal, is robust against error -- it would be an error to put an @ in front of an element not declared EMPTY, because until SGML's syntax can be improved, the @ would be in the element declaration. Afterwards, it could be implied -- you'd set the EMPTY ELEMENT START TAG OPEN delimter to "<@". Is error checking really so hard to figure out? Ask yourself (a) what happens if I forget to use the special marker? (1) with <e/ or <e/>: If there's a DTD, and we're in an SGML application nothing. NET is always optional. If we're an XML application using NSGMLs or some other ESIS-providing system (but can't be SGMLS, as it won't let you do the NET trick I think), it cannot be detected, since ESIS doesn't include minimisation information. An XML-specific application convention might say that an element using the NET feature must declared EMPTY. In that case, when we reach the end of the document, we declare a parse error and exit. (see (c) for the no DTD case) (2) with @ If there's a DTD, we detect the error immmediately, with today's unmodified SGML. Note: although the @ is part of the element name (a kludge, I admit), it is not polluting the reference concrete namespace -- there cannot be any existing document types using the RFC in which GIs began with "@".] (3) with <e> If you put a </e> in the document, and there's a DTD, it's an error and is detected. (b) what happens if I use the special marker where I shouldn't? (1) with <e/ or <e/>: It's legal in SGML. People using SGML tools will get very confused. But maybe this will help discourage that practice, when XML tools become available. In XML with a DTD, you'll get an error. If the XML parser is just an SGML parser and uses ESIS, NET information is not available to it, and it is no longer an error (since it's legal in SGML). (2) with @ If there is a DTD (whether ESIS or no, whether XML or SGML) an error is immediately given at the correct point of the error. (3) with <e> Meaningless in this case. No error. (c) what happens without a DTD, when I don't make an error? (1) with <e/ or <e/>: With XML and the application convention, everything is OK. You can't use NSGMLS and ESIS to implement this, though, since the fact tht NET was used is not included in ESIS. (Using the grove mechanism is probably harder than writing a parser in C from scratch for most non-SGML programmers, I would guess) (2) with @ The @ is part of the element name (with unmodified SGML) and gets passed through to the ESIS and the application. Hence, this approach works in all cases. It might not work with SGMLS, as it's not pure reference concrete syntax any more. But it should work with NSGMLS out-of-the-box (yes? James?) (3) with <e> This doesn't work without a DTD> You're hosed. Broken. Back to the drawing board. We have two languages if this is allowed. Language (1) is only for documents with a DTD. Language (2), XML, does not have empty elements. Note that allowing both <e> and <e/ is harder to implement than only allowing one of them -- it's harder than either of them alone. And allowing <e> at all means that every XML parser has just got a lot harder to write. If you allow <e>, you might as well not bother with <e/>, as it doesn't save the parser writer anything (still has to deal with old-fashioned EMPTY elements). Worse, neither of the two mechanisms accepted by the ERB has good error handling characteristics (as Joe English pointed out and I have attempted to enumerate). Oh well. If we stick with this, I propose to implement _only_ the DTDless XML, with no support for EMPTY at all, for my own use. It'll be _much_ quicker to write the code. If my implementation gets spread around quickly enough, it will become the defacto standard. Later, maybe I'll add #include nd other neat features I like. Marc. :-) Lee Date: Wed, 30 Oct 1996 22:41:00 -0600 (CDT) From: DAVEP@acm.org Subject: Re: ERB meeting, 30 October 1996 To: W3C-SGML-WG@w3.org I just read Lee's analysis of the fragility of the NET trickeries proposed for XML (message resent as <199610310415.XAA24860@www19.w3.org>). All this trickery does indeed get very fragile. There is a proposal that will probably be considered at the combined ISO/ANSI meeting the week before SGML '96 that proposes a neat solution using different closes as well as opens for start- and end-tags. Among other things, it requires that EMPTY or CONREFed elements use the STAGO and the ETAGC for their "start"-tag. For example, if STAGC were "/>" and ETAGC were ">", then "<x/>..<y>..</x> would be an x element with content that included an empty y element. Rather than slavishly trying to jam XML into the existing SGML syntax, which wasn't intended to cope with the things we are here trying to deal with, couldn't we design things like this in consultation with the SGML RG and have a sensible syntax for both XML and SGML/Revised? Then get busy and push/help the revision to get finalized. We'll get a much better XML and probably a better SGML as well. Dave Peterson SGMLWorks! davep@acm.org To: "David G. Durand" <dgd@cs.bu.edu> (David G. Durand), w3c-sgml-wg@w3.org From: Martin Bryan <mtbryan@sgml.u-net.com> Subject: Re: A note on case sensitivity Date: Thu, 31 Oct 1996 13:09:08 +0000 >Now the agonizing part: are !element !attlist, etc. upper or lower case? > There is already a convention that the lowercase version of the names be reserved for representing architectural forms rather than full element/attribute definitions. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Thu, 31 Oct 1996 09:08:41 -0500 From: gtn@ebt.com (Gavin Nicol) To: jenglish@crl.com CC: w3c-sgml-wg@w3.org Subject: Re: ERB meeting, 30 October 1996 >Another problem with the /> NET trick is that it's *still impossible >for a structure-controlled application to create a parseable >instance from ESIS*. This is one of the more serious problems >with ISO 8879 from a tool-writer's standpoint; this is an issue >that XML *must* address for it to satisfy design goal #9: >"XML documents shall be easy to create." While this *is* an important point, one could just as easily say that ESIS is poorly designed: it doesn;' preserve imformation regarding empty elements, or entity boundaries, for example. Not all systems need such information, but many do. Date: Thu, 31 Oct 1996 12:03:35 -0500 To: w3c-sgml-wg@w3.org From: "David G. Durand" <dgd@cs.bu.edu> (David G. Durand) Subject: Re: ERB meeting, 30 October 1996 At 9:08 AM 10/31/96, Gavin Nicol wrote: >>Another problem with the /> NET trick is that it's *still impossible >>for a structure-controlled application to create a parseable >>instance from ESIS*. This is one of the more serious problems >>with ISO 8879 from a tool-writer's standpoint; this is an issue >>that XML *must* address for it to satisfy design goal #9: >>"XML documents shall be easy to create." > >While this *is* an important point, one could just as easily say that >ESIS is poorly designed: it doesn;' preserve imformation regarding >empty elements, or entity boundaries, for example. Not all systems >need such information, but many do. I tend to agree. ESIS defines a minimum level of information required, but I don't see that we should enshrine its flaws, especially since it is non-normative. I am able, for instance, to get the EMPTY element information trivially from YASP, and I'm sure it can be done the same from SP. If XML requires emty element information, that will be an argument for an ESIS+ option to NSGMLS to easily support conversions to XML. Arguments of the form "this is in the ESIS, we need it" should hold a _lot_ of weight. Arguments of the form "We need this (or would like it a lot) but ESIS doesn't have it, so we'll have to live without" are not totally negligible, but ease of implementing such extensions (for a reasonable SGML parser) should be factored in. -- David RE delenda est. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Thu, 31 Oct 96 13:01:34 CST From: Michael Sperberg-McQueen <U35395@UICVM.UIC.EDU> Subject: ERB decision, 31 October 1996 To: W3C SGML Working Group <w3c-sgml-wg@w3.org> The ERB met today, 31 October 1996. Present: Bosak, Bray, Clark, Hollander, Kimber, Maler, Paoli, Sharpe, Sperberg-McQueen. Absent: DeRose, Magliery. We discussed the issue of external text entities and agreed unanimously to rescind the decision of 23 October on question A.17 making support for external text entities an optional feature of XML. Instead, the XML spec will distinguish the treatment required for external text entities in validating and non-validating systems, using language something like this: a reference to an external text entity is a signal to an XML processor that the entity's contents are to be included at the point of the reference. For purposes of *validation*, an XML processor must fetch and read the external text entity at the point of reference; for other purposes, processor behavior is not constrained. This is draft, not final, wording. If a network client chooses to fetch and process external entities at the point of reference, it may do so; if it chooses instead to insert a small icon instead, and fetch and display the entity only on request, or behave in some other way, it may do that too. This has the effect that, if they wish, browsers may from a technical point of view treat external text entities much the way they treat links to other documents or links to embedded graphics -- the user interface may well differ, but text entities do not require a browser to change its internal organization or way of working. Rationale: distinguishing validation behavior from other behavior allows us to reduce the number of optional features in XML to zero, while retaining (a) the information provider's ability to segment documents into several files and (b) the network client's ability to handle documents without required waits during network fetches. Since text entities in XML must be synchronous, adding an entity to the data structure requires only the replacement of a leaf with one or more subtrees; this allows entity fetching to be delayed if delay is useful to the application. As usual, the rationale just given is subject to correction. -C. M. Sperberg-McQueen Date: Thu, 31 Oct 96 15:17:04 CST From: Michael Sperberg-McQueen <U35395@UICVM.UIC.EDU> Subject: Re: ERB meeting, 30 October 1996 To: W3C SGML Working Group <w3c-sgml-wg@w3.org> On Wed, 30 Oct 1996 23:41:40 -0500 <DAVEP@acm.org> said: >I just read Lee's analysis of the fragility of the NET trickeries >proposed for XML (message resent as <199610310415.XAA24860@www19.w3.org>). More on that in another posting. >All this trickery does indeed get very fragile. There is a proposal >that will probably be considered at the combined ISO/ANSI meeting >the week before SGML '96 that proposes a neat solution ... > >Rather than slavishly trying to jam XML into the existing SGML syntax, >which wasn't intended to cope with the things we are here trying to >deal with, couldn't we design things like this in consultation with >the SGML RG and have a sensible syntax for both XML and SGML/Revised? >Then get busy and push/help the revision to get finalized. We'll >get a much better XML and probably a better SGML as well. To the extent possible, that is what the ERB is trying to do (i.e. that is why so many of the revision group are members of the SGML WG); there are unavoidable constraints, however, imposed by the fact that the ERB has a draft to deliver at SGML '96, and so we need to make decisions for XML 1.0 now, not later. The friendly informal exchange of views and of information about where WG8 members believe the revision is headed have been, and will be, very useful in the preparation of the XML spec; we hope that the XML spec will be similarly useful in the SGML revision. Concretely, with respect to the question of recognizing elements declared EMPTY without the DTD, there have been two main types of delimiter-tweaking proposals. First, the proposal discussed a few weeks back on comp.text.sgml, involving four delimiter roles: STAGO, ETAGO, STAGC, and ETAGC, with empty elements being marked by using STAGO, ETAGC. This would allow Dave's <x/>..<e>..</x> as well as Arjun Ray's <x{...<e>...}x> Second, there have been various proposals which involve marking the tag-open or tag-close delimiter of EMPTY elements specially, which would involve a different set of delimiter roles: the existing STAGO, ETAGO, and TAGC, supplemented by an tag-open delimiter for empty elements, a tag-close delimiter for empty elements, or both. Both the <e/> form adopted by the ERB yesterday, and the <@e> form suggested by Lee Quin, are compatible with the second, but not with the first, solution. The easiest way for the SGML revision to ensure compatibility with all the various proposals is for the revision to define six tag delimiter roles, for the open and close delimiters of the three different types of tags. If we call these start-tags, end-tags, and point-tags, we can name the roles STAGO ETAGO PTAGO STAGC ETAGC PTAGC Then ISO 8879-86 has STAGO = PTAGO = '<' ETAGO = '</' STAGC = ETAGC = PTAGC = '>' Dave Peterson's illustration has: STAGO = PTAGO = '<' ETAGO = '</' STAGC = '/>' ETAGC = PTAGC = '>' While Arjun Ray and Charles Goldfarb's illustration is the same except for using '{' '}' for '/>' '</'. Lee Quin's proposal has: STAGO = '<' PTAGO = '<@' ETAGO = '</' STAGC = ETAGC = PTAGC = '>' And XML, as currently defined, has STAGO = PTAGO = '<' ETAGO = '</' STAGC = ETAGC = '>' PTAGC = '/>' Conclusion: three delimiters is not enough; each modification so far proposed requires only four but not the same four; six delimiter roles suffice to express each modification so far proposed. With regard to the specific proposal Dave Peterson mentions: while much taken with the symmetry of the example given, the ERB is concerned about the implications of requiring every start-tag in existing SGML documents to be modified. (It's bad enough requiring all the EMPTY-element tags to be modified!) So while we are happy to contemplate the prospect of the SGML revision distinguishing six delimiter roles instead of the current three, the ERB is more likely to content itself with a proposal which is consistent both with a six-delimiter version of SGML and with the existing SGML '86. -C. M. Sperberg-McQueen From: lee@sq.com Date: Thu, 31 Oct 96 17:43:06 EST To: w3c-sgml-wg@w3.org Subject: Re: ERB meeting, 30 October 1996 Just a quick comment: > With regard to the specific proposal Dave Peterson mentions: while > much taken with the symmetry of the example given, the ERB is > concerned about the implications of requiring every start-tag in > existing SGML documents to be modified. (It's bad enough requiring > all the EMPTY-element tags to be modified!) Actually there is no difference. The omnimark or perl script is no harder or easier whether it works on empty elements or "full" ones. It's not the SGML software and SGML users we have to worry about, as long as there is a clear mapping. It's the non-SGML users, or the SMGL [sic] users, with their (our) Dirty Perl Scripts. It's slightly easier to match <@IMG ALT="</>"> in perl than to match <IMG A1="/>" A2='/>'/> but not much so, for what little that's worth. > So while we are happy > to contemplate the prospect of the SGML revision distinguishing six > delimiter roles instead of the current three, the ERB is more likely > to content itself with a proposal which is consistent both with a > six-delimiter version of SGML and with the existing SGML '86. Both <e/> and <@e> are compatible with both of these, as you mentioned. Lee Date: Thu, 31 Oct 1996 18:23:40 -0500 From: gtn@ebt.com (Gavin Nicol) To: U35395@UICVM.UIC.EDU CC: w3c-sgml-wg@w3.org Subject: Re: ERB decision, 31 October 1996 >We discussed the issue of external text entities and agreed >unanimously to rescind the decision of 23 October on question A.17 >making support for external text entities an optional feature of XML. I would rather see then out than optional. The notion that you *cannot* validate in a lazy-parsing model is incorrect. It is a different model, yes, but not impossible (you'd have to delay validation of certain nodes until a certain portion of an entity had been resolved). I basically assume that any data that is being transmitted will have already been validated... Date: Thu, 31 Oct 1996 17:12:52 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray <tbray@textuality.com> Subject: Re: ERB decision, 31 October 1996 At 06:23 PM 10/31/96 -0500, Gavin Nicol wrote: >>We discussed the issue of external text entities and agreed >>unanimously to rescind the decision of 23 October on question A.17 >>making support for external text entities an optional feature of XML. > >The notion that you *cannot* validate in a lazy-parsing model is >incorrect. It is a different model, yes, but not impossible (you'd >have to delay validation of certain nodes until a certain portion of >an entity had been resolved) Right. And we didn't rule that out. We just said that you don't *have to* read external text entities unless you're validating. Which, as you suggest, a downstream browser likely isn't. As for nuking external text entities altogether, we thought that over seriously; there are just too many people who see them as a sine qua non of a worthwhile authoring system. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Thu, 31 Oct 1996 22:06:10 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray <tbray@textuality.com> Subject: Re: ERB decision, 31 October 1996 At 02:05 AM 11/1/96 GMT, Charles F. Goldfarb wrote: >>Right. And we didn't rule that out. We just said that you don't *have to* >>read external text entities unless you're validating. > >But in SGML they are always accessed and parsed, and the resulting ESIS is >always the same. (Yes, I know that 8879 doesn't mention ESIS by name, but the >SGML conformance testing standard certainly does.) Right. The reason we can get away with this is that we are not claiming that an XML processor is always an SGML parser. When it's *validating* we want the behavior to be effectively identical to that of an XML parser, and the spec needs to lock that in. The behavior described (not having to read an external text entity) only applies when the XML processor is *not trying to validate*. Which is not an 8879-compliant operation in the first place. The consensus apparently seemed to be that while XML *can* parse in the 8879 sense, a Web browser need not and typically does not - and yet we'd still like to call it "XML-compliant". Hence this policy. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Wed, 30 Oct 96 17:03:58 CST From: Michael Sperberg-McQueen <U35395@UICVM.UIC.EDU> Subject: Re: ERB meeting, 30 October 1996 To: W3C SGML Working Group <w3c-sgml-wg@w3.org> On Wed, 30 Oct 1996 14:59:04 -0500 I said: > ... >Agreed unanimously: > ... > - to use the string '/>' as the NET delimiter in the SGML > declaration of XML documents But I forgot to add the important constraint that in XML the delimiter '/>' is explicitly a tag-close delimiter for empty elements, and may not be used to end start-tags for non-empty elements, or as a null end-tag (NET), as described in 8879, clauses 7.4.1.3 and 7.5.1.3. This constraint is essential in order to ensure that empty elements, and *only* empty elements, have tags of the form <e/>. The identification of '/>' with the NET delimiter is exclusively a technique to allow Full-SGML systems to read XML documents. XML does not use any form of minimized start- or end-tags (ERB decision on question A.4, announced by Tim Bray on 9 October) and thus has, in effect, no NET delimiter. Current Full-SGML systems will not typically have an option to allow the user to request that elements declared EMPTY and elements with a CONREF attribute for which a value is specified, and only such elements, be written out using the form <e/>. We may hope that this will change. In the meantime, the form <e> is legal, as long as the empty elements are declared as such. -CMSMcQ