Date: Fri, 1 Nov 1996 02:05:57 -0500 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@w3.org Subject: Re: ERB decision, 31 October 1996 >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. Just to clarify the point: the only reason I can see for the distinction between validating and non-validating parsers is that validating parsers must resolve all entities *before* they can claim a document to be valid, (one of the goals of parsing) whereas in non-validating systems, the chief goals can be met without necessarily resolving all entities. In neither case is there a limitation of resolving entities before parsing can proceed beyond the entity reference, nor is there a restriction on pre-fetching entities. From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Tim Bray Cc: w3c-sgml-wg@w3.org Subject: Re: ERB decision, 31 October 1996 Date: Fri, 01 Nov 1996 02:05:33 GMT On Thu, 31 Oct 1996 17:12:52 -0800, Tim Bray 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. 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. 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.) Lazy parsing needn't be inconsistent with 8879 conformance, as early postings have demonstrated, as long as the external text entity doesn't change the state of the parse. (I still question whether XML can enforce this constraint.) The real problem is with entities whose text changes each time they are accessed, thereby yielding a different ESIS on each parse. Valid XML should require that external text entities be constants. Generated files should be accessed through attributes, where there is a chance to identify the governing semantics of the reference. -- 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, 01 Nov 1996 10:42:11 -0500 To: DAVEP@acm.org, W3C-SGML-WG@w3.org From: "Steven J. DeRose" Subject: Re: ERB meeting, 30 October 1996 >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 ".... would be an >x element with content that included an empty y element. A good beginning (as WG8 members know, I have often requested that the overloaded delimiter roles be divided). So I would strongly support a revision along that line. However, if you only make empties use STAGO+ETAGC you can't distinguish ETAGC from empty-tag-C, which is essential. EMPTY should have its *own* delimiters, or you pointlessly rule out perfectly fine syntaxes, including the one we just approved! That is, the delimiters should be broken down to something like this, which imposes no backward-compatibility limitation, but opens the road forward completely rather than partially: STAGO STAGC for start-tags ETAGO ETAGC for end-tags MTAGO MTAGC for EMPTY/conref/etc. Likewise, the "I can't use curly quotes" problem should become a non-issue: LITO LITC LITAO LITAC And COMO COMC The language-bias issues from punning on "+" meaning "repetition" and "+" means "addition", etc. imply the need for PLUS to be divided into INCLUSION vs REQ; and MINUS to EXCLUSION vs. CAN-OMIT-TAG; and so on. Basically, any time a delimiter appears in more than one 8879 production, there's a limitation on the range of definable syntaxes, and thus a potential problem requiring review. S Date: Fri, 01 Nov 1996 10:42:09 -0500 To: W3C SGML Working Group From: "Steven J. DeRose" Subject: Re: ERB meeting, 30 October 1996 At 06:49 PM 10/30/96 -0800, Joe English wrote: >The /> NET trick is extremely fragile. Most current >SGML parsers cannot even implement it, and those that do >cannot enforce its proper usage. Huh? Define "fragile" please. This usage of NET is precisely in accordance with the definition of NET in 8879, and is therefore only fragile to the extent that ISO 8879 itself is fragile. It is seems obviously not true that "Most current >SGML parsers cannot even implement it" -- any parser supporting SHORTTAG and delimiter changes in accordance with the standard already *has* implemented it. Even a parser that fails to support the delimiter change, though it should be fixed, will at worst be off only slightly: it will recognize the slash NET and then leave an extra ">" as content: at least it didn't trash the tree, say by leaving the element open for ages. What do you mean by "cannot enforce its proper usage"? This could only be applicable to something that must write out XML; but we covered that by allowing the form, which I think is what any conforming SGML system will write out for empty elements. >...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.* True, but if the user forgets the SGML declaration for *any* SGML document that changes it from the RCS in the slightest way, it will fail (reportably or not, but it will fail). I hope we're not thinking of ruling out all other changes from RCS (like, say, limiting GIs to length 8!) to protect users who forget the SGML declaration.... >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." If this is a serious problem with *8879*, there is not much we can do to fix it in XML; or am I missing something? Date: Fri, 1 Nov 1996 11:19:08 -0500 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: ERB decision, 31 October 1996 At 9:05 PM 10/31/96, Charles F. Goldfarb wrote: >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.) Yes, but we are not proposing that XML be SGML conformant, just that an SGML-comformant processor be able to parse XML. >Lazy parsing needn't be inconsistent with 8879 conformance, as early postings >have demonstrated, as long as the external text entity doesn't change the state >of the parse. (I still question whether XML can enforce this constraint.) Well, given the work that Steve DeRose and others in SGML OPEN expended on finding all the state-dependencies in the SGML grammar, I believe him when he says we _already have_ guaranteed that. Or do you have a context dependency in mind tath we have not already eliminated. >The real problem is with entities whose text changes each time they are >accessed, thereby yielding a different ESIS on each parse. Valid XML should >require that external text entities be constants. Generated files should be >accessed through attributes, where there is a chance to identify the governing >semantics of the reference. I'm afraid the only thing I can say is that this would be a stupid restriction: it is not enforceable by any processor, _and_ it would make impossible many useful applications of XML on the Web, that will necessarily involve databases and synamic document generation. It is the responsibility of a dynamic document implementor to produce valid XML, if they want to validate it. What is the point of trying to make a rule that is easy to violate, blocks useful applications of XML, and cannot be enforced by software? -- 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: Fri, 01 Nov 1996 14:15:16 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: XML Draft Specification V0.01 of 1st November The first semi-public release of our draft spec is now available for your review and comment. Do pay close attention to the various disclaimers and notices near the top of the document. If you see something that seems really wrong, it may just be a section that's been drafted in advance of decisions having been taken. Intelligent review is needed at three different levels: 1. The general structure and design of the spec 2. The content of the spec: the XML it defines 3. The style of the spec - spelling, punctuation, grammar, readability. Comments may be directed either to the whole working group or directly to the editors - to me it seems that comments in categories #1 and #2 are more appropriately sent to the WG (particularly if they might launch a useful discussion) - comments in category #3 might as well go straight to Michael and myself, a lot of WG-folk probably have bruised mailboxes already. Officially, speaking, the spec is a W3C Working Draft, and thus its canonical address is: http://www.w3.org/pub/WWW/TR/WD-xml-961101.html However, this may have a fairly lengthy update cycle. The *working* version, which we will try to update in near-real-time as we lead up to a paper version to be released at SGML'96, is at: http://www.textuality.com/sgml-erb/WD-xml.html There is an SGML version of course, but the markup is pretty dense and we don't have a decent stylesheet yet, and the HTML output captures the intent and argument quite well. If someone really wants to work with the SGML source, and it's OK with Jon Bosak, we could make that available. Actually, if someone out there wanted to volunteer to *create* a nice stylesheet, that would be wonderful. You really need release 3 of either Navigator or Internet Explorer in order to see this properly - there is quite heavy use of tables and font switching. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Sat, 02 Nov 1996 00:28:00 -0500 To: w3c-sgml-wg@w3.org From: Harvey Bingham Subject: Thanks to XML contributors Our XML experience has been great. I've enjoyed the prompt and detailed discussions that provided guidance for the Editorial Review Board decisions. I've noted significant disagreements argued without flames. This process is so refreshingly paced that issues raised become issues resolved while still fresh in mind. Much better than the months and years spent evolving some other standards and SGML applications without email. I believe you may be interested in this summary of who have been the players. Contributors to www-sgml-wg@w3.org through 1 Nov 1996 Identifications come primarily from the Working Group and Editorial Review Board lists appended to the Extensible Markup Language (XML) W3C Working Draft 1-Nov-96 http:.//www.w3.org/pub/WWW/TR/WD-xml-9061101.html LEGEND Msgs messages from that email address, "." is none Echos lines from prior messages giving context for response Lines non-header lines that aren't echos Code e editorial review board w working group - other contributor not listed in appendix Name from the lists, or extracted from actual submission Org organization, some guessed. Role erb role if any Email distinct email addresses, some names have several Basis for count is my unofficial record of received messages I may have discarded a few that were non-technical Msgs Echos Lines Code Name, Org, Role . . . w Sharon Adler, EBT 1 1 44 - Terry Allen, O'Reilly 1 8 31 w Paula Angerstein, Texcel 6 85 153 w Todd Bauman, U. of Maryland 2 31 51 w Anders Berglund, EBT . . . w Karl Best, Novell . . . w Michel Biezunski, High Text 7 192 109 w Harvey Bingham, SGML consultant 82 416 1609 e Tim Bray, Textuality, editor . . . w Steve Brown, InfoObjects 75 1 1606 e Jon Bosak, Sun, chair 56 529 967 w Martin Bryan, SGML Centre . . . w Mark Buckley, Microsoft 64 932 1236 w Len Bullard, Lockheed-Martin 4 6 50 w Lou Burnard, Oxford University . . . w Steve Byrne, JavaSoft 48 540 666 e James Clark, SGML Consultant, technical lead . . . e Dan Connolly, W3C, W3C contact . . . w Kurt Conrad, Sagebrush Group . . . w Paul Cope, auto-graphics . . . w Keith Corbett, Harlequin 2 0 127 w Robin Cover, Academic 4 35 120 w Derek Denny-Brown, TechnoTeacher 24 224 560 e Steve DeRose, EBT 1 0 16 - Bob Du Charme, Research Inst of America 95 1424 2604 w Dave Durand, Boston University . . . w Carol Ellerbeck, INSO 24 267 573 w Joe English, CR Laboratories 1 3 17 w Ralph Ferris, Fujitsu . . . w Lee Fogal, Digital Equipment . . . w Todd Freter, Novell 2 46 57 w Matthew Fuchs, Disney Imagineering 141 1758 2606 w Charles Goldfarb, Editor ISO 8879 28 506 608 w Paul Grosso, ArborText 2 24 66 w Eduardo Gutentag, SunSoft 2 22 30 w Hasse Haitto, Synex . . . w Catherine Hamon, Hightext 1 13 14 e Dave Hollander, HP 2 43 70 w Ken Holman, Microstar 18 76 423 w Rick Jelliffe, Allette Systems . . . w Alan Karben, Wall Street Journal . . . w Pär Karlsson, Ericsson 27 355 911 e Eliot Kimber, Passage Systems 11 18 428 w Bill Lindsey, BDM . . . w Per Åke Ling, Ericsson 7 22 57 w Debbie Lapeyre, Mulberry Technologies 5 0 183 - John Lavagnino, Brown University 1 7 39 - Richard Light, Light . . . w Megan MacMillan, BDM Technologies 10 79 300 w Christopher Maden, EBT 1 13 24 e Tom Magliery, NCSA 18 530 293 e Eve Maler, ArborText 3 154 146 - Murray Maloney, SoftQuad 5 40 111 w James Mason, ORNL 1 19 15 w John McFaddan, Omnimark . . . w Alex Milowski, Copernican Solutions 8 225 260 w Alex Milowski, Copernican Solutions 5 43 187 w Steve Newcomb, TechnoTeacher 129 1175 1353 w Gavin Nicol, EBT . . . w Nancy Paisner, Open Environment Corp . . . w Gary Palmer, ActiveSystems . . . e Jean Paoli, Microsoft 2 27 30 w Dave Peterson, SGML Works 76 767 1526 w Paul Prescod, U. of Waterloo . . . w Lynne Price, SGML consultant 90 626 3140 - Liam Quin, SoftQuad 14 137 348 w Arjun Ray, Q2-II 2 16 67 e Peter Sharpe, SoftQuad 32 247 528 w Bill Smith, SunSoft 2 29 36 w Bill Smith, SunSoft 110 358 3130 e C. M. Sperberg-McQueen, U IL Chicago, editor 24 139 1028 e C. M. Sperberg-McQueen, U IL Chicago, editor . . . w Bob Stayton, SCO 9 109 118 w Robert Streich, Schlumberger 45 394 772 w Robert Streich, Schlumberger . . . w Jeff Suttor, SunSoft . . . w James Tauber, U. of Western Australia . . . w Wayne Taylor, Novell 14 84 177 w Henry Thompson, University of Edinburgh . . . w Sam Wilmott, OmniMark . . . w Chris Wilson, Microsoft . . . w Wayne Wohler, IBM 3 9 85 w Lauren Wood, SoftQuad TOTALS Msgs Echos Lines Heads Emails 1347 12804 29705 31625 53 Heads are message header lines Emails are distinct sending email addresses Regards/Harvey Date: Fri, 1 Nov 1996 23:07:33 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: hbingham@acm.org CC: w3c-sgml-wg@w3.org Subject: Re: Thanks to XML contributors | Our XML experience has been great. I've enjoyed the prompt and | detailed discussions that provided guidance for the Editorial | Review Board decisions. I've noted significant disagreements | argued without flames. This process is so refreshingly paced that | issues raised become issues resolved while still fresh in mind. | Much better than the months and years spent evolving some other | standards and SGML applications without email. Thanks, Harvey. Lest anyone get the wrong idea, however, I must observe that we are nowhere near done yet. We need everyone's help in reviewing the draft spec between now and the language freeze on November 13, and after SGML 96 we will need everyone's participation in Phase II of this effort, which will specify hypertext mechanisms for XML. | I believe you | may be interested in this summary of who have been the players. | | Contributors to www-sgml-wg@w3.org through 1 Nov 1996 | | Identifications come primarily from the Working Group and | Editorial Review Board lists appended to the | Extensible Markup Language (XML) W3C Working Draft 1-Nov-96 | http:.//www.w3.org/pub/WWW/TR/WD-xml-9061101.html The list of WG members in the current draft is not complete, and I think that you may be picking up some messages that were not actually directed to the WG. For reference purposes (given that the W3C archive for this group is nearly unusable), I have extracted all WG traffic for the last two months from my own mail archives and put it into the following files: ftp://sunsite.unc.edu/pub/sun-info/standards/xml/wg/9609a.zip ftp://sunsite.unc.edu/pub/sun-info/standards/xml/wg/9609b.zip ftp://sunsite.unc.edu/pub/sun-info/standards/xml/wg/9610a.zip ftp://sunsite.unc.edu/pub/sun-info/standards/xml/wg/9610b.zip There are also gzipped versions of the same files. I cannot guarantee that I received everything sent to the list, but these files contain everything that I did receive. The W3C archive for this group is publicly visible, so you are free share these with anyone who might be interested in our discussions. Jon Date: Sat, 02 Nov 1996 13:41:13 -0500 To: w3c-sgml-wg@w3.org From: "Eve L. Maler" Subject: OMITTAG specifications in element declarations Cc: elm@arbortext.com In XML, we've tossed out OMITTAG. However, there's a question about whether we allow the "omitted tag minimization" parameter in XML element declarations. I feel we should, so that existing DTDs that provide these specifications don't need to be maintained in two separate versions, one for SGML and one for XML. I see no harm in allowing them. In private conversation, Tim has said that we shouldn't, because it requires more cruft in the XML spec. Opinions? Eve Date: Sat, 2 Nov 1996 14:05:27 -0500 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: OMITTAG specifications in element declarations At 1:41 PM 11/2/96, Eve L. Maler wrote: >In XML, we've tossed out OMITTAG. However, there's a question about >whether we allow the "omitted tag minimization" parameter in XML >element declarations. >...deleted... > I see no harm in allowing them. In private conversation, >Tim has said that we shouldn't, because it requires more cruft in the >XML spec. >Opinions? > Eve I think the answer is pretty clear. Ask yourself the question of how we will explain the need to put two hyphens in each element definition to an XML user who doesn't care about SGML, but only wants the advantages of XML (descriptive markup, document grammars, real containment). There's not a plausible explanation. Worse, the explanation points to the removal of a feature that seems like a better idea than it really is, making the naive user feel deprived (as well as bossed around). They typical XML user will only be an SGML user if we fail in our mission in defining XML. Let's design on the assumption that we will succeed and lots of people will use XML, who may or may not ever use SGML. -- 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: Sat, 02 Nov 1996 12:58:41 -0900 To: "Eve L. Maler" , w3c-sgml-wg@w3.org From: "W. Eliot Kimber" Subject: Re: OMITTAG specifications in element declarations Cc: elm@arbortext.com At 01:41 PM 11/2/96 -0500, Eve L. Maler wrote: >In XML, we've tossed out OMITTAG. However, there's a question about >whether we allow the "omitted tag minimization" parameter in XML >element declarations. > >I feel we should, so that existing DTDs that provide these specifications >don't need to be maintained in two separate versions, one for SGML and >one for XML. I see no harm in allowing them. In private conversation, >Tim has said that we shouldn't, because it requires more cruft in the >XML spec. I hadn't thought about it before, but it seems easier to add a little more to the element declaration production (and corresponding pattern matching regexps) than to require changing 99% of existing declarations to work with XML. It's only two additional two-character optional OR groups: ([O\-], S*, [0\-])? Cheers, E. -- W. Eliot Kimber (drmacro@drmacro.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" From: lee@sq.com Date: Sat, 2 Nov 96 14:50:26 EST To: elm@arbortext.com, w3c-sgml-wg@w3.org Subject: Re: OMITTAG specifications in element declarations Eve asked about the "- -" ommitted tag minimization parameter, and adding it in to XML. It is a red herring to say that putting them in XML would help compatibility: if you have OMITTAG YES in your DTD, you need to run SPAM or otherwise ensure that there are no omitted tags. XML applictions won't handle your text otherwise, so it doesn't matter if they wil handle the DTD or not. It would be like adding SHORTREF parsing to XML so that you can parse DTDs with SHORTREF -- if you're using SHORTREF, changing the DTD is the least of the work you have to do, and is a necessary step in any case. So no strange and spurious tokens in XML. They are not needed for SGML conformance, they do not add to the expressive power of the language, they add slightly to language complexity, and not having them will actually _help_ interoperability with SGML. Lee Date: Sat, 02 Nov 1996 17:20:29 -0500 To: lee@sq.com, elm@arbortext.com, w3c-sgml-wg@w3.org From: "Eve L. Maler" Subject: Re: OMITTAG specifications in element declarations At 02:50 PM 11/2/96 EST, lee@sq.com wrote: >Eve asked about the "- -" ommitted tag minimization parameter, and >adding it in to XML. > >It is a red herring to say that putting them in XML would help >compatibility: if you have OMITTAG YES in your DTD, you need to >run SPAM or otherwise ensure that there are no omitted tags. >XML applictions won't handle your text otherwise, so it doesn't >matter if they wil handle the DTD or not. > >It would be like adding SHORTREF parsing to XML so that you can parse >DTDs with SHORTREF -- if you're using SHORTREF, changing the DTD is >the least of the work you have to do, and is a necessary step in >any case. > >So no strange and spurious tokens in XML. They are not needed for >SGML conformance, they do not add to the expressive power of the >language, they add slightly to language complexity, and not having them >will actually _help_ interoperability with SGML. > >Lee I realize it's a bit strange to allow no-op characters, but new XML DTDs simply won't use them. The problem is not so much explaining these tokens to new XML users; it's making existing DTDs usable in XML. I'm not saying new XML DTDs should *require* this field, just allow it. The difference between OMITTAG and SHORTREF is that pretty much *every* DTD today includes the OMITTAG field, even if just "- -", partly because the SGML declaration (where OMITTAG is set to YES or NO) is a component of SGML documents as a whole, and DTDs technically don't automatically "come with" their own SGML declaration. For me, this definitely comes under the heading of deciding whether or not to punish existing SGML users. Eve Date: Sat, 02 Nov 1996 17:10:24 -0600 (CDT) From: DAVEP@acm.org Subject: Re: OMITTAG specifications in element declarations To: elm@arbortext.com Cc: W3C-SGML-WG@w3.org (Eve L. Maler) recently wrote: >In XML, we've tossed out OMITTAG. However, there's a question about >whether we allow the "omitted tag minimization" parameter in XML >element declarations. > >I feel we should, so that existing DTDs that provide these specifications >don't need to be maintained in two separate versions, one for SGML and >one for XML. I see no harm in allowing them. In private conversation, >Tim has said that we shouldn't, because it requires more cruft in the >XML spec. I agree--no harm in allowing them. However, note that 8879 _permits_ (but doesn't _require_) that that parameter be omitted if the SGML declaration doesn't permit OMITTAG. So, with care one could use the stripped DTD for XML and SGML under some scenarios. Although I can certainly imagine where one might require an OMITTAG DTD as well, and in that case it would be convenient to be able to have the omitted tag minimization parameter present and ignored. Dave Peterson SGMLWorks! davep@acm.org To: w3c-sgml-wg@w3.org Subject: Re: OMITTAG specifications in element declarations Date: Sat, 02 Nov 1996 15:36:41 -0800 From: Joe English "Eve L. Maler" wrote: > In XML, we've tossed out OMITTAG. However, there's a question about > whether we allow the "omitted tag minimization" parameter in XML > element declarations. > > I feel we should, so that existing DTDs that provide these specifications > don't need to be maintained in two separate versions, one for SGML and > one for XML. [...] Given that the current XML draft doesn't support parameter entities, name groups for ELEMENT and ATTLIST declarations, AND groups, content models denoting mixed content where #PCDATA appears anywhere other than as the _first_ token in a repeatable OR group, inclusion and exclusion exceptions, and probably a few others, it looks like XML-SGML compatibility will be pretty much limited to document instances in any case. Since most SGML users will have to rewrite their DTDs to make them XML-able anyway, leaving out the omitted tag minimization parameter doesn't seem like that big a deal... --Joe English jenglish@crl.com Date: Sat, 02 Nov 1996 17:51:13 -0600 (CDT) From: DAVEP@acm.org Subject: Re: OMITTAG specifications in element declarations To: lee@sq.com Cc: W3C-SGML-WG@w3.org recently wrote: >It is a red herring to say that putting [omitted tag specs] in XML would help >compatibility: if you have OMITTAG YES in your DTD, you need to >run SPAM or otherwise ensure that there are no omitted tags. You're raising the red herring, Lee. If the SGML declaration says OMITTAG NO, then you can't omit tags. "OMITTAG YES" is not what's under discussion; that's a closed issue--not permitted for XML. As Eve has pointed out; "OMITTAG" goes in the SGML declaration, not in the DTD. What does go in the DTD (in element type declarations therein) is the "omitted tag specification" parameter: a pair of MINUS and/or "O" specifiers, which _when OMITTAG YES is specified_ govern whether an apparently omitted tag detected by the standard algorithm is to be regarded as an error or not. >XML applictions won't handle your text otherwise, so it doesn't >matter if they wil handle the DTD or not. Nonsense. in SGML tags _never_ must be omitted just because they are _permitted_ to be omitted. No one is suggesting that XML documents might have omitted tags. The "OMITTAG NO" in the _SGML_ declaration will enforce that. >So no strange and spurious tokens in XML. They are not needed for >SGML conformance, they do not add to the expressive power of the >language, they add slightly to language complexity, and not having them >will actually _help_ interoperability with SGML. Consider the following scenario: You deal with a lot of documents that at some point in their lives use omittag in their processing, so you need a DTD that can be used with "OMITTAG YES". At some point in the processing, you normalize the documents. Thereafter, the documents can be processed with "OMITTAG YES" or "OMITTAG NO". SGML does not require that you maintain two versions of your DTD, one for processing with "OMITTAG YES" and the other for processing with "OMITTAG NO"--it simply says that if you process with "OMITTAG NO", the omitted tag specification parameters will be ignored. You are saying that under these circumstances it's better to have to maintain two versions of your DTD. I say, nonsense! If XML uses the same interpretation of the omitted tag specification parameter that SGML does, then your XML-only users will never need to put that parameter in their declarations. And your SGML "OMITTAG YES" users will only need one DTD. And all your apparently easily confused XML-only users need be told is that if they see those hyphens and letter Os after the element type name in a DTD that comes from a fancy-SGML shop, its because SGML has some tricks they're using but your SGML-only users aren't, and they can ignore that part of the declaration. I don't think the XML-only users are so easily confused that they can't handle that. C'mon. Dave Peterson SGMLWorks! davep@acm.org Date: Sat, 02 Nov 1996 18:06:42 -0600 (CDT) From: DAVEP@acm.org Subject: Re: OMITTAG specifications in element declarations To: jenglish@crl.com Cc: W3C-SGML-WG@w3.org (Joe English) recently wrote: >Since most SGML users will have to rewrite their DTDs >to make them XML-able anyway, leaving out the omitted >tag minimization parameter doesn't seem like that big >a deal... But rewriting them so that the content models obey the restrictions is a one-shot thing, and then you can continue to deal with those documents using the new DTD with its new content models in both SGML and XML systems. The point of Eve's proposal is to avoid having to continue to maintain both versions. That to me _does_ "seem like that big a deal...". Dave Peterson SGMLWorks! davep@acm.org To: w3c-sgml-wg@w3.org Subject: Re: OMITTAG specifications in element declarations Date: Sat, 02 Nov 1996 17:39:08 -0800 From: Joe English DAVEP@acm.org wrote: > (Joe English) recently wrote: > >Since most SGML users will have to rewrite their DTDs > >to make them XML-able anyway, leaving out the omitted > >tag minimization parameter doesn't seem like that big > >a deal... > > But rewriting them so that the content models obey the > restrictions is a one-shot thing, Don't forget: you also have to expand all the parameter entity references, replace things like: with and change things like: into: Heaven help you if you're using something like TEI, DocBook, or IBM ID Doc... > and then you can > continue to deal with those documents using the new > DTD with its new content models in both SGML and XML > systems. I for one do not relish the thought of maintaining even a moderately large DTD after expanding all the parameter entities... > The point of Eve's proposal is to avoid having to > continue to maintain both versions. That to me > _does_ "seem like that big a deal...". Point taken, but I think it will take more than just allowing "- -" in the XML grammar to make this feasible. I could live without AND groups, but parameter entities and the ability to specify more than one associated element type in and declarations are essential. --Joe English jenglish@crl.com Date: Sat, 02 Nov 1996 20:49:59 -0500 To: Joe English , w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: OMITTAG specifications in element declarations At 05:39 PM 11/2/96 -0800, Joe English wrote: >Don't forget: you also have to expand all the parameter >entity references, ... >Heaven help you if you're using something like >TEI, DocBook, or IBM ID Doc... >> The point of Eve's proposal is to avoid having to >> continue to maintain both versions. That to me >> _does_ "seem like that big a deal...". > >Point taken, but I think it will take more than just >allowing "- -" in the XML grammar to make this feasible. >I could live without AND groups, but parameter entities and >the ability to specify more than one associated element >type in and declarations are >essential. Often I find that even the DTD syntax is not powerful enough to express the particular semantics and element-context linkages I want to express elegantly (e.g. OOP-style "inheritance"). The solution may be to code in something entirely unlike DTDs (for instance one of the instance syntax languages we have discussed) and down-translate. Eve's suggestion would seem to allow ONE down-translation instead of two. Paul Prescod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html Date: Sat, 2 Nov 1996 18:51:31 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Addition to the list Added to the WG: Martin Pike, Stilo mp@stilo.demon.co.uk Jon From: lee@sq.com Date: Sat, 2 Nov 96 23:22:26 EST To: elm@arbortext.com, lee@sq.com, w3c-sgml-wg@w3.org Subject: Re: OMITTAG specifications in element declarations > The difference between OMITTAG and SHORTREF is that pretty much *every* > DTD today includes the OMITTAG field, I would dispute that. Certainly we (at SQ) discourage its use. One reason is that many SGML tools give clearer error messages without it. Another is that it's pointless if you're using SGML-aware software, and that's the business we (SQ) are in. Perhaps most ArborText customers prefer to key their text in using vi or notepad?? :-) :-) > even if just "- -", partly because > the SGML declaration (where OMITTAG is set to YES or NO) is a component of > SGML documents as a whole, and DTDs technically don't automatically > "come with" their own SGML declaration. I'm not sure what this means. Every SGML document has an SGML declaration, and you always have to supply it, so yes, DTDs darned well ought to come with their own SGML declaration if they need one. It's true that I sometimes find people starting with the CALS declaration and editing it, and I usually suggest that they stop doing that and start with the standard one. You can get Author/Editor to save one for you by checking "include SGML declaration" when you save your SGML. > For me, this definitely comes under the heading of deciding whether or > not to punish existing SGML users. I don't think it is any worse in that regard than not supporting parameter entities, or than having NAMECASE NO. Having no OMITTAG support in XML means that you'll have to change all those documents anyway, and what better way to check that than with an SGML declaration with OMITTAG set to NO? And what better way to make sure you've done that than with a DTD without the tag omissibility thingies? If most existing SGML DTDs work unchanged in XML, it seems to me that we probably haven't simplified SGML enough to make any difference. If most existing implementations use only the features of SGML that we deem essential for XML, it's not clear to me that giving a name to that set of features will actually encourage many more people to write software than have already done so. So I think we have to be brutal. But it is good that you've pointed this out. Lee From: lee@sq.com Date: Sat, 2 Nov 96 23:52:44 EST To: DAVEP@acm.org, lee@sq.com Subject: Re: OMITTAG specifications in element declarations Cc: W3C-SGML-WG@w3.org Dave Peterson (after misunderstanding my posting) raises the situation where you process documents to remove omitted tags and then continue to use the same DTD but with OMITTAG set to NO. He then says that he wants to use the same DTD with XML, and therefore XML should ignore the omittag minimization parameters. This argument only works if XML can also ignore all the other SGML features you might be using -- USEMAP, CONREF, CONCUR, LINK, marked sections, & in model groups, inclusions and exclusions, mixed content models with ",", and all the other things not permitted in XML. So I don't buy it. Lee > recently wrote: >> It is a red herring to say that putting [omitted tag specs] in XML would >> help compatibility: if you have OMITTAG YES in your DTD, you need to run >> SPAM or otherwise ensure that there are no omitted tags. > > You're raising the red herring, Lee. If the SGML declaration says OMITTAG > NO, then you can't omit tags. I am perfectly well aware of that! > "OMITTAG YES" is not what's under discussion; > that's a closed issue--not permitted for XML. You misunderstand me completely. I am aware of that too. I am talking about the case where you have been using an SGML declaration that has OMITTAG YES, and the ommitted minimization parameters in the DTD (no, I don't need a lecture about where they go) and therefore you may have documents that omit tags. You might not. In migrating to XML, you must remove all traces of OMITTAG from your documents. You might as well also remove all traces of OMITTAG from your DTD, at the same time as you flatten parameter entites from your content models, remove & from model groups, remove inclusions and exclusions, flatten external entities, and remove marked sections. Then edit your instances to make them conform to the new simpler DTD, removing all SDATA entities and replacing them Unicode character references, as well as inserting all omitted tags, removing all instances of NET tags, null tags, and other minimisation. Probably there will be programs to do this. Maybe an SP application? Maybe the same program will transform your DTD. It's not worth thinking about people with complex DTDs (TEI, DOCBOOK, IBMIDDOC, DECBOOK, CALS, ATA, AAP/ISO12083) using exactly the same unedited DTD with XML. It can't happen. In any case, the goal of XML is surely not to take existing SGML users away from SGML and towards XML, but to win hordes of new people to the burgeoning SGML camp, via a more gentle path than the mountain pass that you, Eve, I and others have traversed. Well, you and Charles were in the party that cut the steps. [explanation of "omitted tag specification parameter" deleted] >> XML applictions won't handle your text otherwise, so it doesn't >> matter if they will handle the DTD or not. > > Nonsense. in SGML tags _never_ must be omitted just because they are > _permitted_ to be omitted. No one is suggesting that XML documents > might have omitted tags. Including me. It isn't nonsense, actually. If you have existing SGML documents with omitted tags, they won't work with XML parsers. And if you have OMITTAG YES in yout SGML declaration, you can't easily tell whether you have such elements or not, in general, unless you've been using InContext, Author/Editor, Adept, or some other software that will put all the tagsin for you. But in that case, there's no need to use OMITTAG in the first place, and hence you don't need to have the ommitted tag minimization parameters in the DTD. > Consider the following scenario: You deal with a lot of documents > that at some point in their lives use omittag in their processing, > so you need a DTD that can be used with "OMITTAG YES". At some point > in the processing, you normalize the documents. Thereafter, the > documents can be processed with "OMITTAG YES" or "OMITTAG NO". [...] > You are saying that under these circumstances it's better to have > to maintain two versions of your DTD. I say, nonsense! That is a good point. However, if you then convert your documents to XML, you will need a new DTD for the XML documents, as described above. Use software to produce the DTD, not hacks. You might as well say that XML parsers should understand parmeter entity definitions and & in content models, but ignore them. So I still think there is no good reason to litter XML DTDs with - and O tokens. Lee Date: Sun, 03 Nov 1996 01:05:01 -0500 To: W3C-SGML-WG@w3.org From: Arjun Ray Subject: Re: OMITTAG specifications in element declarations At 11:52 PM 11/2/96 EST, lee@sq.com wrote: >> Consider the following scenario: You deal with a lot of documents >> that at some point in their lives use omittag in their processing, >> so you need a DTD that can be used with "OMITTAG YES". At some point >> in the processing, you normalize the documents. Thereafter, the >> documents can be processed with "OMITTAG YES" or "OMITTAG NO". >[...] >> You are saying that under these circumstances it's better to have >> to maintain two versions of your DTD. I say, nonsense! > >That is a good point. > >However, if you then convert your documents to XML, you will need a >new DTD for the XML documents, as described above. >Use software to produce the DTD, not hacks. >You might as well say that XML parsers should understand >parmeter entity definitions and & in content models, but ignore them. > >So I still think there is no good reason to litter XML DTDs with >- and O tokens. I agree. It might be worthwhile to point out that a subset (as XML is canonically cast w.r.t SGML) will fail backward compatibility by force, because there will be old (i.e. existing) documents that new (XML) systems will not be able to handle as-is. Some sort of out-conversion will be needed in general, and I agree with Lee that hacks are not the way to do that. OTOH, the forward compatibility test, whether old (SGML) systems can handle new (XML) documents, hinges -- at least here -- on the fact that OMITTAG will be NO for the XML docs, so the SGML system won't need the minimization parameters anyway in the relevant DTDs. Occam's Razor (or is it Caveat Clutter?) says nuke 'em. Arjun -- "Features whose purpose is to cause errors should be removed." -- Erik Naggum To: lee@sq.com cc: w3c-sgml-wg@w3.org Subject: Re: OMITTAG specifications in element declarations <9611030422.AA14864@sqrex.sq.com> Date: Sun, 03 Nov 1996 09:52:27 -0500 From: Eve Maler >> The difference between OMITTAG and SHORTREF is that pretty much *every* >> DTD today includes the OMITTAG field, > >I would dispute that. Certainly we (at SQ) discourage its use. One reason >is that many SGML tools give clearer error messages without it. >Another is that it's pointless if you're using SGML-aware software, and >that's the business we (SQ) are in. Perhaps most ArborText customers >prefer to key their text in using vi or notepad?? :-) :-) No, but a lot of DTDs are industry DTDs where the maintainers have little control or influence over how documents are created. XML may require all tags to be present, but I know an awful lot of people who still key in tags by hand (Allah knows why! :-) and take advantage of tag omission. Is it an acceptable process model to let them do this and then normalize into XML? >> even if just "- -", partly because >> the SGML declaration (where OMITTAG is set to YES or NO) is a component of >> SGML documents as a whole, and DTDs technically don't automatically >> "come with" their own SGML declaration. > >I'm not sure what this means. Every SGML document has an SGML declaration, >and you always have to supply it, so yes, DTDs darned well ought to come >with their own SGML declaration if they need one. What I mean is that the SGML declaration has some settings related to DTDs (e.g. NAMELEN), and some related to instances. You can't craft an SGML declaration solely on the basis of what your DTD needs, and therefore the crafting of the SGML declaration might be in the hands of people who didn't write the DTD. OMITTAG affects both the instance's behavior and the DTD's element declarations. OMITTAG YES requires the tag omission fields; OMITTAG NO *allows* them, precisely (I assume) so you can go back and forth on this setting without having to change the DTD. Of course, XML doesn't even have SGML declarations, but full SGML does. We've disallowed a bunch of DTD behavior already, but none of it has a corresponding setting in the SGML declaration; if we were to provide an "XML SGML declaration" as part of the spec (which I think is a good idea), and it said OMITTAG NO, it would still imply that the tag omission fields are allowed. >It's true that I sometimes find people starting with the CALS declaration >and editing it, and I usually suggest that they stop doing that and >start with the standard one. You can get Author/Editor to save one for >you by checking "include SGML declaration" when you save your SGML. There's no "standard SGML declaration," just reference and core concrete syntaxes. (ADEPT uses a default decl internally, which you can change, save, etc.) I can't imagine whipping up an SGML declaration every time; I always start with an existing one! >> For me, this definitely comes under the heading of deciding whether or >> not to punish existing SGML users. > >I don't think it is any worse in that regard than not supporting >parameter entities, or than having NAMECASE NO. Having no OMITTAG >support in XML means that you'll have to change all those documents >anyway, and what better way to check that than with an SGML declaration >with OMITTAG set to NO? And what better way to make sure you've done >that than with a DTD without the tag omissibility thingies? The ERB is still discussing parameter entities, I believe, and the prognosis looks good. (Would it change your mind if they definitely were allowed?) And NAMECASE GENERAL is still on the block. >If most existing SGML DTDs work unchanged in XML, it seems to me that >we probably haven't simplified SGML enough to make any difference. If >most existing implementations use only the features of SGML that we >deem essential for XML, it's not clear to me that giving a name to that >set of features will actually encourage many more people to write >software than have already done so. > >So I think we have to be brutal. > >But it is good that you've pointed this out. I disagree that DTD simplification provides most of the benefits of XML; I believe it affects validation software more than it affects the majority of users. (The general simplification and normalization of the language as a whole -- DTDs and instances -- does help SGML's teachability and parsability quotients, which are very important.) There are still a lot of questions about how SGML and the "XML application profile" will interact, especially in the short term (when there will be no such thing as "XML software" yet). I guess I'm still an SGML conservative on the OMITTAG issue, preferring to allow more existing DTDs to be used as they are. Eve Date: Sun, 3 Nov 1996 20:14:10 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Case sensitivity in markup OK, internationalization experts, here's your chance to help out in a big way. The ERB has considered the issue of case sensitivity in markup at some length and has boiled down the options to just two alternatives: 1. Full case sensitivity in markup. 2. Case-folding using the Unicode rules. We would like everyone on the WG who has a qualified opinion on this issue to state which of these alternatives is preferable and why. The following points should be borne in mind: 1. Option 1 has tremendous backward-compatibility implications. Important as compatibility is, however, the primary purpose of this activity is to enable standardized structured data to be generated and served out to Web clients, not to preserve existing legacy data unchanged. 2. The Unicode method folds uppercase to lowercase (see below). ISO 8879 folds lowercase to uppercase; that is, it defines uppercase substitution (Clause 13.4.5) but not lowercase substitution. Due to the short amount of time remaining before we freeze the XML 1.0 specification, we need your input on this question as soon as possible. Jon ------------------------------------------------------------------------ >From the Unicode Standard 2.0 (July 1996), Section 4.1: _Case_ is a normative property of characters in certain alphabets whereby characters are considered to be variants of a single letter. These variants, which may differ markedly in shape and size, are called the _uppercase_ letter (also known as _capital_ or _majuscule_) and the _lowercase_ letter (also known as _small_ or _minuscule_). The uppercase letter is generally larger than the lowercase letter. Because of the inclusion of certain composite characters for compatibility, such as U+01F1 LATIN CAPITAL LETTER DZ, there is a third case, called _titlecase_, which is used where the first character of a word is to be capitalized. An example of such a character is U+01F2 LATIN CAPITAL LETTER D WITH SMALL LETTER Z. The three case forms are UPPERCASE, Titlecase, lowercase. For those scripts that have case (Latin, Greek, Cyrillic, and Armenian), the case of a Unicode character can be obtained from the character's name. This is true for only these four scripts. Uppercase characters contain the word _capital_ in their names. Lowercase characters contain the word _small._ The word _small_ in the names of characters from scripts other than the four just listed has nothing to do with case. ... The lowercase letter default case mapping is between the small character and the capital character. The Unicode Standard case mapping tables, which are informative, are on the CD-ROM [bound in with the standard]. In a few instances, upper and lowercase mapping may differ from language to language between writing systems that employ the same letters.... [Examples cited are Turkish dotless "i" and French e-acute.] However, in general the vast majority of case mappings are uniform across languages.... Because there are many more lowercase forms than there are uppercase or titlecase, it is recommended that the lowercase form be used for normalization, such as when strings are case-folded for loose comparison or indexing. [Note:] Case correspondences are not always one-to-one: the result of case folding may be a different character length than in the source string (for example, U+00DF LATIN SMALL LETTER SHARP S [glyph for sz shown] becomes "SS" in uppercase). Date: Sun, 03 Nov 1996 22:38:11 -0600 (CDT) From: DAVEP@acm.org Subject: Re: Case sensitivity in markup To: bosak@atlantic-83.eng.sun.com Cc: W3C-SGML-WG@w3.org recently wrote: >From the Unicode Standard 2.0 (July 1996), Section 4.1: > Because there are many more lowercase forms than there are > uppercase or titlecase, it is recommended that the lowercase form > be used for normalization, such as when strings are case-folded > for loose comparison or indexing. Makes sense when "normalization" means "the best case to keep your master data in, since it's harder to convert other forms to this one (adding information) rather than vice versa (supressing information)". But that doesn't apply here. If my case normalization drops accents going to upper case, how can I normalize to lower case? I don't have an algorithm to regain the correct accents when my parser must convert the occasional uppercase word back to lower case to recognize it. The other examples of conversion problems normalizing to uppercase suggest that the only universal solution will be to disallow case normalization. (Unix forever; down with DOS? :-) ) _Personally_, I don't care. Dave Peterson SGMLWorks! davep@acm.org Date: Sun, 3 Nov 1996 23:55:05 -0500 To: w3c-sgml-wg@w3.org From: "David G. Durand" (David G. Durand) Subject: Re: OMITTAG specifications in element declarations This note starts with one point, and records my reasoning as I abandoned the point again. (Maybe it's not rhetorically sensible, but that's the way it happened, so I've been thinking about this some more, and watching the discussion, and I think that we maybe should allow the minimization flags, _if_ we explicitly label them as an SGML compatibility feature. This explicit labelling may be a hopbby horse of mine, but I think it is something we must do for the negative requirements we are already making (like disallowing -- in comments). Not being honest about these feature would be a terrible mistake. Of course, adding something to the grammar that is not already there is more intrusive than removing something that _could_ be there. No XML document will be invalid when parsed with a parser that fails to implement the comment restriction, but an XML document that puts - - in its element declarations would be invalid to a parser that skipped implementing SGML-compatibility features. It's a much stronger requirement on processors to add something to the language for compatibility, than to remove it for the same reason -- even people who don't care about compatibility have to implement added-features they don't need, whereas not implementing restrictions you don't care about is easier and safer. I guess we're back to eliminating them. I'm not sure it's worth adding syntax, especially given the number of changes that many DTDs will have to undergo, anyway. -- 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: Sun, 3 Nov 1996 20:57:31 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Unicode case mapping Appended below are two items from the CD included with the Unicode 2.0 standard that show the Unicode case mapping rules. The first item is a file called readme.txt that gives the data format for the Unicode character database. Note that the last two fields for each data entry show the lowercase and uppercase mappings. The second item contains all the entries from the Unicode character database for which case mappings are given. Jon ============================================= The file "readme.txt" from the Unicode 2.0 CD ============================================= UNICODE 2.0 CHARACTER DATABASE Copyright (c) 1991-1996 Unicode, Inc. All Rights reserved. DISCLAIMER The Unicode Character Database "UNIDATA2.TXT" is provided as-is by Unicode, Inc. (The Unicode Consortium). No claims are made as to fitness for any particular purpose. No warranties of any kind are expressed or implied. The recipient agrees to determine applicability of information provided. If this file has been purchased on magnetic or optical media from Unicode, Inc., the sole remedy for any claim will be exchange of defective media within 90 days of receipt. This disclaimer is applicable for all other data files accompanying the Unicode Character Database, some of which have been compiled by the Unicode Consortium, and some of which have been supplied by other vendors. LIMITATIONS ON RIGHTS TO REDISTRIBUTE THIS DATA Recipient is granted the right to make copies in any form for internal distribution and to freely use the information supplied in the creation of products supporting the Unicode (TM) Standard. This file can be redistributed to third parties or other organizations (whether for profit or not) as long as this notice and the disclaimer notice are retained. EXPLANATORY INFORMATION The Unicode Character Database defines the default Unicode character properties, and internal mappings. Particular implementations may choose to override the properties and mappings that are not normative. If that is done, it is up to the implementer to establish a protocol to convey that information. For more information about character properties and mappings, see "The Unicode Standard, Worldwide Character Encoding, Version 2.0", published by Addison-Wesley. For information about other data files accompanying the Unicode Character Database, see the section of the Unicode Standard they were extracted from, or the explanatory readme files and/or header sections with those files. The Unicode Character Database is a plain ASCII text file consisting of lines containing fields terminated by semicolons. Each line represents the data for one encoded character in the Unicode Standard, Version 2.0. Every encoded character has a data entry, with the exception of certain special ranges, as detailed below. There are five special ranges of characters that are represented only by their start and end characters, since the properties in the file are uniform, except for code values (which are all sequential and assigned). The names of CJK ideograph characters and Hangul syllable characters are algorithmically derivable. (See the Unicode Standard for more information). Surrogate characters and private use characters have no names. The exact ranges represented by start and end characters are: The CJK Ideographs Area (U+4E00 - U+9FFF) The Hangul Syllables Area (U+AC00 - U+D7A3) The Surrogates Area (U+D800 - U+DFFF) The Private Use Area (U+E000 - U+F8FF) CJK Compatibility Ideographs (U+F900 - U+FAFF) The following table describes the format and meaning of each field in a data entry in the Unicode Character Database. Fields which contain normative information are so indicated. Field Explanation ----- ----------- 0 Code value in 4-digit hexadecimal format. This field is normative. 1 Unicode 2.0 Character Name. These names match exactly the names published in Chapter 7 of the Unicode Standard. This field is normative. 2 General Category. This is a useful breakdown into various "character types" which can be used as a default categorization in implementations. Some of the values are normative, and some are informative. See below for a brief explanation. 3 Canonical Combining Classes. The classes used for the Canonical Ordering Algorithm in the Unicode Standard. These classes are also printed in Chapter 4 of the Unicode Standard. This field is normative. See below for a brief explanation. 4 Bidirectional Category. See the list below for an explanation of the abbreviations used in this field. These are the categories required by the Bidirectional Behavior Algorithm in the Unicode Standard. These categories are summarized in Chapter 4 of the Unicode Standard. This field is normative. 5 Character Decomposition. In the Unicode Standard, Version 2.0, not all of the decompositions are full decompositions. Recursive application of look-up for decompositions will, in all cases, lead to a maximal decomposition. The decompositions match exactly the decompositions published with the character names in Chapter 7 of the Unicode Standard. This field is normative. 6 Decimal digit value. This is a numeric field. If the character has the decimal digit property, as specified in Chapter 4 of the Unicode Standard, the value of that digit is represented with an integer value in this field. This field is normative. 7 Digit value. This is a numeric field. If the character represents a digit, not necessarily a decimal digit, the value is here. This covers digits which do not form decimal radix forms, such as the compatibility superscript digits. This field is informative. 8 Numeric value. This is a numeric field. If the character has the numeric property, as specified in Chapter 4 of the Unicode Standard, the value of that character is represented with an integer or rational number in this field. This includes fractions as, e.g., "1/5" for U+2155 VULGAR FRACTION ONE FIFTH. Also included are numerical values for compatibility characters such as circled numbers. This field is normative. 9 If the characters has been identified as a "mirrored" character in bidirectional text, this field has the value "Y"; otherwise "N". The list of mirrored characters is also printed in Chapter 4 of the Unicode Standard. This field is normative. 10 Unicode 1.0 Name. This is the old name as published in Unicode 1.0. This name is only provided when it is significantly different from the Unicode 2.0 name for the character. This field is informative. 11 10646 Comment field. This field is informative. 12 Upper case equivalent mapping. If a character is part of an alphabet with case distinctions, and has an upper case equivalent, then the upper case equivalent is in this field. See the explanation below on case distinctions. These mappings are always one-to-one, not one-to-many or many-to-one. This field is informative. 13 Lower case equivalent mapping. Similar to 12. This field is informative. 14 Title case equivalent mapping. Similar to 12. This field is informative. GENERAL CATEGORY The values in this field are abbreviations for the following. Some of the values are normative, and some are informative. For more information, see the Unicode Standard. Normative Mn = Mark, Non-Spacing Mc = Mark, Combining Nd = Number, Decimal Digit No = Number, Other Zs = Separator, Space Zl = Separator, Line Zp = Separator, Paragraph Cc = Other, Control or Format Co = Other, Private Use Cn = Other, Not Assigned Informative Lu = Letter, Uppercase Ll = Letter, Lowercase Lt = Letter, Titlecase Lm = Letter, Modifier Lo = Letter, Other Pd = Punctuation, Dash Ps = Punctuation, Open Pe = Punctuation, Close Po = Punctuation, Other Sm = Symbol, Math Sc = Symbol, Currency So = Symbol, Other BIDIRECTIONAL PROPERTIES Please refer to the Unicode Standard for an explanation of the algorithm for Bidirectional Behavior and an explanation of the sigificance of these categories. These values are normative. Strong types: L Left-Right; Most alphabetic, syllabic, and logographic characters (e.g., CJK ideographs) R Right-Left; Arabic, Hebrew, and punctuation specific to those scripts Weak types: EN European Number ES European Number Separator ET European Number Terminator AN Arabic Number CS Common Number Separator Separators: B Block Separator S Segment Separator Neutrals: WS Whitespace ON Other Neutrals ; All other characters: punctuation, symbols CHARACTER DECOMPOSITION TAGS The decomposition is a normative property of a character. The tags supplied with certain decompositions generally indicate formatting information. Where no such tag is given, the decomposition is designated as canonical. Conversely, the presence of a formatting tag also indicates that the decomposition is a compatibility decomposition and not a canonical decomposition. In the absence of other formatting information in a compatibility decomposition, the tag is used to distinguish it from canonical decompositions. In some instances a canonical decomposition or a compatibility decomposition may consist of a single character. For a canonical decomposition, this indicates that the character is a canonical equivalent of another single character. For a compatibility decomposition, this indicates that the character is a compatibility equivalent of another single character. The compatibility formatting tags used are: A font variant (e.g. a blackletter form). A no-break version of a space or hyphen. An initial presentation form (Arabic). A medial presentation form (Arabic). A final presentation form (Arabic). An isolated presentation form (Arabic). An encircled form. A superscript form. A subscript form. A vertical layout presentation form. A wide (or zenkaku) compatibility character. A narrow (or hankaku) compatibility character. A small variant form (CNS compatibility). A CJK squared font variant. Otherwise unspecified compatibility character. CANONICAL COMBINING CLASSES 0: Spacing, enclosing, reordrant, and surrounding 1: Overlays and interior 6: Tibetan subjoined Letters 7: Nuktas 8: Hiragana/Katakana voiced marks 9: Viramas 10: Start of fixed position classes 199: End of fixed position classes 200: Below left attached 202: Below attached 204: Below right attached 208: Left attached (reordrant around single base character) 210: Right attached 212: Above left attached 214: Above attached 216: Above right attached 218: Below left 220: Below 222: Below right 224: Left (reordrant around single base character) 226: Right 228: Above left 230: Above 232: Above right 234: Double above Note: some of the combining classes in this list do not currently have members but are specified here for completeness. CASE MAPPINGS In addition to uppercase and lowercase, because of the inclusion of certain composite characters for compatibility, such as "01F1;LATIN CAPITAL LETTER DZ", there is a third case, called titlecase, which is used where the first character of a word is to be capitalized (e.g. UPPERCASE, Titlecase, lowercase). An example of such a character is "01F2;LATIN CAPITAL LETTER D WITH SMALL LETTER Z". The uppercase, titlecase and lowercase fields are only included for characters that have a single corresponding character of that type. Composite characters (such as "339D;SQUARE CM") that do not have a single corresponding character of that type can be cased by decomposition. The case mapping is an informative, default mapping. Certain languages, such as Turkish, German, French, or Greek may have small deviations from the default mappings listed in the Unicode Character Database. MODIFICATION HISTORY Some of the modifications made in updating the Unicode Character Database for the Unicode Standard, Version 2.0 are: * Fixed decompositions with TONOS to use correct NSM: 030D. * Removed old Hangul Syllables; mapping to new characters are in a separate table. * Marked compability decompositions with additional tags. * Changed old tag names for clarity. * Revision of decompositions to use first-level decomposition, instead of maximal decomposition. * Correction of all known errors in decompositions from earlier versions. * Added control code names (as old Unicode names). * Added Hangul Jamo decompositions. * Added Number category to match properties list in book. * Fixed categories of Koranic Arabic marks. * Fixed categories of precomposed characters to match decomposition where possible. * Added Hebrew cantillation marks and the Tibetan script. * Added place holders for ranges such as CJK Ideographic Area and the Private Use Area. * Eliminated "Nd" as a category. ============================================================================== List of entries from the file "unidata2.txt" for which case mappings are given ============================================================================== 0041;LATIN CAPITAL LETTER A;Lu;0;L;;;;;N;;;;0061; 0042;LATIN CAPITAL LETTER B;Lu;0;L;;;;;N;;;;0062; 0043;LATIN CAPITAL LETTER C;Lu;0;L;;;;;N;;;;0063; 0044;LATIN CAPITAL LETTER D;Lu;0;L;;;;;N;;;;0064; 0045;LATIN CAPITAL LETTER E;Lu;0;L;;;;;N;;;;0065; 0046;LATIN CAPITAL LETTER F;Lu;0;L;;;;;N;;;;0066; 0047;LATIN CAPITAL LETTER G;Lu;0;L;;;;;N;;;;0067; 0048;LATIN CAPITAL LETTER H;Lu;0;L;;;;;N;;;;0068; 0049;LATIN CAPITAL LETTER I;Lu;0;L;;;;;N;;;;0069; 004A;LATIN CAPITAL LETTER J;Lu;0;L;;;;;N;;;;006A; 004B;LATIN CAPITAL LETTER K;Lu;0;L;;;;;N;;;;006B; 004C;LATIN CAPITAL LETTER L;Lu;0;L;;;;;N;;;;006C; 004D;LATIN CAPITAL LETTER M;Lu;0;L;;;;;N;;;;006D; 004E;LATIN CAPITAL LETTER N;Lu;0;L;;;;;N;;;;006E; 004F;LATIN CAPITAL LETTER O;Lu;0;L;;;;;N;;;;006F; 0050;LATIN CAPITAL LETTER P;Lu;0;L;;;;;N;;;;0070; 0051;LATIN CAPITAL LETTER Q;Lu;0;L;;;;;N;;;;0071; 0052;LATIN CAPITAL LETTER R;Lu;0;L;;;;;N;;;;0072; 0053;LATIN CAPITAL LETTER S;Lu;0;L;;;;;N;;;;0073; 0054;LATIN CAPITAL LETTER T;Lu;0;L;;;;;N;;;;0074; 0055;LATIN CAPITAL LETTER U;Lu;0;L;;;;;N;;;;0075; 0056;LATIN CAPITAL LETTER V;Lu;0;L;;;;;N;;;;0076; 0057;LATIN CAPITAL LETTER W;Lu;0;L;;;;;N;;;;0077; 0058;LATIN CAPITAL LETTER X;Lu;0;L;;;;;N;;;;0078; 0059;LATIN CAPITAL LETTER Y;Lu;0;L;;;;;N;;;;0079; 005A;LATIN CAPITAL LETTER Z;Lu;0;L;;;;;N;;;;007A; 0061;LATIN SMALL LETTER A;Ll;0;L;;;;;N;;;0041;;0041 0062;LATIN SMALL LETTER B;Ll;0;L;;;;;N;;;0042;;0042 0063;LATIN SMALL LETTER C;Ll;0;L;;;;;N;;;0043;;0043 0064;LATIN SMALL LETTER D;Ll;0;L;;;;;N;;;0044;;0044 0065;LATIN SMALL LETTER E;Ll;0;L;;;;;N;;;0045;;0045 0066;LATIN SMALL LETTER F;Ll;0;L;;;;;N;;;0046;;0046 0067;LATIN SMALL LETTER G;Ll;0;L;;;;;N;;;0047;;0047 0068;LATIN SMALL LETTER H;Ll;0;L;;;;;N;;;0048;;0048 0069;LATIN SMALL LETTER I;Ll;0;L;;;;;N;;;0049;;0049 006A;LATIN SMALL LETTER J;Ll;0;L;;;;;N;;;004A;;004A 006B;LATIN SMALL LETTER K;Ll;0;L;;;;;N;;;004B;;004B 006C;LATIN SMALL LETTER L;Ll;0;L;;;;;N;;;004C;;004C 006D;LATIN SMALL LETTER M;Ll;0;L;;;;;N;;;004D;;004D 006E;LATIN SMALL LETTER N;Ll;0;L;;;;;N;;;004E;;004E 006F;LATIN SMALL LETTER O;Ll;0;L;;;;;N;;;004F;;004F 0070;LATIN SMALL LETTER P;Ll;0;L;;;;;N;;;0050;;0050 0071;LATIN SMALL LETTER Q;Ll;0;L;;;;;N;;;0051;;0051 0072;LATIN SMALL LETTER R;Ll;0;L;;;;;N;;;0052;;0052 0073;LATIN SMALL LETTER S;Ll;0;L;;;;;N;;;0053;;0053 0074;LATIN SMALL LETTER T;Ll;0;L;;;;;N;;;0054;;0054 0075;LATIN SMALL LETTER U;Ll;0;L;;;;;N;;;0055;;0055 0076;LATIN SMALL LETTER V;Ll;0;L;;;;;N;;;0056;;0056 0077;LATIN SMALL LETTER W;Ll;0;L;;;;;N;;;0057;;0057 0078;LATIN SMALL LETTER X;Ll;0;L;;;;;N;;;0058;;0058 0079;LATIN SMALL LETTER Y;Ll;0;L;;;;;N;;;0059;;0059 007A;LATIN SMALL LETTER Z;Ll;0;L;;;;;N;;;005A;;005A 00C0;LATIN CAPITAL LETTER A WITH GRAVE;Lu;0;L;0041 0300;;;;N;LATIN CAPITAL LETTER A GRAVE;;;00E0; 00C1;LATIN CAPITAL LETTER A WITH ACUTE;Lu;0;L;0041 0301;;;;N;LATIN CAPITAL LETTER A ACUTE;;;00E1; 00C2;LATIN CAPITAL LETTER A WITH CIRCUMFLEX;Lu;0;L;0041 0302;;;;N;LATIN CAPITAL LETTER A CIRCUMFLEX;;;00E2; 00C3;LATIN CAPITAL LETTER A WITH TILDE;Lu;0;L;0041 0303;;;;N;LATIN CAPITAL LETTER A TILDE;;;00E3; 00C4;LATIN CAPITAL LETTER A WITH DIAERESIS;Lu;0;L;0041 0308;;;;N;LATIN CAPITAL LETTER A DIAERESIS;;;00E4; 00C5;LATIN CAPITAL LETTER A WITH RING ABOVE;Lu;0;L;0041 030A;;;;N;LATIN CAPITAL LETTER A RING;;;00E5; 00C6;LATIN CAPITAL LETTER AE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER A E;;;00E6; 00C7;LATIN CAPITAL LETTER C WITH CEDILLA;Lu;0;L;0043 0327;;;;N;LATIN CAPITAL LETTER C CEDILLA;;;00E7; 00C8;LATIN CAPITAL LETTER E WITH GRAVE;Lu;0;L;0045 0300;;;;N;LATIN CAPITAL LETTER E GRAVE;;;00E8; 00C9;LATIN CAPITAL LETTER E WITH ACUTE;Lu;0;L;0045 0301;;;;N;LATIN CAPITAL LETTER E ACUTE;;;00E9; 00CA;LATIN CAPITAL LETTER E WITH CIRCUMFLEX;Lu;0;L;0045 0302;;;;N;LATIN CAPITAL LETTER E CIRCUMFLEX;;;00EA; 00CB;LATIN CAPITAL LETTER E WITH DIAERESIS;Lu;0;L;0045 0308;;;;N;LATIN CAPITAL LETTER E DIAERESIS;;;00EB; 00CC;LATIN CAPITAL LETTER I WITH GRAVE;Lu;0;L;0049 0300;;;;N;LATIN CAPITAL LETTER I GRAVE;;;00EC; 00CD;LATIN CAPITAL LETTER I WITH ACUTE;Lu;0;L;0049 0301;;;;N;LATIN CAPITAL LETTER I ACUTE;;;00ED; 00CE;LATIN CAPITAL LETTER I WITH CIRCUMFLEX;Lu;0;L;0049 0302;;;;N;LATIN CAPITAL LETTER I CIRCUMFLEX;;;00EE; 00CF;LATIN CAPITAL LETTER I WITH DIAERESIS;Lu;0;L;0049 0308;;;;N;LATIN CAPITAL LETTER I DIAERESIS;;;00EF; 00D0;LATIN CAPITAL LETTER ETH;Lu;0;L;;;;;N;;Icelandic;;00F0; 00D1;LATIN CAPITAL LETTER N WITH TILDE;Lu;0;L;004E 0303;;;;N;LATIN CAPITAL LETTER N TILDE;;;00F1; 00D2;LATIN CAPITAL LETTER O WITH GRAVE;Lu;0;L;004F 0300;;;;N;LATIN CAPITAL LETTER O GRAVE;;;00F2; 00D3;LATIN CAPITAL LETTER O WITH ACUTE;Lu;0;L;004F 0301;;;;N;LATIN CAPITAL LETTER O ACUTE;;;00F3; 00D4;LATIN CAPITAL LETTER O WITH CIRCUMFLEX;Lu;0;L;004F 0302;;;;N;LATIN CAPITAL LETTER O CIRCUMFLEX;;;00F4; 00D5;LATIN CAPITAL LETTER O WITH TILDE;Lu;0;L;004F 0303;;;;N;LATIN CAPITAL LETTER O TILDE;;;00F5; 00D6;LATIN CAPITAL LETTER O WITH DIAERESIS;Lu;0;L;004F 0308;;;;N;LATIN CAPITAL LETTER O DIAERESIS;;;00F6; 00D8;LATIN CAPITAL LETTER O WITH STROKE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER O SLASH;;;00F8; 00D9;LATIN CAPITAL LETTER U WITH GRAVE;Lu;0;L;0055 0300;;;;N;LATIN CAPITAL LETTER U GRAVE;;;00F9; 00DA;LATIN CAPITAL LETTER U WITH ACUTE;Lu;0;L;0055 0301;;;;N;LATIN CAPITAL LETTER U ACUTE;;;00FA; 00DB;LATIN CAPITAL LETTER U WITH CIRCUMFLEX;Lu;0;L;0055 0302;;;;N;LATIN CAPITAL LETTER U CIRCUMFLEX;;;00FB; 00DC;LATIN CAPITAL LETTER U WITH DIAERESIS;Lu;0;L;0055 0308;;;;N;LATIN CAPITAL LETTER U DIAERESIS;;;00FC; 00DD;LATIN CAPITAL LETTER Y WITH ACUTE;Lu;0;L;0059 0301;;;;N;LATIN CAPITAL LETTER Y ACUTE;;;00FD; 00DE;LATIN CAPITAL LETTER THORN;Lu;0;L;;;;;N;;Icelandic;;00FE; 00E0;LATIN SMALL LETTER A WITH GRAVE;Ll;0;L;0061 0300;;;;N;LATIN SMALL LETTER A GRAVE;;00C0;;00C0 00E1;LATIN SMALL LETTER A WITH ACUTE;Ll;0;L;0061 0301;;;;N;LATIN SMALL LETTER A ACUTE;;00C1;;00C1 00E2;LATIN SMALL LETTER A WITH CIRCUMFLEX;Ll;0;L;0061 0302;;;;N;LATIN SMALL LETTER A CIRCUMFLEX;;00C2;;00C2 00E3;LATIN SMALL LETTER A WITH TILDE;Ll;0;L;0061 0303;;;;N;LATIN SMALL LETTER A TILDE;;00C3;;00C3 00E4;LATIN SMALL LETTER A WITH DIAERESIS;Ll;0;L;0061 0308;;;;N;LATIN SMALL LETTER A DIAERESIS;;00C4;;00C4 00E5;LATIN SMALL LETTER A WITH RING ABOVE;Ll;0;L;0061 030A;;;;N;LATIN SMALL LETTER A RING;;00C5;;00C5 00E6;LATIN SMALL LETTER AE;Ll;0;L;;;;;N;LATIN SMALL LETTER A E;;00C6;;00C6 00E7;LATIN SMALL LETTER C WITH CEDILLA;Ll;0;L;0063 0327;;;;N;LATIN SMALL LETTER C CEDILLA;;00C7;;00C7 00E8;LATIN SMALL LETTER E WITH GRAVE;Ll;0;L;0065 0300;;;;N;LATIN SMALL LETTER E GRAVE;;00C8;;00C8 00E9;LATIN SMALL LETTER E WITH ACUTE;Ll;0;L;0065 0301;;;;N;LATIN SMALL LETTER E ACUTE;;00C9;;00C9 00EA;LATIN SMALL LETTER E WITH CIRCUMFLEX;Ll;0;L;0065 0302;;;;N;LATIN SMALL LETTER E CIRCUMFLEX;;00CA;;00CA 00EB;LATIN SMALL LETTER E WITH DIAERESIS;Ll;0;L;0065 0308;;;;N;LATIN SMALL LETTER E DIAERESIS;;00CB;;00CB 00EC;LATIN SMALL LETTER I WITH GRAVE;Ll;0;L;0069 0300;;;;N;LATIN SMALL LETTER I GRAVE;;00CC;;00CC 00ED;LATIN SMALL LETTER I WITH ACUTE;Ll;0;L;0069 0301;;;;N;LATIN SMALL LETTER I ACUTE;;00CD;;00CD 00EE;LATIN SMALL LETTER I WITH CIRCUMFLEX;Ll;0;L;0069 0302;;;;N;LATIN SMALL LETTER I CIRCUMFLEX;;00CE;;00CE 00EF;LATIN SMALL LETTER I WITH DIAERESIS;Ll;0;L;0069 0308;;;;N;LATIN SMALL LETTER I DIAERESIS;;00CF;;00CF 00F0;LATIN SMALL LETTER ETH;Ll;0;L;;;;;N;;Icelandic;00D0;;00D0 00F1;LATIN SMALL LETTER N WITH TILDE;Ll;0;L;006E 0303;;;;N;LATIN SMALL LETTER N TILDE;;00D1;;00D1 00F2;LATIN SMALL LETTER O WITH GRAVE;Ll;0;L;006F 0300;;;;N;LATIN SMALL LETTER O GRAVE;;00D2;;00D2 00F3;LATIN SMALL LETTER O WITH ACUTE;Ll;0;L;006F 0301;;;;N;LATIN SMALL LETTER O ACUTE;;00D3;;00D3 00F4;LATIN SMALL LETTER O WITH CIRCUMFLEX;Ll;0;L;006F 0302;;;;N;LATIN SMALL LETTER O CIRCUMFLEX;;00D4;;00D4 00F5;LATIN SMALL LETTER O WITH TILDE;Ll;0;L;006F 0303;;;;N;LATIN SMALL LETTER O TILDE;;00D5;;00D5 00F6;LATIN SMALL LETTER O WITH DIAERESIS;Ll;0;L;006F 0308;;;;N;LATIN SMALL LETTER O DIAERESIS;;00D6;;00D6 00F8;LATIN SMALL LETTER O WITH STROKE;Ll;0;L;;;;;N;LATIN SMALL LETTER O SLASH;;00D8;;00D8 00F9;LATIN SMALL LETTER U WITH GRAVE;Ll;0;L;0075 0300;;;;N;LATIN SMALL LETTER U GRAVE;;00D9;;00D9 00FA;LATIN SMALL LETTER U WITH ACUTE;Ll;0;L;0075 0301;;;;N;LATIN SMALL LETTER U ACUTE;;00DA;;00DA 00FB;LATIN SMALL LETTER U WITH CIRCUMFLEX;Ll;0;L;0075 0302;;;;N;LATIN SMALL LETTER U CIRCUMFLEX;;00DB;;00DB 00FC;LATIN SMALL LETTER U WITH DIAERESIS;Ll;0;L;0075 0308;;;;N;LATIN SMALL LETTER U DIAERESIS;;00DC;;00DC 00FD;LATIN SMALL LETTER Y WITH ACUTE;Ll;0;L;0079 0301;;;;N;LATIN SMALL LETTER Y ACUTE;;00DD;;00DD 00FE;LATIN SMALL LETTER THORN;Ll;0;L;;;;;N;;Icelandic;00DE;;00DE 00FF;LATIN SMALL LETTER Y WITH DIAERESIS;Ll;0;L;0079 0308;;;;N;LATIN SMALL LETTER Y DIAERESIS;;0178;;0178 0100;LATIN CAPITAL LETTER A WITH MACRON;Lu;0;L;0041 0304;;;;N;LATIN CAPITAL LETTER A MACRON;;;0101; 0101;LATIN SMALL LETTER A WITH MACRON;Ll;0;L;0061 0304;;;;N;LATIN SMALL LETTER A MACRON;;0100;;0100 0102;LATIN CAPITAL LETTER A WITH BREVE;Lu;0;L;0041 0306;;;;N;LATIN CAPITAL LETTER A BREVE;;;0103; 0103;LATIN SMALL LETTER A WITH BREVE;Ll;0;L;0061 0306;;;;N;LATIN SMALL LETTER A BREVE;;0102;;0102 0104;LATIN CAPITAL LETTER A WITH OGONEK;Lu;0;L;0041 0328;;;;N;LATIN CAPITAL LETTER A OGONEK;;;0105; 0105;LATIN SMALL LETTER A WITH OGONEK;Ll;0;L;0061 0328;;;;N;LATIN SMALL LETTER A OGONEK;;0104;;0104 0106;LATIN CAPITAL LETTER C WITH ACUTE;Lu;0;L;0043 0301;;;;N;LATIN CAPITAL LETTER C ACUTE;;;0107; 0107;LATIN SMALL LETTER C WITH ACUTE;Ll;0;L;0063 0301;;;;N;LATIN SMALL LETTER C ACUTE;;0106;;0106 0108;LATIN CAPITAL LETTER C WITH CIRCUMFLEX;Lu;0;L;0043 0302;;;;N;LATIN CAPITAL LETTER C CIRCUMFLEX;;;0109; 0109;LATIN SMALL LETTER C WITH CIRCUMFLEX;Ll;0;L;0063 0302;;;;N;LATIN SMALL LETTER C CIRCUMFLEX;;0108;;0108 010A;LATIN CAPITAL LETTER C WITH DOT ABOVE;Lu;0;L;0043 0307;;;;N;LATIN CAPITAL LETTER C DOT;;;010B; 010B;LATIN SMALL LETTER C WITH DOT ABOVE;Ll;0;L;0063 0307;;;;N;LATIN SMALL LETTER C DOT;;010A;;010A 010C;LATIN CAPITAL LETTER C WITH CARON;Lu;0;L;0043 030C;;;;N;LATIN CAPITAL LETTER C HACEK;;;010D; 010D;LATIN SMALL LETTER C WITH CARON;Ll;0;L;0063 030C;;;;N;LATIN SMALL LETTER C HACEK;;010C;;010C 010E;LATIN CAPITAL LETTER D WITH CARON;Lu;0;L;0044 030C;;;;N;LATIN CAPITAL LETTER D HACEK;;;010F; 010F;LATIN SMALL LETTER D WITH CARON;Ll;0;L;0064 030C;;;;N;LATIN SMALL LETTER D HACEK;;010E;;010E 0110;LATIN CAPITAL LETTER D WITH STROKE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER D BAR;;;0111; 0111;LATIN SMALL LETTER D WITH STROKE;Ll;0;L;;;;;N;LATIN SMALL LETTER D BAR;;0110;;0110 0112;LATIN CAPITAL LETTER E WITH MACRON;Lu;0;L;0045 0304;;;;N;LATIN CAPITAL LETTER E MACRON;;;0113; 0113;LATIN SMALL LETTER E WITH MACRON;Ll;0;L;0065 0304;;;;N;LATIN SMALL LETTER E MACRON;;0112;;0112 0114;LATIN CAPITAL LETTER E WITH BREVE;Lu;0;L;0045 0306;;;;N;LATIN CAPITAL LETTER E BREVE;;;0115; 0115;LATIN SMALL LETTER E WITH BREVE;Ll;0;L;0065 0306;;;;N;LATIN SMALL LETTER E BREVE;;0114;;0114 0116;LATIN CAPITAL LETTER E WITH DOT ABOVE;Lu;0;L;0045 0307;;;;N;LATIN CAPITAL LETTER E DOT;;;0117; 0117;LATIN SMALL LETTER E WITH DOT ABOVE;Ll;0;L;0065 0307;;;;N;LATIN SMALL LETTER E DOT;;0116;;0116 0118;LATIN CAPITAL LETTER E WITH OGONEK;Lu;0;L;0045 0328;;;;N;LATIN CAPITAL LETTER E OGONEK;;;0119; 0119;LATIN SMALL LETTER E WITH OGONEK;Ll;0;L;0065 0328;;;;N;LATIN SMALL LETTER E OGONEK;;0118;;0118 011A;LATIN CAPITAL LETTER E WITH CARON;Lu;0;L;0045 030C;;;;N;LATIN CAPITAL LETTER E HACEK;;;011B; 011B;LATIN SMALL LETTER E WITH CARON;Ll;0;L;0065 030C;;;;N;LATIN SMALL LETTER E HACEK;;011A;;011A 011C;LATIN CAPITAL LETTER G WITH CIRCUMFLEX;Lu;0;L;0047 0302;;;;N;LATIN CAPITAL LETTER G CIRCUMFLEX;;;011D; 011D;LATIN SMALL LETTER G WITH CIRCUMFLEX;Ll;0;L;0067 0302;;;;N;LATIN SMALL LETTER G CIRCUMFLEX;;011C;;011C 011E;LATIN CAPITAL LETTER G WITH BREVE;Lu;0;L;0047 0306;;;;N;LATIN CAPITAL LETTER G BREVE;;;011F; 011F;LATIN SMALL LETTER G WITH BREVE;Ll;0;L;0067 0306;;;;N;LATIN SMALL LETTER G BREVE;;011E;;011E 0120;LATIN CAPITAL LETTER G WITH DOT ABOVE;Lu;0;L;0047 0307;;;;N;LATIN CAPITAL LETTER G DOT;;;0121; 0121;LATIN SMALL LETTER G WITH DOT ABOVE;Ll;0;L;0067 0307;;;;N;LATIN SMALL LETTER G DOT;;0120;;0120 0122;LATIN CAPITAL LETTER G WITH CEDILLA;Lu;0;L;0047 0327;;;;N;LATIN CAPITAL LETTER G CEDILLA;;;0123; 0123;LATIN SMALL LETTER G WITH CEDILLA;Ll;0;L;0067 0327;;;;N;LATIN SMALL LETTER G CEDILLA;;0122;;0122 0124;LATIN CAPITAL LETTER H WITH CIRCUMFLEX;Lu;0;L;0048 0302;;;;N;LATIN CAPITAL LETTER H CIRCUMFLEX;;;0125; 0125;LATIN SMALL LETTER H WITH CIRCUMFLEX;Ll;0;L;0068 0302;;;;N;LATIN SMALL LETTER H CIRCUMFLEX;;0124;;0124 0126;LATIN CAPITAL LETTER H WITH STROKE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER H BAR;;;0127; 0127;LATIN SMALL LETTER H WITH STROKE;Ll;0;L;;;;;N;LATIN SMALL LETTER H BAR;;0126;;0126 0128;LATIN CAPITAL LETTER I WITH TILDE;Lu;0;L;0049 0303;;;;N;LATIN CAPITAL LETTER I TILDE;;;0129; 0129;LATIN SMALL LETTER I WITH TILDE;Ll;0;L;0069 0303;;;;N;LATIN SMALL LETTER I TILDE;;0128;;0128 012A;LATIN CAPITAL LETTER I WITH MACRON;Lu;0;L;0049 0304;;;;N;LATIN CAPITAL LETTER I MACRON;;;012B; 012B;LATIN SMALL LETTER I WITH MACRON;Ll;0;L;0069 0304;;;;N;LATIN SMALL LETTER I MACRON;;012A;;012A 012C;LATIN CAPITAL LETTER I WITH BREVE;Lu;0;L;0049 0306;;;;N;LATIN CAPITAL LETTER I BREVE;;;012D; 012D;LATIN SMALL LETTER I WITH BREVE;Ll;0;L;0069 0306;;;;N;LATIN SMALL LETTER I BREVE;;012C;;012C 012E;LATIN CAPITAL LETTER I WITH OGONEK;Lu;0;L;0049 0328;;;;N;LATIN CAPITAL LETTER I OGONEK;;;012F; 012F;LATIN SMALL LETTER I WITH OGONEK;Ll;0;L;0069 0328;;;;N;LATIN SMALL LETTER I OGONEK;;012E;;012E 0130;LATIN CAPITAL LETTER I WITH DOT ABOVE;Lu;0;L;0049 0307;;;;N;LATIN CAPITAL LETTER I DOT;;;0069; 0131;LATIN SMALL LETTER DOTLESS I;Ll;0;L;;;;;N;;;0049;;0049 0132;LATIN CAPITAL LIGATURE IJ;Lu;0;L; 0049 004A;;;;N;LATIN CAPITAL LETTER I J;;;0133; 0133;LATIN SMALL LIGATURE IJ;Ll;0;L; 0069 006A;;;;N;LATIN SMALL LETTER I J;;0132;;0132 0134;LATIN CAPITAL LETTER J WITH CIRCUMFLEX;Lu;0;L;004A 0302;;;;N;LATIN CAPITAL LETTER J CIRCUMFLEX;;;0135; 0135;LATIN SMALL LETTER J WITH CIRCUMFLEX;Ll;0;L;006A 0302;;;;N;LATIN SMALL LETTER J CIRCUMFLEX;;0134;;0134 0136;LATIN CAPITAL LETTER K WITH CEDILLA;Lu;0;L;004B 0327;;;;N;LATIN CAPITAL LETTER K CEDILLA;;;0137; 0137;LATIN SMALL LETTER K WITH CEDILLA;Ll;0;L;006B 0327;;;;N;LATIN SMALL LETTER K CEDILLA;;0136;;0136 0139;LATIN CAPITAL LETTER L WITH ACUTE;Lu;0;L;004C 0301;;;;N;LATIN CAPITAL LETTER L ACUTE;;;013A; 013A;LATIN SMALL LETTER L WITH ACUTE;Ll;0;L;006C 0301;;;;N;LATIN SMALL LETTER L ACUTE;;0139;;0139 013B;LATIN CAPITAL LETTER L WITH CEDILLA;Lu;0;L;004C 0327;;;;N;LATIN CAPITAL LETTER L CEDILLA;;;013C; 013C;LATIN SMALL LETTER L WITH CEDILLA;Ll;0;L;006C 0327;;;;N;LATIN SMALL LETTER L CEDILLA;;013B;;013B 013D;LATIN CAPITAL LETTER L WITH CARON;Lu;0;L;004C 030C;;;;N;LATIN CAPITAL LETTER L HACEK;;;013E; 013E;LATIN SMALL LETTER L WITH CARON;Ll;0;L;006C 030C;;;;N;LATIN SMALL LETTER L HACEK;;013D;;013D 013F;LATIN CAPITAL LETTER L WITH MIDDLE DOT;Lu;0;L; 004C 00B7;;;;N;;;;0140; 0140;LATIN SMALL LETTER L WITH MIDDLE DOT;Ll;0;L; 006C 00B7;;;;N;;;013F;;013F 0141;LATIN CAPITAL LETTER L WITH STROKE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER L SLASH;;;0142; 0142;LATIN SMALL LETTER L WITH STROKE;Ll;0;L;;;;;N;LATIN SMALL LETTER L SLASH;;0141;;0141 0143;LATIN CAPITAL LETTER N WITH ACUTE;Lu;0;L;004E 0301;;;;N;LATIN CAPITAL LETTER N ACUTE;;;0144; 0144;LATIN SMALL LETTER N WITH ACUTE;Ll;0;L;006E 0301;;;;N;LATIN SMALL LETTER N ACUTE;;0143;;0143 0145;LATIN CAPITAL LETTER N WITH CEDILLA;Lu;0;L;004E 0327;;;;N;LATIN CAPITAL LETTER N CEDILLA;;;0146; 0146;LATIN SMALL LETTER N WITH CEDILLA;Ll;0;L;006E 0327;;;;N;LATIN SMALL LETTER N CEDILLA;;0145;;0145 0147;LATIN CAPITAL LETTER N WITH CARON;Lu;0;L;004E 030C;;;;N;LATIN CAPITAL LETTER N HACEK;;;0148; 0148;LATIN SMALL LETTER N WITH CARON;Ll;0;L;006E 030C;;;;N;LATIN SMALL LETTER N HACEK;;0147;;0147 014A;LATIN CAPITAL LETTER ENG;Lu;0;L;;;;;N;;Sami;;014B; 014B;LATIN SMALL LETTER ENG;Ll;0;L;;;;;N;;Sami;014A;;014A 014C;LATIN CAPITAL LETTER O WITH MACRON;Lu;0;L;004F 0304;;;;N;LATIN CAPITAL LETTER O MACRON;;;014D; 014D;LATIN SMALL LETTER O WITH MACRON;Ll;0;L;006F 0304;;;;N;LATIN SMALL LETTER O MACRON;;014C;;014C 014E;LATIN CAPITAL LETTER O WITH BREVE;Lu;0;L;004F 0306;;;;N;LATIN CAPITAL LETTER O BREVE;;;014F; 014F;LATIN SMALL LETTER O WITH BREVE;Ll;0;L;006F 0306;;;;N;LATIN SMALL LETTER O BREVE;;014E;;014E 0150;LATIN CAPITAL LETTER O WITH DOUBLE ACUTE;Lu;0;L;004F 030B;;;;N;LATIN CAPITAL LETTER O DOUBLE ACUTE;;;0151; 0151;LATIN SMALL LETTER O WITH DOUBLE ACUTE;Ll;0;L;006F 030B;;;;N;LATIN SMALL LETTER O DOUBLE ACUTE;;0150;;0150 0152;LATIN CAPITAL LIGATURE OE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER O E;;;0153; 0153;LATIN SMALL LIGATURE OE;Ll;0;L;;;;;N;LATIN SMALL LETTER O E;;0152;;0152 0154;LATIN CAPITAL LETTER R WITH ACUTE;Lu;0;L;0052 0301;;;;N;LATIN CAPITAL LETTER R ACUTE;;;0155; 0155;LATIN SMALL LETTER R WITH ACUTE;Ll;0;L;0072 0301;;;;N;LATIN SMALL LETTER R ACUTE;;0154;;0154 0156;LATIN CAPITAL LETTER R WITH CEDILLA;Lu;0;L;0052 0327;;;;N;LATIN CAPITAL LETTER R CEDILLA;;;0157; 0157;LATIN SMALL LETTER R WITH CEDILLA;Ll;0;L;0072 0327;;;;N;LATIN SMALL LETTER R CEDILLA;;0156;;0156 0158;LATIN CAPITAL LETTER R WITH CARON;Lu;0;L;0052 030C;;;;N;LATIN CAPITAL LETTER R HACEK;;;0159; 0159;LATIN SMALL LETTER R WITH CARON;Ll;0;L;0072 030C;;;;N;LATIN SMALL LETTER R HACEK;;0158;;0158 015A;LATIN CAPITAL LETTER S WITH ACUTE;Lu;0;L;0053 0301;;;;N;LATIN CAPITAL LETTER S ACUTE;;;015B; 015B;LATIN SMALL LETTER S WITH ACUTE;Ll;0;L;0073 0301;;;;N;LATIN SMALL LETTER S ACUTE;;015A;;015A 015C;LATIN CAPITAL LETTER S WITH CIRCUMFLEX;Lu;0;L;0053 0302;;;;N;LATIN CAPITAL LETTER S CIRCUMFLEX;;;015D; 015D;LATIN SMALL LETTER S WITH CIRCUMFLEX;Ll;0;L;0073 0302;;;;N;LATIN SMALL LETTER S CIRCUMFLEX;;015C;;015C 015E;LATIN CAPITAL LETTER S WITH CEDILLA;Lu;0;L;0053 0327;;;;N;LATIN CAPITAL LETTER S CEDILLA;;;015F; 015F;LATIN SMALL LETTER S WITH CEDILLA;Ll;0;L;0073 0327;;;;N;LATIN SMALL LETTER S CEDILLA;;015E;;015E 0160;LATIN CAPITAL LETTER S WITH CARON;Lu;0;L;0053 030C;;;;N;LATIN CAPITAL LETTER S HACEK;;;0161; 0161;LATIN SMALL LETTER S WITH CARON;Ll;0;L;0073 030C;;;;N;LATIN SMALL LETTER S HACEK;;0160;;0160 0162;LATIN CAPITAL LETTER T WITH CEDILLA;Lu;0;L;0054 0327;;;;N;LATIN CAPITAL LETTER T CEDILLA;;;0163; 0163;LATIN SMALL LETTER T WITH CEDILLA;Ll;0;L;0074 0327;;;;N;LATIN SMALL LETTER T CEDILLA;;0162;;0162 0164;LATIN CAPITAL LETTER T WITH CARON;Lu;0;L;0054 030C;;;;N;LATIN CAPITAL LETTER T HACEK;;;0165; 0165;LATIN SMALL LETTER T WITH CARON;Ll;0;L;0074 030C;;;;N;LATIN SMALL LETTER T HACEK;;0164;;0164 0166;LATIN CAPITAL LETTER T WITH STROKE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER T BAR;;;0167; 0167;LATIN SMALL LETTER T WITH STROKE;Ll;0;L;;;;;N;LATIN SMALL LETTER T BAR;;0166;;0166 0168;LATIN CAPITAL LETTER U WITH TILDE;Lu;0;L;0055 0303;;;;N;LATIN CAPITAL LETTER U TILDE;;;0169; 0169;LATIN SMALL LETTER U WITH TILDE;Ll;0;L;0075 0303;;;;N;LATIN SMALL LETTER U TILDE;;0168;;0168 016A;LATIN CAPITAL LETTER U WITH MACRON;Lu;0;L;0055 0304;;;;N;LATIN CAPITAL LETTER U MACRON;;;016B; 016B;LATIN SMALL LETTER U WITH MACRON;Ll;0;L;0075 0304;;;;N;LATIN SMALL LETTER U MACRON;;016A;;016A 016C;LATIN CAPITAL LETTER U WITH BREVE;Lu;0;L;0055 0306;;;;N;LATIN CAPITAL LETTER U BREVE;;;016D; 016D;LATIN SMALL LETTER U WITH BREVE;Ll;0;L;0075 0306;;;;N;LATIN SMALL LETTER U BREVE;;016C;;016C 016E;LATIN CAPITAL LETTER U WITH RING ABOVE;Lu;0;L;0055 030A;;;;N;LATIN CAPITAL LETTER U RING;;;016F; 016F;LATIN SMALL LETTER U WITH RING ABOVE;Ll;0;L;0075 030A;;;;N;LATIN SMALL LETTER U RING;;016E;;016E 0170;LATIN CAPITAL LETTER U WITH DOUBLE ACUTE;Lu;0;L;0055 030B;;;;N;LATIN CAPITAL LETTER U DOUBLE ACUTE;;;0171; 0171;LATIN SMALL LETTER U WITH DOUBLE ACUTE;Ll;0;L;0075 030B;;;;N;LATIN SMALL LETTER U DOUBLE ACUTE;;0170;;0170 0172;LATIN CAPITAL LETTER U WITH OGONEK;Lu;0;L;0055 0328;;;;N;LATIN CAPITAL LETTER U OGONEK;;;0173; 0173;LATIN SMALL LETTER U WITH OGONEK;Ll;0;L;0075 0328;;;;N;LATIN SMALL LETTER U OGONEK;;0172;;0172 0174;LATIN CAPITAL LETTER W WITH CIRCUMFLEX;Lu;0;L;0057 0302;;;;N;LATIN CAPITAL LETTER W CIRCUMFLEX;;;0175; 0175;LATIN SMALL LETTER W WITH CIRCUMFLEX;Ll;0;L;0077 0302;;;;N;LATIN SMALL LETTER W CIRCUMFLEX;;0174;;0174 0176;LATIN CAPITAL LETTER Y WITH CIRCUMFLEX;Lu;0;L;0059 0302;;;;N;LATIN CAPITAL LETTER Y CIRCUMFLEX;;;0177; 0177;LATIN SMALL LETTER Y WITH CIRCUMFLEX;Ll;0;L;0079 0302;;;;N;LATIN SMALL LETTER Y CIRCUMFLEX;;0176;;0176 0178;LATIN CAPITAL LETTER Y WITH DIAERESIS;Lu;0;L;0059 0308;;;;N;LATIN CAPITAL LETTER Y DIAERESIS;;;00FF; 0179;LATIN CAPITAL LETTER Z WITH ACUTE;Lu;0;L;005A 0301;;;;N;LATIN CAPITAL LETTER Z ACUTE;;;017A; 017A;LATIN SMALL LETTER Z WITH ACUTE;Ll;0;L;007A 0301;;;;N;LATIN SMALL LETTER Z ACUTE;;0179;;0179 017B;LATIN CAPITAL LETTER Z WITH DOT ABOVE;Lu;0;L;005A 0307;;;;N;LATIN CAPITAL LETTER Z DOT;;;017C; 017C;LATIN SMALL LETTER Z WITH DOT ABOVE;Ll;0;L;007A 0307;;;;N;LATIN SMALL LETTER Z DOT;;017B;;017B 017D;LATIN CAPITAL LETTER Z WITH CARON;Lu;0;L;005A 030C;;;;N;LATIN CAPITAL LETTER Z HACEK;;;017E; 017E;LATIN SMALL LETTER Z WITH CARON;Ll;0;L;007A 030C;;;;N;LATIN SMALL LETTER Z HACEK;;017D;;017D 017F;LATIN SMALL LETTER LONG S;Ll;0;L; 0073;;;;N;;;0053;;0053 0181;LATIN CAPITAL LETTER B WITH HOOK;Lu;0;L;;;;;N;LATIN CAPITAL LETTER B HOOK;;;0253; 0182;LATIN CAPITAL LETTER B WITH TOPBAR;Lu;0;L;;;;;N;LATIN CAPITAL LETTER B TOPBAR;;;0183; 0183;LATIN SMALL LETTER B WITH TOPBAR;Ll;0;L;;;;;N;LATIN SMALL LETTER B TOPBAR;;0182;;0182 0184;LATIN CAPITAL LETTER TONE SIX;Lu;0;L;;;;;N;;;;0185; 0185;LATIN SMALL LETTER TONE SIX;Ll;0;L;;;;;N;;;0184;;0184 0186;LATIN CAPITAL LETTER OPEN O;Lu;0;L;;;;;N;;;;0254; 0187;LATIN CAPITAL LETTER C WITH HOOK;Lu;0;L;;;;;N;LATIN CAPITAL LETTER C HOOK;;;0188; 0188;LATIN SMALL LETTER C WITH HOOK;Ll;0;L;;;;;N;LATIN SMALL LETTER C HOOK;;0187;;0187 0189;LATIN CAPITAL LETTER AFRICAN D;Lu;0;L;;;;;N;;;;0256; 018A;LATIN CAPITAL LETTER D WITH HOOK;Lu;0;L;;;;;N;LATIN CAPITAL LETTER D HOOK;;;0257; 018B;LATIN CAPITAL LETTER D WITH TOPBAR;Lu;0;L;;;;;N;LATIN CAPITAL LETTER D TOPBAR;;;018C; 018C;LATIN SMALL LETTER D WITH TOPBAR;Ll;0;L;;;;;N;LATIN SMALL LETTER D TOPBAR;;018B;;018B 018E;LATIN CAPITAL LETTER REVERSED E;Lu;0;L;;;;;N;LATIN CAPITAL LETTER TURNED E;;;0258; 018F;LATIN CAPITAL LETTER SCHWA;Lu;0;L;;;;;N;;;;0259; 0190;LATIN CAPITAL LETTER OPEN E;Lu;0;L;;;;;N;LATIN CAPITAL LETTER EPSILON;;;025B; 0191;LATIN CAPITAL LETTER F WITH HOOK;Lu;0;L;;;;;N;LATIN CAPITAL LETTER F HOOK;;;0192; 0192;LATIN SMALL LETTER F WITH HOOK;Ll;0;L;;;;;N;LATIN SMALL LETTER SCRIPT F;;0191;;0191 0193;LATIN CAPITAL LETTER G WITH HOOK;Lu;0;L;;;;;N;LATIN CAPITAL LETTER G HOOK;;;0260; 0194;LATIN CAPITAL LETTER GAMMA;Lu;0;L;;;;;N;;;;0263; 0196;LATIN CAPITAL LETTER IOTA;Lu;0;L;;;;;N;;;;0269; 0197;LATIN CAPITAL LETTER I WITH STROKE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER BARRED I;;;0268; 0198;LATIN CAPITAL LETTER K WITH HOOK;Lu;0;L;;;;;N;LATIN CAPITAL LETTER K HOOK;;;0199; 0199;LATIN SMALL LETTER K WITH HOOK;Ll;0;L;;;;;N;LATIN SMALL LETTER K HOOK;;0198;;0198 019C;LATIN CAPITAL LETTER TURNED M;Lu;0;L;;;;;N;;;;026F; 019D;LATIN CAPITAL LETTER N WITH LEFT HOOK;Lu;0;L;;;;;N;LATIN CAPITAL LETTER N HOOK;;;0272; 01A0;LATIN CAPITAL LETTER O WITH HORN;Lu;0;L;004F 031B;;;;N;LATIN CAPITAL LETTER O HORN;;;01A1; 01A1;LATIN SMALL LETTER O WITH HORN;Ll;0;L;006F 031B;;;;N;LATIN SMALL LETTER O HORN;;01A0;;01A0 01A2;LATIN CAPITAL LETTER OI;Lu;0;L;;;;;N;LATIN CAPITAL LETTER O I;;;01A3; 01A3;LATIN SMALL LETTER OI;Ll;0;L;;;;;N;LATIN SMALL LETTER O I;;01A2;;01A2 01A4;LATIN CAPITAL LETTER P WITH HOOK;Lu;0;L;;;;;N;LATIN CAPITAL LETTER P HOOK;;;01A5; 01A5;LATIN SMALL LETTER P WITH HOOK;Ll;0;L;;;;;N;LATIN SMALL LETTER P HOOK;;01A4;;01A4 01A7;LATIN CAPITAL LETTER TONE TWO;Lu;0;L;;;;;N;;;;01A8; 01A8;LATIN SMALL LETTER TONE TWO;Ll;0;L;;;;;N;;;01A7;;01A7 01A9;LATIN CAPITAL LETTER ESH;Lu;0;L;;;;;N;;;;0283; 01AC;LATIN CAPITAL LETTER T WITH HOOK;Lu;0;L;;;;;N;LATIN CAPITAL LETTER T HOOK;;;01AD; 01AD;LATIN SMALL LETTER T WITH HOOK;Ll;0;L;;;;;N;LATIN SMALL LETTER T HOOK;;01AC;;01AC 01AE;LATIN CAPITAL LETTER T WITH RETROFLEX HOOK;Lu;0;L;;;;;N;LATIN CAPITAL LETTER T RETROFLEX HOOK;;;0288; 01AF;LATIN CAPITAL LETTER U WITH HORN;Lu;0;L;0055 031B;;;;N;LATIN CAPITAL LETTER U HORN;;;01B0; 01B0;LATIN SMALL LETTER U WITH HORN;Ll;0;L;0075 031B;;;;N;LATIN SMALL LETTER U HORN;;01AF;;01AF 01B1;LATIN CAPITAL LETTER UPSILON;Lu;0;L;;;;;N;;;;028A; 01B2;LATIN CAPITAL LETTER V WITH HOOK;Lu;0;L;;;;;N;LATIN CAPITAL LETTER SCRIPT V;;;028B; 01B3;LATIN CAPITAL LETTER Y WITH HOOK;Lu;0;L;;;;;N;LATIN CAPITAL LETTER Y HOOK;;;01B4; 01B4;LATIN SMALL LETTER Y WITH HOOK;Ll;0;L;;;;;N;LATIN SMALL LETTER Y HOOK;;01B3;;01B3 01B5;LATIN CAPITAL LETTER Z WITH STROKE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER Z BAR;;;01B6; 01B6;LATIN SMALL LETTER Z WITH STROKE;Ll;0;L;;;;;N;LATIN SMALL LETTER Z BAR;;01B5;;01B5 01B7;LATIN CAPITAL LETTER EZH;Lu;0;L;;;;;N;LATIN CAPITAL LETTER YOGH;;;0292; 01B8;LATIN CAPITAL LETTER EZH REVERSED;Lu;0;L;;;;;N;LATIN CAPITAL LETTER REVERSED YOGH;;;01B9; 01B9;LATIN SMALL LETTER EZH REVERSED;Ll;0;L;;;;;N;LATIN SMALL LETTER REVERSED YOGH;;01B8;;01B8 01BC;LATIN CAPITAL LETTER TONE FIVE;Lu;0;L;;;;;N;;;;01BD; 01BD;LATIN SMALL LETTER TONE FIVE;Ll;0;L;;;;;N;;;01BC;;01BC 01C4;LATIN CAPITAL LETTER DZ WITH CARON;Lu;0;L; 0044 017D;;;;N;LATIN CAPITAL LETTER D Z HACEK;;;01C6;01C5 01C5;LATIN CAPITAL LETTER D WITH SMALL LETTER Z WITH CARON;Lt;0;L; 0044 017E;;;;N;LATIN LETTER CAPITAL D SMALL Z HACEK;;01C4;01C6; 01C6;LATIN SMALL LETTER DZ WITH CARON;Ll;0;L; 0064 017E;;;;N;LATIN SMALL LETTER D Z HACEK;;01C4;;01C5 01C7;LATIN CAPITAL LETTER LJ;Lu;0;L; 004C 004A;;;;N;LATIN CAPITAL LETTER L J;;;01C9;01C8 01C8;LATIN CAPITAL LETTER L WITH SMALL LETTER J;Lt;0;L; 004C 006A;;;;N;LATIN LETTER CAPITAL L SMALL J;;01C7;01C9; 01C9;LATIN SMALL LETTER LJ;Ll;0;L; 006C 006A;;;;N;LATIN SMALL LETTER L J;;01C7;;01C8 01CA;LATIN CAPITAL LETTER NJ;Lu;0;L; 004E 004A;;;;N;LATIN CAPITAL LETTER N J;;;01CC;01CB 01CB;LATIN CAPITAL LETTER N WITH SMALL LETTER J;Lt;0;L; 004E 006A;;;;N;LATIN LETTER CAPITAL N SMALL J;;01CA;01CC; 01CC;LATIN SMALL LETTER NJ;Ll;0;L; 006E 006A;;;;N;LATIN SMALL LETTER N J;;01CA;;01CB 01CD;LATIN CAPITAL LETTER A WITH CARON;Lu;0;L;0041 030C;;;;N;LATIN CAPITAL LETTER A HACEK;;;01CE; 01CE;LATIN SMALL LETTER A WITH CARON;Ll;0;L;0061 030C;;;;N;LATIN SMALL LETTER A HACEK;;01CD;;01CD 01CF;LATIN CAPITAL LETTER I WITH CARON;Lu;0;L;0049 030C;;;;N;LATIN CAPITAL LETTER I HACEK;;;01D0; 01D0;LATIN SMALL LETTER I WITH CARON;Ll;0;L;0069 030C;;;;N;LATIN SMALL LETTER I HACEK;;01CF;;01CF 01D1;LATIN CAPITAL LETTER O WITH CARON;Lu;0;L;004F 030C;;;;N;LATIN CAPITAL LETTER O HACEK;;;01D2; 01D2;LATIN SMALL LETTER O WITH CARON;Ll;0;L;006F 030C;;;;N;LATIN SMALL LETTER O HACEK;;01D1;;01D1 01D3;LATIN CAPITAL LETTER U WITH CARON;Lu;0;L;0055 030C;;;;N;LATIN CAPITAL LETTER U HACEK;;;01D4; 01D4;LATIN SMALL LETTER U WITH CARON;Ll;0;L;0075 030C;;;;N;LATIN SMALL LETTER U HACEK;;01D3;;01D3 01D5;LATIN CAPITAL LETTER U WITH DIAERESIS AND MACRON;Lu;0;L;00DC 0304;;;;N;LATIN CAPITAL LETTER U DIAERESIS MACRON;;;01D6; 01D6;LATIN SMALL LETTER U WITH DIAERESIS AND MACRON;Ll;0;L;00FC 0304;;;;N;LATIN SMALL LETTER U DIAERESIS MACRON;;01D5;;01D5 01D7;LATIN CAPITAL LETTER U WITH DIAERESIS AND ACUTE;Lu;0;L;00DC 0301;;;;N;LATIN CAPITAL LETTER U DIAERESIS ACUTE;;;01D8; 01D8;LATIN SMALL LETTER U WITH DIAERESIS AND ACUTE;Ll;0;L;00FC 0301;;;;N;LATIN SMALL LETTER U DIAERESIS ACUTE;;01D7;;01D7 01D9;LATIN CAPITAL LETTER U WITH DIAERESIS AND CARON;Lu;0;L;00DC 030C;;;;N;LATIN CAPITAL LETTER U DIAERESIS HACEK;;;01DA; 01DA;LATIN SMALL LETTER U WITH DIAERESIS AND CARON;Ll;0;L;00FC 030C;;;;N;LATIN SMALL LETTER U DIAERESIS HACEK;;01D9;;01D9 01DB;LATIN CAPITAL LETTER U WITH DIAERESIS AND GRAVE;Lu;0;L;00DC 0300;;;;N;LATIN CAPITAL LETTER U DIAERESIS GRAVE;;;01DC; 01DC;LATIN SMALL LETTER U WITH DIAERESIS AND GRAVE;Ll;0;L;00FC 0300;;;;N;LATIN SMALL LETTER U DIAERESIS GRAVE;;01DB;;01DB 01DE;LATIN CAPITAL LETTER A WITH DIAERESIS AND MACRON;Lu;0;L;00C4 0304;;;;N;LATIN CAPITAL LETTER A DIAERESIS MACRON;;;01DF; 01DF;LATIN SMALL LETTER A WITH DIAERESIS AND MACRON;Ll;0;L;00E4 0304;;;;N;LATIN SMALL LETTER A DIAERESIS MACRON;;01DE;;01DE 01E0;LATIN CAPITAL LETTER A WITH DOT ABOVE AND MACRON;Lu;0;L;0041 0307 0304;;;;N;LATIN CAPITAL LETTER A DOT MACRON;;;01E1; 01E1;LATIN SMALL LETTER A WITH DOT ABOVE AND MACRON;Ll;0;L;0061 0307 0304;;;;N;LATIN SMALL LETTER A DOT MACRON;;01E0;;01E0 01E2;LATIN CAPITAL LETTER AE WITH MACRON;Lu;0;L;00C6 0304;;;;N;LATIN CAPITAL LETTER A E MACRON;;;01E3; 01E3;LATIN SMALL LETTER AE WITH MACRON;Ll;0;L;00E6 0304;;;;N;LATIN SMALL LETTER A E MACRON;;01E2;;01E2 01E4;LATIN CAPITAL LETTER G WITH STROKE;Lu;0;L;;;;;N;LATIN CAPITAL LETTER G BAR;;;01E5; 01E5;LATIN SMALL LETTER G WITH STROKE;Ll;0;L;;;;;N;LATIN SMALL LETTER G BAR;;01E4;;01E4 01E6;LATIN CAPITAL LETTER G WITH CARON;Lu;0;L;0047 030C;;;;N;LATIN CAPITAL LETTER G HACEK;;;01E7; 01E7;LATIN SMALL LETTER G WITH CARON;Ll;0;L;0067 030C;;;;N;LATIN SMALL LETTER G HACEK;;01E6;;01E6 01E8;LATIN CAPITAL LETTER K WITH CARON;Lu;0;L;004B 030C;;;;N;LATIN CAPITAL LETTER K HACEK;;;01E9; 01E9;LATIN SMALL LETTER K WITH CARON;Ll;0;L;006B 030C;;;;N;LATIN SMALL LETTER K HACEK;;01E8;;01E8 01EA;LATIN CAPITAL LETTER O WITH OGONEK;Lu;0;L;004F 0328;;;;N;LATIN CAPITAL LETTER O OGONEK;;;01EB; 01EB;LATIN SMALL LETTER O WITH OGONEK;Ll;0;L;006F 0328;;;;N;LATIN SMALL LETTER O OGONEK;;01EA;;01EA 01EC;LATIN CAPITAL LETTER O WITH OGONEK AND MACRON;Lu;0;L;01EA 0304;;;;N;LATIN CAPITAL LETTER O OGONEK MACRON;;;01ED; 01ED;LATIN SMALL LETTER O WITH OGONEK AND MACRON;Ll;0;L;01EB 0304;;;;N;LATIN SMALL LETTER O OGONEK MACRON;;01EC;;01EC 01EE;LATIN CAPITAL LETTER EZH WITH CARON;Lu;0;L;01B7 030C;;;;N;LATIN CAPITAL LETTER YOGH HACEK;;;01EF; 01EF;LATIN SMALL LETTER EZH WITH CARON;Ll;0;L;0292 030C;;;;N;LATIN SMALL LETTER YOGH HACEK;;01EE;;01EE 01F1;LATIN CAPITAL LETTER DZ;Lu;0;L; 0044 005A;;;;N;;;;01F3;01F2 01F2;LATIN CAPITAL LETTER D WITH SMALL LETTER Z;Lt;0;L; 0044 007A;;;;N;;;01F1;01F3; 01F3;LATIN SMALL LETTER DZ;Ll;0;L; 0064 007A;;;;N;;;01F1;;01F2 01F4;LATIN CAPITAL LETTER G WITH ACUTE;Lu;0;L;0047 0301;;;;N;;;;01F5; 01F5;LATIN SMALL LETTER G WITH ACUTE;Ll;0;L;0067 0301;;;;N;;;01F4;;01F4 01FA;LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE;Lu;0;L;00C5 0301;;;;N;;;;01FB; 01FB;LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE;Ll;0;L;00E5 0301;;;;N;;;01FA;;01FA 01FC;LATIN CAPITAL LETTER AE WITH ACUTE;Lu;0;L;00C6 0301;;;;N;;;;01FD; 01FD;LATIN SMALL LETTER AE WITH ACUTE;Ll;0;L;00E6 0301;;;;N;;;01FC;;01FC 01FE;LATIN CAPITAL LETTER O WITH STROKE AND ACUTE;Lu;0;L;00D8 0301;;;;N;;;;01FF; 01FF;LATIN SMALL LETTER O WITH STROKE AND ACUTE;Ll;0;L;00F8 0301;;;;N;;;01FE;;01FE 0200;LATIN CAPITAL LETTER A WITH DOUBLE GRAVE;Lu;0;L;0041 030F;;;;N;;;;0201; 0201;LATIN SMALL LETTER A WITH DOUBLE GRAVE;Ll;0;L;0061 030F;;;;N;;;0200;;0200 0202;LATIN CAPITAL LETTER A WITH INVERTED BREVE;Lu;0;L;0041 0311;;;;N;;;;0203; 0203;LATIN SMALL LETTER A WITH INVERTED BREVE;Ll;0;L;0061 0311;;;;N;;;0202;;0202 0204;LATIN CAPITAL LETTER E WITH DOUBLE GRAVE;Lu;0;L;0045 030F;;;;N;;;;0205; 0205;LATIN SMALL LETTER E WITH DOUBLE GRAVE;Ll;0;L;0065 030F;;;;N;;;0204;;0204 0206;LATIN CAPITAL LETTER E WITH INVERTED BREVE;Lu;0;L;0045 0311;;;;N;;;;0207; 0207;LATIN SMALL LETTER E WITH INVERTED BREVE;Ll;0;L;0065 0311;;;;N;;;0206;;0206 0208;LATIN CAPITAL LETTER I WITH DOUBLE GRAVE;Lu;0;L;0049 030F;;;;N;;;;0209; 0209;LATIN SMALL LETTER I WITH DOUBLE GRAVE;Ll;0;L;0069 030F;;;;N;;;0208;;0208 020A;LATIN CAPITAL LETTER I WITH INVERTED BREVE;Lu;0;L;0049 0311;;;;N;;;;020B; 020B;LATIN SMALL LETTER I WITH INVERTED BREVE;Ll;0;L;0069 0311;;;;N;;;020A;;020A 020C;LATIN CAPITAL LETTER O WITH DOUBLE GRAVE;Lu;0;L;004F 030F;;;;N;;;;020D; 020D;LATIN SMALL LETTER O WITH DOUBLE GRAVE;Ll;0;L;006F 030F;;;;N;;;020C;;020C 020E;LATIN CAPITAL LETTER O WITH INVERTED BREVE;Lu;0;L;004F 0311;;;;N;;;;020F; 020F;LATIN SMALL LETTER O WITH INVERTED BREVE;Ll;0;L;006F 0311;;;;N;;;020E;;020E 0210;LATIN CAPITAL LETTER R WITH DOUBLE GRAVE;Lu;0;L;0052 030F;;;;N;;;;0211; 0211;LATIN SMALL LETTER R WITH DOUBLE GRAVE;Ll;0;L;0072 030F;;;;N;;;0210;;0210 0212;LATIN CAPITAL LETTER R WITH INVERTED BREVE;Lu;0;L;0052 0311;;;;N;;;;0213; 0213;LATIN SMALL LETTER R WITH INVERTED BREVE;Ll;0;L;0072 0311;;;;N;;;0212;;0212 0214;LATIN CAPITAL LETTER U WITH DOUBLE GRAVE;Lu;0;L;0055 030F;;;;N;;;;0215; 0215;LATIN SMALL LETTER U WITH DOUBLE GRAVE;Ll;0;L;0075 030F;;;;N;;;0214;;0214 0216;LATIN CAPITAL LETTER U WITH INVERTED BREVE;Lu;0;L;0055 0311;;;;N;;;;0217; 0217;LATIN SMALL LETTER U WITH INVERTED BREVE;Ll;0;L;0075 0311;;;;N;;;0216;;0216 0253;LATIN SMALL LETTER B WITH HOOK;Ll;0;L;;;;;N;LATIN SMALL LETTER B HOOK;;0181;;0181 0254;LATIN SMALL LETTER OPEN O;Ll;0;L;;;;;N;;;0186;;0186 0256;LATIN SMALL LETTER D WITH TAIL;Ll;0;L;;;;;N;LATIN SMALL LETTER D RETROFLEX HOOK;;0189;;0189 0257;LATIN SMALL LETTER D WITH HOOK;Ll;0;L;;;;;N;LATIN SMALL LETTER D HOOK;;018A;;018A 0258;LATIN SMALL LETTER REVERSED E;Ll;0;L;;;;;N;;;018E;;018E 0259;LATIN SMALL LETTER SCHWA;Ll;0;L;;;;;N;;;018F;;018F 025B;LATIN SMALL LETTER OPEN E;Ll;0;L;;;;;N;LATIN SMALL LETTER EPSILON;;0190;;0190 0260;LATIN SMALL LETTER G WITH HOOK;Ll;0;L;;;;;N;LATIN SMALL LETTER G HOOK;;0193;;0193 0263;LATIN SMALL LETTER GAMMA;Ll;0;L;;;;;N;;;0194;;0194 0268;LATIN SMALL LETTER I WITH STROKE;Ll;0;L;;;;;N;LATIN SMALL LETTER BARRED I;;0197;;0197 0269;LATIN SMALL LETTER IOTA;Ll;0;L;;;;;N;;;0196;;0196 026F;LATIN SMALL LETTER TURNED M;Ll;0;L;;;;;N;;;019C;;019C 0272;LATIN SMALL LETTER N WITH LEFT HOOK;Ll;0;L;;;;;N;LATIN SMALL LETTER N HOOK;;019D;;019D 0283;LATIN SMALL LETTER ESH;Ll;0;L;;;;;N;;;01A9;;01A9 0288;LATIN SMALL LETTER T WITH RETROFLEX HOOK;Ll;0;L;;;;;N;LATIN SMALL LETTER T RETROFLEX HOOK;;01AE;;01AE 028A;LATIN SMALL LETTER UPSILON;Ll;0;L;;;;;N;;;01B1;;01B1 028B;LATIN SMALL LETTER V WITH HOOK;Ll;0;L;;;;;N;LATIN SMALL LETTER SCRIPT V;;01B2;;01B2 0292;LATIN SMALL LETTER EZH;Ll;0;L;;;;;N;LATIN SMALL LETTER YOGH;;01B7;;01B7 0386;GREEK CAPITAL LETTER ALPHA WITH TONOS;Lu;0;L;0391 030D;;;;N;GREEK CAPITAL LETTER ALPHA TONOS;;;03AC; 0388;GREEK CAPITAL LETTER EPSILON WITH TONOS;Lu;0;L;0395 030D;;;;N;GREEK CAPITAL LETTER EPSILON TONOS;;;03AD; 0389;GREEK CAPITAL LETTER ETA WITH TONOS;Lu;0;L;0397 030D;;;;N;GREEK CAPITAL LETTER ETA TONOS;;;03AE; 038A;GREEK CAPITAL LETTER IOTA WITH TONOS;Lu;0;L;0399 030D;;;;N;GREEK CAPITAL LETTER IOTA TONOS;;;03AF; 038C;GREEK CAPITAL LETTER OMICRON WITH TONOS;Lu;0;L;039F 030D;;;;N;GREEK CAPITAL LETTER OMICRON TONOS;;;03CC; 038E;GREEK CAPITAL LETTER UPSILON WITH TONOS;Lu;0;L;03A5 030D;;;;N;GREEK CAPITAL LETTER UPSILON TONOS;;;03CD; 038F;GREEK CAPITAL LETTER OMEGA WITH TONOS;Lu;0;L;03A9 030D;;;;N;GREEK CAPITAL LETTER OMEGA TONOS;;;03CE; 0391;GREEK CAPITAL LETTER ALPHA;Lu;0;L;;;;;N;;;;03B1; 0392;GREEK CAPITAL LETTER BETA;Lu;0;L;;;;;N;;;;03B2; 0393;GREEK CAPITAL LETTER GAMMA;Lu;0;L;;;;;N;;;;03B3; 0394;GREEK CAPITAL LETTER DELTA;Lu;0;L;;;;;N;;;;03B4; 0395;GREEK CAPITAL LETTER EPSILON;Lu;0;L;;;;;N;;;;03B5; 0396;GREEK CAPITAL LETTER ZETA;Lu;0;L;;;;;N;;;;03B6; 0397;GREEK CAPITAL LETTER ETA;Lu;0;L;;;;;N;;;;03B7; 0398;GREEK CAPITAL LETTER THETA;Lu;0;L;;;;;N;;;;03B8; 0399;GREEK CAPITAL LETTER IOTA;Lu;0;L;;;;;N;;;;03B9; 039A;GREEK CAPITAL LETTER KAPPA;Lu;0;L;;;;;N;;;;03BA; 039B;GREEK CAPITAL LETTER LAMDA;Lu;0;L;;;;;N;GREEK CAPITAL LETTER LAMBDA;;;03BB; 039C;GREEK CAPITAL LETTER MU;Lu;0;L;;;;;N;;;;03BC; 039D;GREEK CAPITAL LETTER NU;Lu;0;L;;;;;N;;;;03BD; 039E;GREEK CAPITAL LETTER XI;Lu;0;L;;;;;N;;;;03BE; 039F;GREEK CAPITAL LETTER OMICRON;Lu;0;L;;;;;N;;;;03BF; 03A0;GREEK CAPITAL LETTER PI;Lu;0;L;;;;;N;;;;03C0; 03A1;GREEK CAPITAL LETTER RHO;Lu;0;L;;;;;N;;;;03C1; 03A3;GREEK CAPITAL LETTER SIGMA;Lu;0;L;;;;;N;;;;03C3; 03A4;GREEK CAPITAL LETTER TAU;Lu;0;L;;;;;N;;;;03C4; 03A5;GREEK CAPITAL LETTER UPSILON;Lu;0;L;;;;;N;;;;03C5; 03A6;GREEK CAPITAL LETTER PHI;Lu;0;L;;;;;N;;;;03C6; 03A7;GREEK CAPITAL LETTER CHI;Lu;0;L;;;;;N;;;;03C7; 03A8;GREEK CAPITAL LETTER PSI;Lu;0;L;;;;;N;;;;03C8; 03A9;GREEK CAPITAL LETTER OMEGA;Lu;0;L;;;;;N;;;;03C9; 03AA;GREEK CAPITAL LETTER IOTA WITH DIALYTIKA;Lu;0;L;0399 0308;;;;N;GREEK CAPITAL LETTER IOTA DIAERESIS;;;03CA; 03AB;GREEK CAPITAL LETTER UPSILON WITH DIALYTIKA;Lu;0;L;03A5 0308;;;;N;GREEK CAPITAL LETTER UPSILON DIAERESIS;;;03CB; 03AC;GREEK SMALL LETTER ALPHA WITH TONOS;Ll;0;L;03B1 030D;;;;N;GREEK SMALL LETTER ALPHA TONOS;;0386;;0386 03AD;GREEK SMALL LETTER EPSILON WITH TONOS;Ll;0;L;03B5 030D;;;;N;GREEK SMALL LETTER EPSILON TONOS;;0388;;0388 03AE;GREEK SMALL LETTER ETA WITH TONOS;Ll;0;L;03B7 030D;;;;N;GREEK SMALL LETTER ETA TONOS;;0389;;0389 03AF;GREEK SMALL LETTER IOTA WITH TONOS;Ll;0;L;03B9 030D;;;;N;GREEK SMALL LETTER IOTA TONOS;;038A;;038A 03B1;GREEK SMALL LETTER ALPHA;Ll;0;L;;;;;N;;;0391;;0391 03B2;GREEK SMALL LETTER BETA;Ll;0;L;;;;;N;;;0392;;0392 03B3;GREEK SMALL LETTER GAMMA;Ll;0;L;;;;;N;;;0393;;0393 03B4;GREEK SMALL LETTER DELTA;Ll;0;L;;;;;N;;;0394;;0394 03B5;GREEK SMALL LETTER EPSILON;Ll;0;L;;;;;N;;;0395;;0395 03B6;GREEK SMALL LETTER ZETA;Ll;0;L;;;;;N;;;0396;;0396 03B7;GREEK SMALL LETTER ETA;Ll;0;L;;;;;N;;;0397;;0397 03B8;GREEK SMALL LETTER THETA;Ll;0;L;;;;;N;;;0398;;0398 03B9;GREEK SMALL LETTER IOTA;Ll;0;L;;;;;N;;;0399;;0399 03BA;GREEK SMALL LETTER KAPPA;Ll;0;L;;;;;N;;;039A;;039A 03BB;GREEK SMALL LETTER LAMDA;Ll;0;L;;;;;N;GREEK SMALL LETTER LAMBDA;;039B;;039B 03BC;GREEK SMALL LETTER MU;Ll;0;L;;;;;N;;;039C;;039C 03BD;GREEK SMALL LETTER NU;Ll;0;L;;;;;N;;;039D;;039D 03BE;GREEK SMALL LETTER XI;Ll;0;L;;;;;N;;;039E;;039E 03BF;GREEK SMALL LETTER OMICRON;Ll;0;L;;;;;N;;;039F;;039F 03C0;GREEK SMALL LETTER PI;Ll;0;L;;;;;N;;;03A0;;03A0 03C1;GREEK SMALL LETTER RHO;Ll;0;L;;;;;N;;;03A1;;03A1 03C3;GREEK SMALL LETTER SIGMA;Ll;0;L;;;;;N;;;03A3;;03A3 03C4;GREEK SMALL LETTER TAU;Ll;0;L;;;;;N;;;03A4;;03A4 03C5;GREEK SMALL LETTER UPSILON;Ll;0;L;;;;;N;;;03A5;;03A5 03C6;GREEK SMALL LETTER PHI;Ll;0;L;;;;;N;;;03A6;;03A6 03C7;GREEK SMALL LETTER CHI;Ll;0;L;;;;;N;;;03A7;;03A7 03C8;GREEK SMALL LETTER PSI;Ll;0;L;;;;;N;;;03A8;;03A8 03C9;GREEK SMALL LETTER OMEGA;Ll;0;L;;;;;N;;;03A9;;03A9 03CA;GREEK SMALL LETTER IOTA WITH DIALYTIKA;Ll;0;L;03B9 0308;;;;N;GREEK SMALL LETTER IOTA DIAERESIS;;03AA;;03AA 03CB;GREEK SMALL LETTER UPSILON WITH DIALYTIKA;Ll;0;L;03C5 0308;;;;N;GREEK SMALL LETTER UPSILON DIAERESIS;;03AB;;03AB 03CC;GREEK SMALL LETTER OMICRON WITH TONOS;Ll;0;L;03BF 030D;;;;N;GREEK SMALL LETTER OMICRON TONOS;;038C;;038C 03CD;GREEK SMALL LETTER UPSILON WITH TONOS;Ll;0;L;03C5 030D;;;;N;GREEK SMALL LETTER UPSILON TONOS;;038E;;038E 03CE;GREEK SMALL LETTER OMEGA WITH TONOS;Ll;0;L;03C9 030D;;;;N;GREEK SMALL LETTER OMEGA TONOS;;038F;;038F 03E2;COPTIC CAPITAL LETTER SHEI;Lu;0;L;;;;;N;GREEK CAPITAL LETTER SHEI;;;03E3; 03E3;COPTIC SMALL LETTER SHEI;Ll;0;L;;;;;N;GREEK SMALL LETTER SHEI;;03E2;;03E2 03E4;COPTIC CAPITAL LETTER FEI;Lu;0;L;;;;;N;GREEK CAPITAL LETTER FEI;;;03E5; 03E5;COPTIC SMALL LETTER FEI;Ll;0;L;;;;;N;GREEK SMALL LETTER FEI;;03E4;;03E4 03E6;COPTIC CAPITAL LETTER KHEI;Lu;0;L;;;;;N;GREEK CAPITAL LETTER KHEI;;;03E7; 03E7;COPTIC SMALL LETTER KHEI;Ll;0;L;;;;;N;GREEK SMALL LETTER KHEI;;03E6;;03E6 03E8;COPTIC CAPITAL LETTER HORI;Lu;0;L;;;;;N;GREEK CAPITAL LETTER HORI;;;03E9; 03E9;COPTIC SMALL LETTER HORI;Ll;0;L;;;;;N;GREEK SMALL LETTER HORI;;03E8;;03E8 03EA;COPTIC CAPITAL LETTER GANGIA;Lu;0;L;;;;;N;GREEK CAPITAL LETTER GANGIA;;;03EB; 03EB;COPTIC SMALL LETTER GANGIA;Ll;0;L;;;;;N;GREEK SMALL LETTER GANGIA;;03EA;;03EA 03EC;COPTIC CAPITAL LETTER SHIMA;Lu;0;L;;;;;N;GREEK CAPITAL LETTER SHIMA;;;03ED; 03ED;COPTIC SMALL LETTER SHIMA;Ll;0;L;;;;;N;GREEK SMALL LETTER SHIMA;;03EC;;03EC 03EE;COPTIC CAPITAL LETTER DEI;Lu;0;L;;;;;N;GREEK CAPITAL LETTER DEI;;;03EF; 03EF;COPTIC SMALL LETTER DEI;Ll;0;L;;;;;N;GREEK SMALL LETTER DEI;;03EE;;03EE 0401;CYRILLIC CAPITAL LETTER IO;Lu;0;L;0415 0308;;;;N;;;;0451; 0402;CYRILLIC CAPITAL LETTER DJE;Lu;0;L;;;;;N;;Serbocroatian;;0452; 0403;CYRILLIC CAPITAL LETTER GJE;Lu;0;L;0413 0301;;;;N;;;;0453; 0404;CYRILLIC CAPITAL LETTER UKRAINIAN IE;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER E;;;0454; 0405;CYRILLIC CAPITAL LETTER DZE;Lu;0;L;;;;;N;;;;0455; 0406;CYRILLIC CAPITAL LETTER BYELORUSSIAN-UKRAINIAN I;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER I;;;0456; 0407;CYRILLIC CAPITAL LETTER YI;Lu;0;L;0406 0308;;;;N;;Ukrainian;;0457; 0408;CYRILLIC CAPITAL LETTER JE;Lu;0;L;;;;;N;;;;0458; 0409;CYRILLIC CAPITAL LETTER LJE;Lu;0;L;;;;;N;;;;0459; 040A;CYRILLIC CAPITAL LETTER NJE;Lu;0;L;;;;;N;;;;045A; 040B;CYRILLIC CAPITAL LETTER TSHE;Lu;0;L;;;;;N;;Serbocroatian;;045B; 040C;CYRILLIC CAPITAL LETTER KJE;Lu;0;L;041A 0301;;;;N;;;;045C; 040E;CYRILLIC CAPITAL LETTER SHORT U;Lu;0;L;0423 0306;;;;N;;Byelorussian;;045E; 040F;CYRILLIC CAPITAL LETTER DZHE;Lu;0;L;;;;;N;;;;045F; 0410;CYRILLIC CAPITAL LETTER A;Lu;0;L;;;;;N;;;;0430; 0411;CYRILLIC CAPITAL LETTER BE;Lu;0;L;;;;;N;;;;0431; 0412;CYRILLIC CAPITAL LETTER VE;Lu;0;L;;;;;N;;;;0432; 0413;CYRILLIC CAPITAL LETTER GHE;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER GE;;;0433; 0414;CYRILLIC CAPITAL LETTER DE;Lu;0;L;;;;;N;;;;0434; 0415;CYRILLIC CAPITAL LETTER IE;Lu;0;L;;;;;N;;;;0435; 0416;CYRILLIC CAPITAL LETTER ZHE;Lu;0;L;;;;;N;;;;0436; 0417;CYRILLIC CAPITAL LETTER ZE;Lu;0;L;;;;;N;;;;0437; 0418;CYRILLIC CAPITAL LETTER I;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER II;;;0438; 0419;CYRILLIC CAPITAL LETTER SHORT I;Lu;0;L;0418 0306;;;;N;CYRILLIC CAPITAL LETTER SHORT II;;;0439; 041A;CYRILLIC CAPITAL LETTER KA;Lu;0;L;;;;;N;;;;043A; 041B;CYRILLIC CAPITAL LETTER EL;Lu;0;L;;;;;N;;;;043B; 041C;CYRILLIC CAPITAL LETTER EM;Lu;0;L;;;;;N;;;;043C; 041D;CYRILLIC CAPITAL LETTER EN;Lu;0;L;;;;;N;;;;043D; 041E;CYRILLIC CAPITAL LETTER O;Lu;0;L;;;;;N;;;;043E; 041F;CYRILLIC CAPITAL LETTER PE;Lu;0;L;;;;;N;;;;043F; 0420;CYRILLIC CAPITAL LETTER ER;Lu;0;L;;;;;N;;;;0440; 0421;CYRILLIC CAPITAL LETTER ES;Lu;0;L;;;;;N;;;;0441; 0422;CYRILLIC CAPITAL LETTER TE;Lu;0;L;;;;;N;;;;0442; 0423;CYRILLIC CAPITAL LETTER U;Lu;0;L;;;;;N;;;;0443; 0424;CYRILLIC CAPITAL LETTER EF;Lu;0;L;;;;;N;;;;0444; 0425;CYRILLIC CAPITAL LETTER HA;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER KHA;;;0445; 0426;CYRILLIC CAPITAL LETTER TSE;Lu;0;L;;;;;N;;;;0446; 0427;CYRILLIC CAPITAL LETTER CHE;Lu;0;L;;;;;N;;;;0447; 0428;CYRILLIC CAPITAL LETTER SHA;Lu;0;L;;;;;N;;;;0448; 0429;CYRILLIC CAPITAL LETTER SHCHA;Lu;0;L;;;;;N;;;;0449; 042A;CYRILLIC CAPITAL LETTER HARD SIGN;Lu;0;L;;;;;N;;;;044A; 042B;CYRILLIC CAPITAL LETTER YERU;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER YERI;;;044B; 042C;CYRILLIC CAPITAL LETTER SOFT SIGN;Lu;0;L;;;;;N;;;;044C; 042D;CYRILLIC CAPITAL LETTER E;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER REVERSED E;;;044D; 042E;CYRILLIC CAPITAL LETTER YU;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER IU;;;044E; 042F;CYRILLIC CAPITAL LETTER YA;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER IA;;;044F; 0430;CYRILLIC SMALL LETTER A;Ll;0;L;;;;;N;;;0410;;0410 0431;CYRILLIC SMALL LETTER BE;Ll;0;L;;;;;N;;;0411;;0411 0432;CYRILLIC SMALL LETTER VE;Ll;0;L;;;;;N;;;0412;;0412 0433;CYRILLIC SMALL LETTER GHE;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER GE;;0413;;0413 0434;CYRILLIC SMALL LETTER DE;Ll;0;L;;;;;N;;;0414;;0414 0435;CYRILLIC SMALL LETTER IE;Ll;0;L;;;;;N;;;0415;;0415 0436;CYRILLIC SMALL LETTER ZHE;Ll;0;L;;;;;N;;;0416;;0416 0437;CYRILLIC SMALL LETTER ZE;Ll;0;L;;;;;N;;;0417;;0417 0438;CYRILLIC SMALL LETTER I;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER II;;0418;;0418 0439;CYRILLIC SMALL LETTER SHORT I;Ll;0;L;0438 0306;;;;N;CYRILLIC SMALL LETTER SHORT II;;0419;;0419 043A;CYRILLIC SMALL LETTER KA;Ll;0;L;;;;;N;;;041A;;041A 043B;CYRILLIC SMALL LETTER EL;Ll;0;L;;;;;N;;;041B;;041B 043C;CYRILLIC SMALL LETTER EM;Ll;0;L;;;;;N;;;041C;;041C 043D;CYRILLIC SMALL LETTER EN;Ll;0;L;;;;;N;;;041D;;041D 043E;CYRILLIC SMALL LETTER O;Ll;0;L;;;;;N;;;041E;;041E 043F;CYRILLIC SMALL LETTER PE;Ll;0;L;;;;;N;;;041F;;041F 0440;CYRILLIC SMALL LETTER ER;Ll;0;L;;;;;N;;;0420;;0420 0441;CYRILLIC SMALL LETTER ES;Ll;0;L;;;;;N;;;0421;;0421 0442;CYRILLIC SMALL LETTER TE;Ll;0;L;;;;;N;;;0422;;0422 0443;CYRILLIC SMALL LETTER U;Ll;0;L;;;;;N;;;0423;;0423 0444;CYRILLIC SMALL LETTER EF;Ll;0;L;;;;;N;;;0424;;0424 0445;CYRILLIC SMALL LETTER HA;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER KHA;;0425;;0425 0446;CYRILLIC SMALL LETTER TSE;Ll;0;L;;;;;N;;;0426;;0426 0447;CYRILLIC SMALL LETTER CHE;Ll;0;L;;;;;N;;;0427;;0427 0448;CYRILLIC SMALL LETTER SHA;Ll;0;L;;;;;N;;;0428;;0428 0449;CYRILLIC SMALL LETTER SHCHA;Ll;0;L;;;;;N;;;0429;;0429 044A;CYRILLIC SMALL LETTER HARD SIGN;Ll;0;L;;;;;N;;;042A;;042A 044B;CYRILLIC SMALL LETTER YERU;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER YERI;;042B;;042B 044C;CYRILLIC SMALL LETTER SOFT SIGN;Ll;0;L;;;;;N;;;042C;;042C 044D;CYRILLIC SMALL LETTER E;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER REVERSED E;;042D;;042D 044E;CYRILLIC SMALL LETTER YU;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER IU;;042E;;042E 044F;CYRILLIC SMALL LETTER YA;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER IA;;042F;;042F 0451;CYRILLIC SMALL LETTER IO;Ll;0;L;0435 0308;;;;N;;;0401;;0401 0452;CYRILLIC SMALL LETTER DJE;Ll;0;L;;;;;N;;Serbocroatian;0402;;0402 0453;CYRILLIC SMALL LETTER GJE;Ll;0;L;0433 0301;;;;N;;;0403;;0403 0454;CYRILLIC SMALL LETTER UKRAINIAN IE;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER E;;0404;;0404 0455;CYRILLIC SMALL LETTER DZE;Ll;0;L;;;;;N;;;0405;;0405 0456;CYRILLIC SMALL LETTER BYELORUSSIAN-UKRAINIAN I;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER I;;0406;;0406 0457;CYRILLIC SMALL LETTER YI;Ll;0;L;0456 0308;;;;N;;Ukrainian;0407;;0407 0458;CYRILLIC SMALL LETTER JE;Ll;0;L;;;;;N;;;0408;;0408 0459;CYRILLIC SMALL LETTER LJE;Ll;0;L;;;;;N;;;0409;;0409 045A;CYRILLIC SMALL LETTER NJE;Ll;0;L;;;;;N;;;040A;;040A 045B;CYRILLIC SMALL LETTER TSHE;Ll;0;L;;;;;N;;Serbocroatian;040B;;040B 045C;CYRILLIC SMALL LETTER KJE;Ll;0;L;043A 0301;;;;N;;;040C;;040C 045E;CYRILLIC SMALL LETTER SHORT U;Ll;0;L;0443 0306;;;;N;;Byelorussian;040E;;040E 045F;CYRILLIC SMALL LETTER DZHE;Ll;0;L;;;;;N;;;040F;;040F 0460;CYRILLIC CAPITAL LETTER OMEGA;Lu;0;L;;;;;N;;;;0461; 0461;CYRILLIC SMALL LETTER OMEGA;Ll;0;L;;;;;N;;;0460;;0460 0462;CYRILLIC CAPITAL LETTER YAT;Lu;0;L;;;;;N;;;;0463; 0463;CYRILLIC SMALL LETTER YAT;Ll;0;L;;;;;N;;;0462;;0462 0464;CYRILLIC CAPITAL LETTER IOTIFIED E;Lu;0;L;;;;;N;;;;0465; 0465;CYRILLIC SMALL LETTER IOTIFIED E;Ll;0;L;;;;;N;;;0464;;0464 0466;CYRILLIC CAPITAL LETTER LITTLE YUS;Lu;0;L;;;;;N;;;;0467; 0467;CYRILLIC SMALL LETTER LITTLE YUS;Ll;0;L;;;;;N;;;0466;;0466 0468;CYRILLIC CAPITAL LETTER IOTIFIED LITTLE YUS;Lu;0;L;;;;;N;;;;0469; 0469;CYRILLIC SMALL LETTER IOTIFIED LITTLE YUS;Ll;0;L;;;;;N;;;0468;;0468 046A;CYRILLIC CAPITAL LETTER BIG YUS;Lu;0;L;;;;;N;;;;046B; 046B;CYRILLIC SMALL LETTER BIG YUS;Ll;0;L;;;;;N;;;046A;;046A 046C;CYRILLIC CAPITAL LETTER IOTIFIED BIG YUS;Lu;0;L;;;;;N;;;;046D; 046D;CYRILLIC SMALL LETTER IOTIFIED BIG YUS;Ll;0;L;;;;;N;;;046C;;046C 046E;CYRILLIC CAPITAL LETTER KSI;Lu;0;L;;;;;N;;;;046F; 046F;CYRILLIC SMALL LETTER KSI;Ll;0;L;;;;;N;;;046E;;046E 0470;CYRILLIC CAPITAL LETTER PSI;Lu;0;L;;;;;N;;;;0471; 0471;CYRILLIC SMALL LETTER PSI;Ll;0;L;;;;;N;;;0470;;0470 0472;CYRILLIC CAPITAL LETTER FITA;Lu;0;L;;;;;N;;;;0473; 0473;CYRILLIC SMALL LETTER FITA;Ll;0;L;;;;;N;;;0472;;0472 0474;CYRILLIC CAPITAL LETTER IZHITSA;Lu;0;L;;;;;N;;;;0475; 0475;CYRILLIC SMALL LETTER IZHITSA;Ll;0;L;;;;;N;;;0474;;0474 0476;CYRILLIC CAPITAL LETTER IZHITSA WITH DOUBLE GRAVE ACCENT;Lu;0;L;0474 030F;;;;N;CYRILLIC CAPITAL LETTER IZHITSA DOUBLE GRAVE;;;0477; 0477;CYRILLIC SMALL LETTER IZHITSA WITH DOUBLE GRAVE ACCENT;Ll;0;L;0475 030F;;;;N;CYRILLIC SMALL LETTER IZHITSA DOUBLE GRAVE;;0476;;0476 0478;CYRILLIC CAPITAL LETTER UK;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER UK DIGRAPH;;;0479; 0479;CYRILLIC SMALL LETTER UK;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER UK DIGRAPH;;0478;;0478 047A;CYRILLIC CAPITAL LETTER ROUND OMEGA;Lu;0;L;;;;;N;;;;047B; 047B;CYRILLIC SMALL LETTER ROUND OMEGA;Ll;0;L;;;;;N;;;047A;;047A 047C;CYRILLIC CAPITAL LETTER OMEGA WITH TITLO;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER OMEGA TITLO;;;047D; 047D;CYRILLIC SMALL LETTER OMEGA WITH TITLO;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER OMEGA TITLO;;047C;;047C 047E;CYRILLIC CAPITAL LETTER OT;Lu;0;L;;;;;N;;;;047F; 047F;CYRILLIC SMALL LETTER OT;Ll;0;L;;;;;N;;;047E;;047E 0480;CYRILLIC CAPITAL LETTER KOPPA;Lu;0;L;;;;;N;;;;0481; 0481;CYRILLIC SMALL LETTER KOPPA;Ll;0;L;;;;;N;;;0480;;0480 0490;CYRILLIC CAPITAL LETTER GHE WITH UPTURN;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER GE WITH UPTURN;;;0491; 0491;CYRILLIC SMALL LETTER GHE WITH UPTURN;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER GE WITH UPTURN;;0490;;0490 0492;CYRILLIC CAPITAL LETTER GHE WITH STROKE;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER GE BAR;;;0493; 0493;CYRILLIC SMALL LETTER GHE WITH STROKE;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER GE BAR;;0492;;0492 0494;CYRILLIC CAPITAL LETTER GHE WITH MIDDLE HOOK;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER GE HOOK;;;0495; 0495;CYRILLIC SMALL LETTER GHE WITH MIDDLE HOOK;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER GE HOOK;;0494;;0494 0496;CYRILLIC CAPITAL LETTER ZHE WITH DESCENDER;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER ZHE WITH RIGHT DESCENDER;;;0497; 0497;CYRILLIC SMALL LETTER ZHE WITH DESCENDER;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER ZHE WITH RIGHT DESCENDER;;0496;;0496 0498;CYRILLIC CAPITAL LETTER ZE WITH DESCENDER;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER ZE CEDILLA;;;0499; 0499;CYRILLIC SMALL LETTER ZE WITH DESCENDER;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER ZE CEDILLA;;0498;;0498 049A;CYRILLIC CAPITAL LETTER KA WITH DESCENDER;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER KA WITH RIGHT DESCENDER;;;049B; 049B;CYRILLIC SMALL LETTER KA WITH DESCENDER;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER KA WITH RIGHT DESCENDER;;049A;;049A 049C;CYRILLIC CAPITAL LETTER KA WITH VERTICAL STROKE;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER KA VERTICAL BAR;;;049D; 049D;CYRILLIC SMALL LETTER KA WITH VERTICAL STROKE;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER KA VERTICAL BAR;;049C;;049C 049E;CYRILLIC CAPITAL LETTER KA WITH STROKE;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER KA BAR;;;049F; 049F;CYRILLIC SMALL LETTER KA WITH STROKE;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER KA BAR;;049E;;049E 04A0;CYRILLIC CAPITAL LETTER BASHKIR KA;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER REVERSED GE KA;;;04A1; 04A1;CYRILLIC SMALL LETTER BASHKIR KA;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER REVERSED GE KA;;04A0;;04A0 04A2;CYRILLIC CAPITAL LETTER EN WITH DESCENDER;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER EN WITH RIGHT DESCENDER;;;04A3; 04A3;CYRILLIC SMALL LETTER EN WITH DESCENDER;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER EN WITH RIGHT DESCENDER;;04A2;;04A2 04A4;CYRILLIC CAPITAL LIGATURE EN GHE;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER EN GE;;;04A5; 04A5;CYRILLIC SMALL LIGATURE EN GHE;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER EN GE;;04A4;;04A4 04A6;CYRILLIC CAPITAL LETTER PE WITH MIDDLE HOOK;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER PE HOOK;Abkhasian;;04A7; 04A7;CYRILLIC SMALL LETTER PE WITH MIDDLE HOOK;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER PE HOOK;Abkhasian;04A6;;04A6 04A8;CYRILLIC CAPITAL LETTER ABKHASIAN HA;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER O HOOK;;;04A9; 04A9;CYRILLIC SMALL LETTER ABKHASIAN HA;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER O HOOK;;04A8;;04A8 04AA;CYRILLIC CAPITAL LETTER ES WITH DESCENDER;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER ES CEDILLA;;;04AB; 04AB;CYRILLIC SMALL LETTER ES WITH DESCENDER;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER ES CEDILLA;;04AA;;04AA 04AC;CYRILLIC CAPITAL LETTER TE WITH DESCENDER;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER TE WITH RIGHT DESCENDER;;;04AD; 04AD;CYRILLIC SMALL LETTER TE WITH DESCENDER;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER TE WITH RIGHT DESCENDER;;04AC;;04AC 04AE;CYRILLIC CAPITAL LETTER STRAIGHT U;Lu;0;L;;;;;N;;;;04AF; 04AF;CYRILLIC SMALL LETTER STRAIGHT U;Ll;0;L;;;;;N;;;04AE;;04AE 04B0;CYRILLIC CAPITAL LETTER STRAIGHT U WITH STROKE;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER STRAIGHT U BAR;;;04B1; 04B1;CYRILLIC SMALL LETTER STRAIGHT U WITH STROKE;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER STRAIGHT U BAR;;04B0;;04B0 04B2;CYRILLIC CAPITAL LETTER HA WITH DESCENDER;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER KHA WITH RIGHT DESCENDER;;;04B3; 04B3;CYRILLIC SMALL LETTER HA WITH DESCENDER;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER KHA WITH RIGHT DESCENDER;;04B2;;04B2 04B4;CYRILLIC CAPITAL LIGATURE TE TSE;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER TE TSE;Abkhasian;;04B5; 04B5;CYRILLIC SMALL LIGATURE TE TSE;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER TE TSE;Abkhasian;04B4;;04B4 04B6;CYRILLIC CAPITAL LETTER CHE WITH DESCENDER;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER CHE WITH RIGHT DESCENDER;;;04B7; 04B7;CYRILLIC SMALL LETTER CHE WITH DESCENDER;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER CHE WITH RIGHT DESCENDER;;04B6;;04B6 04B8;CYRILLIC CAPITAL LETTER CHE WITH VERTICAL STROKE;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER CHE VERTICAL BAR;;;04B9; 04B9;CYRILLIC SMALL LETTER CHE WITH VERTICAL STROKE;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER CHE VERTICAL BAR;;04B8;;04B8 04BA;CYRILLIC CAPITAL LETTER SHHA;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER H;;;04BB; 04BB;CYRILLIC SMALL LETTER SHHA;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER H;;04BA;;04BA 04BC;CYRILLIC CAPITAL LETTER ABKHASIAN CHE;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER IE HOOK;;;04BD; 04BD;CYRILLIC SMALL LETTER ABKHASIAN CHE;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER IE HOOK;;04BC;;04BC 04BE;CYRILLIC CAPITAL LETTER ABKHASIAN CHE WITH DESCENDER;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER IE HOOK OGONEK;;;04BF; 04BF;CYRILLIC SMALL LETTER ABKHASIAN CHE WITH DESCENDER;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER IE HOOK OGONEK;;04BE;;04BE 04C1;CYRILLIC CAPITAL LETTER ZHE WITH BREVE;Lu;0;L;0416 0306;;;;N;CYRILLIC CAPITAL LETTER SHORT ZHE;;;04C2; 04C2;CYRILLIC SMALL LETTER ZHE WITH BREVE;Ll;0;L;0436 0306;;;;N;CYRILLIC SMALL LETTER SHORT ZHE;;04C1;;04C1 04C3;CYRILLIC CAPITAL LETTER KA WITH HOOK;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER KA HOOK;;;04C4; 04C4;CYRILLIC SMALL LETTER KA WITH HOOK;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER KA HOOK;;04C3;;04C3 04C7;CYRILLIC CAPITAL LETTER EN WITH HOOK;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER EN HOOK;;;04C8; 04C8;CYRILLIC SMALL LETTER EN WITH HOOK;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER EN HOOK;;04C7;;04C7 04CB;CYRILLIC CAPITAL LETTER KHAKASSIAN CHE;Lu;0;L;;;;;N;CYRILLIC CAPITAL LETTER CHE WITH LEFT DESCENDER;;;04CC; 04CC;CYRILLIC SMALL LETTER KHAKASSIAN CHE;Ll;0;L;;;;;N;CYRILLIC SMALL LETTER CHE WITH LEFT DESCENDER;;04CB;;04CB 04D0;CYRILLIC CAPITAL LETTER A WITH BREVE;Lu;0;L;0410 0306;;;;N;;;;04D1; 04D1;CYRILLIC SMALL LETTER A WITH BREVE;Ll;0;L;0430 0306;;;;N;;;04D0;;04D0 04D2;CYRILLIC CAPITAL LETTER A WITH DIAERESIS;Lu;0;L;0410 0308;;;;N;;;;04D3; 04D3;CYRILLIC SMALL LETTER A WITH DIAERESIS;Ll;0;L;0430 0308;;;;N;;;04D2;;04D2 04D4;CYRILLIC CAPITAL LIGATURE A IE;Lu;0;L;00C6;;;;N;;;;04D5; 04D5;CYRILLIC SMALL LIGATURE A IE;Ll;0;L;00E6;;;;N;;;04D4;;04D4 04D6;CYRILLIC CAPITAL LETTER IE WITH BREVE;Lu;0;L;0415 0306;;;;N;;;;04D7; 04D7;CYRILLIC SMALL LETTER IE WITH BREVE;Ll;0;L;0435 0306;;;;N;;;04D6;;04D6 04D8;CYRILLIC CAPITAL LETTER SCHWA;Lu;0;L;018F;;;;N;;;;04D9; 04D9;CYRILLIC SMALL LETTER SCHWA;Ll;0;L;0259;;;;N;;;04D8;;04D8 04DA;CYRILLIC CAPITAL LETTER SCHWA WITH DIAERESIS;Lu;0;L;018F 0308;;;;N;;;;04DB; 04DB;CYRILLIC SMALL LETTER SCHWA WITH DIAERESIS;Ll;0;L;0259 0308;;;;N;;;04DA;;04DA 04DC;CYRILLIC CAPITAL LETTER ZHE WITH DIAERESIS;Lu;0;L;0416 0308;;;;N;;;;04DD; 04DD;CYRILLIC SMALL LETTER ZHE WITH DIAERESIS;Ll;0;L;0436 0308;;;;N;;;04DC;;04DC 04DE;CYRILLIC CAPITAL LETTER ZE WITH DIAERESIS;Lu;0;L;0417 0308;;;;N;;;;04DF; 04DF;CYRILLIC SMALL LETTER ZE WITH DIAERESIS;Ll;0;L;0437 0308;;;;N;;;04DE;;04DE 04E0;CYRILLIC CAPITAL LETTER ABKHASIAN DZE;Lu;0;L;01B7;;;;N;;;;04E1; 04E1;CYRILLIC SMALL LETTER ABKHASIAN DZE;Ll;0;L;0292;;;;N;;;04E0;;04E0 04E2;CYRILLIC CAPITAL LETTER I WITH MACRON;Lu;0;L;0418 0304;;;;N;;;;04E3; 04E3;CYRILLIC SMALL LETTER I WITH MACRON;Ll;0;L;0438 0304;;;;N;;;04E2;;04E2 04E4;CYRILLIC CAPITAL LETTER I WITH DIAERESIS;Lu;0;L;0418 0308;;;;N;;;;04E5; 04E5;CYRILLIC SMALL LETTER I WITH DIAERESIS;Ll;0;L;0438 0308;;;;N;;;04E4;;04E4 04E6;CYRILLIC CAPITAL LETTER O WITH DIAERESIS;Lu;0;L;041E 0308;;;;N;;;;04E7; 04E7;CYRILLIC SMALL LETTER O WITH DIAERESIS;Ll;0;L;043E 0308;;;;N;;;04E6;;04E6 04E8;CYRILLIC CAPITAL LETTER BARRED O;Lu;0;L;019F;;;;N;;;;04E9; 04E9;CYRILLIC SMALL LETTER BARRED O;Ll;0;L;0275;;;;N;;;04E8;;04E8 04EA;CYRILLIC CAPITAL LETTER BARRED O WITH DIAERESIS;Lu;0;L;019F 0308;;;;N;;;;04EB; 04EB;CYRILLIC SMALL LETTER BARRED O WITH DIAERESIS;Ll;0;L;0275 0308;;;;N;;;04EA;;04EA 04EE;CYRILLIC CAPITAL LETTER U WITH MACRON;Lu;0;L;0423 0304;;;;N;;;;04EF; 04EF;CYRILLIC SMALL LETTER U WITH MACRON;Ll;0;L;0443 0304;;;;N;;;04EE;;04EE 04F0;CYRILLIC CAPITAL LETTER U WITH DIAERESIS;Lu;0;L;0423 0308;;;;N;;;;04F1; 04F1;CYRILLIC SMALL LETTER U WITH DIAERESIS;Ll;0;L;0443 0308;;;;N;;;04F0;;04F0 04F2;CYRILLIC CAPITAL LETTER U WITH DOUBLE ACUTE;Lu;0;L;0423 030B;;;;N;;;;04F3; 04F3;CYRILLIC SMALL LETTER U WITH DOUBLE ACUTE;Ll;0;L;0443 030B;;;;N;;;04F2;;04F2 04F4;CYRILLIC CAPITAL LETTER CHE WITH DIAERESIS;Lu;0;L;0427 0308;;;;N;;;;04F5; 04F5;CYRILLIC SMALL LETTER CHE WITH DIAERESIS;Ll;0;L;0447 0308;;;;N;;;04F4;;04F4 04F8;CYRILLIC CAPITAL LETTER YERU WITH DIAERESIS;Lu;0;L;042B 0308;;;;N;;;;04F9; 04F9;CYRILLIC SMALL LETTER YERU WITH DIAERESIS;Ll;0;L;044B 0308;;;;N;;;04F8;;04F8 0531;ARMENIAN CAPITAL LETTER AYB;Lu;0;L;;;;;N;;;;0561; 0532;ARMENIAN CAPITAL LETTER BEN;Lu;0;L;;;;;N;;;;0562; 0533;ARMENIAN CAPITAL LETTER GIM;Lu;0;L;;;;;N;;;;0563; 0534;ARMENIAN CAPITAL LETTER DA;Lu;0;L;;;;;N;;;;0564; 0535;ARMENIAN CAPITAL LETTER ECH;Lu;0;L;;;;;N;;;;0565; 0536;ARMENIAN CAPITAL LETTER ZA;Lu;0;L;;;;;N;;;;0566; 0537;ARMENIAN CAPITAL LETTER EH;Lu;0;L;;;;;N;;;;0567; 0538;ARMENIAN CAPITAL LETTER ET;Lu;0;L;;;;;N;;;;0568; 0539;ARMENIAN CAPITAL LETTER TO;Lu;0;L;;;;;N;;;;0569; 053A;ARMENIAN CAPITAL LETTER ZHE;Lu;0;L;;;;;N;;;;056A; 053B;ARMENIAN CAPITAL LETTER INI;Lu;0;L;;;;;N;;;;056B; 053C;ARMENIAN CAPITAL LETTER LIWN;Lu;0;L;;;;;N;;;;056C; 053D;ARMENIAN CAPITAL LETTER XEH;Lu;0;L;;;;;N;;;;056D; 053E;ARMENIAN CAPITAL LETTER CA;Lu;0;L;;;;;N;;;;056E; 053F;ARMENIAN CAPITAL LETTER KEN;Lu;0;L;;;;;N;;;;056F; 0540;ARMENIAN CAPITAL LETTER HO;Lu;0;L;;;;;N;;;;0570; 0541;ARMENIAN CAPITAL LETTER JA;Lu;0;L;;;;;N;;;;0571; 0542;ARMENIAN CAPITAL LETTER GHAD;Lu;0;L;;;;;N;ARMENIAN CAPITAL LETTER LAD;;;0572; 0543;ARMENIAN CAPITAL LETTER CHEH;Lu;0;L;;;;;N;;;;0573; 0544;ARMENIAN CAPITAL LETTER MEN;Lu;0;L;;;;;N;;;;0574; 0545;ARMENIAN CAPITAL LETTER YI;Lu;0;L;;;;;N;;;;0575; 0546;ARMENIAN CAPITAL LETTER NOW;Lu;0;L;;;;;N;;;;0576; 0547;ARMENIAN CAPITAL LETTER SHA;Lu;0;L;;;;;N;;;;0577; 0548;ARMENIAN CAPITAL LETTER VO;Lu;0;L;;;;;N;;;;0578; 0549;ARMENIAN CAPITAL LETTER CHA;Lu;0;L;;;;;N;;;;0579; 054A;ARMENIAN CAPITAL LETTER PEH;Lu;0;L;;;;;N;;;;057A; 054B;ARMENIAN CAPITAL LETTER JHEH;Lu;0;L;;;;;N;;;;057B; 054C;ARMENIAN CAPITAL LETTER RA;Lu;0;L;;;;;N;;;;057C; 054D;ARMENIAN CAPITAL LETTER SEH;Lu;0;L;;;;;N;;;;057D; 054E;ARMENIAN CAPITAL LETTER VEW;Lu;0;L;;;;;N;;;;057E; 054F;ARMENIAN CAPITAL LETTER TIWN;Lu;0;L;;;;;N;;;;057F; 0550;ARMENIAN CAPITAL LETTER REH;Lu;0;L;;;;;N;;;;0580; 0551;ARMENIAN CAPITAL LETTER CO;Lu;0;L;;;;;N;;;;0581; 0552;ARMENIAN CAPITAL LETTER YIWN;Lu;0;L;;;;;N;;;;0582; 0553;ARMENIAN CAPITAL LETTER PIWR;Lu;0;L;;;;;N;;;;0583; 0554;ARMENIAN CAPITAL LETTER KEH;Lu;0;L;;;;;N;;;;0584; 0555;ARMENIAN CAPITAL LETTER OH;Lu;0;L;;;;;N;;;;0585; 0556;ARMENIAN CAPITAL LETTER FEH;Lu;0;L;;;;;N;;;;0586; 0561;ARMENIAN SMALL LETTER AYB;Ll;0;L;;;;;N;;;0531;;0531 0562;ARMENIAN SMALL LETTER BEN;Ll;0;L;;;;;N;;;0532;;0532 0563;ARMENIAN SMALL LETTER GIM;Ll;0;L;;;;;N;;;0533;;0533 0564;ARMENIAN SMALL LETTER DA;Ll;0;L;;;;;N;;;0534;;0534 0565;ARMENIAN SMALL LETTER ECH;Ll;0;L;;;;;N;;;0535;;0535 0566;ARMENIAN SMALL LETTER ZA;Ll;0;L;;;;;N;;;0536;;0536 0567;ARMENIAN SMALL LETTER EH;Ll;0;L;;;;;N;;;0537;;0537 0568;ARMENIAN SMALL LETTER ET;Ll;0;L;;;;;N;;;0538;;0538 0569;ARMENIAN SMALL LETTER TO;Ll;0;L;;;;;N;;;0539;;0539 056A;ARMENIAN SMALL LETTER ZHE;Ll;0;L;;;;;N;;;053A;;053A 056B;ARMENIAN SMALL LETTER INI;Ll;0;L;;;;;N;;;053B;;053B 056C;ARMENIAN SMALL LETTER LIWN;Ll;0;L;;;;;N;;;053C;;053C 056D;ARMENIAN SMALL LETTER XEH;Ll;0;L;;;;;N;;;053D;;053D 056E;ARMENIAN SMALL LETTER CA;Ll;0;L;;;;;N;;;053E;;053E 056F;ARMENIAN SMALL LETTER KEN;Ll;0;L;;;;;N;;;053F;;053F 0570;ARMENIAN SMALL LETTER HO;Ll;0;L;;;;;N;;;0540;;0540 0571;ARMENIAN SMALL LETTER JA;Ll;0;L;;;;;N;;;0541;;0541 0572;ARMENIAN SMALL LETTER GHAD;Ll;0;L;;;;;N;ARMENIAN SMALL LETTER LAD;;0542;;0542 0573;ARMENIAN SMALL LETTER CHEH;Ll;0;L;;;;;N;;;0543;;0543 0574;ARMENIAN SMALL LETTER MEN;Ll;0;L;;;;;N;;;0544;;0544 0575;ARMENIAN SMALL LETTER YI;Ll;0;L;;;;;N;;;0545;;0545 0576;ARMENIAN SMALL LETTER NOW;Ll;0;L;;;;;N;;;0546;;0546 0577;ARMENIAN SMALL LETTER SHA;Ll;0;L;;;;;N;;;0547;;0547 0578;ARMENIAN SMALL LETTER VO;Ll;0;L;;;;;N;;;0548;;0548 0579;ARMENIAN SMALL LETTER CHA;Ll;0;L;;;;;N;;;0549;;0549 057A;ARMENIAN SMALL LETTER PEH;Ll;0;L;;;;;N;;;054A;;054A 057B;ARMENIAN SMALL LETTER JHEH;Ll;0;L;;;;;N;;;054B;;054B 057C;ARMENIAN SMALL LETTER RA;Ll;0;L;;;;;N;;;054C;;054C 057D;ARMENIAN SMALL LETTER SEH;Ll;0;L;;;;;N;;;054D;;054D 057E;ARMENIAN SMALL LETTER VEW;Ll;0;L;;;;;N;;;054E;;054E 057F;ARMENIAN SMALL LETTER TIWN;Ll;0;L;;;;;N;;;054F;;054F 0580;ARMENIAN SMALL LETTER REH;Ll;0;L;;;;;N;;;0550;;0550 0581;ARMENIAN SMALL LETTER CO;Ll;0;L;;;;;N;;;0551;;0551 0582;ARMENIAN SMALL LETTER YIWN;Ll;0;L;;;;;N;;;0552;;0552 0583;ARMENIAN SMALL LETTER PIWR;Ll;0;L;;;;;N;;;0553;;0553 0584;ARMENIAN SMALL LETTER KEH;Ll;0;L;;;;;N;;;0554;;0554 0585;ARMENIAN SMALL LETTER OH;Ll;0;L;;;;;N;;;0555;;0555 0586;ARMENIAN SMALL LETTER FEH;Ll;0;L;;;;;N;;;0556;;0556 10A0;GEORGIAN CAPITAL LETTER AN;Lu;0;L;;;;;N;;Khutsuri;;10D0; 10A1;GEORGIAN CAPITAL LETTER BAN;Lu;0;L;;;;;N;;Khutsuri;;10D1; 10A2;GEORGIAN CAPITAL LETTER GAN;Lu;0;L;;;;;N;;Khutsuri;;10D2; 10A3;GEORGIAN CAPITAL LETTER DON;Lu;0;L;;;;;N;;Khutsuri;;10D3; 10A4;GEORGIAN CAPITAL LETTER EN;Lu;0;L;;;;;N;;Khutsuri;;10D4; 10A5;GEORGIAN CAPITAL LETTER VIN;Lu;0;L;;;;;N;;Khutsuri;;10D5; 10A6;GEORGIAN CAPITAL LETTER ZEN;Lu;0;L;;;;;N;;Khutsuri;;10D6; 10A7;GEORGIAN CAPITAL LETTER TAN;Lu;0;L;;;;;N;;Khutsuri;;10D7; 10A8;GEORGIAN CAPITAL LETTER IN;Lu;0;L;;;;;N;;Khutsuri;;10D8; 10A9;GEORGIAN CAPITAL LETTER KAN;Lu;0;L;;;;;N;;Khutsuri;;10D9; 10AA;GEORGIAN CAPITAL LETTER LAS;Lu;0;L;;;;;N;;Khutsuri;;10DA; 10AB;GEORGIAN CAPITAL LETTER MAN;Lu;0;L;;;;;N;;Khutsuri;;10DB; 10AC;GEORGIAN CAPITAL LETTER NAR;Lu;0;L;;;;;N;;Khutsuri;;10DC; 10AD;GEORGIAN CAPITAL LETTER ON;Lu;0;L;;;;;N;;Khutsuri;;10DD; 10AE;GEORGIAN CAPITAL LETTER PAR;Lu;0;L;;;;;N;;Khutsuri;;10DE; 10AF;GEORGIAN CAPITAL LETTER ZHAR;Lu;0;L;;;;;N;;Khutsuri;;10DF; 10B0;GEORGIAN CAPITAL LETTER RAE;Lu;0;L;;;;;N;;Khutsuri;;10E0; 10B1;GEORGIAN CAPITAL LETTER SAN;Lu;0;L;;;;;N;;Khutsuri;;10E1; 10B2;GEORGIAN CAPITAL LETTER TAR;Lu;0;L;;;;;N;;Khutsuri;;10E2; 10B3;GEORGIAN CAPITAL LETTER UN;Lu;0;L;;;;;N;;Khutsuri;;10E3; 10B4;GEORGIAN CAPITAL LETTER PHAR;Lu;0;L;;;;;N;;Khutsuri;;10E4; 10B5;GEORGIAN CAPITAL LETTER KHAR;Lu;0;L;;;;;N;;Khutsuri;;10E5; 10B6;GEORGIAN CAPITAL LETTER GHAN;Lu;0;L;;;;;N;;Khutsuri;;10E6; 10B7;GEORGIAN CAPITAL LETTER QAR;Lu;0;L;;;;;N;;Khutsuri;;10E7; 10B8;GEORGIAN CAPITAL LETTER SHIN;Lu;0;L;;;;;N;;Khutsuri;;10E8; 10B9;GEORGIAN CAPITAL LETTER CHIN;Lu;0;L;;;;;N;;Khutsuri;;10E9; 10BA;GEORGIAN CAPITAL LETTER CAN;Lu;0;L;;;;;N;;Khutsuri;;10EA; 10BB;GEORGIAN CAPITAL LETTER JIL;Lu;0;L;;;;;N;;Khutsuri;;10EB; 10BC;GEORGIAN CAPITAL LETTER CIL;Lu;0;L;;;;;N;;Khutsuri;;10EC; 10BD;GEORGIAN CAPITAL LETTER CHAR;Lu;0;L;;;;;N;;Khutsuri;;10ED; 10BE;GEORGIAN CAPITAL LETTER XAN;Lu;0;L;;;;;N;;Khutsuri;;10EE; 10BF;GEORGIAN CAPITAL LETTER JHAN;Lu;0;L;;;;;N;;Khutsuri;;10EF; 10C0;GEORGIAN CAPITAL LETTER HAE;Lu;0;L;;;;;N;;Khutsuri;;10F0; 10C1;GEORGIAN CAPITAL LETTER HE;Lu;0;L;;;;;N;;Khutsuri;;10F1; 10C2;GEORGIAN CAPITAL LETTER HIE;Lu;0;L;;;;;N;;Khutsuri;;10F2; 10C3;GEORGIAN CAPITAL LETTER WE;Lu;0;L;;;;;N;;Khutsuri;;10F3; 10C4;GEORGIAN CAPITAL LETTER HAR;Lu;0;L;;;;;N;;Khutsuri;;10F4; 10C5;GEORGIAN CAPITAL LETTER HOE;Lu;0;L;;;;;N;;Khutsuri;;10F5; 1E00;LATIN CAPITAL LETTER A WITH RING BELOW;Lu;0;L;0041 0325;;;;N;;;;1E01; 1E01;LATIN SMALL LETTER A WITH RING BELOW;Ll;0;L;0061 0325;;;;N;;;1E00;;1E00 1E02;LATIN CAPITAL LETTER B WITH DOT ABOVE;Lu;0;L;0042 0307;;;;N;;;;1E03; 1E03;LATIN SMALL LETTER B WITH DOT ABOVE;Ll;0;L;0062 0307;;;;N;;;1E02;;1E02 1E04;LATIN CAPITAL LETTER B WITH DOT BELOW;Lu;0;L;0042 0323;;;;N;;;;1E05; 1E05;LATIN SMALL LETTER B WITH DOT BELOW;Ll;0;L;0062 0323;;;;N;;;1E04;;1E04 1E06;LATIN CAPITAL LETTER B WITH LINE BELOW;Lu;0;L;0042 0331;;;;N;;;;1E07; 1E07;LATIN SMALL LETTER B WITH LINE BELOW;Ll;0;L;0062 0331;;;;N;;;1E06;;1E06 1E08;LATIN CAPITAL LETTER C WITH CEDILLA AND ACUTE;Lu;0;L;00C7 0301;;;;N;;;;1E09; 1E09;LATIN SMALL LETTER C WITH CEDILLA AND ACUTE;Ll;0;L;00E7 0301;;;;N;;;1E08;;1E08 1E0A;LATIN CAPITAL LETTER D WITH DOT ABOVE;Lu;0;L;0044 0307;;;;N;;;;1E0B; 1E0B;LATIN SMALL LETTER D WITH DOT ABOVE;Ll;0;L;0064 0307;;;;N;;;1E0A;;1E0A 1E0C;LATIN CAPITAL LETTER D WITH DOT BELOW;Lu;0;L;0044 0323;;;;N;;;;1E0D; 1E0D;LATIN SMALL LETTER D WITH DOT BELOW;Ll;0;L;0064 0323;;;;N;;;1E0C;;1E0C 1E0E;LATIN CAPITAL LETTER D WITH LINE BELOW;Lu;0;L;0044 0331;;;;N;;;;1E0F; 1E0F;LATIN SMALL LETTER D WITH LINE BELOW;Ll;0;L;0064 0331;;;;N;;;1E0E;;1E0E 1E10;LATIN CAPITAL LETTER D WITH CEDILLA;Lu;0;L;0044 0327;;;;N;;;;1E11; 1E11;LATIN SMALL LETTER D WITH CEDILLA;Ll;0;L;0064 0327;;;;N;;;1E10;;1E10 1E12;LATIN CAPITAL LETTER D WITH CIRCUMFLEX BELOW;Lu;0;L;0044 032D;;;;N;;;;1E13; 1E13;LATIN SMALL LETTER D WITH CIRCUMFLEX BELOW;Ll;0;L;0064 032D;;;;N;;;1E12;;1E12 1E14;LATIN CAPITAL LETTER E WITH MACRON AND GRAVE;Lu;0;L;0112 0300;;;;N;;;;1E15; 1E15;LATIN SMALL LETTER E WITH MACRON AND GRAVE;Ll;0;L;0113 0300;;;;N;;;1E14;;1E14 1E16;LATIN CAPITAL LETTER E WITH MACRON AND ACUTE;Lu;0;L;0112 0301;;;;N;;;;1E17; 1E17;LATIN SMALL LETTER E WITH MACRON AND ACUTE;Ll;0;L;0113 0301;;;;N;;;1E16;;1E16 1E18;LATIN CAPITAL LETTER E WITH CIRCUMFLEX BELOW;Lu;0;L;0045 032D;;;;N;;;;1E19; 1E19;LATIN SMALL LETTER E WITH CIRCUMFLEX BELOW;Ll;0;L;0065 032D;;;;N;;;1E18;;1E18 1E1A;LATIN CAPITAL LETTER E WITH TILDE BELOW;Lu;0;L;0045 0330;;;;N;;;;1E1B; 1E1B;LATIN SMALL LETTER E WITH TILDE BELOW;Ll;0;L;0065 0330;;;;N;;;1E1A;;1E1A 1E1C;LATIN CAPITAL LETTER E WITH CEDILLA AND BREVE;Lu;0;L;0114 0327;;;;N;;;;1E1D; 1E1D;LATIN SMALL LETTER E WITH CEDILLA AND BREVE;Ll;0;L;0115 0327;;;;N;;;1E1C;;1E1C 1E1E;LATIN CAPITAL LETTER F WITH DOT ABOVE;Lu;0;L;0046 0307;;;;N;;;;1E1F; 1E1F;LATIN SMALL LETTER F WITH DOT ABOVE;Ll;0;L;0066 0307;;;;N;;;1E1E;;1E1E 1E20;LATIN CAPITAL LETTER G WITH MACRON;Lu;0;L;0047 0304;;;;N;;;;1E21; 1E21;LATIN SMALL LETTER G WITH MACRON;Ll;0;L;0067 0304;;;;N;;;1E20;;1E20 1E22;LATIN CAPITAL LETTER H WITH DOT ABOVE;Lu;0;L;0048 0307;;;;N;;;;1E23; 1E23;LATIN SMALL LETTER H WITH DOT ABOVE;Ll;0;L;0068 0307;;;;N;;;1E22;;1E22 1E24;LATIN CAPITAL LETTER H WITH DOT BELOW;Lu;0;L;0048 0323;;;;N;;;;1E25; 1E25;LATIN SMALL LETTER H WITH DOT BELOW;Ll;0;L;0068 0323;;;;N;;;1E24;;1E24 1E26;LATIN CAPITAL LETTER H WITH DIAERESIS;Lu;0;L;0048 0308;;;;N;;;;1E27; 1E27;LATIN SMALL LETTER H WITH DIAERESIS;Ll;0;L;0068 0308;;;;N;;;1E26;;1E26 1E28;LATIN CAPITAL LETTER H WITH CEDILLA;Lu;0;L;0048 0327;;;;N;;;;1E29; 1E29;LATIN SMALL LETTER H WITH CEDILLA;Ll;0;L;0068 0327;;;;N;;;1E28;;1E28 1E2A;LATIN CAPITAL LETTER H WITH BREVE BELOW;Lu;0;L;0048 032E;;;;N;;;;1E2B; 1E2B;LATIN SMALL LETTER H WITH BREVE BELOW;Ll;0;L;0068 032E;;;;N;;;1E2A;;1E2A 1E2C;LATIN CAPITAL LETTER I WITH TILDE BELOW;Lu;0;L;0049 0330;;;;N;;;;1E2D; 1E2D;LATIN SMALL LETTER I WITH TILDE BELOW;Ll;0;L;0069 0330;;;;N;;;1E2C;;1E2C 1E2E;LATIN CAPITAL LETTER I WITH DIAERESIS AND ACUTE;Lu;0;L;00CF 0301;;;;N;;;;1E2F; 1E2F;LATIN SMALL LETTER I WITH DIAERESIS AND ACUTE;Ll;0;L;00EF 0301;;;;N;;;1E2E;;1E2E 1E30;LATIN CAPITAL LETTER K WITH ACUTE;Lu;0;L;004B 0301;;;;N;;;;1E31; 1E31;LATIN SMALL LETTER K WITH ACUTE;Ll;0;L;006B 0301;;;;N;;;1E30;;1E30 1E32;LATIN CAPITAL LETTER K WITH DOT BELOW;Lu;0;L;004B 0323;;;;N;;;;1E33; 1E33;LATIN SMALL LETTER K WITH DOT BELOW;Ll;0;L;006B 0323;;;;N;;;1E32;;1E32 1E34;LATIN CAPITAL LETTER K WITH LINE BELOW;Lu;0;L;004B 0331;;;;N;;;;1E35; 1E35;LATIN SMALL LETTER K WITH LINE BELOW;Ll;0;L;006B 0331;;;;N;;;1E34;;1E34 1E36;LATIN CAPITAL LETTER L WITH DOT BELOW;Lu;0;L;004C 0323;;;;N;;;;1E37; 1E37;LATIN SMALL LETTER L WITH DOT BELOW;Ll;0;L;006C 0323;;;;N;;;1E36;;1E36 1E38;LATIN CAPITAL LETTER L WITH DOT BELOW AND MACRON;Lu;0;L;1E36 0304;;;;N;;;;1E39; 1E39;LATIN SMALL LETTER L WITH DOT BELOW AND MACRON;Ll;0;L;1E37 0304;;;;N;;;1E38;;1E38 1E3A;LATIN CAPITAL LETTER L WITH LINE BELOW;Lu;0;L;004C 0331;;;;N;;;;1E3B; 1E3B;LATIN SMALL LETTER L WITH LINE BELOW;Ll;0;L;006C 0331;;;;N;;;1E3A;;1E3A 1E3C;LATIN CAPITAL LETTER L WITH CIRCUMFLEX BELOW;Lu;0;L;004C 032D;;;;N;;;;1E3D; 1E3D;LATIN SMALL LETTER L WITH CIRCUMFLEX BELOW;Ll;0;L;006C 032D;;;;N;;;1E3C;;1E3C 1E3E;LATIN CAPITAL LETTER M WITH ACUTE;Lu;0;L;004D 0301;;;;N;;;;1E3F; 1E3F;LATIN SMALL LETTER M WITH ACUTE;Ll;0;L;006D 0301;;;;N;;;1E3E;;1E3E 1E40;LATIN CAPITAL LETTER M WITH DOT ABOVE;Lu;0;L;004D 0307;;;;N;;;;1E41; 1E41;LATIN SMALL LETTER M WITH DOT ABOVE;Ll;0;L;006D 0307;;;;N;;;1E40;;1E40 1E42;LATIN CAPITAL LETTER M WITH DOT BELOW;Lu;0;L;004D 0323;;;;N;;;;1E43; 1E43;LATIN SMALL LETTER M WITH DOT BELOW;Ll;0;L;006D 0323;;;;N;;;1E42;;1E42 1E44;LATIN CAPITAL LETTER N WITH DOT ABOVE;Lu;0;L;004E 0307;;;;N;;;;1E45; 1E45;LATIN SMALL LETTER N WITH DOT ABOVE;Ll;0;L;006E 0307;;;;N;;;1E44;;1E44 1E46;LATIN CAPITAL LETTER N WITH DOT BELOW;Lu;0;L;004E 0323;;;;N;;;;1E47; 1E47;LATIN SMALL LETTER N WITH DOT BELOW;Ll;0;L;006E 0323;;;;N;;;1E46;;1E46 1E48;LATIN CAPITAL LETTER N WITH LINE BELOW;Lu;0;L;004E 0331;;;;N;;;;1E49; 1E49;LATIN SMALL LETTER N WITH LINE BELOW;Ll;0;L;006E 0331;;;;N;;;1E48;;1E48 1E4A;LATIN CAPITAL LETTER N WITH CIRCUMFLEX BELOW;Lu;0;L;004E 032D;;;;N;;;;1E4B; 1E4B;LATIN SMALL LETTER N WITH CIRCUMFLEX BELOW;Ll;0;L;006E 032D;;;;N;;;1E4A;;1E4A 1E4C;LATIN CAPITAL LETTER O WITH TILDE AND ACUTE;Lu;0;L;00D5 0301;;;;N;;;;1E4D; 1E4D;LATIN SMALL LETTER O WITH TILDE AND ACUTE;Ll;0;L;00F5 0301;;;;N;;;1E4C;;1E4C 1E4E;LATIN CAPITAL LETTER O WITH TILDE AND DIAERESIS;Lu;0;L;00D5 0308;;;;N;;;;1E4F; 1E4F;LATIN SMALL LETTER O WITH TILDE AND DIAERESIS;Ll;0;L;00F5 0308;;;;N;;;1E4E;;1E4E 1E50;LATIN CAPITAL LETTER O WITH MACRON AND GRAVE;Lu;0;L;014C 0300;;;;N;;;;1E51; 1E51;LATIN SMALL LETTER O WITH MACRON AND GRAVE;Ll;0;L;014D 0300;;;;N;;;1E50;;1E50 1E52;LATIN CAPITAL LETTER O WITH MACRON AND ACUTE;Lu;0;L;014C 0301;;;;N;;;;1E53; 1E53;LATIN SMALL LETTER O WITH MACRON AND ACUTE;Ll;0;L;014D 0301;;;;N;;;1E52;;1E52 1E54;LATIN CAPITAL LETTER P WITH ACUTE;Lu;0;L;0050 0301;;;;N;;;;1E55; 1E55;LATIN SMALL LETTER P WITH ACUTE;Ll;0;L;0070 0301;;;;N;;;1E54;;1E54 1E56;LATIN CAPITAL LETTER P WITH DOT ABOVE;Lu;0;L;0050 0307;;;;N;;;;1E57; 1E57;LATIN SMALL LETTER P WITH DOT ABOVE;Ll;0;L;0070 0307;;;;N;;;1E56;;1E56 1E58;LATIN CAPITAL LETTER R WITH DOT ABOVE;Lu;0;L;0052 0307;;;;N;;;;1E59; 1E59;LATIN SMALL LETTER R WITH DOT ABOVE;Ll;0;L;0072 0307;;;;N;;;1E58;;1E58 1E5A;LATIN CAPITAL LETTER R WITH DOT BELOW;Lu;0;L;0052 0323;;;;N;;;;1E5B; 1E5B;LATIN SMALL LETTER R WITH DOT BELOW;Ll;0;L;0072 0323;;;;N;;;1E5A;;1E5A 1E5C;LATIN CAPITAL LETTER R WITH DOT BELOW AND MACRON;Lu;0;L;1E5A 0304;;;;N;;;;1E5D; 1E5D;LATIN SMALL LETTER R WITH DOT BELOW AND MACRON;Ll;0;L;1E5B 0304;;;;N;;;1E5C;;1E5C 1E5E;LATIN CAPITAL LETTER R WITH LINE BELOW;Lu;0;L;0052 0331;;;;N;;;;1E5F; 1E5F;LATIN SMALL LETTER R WITH LINE BELOW;Ll;0;L;0072 0331;;;;N;;;1E5E;;1E5E 1E60;LATIN CAPITAL LETTER S WITH DOT ABOVE;Lu;0;L;0053 0307;;;;N;;;;1E61; 1E61;LATIN SMALL LETTER S WITH DOT ABOVE;Ll;0;L;0073 0307;;;;N;;;1E60;;1E60 1E62;LATIN CAPITAL LETTER S WITH DOT BELOW;Lu;0;L;0053 0323;;;;N;;;;1E63; 1E63;LATIN SMALL LETTER S WITH DOT BELOW;Ll;0;L;0073 0323;;;;N;;;1E62;;1E62 1E64;LATIN CAPITAL LETTER S WITH ACUTE AND DOT ABOVE;Lu;0;L;015A 0307;;;;N;;;;1E65; 1E65;LATIN SMALL LETTER S WITH ACUTE AND DOT ABOVE;Ll;0;L;015B 0307;;;;N;;;1E64;;1E64 1E66;LATIN CAPITAL LETTER S WITH CARON AND DOT ABOVE;Lu;0;L;0160 0307;;;;N;;;;1E67; 1E67;LATIN SMALL LETTER S WITH CARON AND DOT ABOVE;Ll;0;L;0161 0307;;;;N;;;1E66;;1E66 1E68;LATIN CAPITAL LETTER S WITH DOT BELOW AND DOT ABOVE;Lu;0;L;1E62 0307;;;;N;;;;1E69; 1E69;LATIN SMALL LETTER S WITH DOT BELOW AND DOT ABOVE;Ll;0;L;1E63 0307;;;;N;;;1E68;;1E68 1E6A;LATIN CAPITAL LETTER T WITH DOT ABOVE;Lu;0;L;0054 0307;;;;N;;;;1E6B; 1E6B;LATIN SMALL LETTER T WITH DOT ABOVE;Ll;0;L;0074 0307;;;;N;;;1E6A;;1E6A 1E6C;LATIN CAPITAL LETTER T WITH DOT BELOW;Lu;0;L;0054 0323;;;;N;;;;1E6D; 1E6D;LATIN SMALL LETTER T WITH DOT BELOW;Ll;0;L;0074 0323;;;;N;;;1E6C;;1E6C 1E6E;LATIN CAPITAL LETTER T WITH LINE BELOW;Lu;0;L;0054 0331;;;;N;;;;1E6F; 1E6F;LATIN SMALL LETTER T WITH LINE BELOW;Ll;0;L;0074 0331;;;;N;;;1E6E;;1E6E 1E70;LATIN CAPITAL LETTER T WITH CIRCUMFLEX BELOW;Lu;0;L;0054 032D;;;;N;;;;1E71; 1E71;LATIN SMALL LETTER T WITH CIRCUMFLEX BELOW;Ll;0;L;0074 032D;;;;N;;;1E70;;1E70 1E72;LATIN CAPITAL LETTER U WITH DIAERESIS BELOW;Lu;0;L;0055 0324;;;;N;;;;1E73; 1E73;LATIN SMALL LETTER U WITH DIAERESIS BELOW;Ll;0;L;0075 0324;;;;N;;;1E72;;1E72 1E74;LATIN CAPITAL LETTER U WITH TILDE BELOW;Lu;0;L;0055 0330;;;;N;;;;1E75; 1E75;LATIN SMALL LETTER U WITH TILDE BELOW;Ll;0;L;0075 0330;;;;N;;;1E74;;1E74 1E76;LATIN CAPITAL LETTER U WITH CIRCUMFLEX BELOW;Lu;0;L;0055 032D;;;;N;;;;1E77; 1E77;LATIN SMALL LETTER U WITH CIRCUMFLEX BELOW;Ll;0;L;0075 032D;;;;N;;;1E76;;1E76 1E78;LATIN CAPITAL LETTER U WITH TILDE AND ACUTE;Lu;0;L;0168 0301;;;;N;;;;1E79; 1E79;LATIN SMALL LETTER U WITH TILDE AND ACUTE;Ll;0;L;0169 0301;;;;N;;;1E78;;1E78 1E7A;LATIN CAPITAL LETTER U WITH MACRON AND DIAERESIS;Lu;0;L;016A 0308;;;;N;;;;1E7B; 1E7B;LATIN SMALL LETTER U WITH MACRON AND DIAERESIS;Ll;0;L;016B 0308;;;;N;;;1E7A;;1E7A 1E7C;LATIN CAPITAL LETTER V WITH TILDE;Lu;0;L;0056 0303;;;;N;;;;1E7D; 1E7D;LATIN SMALL LETTER V WITH TILDE;Ll;0;L;0076 0303;;;;N;;;1E7C;;1E7C 1E7E;LATIN CAPITAL LETTER V WITH DOT BELOW;Lu;0;L;0056 0323;;;;N;;;;1E7F; 1E7F;LATIN SMALL LETTER V WITH DOT BELOW;Ll;0;L;0076 0323;;;;N;;;1E7E;;1E7E 1E80;LATIN CAPITAL LETTER W WITH GRAVE;Lu;0;L;0057 0300;;;;N;;;;1E81; 1E81;LATIN SMALL LETTER W WITH GRAVE;Ll;0;L;0077 0300;;;;N;;;1E80;;1E80 1E82;LATIN CAPITAL LETTER W WITH ACUTE;Lu;0;L;0057 0301;;;;N;;;;1E83; 1E83;LATIN SMALL LETTER W WITH ACUTE;Ll;0;L;0077 0301;;;;N;;;1E82;;1E82 1E84;LATIN CAPITAL LETTER W WITH DIAERESIS;Lu;0;L;0057 0308;;;;N;;;;1E85; 1E85;LATIN SMALL LETTER W WITH DIAERESIS;Ll;0;L;0077 0308;;;;N;;;1E84;;1E84 1E86;LATIN CAPITAL LETTER W WITH DOT ABOVE;Lu;0;L;0057 0307;;;;N;;;;1E87; 1E87;LATIN SMALL LETTER W WITH DOT ABOVE;Ll;0;L;0077 0307;;;;N;;;1E86;;1E86 1E88;LATIN CAPITAL LETTER W WITH DOT BELOW;Lu;0;L;0057 0323;;;;N;;;;1E89; 1E89;LATIN SMALL LETTER W WITH DOT BELOW;Ll;0;L;0077 0323;;;;N;;;1E88;;1E88 1E8A;LATIN CAPITAL LETTER X WITH DOT ABOVE;Lu;0;L;0058 0307;;;;N;;;;1E8B; 1E8B;LATIN SMALL LETTER X WITH DOT ABOVE;Ll;0;L;0078 0307;;;;N;;;1E8A;;1E8A 1E8C;LATIN CAPITAL LETTER X WITH DIAERESIS;Lu;0;L;0058 0308;;;;N;;;;1E8D; 1E8D;LATIN SMALL LETTER X WITH DIAERESIS;Ll;0;L;0078 0308;;;;N;;;1E8C;;1E8C 1E8E;LATIN CAPITAL LETTER Y WITH DOT ABOVE;Lu;0;L;0059 0307;;;;N;;;;1E8F; 1E8F;LATIN SMALL LETTER Y WITH DOT ABOVE;Ll;0;L;0079 0307;;;;N;;;1E8E;;1E8E 1E90;LATIN CAPITAL LETTER Z WITH CIRCUMFLEX;Lu;0;L;005A 0302;;;;N;;;;1E91; 1E91;LATIN SMALL LETTER Z WITH CIRCUMFLEX;Ll;0;L;007A 0302;;;;N;;;1E90;;1E90 1E92;LATIN CAPITAL LETTER Z WITH DOT BELOW;Lu;0;L;005A 0323;;;;N;;;;1E93; 1E93;LATIN SMALL LETTER Z WITH DOT BELOW;Ll;0;L;007A 0323;;;;N;;;1E92;;1E92 1E94;LATIN CAPITAL LETTER Z WITH LINE BELOW;Lu;0;L;005A 0331;;;;N;;;;1E95; 1E95;LATIN SMALL LETTER Z WITH LINE BELOW;Ll;0;L;007A 0331;;;;N;;;1E94;;1E94 1EA0;LATIN CAPITAL LETTER A WITH DOT BELOW;Lu;0;L;0041 0323;;;;N;;;;1EA1; 1EA1;LATIN SMALL LETTER A WITH DOT BELOW;Ll;0;L;0061 0323;;;;N;;;1EA0;;1EA0 1EA2;LATIN CAPITAL LETTER A WITH HOOK ABOVE;Lu;0;L;0041 0309;;;;N;;;;1EA3; 1EA3;LATIN SMALL LETTER A WITH HOOK ABOVE;Ll;0;L;0061 0309;;;;N;;;1EA2;;1EA2 1EA4;LATIN CAPITAL LETTER A WITH CIRCUMFLEX AND ACUTE;Lu;0;L;00C2 0301;;;;N;;;;1EA5; 1EA5;LATIN SMALL LETTER A WITH CIRCUMFLEX AND ACUTE;Ll;0;L;00E2 0301;;;;N;;;1EA4;;1EA4 1EA6;LATIN CAPITAL LETTER A WITH CIRCUMFLEX AND GRAVE;Lu;0;L;00C2 0300;;;;N;;;;1EA7; 1EA7;LATIN SMALL LETTER A WITH CIRCUMFLEX AND GRAVE;Ll;0;L;00E2 0300;;;;N;;;1EA6;;1EA6 1EA8;LATIN CAPITAL LETTER A WITH CIRCUMFLEX AND HOOK ABOVE;Lu;0;L;00C2 0309;;;;N;;;;1EA9; 1EA9;LATIN SMALL LETTER A WITH CIRCUMFLEX AND HOOK ABOVE;Ll;0;L;00E2 0309;;;;N;;;1EA8;;1EA8 1EAA;LATIN CAPITAL LETTER A WITH CIRCUMFLEX AND TILDE;Lu;0;L;00C2 0303;;;;N;;;;1EAB; 1EAB;LATIN SMALL LETTER A WITH CIRCUMFLEX AND TILDE;Ll;0;L;00E2 0303;;;;N;;;1EAA;;1EAA 1EAC;LATIN CAPITAL LETTER A WITH CIRCUMFLEX AND DOT BELOW;Lu;0;L;00C2 0323;;;;N;;;;1EAD; 1EAD;LATIN SMALL LETTER A WITH CIRCUMFLEX AND DOT BELOW;Ll;0;L;00E2 0323;;;;N;;;1EAC;;1EAC 1EAE;LATIN CAPITAL LETTER A WITH BREVE AND ACUTE;Lu;0;L;0102 0301;;;;N;;;;1EAF; 1EAF;LATIN SMALL LETTER A WITH BREVE AND ACUTE;Ll;0;L;0103 0301;;;;N;;;1EAE;;1EAE 1EB0;LATIN CAPITAL LETTER A WITH BREVE AND GRAVE;Lu;0;L;0102 0300;;;;N;;;;1EB1; 1EB1;LATIN SMALL LETTER A WITH BREVE AND GRAVE;Ll;0;L;0103 0300;;;;N;;;1EB0;;1EB0 1EB2;LATIN CAPITAL LETTER A WITH BREVE AND HOOK ABOVE;Lu;0;L;0102 0309;;;;N;;;;1EB3; 1EB3;LATIN SMALL LETTER A WITH BREVE AND HOOK ABOVE;Ll;0;L;0103 0309;;;;N;;;1EB2;;1EB2 1EB4;LATIN CAPITAL LETTER A WITH BREVE AND TILDE;Lu;0;L;0102 0303;;;;N;;;;1EB5; 1EB5;LATIN SMALL LETTER A WITH BREVE AND TILDE;Ll;0;L;0103 0303;;;;N;;;1EB4;;1EB4 1EB6;LATIN CAPITAL LETTER A WITH BREVE AND DOT BELOW;Lu;0;L;0102 0323;;;;N;;;;1EB7; 1EB7;LATIN SMALL LETTER A WITH BREVE AND DOT BELOW;Ll;0;L;0103 0323;;;;N;;;1EB6;;1EB6 1EB8;LATIN CAPITAL LETTER E WITH DOT BELOW;Lu;0;L;0045 0323;;;;N;;;;1EB9; 1EB9;LATIN SMALL LETTER E WITH DOT BELOW;Ll;0;L;0065 0323;;;;N;;;1EB8;;1EB8 1EBA;LATIN CAPITAL LETTER E WITH HOOK ABOVE;Lu;0;L;0045 0309;;;;N;;;;1EBB; 1EBB;LATIN SMALL LETTER E WITH HOOK ABOVE;Ll;0;L;0065 0309;;;;N;;;1EBA;;1EBA 1EBC;LATIN CAPITAL LETTER E WITH TILDE;Lu;0;L;0045 0303;;;;N;;;;1EBD; 1EBD;LATIN SMALL LETTER E WITH TILDE;Ll;0;L;0065 0303;;;;N;;;1EBC;;1EBC 1EBE;LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND ACUTE;Lu;0;L;00CA 0301;;;;N;;;;1EBF; 1EBF;LATIN SMALL LETTER E WITH CIRCUMFLEX AND ACUTE;Ll;0;L;00EA 0301;;;;N;;;1EBE;;1EBE 1EC0;LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND GRAVE;Lu;0;L;00CA 0300;;;;N;;;;1EC1; 1EC1;LATIN SMALL LETTER E WITH CIRCUMFLEX AND GRAVE;Ll;0;L;00EA 0300;;;;N;;;1EC0;;1EC0 1EC2;LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND HOOK ABOVE;Lu;0;L;00CA 0309;;;;N;;;;1EC3; 1EC3;LATIN SMALL LETTER E WITH CIRCUMFLEX AND HOOK ABOVE;Ll;0;L;00EA 0309;;;;N;;;1EC2;;1EC2 1EC4;LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND TILDE;Lu;0;L;00CA 0303;;;;N;;;;1EC5; 1EC5;LATIN SMALL LETTER E WITH CIRCUMFLEX AND TILDE;Ll;0;L;00EA 0303;;;;N;;;1EC4;;1EC4 1EC6;LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND DOT BELOW;Lu;0;L;00CA 0323;;;;N;;;;1EC7; 1EC7;LATIN SMALL LETTER E WITH CIRCUMFLEX AND DOT BELOW;Ll;0;L;00EA 0323;;;;N;;;1EC6;;1EC6 1EC8;LATIN CAPITAL LETTER I WITH HOOK ABOVE;Lu;0;L;0049 0309;;;;N;;;;1EC9; 1EC9;LATIN SMALL LETTER I WITH HOOK ABOVE;Ll;0;L;0069 0309;;;;N;;;1EC8;;1EC8 1ECA;LATIN CAPITAL LETTER I WITH DOT BELOW;Lu;0;L;0049 0323;;;;N;;;;1ECB; 1ECB;LATIN SMALL LETTER I WITH DOT BELOW;Ll;0;L;0069 0323;;;;N;;;1ECA;;1ECA 1ECC;LATIN CAPITAL LETTER O WITH DOT BELOW;Lu;0;L;004F 0323;;;;N;;;;1ECD; 1ECD;LATIN SMALL LETTER O WITH DOT BELOW;Ll;0;L;006F 0323;;;;N;;;1ECC;;1ECC 1ECE;LATIN CAPITAL LETTER O WITH HOOK ABOVE;Lu;0;L;004F 0309;;;;N;;;;1ECF; 1ECF;LATIN SMALL LETTER O WITH HOOK ABOVE;Ll;0;L;006F 0309;;;;N;;;1ECE;;1ECE 1ED0;LATIN CAPITAL LETTER O WITH CIRCUMFLEX AND ACUTE;Lu;0;L;00D4 0301;;;;N;;;;1ED1; 1ED1;LATIN SMALL LETTER O WITH CIRCUMFLEX AND ACUTE;Ll;0;L;00F4 0301;;;;N;;;1ED0;;1ED0 1ED2;LATIN CAPITAL LETTER O WITH CIRCUMFLEX AND GRAVE;Lu;0;L;00D4 0300;;;;N;;;;1ED3; 1ED3;LATIN SMALL LETTER O WITH CIRCUMFLEX AND GRAVE;Ll;0;L;00F4 0300;;;;N;;;1ED2;;1ED2 1ED4;LATIN CAPITAL LETTER O WITH CIRCUMFLEX AND HOOK ABOVE;Lu;0;L;00D4 0309;;;;N;;;;1ED5; 1ED5;LATIN SMALL LETTER O WITH CIRCUMFLEX AND HOOK ABOVE;Ll;0;L;00F4 0309;;;;N;;;1ED4;;1ED4 1ED6;LATIN CAPITAL LETTER O WITH CIRCUMFLEX AND TILDE;Lu;0;L;00D4 0303;;;;N;;;;1ED7; 1ED7;LATIN SMALL LETTER O WITH CIRCUMFLEX AND TILDE;Ll;0;L;00F4 0303;;;;N;;;1ED6;;1ED6 1ED8;LATIN CAPITAL LETTER O WITH CIRCUMFLEX AND DOT BELOW;Lu;0;L;00D4 0323;;;;N;;;;1ED9; 1ED9;LATIN SMALL LETTER O WITH CIRCUMFLEX AND DOT BELOW;Ll;0;L;00F4 0323;;;;N;;;1ED8;;1ED8 1EDA;LATIN CAPITAL LETTER O WITH HORN AND ACUTE;Lu;0;L;01A0 0301;;;;N;;;;1EDB; 1EDB;LATIN SMALL LETTER O WITH HORN AND ACUTE;Ll;0;L;01A1 0301;;;;N;;;1EDA;;1EDA 1EDC;LATIN CAPITAL LETTER O WITH HORN AND GRAVE;Lu;0;L;01A0 0300;;;;N;;;;1EDD; 1EDD;LATIN SMALL LETTER O WITH HORN AND GRAVE;Ll;0;L;01A1 0300;;;;N;;;1EDC;;1EDC 1EDE;LATIN CAPITAL LETTER O WITH HORN AND HOOK ABOVE;Lu;0;L;01A0 0309;;;;N;;;;1EDF; 1EDF;LATIN SMALL LETTER O WITH HORN AND HOOK ABOVE;Ll;0;L;01A1 0309;;;;N;;;1EDE;;1EDE 1EE0;LATIN CAPITAL LETTER O WITH HORN AND TILDE;Lu;0;L;01A0 0303;;;;N;;;;1EE1; 1EE1;LATIN SMALL LETTER O WITH HORN AND TILDE;Ll;0;L;01A1 0303;;;;N;;;1EE0;;1EE0 1EE2;LATIN CAPITAL LETTER O WITH HORN AND DOT BELOW;Lu;0;L;01A0 0323;;;;N;;;;1EE3; 1EE3;LATIN SMALL LETTER O WITH HORN AND DOT BELOW;Ll;0;L;01A1 0323;;;;N;;;1EE2;;1EE2 1EE4;LATIN CAPITAL LETTER U WITH DOT BELOW;Lu;0;L;0055 0323;;;;N;;;;1EE5; 1EE5;LATIN SMALL LETTER U WITH DOT BELOW;Ll;0;L;0075 0323;;;;N;;;1EE4;;1EE4 1EE6;LATIN CAPITAL LETTER U WITH HOOK ABOVE;Lu;0;L;0055 0309;;;;N;;;;1EE7; 1EE7;LATIN SMALL LETTER U WITH HOOK ABOVE;Ll;0;L;0075 0309;;;;N;;;1EE6;;1EE6 1EE8;LATIN CAPITAL LETTER U WITH HORN AND ACUTE;Lu;0;L;01AF 0301;;;;N;;;;1EE9; 1EE9;LATIN SMALL LETTER U WITH HORN AND ACUTE;Ll;0;L;01B0 0301;;;;N;;;1EE8;;1EE8 1EEA;LATIN CAPITAL LETTER U WITH HORN AND GRAVE;Lu;0;L;01AF 0300;;;;N;;;;1EEB; 1EEB;LATIN SMALL LETTER U WITH HORN AND GRAVE;Ll;0;L;01B0 0300;;;;N;;;1EEA;;1EEA 1EEC;LATIN CAPITAL LETTER U WITH HORN AND HOOK ABOVE;Lu;0;L;01AF 0309;;;;N;;;;1EED; 1EED;LATIN SMALL LETTER U WITH HORN AND HOOK ABOVE;Ll;0;L;01B0 0309;;;;N;;;1EEC;;1EEC 1EEE;LATIN CAPITAL LETTER U WITH HORN AND TILDE;Lu;0;L;01AF 0303;;;;N;;;;1EEF; 1EEF;LATIN SMALL LETTER U WITH HORN AND TILDE;Ll;0;L;01B0 0303;;;;N;;;1EEE;;1EEE 1EF0;LATIN CAPITAL LETTER U WITH HORN AND DOT BELOW;Lu;0;L;01AF 0323;;;;N;;;;1EF1; 1EF1;LATIN SMALL LETTER U WITH HORN AND DOT BELOW;Ll;0;L;01B0 0323;;;;N;;;1EF0;;1EF0 1EF2;LATIN CAPITAL LETTER Y WITH GRAVE;Lu;0;L;0059 0300;;;;N;;;;1EF3; 1EF3;LATIN SMALL LETTER Y WITH GRAVE;Ll;0;L;0079 0300;;;;N;;;1EF2;;1EF2 1EF4;LATIN CAPITAL LETTER Y WITH DOT BELOW;Lu;0;L;0059 0323;;;;N;;;;1EF5; 1EF5;LATIN SMALL LETTER Y WITH DOT BELOW;Ll;0;L;0079 0323;;;;N;;;1EF4;;1EF4 1EF6;LATIN CAPITAL LETTER Y WITH HOOK ABOVE;Lu;0;L;0059 0309;;;;N;;;;1EF7; 1EF7;LATIN SMALL LETTER Y WITH HOOK ABOVE;Ll;0;L;0079 0309;;;;N;;;1EF6;;1EF6 1EF8;LATIN CAPITAL LETTER Y WITH TILDE;Lu;0;L;0059 0303;;;;N;;;;1EF9; 1EF9;LATIN SMALL LETTER Y WITH TILDE;Ll;0;L;0079 0303;;;;N;;;1EF8;;1EF8 1F00;GREEK SMALL LETTER ALPHA WITH PSILI;Ll;0;L;03B1 0313;;;;N;;;1F08;;1F08 1F01;GREEK SMALL LETTER ALPHA WITH DASIA;Ll;0;L;03B1 0314;;;;N;;;1F09;;1F09 1F02;GREEK SMALL LETTER ALPHA WITH PSILI AND VARIA;Ll;0;L;1F00 0300;;;;N;;;1F0A;;1F0A 1F03;GREEK SMALL LETTER ALPHA WITH DASIA AND VARIA;Ll;0;L;1F01 0300;;;;N;;;1F0B;;1F0B 1F04;GREEK SMALL LETTER ALPHA WITH PSILI AND OXIA;Ll;0;L;1F00 0301;;;;N;;;1F0C;;1F0C 1F05;GREEK SMALL LETTER ALPHA WITH DASIA AND OXIA;Ll;0;L;1F01 0301;;;;N;;;1F0D;;1F0D 1F06;GREEK SMALL LETTER ALPHA WITH PSILI AND PERISPOMENI;Ll;0;L;1F00 0342;;;;N;;;1F0E;;1F0E 1F07;GREEK SMALL LETTER ALPHA WITH DASIA AND PERISPOMENI;Ll;0;L;1F01 0342;;;;N;;;1F0F;;1F0F 1F08;GREEK CAPITAL LETTER ALPHA WITH PSILI;Lu;0;L;0391 0313;;;;N;;;;1F00; 1F09;GREEK CAPITAL LETTER ALPHA WITH DASIA;Lu;0;L;0391 0314;;;;N;;;;1F01; 1F0A;GREEK CAPITAL LETTER ALPHA WITH PSILI AND VARIA;Lu;0;L;1F08 0300;;;;N;;;;1F02; 1F0B;GREEK CAPITAL LETTER ALPHA WITH DASIA AND VARIA;Lu;0;L;1F09 0300;;;;N;;;;1F03; 1F0C;GREEK CAPITAL LETTER ALPHA WITH PSILI AND OXIA;Lu;0;L;1F08 0301;;;;N;;;;1F04; 1F0D;GREEK CAPITAL LETTER ALPHA WITH DASIA AND OXIA;Lu;0;L;1F09 0301;;;;N;;;;1F05; 1F0E;GREEK CAPITAL LETTER ALPHA WITH PSILI AND PERISPOMENI;Lu;0;L;1F08 0342;;;;N;;;;1F06; 1F0F;GREEK CAPITAL LETTER ALPHA WITH DASIA AND PERISPOMENI;Lu;0;L;1F09 0342;;;;N;;;;1F07; 1F10;GREEK SMALL LETTER EPSILON WITH PSILI;Ll;0;L;03B5 0313;;;;N;;;1F18;;1F18 1F11;GREEK SMALL LETTER EPSILON WITH DASIA;Ll;0;L;03B5 0314;;;;N;;;1F19;;1F19 1F12;GREEK SMALL LETTER EPSILON WITH PSILI AND VARIA;Ll;0;L;1F10 0300;;;;N;;;1F1A;;1F1A 1F13;GREEK SMALL LETTER EPSILON WITH DASIA AND VARIA;Ll;0;L;1F11 0300;;;;N;;;1F1B;;1F1B 1F14;GREEK SMALL LETTER EPSILON WITH PSILI AND OXIA;Ll;0;L;1F10 0301;;;;N;;;1F1C;;1F1C 1F15;GREEK SMALL LETTER EPSILON WITH DASIA AND OXIA;Ll;0;L;1F11 0301;;;;N;;;1F1D;;1F1D 1F18;GREEK CAPITAL LETTER EPSILON WITH PSILI;Lu;0;L;0395 0313;;;;N;;;;1F10; 1F19;GREEK CAPITAL LETTER EPSILON WITH DASIA;Lu;0;L;0395 0314;;;;N;;;;1F11; 1F1A;GREEK CAPITAL LETTER EPSILON WITH PSILI AND VARIA;Lu;0;L;1F18 0300;;;;N;;;;1F12; 1F1B;GREEK CAPITAL LETTER EPSILON WITH DASIA AND VARIA;Lu;0;L;1F19 0300;;;;N;;;;1F13; 1F1C;GREEK CAPITAL LETTER EPSILON WITH PSILI AND OXIA;Lu;0;L;1F18 0301;;;;N;;;;1F14; 1F1D;GREEK CAPITAL LETTER EPSILON WITH DASIA AND OXIA;Lu;0;L;1F19 0301;;;;N;;;;1F15; 1F20;GREEK SMALL LETTER ETA WITH PSILI;Ll;0;L;03B7 0313;;;;N;;;1F28;;1F28 1F21;GREEK SMALL LETTER ETA WITH DASIA;Ll;0;L;03B7 0314;;;;N;;;1F29;;1F29 1F22;GREEK SMALL LETTER ETA WITH PSILI AND VARIA;Ll;0;L;1F20 0300;;;;N;;;1F2A;;1F2A 1F23;GREEK SMALL LETTER ETA WITH DASIA AND VARIA;Ll;0;L;1F21 0300;;;;N;;;1F2B;;1F2B 1F24;GREEK SMALL LETTER ETA WITH PSILI AND OXIA;Ll;0;L;1F20 0301;;;;N;;;1F2C;;1F2C 1F25;GREEK SMALL LETTER ETA WITH DASIA AND OXIA;Ll;0;L;1F21 0301;;;;N;;;1F2D;;1F2D 1F26;GREEK SMALL LETTER ETA WITH PSILI AND PERISPOMENI;Ll;0;L;1F20 0342;;;;N;;;1F2E;;1F2E 1F27;GREEK SMALL LETTER ETA WITH DASIA AND PERISPOMENI;Ll;0;L;1F21 0342;;;;N;;;1F2F;;1F2F 1F28;GREEK CAPITAL LETTER ETA WITH PSILI;Lu;0;L;0397 0313;;;;N;;;;1F20; 1F29;GREEK CAPITAL LETTER ETA WITH DASIA;Lu;0;L;0397 0314;;;;N;;;;1F21; 1F2A;GREEK CAPITAL LETTER ETA WITH PSILI AND VARIA;Lu;0;L;1F28 0300;;;;N;;;;1F22; 1F2B;GREEK CAPITAL LETTER ETA WITH DASIA AND VARIA;Lu;0;L;1F29 0300;;;;N;;;;1F23; 1F2C;GREEK CAPITAL LETTER ETA WITH PSILI AND OXIA;Lu;0;L;1F28 0301;;;;N;;;;1F24; 1F2D;GREEK CAPITAL LETTER ETA WITH DASIA AND OXIA;Lu;0;L;1F29 0301;;;;N;;;;1F25; 1F2E;GREEK CAPITAL LETTER ETA WITH PSILI AND PERISPOMENI;Lu;0;L;1F28 0342;;;;N;;;;1F26; 1F2F;GREEK CAPITAL LETTER ETA WITH DASIA AND PERISPOMENI;Lu;0;L;1F29 0342;;;;N;;;;1F27; 1F30;GREEK SMALL LETTER IOTA WITH PSILI;Ll;0;L;03B9 0313;;;;N;;;1F38;;1F38 1F31;GREEK SMALL LETTER IOTA WITH DASIA;Ll;0;L;03B9 0314;;;;N;;;1F39;;1F39 1F32;GREEK SMALL LETTER IOTA WITH PSILI AND VARIA;Ll;0;L;1F30 0300;;;;N;;;1F3A;;1F3A 1F33;GREEK SMALL LETTER IOTA WITH DASIA AND VARIA;Ll;0;L;1F31 0300;;;;N;;;1F3B;;1F3B 1F34;GREEK SMALL LETTER IOTA WITH PSILI AND OXIA;Ll;0;L;1F30 0301;;;;N;;;1F3C;;1F3C 1F35;GREEK SMALL LETTER IOTA WITH DASIA AND OXIA;Ll;0;L;1F31 0301;;;;N;;;1F3D;;1F3D 1F36;GREEK SMALL LETTER IOTA WITH PSILI AND PERISPOMENI;Ll;0;L;1F30 0342;;;;N;;;1F3E;;1F3E 1F37;GREEK SMALL LETTER IOTA WITH DASIA AND PERISPOMENI;Ll;0;L;1F31 0342;;;;N;;;1F3F;;1F3F 1F38;GREEK CAPITAL LETTER IOTA WITH PSILI;Lu;0;L;0399 0313;;;;N;;;;1F30; 1F39;GREEK CAPITAL LETTER IOTA WITH DASIA;Lu;0;L;0399 0314;;;;N;;;;1F31; 1F3A;GREEK CAPITAL LETTER IOTA WITH PSILI AND VARIA;Lu;0;L;1F38 0300;;;;N;;;;1F32; 1F3B;GREEK CAPITAL LETTER IOTA WITH DASIA AND VARIA;Lu;0;L;1F39 0300;;;;N;;;;1F33; 1F3C;GREEK CAPITAL LETTER IOTA WITH PSILI AND OXIA;Lu;0;L;1F38 0301;;;;N;;;;1F34; 1F3D;GREEK CAPITAL LETTER IOTA WITH DASIA AND OXIA;Lu;0;L;1F39 0301;;;;N;;;;1F35; 1F3E;GREEK CAPITAL LETTER IOTA WITH PSILI AND PERISPOMENI;Lu;0;L;1F38 0342;;;;N;;;;1F36; 1F3F;GREEK CAPITAL LETTER IOTA WITH DASIA AND PERISPOMENI;Lu;0;L;1F39 0342;;;;N;;;;1F37; 1F40;GREEK SMALL LETTER OMICRON WITH PSILI;Ll;0;L;03BF 0313;;;;N;;;1F48;;1F48 1F41;GREEK SMALL LETTER OMICRON WITH DASIA;Ll;0;L;03BF 0314;;;;N;;;1F49;;1F49 1F42;GREEK SMALL LETTER OMICRON WITH PSILI AND VARIA;Ll;0;L;1F40 0300;;;;N;;;1F4A;;1F4A 1F43;GREEK SMALL LETTER OMICRON WITH DASIA AND VARIA;Ll;0;L;1F41 0300;;;;N;;;1F4B;;1F4B 1F44;GREEK SMALL LETTER OMICRON WITH PSILI AND OXIA;Ll;0;L;1F40 0301;;;;N;;;1F4C;;1F4C 1F45;GREEK SMALL LETTER OMICRON WITH DASIA AND OXIA;Ll;0;L;1F41 0301;;;;N;;;1F4D;;1F4D 1F48;GREEK CAPITAL LETTER OMICRON WITH PSILI;Lu;0;L;039F 0313;;;;N;;;;1F40; 1F49;GREEK CAPITAL LETTER OMICRON WITH DASIA;Lu;0;L;039F 0314;;;;N;;;;1F41; 1F4A;GREEK CAPITAL LETTER OMICRON WITH PSILI AND VARIA;Lu;0;L;1F48 0300;;;;N;;;;1F42; 1F4B;GREEK CAPITAL LETTER OMICRON WITH DASIA AND VARIA;Lu;0;L;1F49 0300;;;;N;;;;1F43; 1F4C;GREEK CAPITAL LETTER OMICRON WITH PSILI AND OXIA;Lu;0;L;1F48 0301;;;;N;;;;1F44; 1F4D;GREEK CAPITAL LETTER OMICRON WITH DASIA AND OXIA;Lu;0;L;1F49 0301;;;;N;;;;1F45; 1F51;GREEK SMALL LETTER UPSILON WITH DASIA;Ll;0;L;03C5 0314;;;;N;;;1F59;;1F59 1F53;GREEK SMALL LETTER UPSILON WITH DASIA AND VARIA;Ll;0;L;1F51 0300;;;;N;;;1F5B;;1F5B 1F55;GREEK SMALL LETTER UPSILON WITH DASIA AND OXIA;Ll;0;L;1F51 0301;;;;N;;;1F5D;;1F5D 1F57;GREEK SMALL LETTER UPSILON WITH DASIA AND PERISPOMENI;Ll;0;L;1F51 0342;;;;N;;;1F5F;;1F5F 1F59;GREEK CAPITAL LETTER UPSILON WITH DASIA;Lu;0;L;03A5 0314;;;;N;;;;1F51; 1F5B;GREEK CAPITAL LETTER UPSILON WITH DASIA AND VARIA;Lu;0;L;1F59 0300;;;;N;;;;1F53; 1F5D;GREEK CAPITAL LETTER UPSILON WITH DASIA AND OXIA;Lu;0;L;1F59 0301;;;;N;;;;1F55; 1F5F;GREEK CAPITAL LETTER UPSILON WITH DASIA AND PERISPOMENI;Lu;0;L;1F59 0342;;;;N;;;;1F57; 1F60;GREEK SMALL LETTER OMEGA WITH PSILI;Ll;0;L;03C9 0313;;;;N;;;1F68;;1F68 1F61;GREEK SMALL LETTER OMEGA WITH DASIA;Ll;0;L;03C9 0314;;;;N;;;1F69;;1F69 1F62;GREEK SMALL LETTER OMEGA WITH PSILI AND VARIA;Ll;0;L;1F60 0300;;;;N;;;1F6A;;1F6A 1F63;GREEK SMALL LETTER OMEGA WITH DASIA AND VARIA;Ll;0;L;1F61 0300;;;;N;;;1F6B;;1F6B 1F64;GREEK SMALL LETTER OMEGA WITH PSILI AND OXIA;Ll;0;L;1F60 0301;;;;N;;;1F6C;;1F6C 1F65;GREEK SMALL LETTER OMEGA WITH DASIA AND OXIA;Ll;0;L;1F61 0301;;;;N;;;1F6D;;1F6D 1F66;GREEK SMALL LETTER OMEGA WITH PSILI AND PERISPOMENI;Ll;0;L;1F60 0342;;;;N;;;1F6E;;1F6E 1F67;GREEK SMALL LETTER OMEGA WITH DASIA AND PERISPOMENI;Ll;0;L;1F61 0342;;;;N;;;1F6F;;1F6F 1F68;GREEK CAPITAL LETTER OMEGA WITH PSILI;Lu;0;L;03A9 0313;;;;N;;;;1F60; 1F69;GREEK CAPITAL LETTER OMEGA WITH DASIA;Lu;0;L;03A9 0314;;;;N;;;;1F61; 1F6A;GREEK CAPITAL LETTER OMEGA WITH PSILI AND VARIA;Lu;0;L;1F68 0300;;;;N;;;;1F62; 1F6B;GREEK CAPITAL LETTER OMEGA WITH DASIA AND VARIA;Lu;0;L;1F69 0300;;;;N;;;;1F63; 1F6C;GREEK CAPITAL LETTER OMEGA WITH PSILI AND OXIA;Lu;0;L;1F68 0301;;;;N;;;;1F64; 1F6D;GREEK CAPITAL LETTER OMEGA WITH DASIA AND OXIA;Lu;0;L;1F69 0301;;;;N;;;;1F65; 1F6E;GREEK CAPITAL LETTER OMEGA WITH PSILI AND PERISPOMENI;Lu;0;L;1F68 0342;;;;N;;;;1F66; 1F6F;GREEK CAPITAL LETTER OMEGA WITH DASIA AND PERISPOMENI;Lu;0;L;1F69 0342;;;;N;;;;1F67; 1F70;GREEK SMALL LETTER ALPHA WITH VARIA;Ll;0;L;03B1 0300;;;;N;;;1FBA;;1FBA 1F71;GREEK SMALL LETTER ALPHA WITH OXIA;Ll;0;L;03B1 0301;;;;N;;;1FBB;;1FBB 1F72;GREEK SMALL LETTER EPSILON WITH VARIA;Ll;0;L;03B5 0300;;;;N;;;1FC8;;1FC8 1F73;GREEK SMALL LETTER EPSILON WITH OXIA;Ll;0;L;03B5 0301;;;;N;;;1FC9;;1FC9 1F74;GREEK SMALL LETTER ETA WITH VARIA;Ll;0;L;03B7 0300;;;;N;;;1FCA;;1FCA 1F75;GREEK SMALL LETTER ETA WITH OXIA;Ll;0;L;03B7 0301;;;;N;;;1FCB;;1FCB 1F76;GREEK SMALL LETTER IOTA WITH VARIA;Ll;0;L;03B9 0300;;;;N;;;1FDA;;1FDA 1F77;GREEK SMALL LETTER IOTA WITH OXIA;Ll;0;L;03B9 0301;;;;N;;;1FDB;;1FDB 1F78;GREEK SMALL LETTER OMICRON WITH VARIA;Ll;0;L;03BF 0300;;;;N;;;1FF8;;1FF8 1F79;GREEK SMALL LETTER OMICRON WITH OXIA;Ll;0;L;03BF 0301;;;;N;;;1FF9;;1FF9 1F7A;GREEK SMALL LETTER UPSILON WITH VARIA;Ll;0;L;03C5 0300;;;;N;;;1FEA;;1FEA 1F7B;GREEK SMALL LETTER UPSILON WITH OXIA;Ll;0;L;03C5 0301;;;;N;;;1FEB;;1FEB 1F7C;GREEK SMALL LETTER OMEGA WITH VARIA;Ll;0;L;03C9 0300;;;;N;;;1FFA;;1FFA 1F7D;GREEK SMALL LETTER OMEGA WITH OXIA;Ll;0;L;03C9 0301;;;;N;;;1FFB;;1FFB 1F80;GREEK SMALL LETTER ALPHA WITH PSILI AND YPOGEGRAMMENI;Ll;0;L;1F00 0345;;;;N;;;1F88;;1F88 1F81;GREEK SMALL LETTER ALPHA WITH DASIA AND YPOGEGRAMMENI;Ll;0;L;1F01 0345;;;;N;;;1F89;;1F89 1F82;GREEK SMALL LETTER ALPHA WITH PSILI AND VARIA AND YPOGEGRAMMENI;Ll;0;L;1F02 0345;;;;N;;;1F8A;;1F8A 1F83;GREEK SMALL LETTER ALPHA WITH DASIA AND VARIA AND YPOGEGRAMMENI;Ll;0;L;1F03 0345;;;;N;;;1F8B;;1F8B 1F84;GREEK SMALL LETTER ALPHA WITH PSILI AND OXIA AND YPOGEGRAMMENI;Ll;0;L;1F04 0345;;;;N;;;1F8C;;1F8C 1F85;GREEK SMALL LETTER ALPHA WITH DASIA AND OXIA AND YPOGEGRAMMENI;Ll;0;L;1F05 0345;;;;N;;;1F8D;;1F8D 1F86;GREEK SMALL LETTER ALPHA WITH PSILI AND PERISPOMENI AND YPOGEGRAMMENI;Ll;0;L;1F06 0345;;;;N;;;1F8E;;1F8E 1F87;GREEK SMALL LETTER ALPHA WITH DASIA AND PERISPOMENI AND YPOGEGRAMMENI;Ll;0;L;1F07 0345;;;;N;;;1F8F;;1F8F 1F88;GREEK CAPITAL LETTER ALPHA WITH PSILI AND PROSGEGRAMMENI;Lu;0;L;1F08 0345;;;;N;;;;1F80; 1F89;GREEK CAPITAL LETTER ALPHA WITH DASIA AND PROSGEGRAMMENI;Lu;0;L;1F09 0345;;;;N;;;;1F81; 1F8A;GREEK CAPITAL LETTER ALPHA WITH PSILI AND VARIA AND PROSGEGRAMMENI;Lu;0;L;1F0A 0345;;;;N;;;;1F82; 1F8B;GREEK CAPITAL LETTER ALPHA WITH DASIA AND VARIA AND PROSGEGRAMMENI;Lu;0;L;1F0B 0345;;;;N;;;;1F83; 1F8C;GREEK CAPITAL LETTER ALPHA WITH PSILI AND OXIA AND PROSGEGRAMMENI;Lu;0;L;1F0C 0345;;;;N;;;;1F84; 1F8D;GREEK CAPITAL LETTER ALPHA WITH DASIA AND OXIA AND PROSGEGRAMMENI;Lu;0;L;1F0D 0345;;;;N;;;;1F85; 1F8E;GREEK CAPITAL LETTER ALPHA WITH PSILI AND PERISPOMENI AND PROSGEGRAMMENI;Lu;0;L;1F0E 0345;;;;N;;;;1F86; 1F8F;GREEK CAPITAL LETTER ALPHA WITH DASIA AND PERISPOMENI AND PROSGEGRAMMENI;Lu;0;L;1F0F 0345;;;;N;;;;1F87; 1F90;GREEK SMALL LETTER ETA WITH PSILI AND YPOGEGRAMMENI;Ll;0;L;1F20 0345;;;;N;;;1F98;;1F98 1F91;GREEK SMALL LETTER ETA WITH DASIA AND YPOGEGRAMMENI;Ll;0;L;1F21 0345;;;;N;;;1F99;;1F99 1F92;GREEK SMALL LETTER ETA WITH PSILI AND VARIA AND YPOGEGRAMMENI;Ll;0;L;1F22 0345;;;;N;;;1F9A;;1F9A 1F93;GREEK SMALL LETTER ETA WITH DASIA AND VARIA AND YPOGEGRAMMENI;Ll;0;L;1F23 0345;;;;N;;;1F9B;;1F9B 1F94;GREEK SMALL LETTER ETA WITH PSILI AND OXIA AND YPOGEGRAMMENI;Ll;0;L;1F24 0345;;;;N;;;1F9C;;1F9C 1F95;GREEK SMALL LETTER ETA WITH DASIA AND OXIA AND YPOGEGRAMMENI;Ll;0;L;1F25 0345;;;;N;;;1F9D;;1F9D 1F96;GREEK SMALL LETTER ETA WITH PSILI AND PERISPOMENI AND YPOGEGRAMMENI;Ll;0;L;1F26 0345;;;;N;;;1F9E;;1F9E 1F97;GREEK SMALL LETTER ETA WITH DASIA AND PERISPOMENI AND YPOGEGRAMMENI;Ll;0;L;1F27 0345;;;;N;;;1F9F;;1F9F 1F98;GREEK CAPITAL LETTER ETA WITH PSILI AND PROSGEGRAMMENI;Lu;0;L;1F28 0345;;;;N;;;;1F90; 1F99;GREEK CAPITAL LETTER ETA WITH DASIA AND PROSGEGRAMMENI;Lu;0;L;1F29 0345;;;;N;;;;1F91; 1F9A;GREEK CAPITAL LETTER ETA WITH PSILI AND VARIA AND PROSGEGRAMMENI;Lu;0;L;1F2A 0345;;;;N;;;;1F92; 1F9B;GREEK CAPITAL LETTER ETA WITH DASIA AND VARIA AND PROSGEGRAMMENI;Lu;0;L;1F2B 0345;;;;N;;;;1F93; 1F9C;GREEK CAPITAL LETTER ETA WITH PSILI AND OXIA AND PROSGEGRAMMENI;Lu;0;L;1F2C 0345;;;;N;;;;1F94; 1F9D;GREEK CAPITAL LETTER ETA WITH DASIA AND OXIA AND PROSGEGRAMMENI;Lu;0;L;1F2D 0345;;;;N;;;;1F95; 1F9E;GREEK CAPITAL LETTER ETA WITH PSILI AND PERISPOMENI AND PROSGEGRAMMENI;Lu;0;L;1F2E 0345;;;;N;;;;1F96; 1F9F;GREEK CAPITAL LETTER ETA WITH DASIA AND PERISPOMENI AND PROSGEGRAMMENI;Lu;0;L;1F2F 0345;;;;N;;;;1F97; 1FA0;GREEK SMALL LETTER OMEGA WITH PSILI AND YPOGEGRAMMENI;Ll;0;L;1F60 0345;;;;N;;;1FA8;;1FA8 1FA1;GREEK SMALL LETTER OMEGA WITH DASIA AND YPOGEGRAMMENI;Ll;0;L;1F61 0345;;;;N;;;1FA9;;1FA9 1FA2;GREEK SMALL LETTER OMEGA WITH PSILI AND VARIA AND YPOGEGRAMMENI;Ll;0;L;1F62 0345;;;;N;;;1FAA;;1FAA 1FA3;GREEK SMALL LETTER OMEGA WITH DASIA AND VARIA AND YPOGEGRAMMENI;Ll;0;L;1F63 0345;;;;N;;;1FAB;;1FAB 1FA4;GREEK SMALL LETTER OMEGA WITH PSILI AND OXIA AND YPOGEGRAMMENI;Ll;0;L;1F64 0345;;;;N;;;1FAC;;1FAC 1FA5;GREEK SMALL LETTER OMEGA WITH DASIA AND OXIA AND YPOGEGRAMMENI;Ll;0;L;1F65 0345;;;;N;;;1FAD;;1FAD 1FA6;GREEK SMALL LETTER OMEGA WITH PSILI AND PERISPOMENI AND YPOGEGRAMMENI;Ll;0;L;1F66 0345;;;;N;;;1FAE;;1FAE 1FA7;GREEK SMALL LETTER OMEGA WITH DASIA AND PERISPOMENI AND YPOGEGRAMMENI;Ll;0;L;1F67 0345;;;;N;;;1FAF;;1FAF 1FA8;GREEK CAPITAL LETTER OMEGA WITH PSILI AND PROSGEGRAMMENI;Lu;0;L;1F68 0345;;;;N;;;;1FA0; 1FA9;GREEK CAPITAL LETTER OMEGA WITH DASIA AND PROSGEGRAMMENI;Lu;0;L;1F69 0345;;;;N;;;;1FA1; 1FAA;GREEK CAPITAL LETTER OMEGA WITH PSILI AND VARIA AND PROSGEGRAMMENI;Lu;0;L;1F6A 0345;;;;N;;;;1FA2; 1FAB;GREEK CAPITAL LETTER OMEGA WITH DASIA AND VARIA AND PROSGEGRAMMENI;Lu;0;L;1F6B 0345;;;;N;;;;1FA3; 1FAC;GREEK CAPITAL LETTER OMEGA WITH PSILI AND OXIA AND PROSGEGRAMMENI;Lu;0;L;1F6C 0345;;;;N;;;;1FA4; 1FAD;GREEK CAPITAL LETTER OMEGA WITH DASIA AND OXIA AND PROSGEGRAMMENI;Lu;0;L;1F6D 0345;;;;N;;;;1FA5; 1FAE;GREEK CAPITAL LETTER OMEGA WITH PSILI AND PERISPOMENI AND PROSGEGRAMMENI;Lu;0;L;1F6E 0345;;;;N;;;;1FA6; 1FAF;GREEK CAPITAL LETTER OMEGA WITH DASIA AND PERISPOMENI AND PROSGEGRAMMENI;Lu;0;L;1F6F 0345;;;;N;;;;1FA7; 1FB0;GREEK SMALL LETTER ALPHA WITH VRACHY;Ll;0;L;03B1 0306;;;;N;;;1FB8;;1FB8 1FB1;GREEK SMALL LETTER ALPHA WITH MACRON;Ll;0;L;03B1 0304;;;;N;;;1FB9;;1FB9 1FB3;GREEK SMALL LETTER ALPHA WITH YPOGEGRAMMENI;Ll;0;L;03B1 0345;;;;N;;;1FBC;;1FBC 1FB8;GREEK CAPITAL LETTER ALPHA WITH VRACHY;Lu;0;L;0391 0306;;;;N;;;;1FB0; 1FB9;GREEK CAPITAL LETTER ALPHA WITH MACRON;Lu;0;L;0391 0304;;;;N;;;;1FB1; 1FBA;GREEK CAPITAL LETTER ALPHA WITH VARIA;Lu;0;L;0391 0300;;;;N;;;;1F70; 1FBB;GREEK CAPITAL LETTER ALPHA WITH OXIA;Lu;0;L;0391 0301;;;;N;;;;1F71; 1FBC;GREEK CAPITAL LETTER ALPHA WITH PROSGEGRAMMENI;Lu;0;L;0391 0345;;;;N;;;;1FB3; 1FC3;GREEK SMALL LETTER ETA WITH YPOGEGRAMMENI;Ll;0;L;03B7 0345;;;;N;;;1FCC;;1FCC 1FC8;GREEK CAPITAL LETTER EPSILON WITH VARIA;Lu;0;L;0395 0300;;;;N;;;;1F72; 1FC9;GREEK CAPITAL LETTER EPSILON WITH OXIA;Lu;0;L;0395 0301;;;;N;;;;1F73; 1FCA;GREEK CAPITAL LETTER ETA WITH VARIA;Lu;0;L;0397 0300;;;;N;;;;1F74; 1FCB;GREEK CAPITAL LETTER ETA WITH OXIA;Lu;0;L;0397 0301;;;;N;;;;1F75; 1FCC;GREEK CAPITAL LETTER ETA WITH PROSGEGRAMMENI;Lu;0;L;0397 0345;;;;N;;;;1FC3; 1FD0;GREEK SMALL LETTER IOTA WITH VRACHY;Ll;0;L;03B9 0306;;;;N;;;1FD8;;1FD8 1FD1;GREEK SMALL LETTER IOTA WITH MACRON;Ll;0;L;03B9 0304;;;;N;;;1FD9;;1FD9 1FD8;GREEK CAPITAL LETTER IOTA WITH VRACHY;Lu;0;L;0399 0306;;;;N;;;;1FD0; 1FD9;GREEK CAPITAL LETTER IOTA WITH MACRON;Lu;0;L;0399 0304;;;;N;;;;1FD1; 1FDA;GREEK CAPITAL LETTER IOTA WITH VARIA;Lu;0;L;0399 0300;;;;N;;;;1F76; 1FDB;GREEK CAPITAL LETTER IOTA WITH OXIA;Lu;0;L;0399 0301;;;;N;;;;1F77; 1FE0;GREEK SMALL LETTER UPSILON WITH VRACHY;Ll;0;L;03C5 0306;;;;N;;;1FE8;;1FE8 1FE1;GREEK SMALL LETTER UPSILON WITH MACRON;Ll;0;L;03C5 0304;;;;N;;;1FE9;;1FE9 1FE5;GREEK SMALL LETTER RHO WITH DASIA;Ll;0;L;03C1 0314;;;;N;;;1FEC;;1FEC 1FE8;GREEK CAPITAL LETTER UPSILON WITH VRACHY;Lu;0;L;03A5 0306;;;;N;;;;1FE0; 1FE9;GREEK CAPITAL LETTER UPSILON WITH MACRON;Lu;0;L;03A5 0304;;;;N;;;;1FE1; 1FEA;GREEK CAPITAL LETTER UPSILON WITH VARIA;Lu;0;L;03A5 0300;;;;N;;;;1F7A; 1FEB;GREEK CAPITAL LETTER UPSILON WITH OXIA;Lu;0;L;03A5 0301;;;;N;;;;1F7B; 1FEC;GREEK CAPITAL LETTER RHO WITH DASIA;Lu;0;L;03A1 0314;;;;N;;;;1FE5; 1FF3;GREEK SMALL LETTER OMEGA WITH YPOGEGRAMMENI;Ll;0;L;03C9 0345;;;;N;;;1FFC;;1FFC 1FF8;GREEK CAPITAL LETTER OMICRON WITH VARIA;Lu;0;L;039F 0300;;;;N;;;;1F78; 1FF9;GREEK CAPITAL LETTER OMICRON WITH OXIA;Lu;0;L;039F 0301;;;;N;;;;1F79; 1FFA;GREEK CAPITAL LETTER OMEGA WITH VARIA;Lu;0;L;03A9 0300;;;;N;;;;1F7C; 1FFB;GREEK CAPITAL LETTER OMEGA WITH OXIA;Lu;0;L;03A9 0301;;;;N;;;;1F7D; 1FFC;GREEK CAPITAL LETTER OMEGA WITH PROSGEGRAMMENI;Lu;0;L;03A9 0345;;;;N;;;;1FF3; 2160;ROMAN NUMERAL ONE;No;0;L; 0049;;;1;N;;;;2170; 2161;ROMAN NUMERAL TWO;No;0;L; 0049 0049;;;2;N;;;;2171; 2162;ROMAN NUMERAL THREE;No;0;L; 0049 0049 0049;;;3;N;;;;2172; 2163;ROMAN NUMERAL FOUR;No;0;L; 0049 0056;;;4;N;;;;2173; 2164;ROMAN NUMERAL FIVE;No;0;L; 0056;;;5;N;;;;2174; 2165;ROMAN NUMERAL SIX;No;0;L; 0056 0049;;;6;N;;;;2175; 2166;ROMAN NUMERAL SEVEN;No;0;L; 0056 0049 0049;;;7;N;;;;2176; 2167;ROMAN NUMERAL EIGHT;No;0;L; 0056 0049 0049 0049;;;8;N;;;;2177; 2168;ROMAN NUMERAL NINE;No;0;L; 0049 0058;;;9;N;;;;2178; 2169;ROMAN NUMERAL TEN;No;0;L; 0058;;;10;N;;;;2179; 216A;ROMAN NUMERAL ELEVEN;No;0;L; 0058 0049;;;11;N;;;;217A; 216B;ROMAN NUMERAL TWELVE;No;0;L; 0058 0049 0049;;;12;N;;;;217B; 216C;ROMAN NUMERAL FIFTY;No;0;L; 004C;;;50;N;;;;217C; 216D;ROMAN NUMERAL ONE HUNDRED;No;0;L; 0043;;;100;N;;;;217D; 216E;ROMAN NUMERAL FIVE HUNDRED;No;0;L; 0044;;;500;N;;;;217E; 216F;ROMAN NUMERAL ONE THOUSAND;No;0;L; 004D;;;1000;N;;;;217F; 2170;SMALL ROMAN NUMERAL ONE;No;0;L; 0069;;;1;N;;;2160;;2160 2171;SMALL ROMAN NUMERAL TWO;No;0;L; 0069 0069;;;2;N;;;2161;;2161 2172;SMALL ROMAN NUMERAL THREE;No;0;L; 0069 0069 0069;;;3;N;;;2162;;2162 2173;SMALL ROMAN NUMERAL FOUR;No;0;L; 0069 0076;;;4;N;;;2163;;2163 2174;SMALL ROMAN NUMERAL FIVE;No;0;L; 0076;;;5;N;;;2164;;2164 2175;SMALL ROMAN NUMERAL SIX;No;0;L; 0076 0069;;;6;N;;;2165;;2165 2176;SMALL ROMAN NUMERAL SEVEN;No;0;L; 0076 0069 0069;;;7;N;;;2166;;2166 2177;SMALL ROMAN NUMERAL EIGHT;No;0;L; 0076 0069 0069 0069;;;8;N;;;2167;;2167 2178;SMALL ROMAN NUMERAL NINE;No;0;L; 0069 0078;;;9;N;;;2168;;2168 2179;SMALL ROMAN NUMERAL TEN;No;0;L; 0078;;;10;N;;;2169;;2169 217A;SMALL ROMAN NUMERAL ELEVEN;No;0;L; 0078 0069;;;11;N;;;216A;;216A 217B;SMALL ROMAN NUMERAL TWELVE;No;0;L; 0078 0069 0069;;;12;N;;;216B;;216B 217C;SMALL ROMAN NUMERAL FIFTY;No;0;L; 006C;;;50;N;;;216C;;216C 217D;SMALL ROMAN NUMERAL ONE HUNDRED;No;0;L; 0063;;;100;N;;;216D;;216D 217E;SMALL ROMAN NUMERAL FIVE HUNDRED;No;0;L; 0064;;;500;N;;;216E;;216E 217F;SMALL ROMAN NUMERAL ONE THOUSAND;No;0;L; 006D;;;1000;N;;;216F;;216F 24B6;CIRCLED LATIN CAPITAL LETTER A;Lu;0;ON; 0041;;;;N;;;;24D0; 24B7;CIRCLED LATIN CAPITAL LETTER B;Lu;0;ON; 0042;;;;N;;;;24D1; 24B8;CIRCLED LATIN CAPITAL LETTER C;Lu;0;ON; 0043;;;;N;;;;24D2; 24B9;CIRCLED LATIN CAPITAL LETTER D;Lu;0;ON; 0044;;;;N;;;;24D3; 24BA;CIRCLED LATIN CAPITAL LETTER E;Lu;0;ON; 0045;;;;N;;;;24D4; 24BB;CIRCLED LATIN CAPITAL LETTER F;Lu;0;ON; 0046;;;;N;;;;24D5; 24BC;CIRCLED LATIN CAPITAL LETTER G;Lu;0;ON; 0047;;;;N;;;;24D6; 24BD;CIRCLED LATIN CAPITAL LETTER H;Lu;0;ON; 0048;;;;N;;;;24D7; 24BE;CIRCLED LATIN CAPITAL LETTER I;Lu;0;ON; 0049;;;;N;;;;24D8; 24BF;CIRCLED LATIN CAPITAL LETTER J;Lu;0;ON; 004A;;;;N;;;;24D9; 24C0;CIRCLED LATIN CAPITAL LETTER K;Lu;0;ON; 004B;;;;N;;;;24DA; 24C1;CIRCLED LATIN CAPITAL LETTER L;Lu;0;ON; 004C;;;;N;;;;24DB; 24C2;CIRCLED LATIN CAPITAL LETTER M;Lu;0;ON; 004D;;;;N;;;;24DC; 24C3;CIRCLED LATIN CAPITAL LETTER N;Lu;0;ON; 004E;;;;N;;;;24DD; 24C4;CIRCLED LATIN CAPITAL LETTER O;Lu;0;ON; 004F;;;;N;;;;24DE; 24C5;CIRCLED LATIN CAPITAL LETTER P;Lu;0;ON; 0050;;;;N;;;;24DF; 24C6;CIRCLED LATIN CAPITAL LETTER Q;Lu;0;ON; 0051;;;;N;;;;24E0; 24C7;CIRCLED LATIN CAPITAL LETTER R;Lu;0;ON; 0052;;;;N;;;;24E1; 24C8;CIRCLED LATIN CAPITAL LETTER S;Lu;0;ON; 0053;;;;N;;;;24E2; 24C9;CIRCLED LATIN CAPITAL LETTER T;Lu;0;ON; 0054;;;;N;;;;24E3; 24CA;CIRCLED LATIN CAPITAL LETTER U;Lu;0;ON; 0055;;;;N;;;;24E4; 24CB;CIRCLED LATIN CAPITAL LETTER V;Lu;0;ON; 0056;;;;N;;;;24E5; 24CC;CIRCLED LATIN CAPITAL LETTER W;Lu;0;ON; 0057;;;;N;;;;24E6; 24CD;CIRCLED LATIN CAPITAL LETTER X;Lu;0;ON; 0058;;;;N;;;;24E7; 24CE;CIRCLED LATIN CAPITAL LETTER Y;Lu;0;ON; 0059;;;;N;;;;24E8; 24CF;CIRCLED LATIN CAPITAL LETTER Z;Lu;0;ON; 005A;;;;N;;;;24E9; 24D0;CIRCLED LATIN SMALL LETTER A;Ll;0;ON; 0061;;;;N;;;24B6;;24B6 24D1;CIRCLED LATIN SMALL LETTER B;Ll;0;ON; 0062;;;;N;;;24B7;;24B7 24D2;CIRCLED LATIN SMALL LETTER C;Ll;0;ON; 0063;;;;N;;;24B8;;24B8 24D3;CIRCLED LATIN SMALL LETTER D;Ll;0;ON; 0064;;;;N;;;24B9;;24B9 24D4;CIRCLED LATIN SMALL LETTER E;Ll;0;ON; 0065;;;;N;;;24BA;;24BA 24D5;CIRCLED LATIN SMALL LETTER F;Ll;0;ON; 0066;;;;N;;;24BB;;24BB 24D6;CIRCLED LATIN SMALL LETTER G;Ll;0;ON; 0067;;;;N;;;24BC;;24BC 24D7;CIRCLED LATIN SMALL LETTER H;Ll;0;ON; 0068;;;;N;;;24BD;;24BD 24D8;CIRCLED LATIN SMALL LETTER I;Ll;0;ON; 0069;;;;N;;;24BE;;24BE 24D9;CIRCLED LATIN SMALL LETTER J;Ll;0;ON; 006A;;;;N;;;24BF;;24BF 24DA;CIRCLED LATIN SMALL LETTER K;Ll;0;ON; 006B;;;;N;;;24C0;;24C0 24DB;CIRCLED LATIN SMALL LETTER L;Ll;0;ON; 006C;;;;N;;;24C1;;24C1 24DC;CIRCLED LATIN SMALL LETTER M;Ll;0;ON; 006D;;;;N;;;24C2;;24C2 24DD;CIRCLED LATIN SMALL LETTER N;Ll;0;ON; 006E;;;;N;;;24C3;;24C3 24DE;CIRCLED LATIN SMALL LETTER O;Ll;0;ON; 006F;;;;N;;;24C4;;24C4 24DF;CIRCLED LATIN SMALL LETTER P;Ll;0;ON; 0070;;;;N;;;24C5;;24C5 24E0;CIRCLED LATIN SMALL LETTER Q;Ll;0;ON; 0071;;;;N;;;24C6;;24C6 24E1;CIRCLED LATIN SMALL LETTER R;Ll;0;ON; 0072;;;;N;;;24C7;;24C7 24E2;CIRCLED LATIN SMALL LETTER S;Ll;0;ON; 0073;;;;N;;;24C8;;24C8 24E3;CIRCLED LATIN SMALL LETTER T;Ll;0;ON; 0074;;;;N;;;24C9;;24C9 24E4;CIRCLED LATIN SMALL LETTER U;Ll;0;ON; 0075;;;;N;;;24CA;;24CA 24E5;CIRCLED LATIN SMALL LETTER V;Ll;0;ON; 0076;;;;N;;;24CB;;24CB 24E6;CIRCLED LATIN SMALL LETTER W;Ll;0;ON; 0077;;;;N;;;24CC;;24CC 24E7;CIRCLED LATIN SMALL LETTER X;Ll;0;ON; 0078;;;;N;;;24CD;;24CD 24E8;CIRCLED LATIN SMALL LETTER Y;Ll;0;ON; 0079;;;;N;;;24CE;;24CE 24E9;CIRCLED LATIN SMALL LETTER Z;Ll;0;ON; 007A;;;;N;;;24CF;;24CF FF21;FULLWIDTH LATIN CAPITAL LETTER A;Lu;0;L; 0041;;;;N;;;;FF41; FF22;FULLWIDTH LATIN CAPITAL LETTER B;Lu;0;L; 0042;;;;N;;;;FF42; FF23;FULLWIDTH LATIN CAPITAL LETTER C;Lu;0;L; 0043;;;;N;;;;FF43; FF24;FULLWIDTH LATIN CAPITAL LETTER D;Lu;0;L; 0044;;;;N;;;;FF44; FF25;FULLWIDTH LATIN CAPITAL LETTER E;Lu;0;L; 0045;;;;N;;;;FF45; FF26;FULLWIDTH LATIN CAPITAL LETTER F;Lu;0;L; 0046;;;;N;;;;FF46; FF27;FULLWIDTH LATIN CAPITAL LETTER G;Lu;0;L; 0047;;;;N;;;;FF47; FF28;FULLWIDTH LATIN CAPITAL LETTER H;Lu;0;L; 0048;;;;N;;;;FF48; FF29;FULLWIDTH LATIN CAPITAL LETTER I;Lu;0;L; 0049;;;;N;;;;FF49; FF2A;FULLWIDTH LATIN CAPITAL LETTER J;Lu;0;L; 004A;;;;N;;;;FF4A; FF2B;FULLWIDTH LATIN CAPITAL LETTER K;Lu;0;L; 004B;;;;N;;;;FF4B; FF2C;FULLWIDTH LATIN CAPITAL LETTER L;Lu;0;L; 004C;;;;N;;;;FF4C; FF2D;FULLWIDTH LATIN CAPITAL LETTER M;Lu;0;L; 004D;;;;N;;;;FF4D; FF2E;FULLWIDTH LATIN CAPITAL LETTER N;Lu;0;L; 004E;;;;N;;;;FF4E; FF2F;FULLWIDTH LATIN CAPITAL LETTER O;Lu;0;L; 004F;;;;N;;;;FF4F; FF30;FULLWIDTH LATIN CAPITAL LETTER P;Lu;0;L; 0050;;;;N;;;;FF50; FF31;FULLWIDTH LATIN CAPITAL LETTER Q;Lu;0;L; 0051;;;;N;;;;FF51; FF32;FULLWIDTH LATIN CAPITAL LETTER R;Lu;0;L; 0052;;;;N;;;;FF52; FF33;FULLWIDTH LATIN CAPITAL LETTER S;Lu;0;L; 0053;;;;N;;;;FF53; FF34;FULLWIDTH LATIN CAPITAL LETTER T;Lu;0;L; 0054;;;;N;;;;FF54; FF35;FULLWIDTH LATIN CAPITAL LETTER U;Lu;0;L; 0055;;;;N;;;;FF55; FF36;FULLWIDTH LATIN CAPITAL LETTER V;Lu;0;L; 0056;;;;N;;;;FF56; FF37;FULLWIDTH LATIN CAPITAL LETTER W;Lu;0;L; 0057;;;;N;;;;FF57; FF38;FULLWIDTH LATIN CAPITAL LETTER X;Lu;0;L; 0058;;;;N;;;;FF58; FF39;FULLWIDTH LATIN CAPITAL LETTER Y;Lu;0;L; 0059;;;;N;;;;FF59; FF3A;FULLWIDTH LATIN CAPITAL LETTER Z;Lu;0;L; 005A;;;;N;;;;FF5A; FF41;FULLWIDTH LATIN SMALL LETTER A;Ll;0;L; 0061;;;;N;;;FF21;;FF21 FF42;FULLWIDTH LATIN SMALL LETTER B;Ll;0;L; 0062;;;;N;;;FF22;;FF22 FF43;FULLWIDTH LATIN SMALL LETTER C;Ll;0;L; 0063;;;;N;;;FF23;;FF23 FF44;FULLWIDTH LATIN SMALL LETTER D;Ll;0;L; 0064;;;;N;;;FF24;;FF24 FF45;FULLWIDTH LATIN SMALL LETTER E;Ll;0;L; 0065;;;;N;;;FF25;;FF25 FF46;FULLWIDTH LATIN SMALL LETTER F;Ll;0;L; 0066;;;;N;;;FF26;;FF26 FF47;FULLWIDTH LATIN SMALL LETTER G;Ll;0;L; 0067;;;;N;;;FF27;;FF27 FF48;FULLWIDTH LATIN SMALL LETTER H;Ll;0;L; 0068;;;;N;;;FF28;;FF28 FF49;FULLWIDTH LATIN SMALL LETTER I;Ll;0;L; 0069;;;;N;;;FF29;;FF29 FF4A;FULLWIDTH LATIN SMALL LETTER J;Ll;0;L; 006A;;;;N;;;FF2A;;FF2A FF4B;FULLWIDTH LATIN SMALL LETTER K;Ll;0;L; 006B;;;;N;;;FF2B;;FF2B FF4C;FULLWIDTH LATIN SMALL LETTER L;Ll;0;L; 006C;;;;N;;;FF2C;;FF2C FF4D;FULLWIDTH LATIN SMALL LETTER M;Ll;0;L; 006D;;;;N;;;FF2D;;FF2D FF4E;FULLWIDTH LATIN SMALL LETTER N;Ll;0;L; 006E;;;;N;;;FF2E;;FF2E FF4F;FULLWIDTH LATIN SMALL LETTER O;Ll;0;L; 006F;;;;N;;;FF2F;;FF2F FF50;FULLWIDTH LATIN SMALL LETTER P;Ll;0;L; 0070;;;;N;;;FF30;;FF30 FF51;FULLWIDTH LATIN SMALL LETTER Q;Ll;0;L; 0071;;;;N;;;FF31;;FF31 FF52;FULLWIDTH LATIN SMALL LETTER R;Ll;0;L; 0072;;;;N;;;FF32;;FF32 FF53;FULLWIDTH LATIN SMALL LETTER S;Ll;0;L; 0073;;;;N;;;FF33;;FF33 FF54;FULLWIDTH LATIN SMALL LETTER T;Ll;0;L; 0074;;;;N;;;FF34;;FF34 FF55;FULLWIDTH LATIN SMALL LETTER U;Ll;0;L; 0075;;;;N;;;FF35;;FF35 FF56;FULLWIDTH LATIN SMALL LETTER V;Ll;0;L; 0076;;;;N;;;FF36;;FF36 FF57;FULLWIDTH LATIN SMALL LETTER W;Ll;0;L; 0077;;;;N;;;FF37;;FF37 FF58;FULLWIDTH LATIN SMALL LETTER X;Ll;0;L; 0078;;;;N;;;FF38;;FF38 FF59;FULLWIDTH LATIN SMALL LETTER Y;Ll;0;L; 0079;;;;N;;;FF39;;FF39 FF5A;FULLWIDTH LATIN SMALL LETTER Z;Ll;0;L; 007A;;;;N;;;FF3A;;FF3A From: lee@sq.com Date: Mon, 4 Nov 96 01:08:36 EST To: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org Subject: Re: Case sensitivity in markup Note that the lower case mapping doesn't work for the various forms of French -- as it notes. Also, using lower case as the canonical form, whilst better than upper case in terms of having more distinct symbols, is also not backwards compatible with SGML. I think that case sensitivity is easier to explain, works in all cases, and can be represented by a confrming SGML declaration. On the implications of case folding, I'd say ask Martin Duerst or Glenn Adams directly. Lee To: bosak@atlantic-83.eng.sun.com (Jon Bosak), w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: Case sensitivity in markup Date: Mon, 4 Nov 1996 09:10:35 +0000 At 20:14 3/11/96 -0800, Jon Bosak wrote: >OK, internationalization experts, here's your chance to help out in a >big way. > >The ERB has considered the issue of case sensitivity in markup at some >length and has boiled down the options to just two alternatives: > >1. Full case sensitivity in markup. > >2. Case-folding using the Unicode rules. > >We would like everyone on the WG who has a qualified opinion on this >issue to state which of these alternatives is preferable and why. > >The following points should be borne in mind: > >1. Option 1 has tremendous backward-compatibility implications. >Important as compatibility is, however, the primary purpose of this >activity is to enable standardized structured data to be generated and >served out to Web clients, not to preserve existing legacy data >unchanged. > >2. The Unicode method folds uppercase to lowercase (see below). ISO >8879 folds lowercase to uppercase; that is, it defines uppercase >substitution (Clause 13.4.5) but not lowercase substitution. My initial reaction to the Unicode tables you so thoughtfully supplied is that there is nothing to stop them being used for lowercase to uppercase substitution as for every lowercase character the uppercase equivalent is identified where relevant. I note that for characters such as ß, which is not a one-to-one mapping, no entry is specified in the table, so presumably the lowercase form would always be retained. The Unix tables also provide a useful form of normalization for the conversion of letter+diacritic pairs into "normalized" characters. Your question really boils down to "what does compatibility mean". If we want comatibility with HTML then we need to allow tags to be entered in both shifts, and be able to match a cap start-tag with a lowercase end-tag for any element. For SGML compatibility we could presume that the file is normalized prior to being passed to the web as an XML file. Such normalization would turn any lowercase name characters to caps if NAMECASE GENERAL YES was in force. We know we have to change the SGML DTD to make make it compatible for XML. One such change, therefore, would be that all element, attribute, etc, names (except entity names) would have to be capitalized. Using this simple rule the default output for SGML files would be the capitalized names, and we could use option 1 within XML. If we adopt a case sensitive approach for XML, HTML files that have been normalized using the rules applied for existing SGML files could also be treated as if they would have caps only markup. New XML files should not be a problem if we apply the case sensitive approach, especially if we recommended use of lowercase characters for names. This would have the advantage of clearly distinguishing normalized SGML and HTML files from specially created XML files, and would allow us to maximize the number of characters available for markup. The problem with option 2 is that it is unclear what the rules are for converting from uppercase to lowercase are. In a French word, for example, you cannot presume that a cap E will convert to a lowercase e on conversion; it may well need to be converted to an accented character, depending on the word it has been used in. A third option would be to use the Unicode tables to convert lowercase characters to their cap equivalents, reducing the number of markup characters to those for which an equivalent has been defined. This would probably lead to fewer anomalies than converting caps to lowercase, given that most accented characters have cap equivalents within 10646, but would lead to anomalies due to locale-specific changes in the way capitalization is done. Whilst this approach would have the advantage of making XML backward compatible with the existing version of SGML I'm not convinced that it would remain compatible for SGML97++. The one question I have is "Why the rush?" Given that WG8 may discuss this issue next week, while i18n will discuss it the week after, could we not hold this discussion off for a fortnight to allow a more detailed discussion of it. I would particularly like to raise this question at the i18n conference in Seville, probably on November 21st when the problems of the internationalization of HTML are due to be discussed. It seems silly to force XML members to answer this question before the acknowledged experts in the field meet to discuss it. Martin Bryan ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ From: Ken Holman To: "'w3c-sgml-wg@w3.org'" Subject: RE: Case sensitivity in markup Date: Mon, 4 Nov 1996 09:23:33 -0500 It will be easier to understand/explain/teach case sensitivity if full sensitivity is required. Sensitivity to sensitivity can be judged in XML1.0 for reconsideration in future versions ... it would be difficult to go "the other way" and later decide that the rules are sufficiently complex (or conflicting) to require case sensitivity. ......... 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----- >---------- >From: > bosak@atlantic-83.Eng.Sun.COM[SMTP:bosak@atlantic-83.Eng.Sun.COM] >Sent: Sunday, November 03, 1996 23:14 >To: w3c-sgml-wg@w3.org >Subject: Case sensitivity in markup > ... > >The ERB has considered the issue of case sensitivity in markup at some >length and has boiled down the options to just two alternatives: > >1. Full case sensitivity in markup. > >2. Case-folding using the Unicode rules. > ... > >Due to the short amount of time remaining before we freeze the XML 1.0 >specification, we need your input on this question as soon as >possible. > >Jon > Date: Mon, 4 Nov 96 10:29:31 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: Case sensitivity in markup I'm not so worried about case sensitivity from an implementors point of view--though I do think this, along with disallowing the omitted tag minimization field, are the two biggest stumbling blocks that current SGML tools and applications will have wrt XML--but I'm more worried about the end user here. And it's not just a legacy issue. I looked at the HTML file Tim sent out for the draft XML spec. It mixes case in the tag names, for example [ISO 8879] I just think so many users will be surprised by names/tokens not matching because of case. Things like "yes" not being equal to "YES" and not closing . And all the 8879 keywords having to be in uppercase. And users will have to be more careful when creating style sheets, since they will have to have the element names, attribute names, and attribute values match exactly. To do things like testing if the attribute name is "yes" or "black" or "ID45017" will require the use of "anycase()" sorts of functions or explicit comparisons for all possible combinations of lettercase mixing. I'm quite sensitive to the I18N issues, but let's remember that the whole point of case folding is to make life easier for the end users in general, and there are a lot of them out there for whom losing case folding will make their lives a lot harder. No, it's not hard to "explain" case sensitivity, that's not the point. Every time a user trips over not closing , they'll say, "oh yes, I understand why, it's that @&%$*# rule about case sensitivity in XML--they fixed some of the problems with SGML, so in exchange, they invented some new ones of their own." Date: Mon, 4 Nov 96 10:39:45 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: OMITTAG specifications in element declarations I would like to see the omitted tag minimization allowed in XML DTDs. I fail to see how allowing and ignoring this field will make the implementors job (that is, those implementors whose tools even read the DTD, since there is a whole class which will not) that much harder. I do see, however, how it can make the DTD maintainters job much harder and how it will make SGML compatibility more difficult for very little gain. All the DTD reading and writing tools that use an implied SGML declaration with OMITTAG YES--as well as all those with OMITTAG NO but that write out the omitted tag minimization anyway as permitted by 8879--will not produce valid XML DTDs even if the DTD writer is careful to create models that are otherwise valid per XML. If I were writing an XML tool that was going to read a DTD, I'd sure spend the extra 10 minutes to program it to read and ignore an optional omitted tag minimization field. And once a couple tools do that, users will start assuming it's okay to have that field, and then the tools that don't do it will just be considered suboptimal. Why set ourselves up for this bit of gratuitous non-interoperability? Date: Mon, 4 Nov 1996 10:55:30 -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: Case sensitivity in markup [Martin Bryan:] | The one question I have is "Why the rush?" Given that WG8 may discuss | this issue next week, while i18n will discuss it the week after, could | we not hold this discussion off for a fortnight to allow a more | detailed discussion of it. I would particularly like to raise this | question at the i18n conference in Seville, probably on November 21st | when the problems of the internationalization of HTML are due to be | discussed. It seems silly to force XML members to answer this question | before the acknowledged experts in the field meet to discuss it. Two reasons: 1. We are releasing a spec on November 19 and this issue has to be addressed in it. 2. This will either force the "acknowledged experts in the field" to stop discussing this and come to a decision, or it will give us a direction in which to proceed. It takes some time for a W3C Working Draft to become a Proposed Recommendation and finally an official Recommendation. If the I18N experts come to a decision that differs >from the choice we make now, then we can change the Working Draft. If they don't, that's OK, too. But in any event, we are not dependent on their schedule. Jon From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Michael Sperberg-McQueen Cc: W3C SGML Working Group Subject: Re: ERB decision, 31 October 1996 Date: Tue, 05 Nov 1996 05:24:24 GMT On Thu, 31 Oct 96 13:01:34 CST, Michael Sperberg-McQueen wrote: > 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. I have some questions about this: 1. Is a "reference to an external text entity" a syntactic entity reference, a general entity name attribute value, or both? 2. Will XML require that a syntactic entity reference to an external text entity yield the identical text every time it is resolved? This rule is a requirement for 8879 conformance. (It is not an issue of validation, nor is it related to the time or context of parsing.) A fundamental principle of SGML (perhaps *the* fundamental principle) is that parsing the *SGML text* of a document produces the same data, every single time. Without that principle, SGML documents aren't portable and reusable. (Data entities aren't affected by this rule, since they aren't parsed in context.) The SGML user can distinguish constant text from variable data by the syntax. Syntactic entity references must always resolve to the same text; entity attributes need not. (This has nothing to do with validation.) Even though parsers cannot enforce this distinction, users are entitled to express it in their markup, as it could be meaningful for document management applications. -- 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, 5 Nov 1996 11:18:33 -0400 To: W3C SGML Working Group From: dgd@cs.bu.edu (David G. Durand) Subject: Re: ERB decision, 31 October 1996 At 1:24 AM 11/5/96, Charles F. Goldfarb wrote: >On Thu, 31 Oct 96 13:01:34 CST, Michael Sperberg-McQueen >wrote: >> 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. >1. Is a "reference to an external text entity" a syntactic entity reference, a >general entity name attribute value, or both? A syntaxctic entity refrence, as the discussion makes clear. >2. Will XML require that a syntactic entity reference to an external text >entity >yield the identical text every time it is resolved? This rule is a requirement >for 8879 conformance. (It is not an issue of validation, nor is it related to >the time or context of parsing.) As far as the text says, no. What is not forbidden is permitted. Therefore the requirement is wisely not made! > A fundamental principle of SGML (perhaps *the* fundamental principle) is that >parsing the *SGML text* of a document produces the same data, every single >time. >Without that principle, SGML documents aren't portable and reusable. (Data >entities aren't affected by this rule, since they aren't parsed in context.) This makes some sense in a DP environment with fixed files for entities, but not on the web, as I have argued before. >The SGML user can distinguish constant text from variable data by the syntax. >Syntactic entity references must always resolve to the same text; entity >attributes need not. (This has nothing to do with validation.) Entity attributes are not _included_ in the document however, so the functionality of a normal entity reference is not provided. >Even though parsers cannot enforce this distinction, users are entitled to >express it in their markup, as it could be meaningful for document management >applications. They can create such systems on top of XML if it is useful. I do not expect that anyone will be soe moved. We should defnitely not attempt the foolishness of wagging our fingers at users and saying "naughty, naughty, you used variable replacement text!" XML requirements are requirements for the parser to enforce conditions. Ipso facto, we cannot make requirements that we cannot enforce. -- 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: Tue, 05 Nov 1996 11:49:40 -0500 To: dgd@cs.bu.edu (David G. Durand), W3C SGML Working Group From: "Eve L. Maler" Subject: Re: ERB decision, 31 October 1996 At 11:18 AM 11/5/96 -0400, David G. Durand wrote: >At 1:24 AM 11/5/96, Charles F. Goldfarb wrote: >> A fundamental principle of SGML (perhaps *the* fundamental principle) is that >>parsing the *SGML text* of a document produces the same data, every single >>time. >>Without that principle, SGML documents aren't portable and reusable. (Data >>entities aren't affected by this rule, since they aren't parsed in context.) > >This makes some sense in a DP environment with fixed files for entities, >but not on the web, as I have argued before. I'm really confused by the assertion that parsing the SGML text produces "the same data." The same data as what? If you exclude cases where the entity is manually or automatically created/revised (you have to have created the entity somehow, and once created, it might need to be changed), then this is a tautology: It's the same data as itself. What am I missing? Eve Date: Tue, 05 Nov 1996 09:51:18 -0800 To: W3C SGML Working Group From: Tim Bray Subject: Re: ERB decision, 31 October 1996 Sign me up as also not getting what Charles is driving at here. When I use text entities, it has almost always been in support of authoring, with a hub document along the lines of ... &intro; &documents; &elements; &entities; ... With the entities so named typically being subject to constant revision; so it would be surprising for the to document stay unchanged between two runs of the parser; in fact, since the parser is mostly used for validation and typesetting, you usually run it *because* you've been changing entities. I don't *think* this practice is exotic and weird... like Eve, I feel like I'm missing something obvious. In case it's not obvious, the ERB (and I think this group) do *not* think that in general the SGML external text entity semantics are obviously correct for delivery of distributed network documents; the most recent change in the spec language was precisely to avoid making browsers deal with them. But it's also not obvious that the semantics are not correct. Date: Tue, 5 Nov 1996 11:45:48 -0800 (PST) From: "Deborah A. Lapeyre" Subject: Parameter Entities To: Tim Bray cc: W3C SGML Working Group Quick, before a final vote can go in, we would like to plead for both internal and external paramter entities. The utility of these to a creator of modular DTDs is obvious. Therefore, I need them, want them, would give them up only with regret. May I please hear the other side? ARE they (particluarly the external) very hard to build into a parser or perl hack. Please be specific? Is the objection to external based on Web resolving? Is their presence a real problem for smaller, simpler implementations? --Debbie Lapeyre ======================================================================= 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 ======================================================================= To: w3c-sgml-wg@w3.org Subject: Re: Parameter Entities Date: Tue, 05 Nov 1996 13:16:17 -0800 From: Joe English Deborah A. Lapeyre wrote: > > Quick, before a final vote can go in, we would like to plead for both > internal and external paramter entities. The utility of these to a > creator of modular DTDs is obvious. Therefore, I need them, want them, > would give them up only with regret. Heartily seconded. > May I please hear the other side? ARE they (particluarly the external) > very hard to build into a parser or perl hack. Please be specific? > Is the objection to external based on Web resolving? Dealing with parameter entities takes a bit of forethought, but it doesn't seem to be overwhelmingly difficult to implement. You can't just treat the input as a single stream of characters: you have to either keep a stack of open entities, push back the replacement text as soon as an entity is referenced (as in Earl Hood's Perl-SGML tools), or do something else. This is tough only if you insist on using LEX and YACC. It's pretty straightforward with a hand-written scanner, and I suspect that one could get FLEX to handle it too with a little effort. The major complication is, as you mentioned, potential network latency in resolving external entities. If we add the restriction that external parameter entities may not contain definitions for other parameter entities that are later used in the referring entity, and that external parameter entities must consist of one or more complete markup declarations (which is usually the case), then resolution of external parameter entities can be deferred just like external general entities. For example: %Sub; "sub.dtd" cannot declare any parameter entities that are used later on in "main.dtd", and constructs like: are only be allowed if %body.content; is an internal entity. Given these restrictions, external parameter entities can be treated much the same as external general entities in XML. > Is their presence a real problem for smaller, simpler implementations? I would hypothesize that the smaller, simpler applications -- the ones we expect CS majors to be able to write in a week -- will for the most part not read the DTD at all. --Joe English jenglish@crl.com Date: Tue, 05 Nov 1996 15:40:21 -0600 (CDT) From: DAVEP@acm.org Subject: Re: ERB decision, 31 October 1996 To: tbray@textuality.com Cc: W3C-SGML-WG@w3.org (Tim Bray) recently wrote: >Sign me up as also not getting what Charles is driving at here. >...it would be surprising for the to document stay unchanged between two runs >of the parser;.... I can't speak for Charles, but I interpret that part of 8879 to mean that a text entity referenced twice in the same document should give the same replacement text for both references during the same parse. This sounds reasonable--so that one wouldn't have to keep re-downloading the same entity every time it is referenced. I recommend this much "staticness" is text entities. I think SDATA is the appropriate place for funny tricks. Dave Peterson SGMLWorks! davep@acm.org From: lee@sq.com Date: Tue, 5 Nov 96 17:49:00 EST To: tbray@textuality.com, dlapeyre@mulberrytech.com Subject: Re: Parameter Entities Cc: w3c-sgml-wg@w3.org > May I please hear the other side? ARE they (particluarly the external) > very hard to build into a parser or perl hack. Please be specific? > Is the objection to external based on Web resolving? It depends on your purpose... The "obvious" way to parse XML in perl involves ignoring all comments and PIs and DOCTYPE lines, and assuming that there are no external entities or EMPTY elements or DEFAULT attributes. For example, PERL code to turn Simon Whitehead +39 (12) 42 196342 12 ext. 4210
. . .
into a comma separated file for a database is probably no more than ten minutes' work. (and I've done this...) PERL code to parse a DTD just enough to extract which elements are empty and recognise them adds a few minutes: if (//) { # in the internal subset... # look for # # and add that name to our list: if (/ What you can't do in perl very easily is handle the Ee stuff. E.g. while ($theLine =~ /%([^ ;]+)([ ;])/) { $theLine = $` . entityValue{$1} . $2 . $'; } would probably not work for IBMIDDOC, where there is nested use of quotes inside entitiy values, as after you've done the entity substitution, you have lost the boundaries of the entity. I suppose you could use a control-D as an Ee... The way I would handle entities, if the language were defined sufficiently cleanly, would be with a pre-processor: first expand all the entities, and then handle the data. External entities in XML can certainly be handled this way; If you have to have macros, this is the best way to do them. Of course, one lesson from C++ is that the fewer macros you need and the more functions you have, preferably with strong typing and error checking, the more robust your system will be. But SGML comes out of the Great Macro Processing Era... :-( Parsing the DTD properly in perl will probably produce a totally unmaintanable pile of punctuation that looks utterly pigeon-infested. But there is no point doing that unless someone spends a serious amount of time and writes a general perl module, like David Megginson's excellent SGMLS.pm. I hope this Little Diversion Into Perl is useful. I don't know whether I should admit to doing Dirty Perl Hacking :-), but I want to see XML be used by people to whom it does appeal. Note, by the way, that my examples do not cope with things like even though an SGML parser would. It might be much easier to deal with XML if tokenisation was specified separately from the grammar, which would then never need to include "S" in a production. Lee Date: Wed, 06 Nov 1996 08:39:43 +0000 To: DAVEP@acm.org, tbray@textuality.com From: Martin Bryan Subject: Re: ERB decision, 31 October 1996 Cc: W3C-SGML-WG@w3.org Dave Peterson wrote: >I can't speak for Charles, but I interpret that part of 8879 to mean that >a text entity referenced twice in the same document should give the same >replacement text for both references during the same parse. This is a good interpretation, but also one of the weaknesses of SGML. You should see what happens if you can change the subtrees within a document. This can lead to some really powerful applications. (Not that I'm advocating this for XML, though I will be for SGML97!) ---- 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: Wed, 06 Nov 1996 15:32:39 -0900 To: W3C-SGML-WG@w3.org From: "W. Eliot Kimber" Subject: Re: Recent ERB votes At 12:30 PM 11/6/96 -0800, Tim Bray wrote: >In a recent series of mail votes and meetings, the ERB has resolved >several XML design issues. Under pressure of time, we moved very rapidly >and votes may not have been fully and exactly recorded where the sense >of the ERB on some issue became quickly obvious. It is possible that >ERB members may wish to correct their reported votes. As always, >accompanying rationales, where present, have not been reviewed by the ERB >********** >A.22 XML will have no CONREF attributes (11.3.3, 7.3, 7.9.4.4). > >Passed (no CONREF), Kimber and Maler dissenting I just realized that my vote said "no", which I intended to mean "no conref", not "no, we will have conref". Oops. Not that it affected the outcome. But I didn't want people to think I'm so tied to the essoterica of SGML that I'd vote to keep one of features that precludes declaration-less parsing. One possible solution that might be worth proposing for SGML97 is a new attribute specification syntax for conref attributes so that elements with conref attributes are self describing as for XML empty elements. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Wed, 6 Nov 96 17:49:39 CST From: paul@arbortext.com (Paul Grosso) To: W3C-SGML-WG@w3.org Subject: Re: Recent ERB votes > From: Tim Bray > - The proposal for a PI that summarized the empty elements worked around > a few of these problems, but introduced a new syntax and was a possible > source of inconsistencies. > - Falling back to a position allowing only the syntax solves > all the problems cleanly, but makes it *impossible* for a valid HTML > document to be XML - several on the ERB felt this was political suicide. > > Bearing all this in mind, the ERB voted, Maler dissenting, that: > > - XML support only the syntax for EMPTY elements - this means that > all the language in the spec about "undistinguished" EMPTY elements > can come out. > - In order to make it possible that a valid HTML document can be a valid > XML document, the XML spec will state that XML processors, when they are > processing HTML documents, should recognize, in a built-in way, that the > elements declared as EMPTY for HTML 3.2 (BR, HR, IMG, etc.) are empty even > without syntactic indication. The manner in which an XML processor > is to decide whether a document is HTML is not constrained by the spec. While I respect the fact that the ERB undoubtedly thought very hard about this, I find this decision very unpalatable, much more so that "introducing a new syntax" to summarize empty elements which would then allow XML to handle empty elements as they are written in SGML instances today. As far as "possible inconsistencies," that seems like an odd argument to me. That's like saying having declarations of any kind in any programming or markup language--in fact, *any* declaration, by virtue of "making a statement about what will happen"--opens the door to inconsistencies because the declaration may be a lie. You might as well say that requiring an element to start with an STAGO and end with an ETAGO could lead to inconsistencies because someone might put an STAGO and then not put the ETAGO. What's wrong with, e.g.: to list the empty elements? The "new syntax" doesn't seem so difficult, and I see no more possible inconsistencies than are inherent in any markup scheme. Whether you also allow the syntax is an orthogonal issue, but I personally would find the "new syntax" more of a bother than a simple PI with a list of empty elements, and would rather not have to worry about explaining or handling it. Is there any chance this decision can be reviewed? paul Paul Grosso VP Research, ArborText, Inc. and Chief Technical Officer, SGML Open Email: paul@arbortext.com Date: Wed, 06 Nov 1996 12:30:23 -0800 To: W3C-SGML-WG@w3.org From: Tim Bray Subject: Recent ERB votes In a recent series of mail votes and meetings, the ERB has resolved several XML design issues. Under pressure of time, we moved very rapidly and votes may not have been fully and exactly recorded where the sense of the ERB on some issue became quickly obvious. It is possible that ERB members may wish to correct their reported votes. As always, accompanying rationales, where present, have not been reviewed by the ERB and may be subject to correction. ********** [No item number] Decided unanimously to change PIC for XML to be '?>'. This will allow a lot of things to fit into PI's that currently can't (most notably some proposed server-side scripting languages). ********** A.8, B.7 XML will have INCLUDE/IGNORE marked sections in DTD's Passed, Bray and Paoli dissenting. ********** A.20' XML will change the COM delimiter from '--' to some other string, to minimize user errors. (Candidates: !!, /*, //, **, ??, ;;, ~~. !?, ?!, (), [], others ...) Defeated, Sperberg-McQueen voting in favor ********** A.22 XML will have no CONREF attributes (11.3.3, 7.3, 7.9.4.4). Passed (no CONREF), Kimber and Maler dissenting ********** B.9' Should XML require system and public identifiers to be FORMAL (13.5)? This had actually become a discussion of whether to allow the formulation in front of external identifiers, which must be URL's in XML. Decided, DeRose, Kimber, Maler, and Sperberg-McQueen dissenting, not to allow the prefix. ********** C.10 Should XML allow nondeterministic content models (11.2.4.3)? Voted (Bray, Paoli, and Sharpe dissenting) to retain SGML's restriction in this area. Rationale: Existing SGML tools, for example the SP family, have this rule wired deeply into their logic, and those who wish to use these tools on XML documents won't be able to if they have non-deterministic content models. ********** C.14 Should XML allow more than one enumerated type (name-group declared value) to contain the same possible value (11.3.3)? Voted unanimously to remove SGML's restriction in this area. Rationale: This is incompatible with 8879, but there is every expectation that WG8 will fix this problem soon; furthermore, making this change is not expected to cause serious inconvenience to existing SGML products, whereas the rule is a very serious inconvenience to users of XML and authors of XML software. ********** D.2 Should XML provide shorthand ways of summarizing the salient points of a document's DTD? Discussion: This turned out to be one of the hardest problems the ERB dealt with, and the key issue became that of EMPTY elements. Remember that in a previous decision we had agreed to recommend the syntax, but accept the 8879 syntax. Here are some of the sticky parts: - for a well-formed document to be network-usable, it is important that EMPTY element declarations be available in the document entity so that a browser can be guaranteed of not having to fetch a DTD over the network before starting to parse. - requiring all the declarations to appear in the internal subset could lead to a situation where documents were valid but not well-formed. - Also, it would require those using big existing DTD's to hash them around to make sure these declarations appeared in the internal subset. - As the WG pointed out, supporting two forms of EMPTY is bad design. - The proposal for a PI that summarized the empty elements worked around a few of these problems, but introduced a new syntax and was a possible source of inconsistencies. - Falling back to a position allowing only the syntax solves all the problems cleanly, but makes it *impossible* for a valid HTML document to be XML - several on the ERB felt this was political suicide. Bearing all this in mind, the ERB voted, Maler dissenting, that: - XML support only the syntax for EMPTY elements - this means that all the language in the spec about "undistinguished" EMPTY elements can come out. - In order to make it possible that a valid HTML document can be a valid XML document, the XML spec will state that XML processors, when they are processing HTML documents, should recognize, in a built-in way, that the elements declared as EMPTY for HTML 3.2 (BR, HR, IMG, etc.) are empty even without syntactic indication. The manner in which an XML processor is to decide whether a document is HTML is not constrained by the spec. Rationale: For technical reasons, requiring and allowing only is a big winner. However, many of us, who anticipate an uphill struggle selling XML to web-heads felt that the marketing advantage in making it possible for HTML documents to be valid, and being able to say "XML processors can read HTML", were impossible to give up. In opposition, Eve Maler in particular felt it was unconscionable to kowtow to the requirements of one particular DTD. The ERB acknowledged that allowing
, etc., does *not* enable to XML to grandfather, on a large scale, the existing inventory of XML; simply to state that (at least some normalized) HTML documents can be read by XML processors. ********** 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)? Defeated, Sperberg-McQueen voting in favor. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 From: lee@sq.com Date: Thu, 7 Nov 96 00:28:44 EST To: W3C-SGML-WG@w3.org, paul@arbortext.com Subject: Re: Recent ERB votes Paul asked: > What's wrong with, e.g.: > > to list the empty elements? The "new syntax" doesn't seem so difficult, > and I see no more possible inconsistencies than are inherent in any > markup scheme. Whether you also allow the syntax is an orthogonal > issue, but I personally would find the "new syntax" more of a bother > than a simple PI with a list of empty elements, and would rather not have > to worry about explaining or handling it. If you come at it from an SGML viewpoint, I agree with you. If you come at it from a quick-perl-hack or a short-C-program point of view, having EMPTY elements marked is such a big win I can't even begin to describe it. It's the difference between being able to write something useful in under ten minutes, and taking a day or two or not doing it at all. Frankly, this HTML compatibility thing is a total waste of time. To be at all HTML comptibile, you have to cope with
  • first item
  • second item
  • bold item

  • did you know hr isn't allowd here?
Yes, this "works" in Netscape. Say it isn't calid all you like. shout until you're blue in the face. But reading this is what HTML compatibility is about today. So don't bother about a list of EMPTY elements for HTML compatibility. I don't believe for a moment that that was the real reason that anyone wanted to be able to use -- or if it was, they were having a bad day! To use an XML application to parse HTML, you had better have a transformation... Now, if you are generating the HTML yourself, and it is valid, and you'd like to use the same document in XML programs, SGML programs, RTF programs, a C compiler, five HTML browsers and a food mixer, you can enter the Obfuscated PostScript contest... :-) In the meantime, source-level HTML compatibility isn't one of the goals I see in the charter for this list, nor in the draft spec. Supporting an optional syntax for empty elements clearly violates goal (5) (no optional features). Having two syntaxes for the same thing because the ERB couldn't make up their mind, apart from being silly, seems to me to compromise goal (4) (easy to write programs). It does so without advancing any other stated goal, so is presumably purely political. Let's try not to make too many political compromises, especially where we don't need to... Don't have multiple syntaxes for anything. We've argued long and hard for empty elements to be marked as different, so that they can be parsed easily, reliably, and without a DTD. Don't throw that away now. Lee From: lee@sq.com Date: Thu, 7 Nov 96 00:39:57 EST To: jenglish@crl.com, w3c-sgml-wg@w3.org Subject: Re: Parameter Entities Joe English wrote: > I would hypothesize that the smaller, simpler applications -- > the ones we expect CS majors to be able to write in a week -- > will for the most part not read the DTD at all. I agree. And won't cope with entities or EMPTY elements (if they use the syntax), and will probably treat , and same for . And that will be just fine for most uses. Lee -- Liam Quin, lee@sq.com | lq-text freely available Unix text retrieval Senior Technical Consultant | FAQs: Metafont fonts, OPEN LOOK UI, OpenWindows SoftQuad Inc. +1 416 544-9000 | xfonttool (Unix xfontsel in XView) http://www.softquad.com/ | The barefoot programmer Date: Thu, 07 Nov 1996 01:26:56 -0500 To: lee@sq.com, W3C-SGML-WG@w3.org, paul@arbortext.com From: Arjun Ray Subject: Re: Recent ERB votes At 12:28 AM 11/7/96 EST, lee@sq.com wrote: >Paul asked: >> What's wrong with, e.g.: >> >> to list the empty elements? The "new syntax" doesn't seem so difficult, >> and I see no more possible inconsistencies than are inherent in any >> markup scheme. Whether you also allow the syntax is an orthogonal >> issue, but I personally would find the "new syntax" more of a bother >> than a simple PI with a list of empty elements, and would rather not have >> to worry about explaining or handling it. > >If you come at it from an SGML viewpoint, I agree with you. > >If you come at it from a quick-perl-hack or a short-C-program point >of view, having EMPTY elements marked is such a big win I can't >even begin to describe it. It's the difference between being able to >write something useful in under ten minutes, and taking a day or two >or not doing it at all. I agree. Furthermore, I'm more than a little troubled by PI kludges of any kind for parsing. In general, aren't PIs application level information? The notion that a XML parser (as a potentially independent/separable module/program) needs to peek into PIs, strikes me as just the kind of poor design that motivated "Server Side Includes" or Javascript inside erstwhile comments. OTOH, if we kept it clean, we'd still require (i) every application to call back into the parser to inform it about a PI, and (ii) this round trip would have to occur before any further parsing. All of this (in an effort to be clean) puts even greater burdens on the app/parser interface/API; to take arms against this sea of troubles, programmers *will* take the kludge short-cut -- and open the gates to all sorts of PIs for parsers to peek into and act upon. Blech. >Frankly, this HTML compatibility thing is a total waste of time. Agree again. >We've argued long and hard for empty elements to be marked as different, >so that they can be parsed easily, reliably, and without a DTD. This is the crux of the matter, IMHO. Arjun From: "Henry S. Thompson" Date: Thu, 7 Nov 96 12:44:37 GMT To: Arjun Ray , W3C-SGML-WG@w3.org Subject: Re: Recent ERB votes On the general subject of empty elements, DTD info reprised in PIs, etc, I find myself in a state of serious uncertainty. On the one hand, I REALLY care about SGML forward compatibility, so I'd be REALLY sorry to lose vanilla empty elements. And I already work with a normalised form very close to XML as the draft DID have it, using a concise DTD reprise, so I could see converting my existing code to handle XML plus DTD-reprise-in-PIs very easily. On the other hand, I'm sympathetic to the criticism of adhocery which Arjun makes, and indeed made it myself in the debate over character-set-declarations-as-PIs. I must say I agree with Eve Maler that grandfathering a specific LIST of empty elements is reprehensible. Note that wrt the 'can a perl hacker do it in an afternoon' issue, this makes the published decision virtually indistinguishable in difficulty from the DTD-reprise-in-PIs approach---in either case a table of empty GIs has to be maintained and checked. I also agree with Paul that the 'possible inconsistencies' argument is vacuous. On balance, then, I go with my original response on reading the draft, namely "Oh good, a serviceable approach to compatibility", even if it means using PIs IFF YOU WANT TO USE . Oh yes, one final note, wrt Arjun's remarks about PIs: a parser IS an application, and there's nothing bogus about shortstopping PIs flagged for the parser itself, so the claimed necessity of having to round-trip the PIs out and back again is invalid and not as such a basis for rejecting this approach. I too therefore urge the board to return to the status quo ante wrt and ht From: Paul Prescod Subject: Re: Recent ERB votes To: lee@sq.com Date: Thu, 7 Nov 1996 10:09:34 -0500 (EST) Cc: W3C-SGML-WG@w3.org, paul@arbortext.com > Paul asked: > Frankly, this HTML compatibility thing is a total waste of time. > To be at all HTML comptibile, you have to cope with >
    >
  • first item >
  • second item >
  • bold item
  • >
    did you know hr isn't allowd here? >
  • >
> > Yes, this "works" in Netscape. Say it isn't calid all you like. > shout until you're blue in the face. But reading this is what > HTML compatibility is about today. I think that the ERB is looking at it from the opposite point of view. They are trying to define XML so that an HTML-like subset of XML can be "understood" by existing Web browsers. Then we could roll-out XML as most HTML extensions are rolled out: tags which are ignored by browsers that don't "grok" them. Since none of us expect the HTML-extension mania to end soon, XML might as well provide a standards-compliant mechanism for doing so (as SGML currently does). There are legitimate reasons for wanting to extend HTML (for instance for richer meta-data). Right now this is done through SGML (such as Peter FLynn's HTML Pro) or through prose specifications. XML could take over that job. It is important to remember that HTML should have a special place in these discussions, because it is the current "official" markup language of the group that is sponsoring this effort, and of the information system that we are trying to augment (the Web). Seen in those terms, one could argue that HTML compatibility should be of a higher priority than SGML compatibility (but I certainly won't!). Paul Prescod Date: Thu, 7 Nov 1996 08:17:00 -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: Recent ERB votes [Paul Prescod:] | > Paul [Grosso] asked: | > Frankly, this HTML compatibility thing is a total waste of time. | > To be at all HTML comptibile, you have to cope with | >
    | >
  • first item | >
  • second item | >
  • bold item
  • | >
    did you know hr isn't allowd here? | >
  • | >
| > | > Yes, this "works" in Netscape. Say it isn't calid all you like. | > shout until you're blue in the face. But reading this is what | > HTML compatibility is about today. No. That's not what we're trying to accomplish. | I think that the ERB is looking at it from the opposite point of view. They | are trying to define XML so that an HTML-like subset of XML can be | "understood" by existing Web browsers. Right, though the emphasis is really more the other way around. The idea is *not* to grandfather in existing HTML; in fact, the spec bars virtually all existing HTML documents just because of the end-tag requirement. Rather, the idea is to make it *possible* to create new documents that are both valid HTML (according to the HTML 3.2 spec) and valid XML. Such documents would look a lot different from the typical HTML page today, but they would have the advantage of working in both the HTML and XML application environments. So HTML users can run a normalizer on their existing HTML document bases and get documents that will continue to be viewable by current HTML browsers but will also work in new XML browsers. Without making the one extremely limited concession to existing HTML empty elements that came out of our final round of deliberations, this would not be possible. Please note that there is a huge difference between a mechanism for defining "unqualified" empty elements on an ad-hoc basis and a mechanism that simply recognizes a small, closed set of specific strings ("
", " From: bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) > > Note also that this strategy does not discriminate against the > existing SGML document base. There are probably as many existing SGML > documents that will work unchanged in an XML environment as there are > HTML documents. My Shakespeare and Religious Works collections are > valid XML just as they stand How is that? How are empty elements represented in your existing SGML document base for your Shakespeare and Religious Works collections? Irrespective of the answer to the above, what SGML authoring tools would produce valid XML given document instances in your Shakespeare and Religious Works collections? Assuming neither Author/Editor nor Adept Editor (whose output, I believe, are very similar) are answers to the above question, what would be the list of modifications necessary to convert what they would produce given document instances in your Shakespeare and Religious Works collections into valid XML? From: lee@sq.com Date: Thu, 7 Nov 96 13:53:29 EST To: W3C-SGML-WG@w3.org, paul@arbortext.com Subject: Re: Recent ERB votes > what SGML authoring tools > would produce valid XML given document instances in your Shakespeare > and Religious Works collections? > > Assuming neither Author/Editor nor Adept Editor (whose output, I > believe, are very similar) are answers to the above question, A/E isn't (I think) because (1) it won't let you put a PI before the DOCTYPE line under any circumstance right now (I haven't tried opening such a file in A/E, the assumption being that we will add XML support to A/E and HoTMetaL Pro) (2) it doesn't handle whitespace in the same way (nor in the SGML way): all whitespace is retained. This (it has been argued) is desirable in an editor. (3) (currently) it does not handle EMPTY elements as per XML. There aren't any EMPTY elements in those DTDs; the version of the Psalter that Harry Gaylord and Robin Cover did is a better example, as they used EMPTY elements to represent the overlapping structures in that document that SGML tools can't easily handle. (CONCUR would have been the obvious choice, although the TEI has a better way, as so often, using a linked list of id/idefs) (4) the documents use a public identifier in the document to get at the DTD, and not a SYSTEM identifier that's a URL. No existing collection of SGML documents published with Panorama will work unchanged in XML. > what > would be the list of modifications necessary to convert what they would > produce given document instances in your Shakespeare and Religious > Works collections into valid XML? I'll let Jon answer this :-) but most of it follows from what I have listed. Lee Date: Thu, 7 Nov 1996 11:37:45 -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: Recent ERB votes [Paul Grosso:] | > From: bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) | > | > Note also that this strategy does not discriminate against the | > existing SGML document base. There are probably as many existing SGML | > documents that will work unchanged in an XML environment as there are | > HTML documents. My Shakespeare and Religious Works collections are | > valid XML just as they stand | | How is that? How are empty elements represented in your existing SGML | document base for your Shakespeare and Religious Works collections? There are none. | Irrespective of the answer to the above, what SGML authoring tools | would produce valid XML given document instances in your Shakespeare | and Religious Works collections? The SGML authoring tools that I actually did use: emacs and perl. The fact that these are probably not examples of what you have in mind when you say "SGML authoring tools" says something important about the preconceptions you may have about XML. | Assuming neither Author/Editor nor Adept Editor (whose output, I | believe, are very similar) are answers to the above question, what | would be the list of modifications necessary to convert what they would | produce given document instances in your Shakespeare and Religious | Works collections into valid XML? I think that Lee has addressed this. However, the question misses the point. The primary use of XML is to convey structured information >from SGML databases to Web applications. The batch processes that I used to generate the Shakespeare and Religion collections are actually much closer in spirit to the problem domain that XML is primarily designed to address than anything having to do with native authoring. The point I was trying to make (but complicated by using the word "valid") is that if you strip off the current doctype header from the Shakepeare and Religion files, you have well-formed XML that could (if such things existed) be fed directly to XML browsers. The fact that I was writing well-formed XML in 1992 says to me that XML is "natural SGML" -- it is what I intuitively thought that SGML was when I started. And consequently I believe that a lot of existing "monastic SGML" can be made into XML much more easily than the great majority of existing HTML documents. I will repeat the point that I want to make sure doesn't get lost here: the XML spec does not favor HTML legacy data over SGML legacy data; quite the contrary. Jon From: lee@sq.com Date: Thu, 7 Nov 96 16:01:24 EST To: W3C-SGML-WG@w3.org Subject: Re: Recent ERB votes > The primary use of XML is to convey structured information > from SGML databases to Web applications. Oh. Well, in that case, my interest in XML is considerably reduced. > The batch processes that I > used to generate the Shakespeare and Religion collections are actually > much closer in spirit to the problem domain that XML is primarily > designed to address than anything having to do with native authoring. In that case, the problem needed to be stated more clearly, I think. Or mayby I am the only one who thought that the intent was to attract people (and programmers) who do not today use SGML, and for applications for which neither HTML nor SGML is used today? > I will repeat the point that I want to make sure doesn't get lost > here: the XML spec does not favor HTML legacy data over SGML legacy > data; quite the contrary. In that case, you can delete this silly empty element nonsense. Neither Netscape nor Microsoft will stop adding EMPTY elements just because some hastily-designed SGML database report writing language has a wired-in list of EMPTY elements. I think we're all taking different drugs here. Lee Date: Thu, 7 Nov 1996 13:48:59 -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: Recent ERB votes [Lee Quin:] | > The primary use of XML is to convey structured information | > from SGML databases to Web applications. | | Oh. | | Well, in that case, my interest in XML is considerably reduced. Perhaps you should check out the W3C Activity Page that I keep referring to: http://www.w3.org/pub/WWW/MarkUp/SGML/Activity | > The batch processes that I | > used to generate the Shakespeare and Religion collections are actually | > much closer in spirit to the problem domain that XML is primarily | > designed to address than anything having to do with native authoring. | | In that case, the problem needed to be stated more clearly, I think. | Or mayby I am the only one who thought that the intent was to attract | people (and programmers) who do not today use SGML, and for applications | for which neither HTML nor SGML is used today? The delivery of structured data to Web clients *is* an application for which neither HTML nor SGML is widely used today. Attracting HTML users to SGML is something that all of us would like to get out of this activity. That does not mean that it is the primary goal of the activity. There are a number of goals being balanced here. They do not all have the same priority. Only one of them can be given top priority. That is the one specified in the activity statement. The fact that one goal must be given top priority does not mean that there are not other goals. It just means that they do not all have exactly the same priority. | > I will repeat the point that I want to make sure doesn't get lost | > here: the XML spec does not favor HTML legacy data over SGML legacy | > data; quite the contrary. | | In that case, you can delete this silly empty element nonsense. | Neither Netscape nor Microsoft will stop adding EMPTY elements just | because some hastily-designed SGML database report writing language | has a wired-in list of EMPTY elements. Now you're assuming that the intent is to grandfather HTML documents again. We don't care how many additional empty elements NS/MS wire into their browsers. The idea behind the strategy adopted by the ERB is that it is possible to construct documents that will be XML documents and HTML documents at the same time. Adding more empty tags to an HTML browser has no effect on such documents. Jon Date: Thu, 7 Nov 96 16:26:54 CST From: paul@arbortext.com (Paul Grosso) To: W3C-SGML-WG@w3.org Subject: Re: Recent ERB votes > From: bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) > > [Paul Grosso:] > > | > From: bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) > | > > | > Note also that this strategy does not discriminate against the > | > existing SGML document base. There are probably as many existing SGML > | > documents that will work unchanged in an XML environment as there are > | > HTML documents. My Shakespeare and Religious Works collections are > | > valid XML just as they stand > | > | How is that? How are empty elements represented in your existing SGML > | document base for your Shakespeare and Religious Works collections? > > There are none. > > | Irrespective of the answer to the above, what SGML authoring tools > | would produce valid XML given document instances in your Shakespeare > | and Religious Works collections? > > The SGML authoring tools that I actually did use: emacs and perl. The > fact that these are probably not examples of what you have in mind > when you say "SGML authoring tools" says something important about the > preconceptions you may have about XML. You're wrong. The answer you give is exactly what I expected. > > | Assuming neither Author/Editor nor Adept Editor (whose output, I > | believe, are very similar) are answers to the above question, what > | would be the list of modifications necessary to convert what they would > | produce given document instances in your Shakespeare and Religious > | Works collections into valid XML? > > I think that Lee has addressed this. However, the question misses the > point. The primary use of XML is to convey structured information > from SGML databases to Web applications. The batch processes that I > used to generate the Shakespeare and Religion collections are actually > much closer in spirit to the problem domain that XML is primarily > designed to address than anything having to do with native authoring. Again, your answer is not a surprise to me, but I think it is useful to see it in print. I have sensed a lot of people trying to give lip service to the claim that XML is a subset of SGML--at least in spirit if not in fact--and it's refreshing to have you admit that this is not your intent. It's not your intention that the base of existing SGML authoring tools will handle XML. > The point I was trying to make (but complicated by using the word > "valid") is that if you strip off the current doctype header from the > Shakepeare and Religion files, you have well-formed XML that could (if > such things existed) be fed directly to XML browsers. The fact that I > was writing well-formed XML in 1992 says to me that XML is "natural > SGML" -- it is what I intuitively thought that SGML was when I > started. And consequently I believe that a lot of existing "monastic > SGML" can be made into XML much more easily than the great majority of > existing HTML documents. "Natural SGML" may well be some subset that omits a lot of esoterica. However, XML as being defined now will require new tools and will force new decisions upon potential users that will cause extra confusion as they try to figure out what to do with their data. Whether this ends up being good for the users is still an open question. > > I will repeat the point that I want to make sure doesn't get lost > here: the XML spec does not favor HTML legacy data over SGML legacy > data; quite the contrary. > > Jon I'm not sure a comparison to HTML is of as much interest for me as the comparison between XML and SGML legacy, both in terms of legacy instances as well as legacy DTDs, information modeling, and processes. There is a huge and important customer base that has a whole lot invested in "legacy" SGML. I suspect that only a very small portion of the total investment is, for example, based on the various minimization techniques of 8879, so I'm happy to see them tossed. But I suspect, for example, about 99% of the investment is built on assumptions that there are EMPTY elements. I'm not afraid from a tool producer point of view. Let's face it, for any organization that's developed an SGML aware authoring tool, it's not going to be hard to add an "XML-mode" switch to it. What I'm a bit more concerned about is the confusion among potential adopters we'll be creating just at the time I thought SGML was finally getting over the "it's too new to try out yet" hump. People who just jumped on the SGML bandwagon will now all say "shoot, I jumped too soon, now it looks like XML is the latest thing--geez I knew it was still too early to commit to SGML." This WG has been concentrating on the technical issues, but it's the effect the technical definition of XML has on the market place reaction that has me concerned. Insofar as XML is just "a subset of SGML without the cruft" then I don't have as much of the marketing problem I describe above. Maybe if all the vendors hop to it and add "XML-mode" and "Convert to XML/convert from XML" options in their tools, then we can minimize the effect of the market confusion. Meanwhile, it'll be interesting to see how all this plays in Boston when it gets more into the hands of community at large. paul Date: Thu, 7 Nov 1996 16:08:42 -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: Recent ERB votes [Paul Grosso:] | XML as being defined now will require new tools and will force new | decisions upon potential users that will cause extra confusion as they | try to figure out what to do with their data. We have gone to a lot of trouble to ensure that existing tools can be used to create XML. It would help this discussion if you could specify the features of XML that make it impossible to create using existing SGML tools. | There is a huge and important customer base that has a whole lot | invested in "legacy" SGML. I suspect that only a very small portion | of the total investment is, for example, based on the various | minimization techniques of 8879, so I'm happy to see them tossed. But | I suspect, for example, about 99% of the investment is built on | assumptions that there are EMPTY elements. The XML syntax for EMPTY elements is conformant with 8879 and will not break 8879-conformant authoring tools. The conversion of EMPTY elements in SGML data for export to XML Web browsers is trivial. How does this negatively affect the existing base of SGML documents? Jon Date: Thu, 07 Nov 1996 18:17:31 -0600 From: Len Bullard To: Paul Grosso CC: W3C-SGML-WG@w3.org Subject: Re: Recent ERB votes [Jon Bosak] > > The primary use of XML is to convey structured information > > from SGML databases to Web applications. The batch processes that I > > used to generate the Shakespeare and Religion collections are actually > > much closer in spirit to the problem domain that XML is primarily > > designed to address than anything having to do with native authoring. Whoops! > Again, your answer is not a surprise to me, but I think it is useful > to see it in print. I have sensed a lot of people trying to give > lip service to the claim that XML is a subset of SGML--at least in > spirit if not in fact--and it's refreshing to have you admit that > this is not your intent. It's not your intention that the base of > existing SGML authoring tools will handle XML. Yikes! > "Natural SGML" may well be some subset that omits a lot of esoterica. > However, XML as being defined now will require new tools and will force > new decisions upon potential users that will cause extra confusion as > they try to figure out what to do with their data. Whether this ends > up being good for the users is still an open question. It isn't good for the existing SGML users and vendors. It is an alternative to SGML, not a subset. That is bad news. > > I will repeat the point that I want to make sure doesn't get lost > > here: the XML spec does not favor HTML legacy data over SGML legacy > > data; quite the contrary. Pardon, but only one existing application of SGML is contributing to a tag pool, so far. I understand what political suicide is. I suggest if that is what you want to avoid, retain and state that the added complexity of the parser in XML is to retain compatibility with existing SGML applications and systems such as Netscape and Microsoft IE because these are the only Shogun's that will compel you to ritual suicide. Political suicide allows one to reincarnate. Clinton does it regularly. > I'm not sure a comparison to HTML is of as much interest for me as the > comparison between XML and SGML legacy, both in terms of legacy > instances as well as legacy DTDs, information modeling, and processes. It is for me because I generate information in that notation. However, I also use the others and get them for conversion into hypermedia. XML is *for me* a legal target for simplifying the systems and markup required for that. SGML server to HTML client is just one particular technical approach. Using rewrite languages such as PERL to create markup products is another. XML was *I thought* to be a simplified SGML that works in the *current* network environment and enables products to be created and interoperated at lower costs by reducing the requirements for absolute two way fidelity. In other words, give up some legal and abnormal exception handling; get back the ability to build and choose structures. But, still, generalized validatible markup. The requirements that are compelling beyond that are the markup structures and properties which are used in the interface processes, e.g, hyperlink types. These we share because it makes the net go. Then stylesheets, because fidelity is always a requirement. What the stylesheet is used for vis a vis protocols, operations, etc, is a more difficult question. > There is a huge and important customer base that has a whole lot > invested in "legacy" SGML. I suspect that only a very small portion of > the total investment is, for example, based on the various minimization > techniques of 8879, so I'm happy to see them tossed. But I suspect, > for example, about 99% of the investment is built on assumptions that > there are EMPTY elements. If my sample is significant, I agree. > Insofar as XML is just "a subset of SGML without the cruft" then I > don't have as much of the marketing problem I describe above. Maybe > if all the vendors hop to it and add "XML-mode" and "Convert to > XML/convert from XML" options in their tools, then we can minimize > the effect of the market confusion. Maybe, but if the cost of converting existing legacy to XML is greater than the cost to kluge a way to move SGML onto the Internet even at the risk of monkey-wrenching HTTP, we will do it. So far, nothing I see makes me think we even have to do that. All we have to do is be careful about what features we use and do it. Interoperability with other vendors choices can be an issue worked out in the marketplace, just as it is being done now by the HTML vendors. What I was hoping for from this group was a serious effort to avoid a competition between XML on The Web and SGML On The Web. Seems counterproductive. > Meanwhile, it'll be interesting to see how all this plays in Boston > when it gets more into the hands of community at large. I'd love to see that, but I will be in Orlando trying to convince members of my corporation that we should be targeting XML for IETM products if possible. If not, no sale. We already know how to use SGML for that and the Web and we already know which features of SGML not to use for our purposes. XML is a chance to cooperate. Pardon Jon and members of the ERB: it is yours to vote on the content of the spec. It is ours to implement what we choose to implement. The investment of the SGML tool vendors is important. I doubt that you are going to have as quick a success with your other romances. len bullard ps: out of town from tonight until next friday. y'all have fun. Date: Thu, 07 Nov 1996 23:27:40 -0500 To: lee@sq.com, W3C-SGML-WG@w3.org From: Paul Prescod Subject: Re: Recent ERB votes At 04:01 PM 11/7/96 EST, lee@sq.com wrote: >> The batch processes that I >> used to generate the Shakespeare and Religion collections are actually >> much closer in spirit to the problem domain that XML is primarily >> designed to address than anything having to do with native authoring. > >In that case, the problem needed to be stated more clearly, I think. >Or mayby I am the only one who thought that the intent was to attract >people (and programmers) who do not today use SGML, and for applications >for which neither HTML nor SGML is used today? Mass delivery of large documents IS something that neither HTML nor SGML is used for today. I'm pretty sure I can't acess Jon's Shakespeare collection over the Web without downloading new, complex software (unless he is serving them through DynaWeb, which is not affordable for many of us). If we could easily create print and online versions of annual reports, manuals, etc., we _would_ be able to attract people and programmers who do not today use SGML. >> I will repeat the point that I want to make sure doesn't get lost >> here: the XML spec does not favor HTML legacy data over SGML legacy >> data; quite the contrary. > >In that case, you can delete this silly empty element nonsense. >Neither Netscape nor Microsoft will stop adding EMPTY elements just >because some hastily-designed SGML database report writing language >has a wired-in list of EMPTY elements. Again, the goal isn't to support HTML "du jour", but provide a smooth migration path from HTML to XML for the short term. People will convert their HTML documents into Extended-HTML (HTML plus their own tags) while they wait for robust XML support, and then turn their XHTML into XML when HTML-only browsers are a bad memory. Paul Prescod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html From: Gavin Nicol Date: Fri, 8 Nov 1996 05:22:41 GMT To: tbray@textuality.com CC: W3C-SGML-WG@w3.org Subject: SPACE... I noticed in the XML WD that there is no allowance for zenkaku spaces etc. in markup. This should be fixed. Date: Fri, 08 Nov 96 06:39:31 CST From: Michael Sperberg-McQueen Subject: Re: SPACE... To: W3C SGML Working Group On Fri, 8 Nov 1996 00:24:37 -0500 Gavin Nicol said: > >I noticed in the XML WD that there is no allowance for zenkaku >spaces etc. in markup. This should be fixed. Thanks; it will be. All the characters identified by Unicode as having the property of being white space will be defined as part of XML's non-terminal S, and thus will be treated as separators within markup; we just haven't got around to transcribing the relevant character codes into the non-terminal yet. I had been thinking that all such separators except NBSP should also be subject to XML's white-space normalization rules (reduction of any span of white-space characters to a single SPACE -- i.e. U+0020 -- unless white-space preservation is turned on), but I am now wondering if that is the right behavior. I have no experience using these variant kinds of spaces. Presumably these are distinct from SPACE because they have some desirable property (such as marking 'word' boundaries not otherwise detectable by software) and I'm not sure reducing them to SPACE is the correct behavior. I18nists, speak up now. Reduce them all or not? In favor: it's simple behavior, it is easily understood, and all white space is treated the same. Against: well, I don't know whether there is any argument against, that's what I am asking: *is* there an argument against? Is the distinction between SPACE, half-width space, en-space, em-space, double-width space, zenkaku space, etc., to be preserved in a way that the distinction between SPACE and TAB is not preserved? Should some white space characters be leveled and others not? We were not planning to level NBSP, since one common use for it is to try to prevent such white-space normalization in specific cases; should other 10646 white-space characters also be exempt? Which? -C. M. Sperberg-McQueen Date: Fri, 08 Nov 1996 15:19:53 +0000 To: Michael Sperberg-McQueen , W3C SGML Working Group From: Martin Bryan Subject: Re: SPACE... At 06:39 AM 11/8/96 CST, Michael Sperberg-McQueen wrote: >I18nists, speak up now. Reduce them all or not? In favor: it's >simple behavior, it is easily understood, and all white space is >treated the same. Against: well, I don't know whether there is any >argument against, that's what I am asking: *is* there an argument >against? Is the distinction between SPACE, half-width space, >en-space, em-space, double-width space, zenkaku space, etc., to be >preserved in a way that the distinction between SPACE and TAB is not >preserved? Should some white space characters be leveled and others >not? We were not planning to level NBSP, since one common use >for it is to try to prevent such white-space normalization in >specific cases; should other 10646 white-space characters also be >exempt? Which? I'm not sure about the "its easily understood" statement. 0646 row 20 has a group of 12 "spaces", two of which are em-quad and en-quad and the rest are named as spaces, including something known as a punctuation space. I suspect that if we don't treat em-quad and en-quad as spaces, but treat the rest of them as such we will be OK but I'm not convinced. Personally I think of space of a defined width as being different from a separator, and what we are talking about here is the use of spaces as separators in markup rather than separators in data. I can't really see people entering four-per-em-spaces in an attribute value, though I can see them trying to enter a zenkaku space in a Japanese attribute value Martin Bryan. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ From: lee@sq.com Date: Fri, 8 Nov 96 11:15:21 EST To: W3C-SGML-WG@w3.org Subject: Re: Recent ERB votes Paul Prescod wrote: > Mass delivery of large documents IS something that neither HTML nor SGML is > used for today. I'm pretty sure I can't acess Jon's Shakespeare collection > over the Web without downloading new, complex software (unless he is serving > them through DynaWeb, which is not affordable for many of us). (1) the entire bible is only approx. 5 MBytes -- not exactly a large database. (I don't mean to denigrate what Jon did, by the way, but it pales to insignificance in terms of size when compared to the Novell online documentation, for example) (2) It's accessible today in Panorama; whether you call Panorama complex or not may depend on how much of the source you've seen :-) but it's certainly affordable! > If we could > easily create print and online versions of annual reports, manuals, etc., we > _would_ be able to attract people and programmers who do not today use SGML. I agree. Of course, empty elements aren't related to that. And neither is downloading SGML databases over the internet... > Again, the goal isn't to support HTML "du jour", but provide a smooth > migration path from HTML to XML for the short term. Then why wire in a list of HTML "du jour" EMPTY elements into XML perpetuity? The same program that converts today's HTML into XML can change
to
if it likes. Lee -- Liam Quin, lee@sq.com | lq-text freely available Unix text retrieval Senior Technical Consultant | FAQs: Metafont fonts, OPEN LOOK UI, OpenWindows SoftQuad Inc. +1 416 544-9000 | xfonttool (Unix xfontsel in XView) http://www.softquad.com/ | The barefoot programmer Date: Fri, 8 Nov 96 09:31:41 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: SPACE... > From: Michael Sperberg-McQueen > I had been thinking that all such separators except NBSP should also > be subject to XML's white-space normalization rules (reduction of any > span of white-space characters to a single SPACE -- i.e. U+0020 -- > unless white-space preservation is turned on) > We were not planning to level NBSP, since one common use > for it is to try to prevent such white-space normalization in > specific cases My quick re-reading of the WD doesn't answer the following for me: Is white space normalization done "before" or "after" entity expansion. In other words, if a text entity starts, ends, or consists of white space characters, does white space normalization occur (1) for consecutive whitespace within the entity replacement text and/or (2) for the concatenation of the whitespace preceding the entity ref and the whitespace at the beginning of the replacement text? Likewise, if a character reference is to a whitespace character (other than NBSP or any other for which ws normalization is defined not to occur anyway), does ws normalization occur wrt all the replacement texts? Date: Fri, 08 Nov 1996 11:43:30 -0500 To: W3C-SGML-WG@w3.org From: Paul Prescod Subject: Re: Recent ERB votes At 06:17 PM 11/7/96 -0600, Len Bullard wrote: >> "Natural SGML" may well be some subset that omits a lot of esoterica. >> However, XML as being defined now will require new tools and will force >> new decisions upon potential users that will cause extra confusion as >> they try to figure out what to do with their data. Whether this ends >> up being good for the users is still an open question. > >It isn't good for the existing SGML users and vendors. It is an >alternative to SGML, not a subset. That is bad news. Although I would strongly prefer a standard that works directly with existing SGML source files, I don't think that a subtly different XML will "compete" with SGML. Hardly anyone currently serves "real SGML" on the Web (compared to the number of people that _have_ real SGML). Most people either don't put it on the Web, or convert it to HTML (losing a lot of information). Either way we lose. Although it would not be ideal, an XML that allows a simple, obvious transform from SGML is MUCH preferable to the current situation. I see a requirement to transform into XML as an inconvenience but not a show-stopper. >Pardon, but only one existing application of SGML is contributing >to a tag pool, so far. I understand what political suicide is. What political environment is this political suicide within? XML isn't an ISO standard, but a W3C standard. SGML 97 will be, but it will obviously not mention HTML at all. SGML 97 can standardize the format as the "default" representation for "simple SGML" documents. Some HTML-based XML documents will not be Simple SGML", just as many other legacy SGML documents will not be Simple SGML. I don't see where political suicide comes in. SGML 97 and XML have different legacy problems. The ERB wants some subset of XML documents to be compatible with EXISTING BROWSERS. That seems like a politically smart move to me. >I suggest if that is what you want to avoid, retain and >state that the added complexity of the parser in XML is to >retain compatibility with existing SGML applications and systems >such as Netscape and Microsoft IE because these are the only >Shogun's that will compel you to ritual suicide. Could a parser-implementor comment on the extra difficulty imposed by the "don't worry, be smart" solution? How hard is it? >Maybe, but if the cost of converting existing legacy to XML is >greater than the cost to kluge a way to move SGML onto the >Internet even at the risk of monkey-wrenching HTTP, we will do it. But we already KNOW the cost of kluges. They are _expensive_. DynaWeb is _expensive_. DTD-specific converters are _expensive_. Panorama is expensive because most of your users will never download it, and your information will be lost. If these kluges were cheap, I would wait a few years for the network to speed up, and processors to speed up and would just put raw SGML on the Web. "Simple SGML" (unrelated to the Web) is also interesting and important, but it could be standardized in SGML 97. >So far, nothing I see makes me think we even have to do that. >All we have to do is be careful about what features we use and >do it. Interoperability with other vendors choices can be an >issue worked out in the marketplace, just as it is being done >now by the HTML vendors. What I was hoping for from this group >was a serious effort to avoid a competition between XML on >The Web and SGML On The Web. SGML on the Web seems to be a non-starter for small to medium sized companies/departments and individuals of all sizes. Even for big companies, I think that it is probably misleading to call the current (or near future) state of affairs "SGML on the Web". Panorama documents are not accessible to the majority of Web surfers, and SGML-transformed-to-HTML isn't really SGML anymore. If you are comfortable converting to HTML, you will be even more comfortable converting to XML (or XHTML, in the short term). Paul Prescod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html Date: Fri, 08 Nov 1996 12:11:13 -0500 To: W3C-SGML-WG@w3.org From: Paul Prescod Subject: Re: Recent ERB votes At 11:15 AM 11/8/96 EST, lee@sq.com wrote: >Paul Prescod wrote: >(1) the entire bible is only approx. 5 MBytes -- not exactly a large > database. (I don't mean to denigrate what Jon did, by the way, but > it pales to insignificance in terms of size when compared to the > Novell online documentation, for example) > >(2) It's accessible today in Panorama; whether you call Panorama complex or > not may depend on how much of the source you've seen :-) but it's > certainly affordable! Sure. But what if Jon wants to publish those to his Bible Study Group? Or publish his Shakespeare collection to his Shakespeare scholar's collection group? Do we expect them all to download Panorama? What about those that are using terminals in libraries, or other people's computers? If a)Panorama were a standard part of Netscape or IE, b)it had display mechanisms were based on standards (i.e. DSSSL-O), c)it had performance on par with regular web browsers, then XML would be irrelevant. Simple SGML would still be important, but that would be an ISO project, not a W3C one. XML should be ubiquitous (and thus simple), standards-based, and fast (and thus simple). >> If we could >> easily create print and online versions of annual reports, manuals, etc., we >> _would_ be able to attract people and programmers who do not today use SGML. > >I agree. Of course, empty elements aren't related to that. >And neither is downloading SGML databases over the internet... They are related to that, through simplicity. If we can make parsing simpler, we will get better browser support, and thus ubiquity. We will also get better performance. >> Again, the goal isn't to support HTML "du jour", but provide a smooth >> migration path from HTML to XML for the short term. > >Then why wire in a list of HTML "du jour" EMPTY elements into >XML perpetuity? The same program that converts today's HTML into XML >can change
to
if it likes. Because the ERB is _!NOT!_ interested in compatibility with HTML _documents_ but with EXISTING HTML BROWSERS! They want to be able to do this, in the short term:

This is an HTML-like document with TEI style date elements, written on 21 Feb 1980. It also has a TEI header (though it is not shown here). Thanks to the magic of CSS style sheets, and HTML convention, the TEI tags can either disappear, or be mapped to special formatting for existing browsers. Paul Prescod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html From: lee@sq.com Date: Fri, 8 Nov 96 12:59:28 EST To: W3C-SGML-WG@w3.org, papresco@calum.csclub.uwaterloo.ca Subject: Re: Recent ERB votes > From: Paul Prescod > If > a)Panorama were a standard part of Netscape or IE, > b)it had display mechanisms were based on standards (i.e. DSSSL-O), > c)it had performance on par with regular web browsers, > > then XML would be irrelevant. I wish I had known that the entire reason for XML was a performance issue in Panorama. It would have saved a lot of people a lot of work. If we released a Netscape plugin version of Panorama (that also worked in MSIE), included DSSSL-O support, and made it faster, XML would be a waste of time? I don't actually agree with this, by the way... > Simple SGML would still be important, but that > would be an ISO project, not a W3C one. XML should be ubiquitous (and thus > simple), standards-based, and fast (and thus simple). It will only be ubiquitous if lots of tools support it. > >I agree. Of course, empty elements aren't related to that. > >And neither is downloading SGML databases over the internet... > > They are related to that, through simplicity. If we can make parsing > simpler, we will get better browser support, and thus ubiquity. We will also > get better performance. True, I concede that point -- which is why I wanted to use a form other than or for all EMPTY element. I don't see how having a fixed list of XML elements that are EMPTY for all XML documents, such as BR, HR, IMG, META, LINK and so forth makes things easier. Your TEI documents had better not use any of those GIs except as EMPTY elemnts... > >Then why wire in a list of HTML "du jour" EMPTY elements into > >XML perpetuity? The same program that converts today's HTML into XML > >can change
to
if it likes. > > Because the ERB is _!NOT!_ interested in compatibility with HTML _documents_ > but with EXISTING HTML BROWSERS! They want to be able to do this, in the > short term: What you show does not contain any elements, and for all your shouting :-),\ does not answer my question. > >

This is an HTML-like document with TEI > style date elements, written on 21 Feb > 1980. It also has a TEI header (though it is not > shown here). Thanks to the magic of CSS style sheets, and > HTML convention, the TEI tags can either > disappear, or be mapped to special formatting for existing browsers. RFC 1866 says that unrecognised elements are ignored. A CSS-based browser must treat all those elements as if they were not there. It is not allowed to let you assocuate styles with them, and, if it does, is buggy (albeit useful). Lee Date: Fri, 08 Nov 1996 13:50:39 -0500 To: W3C-SGML-WG@w3.org From: Paul Prescod Subject: Empty tag solution? As I understand the situation, the ERB wants to make an XML-subset compatible with existing HTML browsers by including a list of empty tags in the specification. I am not thrilled with this sort of ad hocery, but I understand the urge to allow a smooth migration from HTML to extended HTML to XML. But perhaps the solution is to change the HTML DTD and instances, instead of the XML standard. What if we changed the content model of all X-HTML empty elements so that they were no longer empty. Then an X-HTML document would look like this:

This is an

And a background sound

This isn't valid HTML, but neither is HTML with XML tags in it. NS 3.0 and IE 3.0 seem to support it. Those who want to do generic markup in other DTDs using traditional authoring tools can do the same thing. Get rid of the empty elements, fix up the existing documents and wait for real XML support. Paul Prescod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html Date: Fri, 08 Nov 1996 12:17:15 -0800 To: W3C-SGML-WG@w3.org From: Tim Bray Subject: XML, HTML, SGML, life, the universe, and everything The rhetorical cannons in here have been going off in all directions, and there are a few points that I thought might benefit from some more clarification. 1. What is XML For? Jon has pointed out that by W3C statute, the primary goal of the ERB and WG work is to enable the delivery of SGML over the Web. Which is true. However, I and several others on both the ERB and the WG (including I think Charles Goldfarb) have an entirely un-hidden agenda, namely to construct a lightweight, lean, mean, easy-to-learn on-ramp for SGML. Which involves no conflict (far as I can see) with the primary Web-oriented goal. At a deep level, XML is *nothing new* - people have been building successful SGML apps for years and making a point of leaving out minimization and other tricky stuff. We're just writing down a standard way to do this. 2. Why the HTML Empty Tag Trick? Primarily, to make it possible for a valid, normalized HTML document also to be a valid XML document. Lee Quinn has raised, and nobody has addressed here, the claim that this is a political move. Not speaking on behalf of the ERB, let me say that I think that Lee is correct; this is a political move, and one which I approve of 100%. It is not an attempt to grandfather existing HTML. It is an attempt to get lightweight SGML off the ground by making it possible to have a dialogue with the huge, well-funded, energetic Web population. Consider two scenarios: a. web-head: "Can XML process HTML documents?" xml-evangelist: "Yes, if they're clean" w-h: ...more questions... b. w-h: "Can XML process HTML documents?" x-e: "No" w-h: "Huh?" x-e: "Well, XML can't handle the syntax of tags like IMG and BR and HR." ... no more questions; the conversation just ended. Now, XML doesn't necessarily win in scenario a; but at least you're still talking and you have a chance. 3. XML and existing SGML tools Existing SGML tools can, if they're compliant, read XML today modulo *only* overlapping enumerated attribute values and perhaps some mild inconsistencies as to which RE's are where. Existing SGML tools can't write XML until they can write empty tags as . I suspect that the SGML vendors of the world could, if they started today, be demonstrating this at SGML'96. Large quantities of SGML that use features such as &-based content models, inclusions, exclusions, and so on, are *not* valid XML and cannot be made into valid XML without some real work. I can't imagine why you'd want to do that work - you already have good tools for dealing with them as SGML, and if you change the end-tag syntax you have well-formed [for well-formed read network-ready] XML. Large quantities of SGML are XML, modulo the syntax of end tags, which I refuse to see as a significant obstacle. It is absolutely the unanimous intent of the ERB that existing SGML tools be able to deal with XML, and there have been significant design compromises in XML in order to make this happen. Paul Grosso's assertion: I have sensed a lot of people trying to give lip service to the claim that XML is a subset of SGML--at least in spirit if not in fact--and it's refreshing to have you admit that this is not your intent. It's not your intention that the base of existing SGML authoring tools will handle XML. is simply incorrect. XML is a subset of SGML in spirit and in fact, and XML is designed so that the adjustments required in existing SGML tools are trivial. Paul, any chance of getting you to back off on that a bit? 4. XML and HTML browsers In order to work with XML, HTML browsers would have to do a small number of things: 1. accept empty tags in the form 2. apply stylesheet directives on non-HTML tags It would also be nice but not essential if they would stop rendering PI's on the screen. [grrrrr] Will this happen? I don't know. I think it would be wonderful and a huge shot in the arm for the Web, and as a consequence a huge shot in the arm for SGML. I think the chances are not that good, but also not zero. If anyone can think of a way to help make this happen, that would be a major contribution. I know for sure that all sorts of people cooking up cool web technologies desperately want to extend HTML, and have damn little chance of getting such extensions blessed by the current W3C process. For them, XML is a gift from above - if the browsers read it. 5. Economic Impacts of XML on the SGML community Yes, if XML succeeds, this will place unprecedented stress on the SGML community, as it scrambles to deal with a user base that has increased by an order of magnitude, and overpowering market pressures >from the big players who have their own axes to grind. It is achingly obvious to me that this is an improvement over the present situation. In particular, this should be a pot of gold for the authoring vendors - none of the current half-cooked HTML-only tools are going to be exactly easy to teach self-extending tag sets to. And I'll tell you something, the end-users are going to love it. I've been pitching the XML idea to my consulting practice customers for the last 2 or 3 months, and the idea of a standard, lightweight, easy way to get into some descriptive markup and structure management is not a hard sell. Most of these people know but SGML but are not currently using it. Mostly because they think it's too complicated. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Fri, 8 Nov 96 17:49:08 CST From: paul@arbortext.com (Paul Grosso) To: W3C-SGML-WG@w3.org Subject: Re: XML, HTML, SGML, life, the universe, and everything > From: Tim Bray > > It is absolutely the unanimous intent of the ERB that existing SGML > tools be able to deal with XML, and there have been significant design > compromises in XML in order to make this happen. Paul Grosso's assertion: > > I have sensed a lot of people trying to give > lip service to the claim that XML is a subset of SGML--at least in > spirit if not in fact--and it's refreshing to have you admit that > this is not your intent. It's not your intention that the base of > existing SGML authoring tools will handle XML. > > is simply incorrect. XML is a subset of SGML in spirit and in fact, and > XML is designed so that the adjustments required in existing SGML tools > are trivial. Paul, any chance of getting you to back off on that a bit? Sure. It appears I was mistaken about the intentions of the ERB with respect to using existing SGML tools. I'm sorry for the misinformation, but I hope my early, relatively semi-private confusion (more private than in front of hundreds at SGML '96 or thousands elsewhere) allows us all to benefit. I have heard it clearly now that XML is a subset of SGML, even if most existing SGML will require some, admittedly minor, conversion to turn it into valid (or well-formed) XML. Is there anything else that needs to be done to your standard SGML declaration for a Basic document other than DELIM GENERAL SGMLREF PIC "?>" and NAMECASE GENERAL NO and whatever has to be done to the character set description (and ignore capacities and quantities) to get it to be sufficient (if admittedly more than necessary) to allow an SGML parser to parse valid XML properly (disregarding the RE/space detail)? paul Date: Fri, 08 Nov 1996 16:57:40 -0800 To: W3C-SGML-WG@w3.org From: Tim Bray Subject: SGML declaration for XML At 05:49 PM 11/8/96 CST, Paul Grosso wrote: >Is there anything else that needs to be done to your standard SGML >declaration for a Basic document other than > DELIM GENERAL SGMLREF PIC "?>" >and > NAMECASE GENERAL NO Huh? I think we finally decided to case-fold, so you mean YES. But somebody who really knows this stuff does need to synthesize an SGML declaration for XML. - Tim Date: Fri, 8 Nov 1996 18:39:16 -0800 (PST) From: "Deborah A. Lapeyre" Subject: Re: XML, HTML, SGML, life, the universe, and everything To: Tim Bray cc: W3C-SGML-WG@w3.org >At a deep level, XML is *nothing new* - people > have been building successful SGML apps for years and making a point of > leaving out minimization and other tricky stuff. We're just writing down > a standard way to do this. This is my hope as part of an SGML consultancy that writes a lot of DTDs and a few apps. We almost never use LINK, CONCUR, SUBDOC, exceptions, #CURRENT, CONREF, etc. now. (Not because we don't like them, or don't understand then, but because we almost never NEED them for real life applications.) We do use parameter entities heavily (both kinds) and despair about RS/RE behavior and the prohibition against the same value in two Declared value list. We don't want this to be "new" either, we hope it will be codified standard practice. Because unless it is codified as well as usual, no one will write applications for/in/using it. > 2. Why the HTML Empty Tag Trick? ...I think that Lee is correct; this > is a political move, and one which I approve of 100%. Seconded. I don't like this solution much, but I have racked for a better one and drawn blank. XML must be easily within the reach of existing tools (small, simple, easy, or clearly superior modes only) or no one will write applications for/in/using it. (And if the tools don't accommodate this fast enough, even I could write a pre/post processor to put them in and take them out with one hand tied behind my back. And so could you. Not a good solution, but a fine temporary.) > 3. XML and existing SGML tools ... Existing SGML tools > can't write XML until they can write empty tags as . I suspect > that the SGML vendors of the world could, if they started today, be > demonstrating this at SGML'96. Pavlov's dogs have nothing on me. As a Co-Chair of SGML'96 may I urge... Being able to demo this, even on a partly smoke-and-mirrors basis would be fantastic! Obviously smaller products with less ISO 9000 and departmental infrastructure have a better change of hacking this in a week, but... Lee, Chris, Gavin, anybody? > XML is a subset of SGML in spirit and in fact, and > XML is designed so that the adjustments required in existing SGML tools > are trivial. This needs to be true. Period. --Debbie Lapeyre Date: Sat, 9 Nov 1996 18:19:06 -0800 (PST) From: "Deborah A. Lapeyre" Subject: Re: Decision: A.22 (no CONREF) To: Jon Bosak cc: w3c-sgml-wg@w3.org > A.22 XML will have no CONREF attributes (11.3.3, 7.3, 7.9.4.4). > Thank you. -dal From: lee@sq.com Date: Sat, 9 Nov 96 21:48:56 EST To: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org Subject: Re: (Repeat) Decision: C.4 (Predefined entities) > (b) Users will be able to override the predefined entities. If it is possible to declare entities in XML, it would be unfortunate if my file did and an SGML browser showed ∏ as I expect, but the XML browser showed a Greek capital letter PI instead (the mathemtical PROD symbol referred to by the prod entity). I also have a file with a list of night clubs formatted as a list, clubs; :-) So I don't think this is a good idea. If you can define any entitiy, you should be able to change them all. If you can't define them. and will never be able to, it's not an issue. If you want to represent predefined entities, either do it in a way that is less likely to conflict, or stick to the accented chracters in iso8859-1. For example, using a prefix of sym for symbol and char for a character, one would have char.aleph sum.prod and so on. If the SDATA entities here are intended to represent glyphs rather than characters (which is wht I suspect) then glyph.Aacute isn't too bad. Lee Here is the list, sorted and put into columns for convenient perusal: > Aacute ccedil eta infin ne Ouml sdot uacute > aacute Cedilla ETH int Ngr ouml sect uArr > Acirc cent eth iota ni para sfgr uarr > acirc chi Euml iquest not part shy Ucirc > acute clubs euml isin notin perp Sigma ucirc > AElig cong exist Iuml nsub PHgr sigma Ugrave > aelig copy fnof iuml Ntilde phis sim ugrave > Agr cup forall kappa ntilde phiv spades Upsi > Agrave curren frac12 Kgr nu Pi sub upsi > agrave dArr frac14 KHgr Oacute pi sube Uuml > aleph darr frac34 Lambda oacute piv sum uuml > alpha degree Gamma lambda Ocirc plusmn sup vprime > amp Delta gamma lang ocirc pound sup1 weierp > and delta ge laquo Ogr Prime sup2 Xi > ang diams gt lArr ogr prod sup3 xi > ap die hArr larr Ograve prop supe Yacute > Aring divide harr le ograve Psi szlig yacute > aring Eacute hearts lowast Omega psi tau yen > Atilde eacute hellip loz omega quot Tgr yuml > atilde Ecirc Iacute lt oplus radic there4 zeta > Auml ecirc iacute macron or rang Theta Zgr > auml EEgr Icirc Mgr ordf raquo thetas > beta Egr icirc micro ordm rArr thetav > Bgr Egrave iexcl middot Oslash rarr THORN > brvbar egrave Igr minus oslash real thorn > bull empty Igrave mu Otilde reg times > cap epsi igrave nabla otilde Rgr trade > Ccedil equiv image nbsp otimes rho Uacute &Lee; Date: Sat, 9 Nov 1996 15:21:04 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Decision: Case sensitivity In its meeting of Thursday, November 7, the SGML ERB decided that for purposes of the XML 1.0 specification, the 8879 rules for case folding in markup shall be extended by folding lowercase to uppercase according to the Unicode mapping tables (see previous correspondence in the WG for an exhaustive list). Abstaining: Clark, Hollander. Date: Sat, 9 Nov 1996 15:17:52 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: (Repeat) Decision: C.4 (Predefined entities) [In my first attempt at this posting, I omitted the list of entities at the end. -- Jon] This is one of a series of reports on recent decisions of the SGML ERB. Due to some confusion on the part of the Chair, this question got resolved in several pieces, which for purposes of simplicity are somewhat condensed in the following report. (a) XML will declare a number of entities automatically. Decision: Yes. Dissenting: Bray. (b) Users will be able to override the predefined entities. Decision: No. Dissenting: Sperberg-McQueen. (Thus, processors shall behave as though declarations for the predefined entities are encountered at the end of the external DTD subset.) (c) In addition to "lt", "amp", and "gt" (decided in a previous vote), the predefined entities shall include "quot" (for hex 22 -- same as in HTML) and "squot" (for hex 27 -- undefined in HTML). Decision: Yes. (d) The predefined entities shall include all those entities specified in the HTML 3.2 specification (the Latin 1 entities plus "copy", "reg", and "nbsp"). Decision: Yes. Dissenting: Bray, Clark. (e) The predefined entities shall include all the entities recently approved by the HTML ERB for inclusion in the "Cougar" DTD. This means, basically, all of the HTML 3.2 entities plus all of the ISO entities for which characters exist in the Adobe Symbol font set, which is supported across Windows, X11, and Macintosh platforms. Decision: Yes. Dissenting: Bray, Clark. Abstaining: Maler. Thus, the list of ISO entities predefined in XML is as follows (list courtesy of Bob Stayton, SCO): ISO Latin 1 ============== quot amp lt gt nbsp iexcl cent pound curren yen brvbar sect die copy ordf laquo not shy reg macron degree plusmn sup2 sup3 acute micro para middot Cedilla sup1 ordm raquo frac14 frac12 frac34 iquest Agrave Aacute Acirc Atilde Auml Aring AElig Ccedil Egrave Eacute Ecirc Euml Igrave Iacute Icirc Iuml ETH Ntilde Ograve Oacute Ocirc Otilde Ouml times Oslash Ugrave Uacute Ucirc Uuml Yacute THORN szlig agrave aacute acirc atilde auml aring aelig ccedil egrave eacute ecirc euml igrave iacute icirc iuml eth ntilde ograve oacute ocirc otilde ouml divide oslash ugrave uacute ucirc uuml yacute thorn yuml Adobe Symbol Font =================== forall exist ni lowast minus cong Agr Bgr KHgr Delta Egr PHgr Gamma EEgr Igr thetav Kgr Lambda Mgr Ngr Ogr Pi Theta Rgr Sigma Tgr Upsi sfgr Omega Xi Psi Zgr there4 perp alpha beta chi delta epsi phis gamma eta iota phiv kappa lambda mu nu ogr pi thetas rho sigma tau upsi piv omega xi psi zeta sim vprime le infin fnof clubs diams hearts spades harr larr uarr rarr darr Prime ge prop part bull ne equiv ap hellip aleph image real weierp otimes oplus empty cap cup sup supe nsub sub sube isin notin ang nabla trade prod radic sdot and or hArr lArr uArr rArr dArr loz lang sum rang int Date: Sat, 9 Nov 1996 14:52:45 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Decision: A.8, B.7 (INCLUDE/IGNORE in DTDs) This is one of a series of reports on recent decisions of the SGML ERB. A.8, B.7 (merged) XML will have INCLUDE and IGNORE marked sections in DTDs. Decision: Yes. Dissenting: Paoli, Bray. Date: Sat, 9 Nov 1996 14:55:09 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Decision: A.22 (no CONREF) This is one of a series of reports on recent decisions of the SGML ERB. A.22 XML will have no CONREF attributes (11.3.3, 7.3, 7.9.4.4). Decision: Yes (no CONREF in XML). Dissenting: Maler. Date: Sat, 9 Nov 1996 14:56:02 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Decision: B.9 ( in SYSTEM identifiers) This is one of a series of reports on recent decisions of the SGML ERB. B.9 XML will allow SYSTEM identifiers (which in XML 1.0 are required to be URLs) to be prefixed by "". Decision: No. Dissenting: Maler, Kimber, Sperberg-McQueen, DeRose. Date: Sat, 9 Nov 1996 14:51:08 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Decision: A.20' (COM delimiter) This is one of a series of reports on recent decisions of the SGML ERB. A.20' XML will change the COM delimiter from '--' to some other string, to minimize user errors. (Candidates: !!, /*, //, **, ??, ;;, ~~. !?, ?!, (), [], others ...) Decision: No. Dissenting: Sperberg-McQueen. Date: Sat, 9 Nov 1996 14:59:35 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Decision: D.4 (parameter entities) This is one of a series of reports on recent decisions of the SGML ERB. D.4 XML shall allow parameter entities and parameter-entity references. (a) XML shall allow internal parameter entities. Decision: Yes. Dissenting: Paoli, Bray. (b) XML shall allow external parameter entities. Decision: Yes. Dissenting: Paoli, Bray, DeRose. Date: Sat, 9 Nov 1996 15:06:45 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Decision: > revisited The ERB has slightly modified its previously reported decision to require "<", "&", and ">" always to be escaped except in markup. The rule for ">" is now that it may always optionally be escaped with > and that it must be escaped when following "]]" if it is not to be interpreted as part of a marked section close. Dissenting: Sperberg-McQueen; abstaining: Clark. Date: Sat, 9 Nov 1996 14:59:02 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Decision: D.3 (XML version of ANY) This is one of a series of reports on recent decisions of the SGML ERB. D.3 XML shall specify a short-hand element declaration keyword (e.g. %ANY-ELEMENT;) for element content in which any element in the DTD is legal (same as ANY, but element not mixed content). Decision: No. Dissenting: DeRose, Hollander. (Note: several members of the ERB feel that this should be dealt with in the SGML revision.) Date: Sat, 9 Nov 1996 14:58:24 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: C.16 (Attribute values if DTD not complete) This is one of a series of reports on recent decisions of the SGML ERB. C.16 When given an incomplete DTD, XML processors and applications may make any assumptions about the treatment of attributes and their values which are consistent with the document. They will be required neither to assume that all attributes are implicity declared CDATA, nor that attributes with names beginning IDREF, ID, ENTITY, etc. have the types IDREF, ID, ENTITY, etc. Decision: No. After much discussion, this became: C.16 In the absence of a declaration, attributes shall behave as if they had been declared CDATA. Decision: Yes. Dissenting: Hollander. (Note: The ERB intends to revisit the possibility of reserving certain attribute names such as "ID" during Phase II of this project, during which it will no doubt have to standardize other incursions into the name space in order to specify hypertext mechanisms.) Date: Sat, 9 Nov 96 12:04:32 CST From: paul@arbortext.com (Paul Grosso) To: W3C-SGML-WG@w3.org Subject: Re: SGML declaration for XML > From: Tim Bray > > At 05:49 PM 11/8/96 CST, Paul Grosso wrote: > > >Is there anything else that needs to be done to your standard SGML > >declaration for a Basic document other than > > DELIM GENERAL SGMLREF PIC "?>" > >and > > NAMECASE GENERAL NO > > Huh? I think we finally decided to case-fold, so you mean YES. I'm quite glad, then, since case sensitivity was problematic for me. Sorry, I must have missed that decision. In that case, we can just go with NAMECASE as in the SGML decl for Basic SGML docs. > But somebody who really knows this stuff does need to synthesize > an SGML declaration for XML. - Tim Of course, 8879:1986 doesn't break down all the options/features in such a way that one could give a precise (necessary and sufficient) 8879:1986 SGML decl for XML, but it would be useful to publish the sufficient and closest-to-necessary-as-possible-given-8879:1986 SGML declaration for XML. Date: Sat, 9 Nov 1996 14:57:46 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Decision: C.4 (Predefined entities) This is one of a series of reports on recent decisions of the SGML ERB. Due to some confusion on the part of the Chair, this question got resolved in several pieces, which for purposes of simplicity are somewhat condensed in the following report. (a) XML will declare a number of entities automatically. Decision: Yes. Dissenting: Bray. (b) Users will be able to override the predefined entities. Decision: No. Dissenting: Sperberg-McQueen. (Thus, processors shall behave as though declarations for the predefined entities are encountered at the end of the external DTD subset.) (c) In addition to "lt", "amp", and "gt" (decided in a previous vote), the predefined entities shall include "quot" (for hex 22 -- same as in HTML) and "squot" (for hex 27 -- undefined in HTML). Decision: Yes. (d) The predefined entities shall include all those entities specified in the HTML 3.2 specification (the Latin 1 entities plus "copy", "reg", and "nbsp"). Decision: Yes. Dissenting: Bray, Clark. (e) The predefined entities shall include all the entities recently approved by the HTML ERB for inclusion in the "Cougar" DTD. This means, basically, all of the HTML 3.2 entities plus all of the ISO entities for which characters exist in the Adobe Symbol font set, which is supported across Windows, X11, and Macintosh platforms. Decision: Yes. Dissenting: Bray, Clark. Abstaining: Maler. Thus, the list of ISO entities predefined in XML is as follows (list courtesy of Bob Stayton, SCO): ******list****** Date: Sat, 9 Nov 1996 11:19:14 -0800 (PST) From: "Deborah A. Lapeyre" Subject: Re: SPACE... To: Michael Sperberg-McQueen cc: W3C SGML Working Group Special spaces are, among other things, a rather old-fashioned typographic technique for inserting a "known" amount of space in a location. The advantage of em-space and en-space (and thin and the like) is that, if your composition device allows it, these can be both clearly specified and font variable. (I.E., My em-space in 36 point Bodini bold not just a generic 12-pt em.) ASCII (currently) makes a distinction between "whitespace" (spaces and tabs) and special characters that happen to resolve to a space on display. Some of these are measured amounts of space (en, em, thin, digit, .. ). Some of these are behaviors, such as "hard-space" or "non breaking space". There hasn't been a problem because SGML tools do not treat   as a space, and wouldn't even CONSIDER compressing "    " into " " although " " is compressed to " ". General thoughts: 1) At least as used in the past, an author intends for special spaces never to go away or be replaced by a "space". 2) How relevant is any of this to screen display? How relevant is any of this to Unicode now? 3) If all spaces translate to "space", then who cares? If the special spaces are individual characters (a la Unicode) then they are not "spaces" at all. Are there any "spaces" that are not characters? (I'm floundering here; these spaces have tied my tongue, but I know what I mean. Can anyone rescue here?) --Debbie Lapeyre ======================================================================= 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: Sat, 9 Nov 1996 21:44:00 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: paul@arbortext.com CC: W3C-SGML-WG@w3.org Subject: Re: SGML declaration for XML | > Huh? I think we finally decided to case-fold, so you mean YES. | | I'm quite glad, then, since case sensitivity was problematic for me. | Sorry, I must have missed that decision. In that case, we can just | go with NAMECASE as in the SGML decl for Basic SGML docs. You didn't miss it. It took me a couple of days to catch up with the reporting. Jon Date: Sun, 10 Nov 1996 01:16:08 -0500 To: bosak@atlantic-83.eng.sun.com (Jon Bosak) From: Harvey Bingham Subject: Re: Decision: C.4 (Predefined entities) Cc: w3c-sgml-wg@w3.org A few of the entity names are rendered on the Netscape 3.0 and MS Internet Explorer 3.0 with suprising results. A trailing ";" concluding an entity name for which there is a shorter valid entity name prefix is retained as part of the text following the entity substitution in Netscape. That trailing ";" is discarded by MS Internet Explorer but the excess characters are retained. In both browsers at least one substitution is for a wrong character: ∉ is recognized by both browsers as ¬ and either "in;" or "in" is retained after that substitution for the not, a known entity in ISO Latin 1. Cedilla; should be cedilla; What is the basis for picking up the Adobe symbol font? Netscape retains the form of unrecognized entities. Internet Explorer retains the prefix of unrecognized entities, discarding the ";". At 15:17 1996/11/09 -0800, you wrote (with much deleted): >Thus, the list of ISO entities predefined in XML is as follows (list >courtesy of Bob Stayton, SCO): > Current anomalies in support: >ISO Latin 1 >======= Netscape 3.0 MS Internet ¨ die unknown, ok keeps ¨ ¯on; macron ok but as macr ok but as macr keeps on; or on keeps on or on °ree; degree ok but as deg ok but as deg keeps ree; or ree keeps ree or ree ¸ Cedilla unknown, keeps all ok+keeps la (should be ¸la; as lower-case) ¸la ok, ok keeps la; or la keeps la la Adobe Symbol Font =================== Only ones I found supported are: >notin wrong symbol wrong symbol keeps in; or in keeps in; or in >trade unknown, ok, as raised keeps all smallcap TM Regards/Harvey Date: Sun, 10 Nov 1996 07:49:38 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: hbingham@ACM.org CC: w3c-sgml-wg@w3.org Subject: Re: Decision: C.4 (Predefined entities) | A few of the entity names are rendered on the Netscape 3.0 and MS | Internet Explorer 3.0 with suprising results. I'm not surprised. :-) | In both browsers at least one substitution is for a wrong character: | ∉ is recognized by both browsers as ¬ and either "in;" or | "in" is retained after that substitution for the not, a known entity | in ISO Latin 1. That's actually correct at this point. "notin" is one of the entities that got approved at the recent HTML ERB meeting but is not part of the HTML standard yet. The entities on Bob's list that appear under "Adobe Symbol Font" are not part of the current HTML 3.2 spec but will be part of Cougar. | Cedilla; should be cedilla; Right. | What is the basis for picking up the Adobe symbol font? The symbol font is supported on all the common Web browser platforms. | Current anomalies in support: | >ISO Latin 1 | >======= Netscape 3.0 MS Internet | | ¨ die unknown, ok | keeps ¨ | | ¯on; macron ok but as macr ok but as macr | keeps on; or on keeps on or on They're right; this should be "macr". | °ree; degree ok but as deg ok but as deg | keeps ree; or ree keeps ree or ree They're right; this should be "deg". | ¸ Cedilla unknown, keeps all ok+keeps la | (should be ¸la; | as lower-case) ¸la ok, ok | keeps la; or la keeps la la They're right; this should be "cedilla". | Adobe Symbol Font | =================== | Only ones I found supported are: | | >notin wrong symbol wrong symbol | keeps in; or in keeps in; or in | | >trade unknown, ok, as raised | keeps all smallcap TM Right, none of the symbol set is officially supported yet. Thanks for your help with this, Harvey. Jon Date: Sun, 10 Nov 1996 07:51:18 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Latest character entity list UCode Entity Name (Unicode 2.0) ----- ------ ------------------ 0022 quot QUOTATION MARK 0026 amp AMPERSAND 0027 squot APOSTROPHE 003C lt LESS-THAN SIGN 003E gt GREATER-THAN SIGN 00A0 nbsp NO-BREAK SPACE 00A1 iexcl INVERTED EXCLAMATION MARK 00A2 cent CENT SIGN 00A3 pound POUND SIGN 00A4 curren CURRENCY SIGN 00A5 yen YEN SIGN 00A6 brvbar BROKEN BAR 00A7 sect SECTION SIGN 00A8 die DIAERESIS 00A9 copy COPYRIGHT SIGN 00AA ordf FEMININE ORDINAL INDICATOR 00AB laquo LEFT-POINTING DOUBLE ANGLE QUOTATION MARK 00AC not NOT SIGN 00AD shy SOFT HYPHEN 00AE reg REGISTERED SIGN 00AF macr MACRON 00B0 deg DEGREE SIGN 00B1 plusmn PLUS-MINUS SIGN 00B2 sup2 SUPERSCRIPT TWO 00B3 sup3 SUPERSCRIPT THREE 00B4 acute ACUTE ACCENT 00B5 micro MICRO SIGN 00B6 para PILCROW SIGN 00B7 middot MIDDLE DOT 00B8 cedilla CEDILLA 00B9 sup1 SUPERSCRIPT ONE 00BA ordm MASCULINE ORDINAL INDICATOR 00BB raquo RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK 00BC frac14 VULGAR FRACTION ONE QUARTER 00BD frac12 VULGAR FRACTION ONE HALF 00BE frac34 VULGAR FRACTION THREE QUARTERS 00BF iquest INVERTED QUESTION MARK 00C0 Agrave LATIN CAPITAL LETTER A WITH GRAVE 00C1 Aacute LATIN CAPITAL LETTER A WITH ACUTE 00C2 Acirc LATIN CAPITAL LETTER A WITH CIRCUMFLEX 00C3 Atilde LATIN CAPITAL LETTER A WITH TILDE 00C4 Auml LATIN CAPITAL LETTER A WITH DIAERESIS 00C5 Aring LATIN CAPITAL LETTER A WITH RING ABOVE 00C6 AElig LATIN CAPITAL LETTER AE 00C7 Ccedil LATIN CAPITAL LETTER C WITH CEDILLA 00C8 Egrave LATIN CAPITAL LETTER E WITH GRAVE 00C9 Eacute LATIN CAPITAL LETTER E WITH ACUTE 00CA Ecirc LATIN CAPITAL LETTER E WITH CIRCUMFLEX 00CB Euml LATIN CAPITAL LETTER E WITH DIAERESIS 00CC Igrave LATIN CAPITAL LETTER I WITH GRAVE 00CD Iacute LATIN CAPITAL LETTER I WITH ACUTE 00CE Icirc LATIN CAPITAL LETTER I WITH CIRCUMFLEX 00CF Iuml LATIN CAPITAL LETTER I WITH DIAERESIS 00D0 ETH LATIN CAPITAL LETTER ETH 00D1 Ntilde LATIN CAPITAL LETTER N WITH TILDE 00D2 Ograve LATIN CAPITAL LETTER O WITH GRAVE 00D3 Oacute LATIN CAPITAL LETTER O WITH ACUTE 00D4 Ocirc LATIN CAPITAL LETTER O WITH CIRCUMFLEX 00D5 Otilde LATIN CAPITAL LETTER O WITH TILDE 00D6 Ouml LATIN CAPITAL LETTER O WITH DIAERESIS 00D7 times MULTIPLICATION SIGN 00D8 Oslash LATIN CAPITAL LETTER O WITH STROKE 00D9 Ugrave LATIN CAPITAL LETTER U WITH GRAVE 00DA Uacute LATIN CAPITAL LETTER U WITH ACUTE 00DB Ucirc LATIN CAPITAL LETTER U WITH CIRCUMFLEX 00DC Uuml LATIN CAPITAL LETTER U WITH DIAERESIS 00DD Yacute LATIN CAPITAL LETTER Y WITH ACUTE 00DE THORN LATIN CAPITAL LETTER THORN 00DF szlig LATIN SMALL LETTER SHARP S 00E0 agrave LATIN SMALL LETTER A WITH GRAVE 00E1 aacute LATIN SMALL LETTER A WITH ACUTE 00E2 acirc LATIN SMALL LETTER A WITH CIRCUMFLEX 00E3 atilde LATIN SMALL LETTER A WITH TILDE 00E4 auml LATIN SMALL LETTER A WITH DIAERESIS 00E5 aring LATIN SMALL LETTER A WITH RING ABOVE 00E6 aelig LATIN SMALL LETTER AE 00E7 ccedil LATIN SMALL LETTER C WITH CEDILLA 00E8 egrave LATIN SMALL LETTER E WITH GRAVE 00E9 eacute LATIN SMALL LETTER E WITH ACUTE 00EA ecirc LATIN SMALL LETTER E WITH CIRCUMFLEX 00EB euml LATIN SMALL LETTER E WITH DIAERESIS 00EC igrave LATIN SMALL LETTER I WITH GRAVE 00ED iacute LATIN SMALL LETTER I WITH ACUTE 00EE icirc LATIN SMALL LETTER I WITH CIRCUMFLEX 00EF iuml LATIN SMALL LETTER I WITH DIAERESIS 00F0 eth LATIN SMALL LETTER ETH 00F1 ntilde LATIN SMALL LETTER N WITH TILDE 00F2 ograve LATIN SMALL LETTER O WITH GRAVE 00F3 oacute LATIN SMALL LETTER O WITH ACUTE 00F4 ocirc LATIN SMALL LETTER O WITH CIRCUMFLEX 00F5 otilde LATIN SMALL LETTER O WITH TILDE 00F6 ouml LATIN SMALL LETTER O WITH DIAERESIS 00F7 divide DIVISION SIGN 00F8 oslash LATIN SMALL LETTER O WITH STROKE 00F9 ugrave LATIN SMALL LETTER U WITH GRAVE 00FA uacute LATIN SMALL LETTER U WITH ACUTE 00FB ucirc LATIN SMALL LETTER U WITH CIRCUMFLEX 00FC uuml LATIN SMALL LETTER U WITH DIAERESIS 00FD yacute LATIN SMALL LETTER Y WITH ACUTE 00FE thorn LATIN SMALL LETTER THORN 00FF yuml LATIN SMALL LETTER Y WITH DIAERESIS 0192 fnof LATIN SMALL LETTER F WITH HOOK 0391 Agr GREEK CAPITAL LETTER ALPHA 0392 Bgr GREEK CAPITAL LETTER BETA 0393 Gamma GREEK CAPITAL LETTER GAMMA 0394 Delta GREEK CAPITAL LETTER DELTA 0395 Egr GREEK CAPITAL LETTER EPSILON 0396 Zgr GREEK CAPITAL LETTER ZETA 0397 EEgr GREEK CAPITAL LETTER ETA 0398 Theta GREEK CAPITAL LETTER THETA 0399 Igr GREEK CAPITAL LETTER IOTA 039A Kgr GREEK CAPITAL LETTER KAPPA 039B Lambda GREEK CAPITAL LETTER LAMDA 039C Mgr GREEK CAPITAL LETTER MU 039D Ngr GREEK CAPITAL LETTER NU 039E Xi GREEK CAPITAL LETTER XI 039F Ogr GREEK CAPITAL LETTER OMICRON 03A0 Pi GREEK CAPITAL LETTER PI 03A1 Rgr GREEK CAPITAL LETTER RHO 03A3 Sigma GREEK CAPITAL LETTER SIGMA 03A4 Tgr GREEK CAPITAL LETTER TAU 03A5 Upsi GREEK CAPITAL LETTER UPSILON 03A6 PHgr GREEK CAPITAL LETTER PHI 03A7 KHgr GREEK CAPITAL LETTER CHI 03A8 Psi GREEK CAPITAL LETTER PSI 03A9 Omega GREEK CAPITAL LETTER OMEGA 03B1 alpha GREEK SMALL LETTER ALPHA 03B2 beta GREEK SMALL LETTER BETA 03B3 gamma GREEK SMALL LETTER GAMMA 03B4 delta GREEK SMALL LETTER DELTA 03B5 epsi GREEK SMALL LETTER EPSILON 03B6 zeta GREEK SMALL LETTER ZETA 03B7 eta GREEK SMALL LETTER ETA 03B8 thetas GREEK SMALL LETTER THETA 03B9 iota GREEK SMALL LETTER IOTA 03BA kappa GREEK SMALL LETTER KAPPA 03BB lambda GREEK SMALL LETTER LAMDA 03BC mu GREEK SMALL LETTER MU 03BD nu GREEK SMALL LETTER NU 03BE xi GREEK SMALL LETTER XI 03BF ogr GREEK SMALL LETTER OMICRON 03C0 pi GREEK SMALL LETTER PI 03C1 rho GREEK SMALL LETTER RHO 03C2 sfgr GREEK SMALL LETTER FINAL SIGMA 03C3 sigma GREEK SMALL LETTER SIGMA 03C4 tau GREEK SMALL LETTER TAU 03C5 upsi GREEK SMALL LETTER UPSILON 03C6 phis GREEK SMALL LETTER PHI 03C7 chi GREEK SMALL LETTER CHI 03C8 psi GREEK SMALL LETTER PSI 03C9 omega GREEK SMALL LETTER OMEGA 03D1 thetav GREEK THETA SYMBOL 03D5 phiv GREEK PHI SYMBOL 03D6 piv GREEK PI SYMBOL 2022 bull BULLET 2026 hellip HORIZONTAL ELLIPSIS 2032 vprime PRIME 2033 Prime DOUBLE PRIME 2111 image BLACK-LETTER CAPITAL I 2118 weierp SCRIPT CAPITAL P 211C real BLACK-LETTER CAPITAL R 2122 trade TRADE MARK SIGN 2135 aleph ALEF SYMBOL 2190 larr LEFTWARDS ARROW 2191 uarr UPWARDS ARROW 2192 rarr RIGHTWARDS ARROW 2193 darr DOWNWARDS ARROW 2194 harr LEFT RIGHT ARROW 21D0 lArr LEFTWARDS DOUBLE ARROW 21D1 uArr UPWARDS DOUBLE ARROW 21D2 rArr RIGHTWARDS DOUBLE ARROW 21D3 dArr DOWNWARDS DOUBLE ARROW 21D4 hArr LEFT RIGHT DOUBLE ARROW 2200 forall FOR ALL 2202 part PARTIAL DIFFERENTIAL 2203 exist THERE EXISTS 2205 empty EMPTY SET 2207 nabla NABLA 2208 isin ELEMENT OF 2209 notin NOT AN ELEMENT OF 220B ni CONTAINS AS MEMBER 220F prod N-ARY PRODUCT 2211 sum N-ARY SUMMATION 2212 minus MINUS SIGN 2217 lowast ASTERISK OPERATOR 221A radic SQUARE ROOT 221D prop PROPORTIONAL TO 221E infin INFINITY 2220 ang ANGLE 2227 and LOGICAL AND 2228 or LOGICAL OR 2229 cap INTERSECTION 222A cup UNION 222B int INTEGRAL 2234 there4 THEREFORE 223C sim TILDE OPERATOR 2245 cong APPROXIMATELY EQUAL TO 2248 ap ALMOST EQUAL TO 2260 ne NOT EQUAL TO 2261 equiv IDENTICAL TO 2264 le LESS-THAN OR EQUAL TO 2265 ge GREATER-THAN OR EQUAL TO 2282 sub SUBSET OF 2283 sup SUPERSET OF 2284 nsub NOT A SUBSET OF 2286 sube SUBSET OF OR EQUAL TO 2287 supe SUPERSET OF OR EQUAL TO 2295 oplus CIRCLED PLUS 2297 otimes CIRCLED TIMES 22A5 perp UP TACK 22C5 sdot DOT OPERATOR 2308 lceil LEFT CEILING 2309 rceil RIGHT CEILING 230A lfloor LEFT FLOOR 230B rfloor RIGHT FLOOR 2329 lang LEFT-POINTING ANGLE BRACKET 232A rang RIGHT-POINTING ANGLE BRACKET 25CA loz LOZENGE 2660 spades BLACK SPADE SUIT 2663 clubs BLACK CLUB SUIT 2665 hearts BLACK HEART SUIT 2666 diams BLACK DIAMOND SUIT Date: Sun, 10 Nov 96 12:23:55 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: (Repeat) Decision: C.4 (Predefined entities) > From: bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) > > (a) XML will declare a number of entities automatically. > > (e) The predefined entities shall include all the entities recently > approved by the HTML ERB for inclusion in the "Cougar" DTD. This > means, basically, all of the HTML 3.2 entities plus all of the ISO > entities for which characters exist in the Adobe Symbol font set, > which is supported across Windows, X11, and Macintosh platforms. > > Decision: Yes. Dissenting: Bray, Clark. Abstaining: Maler. > > Thus, the list of ISO entities predefined in XML is as follows (list > courtesy of Bob Stayton, SCO): > > [...list elided...] I don't want anyone to think I'm trying to start a "but what about my favorite entity" sort of discussion, and I'll be okay with any decision, but by way of an FYI, here are by far the 4 most used entity refs in your average Adept text document (not counting < and & for escaping purposes as already covered in XML by earlier decisions): “, ” (left double quote and right double quote) since Adept automatically puts in your standard (as far as publishing goes) directional double quotes when the user hits the " key. These two entity refs appear in practically every document created by Adept. —, – since Adept automatically puts in your standard (as far as publishing goes) appropriate dash type when the user hits the - key twice or when they hit the - key between two digits. The quotes are in "ISO 8879:1986//ENTITIES Numeric and Special Graphic//EN" and the dashes in "ISO 8879:1986//ENTITIES Publishing//EN". I note that none of these four are in the set Jon distributed. Date: Sun, 10 Nov 96 12:09:56 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: Decision: C.4 (Predefined entities) > From: bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) > > (b) Users will be able to override the predefined entities. > > Decision: No. Dissenting: Sperberg-McQueen. > > (Thus, processors shall behave as though declarations for the > predefined entities are encountered at the end of the external DTD > subset.) Since, in SGML, the first one wins, don't you mean processors shall behave as though declarations for the predefined entities are encountered at the beginning of the internal DTD subset. From: lee@sq.com Date: Sun, 10 Nov 96 14:22:04 EST To: paul@arbortext.com, w3c-sgml-wg@w3.org Subject: Re: (Repeat) Decision: C.4 (Predefined entities) Paul wrote: > here are by far the 4 most used entity refs in your average Adept text > document (not counting < and &) I think this is useful. > “, ” (left double quote and right double quote) > —, – None of these are in Latin 1 or the Adobe Symbol font (you can't substitute the dash from Symbol for a GillSans-UltraBold dash anyway, of course). But they are available on all major platforms, whth more or less effort >from developers. But I agree that it would be good to include them. Please don't specify the replacement text in the XML spec, though, but only the UNICODE character and/or the intended glyph. For example, I might want double quotes to come out 4 points larger than usual -- not uncommon in magazine or newspaper publishing -- and I won't be able to do that in XML by altering the "standard, fixed" entities. I can do it using new entities that themselves include the old ones, of course: “"> in systems that are sufficiently smart. I don't understand the point of being so careful about prefixing all XML names with -XML- earlier, and now suddenly deciding to add several screens' worth of fixed keywords that are not so prefixed. I sense a severe case of Rapidly Encroaching Deployment Elegant Architecture Reduction Syndrome -- RED EARS :-) Lee 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: Recent ERB votes Date: Sun, 10 Nov 1996 19:47:31 GMT On Thu, 7 Nov 1996 08:17:00 -0800, bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) wrote: >The idea is *not* to grandfather in existing HTML; in fact, the spec >bars virtually all existing HTML documents just because of the end-tag >requirement. Rather, the idea is to make it *possible* to create new >documents that are both valid HTML (according to the HTML 3.2 spec) >and valid XML. Such documents would look a lot different from the >typical HTML page today, but they would have the advantage of working >in both the HTML and XML application environments. So HTML users can >run a normalizer on their existing HTML document bases and get >documents that will continue to be viewable by current HTML browsers >but will also work in new XML browsers. Without making the one >extremely limited concession to existing HTML empty elements that came >out of our final round of deliberations, this would not be possible. Yes it would. As Paul Prescod has pointed out, IE and NS 3.0 can both accept end-tags for empty elements. So XML-to-be-read-by-HTML-browsers can have . As you claim it is not an objective for XML to "grandfather" existing HTML, there is no need to support without an end-tag, and therefore no need to pollute XML with knowledge of specific element types. From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Tim Bray Cc: W3C-SGML-WG@w3.org Subject: Re: XML, HTML, SGML, life, the universe, and everything Date: Sun, 10 Nov 1996 19:47:35 GMT On Fri, 08 Nov 1996 12:17:15 -0800, Tim Bray wrote: >1. What is XML For? > >Jon has pointed out that by W3C statute, the primary goal of the ERB >and WG work is to enable the delivery of SGML over the Web. Which is >true. However, I and several others on both the ERB and the WG >(including I think Charles Goldfarb) have an entirely un-hidden agenda, >namely to construct a lightweight, lean, mean, easy-to-learn on-ramp >for SGML. Not just an on-ramp, in my case, but a genuine subset. That means that a valid XML 1.0 document must be a conforming ISO 8879:86 document. >3. XML and existing SGML tools > >Existing SGML tools can, if they're compliant, read XML today modulo >*only* overlapping enumerated attribute values and perhaps some >mild inconsistencies as to which RE's are where. The former makes XML *not* conforming SGML. The latter could avoid being nonconforming if the spec were written carefully (see below). > XML is a subset of SGML in spirit and in fact, and >XML is designed so that the adjustments required in existing SGML tools >are trivial. The above statement is inconsistent on its face. If XML is a subset of SGML "in fact", why should existing "compliant" SGML tools require any adjustments? One can argue (but not here, please) whether a DTD-less markup language is a subset of SGML in spirit, but to be one in fact means that conforming XML documents must conform to 8879. At present, they don't. However, XML can be made conforming (without changing its present RE handling) as follows: 1. The spec must carefully distinguish the "conforming subset" SGML syntax from the other things that XML defines, but which have nothing to do with generic SGML parsing. So far, those other things are: a. Character encoding rules for storage objects. b. A mandatory unvarying SGML declaration. It declares the XML concrete syntax, feature set, etc. c. A mandatory unvarying "XML component" of every DTD. It consists of some entity declarations, a short reference mapping declaration, some element type declarations for empty element types, and a data content notation for white space handling (discussed below). It is considered to occur at the start of the internal subset, meaning that nothing in it can be preempted. d. Some attribute definitions for use in DTDs (notably those having to do with white space handling). e. Prescribed semantic (i.e., not parsing) behavior of XML processors, such as browsers and editors. This would include rules for processor behavior when an XML document is non-conforming (not valid), but possibly well-formed, such as in the absence of a DTD. 2. XML's white space handling should be defined as a data content notation (XMLWS), applicable to the document element. (Suitable shortref mappings can prevent normal SGML RE handling from taking place.) The behavior of the notation can be dependent on attribute values and/or element types, so existing XML white space behavior and/or other useful behaviors could be supported. (It is possible, incidentally, that full SGML applications might want to use this notation.) 3. XML 1.0 would have to drop enumerated attribute values. As has been pointed out, the uniqueness constraint is unjustifiable in the absence of shorttag minimization. Declare them as CDATA and include a comment constraining the values (perhaps expressed as a regexp). All that is lost is parser-level validation. We've exhibited great restraint in more important areas to maintain SGML conformance; it would be unfortunate to abandon conformance just for this one. Date: Sun, 10 Nov 1996 13:06:45 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: U35395@UICVM.UIC.EDU CC: w3c-sgml-wg@w3.org Subject: Re: Decision: C.4 (Predefined entities) | Correction: I think Jon meant to say 'as though declarations for the | predefined entities are encountered at the beginning of the internal | DTD subset.' This makes all user declarations of those entities | into *re*declarations, and renders them nugatory. Sorry, I picked up the wrong version of this from my notes. Jon Date: Sun, 10 Nov 1996 13:28:16 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: lee@sq.com CC: paul@arbortext.com, w3c-sgml-wg@w3.org Subject: Re: (Repeat) Decision: C.4 (Predefined entities) [Lee Quin:] | Paul wrote: | | > here are by far the 4 most used entity refs in your average Adept text | > document (not counting < and &) | I think this is useful. | | > “, ” (left double quote and right double quote) | > —, – | | None of these are in Latin 1 or the Adobe Symbol font (you can't substitute | the dash from Symbol for a GillSans-UltraBold dash anyway, of course). | But they are available on all major platforms, whth more or less effort | from developers. | | But I agree that it would be good to include them. The list that we've adopted simply mirrors a decision of the HTML ERB. Their decision was to include the symbol set; the characters that Paul mentions aren't in it. No argument about relative usefulness here, just consistency of W3C recommendations. | I don't understand the point of being so careful about prefixing all | XML names with -XML- earlier, and now suddenly deciding to add several | screens' worth of fixed keywords that are not so prefixed. I sense a | severe case of Rapidly Encroaching Deployment Elegant Architecture | Reduction Syndrome -- RED EARS :-) All we're doing is recognizing usage in as conservative a way as possible. To millions of people, these entity names have become part of the language. I happen not to like quite a few of them (no offense, Anders), but we're way beyond changing the practice now. I don't like people using the word "gender" when they mean "sex", either, but there comes a point when you have to recognize a cause as lost and move on. Anyone who uses ω at this point to mean anything other than GREEK SMALL LETTER OMEGA is either being obstinately perverse or just ignorant. All we can do is to make the most common names part of the standard so that we are at least doing our best to eliminate the latter possibility. Jon From: lee@sq.com Date: Sun, 10 Nov 96 17:12:29 EST To: w3c-sgml-wg@w3.org Subject: Re: (Repeat) Decision: C.4 (Predefined entities) Thanks for replying. > | > “, ” (left double quote and right double quote) > | > —, – > | But I agree that it would be good to include them. > > The list that we've adopted simply mirrors a decision of the HTML ERB. > Their decision was to include the symbol set; the characters that Paul > mentions aren't in it. No argument about relative usefulness here, > just consistency of W3C recommendations. Consistency with HTML? > | I don't understand the point of being so careful about prefixing all > | XML names with -XML- earlier, and now suddenly deciding to add several > | screens' worth of fixed keywords that are not so prefixed. [...] > All we're doing is recognizing usage in as conservative a way as > possible. To millions of people, these entity names have become part > of the language. The names from the Symbol font are in use by millions of people? I don't believe this. Actually, apart from the accented characters in ISO 8859-1, I don't accept that any of those entity names are being typed knowingly by such quantities of people, and since many of these entities don't work in today's browsers, I don't buy this at all. Have you tried them in Netscape 2.02? Netscape 3? MSIE 3? > Anyone who uses ω at this point to mean > anything other than GREEK SMALL LETTER OMEGA is either being > obstinately perverse or just ignorant. Possibly, but since it doesn't mean that in HTML 2.0, nor in the implementations in use, and since in SGML you can use it for whatever you like, it would not be unreasonable for someone to use it for the engineering OHM symbol, for example. The SGML documentation for the "omega" game might well use it for the name of that game, and I would not call those people "obstinately perverse" nor "ignorant". And taking a name like "prod" seems especially hard to defend. > All we can do is to > make the most common names part of the standard so that we are at > least doing our best to eliminate the latter possibility. If you allow them to be overridden in documents, then it is no longer a problem if people have existing material using them. If you have a fixed list, it would be sensible to make it smaller. If HTML is to be extended to include these entities, it would not seem unreasonable to require some sort of "import" statement in the documents... and of course, SGML has a syntax for that already. I am actually less concerned about backwards compatibility with other standards in this matter as I am with the principle of least surprised. Consider the following tiny XML document: ]> ]> ∏ &endash; book;

Thank you for purchasing ∏. This %book; will take you through the steps of learning to fly your new aeroplane.

In this example, an SGML parser will produce a different ESIS from an XML parser. The XML document will have the greek letter PI in it for a start, whereas the SGML document will include the product name. Now, I for one don't want to get involved in technical support at this point! If it is not possible for an XML DTD to define general entities at all, then this problem goes away, and conversion from SGML to XML will obviously involve entity expansion. One could perhaps use David Megginson's SGMLS.pm perl package to do this, and maybe James might make a version of SPAM that did it (CUSTARD?). We've had a seqence of what to me are very odd decisions lately, ranging from a fixed list of elements declared EMPTY if through some unspecified heuristic the current document is determined to be HTML (it can't be by the published formal definition, as that's illegal in XML, unless that's simply an ERB oversight), through to some strange and SGML-incompatible entities creeping in. I'm worried about this. Should I be? Is XML going to be less useful for its stated purpose (using SGML over the Internet) as a result? I think so. Is it going to be harder to implement? Yes, because now if you have a 2nd definition for an entity, you need to know who defined it in order to determine whether to override it or not. User-defined entities can be overridden provided that their names don't conflict with system-defined ones, but system-defined entities cannot be overridden. Note that this has serious implications for document lifetimes: if XML is revised to include more entities, you WILL break documents. The lack of a required XML Version string at the start ensures this. People objected to my proposal that all XML documents start with saying that it was namespace pollution. But the same people seem happy to add over 100 names without seeming to consider the consequences very carefully. So when you say: > No argument about relative usefulness here, > just consistency of W3C recommendations. what I in fact see is total arbitrariness. What am I missing? Lee Date: Sun, 10 Nov 96 15:51:31 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: Decision: > revisited > From: bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) > To: w3c-sgml-wg@w3.org > > The ERB has slightly modified its previously reported decision to > require "<", "&", and ">" always to be escaped except in markup. The > rule for ">" is now that it may always optionally be escaped with > > and that it must be escaped when following "]]" if it is not to be > interpreted as part of a marked section close. Just to confirm, then, the string: ?> in an XML document is valid text and is only a PIC if one is already in a PI. Is this correct? Date: Sun, 10 Nov 1996 16:06:11 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: lee@sq.com CC: w3c-sgml-wg@w3.org Subject: Re: (Repeat) Decision: C.4 (Predefined entities) | > The list that we've adopted simply mirrors a decision of the HTML ERB. | > Their decision was to include the symbol set; the characters that Paul | > mentions aren't in it. No argument about relative usefulness here, | > just consistency of W3C recommendations. | | Consistency with HTML? Consistency with W3C recommendations. As I said. | > All we're doing is recognizing usage in as conservative a way as | > possible. To millions of people, these entity names have become part | > of the language. | | The names from the Symbol font are in use by millions of people? | I don't believe this. Actually, apart from the accented characters | in ISO 8859-1, I don't accept that any of those entity names are being | typed knowingly by such quantities of people, and since many of these | entities don't work in today's browsers, I don't buy this at all. I meant the entities from the HTML 3.2 set. Your argument seems to be with having any predefined entity names at all. I'm pointing out that you have already lost that battle. | Have you tried them in Netscape 2.02? Netscape 3? MSIE 3? Have you tried them in the versions of these browsers that will available six months from now? Check with Lauren if you don't believe me; she was at the same meeting. | > Anyone who uses ω at this point to mean | > anything other than GREEK SMALL LETTER OMEGA is either being | > obstinately perverse or just ignorant. | | Possibly, but since it doesn't mean that in HTML 2.0, nor in the | implementations in use, and since in SGML you can use it for whatever you | like, it would not be unreasonable for someone to use it for the | engineering OHM symbol, for example. The SGML documentation for the | "omega" game might well use it for the name of that game, and I | would not call those people "obstinately perverse" nor "ignorant". I certainly would if they intended their documents for distribution over the Web. | And taking a name like "prod" seems especially hard to defend. I said that I didn't like all of the names. That's not the point. | > All we can do is to | > make the most common names part of the standard so that we are at | > least doing our best to eliminate the latter possibility. | | If you allow them to be overridden in documents, then it is no longer | a problem if people have existing material using them. We have said a couple of times now that they cannot be overridden in documents. | If you have a fixed list, it would be sensible to make it smaller. Smaller than what every Web browser in the world will support six months from now? Why? | I'm worried about this. Should I be? Is XML going to be less useful | for its stated purpose (using SGML over the Internet) as a result? | I think so. I don't. [... I'll let someone else deal with some of the other points ...] | So when you say: | > No argument about relative usefulness here, | > just consistency of W3C recommendations. | | what I in fact see is total arbitrariness. What am I missing? Maybe the fact that the human use of language evolves in ways that seem arbitrary sometimes and that you have to deal with that if you want to communicate? I think that it's a terrible shame we ever started using the vernacular for written communication; think of how much simpler our work would be if Latin were still the standard. But you can't keep the peasants in line no matter how many academies you set up. The peasants like offloading their declensions onto word order; they appear to like character entities, too. Jon Date: Sun, 10 Nov 1996 22:14:33 -0500 To: Charles@sgmlsource.com, Tim Bray From: "Eve L. Maler" Subject: Re: XML, HTML, SGML, life, the universe, and everything Cc: W3C-SGML-WG@w3.org At 07:47 PM 11/10/96 GMT, Charles F. Goldfarb wrote: >On Fri, 08 Nov 1996 12:17:15 -0800, Tim Bray wrote: >... >>Existing SGML tools can, if they're compliant, read XML today modulo >>*only* overlapping enumerated attribute values and perhaps some >>mild inconsistencies as to which RE's are where. > >The former makes XML *not* conforming SGML. The latter could avoid being >nonconforming if the spec were written carefully (see below). (No matter where the REs are, the *document* would still be valid SGML. It's the *parser behavior* which would differ slightly from "XML processor" behavior...) >> XML is a subset of SGML in spirit and in fact, and >>XML is designed so that the adjustments required in existing SGML tools >>are trivial. > >The above statement is inconsistent on its face. If XML is a subset of >SGML "in >fact", why should existing "compliant" SGML tools require any adjustments? >One >can argue (but not here, please) whether a DTD-less markup language is >a subset >of SGML in spirit, but to be one in fact means that conforming XML >documents >must conform to 8879. At present, they don't. Regarding *writing* XML, it's certainly possible for existing tools to need adjustment. Most SGML-aware editors normalize things like NET. In order to write them out again, they'd need to be modified. (Not that this is achingly hard to do.) >... >2. XML's white space handling should be defined as a data content notation >(XMLWS), applicable to the document element. (Suitable shortref mappings can >prevent normal SGML RE handling from taking place.) The behavior of the >notation >can be dependent on attribute values and/or element types, so existing XML >white >space behavior and/or other useful behaviors could be supported. (It is >possible, incidentally, that full SGML applications might want to use this >notation.) The problem is that only one NOTATION attribute is allowed on any one attlist, and this would be a major invasion of the user's markup design space. (If 8879 were to relax this, it could open up a whole new way to do architectural forms!) >... Eve Date: Sun, 10 Nov 1996 23:20:03 -0600 From: Len Bullard To: Paul Prescod CC: W3C-SGML-WG@w3.org Subject: Re: Recent ERB votes Paul Prescod wrote: > Although I would strongly prefer a standard that works directly with > existing SGML source files, I don't think that a subtly different XML will > "compete" with SGML. Hardly anyone currently serves "real SGML" on the Web > (compared to the number of people that _have_ real SGML). Most people either > don't put it on the Web, or convert it to HTML (losing a lot of > information). Either way we lose. What is currently done and what can be done are different. What the plans of the ERB members and the plans of the implementors are different. What the W3C members want and what is needed may be different. What is ISO 8879 SGML and the XML draft are different. Who loses? Begging the question. I don't accept that. > Although it would not be ideal, an XML that allows a simple, obvious > transform from SGML is MUCH preferable to the current situation. I see a > requirement to transform into XML as an inconvenience but not a show-stopper. No. Nor do I. I just see a slightly more awkward ugly system. I see the same arguments being presented to defend HTML compatibility that are used to defend SGML incompatibility. I see nonsense, and pure and simple also-rans taking advantage of this situation. I don't like it, but I don't vote. But the name of the project was SGML On The Web. When Connoly wrote to me about it, and Jon asked me to join, that is what it was called. Yes, I've read the statements as published. But if this is not to be SGML On The Web, those are false colors and this project has been misrepresented to the SGML community to gain from it a credibility it does not merit. I can't say that any plainer. > What political environment is this political suicide within? XML isn't an > ISO standard, but a W3C standard. SGML 97 will be, but it will obviously not > mention HTML at all. SGML 97 can standardize the format as the > "default" representation for "simple SGML" documents. Some HTML-based XML > documents will not be Simple SGML", just as many other legacy SGML documents > will not be Simple SGML. I don't see where political suicide comes in. Ask those who introduced the term as relevant to a defense of grandfathering HTML. It wasn't me. Whoever or whatever gives them this sense, they must explain. It isn't the SGML community of the ISO working groups as far as I can tell. There is one significant problem with consoritium standards as has been noted before; the need to standardize member practice. > SGML 97 and XML have different legacy problems. The ERB wants some subset of > XML documents to be compatible with EXISTING BROWSERS. That seems like a > politically smart move to me. Whose browsers, Paul? NS and MS? There aren't many viable players left for HTML. Guess what? MS votes but contributes nothing to this list. Let Paoli defend his browser, not you, not the rest of you. Microsoft or Netscape. Their voices aren't even heard on this list. MS justs votes. Nice job if you can get it. If they want to defend their *existing browsers*, let them contribute to the discussion. Are they above that? Politics, not technology? It seems that compatibility with the existing base of SGML tools for SGML On The Web has a voice here too? Am I wrong? I think the SGML community at large should think about this. I think they should be very aware that a self-appointed group of people under the banner of the W3C is deciding whether web browsers from NS or MS are more important than a decade of effort of standards-based tool development and millions of dollars of existing information for systems whose importance are a bit more invested than What's On My Tube This Nanosecond. No, Paul, I am losing patience with this argument. > Could a parser-implementor comment on the extra difficulty imposed by the > "don't worry, be smart" solution? How hard is it? It isn't. I don't think that is the issue. > But we already KNOW the cost of kluges. They are _expensive_. DynaWeb is > _expensive_. DTD-specific converters are _expensive_. Panorama is expensive > because most of your users will never download it, and your information will > be lost. If these kluges were cheap, I would wait a few years for the > network to speed up, and processors to speed up and would just put raw SGML > on the Web. You won't be waiting that long. But you won't build it. Your collegiate friends won't build it. The W3C won't build it. You are too afraid, too enthralled and too bought. HTML and Mosaic were kluges. That didn't bother you because they were free. Better hope MS and NS keep that freeware coming. Your choices there are narrow. > "Simple SGML" (unrelated to the Web) is also interesting and important, but > it could be standardized in SGML 97. Yes. It will be what the Chair, editor and the working group of ISO make it. You better hope that "small incompatibilities" are what they choose as well. Related to the Web? The *Web* is HTTP. HTML is a notation. More coming online every minute. If SGML 97 is positioned for the Internet, there is nothing we can say or do about it. That is ISO's perogative. From what I see of this discussion, the ISO WG8 members are doing everything they can to accomodate. It is the ERB that is being prejudicial. > SGML on the Web seems to be a non-starter for small to medium sized > companies/departments and individuals of all sizes. Bullshit. Pure and simple Bullshit. Anyone out there tried? It depends on the simplification assumptions one makes and the stylesheet. Have you tried? No. > Even for big companies, > I think that it is probably misleading to call the current (or near future) > state of affairs "SGML on the Web". Panorama documents are not accessible to > the majority of Web surfers, and SGML-transformed-to-HTML isn't really SGML > anymore. If you are comfortable converting to HTML, you will be even more > comfortable converting to XML (or XHTML, in the short term). I don't want to convert anything I don't have to. There is no fixing HTML. NS and MS own HTML. It's spoilt goods. XML is still just a proposal. If NS and MS reject it, and the SGML community choose another, ISO-originated choice, XML dies. Len Bullard From: lee@sq.com Date: Mon, 11 Nov 96 01:44:42 EST To: w3c-sgml-wg@w3.org Subject: Re: (Repeat) Decision: C.4 (Predefined entities) >|> The list that we've adopted simply mirrors a decision of the HTML ERB. >|> Their decision was to include the symbol set; To include it in what exactly? >|> the characters that Paul mentions aren't in it. No argument about >|> relative usefulness here, just consistency of W3C recommendations. >| Consistency with HTML? > Consistency with W3C recommendations. As I said. Yes, but which recommendations? Sorry to be obtuse. I don't see how the W3C can usefully make general recommendtions about entity sets in all languages -- they're not available in C, for example! I'm not trying to be awkward. It is really not clear to me that a recommendation that the W3C makes about HTML (presumably) should automatically apply to XML. Earlier you said that the fixed wired-in list of EMPTY elements from (an unspecified version of) HTML only applied in XML if the DOCTYPE was HTML (and there was no DOCTYPE ... PUBLIC line), in order to activate Kludge Mode. Why does the fixed list of wired-in entity names work in all modes, and not just Kludge Mode? > | > All we're doing is recognizing usage in as conservative a way as > | > possible. To millions of people, these entity names have become part > | > of the language. > | > | The names from the Symbol font are in use by millions of people? > I meant the entities from the HTML 3.2 set. I don't have a problem with those names. > Your argument seems to be > with having any predefined entity names at all. No. I'm sorry if I wasn't clear. I had two problems: (1) introducing the Symbol names, seemingly from nowhere. (2) predefining those Symbol entity names in such a way that they can't be overridden. The ISO names were not intended to be used in that way, and are not suitable for such misuse. > | Have you tried them in Netscape 2.02? Netscape 3? MSIE 3? > > Have you tried them in the versions of these browsers that will > available six months from now? Check with Lauren if you don't believe > me; she was at the same meeting. No, but you shouted at me for daring to suggest that there were not in fact millions of users for whom these names were part of the language. What might or night not happen in six months has no bearing on that. Netscape might demonstrate a browser with a million entity names in it today, and thennot release it tomorrow. Any company could. And if they did release it, the markup might spread like wildfire or it might be ignored. We don't know yet. > | > Anyone who uses ω at this point to mean > | > anything other than GREEK SMALL LETTER OMEGA is either being > | > obstinately perverse or just ignorant. > | > | engineering OHM symbol, for example. The SGML documentation for the > | "omega" game might well use it for the name of that game, and I > | would not call those people "obstinately perverse" nor "ignorant". > > I certainly would if they intended their documents for distribution > over the Web. Why? Panorama will interpret such files over the Web today correctly, using standard HTTP. Or do you think the Web is HTML??? Or is this because they would be ignorant of unannounced private demonstrations of what will be released in six months' time? Calling people ignorant for not knowing such things seems unreasonable to me. I might have had less of a problem if I had used "eacute" as an example. But I didn't. > | And taking a name like "prod" seems especially hard to defend. > I said that I didn't like all of the names. That's not the point. It is my point. Don't standardise on unsuitable things. Well, as Vera Lynn might say, there are no angels treading here... :-) > We have said a couple of times now that they cannot be overridden in > documents. > > | If you have a fixed list, it would be sensible to make it smaller. > > Smaller than what every Web browser in the world will support six > months from now? Why? Well, (1) I didn't know that and your announcement didn't mention it, and (2) is Lynx going to be updated? NCSA Mosaic on all platforms? Or is ``all web browsers in the world'' actually only MSIE and Netscape Navigator and any others written by fully paid-up W3C members? [...] > I think that it's a terrible shame we ever started using the > vernacular for written communication; think of how much simpler our > work would be if Latin were still the standard. But you can't keep > the peasants in line no matter how many academies you set up. The > peasants like offloading their declensions onto word order; they > appear to like character entities, too. I'm sorry if I seem like a peasant. It's true that I don't know Latin. I do not dislike entities, either. I will try not to say any more on this -- clearly I am out of place. Sorry. Lee Date: Mon, 11 Nov 1996 03:08:37 -0500 To: cbullard@HiWAAY.net From: Paul Prescod Subject: Re: Recent ERB votes Cc: W3C-SGML-WG@w3.org At 11:20 PM 11/10/96 -0600, Len Bullard wrote: >What is currently done and what can be done are different. I am not convinced. You can't just wire SP into a browser front-end and get "SGML on the Web". It requires too much meta-data. SGML wasn't designed for this environment, and it doesn't "fit". To get the performance we need, we have to have a mechanism for signalling empty elements that does not involve downloading the whole DTD. >> Although it would not be ideal, an XML that allows a simple, obvious >> transform from SGML is MUCH preferable to the current situation. I see a >> requirement to transform into XML as an inconvenience but not a show-stopper. > >No. Nor do I. I just see a slightly more awkward ugly system. In that case, we don't have to have a heated discussion of the issue, because one way or another, the show goes on. >I see >the same arguments being presented to defend HTML compatibility >that are used to defend SGML incompatibility. I see nonsense, and >pure and simple also-rans taking advantage of this situation. I don't know what you mean by this. >I don't like it, but I don't vote. But the name of the project >was SGML On The Web. When Connoly wrote to me about it, and >Jon asked me to join, that is what it was called. Yes, I've >read the statements as published. But if this is not to be >SGML On The Web, those are false colors and this project has >been misrepresented to the SGML community to gain from it >a credibility it does not merit. I can't say that any plainer. As far as I know, nobody is proposing any version of XML which is not SGML. What is being proposed is encoding of new semantics within SGML compatible syntax, which will require a post process to transform from the SGML produced by most SGML tools to the SGML subset that is XML. It is still SGML. Ever since I have been involved in SGML, proponents of it have used the term "SGML" to mean "generic markup." When they (and I) describe the benefits of SGML, they almost always describe it in terms of the benefits of generic markup. So even if XML was an SGML-incompatible generic markup language, W3C would be using _our_ loose terminology to describe their new technology. But nobody is proposing that. >> SGML 97 and XML have different legacy problems. The ERB wants some subset of >> XML documents to be compatible with EXISTING BROWSERS. That seems like a >> politically smart move to me. > >Whose browsers, Paul? NS and MS? There aren't many viable players >left for HTML. Guess what? MS votes but contributes nothing >to this list. Let Paoli defend >his browser, not you, not the rest of you. Microsoft or Netscape. >Their voices aren't even heard on this list. MS justs votes. >Nice job if you can get it. If they want to defend their >*existing browsers*, let them contribute to the discussion. >Are they above that? I dunno. I don't care. When it is in my best interest I will champion the causes of big, stupid, nasty corporations. As you'll see in my tagline, I like to encourage people to use Esso/Exxon or Texaco, because they are the lesser of x evils. Microsoft and Netscape are the cable companies. We have the content. We must conform to their content guidelines (no frontal nudity or undistinguished empty elements!) if we want wide viewership. If we don't want wide viewership, then we can just use our VCR (Panorama). >Politics, not technology? It seems that compatibility with >the existing base of SGML tools for SGML On The Web has a voice >here too? Am I wrong? I think the SGML community at large >should think about this. I think they should be very aware >that a self-appointed group of people under the banner of the >W3C is deciding whether web browsers from NS or MS are more >important than a decade of effort of standards-based tool >development and millions of dollars of existing information >for systems whose importance are a bit more invested than >What's On My Tube This Nanosecond. No, Paul, I am losing >patience with this argument. If you believe that full-blown SGML on the Web is feasible on today's network, we can continue to work towards that goal. Standards compliance is important, and I believe in it. But generic markup is important too -- more important, in my hierarchy. Otherwise why not standardize troff back in 1986? I want to make the generic markup Mass available to the laity. If that means translating it out of Latin, and losing a certain connection to the past, then so be it. It looks like the "translation" is going to be relatively trivial (and, perhaps, non existant). >> Could a parser-implementor comment on the extra difficulty imposed by the >> "don't worry, be smart" solution? How hard is it? > >It isn't. I don't think that is the issue. I think it is. Nobody wants to introduce incompatibility with existing tools as a joke. My understanding is that fast, easy recognition of empty elements is the ONLY reason for this new empty-element syntax. What do you think _is_ the issue? >> SGML on the Web seems to be a non-starter for small to medium sized >> companies/departments and individuals of all sizes. > >Bullshit. Pure and simple Bullshit. Anyone out there tried? >It depends on the simplification assumptions one makes and >the stylesheet. Have you tried? No. Yes. SoftQuad tried. We tried at the University of Waterloo. In the end, we decided to ship ESIS over the web. Panorama also requires a normalization process, and STILL requires the DTD. You posit that a satisfactory product can be built using today's network and today's processors without changing the output of SGML tools. I do not believe it. I could be wrong. Even if it is possible, that wouldn't make generic markup browsers ubiquitous, which is my personal goal in this endeavour. >> Even for big companies, >> I think that it is probably misleading to call the current (or near future) >> state of affairs "SGML on the Web". Panorama documents are not accessible to >> the majority of Web surfers, and SGML-transformed-to-HTML isn't really SGML >> anymore. If you are comfortable converting to HTML, you will be even more >> comfortable converting to XML (or XHTML, in the short term). > >I don't want to convert anything I don't have to. > >There is no fixing HTML. NS and MS own HTML. It's spoilt goods. >XML is still just a proposal. If NS and MS reject it, and the >SGML community choose another, ISO-originated choice, XML dies. If NS and MS reject XML and ISO releases a competitor, then we have gambled and lost, but lost only our time (which will SURELY be recycled into the ISO work anyhow). On the other hand, if NS and MS embrace XML, then we have transformed the world's largest information system into a generic markup based system. SGML-tool output can go through a trivial transform instead of an expensive one. We can publish our documents without information loss to the ordinary people who use the Web (as opposed to the "SGML community"). People with thousands, instead of tens of thousands of dollars can publish generic markup to this same massive readership. Users might start to demand generic markup capabilities in word processors and "Web editors." We can "ramp up" our style sheets from CSS to DSSSL-O to full DSSSL. We can deliver the "help files" for our products in generic markup. SGML databases can be served on the Web through a trivial CGI script. "A Generic Markup Browser on Every Desktop" I consider this a gamble with a million dollar prize and a 50/50 chance of winning. And I suspect that most members of the SGML community (which, IMO, is represented on the ERB) will be happy to take money from our new citizens and do a good deed at the same time. Paul Prescod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html Date: Mon, 11 Nov 1996 03:28:45 -0500 To: w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: (Repeat) Decision: C.4 (Predefined entities) At 03:17 PM 11/9/96 -0800, Jon Bosak wrote: >(b) Users will be able to override the predefined entities. > >Decision: No. Dissenting: Sperberg-McQueen. I don't understand this decision. Perhaps I was asleep at the keyboard, but I haven't yet seen an explanation why these should not be overridable. I understand why they should be predefined, but not why they are not overridable. Paul Prescod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html From: Charles@sgmlsource.com (Charles F. Goldfarb) To: "Eve L. Maler" Cc: Tim Bray , W3C-SGML-WG@w3.org Subject: Re: XML, HTML, SGML, life, the universe, and everything Date: Mon, 11 Nov 1996 10:36:26 GMT On Sun, 10 Nov 1996 22:14:33 -0500, "Eve L. Maler" wrote: >At 07:47 PM 11/10/96 GMT, Charles F. Goldfarb wrote: >>On Fri, 08 Nov 1996 12:17:15 -0800, Tim Bray wrote: > >>... > >>>Existing SGML tools can, if they're compliant, read XML today modulo >>>*only* overlapping enumerated attribute values and perhaps some >>>mild inconsistencies as to which RE's are where. >> >>The former makes XML *not* conforming SGML. You didn't address this point, Eve. >The latter could avoid being >>nonconforming if the spec were written carefully (see below). > >(No matter where the REs are, the *document* would still be valid SGML. >It's the *parser behavior* which would differ slightly from "XML >processor" behavior...) Conforming SGML means that any conforming system will produce the same ESIS. At present, an XML document is not conforming SGML. >>> XML is a subset of SGML in spirit and in fact, and >>>XML is designed so that the adjustments required in existing SGML tools >>>are trivial. >> >>The above statement is inconsistent on its face. If XML is a subset of >>SGML "in >>fact", why should existing "compliant" SGML tools require any adjustments? >>One >>can argue (but not here, please) whether a DTD-less markup language is >>a subset >>of SGML in spirit, but to be one in fact means that conforming XML >>documents >>must conform to 8879. At present, they don't. > >Regarding *writing* XML, it's certainly possible for existing tools >to need adjustment. Most SGML-aware editors normalize things like >NET. In order to write them out again, they'd need to be modified. >(Not that this is achingly hard to do.) True, but it is the parsing that determines conformance, and you haven't refuted my point: XML at present is not conforming SGML. >>2. XML's white space handling should be defined as a data content notation >>(XMLWS), applicable to the document element. (Suitable shortref mappings >can >>prevent normal SGML RE handling from taking place.) The behavior of the >>notation >>can be dependent on attribute values and/or element types, so existing XML >>white >>space behavior and/or other useful behaviors could be supported. (It is >>possible, incidentally, that full SGML applications might want to use this >>notation.) > >The problem is that only one NOTATION attribute is allowed on any >one attlist, and this would be a major invasion of the user's markup >design space. (If 8879 were to relax this, it could open up a whole >new way to do architectural forms!) Not at all. The notation attribute need only be attached to the document element, as everything else is part of its content. Subelements can have their own notations as well. This is certainly a smaller "invasion of the user's markup design space" than the use of dedicated empty element type names or built-in entity declarations. And, it makes XML a conforming subset of SGML, rather than a W3C competitor to ISO. Date: Mon, 11 Nov 1996 22:39:36 +1100 From: Rick Jelliffe To: Michael Sperberg-McQueen CC: W3C SGML Working Group Subject: Re: SPACE... Michael Sperberg-McQueen wrote: > I18nists, speak up now. Reduce them all or not? In favor: it's > simple behavior, it is easily understood, and all white space is > treated the same. Against: well, I don't know whether there is any > argument against, that's what I am asking: *is* there an argument > against? Is the distinction between SPACE, half-width space, > en-space, em-space, double-width space, zenkaku space, etc., to be > preserved in a way that the distinction between SPACE and TAB is not > preserved? In markup, I think that if something looks like whitespace, it should act like whitespace and be treated as a SEPCHAR. However, I don't think using mad typographical spaces it is good markup practise that should be encouraged, so I would be equally happy if just SP and full-width space are treated as SEPCHARs, with a recommendation that the other kinds of spaces be allowed as SEPCHARs in the guise of error-recovery only. What about NBSP? It is tough, but I don't really think it should be exempt: it looks like a space, and it should act like one. This means that languages that use NBSP in words will have to use something else, but there are plenty of things like '-.\'~' for them to use, just like we have to now when we want to construct an identifier >from several words: to make it not a SEPCHAR could make markup visually confusing. In data, I think if someone uses a space character other than the standard ISO 10646 whitespace, they should be free to expect it to be passed to the application as is, otherwise why would they be using it? So I think in ESIS data: (TAB SP LF CR)+ => SP The other kinds of spaces, including the full-width (zenkaku) space, should be left up to the application to deal with. Actually, I am not even really keen on reducing TABs; I would be happy with just (SP LF CR)+ => SP The reduction should be done as a notional post-parse stage, so that 'X' TAB LF '' SP SP LF LF 'X' becomes 'X' SP 'X'. I think this allows more SGML compatability than doing it as a preprocess on the entities, or whatever. Rick Jelliffe Allette Systems Date: Mon, 11 Nov 1996 08:19:05 -0600 From: Len Bullard To: Paul Prescod CC: W3C-SGML-WG@w3.org Subject: Re: Recent ERB votes Paul Prescod wrote: > I am not convinced. You can't just wire SP into a browser front-end and get > "SGML on the Web". It requires too much meta-data. SGML wasn't designed for > this environment, and it doesn't "fit". To get the performance we need, we > have to have a mechanism for signalling empty elements that does not involve > downloading the whole DTD. So you will *wire* in a stylesheet and require Scheme parsing, and you will require the author base to become proficient programmers, and you will require the SGML industry to rewrite its applications and translate all of its large (Very Large, Paul) information so two browsers won't have too? Excuse me, Paul; that's dumb on the face of it. As for SP, no comment. We aren't redesigning SGML here. My thought was that we would try to see where we could do without features to get a better fit. But it goes both ways. I have no problem with . That is trivial to fix. You may find your government has more problems with it than we do. > In that case, we don't have to have a heated discussion of the issue, > because one way or another, the show goes on. Unfortunately, we must. My feeling is that without some adjustment, credible members of the SGML community and ISO are being used to lend credibility to the incredible. > >I see > >the same arguments being presented to defend HTML compatibility > >that are used to defend SGML incompatibility. I see nonsense, and > >pure and simple also-rans taking advantage of this situation. > > I don't know what you mean by this. Every time a requirement to satisfy the requirements of the international standards requires a bit of work, arguments appear that we don't need this. Every time we require an adjustment to HTML, we see silly kludges. That is nonsense. Again, I don't care about . But grandfathering tags from HTML, that is ludicrous. It's bad design for the sake of politics and the personal and economic advantages of those empowered to vote. You are willing to wreck the relationships of W3C to WG8, split the SGML community, dilute both markets, whatever, to keep your privileges and browser. See Scottish history and a fellow named Wallace: "a parcel o' rogues in a nation". So, yes, I think this must be discussed now before this goes one step further. This is the easy part of this design. The next part is a lot harder. Decide now so some of us can decide where we can best focus our own efforts. > As far as I know, nobody is proposing any version of XML which is not SGML. > What is being proposed is encoding of new semantics within SGML compatible > syntax, which will require a post process to transform from the SGML > produced by most SGML tools to the SGML subset that is XML. It is still SGML. See Charles' posts to Eve. He says no. He is the most credible authority in this working group. > So even if XML was an SGML-incompatible generic markup language, W3C > would be using _our_ loose terminology to describe their new technology. But > nobody is proposing that. If it is a W3C competitor to ISO, it is a bald faced failure. > I dunno. I don't care. When it is in my best interest I will champion the > causes of big, stupid, nasty corporations. As you'll see in my tagline, I > like to encourage people to use Esso/Exxon or Texaco, because they are the > lesser of x evils. Microsoft and Netscape are the cable companies. We have > the content. We must conform to their content guidelines (no frontal nudity > or undistinguished empty elements!) if we want wide viewership. If we don't > want wide viewership, then we can just use our VCR (Panorama). Your TV must be wildly different from mine. None of those content guidelines are obeyed. They are given lip service. Pardon, but that I can get on any street corner. I champion the cause of corporations when it makes good sense, technically or economically. Otherwise, when they are wrong, they are wrong. MS was not able to move the VRML community precisely because the self-interested yielded to the greater good, and because they valued the ownership of their own work. The tactics of the Mafia don't work well when the store owners resist. > If you believe that full-blown SGML on the Web is feasible on today's > network, we can continue to work towards that goal. Standards compliance is > important, and I believe in it. But generic markup is important too -- more > important, in my hierarchy. Otherwise why not standardize troff back in 1986? They tried. But full-blown SGML is not what we are discussing. Otherwise, this work would not be needed. I only object to grandfathering HTML to the exclusion of any other considerations. I am reasonably pleased with the other decisions. Truth is, in XML 1.0 I would be quite a bit more restrictive, but I yield to those who insist that IGNORE and INCLUDE, parameter entities, etc. are of "great value". In most cases, I am confident these individuals are protecting their own interests, but I defer on issues I can ignore. > I want to make the generic markup Mass available to the laity. If that means > translating it out of Latin, and losing a certain connection to the past, > then so be it. It looks like the "translation" is going to be relatively > trivial (and, perhaps, non existant). A work for your deity might deserve more respect. That is a personal decision. But if you alter the word of God and consider that trivial, one might wonder about the depth of your worship. Convenience in some things is mortal, not venal. Yet this is technology and legal, validatible agreements; contract law, not holy canons. > I think it is. Nobody wants to introduce incompatibility with existing tools > as a joke. My understanding is that fast, easy recognition of empty elements > is the ONLY reason for this new empty-element syntax. What do you think _is_ > the issue? Grandfathering HTML vs political suicide. Not my term. Part of the explanation for the ERB vote. > Yes. SoftQuad tried. We tried at the University of Waterloo. In the end, we > decided to ship ESIS over the web. Panorama also requires a normalization > process, and STILL requires the DTD. You posit that a satisfactory product > can be built using today's network and today's processors without changing > the output of SGML tools. I do not believe it. I could be wrong. Even if it > is possible, that wouldn't make generic markup browsers ubiquitous, which is > my personal goal in this endeavour. Try shipping markup. Try NOT doing full blown SGML. Try shipping groves. Try a lot of things, but don't claim because you couldn't do it, others can't. I use a very simple form of SGML everyday. It works nicely. I did not say we would not change the output of SGML tools. We just don't use a lot of features. > If NS and MS reject XML and ISO releases a competitor, then we have gambled > and lost, but lost only our time (which will SURELY be recycled into the ISO > work anyhow). That isn't gambling; a gambler bets odds. That is a rejected design. It is a failure to implement. > On the other hand, if NS and MS embrace XML, then we have transformed the > world's largest information system into a generic markup based system. No we haven't. They have. I doubt they will unless economics compels it. NS shows absolutely no interest, and MS won't even do us the courtesy of participation other than voting their interests. > "A Generic Markup Browser on Every Desktop" Only if we build one. Don't expect it otherwise. > I consider this a gamble with a million dollar prize and a 50/50 chance of > winning. And I suspect that most members of the SGML community (which, IMO, > is represented on the ERB) will be happy to take money from our new citizens > and do a good deed at the same time. I don't gamble. That is for suckers. As for who the ERB represents, they represent themselves and possibly their companies. So do I. They vote and that becomes the spec. I don't. Them's the breaks, but hey, no one has to implement the thing if there is another more compelling competitor. As it is said, "standards are nice; so many to choose from". No grandfathering of tags. That is an application problem. len bullard Date: Mon, 11 Nov 1996 10:15:44 -0500 To: Charles@sgmlsource.com, "Eve L. Maler" From: "Eve L. Maler" Subject: Re: XML, HTML, SGML, life, the universe, and everything Cc: Tim Bray , W3C-SGML-WG@w3.org At 10:36 AM 11/11/96 GMT, Charles F. Goldfarb wrote: >>>>Existing SGML tools can, if they're compliant, read XML today modulo >>>>*only* overlapping enumerated attribute values and perhaps some >>>>mild inconsistencies as to which RE's are where. >>> >>>The former makes XML *not* conforming SGML. > >You didn't address this point, Eve. True. That one is incompatible. (I snipped out the parts I agreed with.) The ERB has made some incredibly hard decisions, all to keep compatibility with SGML design, and in the process often went against several of our other principles. Perhaps the notion of a successful SGML on the Web is incompatible with SGML86. If so, we've pared down the true incompatibilites to a tiny list, all because of our commitment to SGML86 and our belief in the SGML97 process. >>The latter could avoid being >>>nonconforming if the spec were written carefully (see below). >> >>(No matter where the REs are, the *document* would still be valid SGML. >>It's the *parser behavior* which would differ slightly from "XML >>processor" behavior...) > >Conforming SGML means that any conforming system will produce the same ESIS. At >present, an XML document is not conforming SGML. But if the XML document is valid -- that is, a full DTD is available (leaving aside for a moment whether the DTD's attlists are all 8879-valid) -- the ESIS is essentially the same, right? "ESIS" is a slippery concept anyway, and the major parsers already produce some differences regarding REs, as I understand it. >>Regarding *writing* XML, it's certainly possible for existing tools >>to need adjustment. Most SGML-aware editors normalize things like >>NET. In order to write them out again, they'd need to be modified. >>(Not that this is achingly hard to do.) > >True, but it is the parsing that determines conformance, and you haven't refuted >my point: XML at present is not conforming SGML. I'm sorry, but I think this is missing the point of XML somehow. I'll let my remarks above stand. >>The problem is that only one NOTATION attribute is allowed on any >>one attlist, and this would be a major invasion of the user's markup >>design space. (If 8879 were to relax this, it could open up a whole >>new way to do architectural forms!) > >Not at all. The notation attribute need only be attached to the document >element, as everything else is part of its content. Subelements can have their >own notations as well. This is certainly a smaller "invasion of the user's >markup design space" than the use of dedicated empty element type names or >built-in entity declarations. And, it makes XML a conforming subset of SGML, >rather than a W3C competitor to ISO. I don't understand how attaching white-space semantics to the document element will help all the other subelements, since it differs on a per-element basis. And the moment you add a notation to a subelement, it can no longer have any other notations. Eve Date: Mon, 11 Nov 1996 09:40:12 -0900 To: W3C-SGML-WG@w3.org From: "W. Eliot Kimber" Subject: Re: Recent ERB votes At 08:19 AM 11/11/96 -0600, Len Bullard wrote: > >> On the other hand, if NS and MS embrace XML, then we have transformed the >> world's largest information system into a generic markup based system. > >No we haven't. They have. I doubt they will unless economics compels >it. NS shows absolutely no interest, and MS won't even do us the >courtesy of participation other than voting their interests. I don't think Len's last statement is entirely fair. In Microsoft's defense, Jean Paoli, who's SGML credentials are as good as anybody's on the ERB, has not simply "voted MS's interests" (to the degree that they could even be meaningfully quantified). Jean certainly argued for design aspects that would make creating Web XML browsers easier and that fit well with the general architecture most Web browsers use, but I don't recall him ever arguing for anything that was wildly in conflict with SGML conformance. Of course, as we all know, the opinions of one employee and corporate policy may be very different. On the other hand, unless Chairman Bill is looking over his shoulder (which I doubt), in this venue, Jean *does* define MS policy and I am satisfied that it is consistent with and supportive of the general XML goals of simplicity and SGML conformance (perhaps biased a bit toward implementation ease, but a bias that is both needed in the group and that is understandable given Jean's background and current assignment). Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 11 Nov 1996 10:34:49 -0500 To: cbullard@HiWAAY.net From: Paul Prescod Subject: Re: Recent ERB votes Cc: W3C-SGML-WG@w3.org At 08:19 AM 11/11/96 -0600, Len Bullard wrote: >So you will *wire* in a stylesheet and require Scheme parsing, and you >will require the author base to become proficient programmers, and >you will require the SGML industry to rewrite its applications and >translate all of its large (Very Large, Paul) information so two >browsers won't have too? We are talking about web delivery of documents, right? On the current network there is _LOADS_ of time to do the necessary conversions as a server-side CGI process. Eons. DynaWeb does SGML-transforms in real-time and delivers the HTML pages almost as quickly as if they were static HTML. So I certainly do NOT propose that you do some mass, batch conversion of gigabytes of data to XML. On the other hand, later in your message you seem to say that you would NOT mind doing so if it were necessary. >Excuse me, Paul; that's dumb on the face of it. As for SP, no comment. >We aren't redesigning SGML here. My thought was that we would try >to see where we could do without features to get a better fit. But >it goes both ways. I have no problem with . That is trivial >to fix. ^^^-- surely it can only be fixed by modifying your existing documents! That is the issue I thought you were concerned about. It is, after all, the major issue that requires a transform from the output of SGML tools to XML. This HTML hackery that is being discussed is not incompatible with SGML in any way, shape or form...it is just a "special case", which good designers tend to try to avoid. In a sense, it is a case where a small subset of XML documents are "incompatible" (or, lets just say "different") from the majority. I think that there is a better way, and I've proposed it, but I will still support XML if it has the HTML-hack in it. >Every time a requirement to satisfy the requirements of the >international >standards requires a bit of work, arguments appear that we don't need >this. Every time we require an adjustment to HTML, we see silly >kludges. That is nonsense. Again, I don't care about . But >grandfathering tags from HTML, that is ludicrous. It's bad design for >the sake of politics and the personal and economic advantages of those >empowered to vote. You are willing to wreck the relationships of >W3C to WG8, split the SGML community, dilute both markets, whatever, >to keep your privileges and browser. See Scottish history and >a fellow named Wallace: "a parcel o' rogues in a nation". Methinks you overstate the case. W8G is not going to smash down W3Cs door because W3C came up with another imperfect standard in the name of backwards-compatibility. Considering the hackery that Charles has proposed in this venture, he understands political realities. Just as he is proposing a "special notation" for XML documents that makes their RE/RS handling "real SGML" (in the letter of the law, if not its spirit), the ERB is propsing a "special subset" of XML which is "real SGML" (in every sense), but is only within the "letter of the law" of the SGML subset known as XML. SGML has LOTS of hackery in it designed to support tools and standards that are now mere memories. It seems unfair to hold XML to a higher standard. I doubt WG8 would do so. >So, yes, I think this must be discussed now before this goes one >step further. This is the easy part of this design. The next >part is a lot harder. Decide now so some of us can decide >where we can best focus our own efforts. Well, we are almost finished part 1, syntax. Part 2 (linking) has only one HTML compatibility concern: URLs must be usable as links, without any special prefix. Part 3 (DSSSL-O) has no backwards compatibility concerns because we have already decided to use DSSSL-O and not CSS. So the issues on the table are probably the last time that XML's HTML heritage should be a concern. >> As far as I know, nobody is proposing any version of XML which is not SGML. >> What is being proposed is encoding of new semantics within SGML compatible >> syntax, which will require a post process to transform from the SGML >> produced by most SGML tools to the SGML subset that is XML. It is still SGML. > >See Charles' posts to Eve. He says no. He is the most credible >authority >in this working group. Charles pointed out that there is only ONE small feature of XML that is SGML incompatible: overlapping enumerated attribute values. He says "it is parsing which determines conformance." Therefore the author-side issues that we are discussing (empty elements etc.) are not issues of conformance or non-conformance. >Your TV must be wildly different from mine. None of those content >guidelines are obeyed. Not at all. Have you ever seen an advertisment encouraging people _NOT_ to buy products and consume ever greater quantities of stuff? There is a group who has put up the "right" amount of money to broadcast such an advertisment but cannot get it on the air on the networks. The networks control the airwaves. Those who want to advertise (or show) must play by their rules. >They tried. But full-blown SGML is not what we are discussing. >Otherwise, >this work would not be needed. I only object to grandfathering HTML to >the exclusion of any other considerations. I haven't yet seen how this is to "the exclusion of other considerations." The only consideration I see being trampelled is elegance and specification simplicity. I've proposed a solution that I consider more elegant and more simple, but I could certainly live with the hack. As I understand it, the hack doesn't trample the name-space of non-HTML documents and doesn't require changes to other XML documents. As far as I can understand, it is a side-effect-free special case. So how does it make your life harder? >I am reasonably pleased >with the other decisions. Truth is, in XML 1.0 I would be quite a bit >more restrictive, but I yield to those who insist that IGNORE and >INCLUDE, >parameter entities, etc. are of "great value". In most cases, I am >confident these individuals are protecting their own interests, but >I defer on issues I can ignore. And why can't you ignore the ...
... special case? >A work for your deity might deserve more respect. That is a personal >decision. But if you alter the word of God and consider that trivial, >one might wonder about the depth of your worship. Convenience in >some things is mortal, not venal. Translation is not generally considered "alteration". Do you read your Book Of Worship in whatever language it was written in? >That isn't gambling; a gambler bets odds. That is a rejected design. >It is a failure to implement. We are gambling that they will not "fail to implement." >> On the other hand, if NS and MS embrace XML, then we have transformed the >> world's largest information system into a generic markup based system. > >No we haven't. They have. I doubt they will unless economics compels >it. NS shows absolutely no interest, and MS won't even do us the >courtesy of participation other than voting their interests. Neither Microsoft nor Netscape participated in the public discussions of CSS, either. But one has implemented and the other has promised to. XML _is_ in Microsoft's economic interest. They use SGML in-house. They are trying to standardize their hypertext delivery. HTML is not flexible enough. They are looking for ways to "out-standardize" Netscape. They have already implemented style sheet support and a basic SGML parser. They have made most of the required investment for XML 1.0 (using HTML linking and CSS) ALREADY. Designing an "SGML for the Web" without expecting MS and NS to implement would be like designing SGML 2.0 and not expecting SoftQuad, ArborText, and Extoerica to support it. XML is also in Netscape's economic interest, but I don't expect them to be smart enough to recognize that. They don't understand documents, having delivered so few of them. >I don't gamble. Standardization is always a gamble. You gear your product towards your perceived user base. You put your product out, and hope that somebody likes/implements it. Paul Prescod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html Date: Mon, 11 Nov 1996 12:02:27 -0500 To: Tim Bray From: murray@spyglass.com (Murray Altheim) Subject: ICADD support in XML [Was: SGML declaration for XML] Cc: W3C-SGML-WG@w3.org, "Michael G. Paciello" Tim Bray writes: >At 05:49 PM 11/8/96 CST, Paul Grosso wrote: >>Is there anything else that needs to be done to your standard SGML >>declaration for a Basic document other than >> DELIM GENERAL SGMLREF PIC "?>" >>and >> NAMECASE GENERAL NO > >Huh? I think we finally decided to case-fold, so you mean YES. >But somebody who really knows this stuff does need to synthesize >an SGML declaration for XML. - Tim I've been trying to locate all references to LINK in the corpus of email and online documents, so pardon me if this comes in from left field. As part of the work I'm doing on behalf of ICADD, I'm providing an LPD to bridge HTML 3.2 and ICADD 2.2 for people with disabilities. I'd like to propose adding support for LINK (specifically IMPLICIT YES) so that the same proposed solution for providing ICADD support for the disabled community in HTML 3.2 could conceivably work for XML. At some point we may want to provide an XML/ICADD LPD along with the XML spec. I realize that LINK is not a common feature in SGML applications, but I believe the same political message would be sent out with XML as currently with the ICADD-less HTML 3.2: W3C is not concerned about providing support to the disabled community. I think (as I'm sure many others do) that this would be a mistake. Note that I'm maintaining a project page on the HTML 3.2/ICADD 2.2 effort at http://www.cm.spyglass.com/doc/icadd/ XML may provide a much greater authoring markup language for the disabled community than HTML, given that the tools for browsing XML have yet to be developed (hence LPD support could be made at least a recommendation), a specific XML flavor could be developed within the disabled community for its own needs, the quality of parsing will be (theoretically) higher, XML seems targeted towards those more concerned with structure and interoperability, etc. Murray cc: Mike Paciello, Executive Director, Yuri Rubinsky Insight Foundation ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." Date: Mon, 11 Nov 1996 11:41:41 -0900 To: W3C-SGML-WG@w3.org, "Michael G. Paciello" From: "W. Eliot Kimber" Subject: Re: ICADD support in XML [Was: SGML declaration for XML] At 12:02 PM 11/11/96 -0500, Murray Altheim wrote: > >I've been trying to locate all references to LINK in the corpus of email >and online documents, so pardon me if this comes in from left field. > >As part of the work I'm doing on behalf of ICADD, I'm providing an LPD to >bridge HTML 3.2 and ICADD 2.2 for people with disabilities. I'd like to >propose adding support for LINK (specifically IMPLICIT YES) so that the >same proposed solution for providing ICADD support for the disabled >community in HTML 3.2 could conceivably work for XML. At some point we may >want to provide an XML/ICADD LPD along with the XML spec. I'm not sure it's strictly necessary to include LINK in the XML spec as any valid XML document can be processed by an SGML parser that supports LINK in order to generate a new XML instance with the link attributes integrated. I too would like to see LINK (at least that part of it needed for associating architectural attributes with elements) in XML, but I think I would agree that it would cause the spec to far exceed the goals set for spec size and simplicity. The use of LINK raises some tricky issues of application-to-parser communication and entity management that would not be resolvable in the time we have for XML 1.0. Note also that the "multiple attribute lists" facility used in architectural meta-DTDs and almost certainly to be included in SGML97 (and, I would presume, immediately adopted by XML), will provide almost the same facility for adding attributes to elements unilaterally that LINK provides today. In other words, with the new syntax, you could so this: ... ]> These attribute declarations could be in an external parameter entity. Note that would you would *NOT* get would be the ability to apply different attributes to the same element type based on hierarchy, which you can do quite effectively with LINK. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 11 Nov 1996 12:13:12 -0600 From: Len Bullard To: "W. Eliot Kimber" CC: W3C-SGML-WG@w3.org Subject: Re: Recent ERB votes W. Eliot Kimber wrote: > > At 08:19 AM 11/11/96 -0600, Len Bullard wrote: > > > >> On the other hand, if NS and MS embrace XML, then we have transformed the > >> world's largest information system into a generic markup based system. > > > >No we haven't. They have. I doubt they will unless economics compels > >it. NS shows absolutely no interest, and MS won't even do us the > >courtesy of participation other than voting their interests. > > I don't think Len's last statement is entirely fair. Perhaps, but it is accurate. > In Microsoft's > defense, Jean Paoli, who's SGML credentials are as good as anybody's on the > ERB, has not simply "voted MS's interests" (to the degree that they could > even be meaningfully quantified). Jean certainly argued for design aspects > that would make creating Web XML browsers easier and that fit well with the > general architecture most Web browsers use, but I don't recall him ever > arguing for anything that was wildly in conflict with SGML conformance. Of > course, as we all know, the opinions of one employee and corporate policy > may be very different. On the other hand, unless Chairman Bill is looking > over his shoulder (which I doubt), in this venue, Jean *does* define MS > policy and I am satisfied that it is consistent with and supportive of the > general XML goals of simplicity and SGML conformance (perhaps biased a bit > toward implementation ease, but a bias that is both needed in the group and > that is understandable given Jean's background and current assignment). Fine Eliot. You hear the discussions; I don't. Let Jean defend his decisions on the working group list. Count the submissions: 0. I don't question his credentials. I watched Microsoft's participation in VRML: it took a brickbat to get them play fair. Perhaps Jean is different, but his personality or credibility are not at issue. The participation of his company is, a participation that should be, for fairness sake, up front and public. The personal policy and the corporate policy may not be the same, but the personal policy is the one we see on this list. I simply hold him to a higher standard because he represents one of the only two credible sources for WWW HTML browsers which are being heavily defended. If Microsoft has plans or positions, enunciate them and this *gamble* takes on less risk. Ok? Fair enough? len Date: Mon, 11 Nov 1996 13:41:53 -0500 To: "W. Eliot Kimber" From: murray@spyglass.com (Murray Altheim) Subject: Re: ICADD support in XML [Was: SGML declaration for XML] Cc: w3c-sgml-wg@w3.org "W. Eliot Kimber" writes: >I'm not sure it's strictly necessary to include LINK in the XML spec as any >valid XML document can be processed by an SGML parser that supports LINK in >order to generate a new XML instance with the link attributes integrated. My experience with SP is that nsgmls requires that one modify the SGML declaration to include LINK IMLICIT YES in order to process LPDs. Am I wrong or misinterpreting your response? This sounds like a workaround rather than a change to the advocated specification. >Note also that the "multiple attribute lists" facility used in >architectural meta-DTDs and almost certainly to be included in SGML97 (and, >I would presume, immediately adopted by XML), will provide almost the same >facility for adding attributes to elements unilaterally that LINK provides >today. [...] >Note that would you would *NOT* get would be the ability to apply different >attributes to the same element type based on hierarchy, which you can do >quite effectively with LINK. I agree that adding an LPD-like document in the declaration subset is a potential solution, but not as effective as an LPD, particularly as the HTML/ICADD LPD will get increasingly complex in attempting to resolve the thornier aspects of HTML 3.2, 3.5, 4.x, and I assume an XML/ICADD LPD would be similar in scope and complexity. Perhaps allowing LINK but placing specific restrictions on its use? I'm certainly not trying to open an enormous door here, just enough of a crack to provide an ICADD solution. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." To: w3c-sgml-wg@w3.org Subject: Re: (Repeat) Decision: C.4 (Predefined entities) Date: Mon, 11 Nov 1996 11:19:43 -0800 From: Joe English bosak@atlantic-83.eng.sun.com (Jon Bosak) wrote: > I think that it's a terrible shame we ever started using the > vernacular for written communication; think of how much simpler our > work would be if Latin were still the standard. But you can't keep > the peasants in line no matter how many academies you set up. The > peasants like offloading their declensions onto word order; they > appear to like character entities, too. This is a gross misrepresentation of Lee's position. There is no problem with predefined entities. There is a big problem with canonizing a set of predefined entities that *cannot be redefined by an XML document or application*. > | since in SGML you can use it for whatever you like [...] > | The SGML documentation for the > | "omega" game might well use it for the name of that game, and I > | would not call those people "obstinately perverse" nor "ignorant". > > I certainly would if they intended their documents for distribution > over the Web. Why? There are no predefined entity names in SGML, let alone reserved, non-overrideable ones. It's neither obstinate nor perverse for an author to expect a system that calls itself SGML-compatible to follow the rules of SGML. Besides that, considering the way the Major Players have treated the issue of putting mathematics on the Web (Netscape: "There does not appear to be a market for it, but if you really want it you can always use JavaScript"; Microsoft: "There does not appear to be a market for it, but if you really want it you can always write a VBX"; W3C: "We're working on the spec. Trust us. We're working on the spec") only the most optimistic Web users expect to see ω recognized by a non-fringe browser any time soon, and even they would be surprised to see thinks like ℑ, ∅, ∏, ♣, ⊥, and ∇ suddenly becoming keywords. > | Have you tried them in Netscape 2.02? Netscape 3? MSIE 3? > > Have you tried them in the versions of these browsers that will > available six months from now? If the XML general entity namespace is to be at the mercy of what Netscape decides to implement six months from now, it would be safest for authors to avoid declaring their own entities altogether. --Joe English jenglish@crl.com Date: Mon, 11 Nov 1996 13:26:35 -0900 To: cbullard@HiWAAY.net From: "W. Eliot Kimber" Subject: Re: Recent ERB votes Cc: W3C-SGML-WG@w3.org At 12:13 PM 11/11/96 -0600, Len Bullard wrote: >I don't question his credentials. I watched Microsoft's participation >in VRML: it took a brickbat to get them play fair. Perhaps Jean is >different, but his personality or credibility are not at issue. The >participation of his company is, a participation that should be, for >fairness sake, up front and public. The personal policy and the >corporate policy may not be the same, but the personal policy is >the one we see on this list. I simply hold him to a higher standard >because he represents one of the only two credible sources for >WWW HTML browsers which are being heavily defended. If Microsoft >has plans or positions, enunciate them and this *gamble* takes on >less risk. > >Ok? Fair enough? I guess. I just didn't want anyone to get the idea that Jean was somehow working to subvert the XML process to somehow reflect MS's presumed nefarious ends. You are certainly entitled to hold Jean and MS to whatever standard you wish and as a former employee of the largest (and, before Microsoft, the most rapacious) vendor in the computer business I can sympathize with holding MS to a higher standard in general (whether it's fair to hold Jean to that same standard, I don't know). I can tell you that in the ERB conference calls and e-mail discussions, Jean never said anything like "it is MS's official position that" or "I've been told by my superiors" or anything. His arguments were always technical, based on his knowledge both of SGML and what he felt he could get MS engineers to accept and implement (which is likely different from what MS official policy on what they *should* accept and implement might be). As XML is largely a marketing exercise, we took his statements about implementability seriously (at least I did), even if we didn't always find them convincing or compelling. There were certainly disagreements about what was and wasn't easily implementable. But Jean never said (and doesn't have the authority to say, as far as I know) "MS will never implement XML if it doesn't have X", at least not in a way that could be construed as a statement of policy [we all made extreme statements in the heat of argument and a lot of them involved the word "never"]. Note also that in the discussion of grandfathering HTML, the focus was on legacy data, not legacy browsers. The question was always *what would the marketing effect of making things really different for HTML authors be", not, how would this hurt Netscape or IE. I think we presumed that Netscape and MS are both more than capable of handling whatever syntax we came up with. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 11 Nov 1996 13:26:38 -0900 To: w3c-sgml-wg@w3.org From: "W. Eliot Kimber" Subject: Re: ICADD support in XML [Was: SGML declaration for XML] At 01:41 PM 11/11/96 -0500, Murray Altheim wrote: >"W. Eliot Kimber" writes: >>I'm not sure it's strictly necessary to include LINK in the XML spec as any >>valid XML document can be processed by an SGML parser that supports LINK in >>order to generate a new XML instance with the link attributes integrated. > >My experience with SP is that nsgmls requires that one modify the SGML >declaration to include LINK IMLICIT YES in order to process LPDs. Am I >wrong or misinterpreting your response? This sounds like a workaround >rather than a change to the advocated specification. Yes, you have to modify the SGML declaration (just as you would to allow OMITTAG or any other optional feature not directly supported by XML). This is a workaround, but one that is generally available, easy to implement, and for which no great barriers exist in the XML spec. In other words, it's a trival NSGMLS application to take as input a valid XML document and an LPD and produce as output a well-formed XML document that includes the ICADD attributes. In fact, adding this feature to any SP- or NSGMLS-based SGML-to-WFXML generator is as simple as recognizing LINK attributes in addition to instance attributes. I would therefore suggest that anyone thinking of writing such a tool include support for putting LINK attributes in the instance. Note that this is really easy if the output is wellformed but not valid, because you don't have to worry about modifying the document type. If you want to produce valid XML documents then you have to update the relevant attribute lists, which is a bit more difficult (but not impossible using something like Earl Hood's DTD processing Perl scripts). Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 11 Nov 1996 14:58:48 -0500 To: W3C-SGML-WG@w3.org From: "Steven J. DeRose" Subject: Re: XML, HTML, SGML, life, the universe, and everything At 10:36 AM 11/11/96 GMT, Charles F. Goldfarb wrote: >Conforming SGML means that any conforming system will produce the same ESIS. At >present, an XML document is not conforming SGML. Well, not exactly ESIS, since ESIS isn't part of 8879. Given that 8879 doesn't say what the result of parsing is, how do you tell whether a conforming system has done "the same thing" as another one has, *purely* given requirements of 8879? In 8879, a parser can be a black box that returns TRUE or FALSE (and maybe some error messages). For example, is there a normative definition for what it actually means to "ignore" an RE? If we take "ignore" at its English face value, then an SGML system which produces a byte-identical copy of its input is non-conforming -- it clearly doesn't ignore the REs that 8879 requires be ignored, so it violates 8879. What I'm saying is, if XML output falls so close to SGML's that nobody cares about the difference in practice, did we make a noise? S Date: Mon, 11 Nov 1996 15:37:06 -0500 To: murray@spyglass.com (Murray Altheim), Tim Bray From: "Steven J. DeRose" Subject: Re: ICADD support in XML [Was: SGML declaration for XML] Cc: W3C-SGML-WG@w3.org, "Michael G. Paciello" At 12:02 PM 11/11/96 -0500, Murray Altheim wrote: >As part of the work I'm doing on behalf of ICADD, I'm providing an LPD to >bridge HTML 3.2 and ICADD 2.2 for people with disabilities. I'd like to >propose adding support for LINK (specifically IMPLICIT YES) so that the >same proposed solution for providing ICADD support for the disabled >community in HTML 3.2 could conceivably work for XML. At some point we may >want to provide an XML/ICADD LPD along with the XML spec. > >I realize that LINK is not a common feature in SGML applications, but I I don't see what the LINK features have to do with ICADD. ICADD involves adding architectural form attributes to elements. You can do that with ATTLIST declarations and be done (which several DTDs have already, admirably, done). Most existing software can look at those attributes and condition formatting or other representational characteristics based on those attributes. Insisting that vendors implement LINK in order to support ICADD is the surest way to be sure no one implements ICADD, which I think would be a tragedy. Steve Date: Mon, 11 Nov 1996 15:57:58 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: (Repeat) Decision: C.4 (Predefined entities) At 11:19 AM 11/11/96, Joe English wrote: >bosak@atlantic-83.eng.sun.com (Jon Bosak) wrote: >There is no problem with predefined entities. There is a big problem >with canonizing a set of predefined entities that *cannot be redefined >by an XML document or application*. I agree with this, and would strongly support overridable predefined entities. Of course, that means that a DTD-less instance with redefined entities will produce different results. I expect people could learn to live with this, since those who create XML DTDs will have to learn how, and that learning will lilkely include the details about overriding. I am sure that the issue of DTD-free processing is what drove the committee to the un-redefinability condition. >Why? There are no predefined entity names in SGML, let alone >reserved, non-overrideable ones. It's neither obstinate >nor perverse for an author to expect a system that calls itself >SGML-compatible to follow the rules of SGML. Nor for an author providing tagged data over the WWW to expect that it will be compatible with other tagged data formats over the web. These two reasonable expectations conflict. We have resolved these conflicts in SGMLs favor (DTD syntax) and in HTML's favor (entities) and in new ways altogether (end tags). I agree about overriding, but the issue of expectations is very complex. >Besides that, considering the way the Major Players have treated >the issue of putting mathematics on the Web (Netscape: >"There does not appear to be a market for it, but if you >really want it you can always use JavaScript"; Microsoft: >"There does not appear to be a market for it, but if you >really want it you can always write a VBX"; W3C: "We're >working on the spec. Trust us. We're working on the spec") >only the most optimistic Web users expect to see ω >recognized by a non-fringe browser any time soon, and even >they would be surprised to see thinks like ℑ, ∅, >∏, ♣, ⊥, and ∇ suddenly becoming keywords. Well, that overlooks the fact that the Adobe characters are _easy to implement_ on Unix, Mac, and PC. They won't do it because it's a good idea, or because people need it, but because the standard says to, and it's almost no extra work to implement it. I won't hold my breath waiting for integrals or summations though. The mathemeticians are unlikely to accept any notation other than TeX anyway, and for reasons that are actually pretty good. >If the XML general entity namespace is to be at the mercy >of what Netscape decides to implement six months from now, >it would be safest for authors to avoid declaring their own >entities altogether. The suggestion was that the XML entity namespace agree with the W3C HTML entity namespace when the standards officially issue (in some timeframe in the future). That is why the proposal is in advance of current practice. -- 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: Mon, 11 Nov 1996 15:57:48 -0500 To: W3C-SGML-WG@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: XML, HTML, SGML, life, the universe, and everything At 5:36 AM 11/11/96, Charles F. Goldfarb wrote: >On Sun, 10 Nov 1996 22:14:33 -0500, "Eve L. Maler" wrote: > >>At 07:47 PM 11/10/96 GMT, Charles F. Goldfarb wrote: >>>On Fri, 08 Nov 1996 12:17:15 -0800, Tim Bray wrote: >> >>>... >> >>>>Existing SGML tools can, if they're compliant, read XML today modulo >>>>*only* overlapping enumerated attribute values and perhaps some >>>>mild inconsistencies as to which RE's are where. >>> >>>The former makes XML *not* conforming SGML. > >You didn't address this point, Eve. Because we have all agreed to bite the bullet here. SGML'97 has the opportunity to fix this problem for SGML, but we can't wait. >Conforming SGML means that any conforming system will produce the same ESIS. At >present, an XML document is not conforming SGML. This is not true. The ESIS definition is not normative text. The standard itself is hopelessly ambiguous on the subject of what is and is not to be produced by an SGML processor, defining only a syntactic acceptance procedure (Exoterica's whitepaper on whitespace is quite informative in this regard). You may _wish_ that the ESIS was normative text, but it is _not_. >>>> XML is a subset of SGML >True, but it is the parsing that determines conformance, and you haven't >refuted >my point: XML at present is not conforming SGML. But I have. Except for the attribute value thing. But that is still impossible to justify in the absence of minimization, and you have already declared that you would be willing to fix in in SGML '97. If we lead by a year, what's the harm? -- 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: Mon, 11 Nov 1996 15:12:16 -0900 To: W3C-SGML-WG@w3.org From: "W. Eliot Kimber" Subject: Re: XML, HTML, SGML, life, the universe, and everything At 02:58 PM 11/11/96 -0500, Steven J. DeRose wrote: >At 10:36 AM 11/11/96 GMT, Charles F. Goldfarb wrote: >>Conforming SGML means that any conforming system will produce the same ESIS. At >>present, an XML document is not conforming SGML. > >Well, not exactly ESIS, since ESIS isn't part of 8879. > >Given that 8879 doesn't say what the result of parsing is, how do you tell >whether a conforming system has done "the same thing" as another one has, >*purely* given requirements of 8879? In 8879, a parser can be a black box >that returns TRUE or FALSE (and maybe some error messages). For example, is >there a normative definition for what it actually means to "ignore" an RE? >If we take "ignore" at its English face value, then an SGML system which >produces a byte-identical copy of its input is non-conforming -- it clearly >doesn't ignore the REs that 8879 requires be ignored, so it violates 8879. > >What I'm saying is, if XML output falls so close to SGML's that nobody cares >about the difference in practice, did we make a noise? I think what needs to be done is to define a grove plan for XML. Given such a grove plan, it is then meaningful to say something like "using the XML grove plan, an XML document parsed by an SGML parser shall produce a grove identical to the grove produced by an XML grove construction process using the same grove plan." Note the connection to the syntax of the source: it's not enough simply to have some arbitrary syntax from which you can construct an SGML grove: it must be possible for an SGML parser to produce the same grove from the same source. For example, the XML grove plan can exclude the "ignored markup" property, thereby stating explicitly that "ignored" REs are in fact truly ignored, in the sense that they will never be available to XML processors operating on an XML document grove. This would certainly provide a more precise definition than "ESIS". Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 11 Nov 1996 15:37:32 -0900 To: W3C-SGML-WG@w3.org From: "W. Eliot Kimber" Subject: Re: ICADD support in XML [Was: SGML declaration for XML] At 03:37 PM 11/11/96 -0500, Steven J. DeRose wrote: >I don't see what the LINK features have to do with ICADD. ICADD involves >adding architectural form attributes to elements. You can do that with >ATTLIST declarations and be done (which several DTDs have already, >admirably, done). Most existing software can look at those attributes and >condition formatting or other representational characteristics based on >those attributes. > >Insisting that vendors implement LINK in order to support ICADD is the >surest way to be sure no one implements ICADD, which I think would be a tragedy. What Steve says is, of course, true, but it somewhat misses the point of using LINK in this case, which is that LINK allows such attributes to be added to documents unilaterally, without the need to modify the document types directly. It also makes it possible to use a wide range of architectures with a documents without overloading each element with a long list of always-there fixed attributes. For ICADD, I think every document type intended to be used for documents that will have visually-impaired readers should include the ICADD architectural attributes in particular, but we can't count on it. I also suspect that once the use of architectures becomes more widespread, which I think it will once the HyTime TC is published and people start to understand the power that's there, that users will start to see how LINK, at least in its simple #IMPLICIT form, can be of real benefit and that, as a result, vendors will start to add support for it. Given that both SoftQuad and ADEPT have to rework their editors to allow element declarations in internal subsets anyway, it can't be that much more effort to support implicit link at the same time. I can't imagine that it would be hard for the DynaText parser to add support for LINK either (if it's Yasp or SP, it's already there or mostly there). However, my point was that, as a delivery mechanism, software that supports LINK sufficiently exists and can be used to easily build the necessary filters. It helps that this software is also free, robust, and fast. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" From: lee@sq.com Date: Mon, 11 Nov 96 16:58:18 EST To: W3C-SGML-WG@w3.org, paciello@yuri.org Subject: Re: ICADD support in XML [Was: SGML declaration for XML] Cc: murray@spyglass.com Steve DeRose wrote: > I don't see what the LINK features have to do with ICADD. nothing, as you point out. > Insisting that vendors implement LINK in order to support ICADD is the > surest way to be sure no one implements ICADD, > which I think would be a tragedy. I agree on all counts -- well said! Lee Date: Mon, 11 Nov 1996 17:43:47 -0600 From: Len Bullard To: "W. Eliot Kimber" CC: W3C-SGML-WG@w3.org Subject: Re: Recent ERB votes W. Eliot Kimber wrote: > > I guess. I just didn't want anyone to get the idea that Jean was somehow > working to subvert the XML process to somehow reflect MS's presumed > nefarious ends. I haven't gone over the edge yet. We squashed all of the "Microsoft is The Evil Empire" stuff on the VRML list and I am the one that stood up for them and got the hate mail from the kids as well as some nice thank yous >from the MS employees. I am also the one that took them to task for not respecting the community they asked to be part of. All in a days work. But anytime we say HTML now, we are automatically saying Netscape or Microsoft. It isn't even a contest elsewhere. Furthermore, ecotonal reality: the W3C HTML spec may not recognize frames, but the ISO draft for VRML 2.0 does. Life at the interface. That is a market reality for the moment, and because they have the HTML browsers any of us who expect to sell in the HTML market will bend. That is also a market reality. Yet, when we begin to grandfather *any* existing SGML application, we are on bad ground and will be held to it. SGML doesn't work that way, and if XML does, I think it is a disaster. That said, do any of you seriously think for a moment we WON'T provide HTML tag scanners? Get real. Truth is, if it says HTML in the content, we won't handle it as SGML. The Dueling Dwarves have made that impossible and the W3C can't fix the problem. So, the tag salad is a permanent part of the code now. Burrrrrp! > You are certainly entitled to hold Jean and MS to whatever > standard you wish and as a former employee of the largest (and, before > Microsoft, the most rapacious) vendor in the computer business I can > sympathize with holding MS to a higher standard in general (whether it's > fair to hold Jean to that same standard, I don't know). In this discusssion, Jean is Microsoft. I will never blame him for any move the company makes, but just as I have to stand up and take blows for Lockheed's local implementations of SGML, he must for MS. That is how it works. OTH, I have also had to stand before the SGML groups and say, "yes, I know, but the programmers just won't do it". Got the T-shirt. > I can tell you that in the ERB conference calls and e-mail discussions, > Jean never said anything like "it is MS's official position that" or "I've > been told by my superiors" or anything. His arguments were always > technical, based on his knowledge both of SGML and what he felt he could > get MS engineers to accept and implement (which is likely different from > what MS official policy on what they *should* accept and implement might > be). Yep. And he will argue for that. No problem. I would much rather see those arguments on this list. I would much rather see all of the ERB arguments on this list. I dislike oligarchy, especially the self-ordained type. It is political reality, but I repeat, if you want support, we have to see the process work: up front. Process makes community. Nothing else will work. The only reason the VRML community stood up to assaults was *everyone* voted. Everyone had a stake. That works. This process will always be suspicious regardless of circumstance. The W3C is a weak consortium and getting weaker by the day. If you want to make it stronger, make it open. By the time VRML 2.0 came around, wiser heads took it to ISO. I suspect XML has a similar future, but by that time, it better be SGML 9x. > As XML is largely a marketing exercise, we took his statements about > implementability seriously (at least I did), even if we didn't always find > them convincing or compelling. Marketing exercise? Call me skittish, but the best way to get this to be accepted is if both communities see it as an advantage. If the SGML tool makers and vendors don't, it will not fly. That is 98 percent certain. We already have work in progress to put SGML on the Internet. If XML is a competitor to that, or is perceived to be, it will be a major problem here. For example, if Dr Goldfarb announces at the end of this process, "nice try but not SGML", XML will have to go elsewhere for support. I don't speak for him, and he certainly will rebut what I say if I misspeak, but his position makes him responsible for an international standard and to an international body supported by nations, not corporations. You and I are aware that he takes that PD seriously. > There were certainly disagreements about > what was and wasn't easily implementable. But Jean never said (and doesn't > have the authority to say, as far as I know) "MS will never implement XML > if it doesn't have X", at least not in a way that could be construed as a > statement of policy [we all made extreme statements in the heat of argument > and a lot of them involved the word "never"]. That is the nature of committee work. Again, no disrespect to Jean, but until his arguments appear on this list, I really don't take his arguments seriously because I don't know what they are. If that is something I don't have to know, then fine. Cooperation isn't a begging exercise. If our engineers can implement it and his can't, so much the better for our market position. That said, I'm on his side about ease, but ease of use, not implementation. We pay programmers to do what they are told. Since we hire good ones and treat them professionally, we expect professional results. Microsoft's personnel policies are their own problem. But sure, as I said, I know about cat herding. > Note also that in the discussion of grandfathering HTML, the focus was on > legacy data, not legacy browsers. When there are only two significant HTML browsers, that is the same thing. Besides, there is a lot of SGML legacy out there. If XML has any other life, why not grandfather that? The reason given was "political suicide". I repeat: what shotgun compels that? If it is just vs , use and ALL of the applications are happy. But to grandfather one app for it's legacy and leave the rest, the ERB is on bad ground. > The question was always *what would the > marketing effect of making things really different for HTML authors be", > not, how would this hurt Netscape or IE. What about the rest of the world's SGML authors? Fish or cut bait. > I think we presumed that Netscape > and MS are both more than capable of handling whatever syntax we came up with. I hope so. I have my doubts. We have done a lot of work in this area and some aspects of one of those browsers make us very suspicious of its extant code base. As for our work, we will use SGML. If XML works there, good. If not, let the market pick products based on criteria they understand. We have HTML apps ready. It is the SGML that is work and it is close. DSSSL is next year's challenge. Dang. back on the airplane tomorrow.... cheers, len Date: Mon, 11 Nov 1996 17:44:21 -0600 From: Len Bullard To: "W. Eliot Kimber" CC: W3C-SGML-WG@w3.org Subject: Re: XML, HTML, SGML, life, the universe, and everything W. Eliot Kimber wrote: > > I think what needs to be done is to define a grove plan for XML. Given > such a grove plan, it is then meaningful to say something like "using the > XML grove plan, an XML document parsed by an SGML parser shall produce a > grove identical to the grove produced by an XML grove construction process > using the same grove plan." [snip] > This would certainly provide a more precise definition than "ESIS". This is emminently sensible. Accepting the grove concept would certainly make the other pieces we need to consider easier to specify as well. ESIS has been a weakly defined concept for some time and has not given us the required precision in many cases. That is why we have heard the term "beyondESIS" or "superESIS" too often. I think this also establishes a precedent that will serve the W3C members well in other applications and language work if adopted. What are the objections? len Date: Mon, 11 Nov 1996 16:22:26 -0800 From: lauren@sqwest.bc.ca (Lauren Wood) To: w3c-sgml-wg@w3.org Subject: Re: (Repeat) Decision: C.4 (Predefined entities) % From: dgd@cs.bu.edu (David G. Durand) % % I agree with this, and would strongly support overridable predefined entities. % % Of course, that means that a DTD-less instance with redefined entities % will produce different results. I expect people could learn to live with % this, since those who create XML DTDs will have to learn how, and that % learning will lilkely include the details about overriding. I am sure that % the issue of DTD-free processing is what drove the committee to the % un-redefinability condition. The whole issue here seems to have been caught up with attitudes towards HTML. I don't think HTML is even particularly relevant to the main question, which is: Is the simplification inherent in defining a set of entities worth the loss of flexibility for this version of XML? The advantage of the simplification is knowing that applications won't do something weird with your data if you don't supply a DTD. It's knowing that ä is always a with an umlaut, etc. The other side is the flexibility that SGML users are used to having, and that hopefully XML users will soon get used to having. This would come at the cost of some bandwidth to transmit the redefinitions, and some complication to the specification. We should make such a decision based on what we think will be good for XML, not because of, or in spite of, anything that MS or NS may or may not do in the HTML world. I personally think having a base set is a good idea; I would probably prefer to use other entity names to avoid clashes and possible misunderstandings; but others who already have large quantities of data that they want to put up on the Web with as little fuss as possible need to think about whether the trade-off is worthwhile. I do; others may not. cheers, Lauren --- Lauren Wood, SoftQuad, Inc. Lauren Date: Tue, 12 Nov 1996 00:10:40 -0500 To: "Deborah A. Lapeyre" From: masonjd@ornl.gov (James David Mason) Subject: Re: SPACE... Cc: Michael Sperberg-McQueen , W3C SGML Working Group At 11:19 AM 11/9/96 -0800, Deborah A. Lapeyre wrote: > >Special spaces are, among other things, a rather old-fashioned typographic >technique for inserting a "known" amount of space in a location. The >advantage of em-space and en-space (and thin and the like) is that, if >your composition device allows it, these can be both clearly specified >and font variable. (I.E., My em-space in 36 point Bodini bold not just a >generic 12-pt em.) > >ASCII (currently) makes a distinction between "whitespace" (spaces and >tabs) and special characters that happen to resolve to a space on display. >Some of these are measured amounts of space (en, em, thin, digit, .. ). >Some of these are behaviors, such as "hard-space" or "non breaking space". >There hasn't been a problem because SGML tools do not treat   as >a space, and wouldn't even CONSIDER compressing "    " >into " " although " " is compressed to " ". > >General thoughts: > >1) At least as used in the past, an author intends for special spaces never >to go away or be replaced by a "space". > >2) How relevant is any of this to screen display? How >relevant is any of this to Unicode now? > >3) If all spaces translate to "space", then who cares? If the special >spaces are individual characters (a la Unicode) then they are not >"spaces" at all. Are there any "spaces" that are not characters? > >(I'm floundering here; these spaces have tied my tongue, but I know what I >mean. Can anyone rescue here?) > >--Debbie Lapeyre I'm pretty spacey after a day of standards meetings, but I second what I think I hear Debbie saying here. There is "whitespace" which composition systems, as well as SGML processors, have traditionally thrown away. Then there is space which is special and which I don't want any system to mess with. To Debbie's list I add the spaces that are part of the rhetoric of mathematics, such as the one before the "dx" in an integral. And what about italic correction? That's space that sometimes the user adds, but that may also be added by a good composition system like TeX. I've always been uneasy about SGML's handling of space, which seems overly fussy from certain programming perspectives but unnecessary and downright confusing from a user-interface perspective. (Sitting through a couple of hours of discussions about the character-coding parts of the SGML Declaration is good for reinforcing the suspicion that we work hard at making things hard for ourselves. Hearing some notable parser writers' comments on their sufferings tends to reinforce that suspicion.) A lot of screen displays certainly aren't good enough to reproduce the old typographers' use of space, but I don't think the issue will go away. The mathematicians continue to use TeX because of its capabilities for typographic expression, in spite of the rise of WYSIWYG systems. After a few years of MacTacky, we've seen a return to concern for well-designed fonts. I suspect that concern for spacing will return, too, as display technology improves. 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 http://www.ornl.gov/sgml/wg8/wg8home.htm Date: Mon, 11 Nov 1996 23:17:21 -0600 To: W3C-SGML-WG@w3.org From: Robert Streich Subject: Re: Recent ERB votes At 12:30 PM 11/6/96 -0800, Tim Bray wrote: > - In order to make it possible that a valid HTML document can be a valid > XML document, the XML spec will state that XML processors, when they are > processing HTML documents, should recognize, in a built-in way, that the > elements declared as EMPTY for HTML 3.2 (BR, HR, IMG, etc.) are empty even > without syntactic indication. The manner in which an XML processor > is to decide whether a document is HTML is not constrained by the spec. Wow! It's utterly amazing how quickly a whole lot of hard-earned credibility can disappear in one fell swoop! All of the sometimes eloquent, frequently lucid, always opinionated technical arguments in defense of this or that feature/exclusion/modification just became compromised in one decision of extremely questionable value. I wish I had the time to express my feelings completely about the state of affairs, but I don't (perhaps the better for all of us). So all I can say is: "I just don't get it." I hear and understand your comments, Jon, but I think you're (the ERB) talking out both sides of your mouth. I agree wholeheartedly with all of the disagreement to this decision. It never should have seen the light of day. Perhaps that's why it didn't until it became a "decision." bob Robert Streich streich@slb.com Schlumberger voice: 1 512 331 3318 Austin Research fax: 1 512 331 3760 From: "Christopher R. Maden" Date: Tue, 12 Nov 1996 06:02:32 GMT To: w3c-sgml-wg@w3.org Subject: 1 Nov. draft comments All comments are against the 1 November draft. However, the draft on the W3C Web server and the one on Textuality are both identified as version 0.01, 1 November, yet are different. When not identified, comments are believed applicable to both, but have only been checked against (and cut&pasted from) the Textuality version. Header: Pointer to "this version" is invalid. Clause 1.1, W3C version only: Says that this is only for the SGML ERB, but is publicly available. It looks like a "leak". Clause 1.5, production group 4: QuotedNames ::= '"' Names '"' | "'" Names "'" The non-terminal Names is never defined. Clause 2.2, first paragraph: A character is A character is an atomic... Typo. Clause 2.3, production group 6: | '' /* doc type declaration */ The beginning of the production component allows a jumble, and the end does not allow space between DSC and MDC. If the purpose is to simply allow recognition and skipping of the doctype declaration, then ']* ('[' [^]]* ']' S?)? '>' should suffice; if more restrictive syntax is warranted, then something like the doctypedecl production (in 2.8) should be invoked. Clause 2.3, last paragraph, W3C: the single-quote character (') may be represented as "&sq;", and the double-quote character (") as "&dq;". Clause 2.3, last paragraph, Textuality: the single-quote character (') may be represented as "&sqot;", and the double-quote character (") as """. Please synchronize the W3C version and Textuality's, and PLEASE change version numbers when something as substantial as this changes. Both versions are identified as 0.01. I far prefer the Textuality version here. Clause 2.4, first paragraph: Comments may appear anywhere that character data may, except in a marked section (more properly, comments appearing in a marked section will not be recognized as such). Comments may appear in element content and in the prolog, as well, no? In other words, "Comments may appear anywhere, except in a marked section; i.e., within element content, in mixed content, or in a document type declaration subset (see doctypedecl)." Clause 2.6, and in general: Wherever using a term important to ISO 8879 in a different manner from 8879, the term 8879 uses for the concept should be given for reference. In this case, the term "marked section" in XML refers to what 8879 calls "CDATA marked section". This should be made clear in a note; as 8879 is referenced, some non-trivial portion of implementers will make reference to it, and different terminology may confuse them. Clause 2.7: I still think that making whitespace handling vary by an attribute value is a big mistake. This is something that should be handled by a stylesheet. If all whitespace, everywhere, is preserved by the XML processor, the application is guaranteed not to lose any it wants, and can toss anything it doesn't. For most formatting, some whitespace will need to be collapsed and others kept, so a renderer would need this ability anyway. Adding it to the processor requirement seems silly. Clause 2.7, example: Does this mean '*' is allowable at that point in an ATTLIST declaration? It should be made clear in the surrounding text. (Given that attlist declarations are not cumulative, this attribute will need to be definied for every element on which it will be used, even if just to default it. Seems a bit silly.) Clause 2.8, production group 12: The placement of the production group breaks up the flow of text; the paragraph after refers to "these two subsets", and I was very confused as to *which* two until I realized that they had been referenced in the paragraph prior to the production group. Move the group down a paragraph, just before the example, maybe. Clause 2.9, third paragraph: 1. attributes with default values, and elements to which these attributes apply appear in the document,.. I think a more applicable phrasing is, "attributes with default values, and elements to which these attributes apply *and are not explicitly set* appear in the document..." though this may be too complex to easily check. Clause 2.9, last paragraph: If no RMD is provided, the effect is identical to an RMD with the value ALL. I feel that NONE should be the default. The simplest XML document should not require the RMD at all. Clause 3.1, second text paragraph: The Name in the start- and end-tag rules gives the element's type. Strike "rules", or reword this. "The Name referred to in the ..." or "The Name in the ... -tags gives...". Ibid: The Name-QuotedCData pairs are referred to as the attributes of the element,... Everyone here is aware that this is the attribute value specification, but we use the terms interchangeably. We must NOT do this in the XML spec; it caused endless headaches when Netscape started to handle entity refs in attribute value *specifications*. The discussions about when to use & and when to use %24 in
went for far too long on www-html, html-wg, and lynx-dev. Care must be taken in XML to use the correct terms "attribute value specification" and "attribute value" as appropriate. Even though entity references are not allowed in AVSs in XML 1.0, lack of confusion now will make going forward easier. Clause 3.1, production group 17: content ::= (element | PCDATA | MS | PI | Comment)* There should be [ VC: Content model ] after that; i.e., the content of an element will match the content model in the DTD if the document is valid. Clause 3.2, second list: More simply stated, the elements, delineated by start- and end-tags, nest within each other properly. Either strike "properly" or define it. Nesting makes sense, I think, to the target non-SGML-aware audience; adding "properly" implies that there's something special that's not being said. Clause 3.5: Where did it go? It's in the W3C version, but not on Textuality. Has the DTD summary been done away with? It's no longer needed for empty elements, and is moot for mixed vs. element content distinction, but would be a VERY useful way to override the defaulted entities without requiring DTD parsing. The receiving non-DTD-speaking application could say, "This ∏ here does something other than a big ol' pi, but I don't know what...". Clause 4.2, productions: EntityDecl ::= '' EntityDef ::= Literal | ExternalDef; ... ExternalDef ::= NDataDecl? 'SYSTEM' Literal NDataDecl ::= 'NDATA' S Name S [ VC: Notation Declared ] These are badly broken. or is legal. In addition, the order of the external identifier and notation identifier is backwards from 8879 production [108]. Try these: EntityDecl ::= '' ExternalDef ::= 'SYSTEM' S Literal (S NDataDecl)? NDataDecl ::= 'NDATA' S Name [ VC: Notation Declared ] Clause 4.2.3, production group 30 (W3C) or 29 (Textuality): Encoding ::= ... Are the members of the enumerated list the only encodings permitted in XML 1.0, at all? What about other IANA-registered encodings, if the system can handle them? What about X-prefixed ones that are spoken by the system? Clause 4.4, production group 30 (Textuality; 31? on W3C): NotationDecl ::= '' The Extid non-terminal is not defined. It is also used in doctypedecl, but I didn't notice until now. Also, depending on what Extid ends up defined as, this can read as requiring system identifiers on notation declarations. In the worst case, MIME types may be required, a for-real filename must NEVER be required (and should be deprecated) in a notation declaration. Appendix A, feature list: 3. The "&" connector in content models Make that 'The "and" connector'. General gripe #1: Versioning XML desparately needs versioning information. Otherwise, XML 2.0 will struggle painfully with how to make itself not cripple XML 1.0 systems. At a minimum, XML 1.0 can have an absence of versioning information if it knows how to recognize a newer version. I would prefer that an explicit mechanism be provided now, but with a default of 1.0 in its absence. A required element has been rejected; perhaps a PI, then: . General gripe #2: Case folding I predict, based on the www-international list and private conversations, that case-folding is not going to work as spec'd now. But besides that: a non-folding document is valid in a folding system, but the reverse is not true. In other words, we can add case folding later, but taking it out is going to HURT! Keep XML 1.0 case sensitive and spend the next year trying to figure out how to do case- folding intelligently, if it can be done at all. I think the number of SGML documents (including HTML) that will be valid XML at this point with no processing whatsoever is vanishingly small, and allowing the individual data preparers to decide what to do with their case is far better than to impose weird rules from above. General gripe #3: HTML concessions The list of elements is silly. works fine. (I tried the
hack; gets through Lynx 2.6, but
doesn't get recognized.) If an XML processor detects that the document is HTML, then for God's sake process it as HTML! I can think, off the top of my head, of 2 SGML systems that drop into a special mode when HTML is detected. (If it were earlier, I could probably come up with more.) The acceptance in HTML means that documents *can* be XML and acceptable to HTML browsers, and *all* HTML (unless anyone really uses

and ) will require some processing. Case fold it and end-tag empties while you're at it. The entity list is also this way. I am very in favor of < and &, and mostly in favor of the HTML 2.0 list. A list of future entities has, I think, no place in the XML 1.0 spec. It's being announced in a little over a week; no one is used to those entities yet. If there were a DTD-less way to overrride them, as with PIs, I wouldn't mind so much. (And as for who will incorporate them into Lynx: probably me. Lynx 2.6 currently has the biggest list of supported entities of any Web client, and I'd be happy (if busy) to keep it on top of the stack.) Bleah. I'm going to bed now. Please excuse terminal-induced weirdness in this message. -Chris -- http://www.ebt.com +1.401.421.9550 +1.401.521.2030 One Richmond Square, Providence, RI 02906 USA" NDATA SGML.Geek> Date: Tue, 12 Nov 1996 11:15:59 -0500 From: gtn@ebt.com (Gavin Nicol) To: mtbryan@sgml.u-net.com CC: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: SPACE... >than separators in data. I can't really see people entering >four-per-em-spaces in an attribute value, though I can see them trying to >enter a zenkaku space in a Japanese attribute value The problem I've seen much more often is zenkaku spaces in a DTD... Date: Tue, 12 Nov 1996 11:18:57 -0500 From: gtn@ebt.com (Gavin Nicol) To: papresco@calum.csclub.uwaterloo.ca CC: W3C-SGML-WG@w3.org Subject: Re: Recent ERB votes >But we already KNOW the cost of kluges. They are _expensive_. DynaWeb is >_expensive_. DTD-specific converters are _expensive_. Panorama is expensive >because most of your users will never download it, and your information will >be lost. If these kluges were cheap, I would wait a few years for the >network to speed up, and processors to speed up and would just put raw SGML >on the Web. I wouldn't call any of these kludges... Date: Tue, 12 Nov 1996 09:34:45 -0800 To: W3C-SGML-WG@w3.org From: Tim Bray Subject: Re: Recent ERB votes At 11:20 PM 10/11/96 -0600, Len Bullard wrote: ... a whole bunch of stuff that deserves a reaction. ... I know Len quite well and respect his opinion on all sorts of things, so at this point, I am going to discard diplomacy and say: Len, you are right out to lunch on this one. 1. Microsoft and VRML and XML First off, your attempt to draw a parallel to the VRML war stories is bogus. I was there too. In VRML, Microsoft ignored the process, did not even listen to the discussions, then dropped a violently incompatible, radically weird, technology from a great height, and was [deservedly] rejected. Len also conveniently ignores the fact that a small panel of self-appointed experts, the VRML architecture group, once the basic framework was selected, made essentially all the crucial detail decisions about what was in, what was out, and the technical details. Many members of the VAG never said a word on the public mailing lists. Microsoft has been on board, since day 1, and has subscribed to the basic design goals that we pretty much all share. I would also have been happier to see Jean outline some of his positions to the WG; but if you look at the brutal ERB meeting schedule, it becomes clear why only unemployed layabouts like myself and James Clark, and those who can type faster than 3 people can talk, such as Michael S-McQ and Eliot Kimber, can really afford to pitch in there and also carry lances in WG-land. The main role of the ERB was to listen to the WG, and to vote. We did those things. 2. Role and Transparency of the ERB I think that if we could have had a much larger-scale, slower, more collegial process, we would have had a better XML. But we would have had it in 1998, with luck. The ERB was the only way to make this happen in Internet time. Secondly, all the votes of the ERB are a matter of public record. You can certainly find some trends there (Bray voting for minimalism at all costs, Maler for SGML micro-consistency, Kimber for a larger subset, Sperberg-McQueen for a richer authoring environment) but you can *not* find evidence of any sleazy corporate machinations. Because there weren't any. Consider the makeup of the 11 voting members. 5 have no vendor affiliations (Bray, Clark, Kimber, Magliery, Sperberg-McQueen) 3 come from established SGML vendors (DeRose, Maler, Sharpe), 2 from big system vendors (whose SGML plans if any are opaque to me at least) (Bosak, Hollander), and Paoli from Microsoft. If you think that Jean, even if he had been pushing a diabolical corporate agenda, could buffalo this collection of obsessive-compulsives, pedantic purists, and get-it-done-now engineers... gimme a break. 3. On the nature of appropriate debate It is perfectly reasonable to disagree with the selection of predefined attributes (I do) and politico-technical design compromises (as Lee and Bob Streich do) and deviations from 8879 no matter how minor (as Charles does). It is not appropriate or useful, at this point, to start sliming the process because it producec some results you didn't like. This conspiracy soapbox is unworthy of you, Len, and has no basis in fact. Climb down. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Tue, 12 Nov 1996 10:20:34 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: XML draft v0.02 A new working draft of the XML spec is now available from ftp://sunsite.unc.edu/pub/standards/xml/spec/xml.rtf.zip ftp://sunsite.unc.edu/pub/standards/xml/spec/xml.ps.zip This draft is only going to exist for about 48 hours; a final version will be made available Thursday morning. It differs from the draft published last week chiefly in a reworked treatment of names and in the addition of discussions of entities and conditional sections. There is also now a table of all the predefined character entities in an appendix at the end. Yet to come are a treatment of ambiguous content models, some stylistic changes, and some organizational changes. Please check the list of WG member names at the back of the draft to make sure that I have your most recent organizational affiliation. Jon From: "Christopher R. Maden" Date: Tue, 12 Nov 1996 19:04:21 GMT To: w3c-sgml-wg@w3.org Subject: Re: XML draft v0.02 [Jon Bosak] > A new working draft of the XML spec is now available from > > ftp://sunsite.unc.edu/pub/standards/xml/spec/xml.rtf.zip > ftp://sunsite.unc.edu/pub/standards/xml/spec/xml.ps.zip Correction: ftp://sunsite.unc.edu/pub/sun-info/standards/xml/spec/* Also, http://sunsite.unc.edu/... works as well. -Chris Date: Tue, 12 Nov 1996 12:04:10 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Selling XML I have a consulting practice. When I'm not programming, I mostly go around explaining the differences between SGML and HTML and PDF and VRML and Shockwave and RTF and Java and yadda yadda yadda. Almost everyone I consult for is doing electronic publishing and is scrambling to get their stuff up via web technology, and at the same time, have some kind of a sane authoring and management environment. One of my primary pieces of advice is that you should never author HTML when you can generate it from something else, and *never* put it in a repository. I have always explained all the benefits of SGML (ISO, vendor-independent, platform-independent, content not presentation, you know the drill). When I do that, I almost always get the Sounds Good Maybe Later response: "SGML is this great big complicated technology and we're going to have to hire consultants and buy huge expensive pieces of software and it won't work with the Web." I sometimes feel that that the SGML community is unaware how prevalent this mind-set is. I've always argued against this, but have felt to some degree like I'm swimming up-hill. Lately, I have also been explaining that there is an SGML starter-kit called XML, which is small, lightweight (I wave a printout of the draft spec at them), easy to understand, and designed to work on the web. But you still get data safety and constrained-authoring because it's SGML. The next question is, "where can I buy the software?". It's the second easiest technology sale of my career (the easiest was the initial manic wave of blind-faith WWW adoptions based on a 3-minute Mosaic demo). So anyhow, assuming we come out of Boston with decent consensus and a couple of vendors start climbing on board, I think we're really onto something here. In preparation, I've started working on introductory material and a FAQ and so on, which may be previewed at: http://www.textuality.com/xml/ Feedback, and general thoughts as to how and where we should spin XML in the marketpace, are solicited. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 From: Paul Prescod Subject: Re: Recent ERB votes To: gtn@ebt.com (Gavin Nicol) Date: Tue, 12 Nov 1996 15:03:41 -0500 (EST) Cc: W3C-SGML-WG@w3.org > >But we already KNOW the cost of kluges. They are _expensive_. DynaWeb is > >_expensive_. DTD-specific converters are _expensive_. Panorama is expensive > >because most of your users will never download it, and your information will > >be lost. If these kluges were cheap, I would wait a few years for the > >network to speed up, and processors to speed up and would just put raw SGML > >on the Web. > > I wouldn't call any of these kludges... They are kludges in that they are short-term measures while we wait for the deployment of ubiquitous generic markup browsers with features more like those of SoftQuad's Explorer and EBT's DynaText - generic markup native, Web-native. I suspect that some form of smart SGML server will always exist, but it will not always serve such "dumb" clients. Paul Prescod Date: Tue, 12 Nov 1996 16:12:04 -0500 From: gtn@ebt.com (Gavin Nicol) To: bosak@atlantic-83.eng.sun.com CC: w3c-sgml-wg@w3.org Subject: Re: Decision: B.9 ( in SYSTEM identifiers) >B.9 XML will allow SYSTEM identifiers (which in XML 1.0 are required >to be URLs) to be prefixed by "". > >Decision: No. Dissenting: Maler, Kimber, Sperberg-McQueen, DeRose. Bad decision. At least we'd be able to build some test systems using FSI's if we allowed this... Date: Tue, 12 Nov 1996 16:28:28 -0500 From: gtn@ebt.com (Gavin Nicol) To: lee@sq.com CC: w3c-sgml-wg@w3.org Subject: Re: (Repeat) Decision: C.4 (Predefined entities) >Yes, but which recommendations? Sorry to be obtuse. I don't see how >the W3C can usefully make general recommendtions about entity sets in >all languages -- they're not available in C, for example! I'm not trying >to be awkward. It is really not clear to me that a recommendation that >the W3C makes about HTML (presumably) should automatically apply to XML. I'm still trying to catch up on my email, so I may be commenting out of line. It seems to me that having a predefined set of *required* entities (other than those needed for escaping markup) is a BAD idea. I have no problem with a *recommended* set of entites, or even a *required* set that all XML systems must understand. I cannot see why these need to be intriduced that the syntactical level. Also, with HTML compatability: I have no problem with recommended behaviour for HTML documents, but again, including it at the syntactical level is a bit ugly, to say the least. (Now I'll go off an get caught up, red the spec, and turn bright red after I find this has all be resolved...) Date: Tue, 12 Nov 1996 16:40:13 -0500 From: gtn@ebt.com (Gavin Nicol) To: ricko@allette.com.au CC: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: SPACE... >> I18nists, speak up now. Reduce them all or not? In favor: it's >> simple behavior, it is easily understood, and all white space is >> treated the same. Against: well, I don't know whether there is any >> argument against, that's what I am asking: *is* there an argument >> against? Is the distinction between SPACE, half-width space, >> en-space, em-space, double-width space, zenkaku space, etc., to be >> preserved in a way that the distinction between SPACE and TAB is not >> preserved? > >In markup, I think that if something looks like whitespace, >it should act like whitespace and be treated as >a SEPCHAR. I think Rick's statement is something we should all note. This is the right approach: clean and obvious. Date: Tue, 12 Nov 1996 15:20:42 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Re: XML draft v0.02 Oops. As someone has already pointed out, the v0.02 XML draft is actually at ftp://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml.rtf.zip ftp://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml.ps.zip If you poke around under the spec directory, you will also find gzipped versions if you need them. Jon From: "Christopher R. Maden" Date: Tue, 12 Nov 1996 23:31:08 GMT To: w3c-sgml-wg@w3.org Subject: Read the draft carefully! Everyone receiving this message, PLEASE read the spec carefully ASAP. I'm finding numerous oversights in the EBNF, and apparently unintentional incompatibilities with 8879. I don't fault the authors; it's easy to overlook syntactic errors in your own work, especially when working so quickly. But I don't feel at all confident that I can catch all of the errors, so help would be appreciated. I saw no extensive critiques other than mine on the previous draft, and don't want that to happen again. No undefined terminals so far, though - congrats. I'll post a summary of what I've got before I leave work tonight. -Chris -- http://www.ebt.com +1.401.421.9550 +1.401.521.2030 One Richmond Square, Providence, RI 02906 USA" NDATA SGML.Geek> From: "Christopher R. Maden" Date: Wed, 13 Nov 1996 00:06:41 GMT To: w3c-sgml-wg@w3.org Subject: Comments: through clause 3 Here's what I've found so far. Nearly all of this is different from comments sent last night; what's not is explicitly marked "Carried >from 0.01." I'd appreciate some reaction, even if it's "that was too long to bother reading". I feel my last comments went into a void. As noted previously, all productions checked thus far (through [60]) have no undefined references. Comments updated for 0.02 of 10 November, PostScript from SunSite. Clause 1.2, reference 2: ISO 10646 Isn't it ISO/IEC 10646? I can't remember. Clause 1.3, first example: symbol ::= expression All the productions use ':=', not '::='. Clause 1.5, production [1]: [1] S := (#x0020 | #x000a | #x000d | #x0009)+ This, as has been pointed out, does not allow non-Latin spaces. I don't mind the omission of typographic spaces, but CJK spaces (e.g., zenkaku) should be included. At a minimum, this needs inclusion in the known limitations of the draft until it's been fixed from the Unicode tables. Clause 1.5, production [8]: [8] Ignorable := ... I think the choice of the word "Ignorable" is unfortunate; although not the case, it *implies* that these characters should be ignored in content, as well. I don't really have a better suggestion; maybe "WSChars" for Writing System Characters? Clause 1.5, paragraph post-production [9]: ... a string which matches "-XML-" in a fashion... When did the ERB decision announced as "1. Reservation of name space" change from .XML. to -XML-? Not that it matters, really. Clause 2.2, first paragraph: A character is A character is an atomic... Carried from 0.01. Typo. Clause 2.3, production [22]: | '' /* doc type declaration */ Carried from 0.01. The beginning of the production component allows a jumble, and the end does not allow space between DSC and MDC. If the purpose is to simply allow recognition and skipping of the doctype declaration, then ']* ('[' [^]]* ']' S?)? '>' should suffice; if more restrictive syntax is warranted, then something like the doctypedecl production (in 2.8) should be invoked. Clause 2.3, last paragraph: The right angle bracket (>) may be represented using the string ">", and must be so represented when it appears in the string "]]>", to avoid confusion with the marker for the end of a marked section. It must be made explicit here that this does NOT work in a marked section. For SGML reasons, recognition of ]]> as a delimiter outside a marked section is a problem, but this is not clear to non--SGML- users. The only reason, in their minds, to escape ">" will be to prevent the end of the marked section - but entities won't be recognized there. A note should also be made that if the sequence "]]>" is needed in a literal section, escaping of "<" and "&" by entity references will work, but that a marked section will not. Clause 2.4, first paragraph: Comments may appear anywhere that character data may, except in a marked section (more properly, comments appearing in a marked section will not be recognized as such). Carried from 0.01. Comments may appear in element content and in the prolog, as well, no? In other words, "Comments may appear anywhere, except in a marked section; i.e., within element content, in mixed content, or in a document type declaration subset (see doctypedecl)." Clause 2.6, and in general: Carried from 0.01. Wherever using a term important to ISO 8879 in a different manner from 8879, the term 8879 uses for the concept should be given for reference. In this case, the term "marked section" in XML refers to what 8879 calls "CDATA marked section". This should be made clear in a note; as 8879 is referenced, some non-trivial portion of implementers will make reference to it, and different terminology may confuse them. Clause 2.7: Critique revised from 0.01. I think that specifying two whitespace modes for the processor is a mistake. It complicates parsing, with little gain. Decisions about whitespace handling will need to be made by a renderer anyway (e.g., to strip leading and trailing space from each line in a preformatted block), and an indexer will ignore all of it. IOW, the application is saved nothing, and the processor is complicated. Preserve all namespace, period. Barring this, make the -XML-SPACE attribute value default to PRESERVE. Clause 2.7, example: Critique revised from 0.01. Is this line to be included verbatim in all DTDs? Is it a model that must be added to the ATTLIST declaration for every element? The discussion is not clear. (Either case - the necessity for an extra attribute on every element, or a bizarre deviation from ATTLIST syntax - highlights the weirdness of this DTD-specified whitespace handling scheme.) Clause 2.8, production [31]: [31] Prolog := EncodingDecl? ... Production [72] is defined as Encodingdecl, not EncodingDecl. Clause 2.8, productions [33] and [34]: Carried from 0.01. The placement of the production group breaks up the flow of text; the paragraph after refers to "these two subsets", and I was very confused as to *which* two until I realized that they had been referenced in the paragraph prior to the production group. Move the group down a paragraph, just before the example, maybe. Clause 2.8, production [33] (and [70]): [33] doctypedecl := '' ... [70] ExternalID := 'SYSTEM' Literal This mandates the form Spaces (_ps_) are required by ISO 8879 [110] between _document type name_, _external identifier_, and _document type declaration subset_. I would recommend changes thusly: [33] doctypedecl := '' [70] ExternalID := 'SYSTEM' S Literal Clause 2.8, last example: I believe that introduction of the encoding PI at this point is premature, and will cause confusion. Discussion of encoding PIs should be restricted to a discussion within their own section. Clause 2.9, third paragraph: 1. attributes with default values, and elements to which these attributes apply appear in the document, or Carried from 0.01. I think a more applicable phrasing is, "attributes with default values, and elements to which these attributes apply *and are not explicitly set* appear in the document..." though this may be too complex to easily check. Clause 2.9, last paragraph: If no RMD is provided, the effect is identical to an RMD with the value ALL. I feel that NONE should be the default. The simplest XML document should not require the RMD at all. Clause 3.1, second text paragraph: The Name in the start- and end-tag rules gives the element's type. Carried from 0.01. Strike "rules", or reword this. "The Name referred to in the ..." or "The Name in the ... -tags gives...". Ibid: ... and the content of the QuotedCData (the characters between the "'" or '"' delimiters) as the attribute value. Carried from 0.01 (but additional comment below). Everyone here is aware that this is the attribute value specification, but we use the terms interchangeably. We must NOT do this in the XML spec; it caused endless headaches when Netscape started to handle entity refs in attribute value *specifications*. The discussions about when to use & and when to use %24 in
went for far too long on www-html, html-wg, and lynx-dev. Care must be taken in XML to use the correct terms "attribute value specification" and "attribute value" as appropriate. Even though entity references are not allowed in AVSs in XML 1.0, lack of confusion now will make going forward easier. In addition, don't quote the quotes - this looks *really* confusing, at least on paper. It looks like "between the ''''' or '''' delimiters". Clause 3.1, post-production [39] paragraph: The special casing of HTML must be eliminated from the specification. It will *not* be implemented by most implementors, because they have separate tools for handling HTML. Therefore, most XML implementations will be non-compliant, and this specification becomes moot anyway. Clause 3.1, production group 17: content := (element | PCDATA | MS | PI | Comment)* Carried from 0.01. There should be [ VC: Content model ] after that; i.e., the content of an element will match the content model in the DTD if the document is valid. Clause 3.2, first paragraph: A textual object is said to be a well-formed... if... it matches the production above labeled XML Document,... Give a production number when they've settled. Clause 3.2, second list item: More simply stated, the elements, delineated by start- and end-tags, nest within each other properly. Carried from 0.01. Either strike "properly" or define it. Nesting makes sense, I think, to the target non-SGML-aware audience; adding "properly" implies that there's something special that's not being said. Clause 3.3.2, production [44] and discussion: [44] elements := cp This allows violations of 8879 productions [116], [126], and [127], which dictate that any element declaration other than ANY or EMPTY (for XML's purposes) require grpo and grpc around the content model. I recommend: [44] elements := (choice | seq) ('?' | '*' | '+')? Changing cp (my first thought) isn't good because it's fine to have a naked Name in a choice or seq construct, just not as the main content model. Clause 3.4, productions [49] and [50]: [49] AttlistDecl := '' [50] AttDef := S Name S AttType S Default This is accurate, but I think a cleaner production would be: [49] AttlistDecl := '' [50] AttDef := Name S AttType S Default It better reflects the syntactic components, IMO. Clause 3.4.1, Validity checks: ID and Idref do not mention normalization of case; Name token and Name tokens do. This is inconsistent with both NAMECASE GENERAL YES and NAMECASE GENERAL NO. It should be consistent. I am opposed to case folding; I think it will be far easier to add it in XML 2.0 if a workable method is found (which I doubt will happen). The current method (assuming case folding was intended for ID and Idref) will produce a different parse in France and in Canada for a French-language document. This small XML document: ]> is valid if parsed in Canada, but invalid if parsed in France. That is a Bad Thing. (Should we add an XML PI to indicate intended parsing locale? d-:) In addition, Name tokens mentions white space reduction; Idref and Entity Name do not for their plural forms. Name tokens does not mention stripping of leading and trailing space; should it? Clause 3.5 in 0.01/W3C (now missing): Carried from 0.01. The DTD summary is no longer needed for empty elements, and is moot for mixed vs. element content distinction, but would be a VERY useful way to override the defaulted entities without requiring DTD parsing. The receiving non-DTD-speaking application could say, "This ∏ here does something other than a big ol' pi, but I don't know what...". -Chris -- http://www.ebt.com +1.401.421.9550 +1.401.521.2030 One Richmond Square, Providence, RI 02906 USA" NDATA SGML.Geek> Date: Tue, 12 Nov 1996 16:44:14 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: Read the draft carefully! At 11:31 PM 11/12/96 GMT, Christopher R. Maden wrote: >Everyone receiving this message, PLEASE read the spec carefully ASAP. To which I say: hear hear! We have made this request several times; as Chris points out, this was prepared in an amount of time that (if you're not thinking in Internet terms) is just insanely small, and it guaranteed to have some typos and thinkos. Every one of you can have a substantial positive influence on this baby just by pitching in and giving it a sharp-eyed once-over. Thanks to Chris. -T. Date: Tue, 12 Nov 1996 20:24:53 -0500 To: "Christopher R. Maden" , w3c-sgml-wg@w3.org From: "Eve L. Maler" Subject: Re: Comments: through clause 3 I'm not one of the editors, but I wanted to reassure you that Tim and Michael are hearing from others on lots of the same topics. (I've just sent volume 6 (!) of my spec comments to the ERB, and many of them duplicate yours.) I know they're taking all comments seriously, but at this point it may be hard for them at this point to both crank out the next spec version in time, *and* respond to individual comments... Eve At 12:06 AM 11/13/96 GMT, Christopher R. Maden wrote: >Here's what I've found so far. Nearly all of this is different from >comments sent last night; what's not is explicitly marked "Carried >from 0.01." I'd appreciate some reaction, even if it's "that was too >long to bother reading". I feel my last comments went into a void. From: lee@sq.com Date: Tue, 12 Nov 96 22:26:15 EST To: crm@ebt.com, w3c-sgml-wg@w3.org Subject: Re: Comments: through clause 3 Just a few comments on Cris' comments (but I have not been able to read the new draft yet, sorry) > When did the ERB decision announced as "1. Reservation of name space" > change from .XML. to -XML-? Not that it matters, really. some time ago, since the current draft "CSS1" style system can't cope with dots in element types. I am not sure why this is relevant to XML, though, or, if it is, why it can't be fixed in CSS1, which is also a W3C thing. > Clause 2.7: > > Critique revised from 0.01. I think that specifying two whitespace > modes for the processor is a mistake. I agree; it was done for the sake of SGML compatibility (which turned out to be lost by it) and because some people thought that they could change all EMPTY elements in their documents but not escape whitespace. I.e. for no good reason. I agree that it is a mistake, but it pales into insignificance besides other more recent mistakes, and isn't worth fighting for. My hope is that enough is learnt from XML that the SGML revision can be useful to use instead of XML. > Clause 2.7, example: > > > Critique revised from 0.01. Is this line to be included verbatim in > all DTDs? I think the idea was that you could add -XML-SPACE-"PRESERVE" whenever you wanted the non-default behaviour, DTDs notwithstanding. I'm not sure. Certainly the syntax as given isn't legal SGML. I'm not sure if it's legal XML -- I can't read PostScript documents from here right now. > [31] Prolog := EncodingDecl? ... > > Production [72] is defined as Encodingdecl, not EncodingDecl. Note also that mandating that a system detect when a document is not using the encoding and/or character set specified is not in general technically possible. You can't distinguish ISO 8859-1 and ISO 8859-7 without some fairly complex AI algorithms, for example. The wording needs to be changed to say that the behaviour in that case is undefined. > Clause 2.8, production [33] (and [70]): > [33] doctypedecl := ' internalsubset* ']' S?)? '>' > ... > [70] ExternalID := 'SYSTEM' Literal > > This mandates the form > True (there are some other cases of missing S I think, or were in the previous draft). The right fix (I think) woud be to get rid of S altogether and explain exactly which delimiters separate tokens. See the PostScript language specification for a clear example -- or see C for another one. It is harder to ensure full SGML compatibility if you do this, but I really do believe it's worth the effort. For one thing, it encourages simple token-stream implementations.. :-) Note also that this production makes the HTML DOCTYPE illegal in XML, since HTML requires a PUBLIC identifier, so that there is no document valid in both XML and HTML. (see RFC 1866; I believe HTML 3.2 to be the same in this regard, excvept with a different PI) > Clause 2.9, last paragraph: > If no RMD is provided, the effect is identical to an RMD with the > value ALL. > > I feel that NONE should be the default. The simplest XML document > should not require the RMD at all. I assumed that was an error in the specification! A third value, -XML-IF-DTD-WAS-GIVEN, might be a better default. > Clause 3.1, post-production [39] paragraph: > > The special casing of HTML must be eliminated from the specification. > It will *not* be implemented by most implementors, because they have > separate tools for handling HTML. Therefore, most XML implementations > will be non-compliant, and this specification becomes moot anyway. I fully agree, but it has been the source of bitter argument recently. Since no XML document is a valid HTML document, and vice versa, it is all in any case totally redundant. > Clause 3.4.1, Validity checks: > > ID and Idref do not mention normalization of case; Name token and Name > tokens do. This is inconsistent with both NAMECASE GENERAL YES and > NAMECASE GENERAL NO. It should be consistent. > > I am opposed to case folding; I think it will be far easier to add it > in XML 2.0 if a workable method is found (which I doubt will happen). I agree. [...] > > > > > > is valid if parsed in Canada, but invalid if parsed in France. That > is a Bad Thing. (Should we add an XML PI to indicate intended parsing > locale? d-:) In SGML it may or may not be valid depending on the SGML declaration,. If you add and you have a cross reference which points to a different element in Quebec and in France! This is obviously a potential source of errors, especially given the almost complete internationalisation otherwise. > Clause 3.5 in 0.01/W3C (now missing): > > Carried from 0.01. The DTD summary is no longer needed for empty > elements, and is moot for mixed vs. element content distinction, but > would be a VERY useful way to override the defaulted entities without > requiring DTD parsing. You can't override the default entities (believe it or not -- it's a design bug). Apart from that nonsense, it would be better to allow entity declarations in a document type subset, perhaps? Lee From: "Christopher R. Maden" Date: Wed, 13 Nov 1996 03:57:38 GMT To: w3c-sgml-wg@w3.org Subject: Re: Comments: through clause 3 [Lee Quin] > [Chris Maden] > > Clause 3.5 in 0.01/W3C (now missing): > > > > Carried from 0.01. The DTD summary is no longer needed for empty > > elements, and is moot for mixed vs. element content distinction, > > but would be a VERY useful way to override the defaulted entities > > without requiring DTD parsing. > > You can't override the default entities (believe it or not -- it's a > design bug). Apart from that nonsense, it would be better to allow > entity declarations in a document type subset, perhaps? The only reason I could see for not allowing the entity overrides is that it requires DTD parsing, and so a DTDless parse would come up different from a DTD parse, and that's bad. But if there's a way to tell DTDless systems which entities have been overridden, even without the actual definitions, then it's not such a problem. -Chris -- http://www.ebt.com +1.401.421.9550 +1.401.521.2030 One Richmond Square, Providence, RI 02906 USA" NDATA SGML.Geek> Date: Tue, 12 Nov 1996 23:19:00 -0500 To: w3c-sgml-wg@w3.org From: Arjun Ray Subject: Please listen, Microsoft (was: Comments: through clause 3) At 10:26 PM 11/12/96 EST, lee@sq.com wrote: > >> When did the ERB decision announced as "1. Reservation of name space" >> change from .XML. to -XML-? Not that it matters, really. > >some time ago, since the current draft "CSS1" style system can't cope with >dots in element types. I am not sure why this is relevant to XML, though, >or, if it is, why it can't be fixed in CSS1, which is also a W3C thing. It *needs* to be fixed in CSS1. Using '.' to separate GIs in a hierarchic context specification, as in X.Y.Z { foo: bar } clashes with the fact that '.' is a name character. CSS1 should use something like '/' instead. But will this be fixed? Nobody ever fixed the problem of CGI '&'s in attribute value literals. Arjun From: "Christopher R. Maden" Date: Wed, 13 Nov 1996 04:15:32 GMT To: w3c-sgml-wg@w3.org Subject: Comments: clause 4+ Comments updated for 0.02 of 10 November, PostScript from SunSite. Clause 4.1, productions [64]-[66] There's a mysterious 'PEReference' floating in the middle of the production group. Is Reference supposed to include '| PEReference'? It doesn't appear to be referenced anywhere else. Clause 4.1, No Recursion WFC: A text entity may not contain a reference to itself. How many levels must an XML processor check for circular references to be compliant with this specification? One? It should be explicit. Clause 4.2, production [67]: [67] EntityDecl := '' This doesn't allow space between the name and the definition. Try: [67] EntityDecl := '' Clause 4.2.2, production [69]: [69] ExternalDef := ExternalID NDataDecl? Same problem; try [69] ExternalDef := ExternalID (S NDataDecl)? Clause 4.2.2, production [71]: [71] NDataDecl := 'NDATA' S Name S The second S is redundant and not required. Strike it. Clause 4.2.3, first paragraph: It is recognized that for for some advanced work, particularly with Asian languages,... a) There is a duplicate "for". b) I don't think Asian-language speakers consider it advanced. At a minimum, replace "advanced" with "non-European". (And call me a P.C. Brown grad.) Clause 4.2.3, production [74]: [74] Encoding := ... Revised from 0.01. Are the members of the enumerated list the only encodings permitted in XML 1.0, at all? What about other IANA-registered encodings, if the system can handle them? What about X-prefixed ones that are spoken by the system? EBCDIC isn't even mentioned here. It's not at all dead (is the Brown STG still using BrownVM?). Big5 (Chinese) and KOR-8 (Russian) are in use on the Web for HTML now. Clause 4.2.3, last paragraph: 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 binary entity, or that processing should cease. a) s/an binary entity/a binary entity/ b) I believe the application should also be permitted to cancel processing just of that entity, and carry on. If that is what is intended by the second option above, it needs to be better worded. Clause 4.3, list item 1: ... for a character reference, the "&..." string.) Which string? That should be more explicit: 'the "&...;" string.' Clause 4.4, production [75] and discussion: I feel that *requiring* ExternalID for NotationDecl is unnecessary. What is the system identifier for processing a text file, in a cross- platform way? I think this hurts XML's network friendliness. I would prefer to see MIME types recommended as system identifiers, as the HyTime Technical Corrigendum allows in FSIs. Appendix A, feature list: 3. The "&" connector in content models Revised from 0.01. Make that 'The "and" connector (&)'. Appendix B: References. 8879 isn't ISO/IEC, just ISO. I don't know about 10646 or 10744. Appendix D: There appears to have been a one-to-one mapping made from Symbol font characters to entity names. There is actually a one-to-many for some. The ones I caught are the Greek letters. I'm at home, so please pardon if I get the entity sets backwards, but: "Gamma", "Delta", etc., are from iso-grk1, and refer to the mathematical symbols capital gamma, capital delta, etc. "Ggr", "Dgr", etc., are from iso-grk3, and refer to the Greek capital letter G, the Greek capital letter D, etc. Both should be accepted by XML; whether they should reference the same Unicode character, I'm not sure. (Does anyone know if Unicode distinguishs the two type of characters?) In any case, they would end up as the same Symbol glyph, most likely. At a minimum, though, XML should pick one or the other, if not allowing both; the current chart mizes and matches (Agr, Bgr, Gamma, Delta, Egr,...) I think I see a pattern - iso-grk1 doesn't cover the whole alphabet, and iso-grk3 was used to fill in the holes. Never mind that - both entity sets should be fully supported. Extra comment #1: Carried from 0.01. XML desparately needs versioning information. Otherwise, XML 2.0 will struggle painfully with how to make itself not cripple XML 1.0 systems. At a minimum, XML 1.0 can have an absence of versioning information if it knows how to recognize a newer version. I would prefer that an explicit mechanism be provided now, but with a default of 1.0 in its absence. A required element has been rejected; perhaps a PI, then: . Extra comment #2: Has anyone registered text/xml and application/xml with IANA? It would be cool if it were done by next Wednesday. -Chris -- http://www.ebt.com +1.401.421.9550 +1.401.521.2030 One Richmond Square, Providence, RI 02906 USA" NDATA SGML.Geek> From: lee@sq.com Date: Tue, 12 Nov 96 23:44:14 EST To: w3c-sgml-wg@w3.org Subject: overriding... &Chris; wrote: The only reason I could see for not allowing the entity overrides is that it requires DTD parsing This is true for any entities at all except the default ones. So this would be an argument for not allowing entities other than those in a defult set. Also, note that entities can be declared in the subset even if nothing else is -- e.g. ]> Lee -- Liam Quin, lee@sq.com | lq-text freely available Unix text retrieval Senior Technical Consultant | FAQs: Metafont fonts, OPEN LOOK UI, OpenWindows SoftQuad Inc. +1 416 544-9000 | xfonttool (Unix xfontsel in XView) http://www.softquad.com/ | The barefoot typographer From: lee@sq.com Date: Tue, 12 Nov 96 23:51:11 EST To: w3c-sgml-wg@w3.org Subject: PIC Would /> be better than ?>? I keep reading as meaning that that the value is in doubt! But would match the EMPTY tag close delimiter, which would add some symmetry without hurting anything, I think. It would also help understanind, in that is self-contained, just like . I suppose one could argue that should have a similar property, should have a similar property, > From: lee@sq.com Date: Wed, 13 Nov 96 22:09:55 EST To: W3C-SGML-WG@w3.org, karben@interactive.wsj.com Subject: Re: ICADD support in XML [Was: SGML declaration for XML] Cc: paciello@yuri.org > At 03:37 PM 11/11/96 -0500, Steven J. DeRose wrote: > >Insisting that vendors implement LINK in order to support ICADD is the > >surest way to be sure no one implements ICADD, which I think would be a > tragedy. > Alan Karben wrote: > I'm still ramping up on these issues, but I would venture that XML offers a > much better solution than the current ICADD for those who need ICADD's > benefits. You might well be right. One discussion was about the use of LINK for adding ICADD SDA forms to the HTML 3.2 DTD. I am still not convinced that this is a good idea. As far as I know, none of the major HTML browsers today will cope very well with an SGML declaration in a document, let alone a link process definition. Presumably would become legal within an HTML document. Introducing LINK into HTML could have interesting implications for CSS1 and also for anchors -- it gives you a way of doing something very like a HyTime ILINK (but restricted to pointing to entire elements). But given that HTML applications today don't (in generl) even support document-specific entities, it would seem to me better not to extend HTML in this way, but to use existing technology. If you want to have the ICADD attributes in a separate file, assume that the SGML 97 rule has passed to allow so that you can put all the #FIXED attributes (and maybe others) in a separate file and include it from the base DTD. Alan's comment: > Doesn't the world of style sheets offer a far greater avenue for opening > access than hiding hints inside a DTD? Instead of just prefixes and > suffixes, a content provider could call for much more useful > annotations/transformations/inflection-changes. Is a good one. LINK was an early (and I think unsuccessful) attempt to provide a general transformation model for SGML. This has since been done in DSSSL. It would be better to supply a DSSSL transformation than a LINK process definition set file, I think. It is unlikely that existing vendors will start to support LINK. It is very likely that they will support DSSSL. On the other hand, as far as I can tell from reading 8879, an SGML application can ignore LINK if it wants to. The information is a hint to the parser, no more. I don't have a formal definition of ESIS in front of me, so don't know if ESIS is required to be changed by LINK. So maybe HTML software could conform if it ignored the LPD. But I am not sure if that helps anyone. Since the issues are political and not technical, I don't think I can comment further. Lee Date: Thu, 14 Nov 1996 06:09:22 -0600 To: Paul Prescod , W3C-SGML-WG@w3.org From: "W. Eliot Kimber" Subject: Re: Rhetoric and Psychology At 02:06 PM 11/13/96 -0500, Paul Prescod wrote: >I don't mean to pick on Lee, but I've just snapped. I'll address his >conspiracy theories first, and then the larger issue of the degenerating >tone of the discussions. Paul, Thanks for the reality check. Everything you say is true. No standard created by and for more than one person can ever be perfect. XML bit off a particularly difficult chunk to chew, namely to produce a simple specification to solve a hard problem in a nearly impossible political situation. The fact that we have even been able to produce a reasonable draft without anybody A) leaving the ERB or B) any friendships being lost (as far as I know) is, I think, a major miracle. The ERB certainly listens to the WG and has reconsidered a number of key issues when the response from the WG made it clear we needed to. We have gone to pains to explain our rationales for design decisions. We have had to make number of very difficult decisions and for each member of the ERB there is at least one such decision that they think was the worst possible choice to make. It's been an exercise in compromise, done with a huge amount of genuine concern for the constituencies affected and very little grandstanding or brinksmanship. At the end of the day what matters is whether or not we've produced something that is both *useful* and *not politically destructive*. XML, for a number of reasons, is inherently *very dangerous* in a number of ways to a number of different interested parties. I think we have done things in a way that minimize the danger (at least for some, such as those that depend on vendor-independent standards to protect their investement in long-term information bases). I don't think it's meaningful to talk about XML "failing". Either it meets the requirements it claims to meet or it doesn't. If it does, people will probably use it, because people need something like it. If it mostly does, people will still probably use it because they know it can be fixed. Even if nobody ever uses it (which seems highly unlikely), it will still have been a success if for no other reason than it both spurred the SGML RG into action and provided a huge amount of very useful input in terms of requirements and design. Cheers, E. -- W. Eliot Kimber (drmacro@drmacro.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Thu, 14 Nov 96 15:55:55 CST From: Michael Sperberg-McQueen Subject: ERB discussions and decisions To: W3C SGML Working Group The ERB met yesterday, 13 November 1996, to discuss the XML working draft and approve the distribution of the current text at SGML '96 next week. We considered a number of topics arising from the draft, some of which have already been discussed, or are still being discussed, on this list, and other of which have not received much discussion. Present: Bosak, Bray (intermittently), Clark, DeRose, Kimber, Maler, Magliery, Paoli, Sharpe, and Sperberg-McQueen. Absent: Hollander. The author's apologies to busy members of the WG who would prefer a shorter account of the decisions; recent claims on the WG list that the ERB does not explain or discuss its decisions with the rest of the WG have led me, perhaps mischievously, to provide as full a discussion and explanation as my fingers can handle. There's an executive summary at the end. Given the number of major topics on which the WG appears not to have reached consensus and the volume of comment lately, it seems safe to say that some issues will require ongoing consideration and discussion, and the text of the working draft which we can distribute next week will be subject to change in non-trivial ways before we can leave this phase of the project's work behind. We considered dropping the plan to distribute printed copies at SGML '96, in order not to give a false impression of completeness. On the whole, however, the ERB thought that having printed copies available would be worthwhile, and we decided to go ahead with the plan. The cover page will, like the current Web copies, identify the document as a Working Draft, so the fact that it's not completely stable should be visible to any reader. And as the experience of the ERB and WG shows, having something that appears completed is one of the best ways to get people to read a draft and comment on it. Since Henry Thompson raised the question directly: no, it's not too late for comments on substantive issues. The document is a Working Draft, and when the ERB stops work on it and moves to the next phase, it will still be a Working Draft until the W3C advances it to Draft Recommendation status, using the normal W3C procedures. There is some sentiment for avoiding the kind of violent swings in philosophy and technical direction that characterize some working drafts in some organizations, but in principle and in practice, working drafts are subject to change, and discussion about what changes to make is always appropriate unless the rules of the WG make it out of order (e.g. while we focus on some specific issue). In the meantime, it is too late for typographic corrections to be included in the version distributed at SGML '96. * Jon Bosak suggested we reconsider the decision to include all the Cougar entities as predefined entities in XML; examining the list with more care while preparing it for inclusion in the spec, he had noticed a number of inconsistencies and infelicities -- especially the fact that the entity names for some Greek characters are taken >from the ISOgrk1 set and others from the ISOgrk3 set. In discussion with Jon, Anders Berglund had also pointed out some other problems with the entity set. In view of the negative reaction from some members of the WG, it also appeared to some ERB members that the inclusion of these entities, intended as a convenience for users, would strike some users as the reverse. Agreed (Paoli abstaining) to remove the Cougar entities from the spec. * Agreed to keep the five entities lt, gt, amp, quot, and apos, for use in escaping markup delimiters, and to retain their current status as non-redeclarable. Rationale: we agreed long ago that entity reference was the preferred method of escaping markup characters, and it's clearly better if tools generating XML can rely on the standard entity names. To the lasting disappointment of the humorists among us, the name squot was dropped in favor of apos, which occurs in 8879 Annex D, set ISOnum, as do the others. * Discussed, once more, question C.10 (allow or prohibit non-deterministic content models). In a recent meeting, there had been wide support for reconsidering the decision (reported 6 November) to prohibit such models, for the sake of compatibility (thus ensuring that SGML-based processors can handle all XML documents). In particular, it was pointed out that many existing SGML systems have no trouble at all with non-deterministic models, and argued that the restriction to determinism is poorly motivated, since it does not in fact provide serious benefits to implementors (this is a disputed point) and (pace Charles Goldfarb) has at best a neutral effect on legibility of content models by end users. It was generally thought that the spec would be cleaner without the restriction. In this meeting, this discussion was continued. Some ERB members not present at the earlier discussion argued against lifting the prohibition, on the grounds that (a) WG 8 has not agreed to change this rule in the revision of SGML, and there is no reason to think such a change likely, (b) there are some widely used SGML systems (more than one or two) which rely crucially on determinism in the content model, and (c) some nondeterministic content models have no deterministic equivalent, so the idea of providing an algorithm for making all content models deterministic is not feasible. Determinism is not particularly important to XML, but in Full SGML, the AND connector and the definition of start-tag omission interact with it and make it far more important. A minority asked what AND has to do with it, and suggested that all cases of start-tag omission allowed by the current rules would also be possible with nondeterministic rules, as experimentation with any LALR(1) parser generator should show. We never did clarify how AND makes determinism more important, and on the other hand we never did hear anything like a proof that LR(1) parsing could handle all cases of start-tag omission, let alone -- the really hard part -- an argument showing that LALR(1) parsing can be documented suitably in ISO-type language. A digression into practical linguistics and stylistic criticism loomed, full of anecdotes about standard-speak, but was luckily averted. Decision: retain the prohibition. This was not unanimous, but my notes don't record the vote, so I don't recall who besides Tim Bray was in dissent. * We reconsidered also the decision on question C.14 (reported 6 Nov) to drop SGML's prohibition on overlapping sets of name tokens in enumerated attribute types. The SGML revision group is on record as favoring this change, it seems to be agreed that there is no technical reason for the prohibition, and dropping it gives users a much improved tool. The discussion in the WG, however, seems to suggest that some portions of the community will be extremely, perhaps excessively, alarmed if XML anticipates the SGML revision in this regard. We considered standing by the decision reported on 6 November (clean this area up), reversing it (follow ISO 8879:1986, even though on this point the rule is uniformly thought to be a design error), and drop enumerated data types for attributes, and place them on the list of constructs to be added in a later revision. There was almost no support for dropping enumerated types: they are extremely useful both for validation and for documenting the expected range of values, and they make it possible for authoring systems to provide much better support for attribute value specification. The other two possibilities were very closely matched, but after long discussion the majority view came to be that the symbolic importance of guaranteeing that all valid XML documents are valid SGML documents outweighed the technical arguments. The SGML community has over time become accustomed, or at least resigned, to this rule; those members of the HTML community who care at all about standardization and DTDs are at least aware of this restriction already, so that its inclusion in XML will not come as a total shock to them. The base political observation that they'll blame WG8, not us, may have occurred to some minds besides my own, but it was not spoken. It may not be true, in any case. Reversed the decision announced 6 Nov: XML 1.0 now prohibits overlap among enumerated attribute types declared in the same attribute-list declaration. Dissenting: Bray, Hollander, Magliery. * We also reconsidered, for the second time, our decision on the form of EMPTY elements. Initially, we had agreed (deciding question B.10 on 30 October) to allow both the form and the form , restricting the latter to cases where the element was explicitly declared EMPTY but allowing whether a declaration was present or not. This was felt unsatisfactory by some members of the WG and ERB because it requires all parsers to read and parse the DTD, even if all they want is to detect element boundaries correctly in a single entity. It also leads to some unhappy choices between requiring parsers to fetch external DTD entities *before even starting to parse the document* or requiring users to include all declarations of EMPTY elements in the internal subset, which could create maintenance headaches of epic proportions. As a result, we revisited the question in early November (in the course of discussing question D.2, reported 6 November) and sought ways to allow the form without effectively requiring all XML processors to read all of the DTD, all of the time, before parsing. As reported on 6 November, we agreed to restrict the use of the form to a set list of known EMPTY elements, in order to allow users to create, if need be, documents which are simultaneously processable HTML and valid XML. There was some concern about singling out a single DTD for special treatment, but the importance of HTML on the Web (in the context of Documents on the Web, *are* there other DTDs?) and the fact that SGML users already have the same ability we were trying to give HTML users (i.e. the ability to create valid XML documents processable with their existing systems) outweighed those concerns. The ad hoc nature of the decision, however, continued to bother several people (as well as several members of the WG), so we took it up again. Paul Prescod suggested on 8 November that HTML's EMPTY elements could be handled by defining them (in an XML-friendly version of the HTML DTD) as empty but not EMPTY, allowing XML-aware users to write

, etc., which (a) is legal XML and (b) can be processed by existing HTML browsers. Some ERB members felt some misgivings about tagging EMPTY elements this way, but (a) it works, (b) it can't be all that bad, since it has been repeatedly suggested as an enhancement for SGML itself, (c) it works, (d) it's much less bad than the hard-coded list of elements, and (e) it works. Agreed (Bray and Sharpe dissenting) to replace the paragraph requiring XML processors to handle -style tags for HTML 3.2's EMPTY elements, if they detected that they were handling HTML, and replace it with a paragraph explaining the Prescod technique of making valid XML documents which can work with HTML browsers not fitted out with handling. * Agreed (by general assent) to add a required version declaration in the form of an XML PI at the beginning of the document. The version information to be required, the character-set information optional. In the ensuing editorial work, the version, charset, and RMD information were all merged into a single 'XML declaration'. * Agreed (by general assent) to allow processing instructions in the DTD. (This may have been decided already, but it wasn't in the grammar and we voted rather than look it up. The deadline was looming pretty high at this point.) Other items remaining undiscussed and undecided were implicitly declared editorial questions for purposes of getting copy to the printer in time for SGML '96 distribution. The editors resisted the temptation to seize this opportunity to restore the DSD syntax for markup declarations. The spec has now gone to the printer; the editors would like to thank those members of the WG who sent us corrections and pointed out errors. It'll be a materially more complete, correct, and less confusing document thanks to your efforts. - C. M. Sperberg-McQueen Summary: * Removed (Paoli abstaining) the Cougar entities from XML 1.0. * Retained lt, gt, amp, quot, apos as non-redeclarable entities. * Retained ban on nondeterministic content models. * Prohibited (Bray, Hollander, Magliery dissenting) overlap among enumerated types in XML 1.0. * Dropped special handling of HTML EMPTY elements, added paragraph explaining Prescod method of making HTML valid XML (Bray, Sharpe dissenting). * Added version declaration. * Allowed processing instructions in DTD. Date: Thu, 14 Nov 1996 20:04:55 -0500 To: W3C SGML Working Group From: Paul Prescod Subject: Re: ERB discussions and decisions At 03:55 PM 11/14/96 CST, Michael Sperberg-McQueen wrote: >The author's apologies to busy members of the WG who would prefer a >shorter account of the decisions; recent claims on the WG list that >the ERB does not explain or discuss its decisions with the rest of >the WG have led me, perhaps mischievously, to provide as full a >discussion and explanation as my fingers can handle. I quite like the amount of text in these descriptions. It _is_ important for us to know what ideas were batted around, discarded, revived, etc. I also quite like the decisions you reached. I think that most of the earth-shattering concerns people had have been alleviated. Finally, I like being cited. The ERB has permission to use my idea in perpetuity as long as my name stays with it. =) (oh well, I tried) Paul Prescod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html From: lee@sq.com Date: Thu, 14 Nov 96 20:53:51 EST To: w3c-sgml-wg@w3.org Subject: Re: ERB discussions and decisions: entities > To the lasting disappointment of the humorists among > us, the name squot was dropped in favor of apos, which occurs in 8879 > Annex D, set ISOnum, as do the others. Note that " is a single quote, which does not occur in ASCII. (many implementations include a single quote at position 39 instead of an apostrophe, but this is in error) The apostrophe is normally the same as an open single quote, but this is not necessarily so. Hence, ' is the correct entitiy for the ASCII ' character, as far as I can tell. I am very pleased with the decision to reduce the list of predefined entities to a manageable number. I'm not actually sure why any beyong < and & are needed, although > is good for symmetry. The current situation is so much of an improvement that it seems almost churlish to ask this, but why is ' included when it is not recognised in plain text? Lee Date: Thu, 14 Nov 1996 18:23:20 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: WD-xml-961114 hardcopy available I'm pleased to announce that the 961114 version of the XML Working Draft is now available in both PostScript and RTF. This is the version that will be distributed at SGML 96. You can download a copy from: ftp://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml.ps.zip ftp://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml.rtf.zip You can also use http to get these files. The draft will soon be made available in HTML from Tim Bray's site at www.textuality.com (expect an announcement tomorrow) and, of course, >from the W3C Web site. No sooner had I sent the PostScript copy in to the printers (four minutes under the deadline -- about right for commercial work) than I realized that somewhere in the last round of edits I had put the wrong version of the SGML declaration in Appendix A. Years of earning a living writing computer documentation have long since left me incapable of feeling properly remorseful about this; I mention it only to save some of you the trouble of pointing this out as a bug. It will get fixed the next time we refresh the WD. Jon Date: Thu, 14 Nov 1996 22:40:17 -0600 From: Len Bullard To: Tim Bray CC: W3C-SGML-WG@w3.org Subject: Re: Recent ERB votes Tim Bray wrote: > > At 11:20 PM 10/11/96 -0600, Len Bullard wrote: > > ... a whole bunch of stuff that deserves a reaction. ... > > I know Len quite well and respect his opinion on all sorts of > things, so at this point, I am going to discard diplomacy and say: > Len, you are right out to lunch on this one. Good. > 1. Microsoft and VRML and XML > > First off, your attempt to draw a parallel to the VRML war stories > is bogus. I was there too. Yes, I remember. I have the archive. > In VRML, Microsoft ignored the process, > did not even listen to the discussions, then dropped a violently > incompatible, radically weird, technology from a great height, and > was [deservedly] rejected. It was also a good design in many ways. Failure to participate publicly was the public reason for rejection, IMO. Brutality in the private sessions was reported by those who were there. > Len also conveniently ignores the fact that > a small panel of self-appointed experts, the VRML architecture group, > once the basic framework was selected, made essentially all the crucial > detail decisions about what was in, what was out, and the > technical details. Many members of the VAG never said a word on > the public mailing lists. True but not forgotten. But for every major decision, a list vote was held and enforced. It was as open a process as one could have hoped for. Probably the only one I've seen of that magnitude. > Microsoft has been on board, since day 1, and has subscribed to the basic > design goals that we pretty much all share. The interesting thing is that there were several who were on board >from day one and have been at work for a while now. A self-chosen group. VRML did not start that way. It was a list that eventually spawned a VAG, also self-appointed but selected as well by the moderator. Same results, different and open process. > I would also have been happier > to see Jean outline some of his positions to the WG; but if you look at the > brutal ERB meeting schedule, it becomes clear why only unemployed layabouts > like myself and James Clark, and those who can type faster than 3 people > can talk, such as Michael S-McQ and Eliot Kimber, can really afford to pitch > in there and also carry lances in WG-land. This is a bit too important for such excuses. Sorry, Tim, but a lot of us have brutal schedules. > The main role of the ERB was to > listen to the WG, and to vote. We did those things. Yes. > 2. Role and Transparency of the ERB > > I think that if we could have had a much larger-scale, slower, more > collegial process, we would have had a better XML. But we would > have had it in 1998, with luck. The ERB was the only way to make this > happen in Internet time. Interesting. Self-appointed panic as well. > Secondly, all the votes of the ERB are a matter of public record. You > can certainly find some trends there (Bray voting for minimalism at all > costs, Maler for SGML micro-consistency, Kimber for a larger subset, > Sperberg-McQueen for a richer authoring environment) but you can *not* > find evidence of any sleazy corporate machinations. Because there > weren't any. I didn't say there were. You are making up things, Tim. I point out that in the case of grandfathering HTML, you serve the economic interests of two corporations who are the only serious contenders in the HTML browser industry. That is not conspiracy. That you serve the interests of the HTML authors is also true, but this is not about HTML or any specific SGML application. If it is, then it is time for many of us to go on to other more important work. There are many SGML applications. Your own feelings about that are clear and a matter of record. So are mine. We can leave it at that. > Consider the makeup of the 11 voting members. 5 have no vendor > affiliations (Bray, Clark, Kimber, Magliery, Sperberg-McQueen) 3 > come from established SGML vendors (DeRose, Maler, Sharpe), 2 from > big system vendors (whose SGML plans if any are opaque to me at > least) (Bosak, Hollander), and Paoli from Microsoft. If you think that > Jean, even if he had been pushing a diabolical corporate agenda, could > buffalo this collection of obsessive-compulsives, pedantic purists, and > get-it-done-now engineers... gimme a break. I am not attacking Jean. I am saying, let microsoft make some contributions to this working list. Otherwise, let the HTML justifications for bad design go because the owner of the application is not interested in contributing. > 3. On the nature of appropriate debate > > It is perfectly reasonable to disagree with the selection of predefined > attributes (I do) and politico-technical design compromises (as Lee and > Bob Streich do) and deviations from 8879 no matter how minor (as Charles > does). It is not appropriate or useful, at this point, to start sliming > the process because it producec some results you didn't like. You are over the mark, Tim. I am not sliming this process. I am objecting to it. > This conspiracy soapbox is unworthy of you, Len, and has no basis in fact. > Climb down. Take the obnoxious reading elsewhere, Tim. You are talking conspiracy and that is a charge unworthy of you. I am talking bad design being defended by mediocre justfications, and noting that such things are being voted into the spec. That isn't conspiracy. It is poor judgement. Len Bullard Date: Thu, 14 Nov 1996 22:43:16 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: XML Spec Draft of Nov. 14th; versions at Textuality The November 14th draft is available in HTML, zipped PostScript, gzipped PostScript, zipped RTF, and gzipped RTF, at http://www.textuality.com/sgml-erb/ The HTML looks a little different - critiques on that welcome; since this will be the first form that many people will run across, it's worthwhile investing time in making it friendly. One specific question: all of the terms in the XML source are linked to a ... phrase. HTML being what it is, I've just put a hot-link in to the beginning of the termdef. Can anyone think of a clever trick to mark the extent of these definitions without seriously impairing the readability of the HTML? Coming real soon now: SGML/XML version, as soon as we finish wrangling the Panorama stylesheet. If anyone else reading this can think of another delivery format I'd be happy to host it. I find the slight differences in flavor that you get in the different versions are very interesting. The RTF/PostScript certainly has immensely superior typographic values; on the other hand, the fact that all the terms and nonterminals and references in the HTML are hotlinks is a substantial value-add. If you're having trouble printing one of the RTF/PS versions, you can get something perfectly usable by bringing the HTML up in a browser, reducing the font size to the minimum, and printing there; I find that MSIE produces a slightly more elegant printout than Netscape, but your mileage may vary. For what it's worth, Michael and I are agreed, but the ERB hasn't yet considered the question, that the huge list of 10646 character roles should migrate into an appendix, with a pointer in the main text. Aside from being hideously ugly, it breaks up the flow [and also, things that are in the appendix don't count against XML's 20-page budget.] Does anyone have a reason not to do this? - Tim Date: Fri, 15 Nov 1996 02:12:17 -0500 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@w3.org Subject: Re: XML Spec Draft of Nov. 14th; versions at Textuality >For what it's worth, Michael and I are agreed, but the ERB hasn't >yet considered the question, that the huge list >of 10646 character roles should migrate into an appendix, with >a pointer in the main text. Aside from being hideously ugly, >it breaks up the flow [and also, things that are in the >appendix don't count against XML's 20-page budget.] Does >anyone have a reason not to do this? - Tim Good idea. I think that in general, the names of the major character classes is enough. From: "Henry S. Thompson" Date: Fri, 15 Nov 96 10:19:12 GMT To: W3C SGML Working Group Subject: Last try I take it silence indicates agreement, that it IS too late to change anything, but being an ornery type, I'll try one last time: Will someone on the ERB stand up and be counted by explaining why an unprincipled hack (enumerating 11 grandfathered empty tags without amending the definitions of well-formedness and validity) is preferable to a principled hack (allowing and defining its impact on well-formedness and validity, as in version 0.1)? Will someone on the ERB stand up and be counted by explaining why the built-in entity names are not overridable? (I don't care about this one personally, but I think the others who do deserve an answer) Will someone on the ERB stand up and be counted by explaining why being a proper SGML subset is being prevented by the enumerated attribute value change? I do not doubt that, as Eliot pointed out, you all took your responsibilities seriously, voted on the basis of your understanding, and after due consideration took the decisions you have on all three of these cases. What I think the rest of us deserve, and you ought to WANT to provide, for ongoing PR reasons if nothing else, is an EXPLANATION of why you collectively disagreed with the apparent (substantial, in some cases) majority view of the rest of the WG members. All three of these issues are going to provoke questions next week -- you better get your story straight on them. What better place to do so than this list? Come on, guys -- we'd like to be behind you, but that's hard when we don't know where you stand! ht From: "Henry S. Thompson" Date: Fri, 15 Nov 96 10:31:22 GMT To: Michael Sperberg-McQueen Subject: Re: ERB discussions and decisions -- Retraction of previous message Cc: W3C SGML Working Group Sod's law my newsreader would stutter at a time like this. Michael's message more than satisfies the requests in my previous message, which would not have been sent if I had read his first. ht Date: Fri, 15 Nov 1996 08:06:24 -0600 From: Len Bullard To: "W. Eliot Kimber" CC: Paul Prescod , W3C-SGML-WG@w3.org Subject: Re: Rhetoric and Psychology W. Eliot Kimber wrote: > > At 02:06 PM 11/13/96 -0500, Paul Prescod wrote: > >I don't mean to pick on Lee, but I've just snapped. I'll address his > >conspiracy theories first, and then the larger issue of the degenerating > >tone of the discussions. > > Paul, > > Thanks for the reality check. Everything you say is true. No standard > created by and for more than one person can ever be perfect. XML bit off a > particularly difficult chunk to chew, namely to produce a simple > specification to solve a hard problem in a nearly impossible political > situation. The fact that we have even been able to produce a reasonable > draft without anybody A) leaving the ERB or B) any friendships being lost > (as far as I know) is, I think, a major miracle. Goodness. I didn't think it was time to get out the nerf bats and work each other over. Take a look at any list online that has done this kind of work and you will find harsh and harsher debates. I thought during the VRML debates people would gather torches and go burn down the headquarters of some of the companies if not the homes of the members. Nature of the process. Still is over there although having moved the paperwork to ISO calmed it down some. It is very necessary to take the heat here. It makes it much easier later to say, yes, we fought over that and still came to this conclusion. IMO, the archive is the legal documentation of the process much like a court transcript. It is later reviewed and many *heated* comments are overlooked as in-process debate that is not relevant to the final judgement of whether the results meet the requirements. Take it to the bank, we will all use the tactics we think necessary. Sometimes that means, do the mock turtle dance and let the issues fly. Later, it is much easier to say, yes, we debated the speed of a bolt action rifle, the man on the grassy knoll, etc. and were satisfied a lone nut could do it and probably did. That won't satisfy people who live for conspiracy, but it satisfies many more logical types. If we don't do that, no one is satisfied. If at the end, XML is useful, we did the job. len Date: Fri, 15 Nov 1996 11:06:04 -0500 To: w3c-sgml-wg@w3.org From: Paul Prescod Subject: CSS1 becomes W3C Proposed Recommendation If we want to change the CSS class selector character from ".", we should set whatever political process is needed into motion immediately. There are only a few implementations now. We should fix this now. We should also consider approaching the HTML ERB to ask them to change the HTML DTD to be compatible with the XML-HTML DTD as soon as possible (HTML 3.2? Cougar?). This change should not invalidate current documents. To: www-style@w3.org Subject: CSS1 becomes W3C Proposed Recommendation From: Hakon Lie The CSS1 specification has moved from being a W3C Working Draft to a W3C Proposed Recommendation. From [1]: --- Cascading Style Sheets, level 1 W3C Proposed Recommendation 12 Nov 1996 .. Status of this document This document is in the course of review by the members of the World-Wide Web Consortium. This is a stable document derived from internal Working Drafts of the W3C HTML Editorial Review Board and the public working draft WD-css1-960911. Details of this review have been distributed to member's representatives. Comments by non-members should be sent to www-style@w3.org. ... The review period will end on 11 December 1996 24:00 GMT. Within 14 days >from that time, the document's disposition will be announced: it may become a W3C Recommendation (possibly with minor changes), or it may revert to Working Draft status, or it may be dropped as a W3C work item. This document does not at this time imply any endorsement by the Consortium's staff or member organizations. --- Paul Prescod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html Date: Fri, 15 Nov 1996 11:41:57 -0500 To: W3C SGML Working Group From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Last try (really comments on recent ERB decisions) At 5:19 AM 11/15/96, Henry S. Thompson wrote: >I take it silence indicates agreement, that it IS too late to change >anything, but being an ornery type, I'll try one last time: Well, you got what you asked (too much of it in some cases). >Will someone on the ERB stand up and be counted by explaining >why an unprincipled hack (enumerating 11 grandfathered empty tags >without amending the definitions of well-formedness and validity) is >preferable to a principled hack (allowing >and defining its impact on well-formedness and validity, as in version >0.1)? They are gone. This is the best of the decisions recently announced. > >Will someone on the ERB stand up and be counted by explaining >why the built-in entity names are not overridable? Well, they are now gone altogether. This is worse than having them not be overridable. We have now ensured that HTML entities will not work without elaborate declarations. We could have made the default entities overrridable in the DTD subset, but that option does not appear to have been discussed by the ERB (according to the posting). Needless to say, I think this will damage XML acceptance by users. I'm sorry Len, but HTML is not an issue because of vendors but because of users. SGML users transform documents all the time -- that's part of what SGML is for -- HTML users do not, so they have a greater claim for compatibility in my book. >Will someone on the ERB stand up and be counted by >explaining why being a proper SGML subset is being prevented by the >enumerated attribute value change? It's been undone. However, we have now got the wrong decision and for craven political reasons. We have endorsed a known design flaw, that WG8 already intends to remove, solely to avoid disturbing people by the timing of our announcement. Since the SGML revision has been underway for some years now, with few public announcements of work-in-progress, I am inclined to think we may be justified in proceeding. Those of use who do not work for DOD-Contractors organizations can't afford to wait forever. So, if we follow this recent revision, enumerated attribute values will continue to be highly broken. I thought originally that the strict SGML-subset idea should have been strangled in the grave, and now we see the results in paying the price of pointless compatibility with SGML design flaws that are already slated for demolition. -- David 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: Fri, 15 Nov 1996 11:42:04 -0500 To: W3C SGML Working Group From: dgd@cs.bu.edu (David G. Durand) Subject: Re: ERB discussions and decisions At 3:55 PM 11/14/96, Michael Sperberg-McQueen wrote: >Summary: > > * Removed (Paoli abstaining) the Cougar entities from XML 1.0. > * Retained lt, gt, amp, quot, apos as non-redeclarable entities. > * Retained ban on nondeterministic content models. > * Prohibited (Bray, Hollander, Magliery dissenting) overlap among >enumerated types in XML 1.0. > * Dropped special handling of HTML EMPTY elements, added paragraph >explaining Prescod method of making HTML valid XML (Bray, Sharpe >dissenting). > * Added version declaration. > * Allowed processing instructions in DTD. In other words, any SGML design flaw, even one slated for demolition, will be preserved (except for whitespace, where we will choose to complicate the syntax, with attribute names that affect the parsing of data). (2 cases currently in evidence: determinism, attribute values). I am still interested in seeing an ERB discussion of MIME headers (an already existing, generalized, extensible, syntax for version information and other meta-data, which is compatible with SGML entity management according to Goldfarb, has existing code base, and would eliminate all our uses of the hideous PI feature (which seems like it will never die!)). I also ask, whither SDATA? This common processing convention (as supported by Omnimark, SP, SGMLS, and probably others (given the ESIS, probably a _lot_ of others) is still out, without any ERB formal discussion. I'll also note that Private Use does not seem to be very popular with Unicode advocates. In recent discussion on the URN list, Martin Duerst, I18N advocate extraordinary, reacted to my suggestion to use Private Use characters (in a different context) with a plea that we not advertise the presence of this feature of Unicode. I have yet to hear anyone offer an argument as to why a character string describing missing data (an unknown glyph) is inferior to a number describing missing data, especially when the web infrastructure does not provide a convenient way to make the private arrangements needed for private-use to work (funny property of a publishing medium, isn't it?). I stopped posting on these topics because it seemed that the arguments were all out in the open, but if the ERB is going to listen to them and then _not_ vote, maybe I should just keep repeating the obvious. "Numerical codes for non-numeric objects are _always_ inferior to string codes unless there is a critical storage-space tradeoff." -- David PS. I agree with Paul Prescod that this was the right level of detail to use in reporting on the decisions. _________________________________________ 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: Fri, 15 Nov 1996 12:07:02 -0500 To: dgd@cs.bu.edu (David G. Durand), W3C SGML Working Group From: Paul Prescod Subject: Re: Last try (really comments on recent ERB decisions) At 11:41 AM 11/15/96 -0500, David G. Durand wrote: > > It's been undone. However, we have now got the wrong decision and for >craven political reasons. We have endorsed a known design flaw, that WG8 >already intends to remove, solely to avoid disturbing people by the timing >of our announcement. We try to stay within SGML for the same reason that people try to obey laws, because we want others to. Most people agree that there are sometimes good reasons for ignoring standards, and for breaking laws, but it generally takes a Really Good Reason. But standards, like laws, are not set in stone. When our "SGML Constitution" is amended, we will have more latitude to correct this flaw without seeming to disregard the importance of standards. Ignoring SGML in XML would send out a message about what we *really* think of standards, and would weaken our moral authority. It's like when a cop speeds past you at double the speed limit and turns into a donut shop. I strongly suspect that all *validating* XML parsers are going to be based on SGML parsers in the short term anyhow, so this restriction would still have been in force, in practice. Between you and me, if you don't intend to use these validating XML parsers, then you can have as many overlapping attribute values in your instances as you like. Netscape and IE are certainly not going to report an error! Paul Prescod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html Date: Fri, 15 Nov 1996 12:09:49 -0500 To: lee@sq.com From: murray@spyglass.com (Murray Altheim) Subject: Re: ERB discussions and decisions: entities Cc: w3c-sgml-wg@w3.org Lee Quinn writes: >> To the lasting disappointment of the humorists among >> us, the name squot was dropped in favor of apos, which occurs in 8879 >> Annex D, set ISOnum, as do the others. > >Note that " is a single quote, which does not occur in ASCII. >(many implementations include a single quote at position 39 instead >of an apostrophe, but this is in error) [...] >from HTML 2.0 (RFC 1866): " " " Quotation mark op.cit., '13. The HTML Coded Character Set': " Quotation mark ' Apostrophe Why do you say " is a single quote? ASCII 34 is a double quote. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." Date: Fri, 15 Nov 1996 12:52:09 -0500 To: "Chris Wilson (PSD)" , "'Paul Prescod'" , "'w3c-sgml-wg@w3.org'" From: Paul Prescod Subject: RE: CSS1 becomes W3C Proposed Recommendation At 09:26 AM 11/15/96 -0800, Chris Wilson (PSD) wrote: >Sorry, I haven't been paying as close attention to this list as perhaps >I should have. What's the problem with CSS using '.' as a class >selector indicator? It is a useful SGML NAME character: Since the SGML Reference Concrete Syntax ("regular SGML") doesn't allow underscore as a word-joiner, the loss of "." is a problem. Paul Prescod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html From: "Chris Wilson (PSD)" To: "'Paul Prescod'" , "'w3c-sgml-wg@w3.org'" Subject: RE: CSS1 becomes W3C Proposed Recommendation Date: Fri, 15 Nov 1996 09:26:19 -0800 Encoding: 64 TEXT Sorry, I haven't been paying as close attention to this list as perhaps I should have. What's the problem with CSS using '.' as a class selector indicator? -Chris Chris Wilson cwilso@microsoft.com -[- >-----Original Message----- >From: Paul Prescod [SMTP:papresco@calum.csclub.uwaterloo.ca] >Sent: Friday, November 15, 1996 8:06 AM >To: w3c-sgml-wg@w3.org >Subject: CSS1 becomes W3C Proposed Recommendation > >If we want to change the CSS class selector character from ".", we should >set whatever political process is needed into motion immediately. There are >only a few implementations now. We should fix this now. > >We should also consider approaching the HTML ERB to ask them to change the >HTML DTD to be compatible with the XML-HTML DTD as soon as possible (HTML >3.2? Cougar?). This change should not invalidate current documents. > >To: www-style@w3.org >Subject: CSS1 becomes W3C Proposed Recommendation >From: Hakon Lie > >The CSS1 specification has moved from being a W3C Working Draft to a >W3C Proposed Recommendation. From [1]: > >--- >Cascading Style Sheets, level 1 > >W3C Proposed Recommendation 12 Nov 1996 > .. >Status of this document > >This document is in the course of review by the members of the >World-Wide Web Consortium. This is a stable document derived from >internal Working Drafts of the W3C HTML Editorial Review Board and the >public working draft WD-css1-960911. Details of this review have been >distributed to member's representatives. Comments by non-members >should be sent to www-style@w3.org. > >... > >The review period will end on 11 December 1996 24:00 GMT. Within 14 days >from that time, the document's disposition will be announced: it may become >a W3C Recommendation (possibly with minor changes), or it may revert to >Working Draft status, or it may be dropped as a W3C work item. This document >does not at this time imply any endorsement by the Consortium's staff or >member organizations. >--- > > Paul Prescod >--- >Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm > >"Shell is here on trial and it is as well that it is represented by counsel >said to be holding a watching brief."..."The ecological war that the Company >has waged in the Delta will be called to question sooner than later." -Ken >Saro-Wiwa to the tribunal that later executed him. >http://www.goldmanprize.org/goldman/ken.html > From: lee@sq.com Date: Fri, 15 Nov 96 13:28:49 EST To: w3c-sgml-wg@w3.org Subject: Re: ERB discussions and decisions: entities > Lee Quinn writes: (what is it with all these mailers that change the spelling of my name?) > >> To the lasting disappointment of the humorists among > >> us, the name squot was dropped in favor of apos, which occurs in 8879 > >> Annex D, set ISOnum, as do the others. > > > >Note that " is a single quote, which does not occur in ASCII. > >(many implementations include a single quote at position 39 instead > >of an apostrophe, but this is in error) [...] > > from HTML 2.0 (RFC 1866): > " " " Quotation mark > op.cit., '13. The HTML Coded Character Set': > " Quotation mark > ' Apostrophe > > Why do you say " is a single quote? ASCII 34 is a double quote. Sorry if I wasn't clear. " is defined as [single] quotation mark in ISO8879:1986(e) D.4.3.1, ENTITIES Numeric and Special Graphic, along with lsquo and rsquo for open and close single quote and apos for apostrophe. Joan Smith's book gives a squot as a single quote. The standard doesn't say which it is, only that it is a quotation mark, but the 10646 draft I have uses QUOTATION MARK for a double quote. I don't know which interpretation is correct, butif RFC1866 has quot being a double quote, we'd better stick with it. I still don't yet see why we need an entitiy for it. If it had been an SDATA entity, it would have been useful for escaping markup, but my understanding is that there are no SDATA dentities in XML. But I'm probably confused... (I think this works for & because Ee isn't a NAME START character) Lee From: "Chris Wilson (PSD)" To: "'Paul Prescod'" , "'w3c-sgml-wg@w3.org'" Subject: RE: CSS1 becomes W3C Proposed Recommendation Date: Fri, 15 Nov 1996 10:39:19 -0800 Encoding: 45 TEXT It's not actually lost; any character can be escaped in a CSS selector name. According to section 7.2 of the CSS PR, 'in CSS1, selectors...can also contain escaped characters and any Unicode character as a numeric code...the backslash followed by at most four hexadecimal digits (0..9A..F) stands for the Unicode character with that number...any character except a digit can be escaped to remove its special meaning, by putting a backslash in front, Example: "\"" is a string consisting of one double quote.' Does this suffice to address your concerns? -Chris Chris Wilson cwilso@microsoft.com ( And no, Internet Explorer 3.0 did not support this. :^) ) >-----Original Message----- >From: Paul Prescod [SMTP:papresco@calum.csclub.uwaterloo.ca] >Sent: Friday, November 15, 1996 9:52 AM >To: Chris Wilson (PSD); 'Paul Prescod'; 'w3c-sgml-wg@w3.org' >Subject: RE: CSS1 becomes W3C Proposed Recommendation > >At 09:26 AM 11/15/96 -0800, Chris Wilson (PSD) wrote: >>Sorry, I haven't been paying as close attention to this list as perhaps >>I should have. What's the problem with CSS using '.' as a class >>selector indicator? > >It is a useful SGML NAME character: > > > >Since the SGML Reference Concrete Syntax ("regular SGML") doesn't allow >underscore as a word-joiner, the loss of "." is a problem. > > Paul Prescod >--- >Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm > >"Shell is here on trial and it is as well that it is represented by counsel >said to be holding a watching brief."..."The ecological war that the Company >has waged in the Delta will be called to question sooner than later." -Ken >Saro-Wiwa to the tribunal that later executed him. >http://www.goldmanprize.org/goldman/ken.html > Date: Fri, 15 Nov 96 12:48:42 CST From: Michael Sperberg-McQueen Subject: Re: ERB discussions and decisions: entities To: W3C SGML Working Group On Thu, 14 Nov 1996 20:54:23 -0500 said: >Note that " is a single quote, which does not occur in ASCII. >(many implementations include a single quote at position 39 instead >of an apostrophe, but this is in error) The documentation I checked said it's a typewriter double quote, ASCII x21 or whatever. Unfortunately I can't remember what doc that was; what's your source? ISO 10646 and other ISO character sets uniformly use 'quotation mark' -- which is what the comment in the entity set says -- for the " symbol, and 'apostrophe' for the ' symbol, and 'grave accent' (and possibly something else indicating its use as an open single quote) for the ` character. That seems to me reason enough to believe the " should be treated as ", and ' as '. >I am very pleased with the decision to reduce the list of predefined >entities to a manageable number. I'm not actually sure why any beyong >< and & are needed, although > is good for symmetry. providing quot and apos makes it possible for attribute values to contain both characters; it also allows the user to choose which delimter to use, if they prefer to use the same one all the time. Strictly speaking, one would have sufficed. >The current situation is so much of an improvement that it seems almost >churlish to ask this, but why is ' included when it is not >recognised in plain text? It is recognized in literals and may need to be escaped there. Michael Date: Fri, 15 Nov 1996 19:26:35 +0000 To: lee@sq.com From: James Clark Subject: Re: ERB discussions and decisions: entities Cc: w3c-sgml-wg@w3.org At 20:53 14/11/96 EST, lee@sq.com wrote: >> To the lasting disappointment of the humorists among >> us, the name squot was dropped in favor of apos, which occurs in 8879 >> Annex D, set ISOnum, as do the others. > >Note that " is a single quote, which does not occur in ASCII. quot is defined as in 8879 as quotation mark, which is ISO standard name for the ASCII " character. HTML also defines quot as the ASCII " character. >I am very pleased with the decision to reduce the list of predefined >entities to a manageable number. I'm not actually sure why any beyong >< and & are needed, although > is good for symmetry. gt is included because ]]> is recognized even outside marked sections. >The current situation is so much of an improvement that it seems almost >churlish to ask this, but why is ' included when it is not >recognised in plain text? apos and quot are included for escaping LIT and LITA in literals. James To: W3C SGML Working Group Subject: Re: ERB discussions and decisions Date: Fri, 15 Nov 1996 12:46:33 -0800 From: Joe English Michael Sperberg-McQueen wrote: > The author's apologies to busy members of the WG who would prefer a > shorter account of the decisions; Not at all! Your account of the meeting is very much appreciated -- thanks for taking the time to report it at that level of detail. [ ... ] > * Discussed, once more, question C.10 (allow or prohibit > non-deterministic content models). [...] Determinism > is not particularly important to XML, but in Full SGML, the AND > connector and the definition of start-tag omission interact with it > and make it far more important. A minority asked what AND has to do > with it, AND groups and the ambiguity restriction interact in at least two ways: 1) The presence of AND groups makes checking content models for ambiguity much more difficult; and 2) The ambiguity restriction makes it easier to parse instances against content models with AND groups. #2 requires some explanation. There are dozens of algorithms for matching a sequence against a regular expression. The introduction of AND groups makes many of these algorithms either intractable or unusable. However, if a parser is allowed to assume that the content model is deterministic, then some of them become tractable again. In particular, many finite automaton-based techniques (e.g., Ken Thompson's familiar construction) and the "parse-tree walking" algorithm (the one used by SGMLS and, I think, SP) can be straightforwardly adapted to handle AND groups (using the "set an auxilliary flag" method), but this only works if the content model as a whole is deterministic. This is not to say that the ambiguity restriction is _necessary_ to make validation tractable: there are efficient algorithms for matching against extended regular expressions, including nondeterministic ones with the permutation operator (AND groups); these are not, however, as far as I know, as widely known. Nor do I mean to say that there are no automaton-based algorithms that can handle both AND groups and nondeterminism efficiently, it's just that I haven't been able to find any yet. Anyway, the upshot of all this is: the ambiguity rule makes it harder to validate DTDs. AND groups make it harder to validate instances. The ambiguity rule makes it "easier" to validate instances, in the sense that more algorithms are available to choose from. > and suggested that all cases of start-tag omission allowed > by the current rules would also be possible with nondeterministic > rules, as experimentation with any LALR(1) parser generator should > show. I've done some research on this issue too. I don't have any conclusive results, but I can say with certainty that: 1) The "obvious" approach [*] for handling start-tag omission by LL- or LR- parsing techniques will not work. In particular: a) using the "obvious" DTD->CFG construction, a LALR or LL parser will predict start-tag omission in places that an SGML parser will not, and an SGML parser will allow omission in places that an LALR or LL parser will not. b) the "obvious" DTD->CFG construction will not, in many cases, yield an LL- or LR- grammar [**]. 2) Converting content models to CFG productions induces a worst-case exponential increase in size (the average case for typical content models is linear, though). 3) LALR parsing is much more expensive than "conventional" SGML parsing (i.e., "how SP does it"). In particular, constructing LALR parsing tables requires time polynomial in the size of the entire grammar. [*] In case the "obvious" approach isn't so obvious: becomes, given suitable transformations for ?-start-tag, ?-content-model and ?-end-tag: X ::= x-start-tag x-content-model x-end-tag Y ::= y-start-tag y-content-model y-end y-end ::= y-end-tag | nothing Z ::= z-start z-content-model z-end z-start ::= z-start-tag | nothing z-end ::= z-end-tag | nothing [**] Consider: ... The "obvious" equivalent CFG is ambiguous (let alone LL or LR). --Joe English jenglish@crl.com Date: Fri, 15 Nov 1996 16:13:42 -0600 From: Len Bullard To: Joe English CC: W3C SGML Working Group Subject: Re: ERB discussions and decisions Joe English wrote: > > Michael Sperberg-McQueen wrote: > > > The author's apologies to busy members of the WG who would prefer a > > shorter account of the decisions; > > Not at all! Your account of the meeting is very much > appreciated -- thanks for taking the time to report it > at that level of detail. The level of detail is good for purpose of process and documentation of same. It serves both as a record and as the material needed to assemble follow on information products. Please continue this practice. len Date: Fri, 15 Nov 1996 17:39:16 -0500 (EST) To: W3C SGML Working Group Subject: PI and entity specs in XML draft of 14-Nov-96 From: John_Lavagnino@brown.edu Section 2.6 says that the name which follows " Subject: -XML-space attribute in XML draft of 14-Nov-96 From: John_Lavagnino@brown.edu Section 2.8 says that XML processors must behave as though every element encountered in the document had an attribute declared thus: -XML-space (preserve|collapse) #IMPLIED Is it then legal or not to explicitly declare such an attribute for an element, possible with the specification of a default value? There's nothing to suggest that it can't be done, except the provision in 1.5 about it being naughty to use a name beginning "-XML-" "in a fashion other than those described in this specification". And it does seem to me that for documents with a DTD one would certainly often want to be able to set a default in this manner in the DTD. John Lavagnino Martin Hensel Corporation and Brown University Date: Fri, 15 Nov 1996 16:35:43 -0800 To: John_Lavagnino@brown.edu, W3C SGML Working Group From: Tim Bray Subject: Re: -XML-space attribute in XML draft of 14-Nov-96 At 05:45 PM 11/15/96 -0500, John_Lavagnino@brown.edu wrote: >Section 2.8 says that > > XML processors must behave as though every element encountered > in the document had an attribute declared thus: > > -XML-space (preserve|collapse) #IMPLIED Yup, that language could be improved. What I think we mean is that of course you can declare such an attribute for some element (presumably #FIXED might come in handy) in your DTD, and this would not certainly not contravene the language about "using it for a purpose other than..." - or in a well-formed doc where you don't have a DTD, you could just slap the -XML-SPACE="KEEP" on any old start-tag you wanted to. This should be made more explicit and straightforward. - Tim Date: Fri, 15 Nov 1996 22:44:36 -0500 From: gtn@ebt.com (Gavin Nicol) To: w3c-sgml-wg@w3.org Subject: A few comments on the draft Comments on the version as of November 14th: Production 1. This group does not appear complete. Character classes are best defined elsewhere anyway. Section 2.8: This section is really quite distasteful. I cannot for the life of me understand why a content validator need necessarily be part of a parser. If we look upon a validator as just another application, then the "RE delenda est" solution is the cleanest because it results in identical post-parse data structures being transmitted to the application *irrespective* of the DTD. In other words, the parser would *always* parse as though mixed content were allowed (a la Dan Conolly's lex scanner). I do not mind the attributes too much, but certainly do not think them necessary given a model as outlined above. Section 2.9 That grotty PI is taking on a new life form. It should be killed, especially so now because we have variant parts that will *require* parsing it in order to get to the encoding specification. I find it quite disturbing to see the ERB promoting this over any other more technically sound mechanism. We should revisit MIME, and/or downplay the importance of the PI for content labelling. Production 38. The stuff about HTML really belongs in an appendix "Interoperability with HTML", possibly containing the variant HTML DTD's. Section 4.2.2 Seems a shame to limit SYSTEM ID's to URL's. The FSI backwayd compatability note seemed enough to allow them... Section 4.2.3 This PI should not be part of the normative text for XML. Not only that, but the information about which coded characer sets are used by SHIFT-JIS etc. is wrong anway (you fix it, I'll not help). I do not mind having the PI there for *documentation* purposes, but promoting it as the primary method of encoding declaration is not something I can condone. It is an ugly hack, and getting uglier. The weasley wording stating that all mechanisms should be used is insufficient. Appendix A. The note about SGML declaration is *wrong*. There need only be a *single* SGML declaration for XML with regards to character set. This shows a conflusion of encoding and coded character set. They are not the same thing and encoding has no relation to the SGML declaration at all. This is a very important point because if we follow the logic behind the statement in this section, then the numeric character reference specification, as defined, will be incompatible with SGML. From: lee@sq.com Date: Sat, 16 Nov 96 00:27:24 EST To: gtn@ebt.com, w3c-sgml-wg@w3.org Subject: Re: A few comments on the draft Some comments on Gavins' comments (sorry) and some new comments. > Production 1. > This group does not appear complete. > Character classes are best defined elsewhere anyway. Perhaps the best way to do this would be to use the Posix regexp notation and say: S ::= [:space:] and then in the character class section define exactly which code points map to space. An even better way would be to remove S entirely, and to explain that the following sequences are self-delimiting and are thus recognised whether or not surrounded by spaces: [:space:] the remaining tokens being determined by their respective modes -- for example, a string starts with " and continues to a matching " irrespective of whitespace. The productions would then all become much simpler, as they would be in terms of a sequence of tokens. I can't check the ISO 10646 code points here, but assume several people have done so. I am not sure I follow Literal data is any quoted string containing neither a left ankle bracket nor the quotation mark used as a delimiter Are you forbidding an unquoted < within an attribute value? The requirement for a root seems to preclude forests. We've found forests to be very useful, especially in the Canadian Winter :-) In 2.4, Most processors will require the more complex grammar [...] I think it might be more helpful to say why --- e.g.: Any non-trivial application is likely to require... In 2.5 For compatibility is meaningless unless you say with _what_... I realise the SGML world is in fact quite ashamed of the SGML syntax (even though the ideas are good), but I think you should say For compatibility with SGML if that's what you mean. If you want compatibility with the majority of HTML browsers in use today (and probably for the next year or two), you would also need to forbid > within a comment. 2.6 PI target... notation You need a cross reference to the definition of "notation". I think someone else already asked what "normally" means. I take it to mean "in all cases except for the string "XML". The application to which it belongs to which what belongs? The PI or the target or the notation? 2.7 CDATA sections should probably be called CDATA Marked Sections, so that other kinds of marked section can be introduced in future versions of XML, should it be so desired. I particularly want ignored TMP NDATA mrked sections :-) > Section 2.8: > This section is really quite distasteful. I agree. The statement In elment content, all white space (S) is ignored seems a little odd to me!

This is odd

Thisisodd

are the same? Or is "element content" being used in the SGML sense? If so, it must be defined before being used, and I would strongly urge the use of italics or some other indication that "element content" does not mean "element content" but means "element context" (so to speak). In COLLAPSE mode,

is the same as

but if there is an SGML parser, we get

(right?) I don't think this will help interoperability. All white space should be retained at the parser level in XML, at least ouside of a DTD. Inside a DTD I'd really hate it if a parser included the S nonterminal in parse trees! The XML _document type declaration_ may include a pointer... I think "pointer" is misleading here. You don't mean a machine address, for example, but rather some kind of logical pointer, and should say so. I agree with Gavin that the PI hack sucks. I can't accept that it is better than a fixed outermost element of XML with attributes, and I don't accept that it is better than MIME headers. It is not compatible with SGML or SGML tools, even though it is in some semse legal SGML: it will not in itself allow an XML file to be read by an SGML application, as the SGML application won't know how to switch character sets based on the PI. [34] RMDecl default value of ALL... if neither internal nor external subset no "visible" effect: what invisible effect is occurring? It would be far simpler to say that if there is no subset and no RMDecl, it defaults to NONE, but that if a subset is given, it defaults to INTERNAL if an internal subset only is given, and ALL otherwise. It would be a good idea to have a value that meant parse the internal subset if there is one parse the external subset if there is one if not, default to NONE as this would significantly ease document maintenance, I think. The spec is nearly 30 pages, by the way -- time to simplify it! > Production 38. The stuff about HTML really > belongs in an appendix "Interoperability with > HTML", possibly containing the variant HTML DTD's. Agreed. This section is greatly improved, by the way... :-) 3.2 Well, it's late & I'm hungry, so I have to go and forage for restaurants :-) More later. Hang on -- > Section 4.2.2 Seems a shame to limit SYSTEM ID's > to URL's. The FSI backwayd compatability note > seemed enough to allow them... I don't understand this comment. seemed enough to allow what? URLs _are_ allowed. It's a really bad idea to prefix them with , as that way you can't treat the same file as containing filenames and as containing URLs. If SGML used only the same syntax everywhere, so that FSIs were attributes on elements, we could use arch forms! Lee Date: Sat, 16 Nov 1996 00:40:30 -0500 From: gtn@ebt.com (Gavin Nicol) To: lee@sq.com CC: w3c-sgml-wg@w3.org Subject: Re: A few comments on the draft >Perhaps the best way to do this would be to use the >Posix regexp notation and say: > S ::= [:space:] >and then in the character class section define exactly >which code points map to space. Good idea... >The productions would then all become much simpler, as they would be >in terms of a sequence of tokens. and the ideas preceeding this are even better. I like simple token delimited parsing models (good for quick hacks). >The requirement for a root seems to preclude forests. >We've found forests to be very useful, especially in the Canadian >Winter :-) Ahh, but a forest is but a tree of tree after all... >All white space should be retained at the parser level in XML, >at least ouside of a DTD. Inside a DTD I'd really hate it if a >parser included the S nonterminal in parse trees! Quite! As I noted, if all whitespace is kept around, then the parser output is the same regardless of whether one has a DTD or not. A validator can do whateever it wants with that, and one thing might well be to enforce SGML RE/RS handling rules, thereby producing (assuming a valid document) a post-validator data structure exactly the same as that produced by an SGML system. On the other hand, other applications (formatters for example) could toss the whitespace as they see fit. >I agree with Gavin that the PI hack sucks. Thank you ;-) >> Section 4.2.2 Seems a shame to limit SYSTEM ID's >> to URL's. The FSI backwayd compatability note >> seemed enough to allow them... > >I don't understand this comment. seemed enough to allow what? >URLs _are_ allowed. It's a really bad idea to prefix them with , >as that way you can't treat the same file as containing filenames and >as containing URLs. If SGML used only the same syntax everywhere, so >that FSIs were attributes on elements, we could use arch forms! No. I wished to at least *allow* FSI's, though not as the normative mechanism perhaps. Date: Sat, 16 Nov 1996 01:45:56 -0500 To: "Chris Wilson (PSD)" , "'Paul Prescod'" , "'w3c-sgml-wg@w3.org'" From: Arjun Ray Subject: RE: CSS1 becomes W3C Proposed Recommendation At 10:39 AM 11/15/96 -0800, Chris Wilson (PSD) wrote: >It's not actually lost; any character can be escaped in a CSS selector >name. According to section 7.2 of the CSS PR, > >'in CSS1, selectors...can also contain escaped characters and any >Unicode character as a numeric code...the backslash followed by at most >four hexadecimal digits (0..9A..F) stands for the Unicode character with >that number...any character except a digit can be escaped to remove its >special meaning, by putting a backslash in front, Example: "\"" is a >string consisting of one double quote.' > >Does this suffice to address your concerns? No. It would be much simpler all around for interoperability if CSS1 abided by the naming conventions of the Reference Concrete Syntax. In fact, insofar as CSS1 has some (integral?) relation with HTML, I see no reason why it shouldn't square with naming conventions legal in HTML. Or are you saying that we should take something bog-standard and gratuitously break it with an unnecessary escaping "convention"? Arjun -- "Features whose purpose is to cause errors should be removed." -- Erik Naggum Date: Sat, 16 Nov 1996 03:45:41 -0500 To: "Chris Wilson (PSD)" , "'Paul Prescod'" , "'w3c-sgml-wg@w3.org'" From: Paul Prescod Subject: RE: CSS1 becomes W3C Proposed Recommendation At 10:39 AM 11/15/96 -0800, Chris Wilson (PSD) wrote: >It's not actually lost; any character can be escaped in a CSS selector >name. According to section 7.2 of the CSS PR, ... >Does this suffice to address your concerns? My post wasn't meant so much to say that the current CSS spec should be changed as to encourage conversation to decide if it should be. Since nobody else seems concerned, I guess this isn't a big problem, and the workaround will be okay for me. >( And no, Internet Explorer 3.0 did not support this. :^) ) That would make me feel more comfortable :^) Paul Presscod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html Date: Sat, 16 Nov 1996 04:37:59 -0500 To: lee@sq.com, gtn@ebt.com, w3c-sgml-wg@w3.org From: Paul Prescod Subject: XML Draft Section 2.8 `At 12:27 AM 11/16/96 EST, lee@sq.com wrote: >> Section 2.8: >> This section is really quite distasteful. >I agree. > >The statement > In elment content, all white space (S) is ignored >seems a little odd to me! >

This is odd

>

Thisisodd

>are the same? > >Or is "element content" being used in the SGML sense? It is defined in 3.2.2. There is one spot where it seems to be used in a different sense though, 3.1. You are right, there should probably be a forward reference to the definition in 2.8. >In COLLAPSE mode, >

> >is the same as >

> >but if there is an SGML parser, we get >

>(right?) > >I don't think this will help interoperability. I don't think that there is a system that is simpler than SGML which is also 100% interoperable with SGML tools. Making all REs significant certainly wouldn't. Some SGML tools use them to format output to make it more human readable (and I like that!!!). >All white space should be retained at the parser level in XML, >at least ouside of a DTD. Inside a DTD I'd really hate it if a >parser included the S nonterminal in parse trees! What if you are using XML documents to create DTDs (as has been agreed is reasonable)? The exact same problem afflicts people creating instance parsers as it does those working with DTDs. Some whitespace is only meant to format. If I were XML tagging this document, I would put and tags around our respective content, but I would still leave a blank line between your contributions and mine for readability. Paul Prescod --- Boycott Shell Oil worldwide! http://www.web.apc.org/embargo/shell.htm "Shell is here on trial and it is as well that it is represented by counsel said to be holding a watching brief."..."The ecological war that the Company has waged in the Delta will be called to question sooner than later." -Ken Saro-Wiwa to the tribunal that later executed him. http://www.goldmanprize.org/goldman/ken.html