Date: Sat, 16 Nov 1996 13:26:11 -0500 From: gtn@ebt.com (Gavin Nicol) To: papresco@calum.csclub.uwaterloo.ca CC: lee@sq.com, w3c-sgml-wg@w3.org Subject: Re: XML Draft Section 2.8 >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!!!). Do NOT say RE when you mean newline. That is the whole source of confusion here (the fact that people look upon them as one and the same). I think have all data be significant in all cases to be a great win: especially for identity tranforms and parser validation (ie. validation of parsers). Date: Sat, 16 Nov 1996 13:51:26 -0500 To: gtn@ebt.com (Gavin Nicol) From: Paul Prescod Subject: Re: XML Draft Section 2.8 Cc: lee@sq.com, w3c-sgml-wg@w3.org At 01:26 PM 11/16/96 -0500, Gavin Nicol wrote: >>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!!!). > >Do NOT say RE when you mean newline. That is the whole source of >confusion here (the fact that people look upon them as one and the >same). Okay. I think that the SGML spec intended for newlines to be REs (as people have attested here), but I can use a different terminology. "I don't think that there is a system that is simpler than SGML which is also 100% interoperable with SGML tools. Making all newlines significant certainly wouldn't be. Some SGML tools use them to format output to make it more human readable (and I like that!!!)." Changing the terminology does not change the facts about current tools. EBT uses these meaningless spaces and newlines all over their Website, both in content that is obviously generated by DynaWeb and content which I presume is created by hand. It is an entirely aestethic argument, but it seems to be a pervasive aestethic. 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, 16 Nov 1996 19:44:40 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Feedback on the spec Lots of good comments on the spec; for which, thanks. I am still unconvinced by Gavin's jeremaiads on the terrible evil of our technique, but keep trying Gavin, the ERB is demonstrably responsive to WG misgivings. However, even though I voted for the -XML-SPACE trick, and actually drafted that part of the spec myself, upon re-reading it, and listening to David Durand's arguments, it now feels intolerably inelegant. Look, HTML processors are going to do what they do with spaces. Full-text indexers and authoring tools and database engines are all going to do radically different sets of things. I now fail to see why an XML processor should get in the way of what an application wants to do with white space, particularly since both WG8 and now (in my view) the ERB have failed to come up with a simple, clean way to specify anything more useful. And not for lack of effort. Also - a very material problem - with the current language, it is simply impossible to base a full-text indexer on an XML parser; indexers often need to know the byte offsets of words in entities. OK, there are other problems: the processor needs to provide more data, e.g. lengths of excised comments and entity references, but these can be added without breaking the spec - the application of -xml-space="COLLAPSE" to any element fatally cripples a full-text indexer. For this reason, if we must retain COLLAPSE, the spec should say that the application can cause the processor to ignore this behavior. So let's lose the Space Handling bit. I would retain the provision that *if* there's a DTD *and* you know you're in Element Content, the processor must inform the application of this since the application could thus know that any white space cannot be character data. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 From: lee@sq.com Date: Sat, 16 Nov 96 23:46:01 EST To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: Feedback on the spec > So let's lose the Space Handling bit. Amid much rejoicing in Toronto (and probablyu Japan) Lee Date: Sun, 17 Nov 1996 07:04:26 -0500 From: gtn@ebt.com (Gavin Nicol) To: lee@sq.com CC: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: Feedback on the spec >> So let's lose the Space Handling bit. > >Amid much rejoicing in Toronto (and probablyu Japan) ... (too happy/shocked for words) Date: Sun, 17 Nov 1996 13:22:11 +0000 To: Tim Bray From: James Clark Subject: Re: Feedback on the spec Cc: w3c-sgml-wg@w3.org At 19:44 16/11/96 -0800, Tim Bray wrote: >Also - a very material problem - with the current language, it is simply >impossible to base a full-text indexer on an XML parser; indexers often >need to know the byte offsets of words in entities. OK, there are other >problems: the processor needs to provide more data, e.g. lengths of excised >comments and entity references, but these can be added without breaking the >spec - the application of -xml-space="COLLAPSE" to any element fatally >cripples a full-text indexer. It is perfectly possible for a processor to collapse white space whilst reporting byte offsets. In fact SP does it today (in public identifiers). James Date: Mon, 18 Nov 1996 01:38:52 +1100 From: Rick Jelliffe To: "David G. Durand" CC: W3C SGML Working Group Subject: Re: ERB discussions and decisions David G. Durand wrote: > 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?). OK, lets decree that all names should be written in Chinese, since they are the most numerous people and characters. They have a phonetic system, so we can spell out any English words in bopomofo: in the West will only have to learn a few dozen characters, which is trivial, and we can figure out what a name means by looking in some (online) list with representative glyphs :-) Less flippantly, even simple English names are not clear. It took me a long time to realise Americans seem to mean what we call "hash" by "pound". So I don't have any confidence that English names are much use to most people in the world. That is the first reason why names are inferior. The second reason is that there are so many characters that giving them identifiers that also describe them means some of those identifiers must get very complicated, unless you adopt a Polish notation (semi-acronym contractions) like Microsoft advocates for C code. In which case you don't have a name anyway, since you need to know the contraction. The Omega thread earlier shows how deceptive it can be to use meaningful-looking identifiers. The third reason is that the way people seem to like to handle lots of characters is to use a "Keycaps" utility applet, like Windows and Macs (and FrameMaker on UNIX) provide. In this case, the user doesn't care what the identifier is. So the main concern is for machine efficiency rather than readability, IMHO, since users increasingly won't edit in dumb text editors. So both our points may be moot (but my point is less moot than yours :-). You mention 'unknown glyphs', and I think you really mean arbitrary glyphs not specifiable by ISO10646+markup+stylesheet/DSSSL+locale. I have been assuming that XML was targetted at 'resolved' (closed-system) data, not (open-system) system-independant data. In a closed-system, resolution of arbitrary foreign glyphs must be a transparent function of the application, not an XML parser function that requires any user's intervention. Which sounds to me like something better handled in-place in element markup rather than entity markup, given the rarity of the glyphs, and in the spirit of element-set-less simplicity from HTML (or is that spectre?) -- Regards Rick Jelliffe email: ricko@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 262 4777 fax: +61 2 262 4774 _______________________________________________________________ Date: Sun, 17 Nov 1996 07:04:04 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: gtn@ebt.com CC: lee@sq.com, tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: Feedback on the spec | >> So let's lose the Space Handling bit. | > | >Amid much rejoicing in Toronto (and probablyu Japan) | | ... (too happy/shocked for words) I wouldn't start dancing in the streets yet. The -xml-space mechanism came out of many, many hours of discussion in the ERB during which the alternatives were discussed not just exhaustively but to the point of literal exhaustion. And this came after a long discussion of the RE rules in the WG that can be found in the archives. The final vote on the language in the current draft was unanimous. I haven't seen any new information presented recently that would change this. The fact that Tim has changed his mind is interesting but in itself procedurally insignificant. If it is based on some new information that was not present during the long discussions that have already taken place on this subject, I would like a clear statement of that new information and how it fundamentally changes the considerations that went into the decision as it presently stands. Jon Date: Mon, 18 Nov 1996 03:16:06 +1100 From: Rick Jelliffe To: Tim Bray CC: w3c-sgml-wg@w3.org Subject: Re: XML Spec Draft of Nov. 14th; versions at Textuality Tim Bray wrote: > > The November 14th draft is available in HTML, zipped PostScript, > gzipped PostScript, zipped RTF, and gzipped RTF, at > > http://www.textuality.com/sgml-erb/ Well done. > 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. The Technical Corrigendum (TC) to SGML on Extended Naming Rules (ENR) looks like it has succeeded. If so, there is now a legit SGML declaration possible for defining all those extra name characters, if they are used. (EditTime editor already handles ENR/Unicode, if anyone is interested.) ENR TC is at http://www.ornl.gov/sgml/wg8/document/1896.htm By the way, if the XML data has been generated valid, am I right in thinking a non-validing XML parser is completely OK with the robust and simple lexical rule that a name is anything up to a delimiter or 's' (after entity references in (non-CDATA) attribute values have been resolved)? If so, that should be made clear in the 1.0 spec, since it drastically simplifies things for implementors. Also, I think the &u form entities should just have the "u" prefix, not the "u-" prefix. I don't think it adds anything, and, potentially add thousands of characters to any entity declarations. -- Regards Rick Jelliffe email: ricko@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 262 4777 fax: +61 2 262 4774 _______________________________________________________________ Date: Sun, 17 Nov 1996 14:11:18 -0500 To: W3C SGML Working Group From: dgd@cs.bu.edu (David G. Durand) Subject: Re: ERB discussions and decisions At 1:38 AM 11/18/96, Rick Jelliffe wrote: > >OK, lets decree that all names should be written in Chinese, since they >are >the most numerous people and characters. They have a phonetic system, >so we can spell out any English words in bopomofo: in the West will only >have to >learn a few dozen characters, which is trivial, and we can figure out >what a name means by looking in some (online) list with representative >glyphs :-) Interesting, but not relevant to the problem that I am raising, which is not to do with the _ordinary_ problems of internationalization, but the ordinary problem of "nonstandard characters". >Less flippantly, even simple English names are not clear. It took me a >long time to realise Americans seem to mean what we call "hash" by >"pound". >So I don't have any confidence that English names are much use to most >people in the world. That is the first reason why names are inferior. Inferior to "Private-use character #C023"? That is even worse than "[Pound sign]", which at least gives me a 50% chance of finding the right character. "[Sumerian Cuneiform GUL.2]" might bemore meaningful, too. Even "[Brantaku Lhatala]" is no worse than "Private use character #C023" >The second reason is that there are so many characters that giving them >identifiers that also describe them means some of those identifiers must >get very complicated, unless you adopt a Polish notation (semi-acronym >contractions) >like Microsoft advocates for C code. In which case you don't have a name >anyway, since you need to know the contraction. The Omega thread >earlier >shows how deceptive it can be to use meaningful-looking identifiers. Yes, but a table of even long identifiers at the top of a document is not a cause for abbreviation (we are discussing entity definitions, after all). And the point is not that they will _always work_ but that they are _never worse_ than just a number. >The third reason is that the way people seem to like to handle lots of >characters is to use a "Keycaps" utility applet, like Windows and Macs >(and FrameMaker on UNIX) provide. In this case, the user doesn't care >what the identifier is. So the main concern is for machine efficiency >rather than readability, IMHO, since users increasingly won't edit in >dumb text editors. So both our points may be moot (but my point is >less moot than yours :-). We are talking about how a system should represent a character that is not in Unicode for transmission on the wire. Mathematical symbols are proabably the best non-scholarly example raised so far in the discussion. >You mention 'unknown glyphs', and I think you really mean arbitrary >glyphs not specifiable by ISO10646+markup+stylesheet/DSSSL+locale. I >have >been assuming that XML was targetted at 'resolved' (closed-system) data, >not (open-system) system-independant data. Well, then you haven't been reading the many arguments on this topic very closely. > In a closed-system, >resolution >of arbitrary foreign glyphs must be a transparent function of the >application, >not an XML parser function that requires any user's intervention. >Which sounds to me like something better handled in-place in element >markup >rather than entity markup, given the rarity of the glyphs, and in the >spirit of element-set-less simplicity from HTML (or is that spectre?) Yes, but that only works for a closed vocabulary of glyphs. I don't believe that that is a closed set, ever has been a closed set in the history of humanity, or ever will be a closed set at some future date. -- 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: Sun, 17 Nov 1996 13:49:55 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: Feedback on the spec At 07:04 AM 17/11/96 -0800, Jon Bosak wrote: >| >> So let's lose the Space Handling bit. >| > >| >Amid much rejoicing in Toronto (and probablyu Japan) >| ... (too happy/shocked for words) > >I wouldn't start dancing in the streets yet. Jon is correct. I thought it was obvious (although I should have said so) that this was merely a personal point of view that I was advancing in the WG. > If it is based on some new information >that was not present during the long discussions that have already >taken place on this subject, I would like a clear statement of that >new information Three things. (a) The principle we voted on sounded reasonable. The language that was generated in the spec (after a *whole lot* of work) is messy, inelegant, and I think prone to misinterpretation. Much like 8879. Note the excellent and difficult question raised by Paul Grosso in respect of white space at text entity boundaries. I predict that things like this will keep coming up us a result of us having opened the Pandora's box of interfering with users' data. (b) having made the decision to reserve some attribute/element namespace, we only had to use it once. I think this is a signal that we're doing something wrong. (c) Because of our decision on unified attribute name space, no element to which you might want to apply -xml-space can take an enumerated-value attribute where the enumeration includes either "keep" or "collapse". The only solution is to change the attribute values to "-xml-keep" and "-xml-collapse". - Tim Date: Sun, 17 Nov 1996 13:49:51 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: Feedback on the spec At 01:22 PM 17/11/96 +0000, James Clark wrote: >At 19:44 16/11/96 -0800, Tim Bray wrote: >>Also - a very material problem - with the current language, it is simply >>impossible to base a full-text indexer on an XML parser; indexers often >>need to know the byte offsets of words in entities. >It is perfectly possible for a processor to collapse white space whilst >reporting byte offsets. In fact SP does it today (in public identifiers). Suppose I have:

Testing, one 2 three four five

are you saying that SP can tell me the byte offsets of the individual words in that text, while it also performs the -xml-space="collapse" behavior? This seems difficult - how is it accomplished? - Tim Date: Sun, 17 Nov 1996 21:35:29 -0500 To: Tim Bray , w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: Feedback on the spec At 01:49 PM 11/17/96 -0800, Tim Bray wrote: >Three things. (a) The principle we voted on sounded reasonable. The >language that was generated in the spec (after a *whole lot* of >work) is messy, inelegant, and I think prone to misinterpretation. >Much like 8879. Note the excellent and difficult question raised by >Paul Grosso in respect of white space at text entity boundaries. I >predict that things like this will keep coming up us a result of >us having opened the Pandora's box of interfering with users' data. We need to keep the concepts of "source" and "destination" separate. I would be annoyed if my text editor changed the source of my SGML (or C++ or Java) documents. But in none of those languages am I surprised or annoyed when the language parser strips out token-delimiting whitespace: ^ indicates token separator ! indicates meaningful space C++: cout << "Foo Bar" << endl ; ^ ^ ! ^ ^ ^ SGML/XML: Foo Bar ^ ^ ^ ! ^ ^ ^ These rules are not bizarre inventions from outer space. They follow common encoding/programming language conventions. There is no "interfering with users' data". I haven't yet seen Paul's post that questioned entity/record end handling. >(b) having made the decision to reserve some attribute/element >namespace, we only had to use it once. I think this is a signal >that we're doing something wrong. > >(c) Because of our decision on unified attribute name space, no >element to which you might want to apply -xml-space can take an >enumerated-value attribute where the enumeration includes either >"keep" or "collapse". The only solution is to change the >attribute values to "-xml-keep" and "-xml-collapse". I agree that the attribute thing seems suboptimal to me. Couldn't it be replaced with a marked-section mechanism? By restricting the content of those marked sections we could probably eliminate *all* occurances of SGML-incompatibility until SGML is fixed. 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, 18 Nov 1996 06:37:59 -0500 To: w3c-sgml-wg@w3.org From: Paul Prescod Subject: RS/RE in SGML 97 I don't want to introduce any more funny syntax for XML. But perhaps for SGML 97 WG8 could make the distinction between element context and mixed context syntactically clear. Then a DTD-less parser and a human reader can see where whitespace will be normalized and where it will not be. }HEAD> }BODY> }HTML> 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, 18 Nov 1996 08:52:19 -0500 To: w3c-sgml-wg@w3.org From: Paul Prescod Subject: XML Abstract "Abstract" "Extensible Markup Language (XML) is an extremely simple dialect of SGML which is completely described in this document. The goal is to enable [*]generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. For this reason, XML has been designed for ease of implementation and for interoperability with both SGML and HTML." I would like to suggest a change of wording there. To me, "generic SGML" is SGML conforming to the full range of features available in the SGML specification (e.g. SGML without limitations not present in the ISO standard). I would prefer "generic markup conforming to the SGML standard". 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, 18 Nov 1996 08:57:25 -0500 To: w3c-sgml-wg@w3.org From: Paul Prescod Subject: XML Introduction "XML documents are made up of storage units called entities, which contain either text or binary data." Could we say "XML text or non-XML text?" I am not sure in what sense an ASCII inclusion (e.g. a VRML world) is more "binary" than an XML document. 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, 18 Nov 1996 08:36:38 -0600 From: Len Bullard To: Paul Prescod CC: w3c-sgml-wg@w3.org Subject: Re: XML Introduction Paul Prescod wrote: > > "XML documents are made up of storage units called entities, which contain > either text or binary data." > > Could we say "XML text or non-XML text?" I am not sure in what sense an > ASCII inclusion (e.g. a VRML world) is more "binary" than an XML document. Agreed. Would XML ever contain VRML? VRML x.x might contain XML. There were some long discussions on having a structured text representation for 2.0. HTML was considered, but it was decided that simpler text was preferable for the current systems. We also considered that HTML was a particular text application, and that others might be needed or desired. VRML 1.0 is ASCII. VRML 2.0 is UTF8. The definition is looser than is comfortable. Isn't the notion of notation stronger? Text or binary seems weakly-defined. len bullard Date: Mon, 18 Nov 1996 10:00:50 -0500 To: cbullard@HiWAAY.net, Paul Prescod From: Paul Prescod Subject: Re: XML Introduction Cc: w3c-sgml-wg@w3.org At 08:36 AM 11/18/96 -0600, Len Bullard wrote: >Paul Prescod wrote: >> Could we say "XML text or non-XML text?" I am not sure in what sense an >> ASCII inclusion (e.g. a VRML world) is more "binary" than an XML document. I would like to amend my suggestion to "XML data or non-XML data". >Agreed. Would XML ever contain VRML? Why not? Isn't VRML a good language for embedding a 3D representation of financial data? Or of a room? >VRML x.x might contain XML. ... >We also considered that HTML was a particular >text application, and that others might be needed or desired. Good decision! 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, 18 Nov 1996 13:10:31 -0600 From: Len Bullard To: Paul Prescod CC: w3c-sgml-wg@w3.org Subject: Re: XML Introduction Paul Prescod wrote: > > > >Agreed. Would XML ever contain VRML? > > Why not? Isn't VRML a good language for embedding a 3D representation of > financial data? Or of a room? Sure. I just wasn't sure about using it inline. OTH, why not. > >VRML x.x might contain XML. > ... > >We also considered that HTML was a particular > >text application, and that others might be needed or desired. > > Good decision! There was a lot of discussion about the ease of implementation of embedding text apps inside VRML objects, although, it isn't impossible. Requiring it seemed burdensome at the time but there were several good arguments, some from Tim Bray and Gavin Nicol who may remember them, for having this kind of functionality in VRML. We disagreed on the HTML-only aspects. The consensus seemed to be, "that's what frames are for". BTW, VRML does not cite a frame directly but includes a target attribute for which a frame is given as an example. len Date: Mon, 18 Nov 1996 13:45:08 -0600 From: Len Bullard To: w3c-sgml-wg@w3.org Subject: XML Draft Comments These are my comments on the Nov 14 draft. >Extensible Markup Language (XML) is an extremely simple dialect of SGML which is completely >described in this document. Remove "extremely simple". Not able to technically evaluate that without some criteria. >The goal is to enable generic SGML to be served, received, and >processed on the Web in the way that is now possible with HTML. Replace "generic SGML" with "this dialect of SGML" to clearly point out the difference. The term "generic SGML" is redundant in one sense, and not sensible in that any SGML is an application, not SGML. The use of the term, application profile, later is better in that it will be better understood in the standards community except for the confusion of SGML's common practice of using the terms DTD and SGML application interchangeably. Like three letter acronyms, all words are reserved by somebody. ;-) Unless a clarifying glossary is pointed to, you might want to include one in an appendix somewhere. >For this reason, XML has been >designed for ease of implementation, and for interoperability with both SGML and HTML. As HTML is an application of SGML, interoperability should refer to the systems that handle applications of SGML and specifically in the sentence cited, the systems that handle HTML. This is grandfathering and an imprecise equivalence. Change this to interoperability with systems. It is better to use portability where you intend, "I send you this markup and you do what you do with it" and use interoperability to mean "I send you this command and you do what you must". If you send an object that has both, you mean both. >Extensible Markup Language, abbreviated XML, describes a class of data objects called XML >documents which are stored on computers, and partially describes the behavior of programs which >process these objects. Does the language specify a behavior or does the spec prescribe a behavior based on the type of data object? It's quibbling, but unless there is a script in the XML, I expect it to only send data. >XML documents are made up of storage units called entities, which contain either text or binary >data. Text is immediately defined. Binary is defined later as notation. Would it be prudent to note this here in some short form or changed this to "text and non-text types defined by formal notation citation". Ick.... Binary seems restrictive in that SGML, VRML, CGM, etc are all notations and are not of necessity, binary. The later explanation >So-called binary data may in fact be textual, perhaps even >well-formed XML text; its identification as binary means that an XML processor need not >parse it in the fashion described by the specification. doesn't justify the use of the term, "binary". Why is this term used when all it appear to mean is "not constrained by XML specification". >A software module called an XML processor is used to read XML documents and provide >access to their content and structure. It is assumed that an XML processor is doing its work on >behalf of another module, referred to as the application. Processor is fine. I believe HyTime uses the term "engine". Are these equivalent? The term "application" is loose and may confuse the SGML user. Again, there are no unreserved terms left. Would it better to use the terms server and client? 1.5 Syntactic Constraints The tables should be in an appendix unless that makes them non-normative. Examples would suffice. >Entities must each contain an integral number of elements, comments, processing instructions, >and references, possibly together with character data not contained within any element in the >entity, or else they must contain non-textual data, which by definition contains no elements. Just to be sure, does this preclude the use of XML to reference an entity that contains other SGML/non-XML application data? >Users may extend the ISO 10646 character repertoire, in the rare cases where this is necessary, by >exploiting the private use areas. An editor design note to explain the ramifications of this might be prudent. Another tact is to add such to a follow-on "The Annotated XML Specification" which could be privately written and published. This is being done with VRML to help implementors with areas of the spec that need explanation, not clarification and to document design decisions. Clear transcripts of all design discussions and decisions are useful for this task. > Comments may appear anywhere except in a CDATA section, i.e. within element content, in > mixed content, or in a DTD subset. They may not occur within declarations or tags. They are > not part of the document's character data; an XML processor may, but need not, make it > possible for an application to retrieve the text of comments. For compatibility, the string -- > (double-hyphen) may not occur within comments. Is the use of "may" correct in this section as defined earlier? >Processing instructions (PIs) allow the XML processor to pass instructions directly to >selected applications. Since PIs have a deprecated heritage and undeserved bad reputation, should some explanation of the intent for its use be added in a non-normative appendix? This will come up again in later discussions of linking and external interface design to XML processors. > CDATA sections begin with the string Bugugly but ok. We are used to it and an editor can hide the acne scars. >In element content, all white space (S) is ignored; validating XML processors must not pass it >to the application. Non-validating processors which do not read the DTD must treat all >elements as if they were declared with mixed content; this will in some cases result in a different >parse tree from that produced by processors which do read the DTD. Another candidate for design notes. The impact of "a different parse tree" should be noted. >The white space handling mode is signaled through the use of a reserved attribute; XML >processors must behave as though every element encountered in the document had an attribute >declared thus: TripleBugUgly. In effect, to get around having a DTD, the DTD information moves into the instance. I don't know any other way though unless XML application communities are given a way to meta-declare this information or put it in the stylesheet. BTW, which is the default behavior if not specified in the instance? Is it undefined or left to the implementor? An argument to support this approach is that any editor worth having will automatically insert this attribute value for elements which clearly require it. >A document author can communicate whether or not >DTD processing is necessary using a required markup declaration (abbreviated RMD) >processing instruction, which appears as a pseudo-attribute on the XML declaration: As ugly as this first appears, it seems sound to leave the decision to the policies/processes of the document originator, be it author or organization. It will be interesting to see what develops as common practice. This looks like another candidate for the editor to enforce as a convenience to authors who would probably exercise the conservative options if they are aware of them. >For interoperation with existing Web software, users of XML may desire to create documents >which are simultaneously valid XML and processable by existing HTML browsers. The >difference in the form of empty elements may be accommodated by using an XML-compatible >version of the HTML DTD ... Sanity check for me. This says in effect, you can or but never . Is that right? In that case, the text as presented applies to any existing SGML application that currently uses , right? So, this explanation should be written to the general case of all SGML applications which use , with HTML cited as a well-known example. >The grammar is built on content particles (CPs), which consist of names, choice lists of content particles, >or sequence lists of content particles: What is the origin of the term, content particles? Are we invoking dead poets again or avoiding subatomic theorists? ;-) BTW, should there be a note that tells an SGML hacker that the minimization flags are gone, or do you wish to explain this 10,000 times when the error reports come in? > For compatibility reasons, the same Nmtoken may not occur more than once in the enumerated attribute > types of a single attribute-list declaration. Strong hint to WG8: this should go away quickly before the XML implementors get very far. >Notation declarations provide a name for the notation, for use in entity and attribute-list >declarations and in attribute-value specifications, and an external identifier for the notation which >may allow an XML processor or its client application to locate a helper application capable of >processing data in the given notation. The term "client application" is introduced. Can it be used in the abstract as well? The term "helper application" is introduced. It is informal though understood. Is there a better term to use here or is it necessary to introduce the concept informally? I can't think of a better term, but helper seems imprecise as all it says is "give this to someone else" and that could be a "plugin". >Despite this, there are a small number of cases where XML fails to be a pure subset of SGML, >including: Prefer the word "strict". This is not a moral or chemical issue but it is a legal one. Some explanation of what it means to be an "application profile" vs a "strict subset" is in order. Otherwise, the rationale that follows equates to "we thought it was ugly so we threw it out". Many of the decisions which violate SGML strictures are a result of the design decision to enable DTD-less processing. This should be so stated and the rationale for it. Otherwise, since any processing organization can agree in advance to have identical DTDs, they can always live without that design decision and get the same effect. So, tie this to the design rationale and save yourselves some headaches later. >The following list describes features which are available in SGML but not in XML. It may not >be complete. Complete it. ***************************************************************** Ok. Good job on the writing and substance. I understand the requirement on the 20 page limit. I do think clarity or completeness should not take a backseat to brevity. len bullard lockheed-martin Date: Wed, 20 Nov 1996 12:00:13 -0500 To: w3c-sgml-wg@w3.org From: Harvey Bingham Subject: on record handling, reference http://www.ornl.gov/sgml/wg8/documents/1875.htm U.S.Contribution on SGML review, by Lynne A. Price includes a detailed discussion on record handling, and more on character sets. Regards/Harvey Date: Thu, 21 Nov 1996 18:54:47 +1100 From: Rick Jelliffe To: "David G. Durand" CC: W3C SGML Working Group Subject: Re: ERB discussions and decisions David G. Durand wrote: > We are talking about how a system should represent a character that is not > in Unicode for transmission on the wire. Mathematical symbols are proabably > the best non-scholarly example raised so far in the discussion. Another good example might be place and personal names of Japanese and Taiwanese: these often cannot be written using characters in computer character sets, and must be spelled out in some alternative form. Imagine not even being able to give your name using a computer! For CJK characters it has been proposed (Prof. Eiji Matsuoka) that the standard national character book (E.g. in Japan the Daiwa Kanten) be used: these are collections with all known characters (or at, at least, glyphs) and national variants. So the character is identified by a string, either in the comment string or in the SDATA entity text value, giving the source book and an index into it, e.g. "Daiwa Kanten, character 40000", or "Daiwa Kanten, 3rd ed., p24, char 2" I guess. Other suggested methods are the telphone method of saying a well-known character that the character looks like, then giving the differences, or building the character up from radicals. (And there is also the encoded bitmap idea, to actually send a rough sample of the glyph.) These let the sucker at the receiving end reconstruct the character. (As I have said before, I think a preferable method is that whoever makes a document undertakes to put some kind of usable glyph on the web too, when some kind of WWW font service mechanism is established.) I am not objecting to nickname identifiers, expecially for specialists sending material to each other. That is fine for documents with occasional strange characters, and for logos and symbols. But document series that have tens of thousands of non-Unicode characters (e.g. the EBTI projects going on in CJK and Thailand) either the identifier or the SDATA text values have to have something that can be directly used to index large character tables: numbers are directly useful for this. Mapping the ISO entities sets to system values is tedious enough, let alone document-specific character entity sets. Anyway, I think you ask if ever (unnumbered) nicknames are not preferable to identifiers with numbers. I think there are many such, certainly in documents outside the Western hemisphere. -- Regards Rick Jelliffe email: ricko@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 262 4777 fax: +61 2 262 4774 _______________________________________________________________ Date: Thu, 21 Nov 1996 14:37:47 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Seybold on XML [Courtesy of a correspondent.] --------------------------------------------------------------------- THE BULLETIN: SEYBOLD NEWS & VIEWS ON ELECTRONIC PUBLISHING --------------------------------------------------------------------- Volume 2, No. 7 November 20, 1996 -------------------------------------------------------- W3C DEBUTS DRAFT OF SIMPLIFIED SGML On the tenth anniversary of the adoption of SGML as an ISO standard, a band of SGML experts announced they have drafted a simplified subset of the language they hope will spur the use of SGML on the Internet. The new language, Extensible Markup Language, or XML, was prepared by a World Wide Web Consortium working group consisting of about 80 members, primarily representing vendors. The announcement was made at SGML '96, being held in Boston this week. The first published draft is available on the Web at http://www.w3.org/pub/WWW/TR/WD-xml-964.html XML, like SGML, is a meta-language for describing the markup of different types of documents. It is simpler than SGML, reducing a 500-page reference to 26 pages. Unlike HTML, which has a fixed (albeit changing) set of tags, XML lets you define your own tags and attributes. Support for XML by the Internet community would open up vast new possibilities for Internet publishing. Instead of shoehorning all documents into HTML, or having to invent a browser to handle non-HTML documents, XML would enable a wide array of user-defined documents to be handled by generic Web application software. Users of SGML can easily make use of XML. XML is a valid subset of SGML, so translation from SGML to XML is straightforward. To simplify SGML, the W3C working group dropped support for certain features that required heavy processing on SGML client software. For example, a well-formed XML document is unambiguous, so that a browser or editor can read the tags and create a tree of the hierarchical structure without having to read a document type definition. XML also does not allow markup minimization, require that empty elements be self-identifying or support several of the complex optional features of SGML. At least two vendors were demonstrating XML support at SGML '96. Neither Microsoft nor Netscape has disclosed if it will support the standard. XML uses 8-bit ASCII and Unicode as its primary character sets. Having rocked the SGML community with the most radical SGML development in a decade, the W3C working group plans to continue with two more phases of XML. According to Jon Bosak, chair of the W3C SGML Editorial Review Board, the next phase will add more complex hyperlinking, and the third phase will address style sheets, using either an improved version of CSS or an online version of DSSSL. Date: Fri, 22 Nov 1996 14:06:58 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: XML announcement The following announcement went out to comp.infosystems.www.misc today. Jon ======================================================================== Newsgroups: comp.infosystems.www.misc Subject: XML proposed A new language for advanced Web applications has been proposed by a working group of the World Wide Web Consortium (W3C). Extensible Markup Language (XML) is a standardized text format specially designed for transmitting structured data to Web applications. The new language addresses the needs of Web publishers who encounter limitations in the ability of HTML to express structured data. XML differs from HTML in three basic ways: 1. Information providers can define new tag and attribute names at will. 2. Document structures can be nested to any level of complexity. 3. Any XML document can contain an optional description of its grammar for use by applications that need to perform structural validation. XML has been designed for maximum expressive power, maximum ease of implementation, and maximum teachability (the entire draft specification is less than 30 pages long). The XML character set is Unicode. XML is not backward-compatible with existing HTML documents, but documents conforming to the W3C HTML 3.2 specification can easily be converted to XML, as can documents conforming to ISO 8879 (SGML) and documents generated from databases. An initial working draft for XML 1.0 has been released for public discussion at http://www.w3.org/pub/WWW/TR/WD-xml-961114.html Zipped and gzipped PostScript versions of the draft are available at two sites: http://www.textuality.com/sgml-erb/xml.ps.zip http://www.textuality.com/sgml-erb/xml.ps.gz ftp://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml.ps.zip ftp://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml.ps.gz The current draft only addresses syntax, and consequently XML alone can at present only be used for interprocess communication and for the delivery of documents to specialized applications (or plug-ins) that have been configured to interpret a particular XML grammar. A specification that includes methods for associating hypertext linking and stylesheet mechanisms with XML documents is scheduled for release at the Sixth World Wide Web Conference in April, 1997. ---------------------------------------------------------------------- Jon Bosak, Online Information Technology Architect, Sun Microsystems ---------------------------------------------------------------------- 2550 Garcia Ave., MPK17-101, | Best is he that inuents, Mountain View, California 94043 | the next he that followes Davenport Group::SGML Open::ANSI X3V1 | forth and eekes out a good ::ISO/IEC JTC1/SC18/WG8::W3C SGML ERB | inuention. ---------------------------------------------------------------------- Date: Fri, 22 Nov 1996 16:46:52 -0600 To: w3c-sgml-wg@w3.org From: mag@ncsa.uiuc.edu (Tom Magliery) Subject: Re: XML announcement Cc: bosak@atlantic-83.eng.sun.com At 2:06 PM 11/22/96, Jon Bosak wrote: >The following announcement went out to comp.infosystems.www.misc today. here we go! :-) sure has been quiet around here this week. those us not lucky enough to be in boston are eagerly looking forward to hearing what the buzz has been around there... mag -- .---o Tom Magliery, Research Programmer .---o `-O-. NCSA, 605 E. Springfield (217) 333-3198 `-O-. o---' Champaign, IL 61820 O- mag@ncsa.uiuc.edu o---' Date: Fri, 22 Nov 1996 16:00:34 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: XML at SGML 96 This is a very brief summary report on XML activities at SGML 96 for the benefit of WG members who were not able to attend. ---------- WG MEETING ---------- A meeting of the W3C SGML WG was held on Sunday, November 17, the evening before the conference. The meeting gave those who attended a chance to see each other in person and to exchange views on the progress of the XML effort. Printed copies of the XML 1.0 draft of 961114 were distributed, and two questions were put to the members assembled: 1. Should we proceed in two further phases as we have been saying we would, or should we rather (a) proceed with both in parallel or (b) switch the order to address stylesheets first and linking second? Option (a) found little support in its strong form (that we create a subgroup for each activity), but the discussion made clear that some linking and some stylesheet functions would both have to be demonstrable by the April WWW conference. After thinking about (b) for a while, it was generally accepted that linking is more critical than stylesheets, so on paper at least, we are still saying that Phase II is basically about linking (though "linking" here has to include the ability to link to a stylesheet). 2. Bearing in mind that we need to limit WG participation to qualified people, should we invite more participants? Here the sentiment was clearly in favor of expanding the WG, but only by invitation. Current members of the WG can recommend persons known to them to have SGML expertise for inclusion in the WG, but there will be no general announcement or call for participants. Recommendations of persons to be considered for WG membership must be made to me directly by existing WG members. ----------- XML ROLLOUT ----------- The XML 1.0 draft was officially presented to a standing-room-only crowd during the second morning session of the technical track on Tuesday, November 19. Tommie Usdin chaired the session. Tim Bray eloquently presented the rationale for SGML simplification. Jon Bosak explained the organization of the WG and ERB and introduced the ERB members to the audience (nine of the eleven ERB members were in attendance on stage). Michael Sperberg-McQueen led the audience through the specification, noting which features of 8879 had been retained or dropped and explaining the new XML concept of "well formedness". James Clark briefly described the implications of XML for implementors. Tim Bray returned to give his recommendations for vendors, and Jon Bosak finished with recommendations for content providers. Questions following the presentations focused mainly on clarifications of technical points, especially the concept of well-formedness, and implicit requests for reassurance that we were not eliminating the concept of validation. The political backlash that some of us had feared simply did not materialize. --------- AFTERMATH --------- Since the XML rollout occurred fairly early in the conference, there were another two days to assess the impact of the announcement plus an additional day of SGML Open vendor feedback. While it is clear that not everyone in the SGML community is entirely happy with the draft specification, the general response was overwhelmingly positive. As we had hoped, the majority of SGML experts saw XML as a way to bring more people into the world of structure and open standards, while the beginners welcomed a subset that was obviously easier to learn than the full standard. Vendors were quick to see the marketing opportunities presented by XML, and most were claiming some form of support before the conference was over. One of the most gratifying and hopeful developments of the conference was the willingness expressed by leaders of the SGML revision effort to cooperate with us in further improving the XML specification by working quickly to approve a Technical Corrigendum to 8879 that would help us resolve some of the SGML compatibility issues that have given us the most trouble in defining the specification. This spirit of cooperation will make it possible to productively revisit at least three issues that have created the most unhappiness both in the WG and the ERB -- overlapping attribute values, white space handling, and ambiguous content models. The warm reception accorded XML by the SGML community and the positive participation of WG8 leadership in forming the best possible specification make me very optimistic that we can produce an attractive new technology in time for the WWW6 conference in April. Jon Date: Fri, 22 Nov 1996 21:51:44 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Boston, for those who weren't there Sitting in the airport on the way home, it dawned on me that at least 20 of you weren't in Boston and deserve a report on the first fruits of our machinations. I. Saturday During the OMUG (Omnimark Users' Group) meeting on Saturday, John McFadden, Omnimark supremo, expressed grave public doubts about XML. I wasn't there so I won't try to give you what he said at third-hand, but he certainly did make all the attendees curious to find out what it was all about. II. Sunday evening The WG and some hangers-on and friends and relations met Sunday night in a relaxed mood, basically to see each others' faces. Highlights were: 1. the availability of the standard; Jon Bosak brought 1200 copies, nicely printed up in a dark turquoise cover. (The conference had about 1000 attendees, and with vendors and camp followers, the total population was on the order of 1400). No draft XML specs were left over. Jon had also done up a 4-page, thorough, light-hearted, "XML Q & A", which was also generally available. I'm sure Jon could post a copy here. 2. lapel pins, red background with silver lettering saying "". There were only a hundred, and they're basically gone now, so a future collectors' item. 3. discussion of the problems and advantages of strict 8879 conformance, and how we could work with ISO to minimize those problems. Charles Goldfarb and the rest of the WG8 people, who had already been in Boston for a week-long meeting, were in 100% onside and we are completely unified in our desire to have an XML that is clean, free of design blemishes, and fully conformant. Skipping forward, by weeks' end WG8, through Charles, had solicited the ERB to propose a draft technical corrigendum to see if we can put to bed some of the thornier issues in this area. While ISO is not (nor arguably should be) a fast-moving organization, the WG8 folks will do what they can do to make this happen. 4. discussion about what we should discuss next. While no votes were taken, there seems to be a surprisingly-strong sentiment for plowing ahead with hyperlinks now and deferring the display-semantics issues for a bit. Reasons: CSS is awfully hard to fight at the moment, since both Netscape and Microsoft are working on it like mad, and potentially very vulnerable in a few months time if the design fails under pressure, as some of us suspect it will. Second, by stealing a few juicy tidbits from HyTime, we can probably, by the Web conference in April, probably show some hyperlink semantics that are way better than what a naked URL can do, and at the same time avoid getting diverted down the URI trail-of-tears. All in all a successful evening. A downside - at some point early in the week [Monday?] Gavin Nicol had his nice new Volvo totaled but I gather walked away from it. I never saw him again; if anyone can post reassuring us of Gavin's good health that would be welcome. III. Monday Charles, in his inventor's keynote, gave XML a nice plug. In the poster room (lots of good posters) Michael Sperberg-McQueen had done a nice big 3-panel XML poster; it was pretty well attended. I will retain the memory of Pam Gennusa standing there saying "No DTD? That makes me feel realy weird!" What with this, and the posters all over the place, and the pins in evidence, there was a bit of an XML buzz... a lot of people were nervous. IV. Tuesday The Show Daily led off with a brief piece from yours truly announcing that XML would hit the streets and giving some URL's and so on. Our session ran from 11:15 to 12:45, on the "expert" track. It was standing room only, so I think that the luckless souls giving parallel sessions may have been pretty thinly attended. I led off addressing the question of "Why XML?" The highlight of my speech was when I frisbeed the XML spec off the stage and it twirled like a November leaf gently to earth, with nary a thud. Also I drew attention to Jon's nearly miraculous deftness and energy in making XML happen. Jon was next, explaining the process; the coreof his talk was an attempt to pre-answer the main question which was doubtless being asked but not openly: what bunch of W3C turkeys are qualified to subset SGML? Jon focused not on people, but on DocBook, WG8, the Open Text Index, the OED, SDL, HyTime (Eliot's the co-editor), the TEI, Author/Editor, HoTMetaL, Adept, Dynatext, Dynaweb, IBMIDDOC, groff, sgmls, nsgmls, jade, Grif, Mosaic. The idea was that people should feel free to disagree with us, but that cheap shots about experience or qualifications were out of order. The highlights of Jon's speech were spontaneous applause for getting the draft out in 11 weeks, and for James' bio. Then Michael ran through the technical differences between SGML and XML, leaning heavily on the great pains we'd gone to for compatibility. James discussed the XML issues for implementors, covering the cases of people with existing SGML implementations, and people doing XML from scratch; he got a big laugh by out that a really big gain in ease of implementation is that you don't have to come to an understanding of the ISO standard. I and Jon closed, discussing the implications of XML respectively for vendors and information providers. We were able to announce that SoftQuad and Arbortext were doing an interoperability demo using XML (forgiveably, version 0.003 of the spec I think), that AIS had announced that Balise would implement XML (and they support Unicode!), as would Stilo, who sell an SGML Editor. (parenthetical note: Jean Paoli and Bill Smith took the opportunity to wander gleefully about the show floor, pouncing on hapless and high-strung exhibitor marketing executives and demanding XML demos). After the speechmaking, we had a half-hour for questions, and they were both friendly and excellent. Francois Chahuneau (his agenda only slightly veiled) wanted a verification that SGML vendors would need to put in Unicode support. Eric Severson wanted to know about our relationship with WG8. Somebody (Pam Gennusa?) wanted to know about the dangers of living without a DTD. Ludo Van Vooren pointed out that well-formed XML might be *very* useful for those doing large scale SGML up-conversions; the problem is not spotting the data items, but making the de facto structures fit the DTD. So, just make 'em well-formed XML and leave the validation until the editorial process comes around (if ever). Murray Altheim had a good question, but I forget what it was. V. Wednesday The show daily was all XML, almost literally - there were a couple of squibs on other subjects, but not much. The coverage was overwhelmingly favorable. We had disposed of almost all the XML pins, and they were gracing many well-known chests, including Charles Goldfarb's. XML was showing up on a lot of slides in only-loosely-related presentations. AIS was doing a printed XML press release - nice work. VI. Thursday The show daily had an editorial from Brian Travis, previously on record as dubious about XML, saying that he would wear the pin with pride. Michael touched briefly on XML in his (wonderful, as always) closing address. But the real news was that the GCA announced that there would be a workshop in March on the subject of "Selling SGML using XML and the Web" - two days in San Diego - the first wholly nontechnical SGML conference anywhere, as far as I know. Details to follow we hope. ===================== That's about all. I'd say it went about as well as we could have hoped. Our next job is figuring out what to do to make sure that XML makes the right impression at the big Web conference at Santa Clara in April. One parenthetical note - about half a dozen people separately said they wished we'd put FPI's in. My standard answer was "James says it's too hard," but there is clearly a desire for this on the SGML side of the fence. Not only would it be hard, it would add substantially to the spec. I'd favor heel-dragging on this, but now would be a good time for pro-FPI manifestoes in the WG. Everyone on the WG should reach around and pat themselves on the back. - Tim Date: Sat, 23 Nov 1996 15:39:38 -0500 To: Tim Bray From: murray@spyglass.com (Murray Altheim) Subject: Re: Boston, for those who weren't there Cc: w3c-sgml-wg@w3.org Tim Bray writes: >[...] Murray Altheim had a good question, but I forget what it was. Stylesheets and linking of meta information. Assuming even a minimal SGML application (without tables, forms, hyperlinks, and other features folks in the HTML world have come to expect*), we still need to provide a method of attaching presentation information to our structured content. >One parenthetical note - about half a dozen people separately said they >wished we'd put FPI's in. My standard answer was "James says it's too >hard," but there is clearly a desire for this on the SGML side of the >fence. Not only would it be hard, it would add substantially >to the spec. I'd favor heel-dragging on this, but now would be a >good time for pro-FPI manifestoes in the WG. I was one, only because I see academic, corporate and government sites wishing to build lightweight applications around a common DTD. Without FPIs there is no simple way (other than the hack of embedding URLs into system ids) of providing the benefits of public text. Perhaps a subset of TR9401 rather than the whole shebang would do fine. Murray * Netscape's new XML browser, called the 'Netscape Geomancer', already supports XML frames, VRML, BGSOUND, and BLINK. It also supports a new flavor of XML they've developed called XML+. Go smoke somethingk and call me in de morning. ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." Date: Sat, 23 Nov 1996 17:23:29 -0500 To: Tim Bray , w3c-sgml-wg@w3.org From: papresco@calum.csclub.uwaterloo.ca Subject: CSS vs. DSSSL-O At 09:51 PM 11/22/96 -0800, Tim Bray wrote: >Reasons: CSS is awfully hard to fight at the moment, since >both Netscape and Microsoft are working on it like mad, and potentially >very vulnerable in a few months time if the design fails under pressure, >as some of us suspect it will. Is there a way to avoid these notation wars? I'm wondering if, at the very least, we can sufficiently influence the concepts in the CSS-layout specification (which is still very much under development) so that they "align" with those of DSSSL-O. Perhaps we could attack through Java. It sounds bizarre, but right now Java is so heavily hyped that Java-anything is considered good. Ergo Netscape has declared "JavaScript Stylesheets". JavaScript is evil voodoo, but Java is actually not half bad. I am envisioning something we could call "Java stylesheets". It would be a DSSSL-like transformation that works on the source object and builds a screen display. The style sheet would be delivered as Java byte codes. The byte codes would have to have access to a much more powerful display layout API than they do now (fonts, layout, etc...much like DSSSL flow objects). Now there are a few different groups working on Scheme->Java, so we could deliver our DSSSL script as Java bytecodes and nobody would be the wiser. A war would have been averted. Principles: a) Scheme has a stigma (though I *really* like it, I can imagine Marc Andreesen snickering) b) DSSSL will have a scheme-stigma. c) DSSSL without scheme is, in my opinion, underpowered, just as CSS is underpowered. d) Java bytecodes put everyone on fairly level ground. e) Java interpreters are already widely deployed and getting more and more efficient. e) maybe once the document UI is controlled in Java there are some interesting interactive things we can do (expandable table of contents, for instance) Once Java-style sheets are implemented, CSS, DSSSL-O and full DSSSL could all be built on top of them, either by compilation *to* Java byte codes, or by interpretation *by* Java bytecodes. Perhaps it is too early in our understanding of online style sheets to choose *any* standardized style sheet syntax. Look at the complexity of DSSSL-Print. It is only after *centuries* of typographic development that we knew what the right flow objects and characteristics to provide were. 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.gem.co.za/ELA/ken.html Date: Sat, 23 Nov 1996 21:15:02 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: XML samples Experimenters needing some well-formed documents for testing XML tools can find a starter set at ftp://sunsite.unc.edu/pub/sun-info/standards/xml/eg/religion.1.00.xml.zip ftp://sunsite.unc.edu/pub/sun-info/standards/xml/eg/shakespeare.1.00.xml.zip Jon Date: Mon, 25 Nov 1996 10:23:44 +0000 To: Tim Bray , w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: Boston, for those who weren't there Tim > A downside - at some point early in >the week [Monday?] Gavin Nicol had his nice new Volvo totaled but >I gather walked away from it. I never saw him again; if anyone can >post reassuring us of Gavin's good health that would be welcome. > Gavin is alive and well (if without his glasses!), and currently recouperating by driving around Spain after a successful week at the W3C Internationalization and Multilingualism conference in Seville, at which he gave valuable support to my presentation on XML, and to other aspects of the role of DSSSL in processing multilingual documents properly. You might like to consider, carefully, the fact that ISO 10646 support is not fully available from CSS1 when looking at stylesheet issues for XML. While Bert Bos has now been made aware of what is needed for CSS2 in this field there are still likely to be many issues of multilingual document production that are not supported by CSS2 but are supported by DSSSL. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Mon, 25 Nov 1996 06:49:12 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: papresco@calum.csclub.uwaterloo.ca CC: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: CSS vs. DSSSL-O [Paul Prescod:] | At 09:51 PM 11/22/96 -0800, Tim Bray wrote: | >Reasons: CSS is awfully hard to fight at the moment, since | >both Netscape and Microsoft are working on it like mad, and potentially | >very vulnerable in a few months time if the design fails under pressure, | >as some of us suspect it will. | | Is there a way to avoid these notation wars? I'm wondering if, at the very | least, we can sufficiently influence the concepts in the CSS-layout | specification (which is still very much under development) so that they | "align" with those of DSSSL-O. | | Perhaps we could attack through Java. It sounds bizarre, but right now Java | is so heavily hyped that Java-anything is considered good. Ergo Netscape has | declared "JavaScript Stylesheets". JavaScript is evil voodoo, but Java is | actually not half bad. I am envisioning something we could call "Java | stylesheets". It would be a DSSSL-like transformation that works on the | source object and builds a screen display. The style sheet would be | delivered as Java byte codes. The byte codes would have to have access to a | much more powerful display layout API than they do now (fonts, layout, | etc...much like DSSSL flow objects). [... further details of this plan omitted ...] Personally, I think that the only strategy that makes sense here is the full frontal attack: enable dsssl-o processing through plug-ins or applets and insist that real XML browsers are browsers with dsssl-o capabilities. Remember, we have available a very powerful free DSSSL engine (Jade -- see http://www.jclark.com/jade/) designed to be used for exactly this purpose. It's entirely possible to have not just one but several dsssl-enabled browsers working by WWW6 if people with the requisite Windows rendering experience pick up this ball and run with it. If "XML" becomes just "XML with CSS" it will be because we failed to seize this opportunity while it was open to us. I am willing to serve as a coordination point for efforts to develop dsssl-o plug-ins or applets for demonstration at WWW6 in April. If you are working on such a thing and think that you have a reasonable chance for success in an April time frame, please let me know and I will arrange with the conference organizers for a demo session. There is a genuine possibility here for someone with the right combination of nerve and programming skill to create another breakthrough like Mosaic. If you are working on something and don't want to blow your cover until an April rollout, you can contact me privately and I will keep your work confidential until the conference. Jon ---------------------------------------------------------------------- Jon Bosak, Online Information Technology Architect, Sun Microsystems ---------------------------------------------------------------------- 2550 Garcia Ave., MPK17-101, | Best is he that inuents, Mountain View, California 94043 | the next he that followes Davenport Group::SGML Open::ANSI X3V1 | forth and eekes out a good ::ISO/IEC JTC1/SC18/WG8::W3C SGML ERB | inuention. ---------------------------------------------------------------------- Date: Mon, 25 Nov 1996 09:37:20 -0600 From: Len Bullard To: Jon Bosak CC: papresco@calum.csclub.uwaterloo.ca, tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: CSS vs. DSSSL-O Jon Bosak wrote: > Personally, I think that the only strategy that makes sense here is > the full frontal attack: enable dsssl-o processing through plug-ins or > applets and insist that real XML browsers are browsers with dsssl-o > capabilities. DSSSL is powerful. JADE is a good thing to have. Why would XML of necessity, (meaning, a requirement for conformance) require DSSSL? If simplicity is a goal, there are simpler ways to create stylesheets than DSSSL. Remember, I am not arguing against DSSSL or it's power, but I am asking why a "RealXML browser" must use it. That sounds like the sort of legal beagle trick that forces a system solution rather than enabling the vendor and the market to choose. The result will be to isolate XML, or tools, or certain vendors. Isolation leads to war quicker than a free trade zone. DSSSL must sell itself. If there is a compelling need and only one *obvious* solution, why is that a problem? The Technical Corrigendum and alignment made it possible to develop systems that can use the SGML standards family without conflicts, but it doesn't force that. XML is in a much weaker position to attempt to force that. Anyway, aren't hyperlinks the next scheduled task? len bullard Date: Mon, 25 Nov 1996 11:24:42 -0500 To: bosak@atlantic-83.eng.sun.com (Jon Bosak) From: murray@spyglass.com (Murray Altheim) Subject: Re: CSS vs. DSSSL-O Cc: w3c-sgml-wg@w3.org Jon Bosak writes: [...] >capabilities. Remember, we have available a very powerful free DSSSL >engine (Jade -- see http://www.jclark.com/jade/) designed to be used >for exactly this purpose. It's entirely possible to have not just one >but several dsssl-enabled browsers working by WWW6 if people with the >requisite Windows rendering experience pick up this ball and run with >it. If "XML" becomes just "XML with CSS" it will be because we failed >to seize this opportunity while it was open to us. Isn't Jade written for full DSSSL functionality? Just as one of the chief concerns of using SP in an application is the size of the code, wouldn't a Jade-o or Jade-Lite really be what we need here? If the compiled code for the stylesheet engine is an order of magnitude* larger than the XML parser, then a simplified toolkit is absolutely necessary if we expect dsssl-o support in applications. Murray * the executable and support files for Jade (Win95) total almost 700K. This doesn't include nsgmls. ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." Date: Mon, 25 Nov 1996 10:48:07 -0500 To: cbullard@HiWAAY.net, Jon Bosak From: Paul Prescod Subject: Re: CSS vs. DSSSL-O Cc: tbray@textuality.com, w3c-sgml-wg@w3.org At 09:37 AM 11/25/96 -0600, Len Bullard wrote: >Anyway, aren't hyperlinks the next scheduled task? I think that we are trying to decide that. It depends on our overall strategy. If Jon wants to get style sheet implementations by April, then we can't wait until too late to start discussing layout. Parsing and hyperlinking are relatively trivial (to implement) by comparison. Paul Prescod Date: Mon, 25 Nov 1996 13:33:28 -0600 From: Len Bullard To: Paul Prescod CC: Jon Bosak , tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: CSS vs. DSSSL-O Paul Prescod wrote: > > At 09:37 AM 11/25/96 -0600, Len Bullard wrote: > > >Anyway, aren't hyperlinks the next scheduled task? > > I think that we are trying to decide that. It depends on our overall > strategy. If Jon wants to get style sheet implementations by April, then we > can't wait until too late to start discussing layout. Parsing and > hyperlinking are relatively trivial (to implement) by comparison. > > Paul Prescod Ok. I thought that was already decided. It would seem the first issue would be if designing XML requires one to also design styles and hyperlinks. For SGML, those are separate issues traditionally. Why in XML are they not? len Date: Mon, 25 Nov 1996 19:06:25 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: murray@spyglass.com CC: w3c-sgml-wg@w3.org Subject: Re: CSS vs. DSSSL-O [Murray Altheim:] | Isn't Jade written for full DSSSL functionality? Just as one of the chief | concerns of using SP in an application is the size of the code, wouldn't a | Jade-o or Jade-Lite really be what we need here? | | If the compiled code for the stylesheet engine is an order of magnitude* | larger than the XML parser, then a simplified toolkit is absolutely | necessary if we expect dsssl-o support in applications. Jade is *not* written for full DSSSL functionality; it's not even close. It's dsssl-o with a few recent extensions. But it may indeed be necessary to cut it back in implementations. The need to find out is one of the reasons that I am trying to encourage some development. Jon Date: Mon, 25 Nov 1996 19:02:10 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: papresco@calum.csclub.uwaterloo.ca CC: cbullard@HiWAAY.net, tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: CSS vs. DSSSL-O [Paul Prescod:] | >Anyway, aren't hyperlinks the next scheduled task? | | I think that we are trying to decide that. It depends on our overall | strategy. If Jon wants to get style sheet implementations by April, then we | can't wait until too late to start discussing layout. The default style sheet language for the W3C SGML Web activity is dsssl-o (see the activity page). We don't need much discussion of that right now, but we do need some development if we want to demonstrate this by April; that's what I was suggesting. | Parsing and hyperlinking are relatively trivial (to implement) by | comparison. I hope you're right... Jon Date: Mon, 25 Nov 1996 18:56:30 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: cbullard@HiWAAY.net CC: papresco@calum.csclub.uwaterloo.ca, tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: CSS vs. DSSSL-O [Len Bullard:] | Jon Bosak wrote: | | > Personally, I think that the only strategy that makes sense here is | > the full frontal attack: enable dsssl-o processing through plug-ins or | > applets and insist that real XML browsers are browsers with dsssl-o | > capabilities. | | DSSSL is powerful. JADE is a good thing to have. Why would | XML of necessity, (meaning, a requirement for conformance) | require DSSSL? Notice that I began my comment with the word "personally". This means that I am expressing my personal desire or opinion, not an official position. However, I would like to point out that dsssl-o has been specified as the formatting standard for what we now call XML since the W3C page for this activity went public in June. The relevant section reads as follows:

Specific deliverables under development by the SGML WG/ERB include:

  • The specification of an application profile defining a form of generic SGML designed for Internet transmission and processing by user agents.
  • The specification of basic hypertext link types to be used with SGML. These types have yet to be identified, but a basic goal is to go beyond the single link type in HTML to include the types that have been considered basic in hypertext systems for the last decade.
  • The specification of extensions and public text needed to make DSSSL (SGML's stylesheet language) work in an Internet context.
| Anyway, aren't hyperlinks the next scheduled task? Yes. And it's because that will be our next official task that I was proposing to anyone interested that we try to get some dsssl-o support going on the side. Jon Date: Mon, 25 Nov 1996 22:00:02 -0600 From: Len Bullard To: Jon Bosak CC: w3c-sgml-wg@w3.org Subject: Re: CSS vs. DSSSL-O Jon Bosak wrote: > > The default style sheet language for the W3C SGML Web activity is > dsssl-o (see the activity page). We don't need much discussion of > that right now, but we do need some development if we want to > demonstrate this by April; that's what I was suggesting. Ok but if that is a done deal, why is it a work item? I hope that comes up for debate. The CSS guys have their case to make. DSSSL-O has few implementations whereas XML gets quite a few with some simple adjustments. If a vendor chooses to support CSS, why should that make it impossible to support XML as well? Why isn't a stylesheet type on a par with any other notation, eg. as a MIME type? > | Parsing and hyperlinking are relatively trivial (to implement) by > | comparison. > > I hope you're right... > > Jon So do I but I've been through the debate before and it wasn't that simple to choose. Hyperlinking has some notable variants and existing standards. Tim is probably right that adopting some HyTime concepts will help. We might consider looking at the legacy out there, IOW, how many ways have hyperlinks been defined in existing SGML applications, where are they similar and different, and how can XML support these. While the work on DOCBOOK, TEI, Mosaic etc cited in your speech are examples, so is the preexisting and well documented and well-supported work done in MIL-D-87269, MID, proposals to MIL-PRF-28001, the Philly DTD, etc. BTW, for the Quran test file, is this right? Also, see verse 78 of The Cow. Arc should be are. That one was easy. Good reading too. The files are a bit big for test files though. IDEAS handles them without a burp but the size is overkill for testing. len From: Kurt Conrad To: Jon Bosak Cc: "papresco@calum.csclub.uwaterloo.ca" , "tbray@textuality.com" , "w3c-sgml-wg@w3.org" Subject: RE: CSS vs. DSSSL-O Date: Mon, 25 Nov 1996 20:06:51 -0800 While reading Len's message, another thought came to mind. A much stronger case could me made for DSSSL(-o) if a substancial = portion of SGML vendors supported it in commercial products. = User-defined markup languages (on the other hand) and even portions of = HyTime have been supported in the open market for some time now. This = could easily make DSSSL seem much more risky to those driven by market = forces than should otherwise be the case and create an obstacle where = none needs to exist. /s/ kwc 11/25/96 20:06 Date: Mon, 25 Nov 1996 22:18:48 -0600 From: Len Bullard To: Jon Bosak CC: papresco@calum.csclub.uwaterloo.ca, tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: CSS vs. DSSSL-O Jon Bosak wrote: > > Notice that I began my comment with the word "personally". This means > that I am expressing my personal desire or opinion, not an official > position. Noted. >
  • The specification of extensions and public text needed to make > DSSSL (SGML's stylesheet language) work in an Internet context. > Also noted and I have very publicly stated support for DSSSL. But public announcements aside, I am looking for a technically compelling reason that this is the focus. IOW, if the CSS supporters have a case to make, they should make it. Otherwise, DSSSL-O is a fait accompli of a work item not a decision arrived at as a result of open technical debate. If by the conference cited, the CSS developers can also show how they would support XML using their approach, doesn't that strengthen XML? I don't know about particular XML applications (e.g, document types), but for some it must certainly be reasonable to use CSS. If that statement is technically incorrect, please tell me why. What I am saying is that I don't think that it is necessary to pit the style languages against each other for the sake of XML in more than it is necessary when one has a style lanaguage two parties agree to use to pit HTML against SGML. That seems bizarre. Why aren't stylesheet systems registered and negotiated like other MIME types? > | Anyway, aren't hyperlinks the next scheduled task? > > Yes. And it's because that will be our next official task that I was > proposing to anyone interested that we try to get some dsssl-o support > going on the side. Certainly, that is a worthy goal. Having the XML working group provide the recommendations for applying DSSSL-O to XML is fine. Having them choose DSSSL over CSS doesn't seem to be necessary. It's like asking them to choose HTML over TEI. Why? Hyperlinking is a bit different. That is asking them to provide recommendations for something the Internet does not currently have except as xenoforms disguised as applet, imagemap, object, etc tags in HTML. Whereas SGML applications already have plenty of these and it seems prudent to arrive at a set we can all use as SGML legacy moves onto the networks. OTH, wouldn't linktypes for the network have to consider all of the notations if interoperability among framework notation handlers is to be preserved? len Date: Mon, 25 Nov 1996 21:37:42 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: cbullard@HiWAAY.net CC: papresco@calum.csclub.uwaterloo.ca, tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: CSS vs. DSSSL-O [Len Bullard:] | It would seem the first issue would be if designing | XML requires one to also design styles and hyperlinks. | For SGML, those are separate issues traditionally. | Why in XML are they not? You cannot have a high-end delivery vehicle for the Web unless you have 1. Structure 2. Hyperlinking 3. Presentational semantics. These have been our three explicit deliverables since we started this activity. Please read the activity statement. Jon Date: Tue, 26 Nov 1996 07:42:01 -0600 From: Len Bullard To: Jon Bosak CC: papresco@calum.csclub.uwaterloo.ca, tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: CSS vs. DSSSL-O Jon Bosak wrote: > > [Len Bullard:] > > | It would seem the first issue would be if designing > | XML requires one to also design styles and hyperlinks. > | For SGML, those are separate issues traditionally. > | Why in XML are they not? > > You cannot have a high-end delivery vehicle for the Web unless you have > > 1. Structure > > 2. Hyperlinking > > 3. Presentational semantics. Not at issue. Structure has been resolved with some issues remaining that need a Technical Corrigendum for SGML. Hyperlinking is to be discussed next and the presentational semantics are the last item. Ok so far? > These have been our three explicit deliverables since we started this > activity. > > Please read the activity statement. I have read the activity statement. Why is that an obstacle to a reasonable discussion of the questions I am raising? len Date: Tue, 26 Nov 1996 08:22:39 -0800 (PST) From: "Deborah A. Lapeyre" Subject: FPIs To: Murray Altheim cc: Tim Bray , w3c-sgml-wg@w3.org I heard James and I canot refute what he says. But I am one of the voices asking loudly for FPIs. I don't ask that anything be done with their little insides (semantically, syntactically, or anything else you can think of). I would be content if they could be viewed as one long silly-looking string that we use in a character for character match. I would not find that match hard to do. Therefore I'm assuming that it must be the catalog part that is difficult. Is it the SGML Open catalog that is the problem? That catalog was intended to be interchageable and complete (well...), not simple. Would a simplification of it help? And (for those of us whose dragon-book years are very long ago and far away) what is the difficult part? --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: Tue, 26 Nov 1996 13:15:17 -0500 To: w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: Re: FPIs On 26-NOV-1996 dlapeyre@mulberrytech.com wrote: >I heard James and I canot refute what he says. But I am one of the >voices asking loudly for FPIs. I don't ask that anything be done with >their little insides (semantically, syntactically, or anything else you >can think of). I would be content if they could be viewed as >one long silly-looking string that we use in a character for character >match. I concur, with one extra request that shouldn't be difficult. When the "F"PI is presented to the application or entity manager, it should be compressed IAW 8879: "A minimum literal is interpreted by ignoring RS and replacing a sequence of one or more RE and/or SPACE characters with a single SPACE, except that such a sequence is ignored if it occurs at the start or end of the minimum literal." I believe this is the same algorithm used for COLLAPSE handling of mixed- content elements. (NB: This is my first attempt with a new mail handler. Pls forgive if I screw up the formatting or whatever. -D.P.) Dave Peterson SGMLWorks! davep@acm.org From: dgd@cs.bu.edu (David Durand) Date: Tue, 26 Nov 1996 13:41:04 -0500 (EST) To: davep@acm.org, w3c-sgml-wg@w3.org Subject: Re: FPIs I'll also re-iterate that we could simply prepare to use the URN approach in defining XML. We would be making a conscious decision not to implement FPI resolution, but would also be enabling FPI use once the URN infrastructure is in place. This would let us get the advantages of FPIs while deferring to the internet standards bodies. Of course I wouldn't complain about just including FPIs -- we don't need to accept the catalog mechanism if it takes 5000 lines of code to implement. -- David I am not a number, I am an undefined character! From: lee@sq.com Date: Tue, 26 Nov 96 15:32:23 EST To: dlapeyre@mulberrytech.com, murray@spyglass.com Subject: Re: FPIs Cc: tbray@textuality.com, w3c-sgml-wg@w3.org > I would be content if [FPIs] could be viewed as > one long silly-looking string that we use in a character for character > match. The original request (and the 5,00 lines,0 I think) included Formal System Identifiers. Having said that, if you don't care what's inside the FPI, it might as well be any string. So it could be a string that looks like a URL. So it could be a URL. In particular, it could be the same string as the URL used for the system identifier for the DTD. In other words, another way to look at it is that XML _only_ has public identifiers, but all XML public identifiers are actually called SYSTEM rather than PUBLIC, and take the form of URLs. The only thing in practice today that an FPI gives you is that you can compare it to one in a printed standard... anything downloaded over the net is likely to differ from the formally published text anyway, and there is not yet any way to resolve FPIs automatically that does not involve writing a letter to the GCA or ISO... If you want the kind of indirection a catalog gives you, you can use Apache 1.1 and put Redirect or Alias commands in an .htaccess file. For non-Internet use, I don't see FPIs as an issue right now. Lee Date: Tue, 26 Nov 1996 12:45:58 -0800 (PST) From: Terry Allen To: bosak@atlantic-83.eng.sun.com, cbullard@HiWAAY.net Subject: Re: CSS vs. DSSSL-O Cc: papresco@calum.csclub.uwaterloo.ca, tbray@textuality.com, w3c-sgml-wg@w3.org Jon cites the (charter? activity statement?): >
  • The specification of extensions and public text needed to make DSSSL (SGML's stylesheet language) work in an Internet context. and in conversation last week with various folks about what is implied by sending a document without a DTD, it was pointed out to me that one could convey one's semantics through a style sheet or an applet that interprets the documents (you might prefer to send an applet for something like an airline schedule marked up in XML). Is it an implication of the
  • above, and the sentiment expressed in this thread that dsssl-o is XML's style sheet language (and not CSS) that an applet that handles the putative airline schedule exports either a dsssl-o style sheet or a FOT to the rendering application? (Just asking.) Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Date: Tue, 26 Nov 1996 15:46:48 -0500 To: lee@sq.com From: murray@spyglass.com (Murray Altheim) Subject: Re: FPIs Cc: dlapeyre@mulberrytech.com, tbray@textuality.com, w3c-sgml-wg@w3.org >The only thing in practice today that an FPI gives you is that you can >compare it to one in a printed standard... anything downloaded over the >net is likely to differ from the formally published text anyway, and there >is not yet any way to resolve FPIs automatically that does not involve >writing a letter to the GCA or ISO... Broken practice isn't a reason not to design something correctly in the first place. Had URIs preceded HTML, we'd see a very different Web today. >If you want the kind of indirection a catalog gives you, you can use >Apache 1.1 and put Redirect or Alias commands in an .htaccess file. This may work, but would you advocate this to a Fortune 500 as a solution? >For non-Internet use, I don't see FPIs as an issue right now. Agreed. But I'm assuming we'll want to use XML on the Internet, where FPIs will be, if not essential, at least very useful. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." Date: Tue, 26 Nov 1996 15:51:36 -0800 (PST) From: Bill Smith Subject: Re: CSS vs. DSSSL-O To: w3c-sgml-wg@w3.org Terry Allen wrote: > Is it an implication of the
  • above, and the sentiment > expressed in this thread that dsssl-o is XML's style sheet > language (and not CSS) that an applet that handles the putative > airline schedule exports either a dsssl-o style sheet or a FOT > to the rendering application? (Just asking.) Based on the WG's charter, dsssl-o is XML's style sheet language. I for one wouldn't mind discussing the possibility of one or more alternatives - like CSS. However, any discussion on style sheets should occur after we handle link syntax and semantics. HTML already has style sheets, broken though they may be. If we waste time arguing about CSS and dsssl now, we won't make progress on linking and that is an area where HTML is clearly lacking. Beyond allowing extensible structure and markup, XML can differentiate itself from HTML by providing richer link semantics. We can do this in time for WWW6 as long as we remain focussed. I'd like to see us move into the "link phase" of our discussions. We have the right people assembled to rationally discuss this issue. We have demonstrated that we can have meaningful discussions, argue points strongly, (reasonably) reach consensus, remain (relatively) focussed, and perhaps most important, effectively communicate our decisions outside this WG. Let's keep up the good work by remaining focussed on the next task - link syntax and semantics. We have an opportunity to make a significant contribution to the Web community at large by establishing some simple, well-defined constructs for hypertext links in XML. Style sheets come later. Date: Tue, 26 Nov 1996 19:41:28 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Pro-FPI manifesto. (Actually a one-character correction to get FPIs for free) I think I had mailer problems. So this is a re-transmission. -- David Tim's invitation for manifestoes was too good to pass up, for the manifestly inclined... The W3C has an ongoing URN process, that is now (finally) bearing fruit. There are IETF drafts in place for syntax and an initial resolution mechanism. FPIs will be "grandfathered" into the URN namespace, so that every FPI will have an equivalent URN, and if we get the resolutin services working within the framework, they will be resolvable over the web. So, my new suggestion for FPIs is that we not worry about the special SGMl syntax for them, but correct the String "URL" in the XML document to read "URI". A URI is a Universal Resource Identifier (URL _or_ URN). The IETF is recasting specs to refer to URI's instead of URLs anyway, in anticipation of URNs becoming real. Now we can have FPIs if we want, with no special syntax requirements, and with no additional work for implementors who implement URN resolution services in their applications. Easy, no? -- 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: Tue, 26 Nov 1996 19:41:13 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: CSS vs. DSSSL-O I think I had mailer problems. So this is a re-transmission. -- David At 5:23 PM 11/23/96, papresco@calum.csclub.uwaterloo.ca wrote: >At 09:51 PM 11/22/96 -0800, Tim Bray wrote: >Perhaps we could attack through Java. It sounds bizarre, but right now Java >is so heavily hyped that Java-anything is considered good. Ergo Netscape has >declared "JavaScript Stylesheets". JavaScript is evil voodoo, but Java is >actually not half bad. I am envisioning something we could call "Java >stylesheets". It would be a DSSSL-like transformation that works on the >source object and builds a screen display. The style sheet would be >delivered as Java byte codes. The byte codes would have to have access to a >much more powerful display layout API than they do now (fonts, layout, >etc...much like DSSSL flow objects). An interesting aspect of this is that XML is actually a much nicer way to pass parameters to applets: markup can be pre-compiled into an attributed tree, that can (optionally) be verified for structure, and then fed as input to the applet. So whatever XML styles are, they should have a way to specify that an element should have its parse-tree passed to an embedded application (applet). Since we have a well-defined notion of what information the parser must pass to an application, we can do a Java language binding, and a Scheme/DSSSL language binding as well... (In the case of Scheme-in-Java these might be identical). > a) Scheme has a stigma (though I *really* like it, I can imagine Marc >Andreesen snickering) > b) DSSSL will have a scheme-stigma. > c) DSSSL without scheme is, in my opinion, underpowered, just as CSS is >underpowered. > d) Java bytecodes put everyone on fairly level ground. > e) Java interpreters are already widely deployed and getting more and more >efficient. > e) maybe once the document UI is controlled in Java there are some >interesting interactive things we can do (expandable table of contents, for >instance) > >Once Java-style sheets are implemented, CSS, DSSSL-O and full DSSSL could >all be built on top of them, either by compilation *to* Java byte codes, or >by interpretation *by* Java bytecodes. The only problem I see with this is that there are good reasons to have declarative style sheets rather than only xecutable style sheets. There is also a real performance and/or deployment hit for distributing formatters over the web. Either we get large downloads (which Netscape caching strategies do not help with), or we have to somehow get the formatters onto people's disks. Also, I think the politics of defining an API that goes that far down into a browser's guts will be pretty difficult. We definitely need to do whatever we can to make XML and CSS work together. I think the fundamental idea of CSS (cascading) is so misguided and retarded as to be comical, but that doesn't change the facts that it is being implemented by the two gorillas -- so we better be able to work within that framework, as well as within a smarter one. I don't think we can afford to be wrong if people choosse to patch CSS rather than discard it once the limitations become clear. In fact, given the history of HTML, I would expect that CSS will be hard to kill. >Perhaps it is too early in our understanding of online style >sheets to choose *any* standardized style sheet syntax. Look at the >complexity of DSSSL-Print. It is only after *centuries* of typographic >development that we knew what the right flow objects and characteristics to >provide were. Probably so, but we have to try anyway, I think. And at least the basic structures of typography are not as divergent from print as the video and multimedia stuff... I think we can be useful, even if we are not 100% right. 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, 26 Nov 1996 19:41:23 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Small change I think I had mailer problems. So this is a re-transmission. -- David Since we're making the mistake of keeping the non-overlapping attribute value restriction, we need to add an -XML- prefix to the whitespace attributes (So that a parser can treat them the same as user defined attributes without polluting the namespace). -- 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: Tue, 26 Nov 1996 16:45:38 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org Subject: Our current discussion schedule For those of you who don't have access to the Web and can't see our public W3C SGML activity page, and who therefore may be confused by the recent discussion of CSS vs. DSSSL and may be thinking that we are uncertain about what we are supposed to be doing now, I quote the relevant section below. (The corresponding section that I quoted in an earlier message was from the original activity page posted last June. The excerpt below is from our current activity page, which is dated October 4.) Jon ========================================================================

    Activities within the W3C

    The W3C has formed an SGML Working Group made up of SGML experts and an SGML Editorial Review Board made up of SGML experts who also have special standards and implementation experience to coordinate with existing related standards efforts and to provide specifications where needed to form a complete SGML Internet solution.

    Specific deliverables under development by the SGML WG/ERB include:

    • A specification for a simplified version of SGML suitable for Internet applications. Target delivery: draft by the SGML 96 Conference (November 1996).
    • A specification of standard hypertext mechanisms for SGML applications. Target delivery: draft by the WWW6 Conference (April 1997).
    • Public text and extensions needed to apply the DSSSL stylesheet language (ISO/IEC 10179) to Web browsers. Target delivery: draft by the SGML 97 Conference (December 1997).
    Date: Tue, 26 Nov 1996 17:01:35 -0800 (PST) From: Terry Allen To: dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: Pro-FPI manifesto. (Actually a one-character correction to get FPIs for free) David Durand writes: > So, my new suggestion for FPIs is that we not worry about the special SGMl syntax for them, but correct the String "URL" in the XML document to read "URI" That was my idea too, but it would encompass URCs, and I'm not sure that we want to get into resolution by URCs (bags-o-metadata). One might better point to a URC by an URL or URN. URNs would be PUBLIC, not SYSTEM, I would think. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Date: Tue, 26 Nov 1996 22:10:43 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Pro-FPI manifesto. (Actually a one-character correction to get FPIs for free) At 5:01 PM 11/26/96, Terry Allen wrote: >That was my idea too, but it would encompass URCs, and I'm not >sure that we want to get into resolution by URCs (bags-o-metadata). >One might better point to a URC by an URL or URN. I agree about URCs being fishy... still, we're only on the hook if someone thinks they've solved the URC problem (which is a small worry for the near future). >URNs would be PUBLIC, not SYSTEM, I would think. Well, they ought to be, but my point was that the sentiment against PUBLIC could carry the day and we will still be alright (assuming that the URN: prefix goes through). I mean from an SGML point of view URNs are SYSTEM (because they're not native to SGML itself). I tend to agree that encoding FPIs as URNs in a SYSTEM identifier is kinda weird, but then the whole web is kinda weird... >Regards, > Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com >"In going on with these experiments, how many pretty systems do we build, > which we soon find outselves obliged to destroy?" - Benjamin Franklin > A Davenport Group Sponsor: http://www.ora.com/davenport/index.html _________________________________________ 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, 26 Nov 1996 21:50:41 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Quran test file [Len Bullard:] | BTW, for the Quran test file, is this right? | | | | | | | | | | | | | Can't be; you have two content models for v and vn. Interestingly (in light of a previous discussion about implied DTDs), the actual DTD for this example was one that I made to cover all three "testaments" in the sample set -- the King James Bible, the Quran, and the Book of Mormon. This was a fundamentally misguided thing to do, and when I teach beginning SGML concepts I use the story of how I came to do this to show students the kinds of problems that come up in DTD design and the kinds of silly hacks that people make in attempting to deal with them. The actual "union DTD" that I came up with back in 1992 was this: As I said, this is instructive chiefly as a bad example; I get a good exercise out of asking students what would be wrong in an authoring environment if we allowed these definitions of "book" and "sura" in the same DTD. (Another indicator of its awfulness is that I never got around to using the element "i", which I had intended to use in the KJV and then abandoned when I realized how much work would be involved.) But it is interesting in connection with the earlier thread that the actual DTD that was used for this set is one that no mechanical process on earth would produce from the instances. | Also, see verse 78 of The Cow. Arc should be are. Thanks, I'll try to remember to fix that if I ever get around to revising the set. You should have seen the source for this thing; it took me several days of going over it with a specialized spell checker to get it to the point where you see it now. | That one was easy. Good reading too. | The files are a bit big for test files though. | IDEAS handles them without a burp but the size | is overkill for testing. On the contrary, the length of these examples is exactly why I put them out there. XML makes it trivially easy to construct and process small examples. I want to see what happens when prototype applications get fed something the size of the ot.xml file. Jon Date: Tue, 26 Nov 1996 22:54: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: CSS vs. DSSSL-O [Len Bullard:] | [...] I have very publicly stated support for DSSSL. | But public announcements aside, I am looking for a technically | compelling reason that this is the focus. IOW, if the CSS | supporters have a case to make, they should make it. Otherwise, | DSSSL-O is a fait accompli of a work item not a decision arrived | at as a result of open technical debate. If by the conference | cited, the CSS developers can also show how they would support XML | using their approach, doesn't that strengthen XML? I don't | know about particular XML applications (e.g, document types), | but for some it must certainly be reasonable to use CSS. If | that statement is technically incorrect, please tell me why. Of course it's not technically incorrect. One of the reasons for using XML is to enable every imaginable variety of output treatments. You are perfectly free to use whatever output process specification you want. FOSI, for example. But it is not the stated objective of the group to produce a Web FOSI deliverable. It is a stated objective of the group to produce a Web DSSSL deliverable. It has been a stated objective since the discussions with W3C leadership that led to the creation of the group, since the decision to form the group, since the invitations to participate in the group, and in every public statement of what the group is intended to do. I have already pointed out that every version of the W3C SGML activity statement has listed the specification of DSSSL for the Web as a key deliverable for this activity. I will also remind the WG that most of its members (all of you who were here from the beginning) were invited to participate by a letter that read in part as follows: The working group is organized into a core design team with heavy implementor representation and a somewhat larger advisory group consisting of people qualified to review and comment on the work as it moves forward. The design team has been formed, and I am now in the process of finding the right people for the advisory group. Specifically, I am looking for people who: 1. Agree that we will need an industrial-strength counterpart to the HTML/CSS combination for the future delivery of richly structured, extensible data over the Internet in support of certain types of future high-end Web applications. (This must be distinguished from the use of SGML as an authoring/database format for the Web, which is possible already.) 2. Agree that some subset of SGML combined with some subset of DSSSL represents the best strategy for implementing the higher-level counterpart to the combination of HTML and CSS. 3. Are qualified and willing to advise the design team by reviewing and discussing decisions of the design team and contributing ideas and information to the process. [...] The following items are expected to constitute the major activities of the Web SGML working group: 1. Coordinate with existing efforts to define enabling standards for the delivery of generic SGML on the Web, including: a. The standardization of SGML fragments in SGML Open b. The extension of catalog syntax in SGML Open c. MIMESGML activity in the IETF d. Efforts by vendors to establish an application profile for dsssl-o 2. Identify remaining areas needing standardization to enable the use of generic SGML on the Web and construct the needed specifications. These areas would include, but not be limited to, the following: a. Specification of standard Web semantics for SGML, especially semantics for link behavior that will be treated uniformly by future SGML Web browsers. b. Specification of SGML and DSSSL subsets to define a minimum level of support for Web SGML tools. c. Specification of entity management for SGML objects on the Web. I really don't see how it's possible to be much clearer about what we are supposed to be doing here than I was in that letter. There is obviously nothing to prevent CSS from being used with XML, and there are obviously some people (at least one of whom works closely with me!) who think that this would be a great idea. I am strongly in favor of making the mechanism for linking particular stylesheets with particular documents as general as possible. I am not arguing in favor of doing anything that would make it difficult to construct XML applications that would use CSS stylesheets. But it is *not* a purpose of this activity to foster the use of CSS. It *is* a purpose of this activity to foster the use of DSSSL. If this offends anyone, it's because they haven't bothered to read the statements of purpose that I have taken care to provide regarding this activity. People who find the DSSSL component of the activity unacceptable may wish to consider leaving the group after we finish with the hypertext design phase in April. In the meantime, it's clear that we should avoid becoming sidetracked by the discussion of particular stylesheet methodologies until we have linking completely specified, just as we were careful to avoid the discussion of linking until we had the basic markup syntax specified. I was among the first to go off the track here, for which I apologize. Any further discussion of specific stylesheet formats should be conducted by private mail until the time comes to deal with that subject directly. Jon Date: Wed, 27 Nov 1996 02:27:57 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: FPIs At 03:46 PM 26/11/96 -0500, Murray Altheim wrote: >Broken practice isn't a reason not to design something correctly in the >first place. Had URIs preceded HTML, we'd see a very different Web today. If the Web had waited for the URI problem to get solved, we wouldn't have a Web today. I think the problem of figuring out how to name things properly in the context of a heterogeneous universal network is just too hard, and anyhow orthogonal to XML. On the other hand, a handful of vendors on the floor at SGML'96 were showing off working software with typed multiway multimodal hyperlinks doing things that HTML can currently only dream of. The spirit of XML so far has been to go for the quick kills and pluck the low-hanging fruit. Which in retrospect seems wise; let's stay with it. Which is a long-winded way of saying that I just haven't seen any evidence in the field that FPI's have any *practical* utility other than serving as a rather lengthy and awkward lookup key in a catalog. I think the problem that FPI's purport to try to solve is in fact a real problem, and in fact as soon as there is working technology out there that demonstrably uses FPI's (or some other mechanism) to solve it, we should adopt the proper attitude of gratefulness and steal it. The kind of argument on the WG that would succeed in swinging me (and I suspect a lot of others) toward including FPI's would be a war story along the lines of "here's how we used FPI's to solve important problem X, and here's where you can go and look at the software that does it." Of course, the software function would have to be something that you could do in a lightweight, compact implementation. Cheers from Melbourne, Oz. - Tim Date: Wed, 27 Nov 1996 08:49:47 -0500 To: bosak@atlantic-83.eng.sun.com (Jon Bosak), w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: CSS vs. DSSSL-O At 10:54 PM 11/26/96 -0800, Jon Bosak wrote: >Of course it's not technically incorrect. One of the reasons for >using XML is to enable every imaginable variety of output treatments. >You are perfectly free to use whatever output process specification >you want. I think Len is asking if it is technically or politically valid to *require* conforming XML browsers to support DSSSL. If that is not our goal, then he probably does not mind that we will refine DSSSL-O, "while we are all together." I think that the quote that has us a little confused is: "Personally, I think that the only strategy that makes sense here is the full frontal attack: enable dsssl-o processing through plug-ins or applets and insist that real XML browsers are browsers with dsssl-o capabilities. " Do you mean "insist as a set of users that this is what we want" or "insist as a standards group that this is what is conforming?" Paul Prescod Date: Wed, 27 Nov 1996 07:48:34 -0600 From: Len Bullard To: Jon Bosak CC: w3c-sgml-wg@w3.org Subject: Re: Quran test file Jon Bosak wrote: > > [Len Bullard:] > > | BTW, for the Quran test file, is this right? > | > Can't be; you have two content models for v and vn. Yep. The stylesheet builder noted that to me and I forgot to take it out of the file on the disk. Duh!! > Interestingly (in light of a previous discussion about implied DTDs), > the actual DTD for this example was one that I made to cover all three > "testaments" in the sample set -- the King James Bible, the Quran, and > the Book of Mormon. This was a fundamentally misguided thing to do, > and when I teach beginning SGML concepts I use the story of how I came > to do this to show students the kinds of problems that come up in DTD > design and the kinds of silly hacks that people make in attempting to > deal with them. Ok. What is the misguided part? I usually don't find it good to write "union" DTDs because I end up adding too much unnecessary markup possibilities to get different structures in the same tree. It's what I don't like about the tag bag structures we get from 38784 legacy. It confuses the user of the editor, fattens the files, and overall, just bloats the information. Since DTDs are pretty easy to write and select in editors, I find it better to keep smaller sets. Of course, most documents I have to use DTDs for are structurally more complex. > The actual "union DTD" that I came up with back in > 1992 was this: Thanks. > But it is interesting in connection with the earlier > thread that the actual DTD that was used for this set is one that no > mechanical process on earth would produce from the instances. Yes. OTH, if we fed several documents to such a process, I wonder what the results would be. > You should have seen the source for this thing; it > took me several days of going over it with a specialized spell checker > to get it to the point where you see it now. Yes. We do a lot of conversion work here where we are asked as a primary requirement to preserve look (?#&#^$^) and create a hypertext. Lockheed also has some very sophisticated automated conversion software in Orlando (ACS). Our experience is that the scanning is in some ways, one of the most mind numbing bits. The technology is certainly much better than it used to be, but 100%, not yet. > On the contrary, the length of these examples is exactly why I put > them out there. XML makes it trivially easy to construct and process > small examples. I want to see what happens when prototype > applications get fed something the size of the ot.xml file. Good idea. IDEAS isn't a prototype, so it works well with the exception of having to comment out the version statement. That's an easy feature to add. On another product, I found the file size was a problem in the 16-bit version and that was good to know. And as I said, good reading. Much better than most of what I see. Thanks again. len Date: Wed, 27 Nov 1996 08:08:27 -0600 From: Len Bullard To: Jon Bosak CC: w3c-sgml-wg@w3.org Subject: Re: CSS vs. DSSSL-O Jon Bosak wrote: > Of course it's not technically incorrect. One of the reasons for > using XML is to enable every imaginable variety of output treatments. > You are perfectly free to use whatever output process specification > you want. Ok. But if I have to write a FOSI for XML, I'm going to take up knitting screen displays instead. > I really don't see how it's possible to be much clearer about what we > are supposed to be doing here than I was in that letter. The intent is clear. The reason is not. Again, I support DSSSL. I think it good to discover and elaborate as the work item proceeds why other approaches may not or are not as effective as the one being worked. > It *is* a > purpose of this activity to foster the use of DSSSL. Ok. The sidebar discussions of CSS will be inevitable, but no recommendations have to be issued for it. David Durand mentions in his post that it may be early to choose a stylesheet language, and the considerable work going into it by W3C members just as the IETF is working on URI/URN/URC pieces. So, where we don't consider parallel work, we have to be clear as to why one is and another is not worked. I certainly accept and welcome the DSSSL work item. My personal opinion is pretty much the same as David's on the issues here. > In the meantime, it's clear > that we should avoid becoming sidetracked by the discussion of > particular stylesheet methodologies until we have linking completely > specified, just as we were careful to avoid the discussion of linking > until we had the basic markup syntax specified. I agree. Because I wasn't involved in the discussion of the decision to stick to the schedule and not do these in parallel, please provide the rationale for that and the means by which hyperlinking is separated from the stylesheet discussion since there are concepts in which the two overlap. How is that separation maintained? That helps us understand what hyperlinking concepts are being worked. In other words, a reply to a question on a design vote by the ERB of "oh don't worry, the stylesheet will handle that" will be unacceptable rationale. len bullard lockheed martin Date: Wed, 27 Nov 1996 08:34:52 -0600 From: Len Bullard To: Tim Bray CC: w3c-sgml-wg@w3.org Subject: Re: FPIs Tim Bray wrote: > The kind of argument on the WG that would succeed in swinging me > (and I suspect a lot of others) toward including FPI's would be a war > story along the lines of "here's how we used FPI's to solve important > problem X, and here's where you can go and look at the software that > does it." Of course, the software function would have to be something > that you could do in a lightweight, compact implementation. I think a concise statement of the problem FPIs are intended to solve and a shorter primer of how they do that would be invaluable as well because otherwise, they really do look like an overbuilt lookup. Because the URC came up in another post, I recall a lot of discussion on the syntax issues of using SGML for that. Many of the arguments were based on parsing problems in SGML, the speed of value-pairs vs hierarchies, etc. 1. Might XML help in the parsing problem of the URC? That isn't a work item here, but I am curious because a lot of work went into the Dublin core, etc. 2. Are the implementation problems of the FPI related to the parsing difficulty, the resolution, interoperation with other resolution components, what? James? (saying it takes 5000 lines doesn't help me understand why it takes 5000 lines). len From: Ken Holman To: "'w3c-sgml'" Subject: RE: FPIs Date: Wed, 27 Nov 1996 10:15:14 -0500 [Tim Bray] >Which is a long-winded way of saying that I just haven't seen any >evidence in the field that FPI's have any *practical* utility other >than serving as a rather lengthy and awkward lookup key in a catalog. >I think the problem that FPI's purport to try to solve is in fact >a real problem, and in fact as soon as there is working technology >out there that demonstrably uses FPI's (or some other mechanism) >to solve it, we should adopt the proper attitude of gratefulness >and steal it. > >The kind of argument on the WG that would succeed in swinging me >(and I suspect a lot of others) toward including FPI's would be a war >story along the lines of "here's how we used FPI's to solve important >problem X, 1) Identifier Uniqueness An FPI is made up of an owner name and an object name. When owner names are unique, the uniqueness of object names is the responsibility of the owner in the owner's object name space. FPI's that begin "-//" are unregisterable and can _never_ be guaranteed to be unique. FPI's that begin "+//" or "ISO" are _obliged_ to have been assigned by a _recognized_ ISO authority: the ISO publication authority, the ISO registration authority, an ISO member body authority or an ISO identified organisation authority. I was very surprised to see that some people at SGML'96 were incorrectly using FPI's that were prefixed "+//" in direct contravention of this rule ... if you see "+//" without a recognized registration authority, do not assume that the identifier is guaranteed to be unique as it has been improperly formed. Two available registered owner name spaces that guarantee uniqueness are ISBN (recognized as an authorized organisation for a long time) and the ISO registration authority (available real soon now!). Microstar's 2 registered owner names begin: +//ISBN 1-55160 and (real soon now) +//ISO/IEC 9070/RA::A00004 In both cases we use additional owner-name components to further identify us and our project, customer, application, whatever. For example: +//ISBN 1-55160::MSL//DTD Presentation Slide Show//EN +//ISBN 1-55160::MSL::CUST-A//DTD Book Test//EN +//ISBN 1-55160::MSL::CUST-B//DTD Book Test//EN Each project can then manage their own object name space as they wish, knowing that whatever they choose they will not interfere with any other project's object name space, nor with any other company's use of public identifiers. I am guaranteed that no other organisation in the world will be legally authorized to use our owner-name, unless we give them part of our extended name space. BTW, we obtained our ISBN Publisher's Prefix by a simple application to our country's ISBN Registration Authority, the National Library of Canada (who were assigned sets of numbers by the International Standard Book Numbering Agency in Berlin). Contact your government for the name of the authority in your country. 2) Identifier Persistence I'm not sure that this is the correct word, as it might be overloaded by now ... but the idea is that given the uniqueness guaranteed in (1), it is now up to the owner to ensure that the object's name lasts forever and is not made ambiguous by identifying something else with the same identifier. 3) Identifier Management When we deliver a project to a customer, the _only_ change required to locate _all_ objects (we try to _never_ use SYSTEM identifiers _anywhere_) is to modify the catalog (and even that can be mitigated as noted below). None of our SGML instances change one iota, and can be marked read-only when delivered (this is so that the customer cannot accidentally change something else when attempting to change only SYSTEM identifiers if the SGML files contained SYSTEM identifiers). Also, how would the customer know where all of the SYSTEM identifiers were in a set of SGML instances? By delivering a system based _entirely_ on PUBLIC identifiers, all external identifiers can be summarized in catalogs. FPI's make an excellent management tool for the delivery of a suite of interconnected SGML files. 4) Identifier Portability If, after delivery with our catalogs, the customer wishes to move the suite of SGML files elsewhere within their system, or change the source of any file of the system, only the catalogs need be changed. The customer need not know how many files share a common resource in order for all references to that resource to be changed. Think of how quickly aged, broken or incompatible HTTP links can be repaired if all links in a suite of files are FPI's, thus fixable with a single change to a catalog. >and here's where you can go and look at the software that >does it." Of course, the software function would have to be something >that you could do in a lightweight, compact implementation. [Debbie Lapeyre] >I would be content if they could be viewed as >one long silly-looking string that we use in a character for character >match. Sounds good enough for me, though there are some very nice aspects of the SGML Open catalog specification to make life easier. The SGML Open catalog convention of resolving relative file path named SYSTEM identifiers as being relative to the location of the SGML Open catalog provides further independence and can reduce the amount of "customisation" required when delivering, or moving, a suite of SGML files. Please add my voice (LOUDLY) to the clamour for supporting FPIs in XML. ....... 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 E-mail: gkholman@CanadaMail.com CANADA KOA-2E0 E-mail: ab945@freenet.carleton.ca -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAjHOimAAAAEEAK47HbDtZZB8hJBk+r9Zh7m7QxdFHTaz/m200QQ7J9XX4QYs h6hsuP6ZqBJXyLdmIVMEwR6Ry6oxjKMd6BRJ8OGScD89eIghgbrpMX+900NxM0x2 v3yWO9ki2gKRPrn4vlCXznnmcmsyke0G02T2LefXbgZHyVSqDSOLy8nwuN7dAAUR tClHLiBLZW4gSG9sbWFuIDxhYjk0NUBmcmVlbmV0LmNhcmxldG9uLmNhPg== =IN3T -----END PGP PUBLIC KEY BLOCK----- Date: Wed, 27 Nov 1996 10:33:35 -0500 To: cbullard@HiWAAY.net, Tim Bray From: Paul Prescod Subject: Simple solution? Pub. Idents. vs URN. Cc: w3c-sgml-wg@w3.org I am going to presume that the "formal" part of FPIs is not really what we care about. If I am wrong, please correct me. At 08:34 AM 11/27/96 -0600, Len Bullard wrote: >I think a concise statement of the problem FPIs are intended to solve >and a shorter primer of how they do that would be invaluable as well >because otherwise, they really do look like an overbuilt lookup. "A public identifier is a name that is intended to be meaningful across systems and different user environments." Goldfarb, p378 "public identifer: A minimum literal that identifies public text." p181 There seems to be a complete overlap of the intended goals of FPIs and URNs. But I think that these two beasts can co-habit. In XML DTDs are optional, and those that need them (I.e., the SGML community, and those that care about validation) use them, and those that don't, needn't. Why can't FPIs be handled in the same way? If we allow either of these syntaxes: then we preserve the essential internet-centricity and usability of XML, but allow the traditional SGML "escape hatch" for people who want to a) redirect to a local copy, b) to use documents off-line or c) use older SGML tools that don't understand URLs. Paul Prescod Date: Wed, 27 Nov 1996 12:54:36 -0500 To: w3c-sgml-wg@w3.org From: Paul Prescod Subject: URNs: Exactly what *is* happening? Many of the people on this list seem to be involved with the URN effort, >from a perusal of the archives (I caught you!). What is the current status of those efforts? This is definately a linking issue, and also related to XML syntax. Paul Prescod Date: Wed, 27 Nov 1996 12:54:34 -0500 To: lee@sq.com, dlapeyre@mulberrytech.com, murray@spyglass.com From: Paul Prescod Subject: Re: FPIs Cc: tbray@textuality.com, w3c-sgml-wg@w3.org At 03:32 PM 11/26/96 EST, lee@sq.com wrote: >In other words, another way to look at it is that XML _only_ has public >identifiers, but all XML public identifiers are actually called SYSTEM >rather than PUBLIC, and take the form of URLs. As long as you are connected to the SYSTEM, the Internet, and it meets your needs, that's fine. But PUBLIC identifiers are not tied to any particular system. This makes them convenient, but perhaps not absolutely required in a system geared towards the web. >If you want the kind of indirection a catalog gives you, you can use >Apache 1.1 and put Redirect or Alias commands in an .htaccess file. But PUBLIC identifiers put that redirection under the control of end-users. There are numerous techniques for doing redirection on the server side. Paul Prescod Date: Wed, 27 Nov 1996 14:03:16 -0500 To: Tim Bray From: murray@spyglass.com (Murray Altheim) Subject: Re: FPIs Cc: w3c-sgml-wg@w3.org >At 03:46 PM 26/11/96 -0500, Murray Altheim wrote: >>Broken practice isn't a reason not to design something correctly in the >>first place. Had URIs preceded HTML, we'd see a very different Web today. > >If the Web had waited for the URI problem to get solved, we wouldn't >have a Web today. I think the problem of figuring out how to name things >properly in the context of a heterogeneous universal network is just >too hard, and anyhow orthogonal to XML. That was not my point. To be sure, it is so difficult a problem that yes, the Web was built exclusive of the solution. But stating something is simply too difficult does not make it go away. And why it's considered orthogonal to XML is beyond me. We wouldn't be having this discussion if it was truly orthogonal. 'Orthogonal' seems to have become a popular way of saying 'I don't want to deal with this.' [...] >The kind of argument on the WG that would succeed in swinging me >(and I suspect a lot of others) toward including FPI's would be a war >story along the lines of "here's how we used FPI's to solve important >problem X, and here's where you can go and look at the software that >does it." Of course, the software function would have to be something >that you could do in a lightweight, compact implementation. I have a rather simple argument, and nothing along the lines of the manifesto you demand (and maybe others are willing to deliver): "I don't want to hard code a SYSTEM identifier in 10,000 documents." Using even relative URLs (which doesn't really solve the problem, and introduces others such as ambiguity) provides no level of indirection, which is required for portability. I just read Jon's plea for movement of discussion back in line with our agenda, so until we revisit this issue (after hyperlinks), I'll shelve this one. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." Date: Wed, 27 Nov 1996 14:38:31 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Simple solution? Pub. Idents. vs URN. At 10:33 AM 11/27/96, Paul Prescod wrote: >I am going to presume that the "formal" part of FPIs is not really what we >care about. If I am wrong, please correct me. True, except insofar as the syntax and structure of FPIs contributes to the core issues of persistence, and global uniqueness. The administrative requirements of "formal" names ensure these as long as you follow the rules when assigning identifiers. >There seems to be a complete overlap of the intended goals of FPIs and URNs. >But I think that these two beasts can co-habit. FPIs will someday be part of URNs (when they become real). > SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml"> > > PUBLIC "ISO .... " >"http://www.textuality.com/boilerplate/OpenHatch.xml"> > >then we preserve the essential internet-centricity and usability of XML, but >allow the traditional SGML "escape hatch" for people who want to This is acceptable, but making the system identifier mandatory is a shame given that it is the _optional_ FPI that is the persistent identifier. I'd be happier if I could stop using URLs the _instant_ it was feasible. Allowing URNs as system IDs seems a way to accomplish that. > a) redirect to a local copy, > b) to use documents off-line or > c) use older SGML tools that don't understand URLs. My XML parser can always implement catalogs by looking for URN syntax in the sytem ID, and doing something sensible. -- 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: Wed, 27 Nov 1996 14:54:15 -0500 To: dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: Simple solution? Pub. Idents. vs URN. At 02:38 PM 11/27/96 -0500, David G. Durand wrote: >>> PUBLIC "ISO .... " >>"http://www.textuality.com/boilerplate/OpenHatch.xml"> >> >>then we preserve the essential internet-centricity and usability of XML, but >>allow the traditional SGML "escape hatch" for people who want to > >This is acceptable, but making the system identifier mandatory is a shame >given that it is the _optional_ FPI that is the persistent identifier. Not all documents will have persistent identifiers. But all documents *will* have locations. (just as all machines do not have domain names, but all machines do have IP addresses) We would give the FPI "dominance" over the SYSTEM identifier, if the XML processor thought it knew how to resolve it. >I'd >be happier if I could stop using URLs the _instant_ it was feasible. >Allowing URNs as system IDs seems a way to accomplish that. There will be a transition period. Don't you find you occaisionally still have to type IP addresses out, or see them pop up in your browser? How do you decide when it is "feasible?" And, more important, why not begin putting persistent names in your documents now, with the understanding that the technology to seamlessly handle them is coming. I think it is a good idea to provide a direct pointer to the real object as a backup, anyhow. I suspect that URN resolvers will break down sometimes... > My XML parser can always implement catalogs by looking for URN syntax in >the sytem ID, and doing something sensible. As long as you don't want to use those documents with next year's batch of XML browsers, which will not understand URN syntax (unless we intend to preemptively standardize it). Paul Prescod Date: Wed, 27 Nov 1996 14:46:22 -0500 To: murray@spyglass.com (Murray Altheim), Tim Bray From: Paul Prescod Subject: Re: FPIs Cc: w3c-sgml-wg@w3.org At 02:03 PM 11/27/96 -0500, Murray Altheim wrote: >I have a rather simple argument, and nothing along the lines of the >manifesto you demand (and maybe others are willing to deliver): > > "I don't want to hard code a SYSTEM identifier in 10,000 documents." > >Using even relative URLs (which doesn't really solve the problem, and >introduces others such as ambiguity) provides no level of indirection, >which is required for portability. Indirection could be (and should be) provided for in the markup. Once we get hyperlinking working, couldn't you embed an XML fragment that is referenced in an XML document at another site in another character set? >I just read Jon's plea for movement of discussion back in line with our >agenda, so until we revisit this issue (after hyperlinks), I'll shelve this >one. Isn't this hyperlinks? A syntax for objects to embed other objects sounds like linking to me. Paul Prescod Date: Wed, 27 Nov 1996 15:10:50 -0500 To: Ken Holman From: "Keith M. Corbett" Subject: RE: FPIs Cc: "'w3c-sgml'" At 10:15 AM 11/27/96 -0500, Ken Holman wrote: >The SGML Open catalog convention of resolving relative file path named >SYSTEM identifiers as being relative to the location of the SGML Open >catalog provides further independence and can reduce the amount of >"customisation" required when delivering, or moving, a suite of SGML >files. Yes! it's one of those simple ideas that makes a huge difference. Jo WebPage will be impressed when she sees a working entity resolution mechanism that supports indirection. Some of the SP extensions (CATALOG and DELEGATE) are particularly useful for managing multiple "interchange packages". >Please add my voice (LOUDLY) to the clamour for supporting FPIs in XML. And mine. /kmc To: w3c-sgml-wg@w3.org Subject: Re: CSS vs. DSSSL-O Date: Wed, 27 Nov 1996 12:02:59 -0800 From: Joe English I think we should also consider using architectural forms for specifying presentation for XML documents. A simple "XML online display architecture" -- most likely based on HTML -- would be sufficient for many user applications, and would probably be significantly easier than either DSSSL or CSS. It would be easier for implementors: the display engine would only need to deal with a single architecture (no harder than writing an HTML browser), and an architecture engine only adds a little more work. (The architecture engine doesn't even have to be based on the AFDR; indeed, in the absense of a DTD the AFDR is probably not workable.) It would be easier for users: mapping DTDs to an architecture is much simpler than writing a DSSSL stylesheet, and possibly simpler than CSS too. It would be more work for us though: we'd need to define the architecture, and possibly a new mechanism for architectural transformation. (Then again maybe not; the former could be based on HTML, and the latter could be a subset of the AFDR. This might not take any more work than defining a DSSSL application profile or modifying CSS to support arbitrary document types would.) --Joe English jenglish@crl.com Date: Wed, 27 Nov 1996 13:29:08 -0800 (PST) From: "Deborah A. Lapeyre" Subject: Re: FPIs To: Paul Prescod cc: lee@sq.com, murray@spyglass.com, tbray@textuality.com, w3c-sgml-wg@w3.org On Wed, 27 Nov 1996, Paul Prescod wrote: > But PUBLIC identifiers put that redirection under the control of end-users. > There are numerous techniques for doing redirection on the server side. And that is why they are critical to me. Not that there may be lookup but that there must be and on the client side. But perhaps that is exactly what we are trying to avoid. A URL is all on the front end. An FPI is by definition NOT on the front end and guarantees indirection. Are we trying to forbid indirection and force front-endedness? Is that the objection? P.S. Because of ownership, accidental name duplication is very easy to avoid. Both registered and unregistered (the 99% case) provide simple but very real duplication protection. (It is easy to screw up your own stuff but very hard to screw up someone elses if you follow the rules at all.) Date: Wed, 27 Nov 1996 13:51:50 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: MIME type for XML Well, it's time to start the IANA registration process for text/xml. The first step is to send a message to the discussion group that reviews proposals for new media types. My previous experience with the registration of media types is zero, so I need the knowledgeable members of the WG to help out here. According to draft-ietf-822ext-mime-reg-03, rfc1590, and rfc1521, the message that begins the discussion should look something like the one I've appended below. Please review and comment if you are familiar with this process. Jon ======================================================================== To: ietf-types@cs.utk.edu Subject: Registration of MIME media type text/xml MIME media type name: text MIME subtype name: xml Required parameters: none Optional parameters: charset Encoding considerations: the primary encodings are UTF-8 and UCS-2, but other common encoding schemes such as SJIS are also allowed. UTF-8 is the default. Security considerations: the security considerations associated with text/plain apply. Interoperability considerations: the interoperability considerations associated with text/plain apply. Published specification: Extensible Markup Language (XML), W3C Working Draft 14-Nov-96 (http://www.w3.org/pub/WWW/TR/WD-xml-961114.html; also ftp://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml.ps.gz, etc.) Applications which use this media type: any application that uses extensible, structured, validatable text defined by the published specification. Additional information: Magic number(s): none File extension(s): xml Macintosh File Type Code(s): none Person & email address to contact for further information: Jon Bosak, jon.bosak@sun.com Intended usage: COMMON Authors/Change controllers: Tim Bray, tbray@textuality.com C. M. Sperberg-McQueen, U35395@UICVM.UIC.EDU From: lee@sq.com Date: Wed, 27 Nov 96 17:33:42 EST To: w3c-sgml-wg@w3.org Subject: Re: FPIs Debbie wrote: > A URL is all on the front end. An FPI is > by definition NOT on the front end and guarantees indirection. > Are we trying to forbid indirection and force front-endedness? > Is that the objection? You can get client-side indirection in some areas with and this does not require further extension. Unfortunately, & and % are not recognised in SGML system identifiers,... [they're system data, defined as character data, which in turn is defined as data character*, where data character is defined as SGML character, which in turn is defined as (why would anyone want to simplify SGML??) markup character | DATACHAR, where markup character is name character, function character or DELIMCHAR, where name character is name start character | Digit | LCMNMCHAR | UCNMCHAR, and a .... aaargh! But at any rate it turns out that entities aren't expanded in them. ] Therefore you can't use this technique for the DTD or for entity sets included in the DTD. None the less, you can do something just like an SGML open catalog in XML right now today: %Catalog; %Latin1; ]> ..... Now put the real URL for Latin1, if you need to override it, in catalog.sgml, and you have the indirection that Murray Altheim mentioned. Panorama lets the local copy of the SGML OPEN CATALOG file override the copy on the remote server (assuming the documents are on a remote server), and the mechanism I have described does not address that. Power Users may have to wait for XML 2. Lee From: lee@sq.com Date: Wed, 27 Nov 96 17:35:47 EST To: w3c-sgml-wg@w3.org Subject: Re: MIME type for XML This might go better if there was a magic number -- i.e. if there was a way of determining that a file was an XML file by inspecting the first few bytes. To: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org Subject: Re: MIME type for XML I'm glad you're thinking of this, Jon, but isn't it premature to register the MIME type before the spec is finished? If a MIME type is needed for demos, let's use text/x-xml until both linking and style sheets are settled. It would be reasonable for the recipients of the request to ask "what about security considerations for linking and style sheets?", to which we perforce have no answer yet. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Date: Wed, 27 Nov 1996 17:43:50 -0600 From: Len Bullard To: Paul Prescod CC: Murray Altheim , Tim Bray , w3c-sgml-wg@w3.org Subject: Re: FPIs Paul Prescod wrote: > > At 02:03 PM 11/27/96 -0500, Murray Altheim wrote: > >I just read Jon's plea for movement of discussion back in line with our > >agenda, so until we revisit this issue (after hyperlinks), I'll shelve this > >one. > > Isn't this hyperlinks? A syntax for objects to embed other objects sounds > like linking to me. Me too. Could be issue number one. BTW, when the syntax phase started, an extensive set of proposal/questions was posted. Will that be done for this phase, or are we winging it? len bullard Date: Wed, 27 Nov 1996 16:32:13 -0800 (PST) From: Terry Allen To: w3c-sgml-wg@w3.org Subject: Request for charset clarification This is solely a request for clarification; private responses are fine. What does [2] Character include that [3] BaseChar excludes? Or, what is a short description in plain language of BaseChar? Am I right in imagining that unassigned code points are excluded from BaseChar? What is a correct SGML declaration for XML? Repeat: this is solely a request for clarification; private responses are fine. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Date: Wed, 27 Nov 1996 18:07:20 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Links and stylesheets [Len Bullard:] | Because I wasn't involved in the discussion of the decision to stick | to the schedule and not do these in parallel, please provide the | rationale for that Because we can't do everything all at once. | and the means by which hyperlinking is separated | from the stylesheet discussion since there are concepts in which the | two overlap. How is that separation maintained? By providing a general link mechanism that points to one or more stylesheets and says "hey, these are stylesheets". We will have a link mechanism that can point to multiple targets (or we're just screwing around, in my opinion), and I don't know any reason a priori why a document couldn't point to stylesheets of several different types -- four FOSI, three dsssl-o, two CSS, and a partridge in a pear tree -- or why, if the app can handle it, it couldn't put up a menu and let the user choose which one to apply. The tricky part is whether the behavior specifications go in the stylesheet language or not. As you rightly say, | a reply to a question on a design vote by the ERB of "oh don't worry, | the stylesheet will handle that" will be unacceptable rationale and I think that it's in the area of behavioral specifications that this kind of question will arise. By "behavior" I mean, for example, the specification that this particular link right here will pop up a single scrollable child window that contains just the content of the element pointed to in the target document, while that other five-ended link over there will pop up five tiled areas in my current view port each of which allows me to view the entire document containing the element pointed to. Or whatever. I believe that there are basically two ways to provide for such specifications: you either consider them to be part of the stylesheet (the way that DynaText does it) or you provide some kind of architectural form mechanism that allows the behavior to be attached to the link element. Deciding which way to go will indeed involve us in some discussion of stylesheets, but the goal here is to keep ourselves sane by getting into this area as little as possible and as late as possible. In today's ERB conference, we decided to divide Phase II (hypertext) into three subphases: 1. Addressing 2. Typing 3. Behavior The first phase of this effort has shown us the virtue of putting off the hardest questions until the end: you understand more by the time you get there. It is hoped that in the process of solving the link addressing and link typing problems we will learn enough to do the right thing when it comes time to deal with behavior. Jon Date: Wed, 27 Nov 1996 18:26:22 -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: FPIs If I can find time over the weekend I will (with my Chairman hat off and my Sun Representative hat on) describe the application of FPIs that we are putting in place at Sun for managing links in Solaris documentation, and then you will see why I agree strongly with Ken Holman that FPIs are something that we should have in XML. For the moment, however, I would like to go slightly beyond Ken's position by quibbling with this statement from his excellent post on the subject: | FPI's that begin "-//" are unregisterable and can _never_ be guaranteed | to be unique. This may be true from the wording of the standards, but I maintain that it's not actually the case in practice. For example, we are adopting the convention for SunSoft documents that they are all assigned unique FPIs that begin "-//SUN::SUNSOFT//..." The standards may not guarantee you that such an identifier is unique, but Sun can guarantee you a couple of other things: 1. Our document check-in system will not allow two documents to be created with the same FPI, and 2. If you start creating FPIs that begin "-//SUN::SUNSOFT" then you can count on spending the next few years of your life in court with our trademark lawyers. So in reality, even unregistered FPIs can function as unique and persistent names. Jon Date: Wed, 27 Nov 96 20:00:39 CST From: Michael Sperberg-McQueen Subject: Re: Request for charset clarification To: W3C SGML Working Group On Wed, 27 Nov 1996 19:34:42 -0500 Terry Allen said: >What does [2] Character include that [3] BaseChar excludes? >Or, what is a short description in plain language of BaseChar? >Am I right in imagining that unassigned code points are >excluded from BaseChar? What is a correct SGML declaration >for XML? You stress that your query is purely for information and that private replies are fine, but since I can't imagine anyone not being fascinated by character-set issues, I'll reply to the list ... BaseChar is, very very roughly, the set of letters without diacritics, or, more precisely -- but not *wholly* precisely since I don't have the Unicode manual at home and have not memorized its terminology of character classification --, the set of alphabetics minus the set of combining forms. (Since the set subtraction was done by hand rather than by dbms manipulation of the Unicode data file, it needs checking. But the intent was Alpha \ Combining.) So 3 BaseChar excludes several things included in 2 Character: (a) punctuation, (b) numerals both decimal and others -- it's startling to realize Unicode has two sets of 'characters' devoted to Roman numerals in upper and lower case (looks like a serious case of legacy compatibility, but what legacy system has characters for i, ii, iii, iv, v, ...?), (c) ideographs, (d) combining characters, (e) various special-purpose things one can read about in the Unicode book, (f) code points unassigned in the current version of ISO 10646/Unicode, and (g) other stuff I have surely forgotten. A correct SGML declaration for XML ought to use the extended naming rules to specify name characters and name-start characters; it should also assign case properly to those characters which have case. (Bleagh.) There may be a canned declaration with the desired effect already in existence; I don't know. The one in the version of 14 November is, as has been pointed out variously, in error, since it declares ASCII, not 10646, as the document character set. (It got included because it was the one which actually worked on Jon's machine, but that was because he has an ASCII machine rather than a Unicode machine.) What an SGML declaration should do about the unassigned code points, I don't know. Is this where, after all this time, I actually get to (? have to?) learn what NONSGML and SHUNCHAR are supposed to mean? If anyone with an interest in Unicode is willing to confirm that my translation of the Unicode recommendations for identifier formation into SGML terms actually makes sense, I'd be very glad. In particular, I changed the way combining characters were used, in a way which may be harmless, but which won't be harmless if combining characters really have to be legal in identifiers after digits and other characters not in BaseChar. While I'm on this general topic, may I ask anyone still reading this if you can recommend a good description of the character encoding model which I gather WG8 has now formulated and accepted? I hear people saying things about the SGML character-set declarations (e.g. that they have nothing to do with the way characters are represented in the document being parsed) which I don't believe I ever read in 8879, and I'd like a chance to catch up. I've looked on the WG8 server and Charles Goldfarb's server, without seeing anything that looked promising. Can anyone help me out on this? Many thanks. -C. M. Sperberg-McQueen Date: Wed, 27 Nov 1996 21:54:33 -0500 To: w3c-sgml-wg@w3.org From: Paul Prescod Subject: SGML and XML Could someone please summarize the situation with the SGML TC that is supposed to make our lives easier for creating XML? What XML restrictions will be loosened? I am particularly interested in the whitespace handling. Are the current XML rules going to be revamped, or just made more strictly compliant. Paul Prescod Date: Wed, 27 Nov 1996 22:25:00 -0500 To: w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: Re: Request for charset clarification Michael Sperberg-McQueen wrote: >What an SGML declaration should do about the unassigned code points, I >don't know. Is this where, after all this time, I actually get to (? >have to?) learn what NONSGML and SHUNCHAR are supposed to mean? Don't sweat SHUNCHAR; it doesn't really make sense--definitely doesn't make sense in the new model. I predict it'll disappear. NONSGML applies to character numbers (the numerals that occur within numeric character references), not characters. Non-SGML character numbers are those that are marked UNUSED in the document character set parameter of the SGML declaration. They may be used in numeric character references, but what character they represent must be communicated to the system using some system-dependent means outside of the document. >While I'm on this general topic, may I ask anyone still reading this if >you can recommend a good description of the character encoding model >which I gather WG8 has now formulated and accepted? I hear people >saying things about the SGML character-set declarations (e.g. that they >have nothing to do with the way characters are represented in the >document being parsed) which I don't believe I ever read in 8879, and >I'd like a chance to catch up. I've looked on the WG8 server and >Charles Goldfarb's server, without seeing anything that looked >promising. Can anyone help me out on this? Many thanks. See my paper "The SGML Character Model", in the SGML '96 Conference Proceedings, pp 681ff. Basically: The point of view to take is that an SGML parser is, in the abstract, processing a stream of abstract characters--which are of necessity represented somehow in a computer system, but SGML does not prescribe how they must be represented. The document character set maps abstract characters to integers so that the parser will know what character intended by a numeric character reference. In the process, the characters to which numbers are assigned become "SGML characters", the characters that are permitted in the document. Other numbers are specified non-SGML; they can be used in numeric character references but what character they represent is not described in the document. The document character set *may* describe the representation of characters at the interface of the entity manager and parser--or they may use some other representation (possibly hard-wired). There are pros and cons to both implementation strategies. The document character set *may* also describe the storage representation used to store the data from which entities are assembled by the entity manager. Or the entity manager may be told by the storage system how it is representing characters. Not-to-smart entity managers may not be able to handle more than one storage representation, or may not be able to handle a representation other than that defined by the document character set. Hope this helps Dave Peterson SGMLWorks! davep@acm.org Date: Wed, 27 Nov 1996 22:11:40 -0600 From: Len Bullard To: Jon Bosak CC: w3c-sgml-wg@w3.org Subject: Re: Links and stylesheets Jon Bosak wrote: > > [Len Bullard:] > > | Because I wasn't involved in the discussion of the decision to stick > | to the schedule and not do these in parallel, please provide the > | rationale for that > > Because we can't do everything all at once. hehe. So much for creation by "Be!" > By providing a general link mechanism that points to one or more > stylesheets and says "hey, these are stylesheets". We will have a > link mechanism that can point to multiple targets (or we're just > screwing around, in my opinion), and I don't know any reason a priori > why a document couldn't point to stylesheets of several different > types negotiation? > The tricky part is whether the behavior specifications go in the > stylesheet language or not. As you rightly say, > > | a reply to a question on a design vote by the ERB of "oh don't worry, > | the stylesheet will handle that" will be unacceptable rationale > > and I think that it's in the area of behavioral specifications that > this kind of question will arise. By "behavior" I mean, for example, > the specification that this particular link right here will pop up a > single scrollable child window that contains just the content of the > element pointed to in the target document, while that other five-ended > link over there will pop up five tiled areas in my current view port > each of which allows me to view the entire document containing the > element pointed to. Or whatever. Interface specification. We struggled in MID on the idea of logical vs explicit behavior in the widgets. It is easy to just say, three radiobuttons, and most people will know what you intend it to do. OTH, if you say, pickOne, they do as well but rather than radio buttons, you might have three big birds hollering at you and you pick one and they fly away. It is almost funny after a while and the reason Dave Cooper had the More Meta Than Thou posters made. There are problems just labeling it behavior but it is a place to start. > I believe that there are basically two ways to provide for such > specifications: you either consider them to be part of the stylesheet > (the way that DynaText does it) or you provide some kind of > architectural form mechanism that allows the behavior to be attached > to the link element. Deciding which way to go will indeed involve us > in some discussion of stylesheets, but the goal here is to keep > ourselves sane by getting into this area as little as possible and as > late as possible. Ok. This phase is quite hard to do without a notion of implementation and further definition of system design instead of abstract markup. > In today's ERB conference, we decided to divide Phase II (hypertext) > into three subphases: > > 1. Addressing Locations? Resource resolution? > 2. Typing Semantic linking? Reference types for linkends? > 3. Behavior Scripts, protocols, light (internal) vs heavy (java, etc) languages. These seem to come up often. The behavior problem has been discussed many times. > The first phase of this effort has shown us the virtue of putting off > the hardest questions until the end: you understand more by the time > you get there. It is hoped that in the process of solving the link > addressing and link typing problems we will learn enough to do the > right thing when it comes time to deal with behavior. I think this is a good idea. Behavior is tricky and a more religion-riddled topic you won't find in computer science. This is tough. Probably half of the WG has been involved in a project that set out to define this in a *standard* way, so there are lots of ideas, and lots of compromises ahead. sigh... another winter here by the sliding glass doors... happy thanksgiving! all! len Date: Wed, 27 Nov 1996 20:19:49 -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: FPIs [Murray Altheim:] | I just read Jon's plea for movement of discussion back in line with | our agenda, so until we revisit this issue (after hyperlinks), I'll | shelve this one. I was asking to defer the discussion of stylesheets. FPIs actually belong to the current draft, and what some people are requesting is the reconsideration of a previous decision. So this discussion is in order here, though its resolution may turn out to hinge on decisions that we will be making about linking mechanisms. Jon Date: Wed, 27 Nov 1996 21:25:50 -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: Simple solution? Pub. Idents. vs URN. | Not all documents will have persistent identifiers. But all documents | *will* have locations. (just as all machines do not have domain names, | but all machines do have IP addresses) I personally believe that the parallel almost universally drawn between persistent identifiers and IP addresses is the single largest obstacle to understanding this entire problem. In fact, document resolution and domain name resolution are almost exactly opposite problems. Domain name resolution is when I'm given one of a possibly unlimited number of names for a machine and I need to find the one machine that it refers to. Document resolution is when I'm given the name of a document and I need to find one of its possibly unlimited number of copies. To think of "the document" as a thing bound to a location in the same way that one thinks of "the machine" as a thing bound to a location is, in my opinion, to commit a category error that hopelessly muddles all further thought on the subject. The notion that there is One True Copy of a text stopped being accurate with the invention of the printing press, and we stopped referencing documents that way even before then. The biggest problem with URLs is that in attempting to implement hypertext they misrepresent the idea of text itself. (My apologies to the innocent poster who set that off.) Jon Date: Wed, 27 Nov 1996 21:53:12 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Revised XML registration Paul Grosso has very kindly shared the language that he used when registering the SGML Open catalog (along with a tip that could save us a few months in getting this approved). I have spliced Paul's SGML Open language in below with some questions for our MIME experts. Jon ======================================================================== To: iana@isi.edu cc: w3c-sgml-wg@w3.org Subject: Registration of MIME media type text/xml MIME media type name: text MIME subtype name: xml Required parameters: none Optional parameters: charset ************************************************************************ Here is what Paul said for SGML Open catalogs: For use over the Internet, a catalog may use only a single character repertoire. (A character repertoire describes a set of characters, where a character is an atom of information. A character repertoire does not describe any of the common attributes typically associated with a character such as the character's form or coded representation. For example, the letter capital cee is a character, it can take the form C and has the US-ASCII coded representation of 67 decimal.) The mapping from the sequence of octets making up the message body, to the sequence of characters making up the catalog, is indicated by the charset parameter of the Content-Type MIME header line [RFC1521]. The value of the charset parameter must be one that is registered with IANA [RFC1700], or employ an extension-token, such as X-big10. In general, it should be possible to infer the character repertoire and coded character set from the name of the encoding. If no value is supplied, the default shall be US-ASCII. Do we want to say the same thing? ************************************************************************ Encoding considerations: the primary encodings are UTF-8 and UCS-2, but other common encoding schemes such as SJIS are also allowed. UTF-8 is the default. ************************************************************************ Here is what Paul said for catalogs: Encoding considerations: Some encodings of coded character sets may require that an additional content-transfer-encoding be applied. Do we want to say the same thing? ************************************************************************ Security considerations: the security considerations associated with text/plain apply. ************************************************************************ Obviously just punting. Paul has: Security considerations: This media type contains SGML references to external object, files, and programs. Its use does present security implications due to the access of these entities by SGML systems. However, these security concerns are the same as those for the operation of any SGML system and are addressed in the SGML specifications. The same would apply to XML, right? ************************************************************************ Interoperability considerations: the interoperability considerations associated with text/plain apply. ************************************************************************ Same here. Paul said: Interoperability considerations: The specification for this media type (see "Published specification" below) provides for extensions by allowing for other information, i.e., pairs. The usefulness of such other information will depend on the range of recognition of each such extension. However, the specification indicates that a processor of this media type shall be able to process a catalog even if it does not recognize the meaning of such an extension. The first part of this looks like it might be recyclable. ************************************************************************ Published specification: Extensible Markup Language (XML), W3C Working Draft 14-Nov-96 (http://www.w3.org/pub/WWW/TR/WD-xml-961114.html; also ftp://sunsite.unc.edu/pub/sun-info/standards/xml/spec/xml.ps.gz, etc.) ************************************************************************ A couple of people have pointed out that XML does indeed hava a "magic number" (see below). ************************************************************************ Additional information: Magic number(s): In today's ERB conference, we decided to divide Phase II (hypertext) | > into three subphases: | > | > 1. Addressing | | Locations? Resource resolution? Yes. | > 2. Typing | | Semantic linking? Reference types for linkends? Yes. | > 3. Behavior | | Scripts, protocols, light (internal) vs heavy (java, etc) languages. | These seem to come up often. The behavior problem has been | discussed many times. Yes. Sigh. Jon From: Paul Prescod Subject: Re: Simple solution? Pub. Idents. vs URN. To: bosak@atlantic-83.eng.sun.com (Jon Bosak) Date: Thu, 28 Nov 1996 06:35:33 -0500 (EST) Cc: w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com > I personally believe that the parallel almost universally drawn > between persistent identifiers and IP addresses is the single largest > obstacle to understanding this entire problem. In fact, document > resolution and domain name resolution are almost exactly opposite > problems. > > Domain name resolution is when I'm given one of a possibly unlimited > number of names for a machine and I need to find the one machine > that it refers to. > > Document resolution is when I'm given the name of a document and I > need to find one of its possibly unlimited number of copies. Not so. The W3C Addressing/Activity page describes how it is already possible for one domain name address to point to multiple IP addresses. So domain name resolution is *also* sometimes a many to one, one to one, or one to many mapping. That this process is currently difficult, and underused is a bug in DNS and DNS systems, not in the basic DNS problem space. So I don't see how these are opposites. In my message I should have said that every document has *at least* one actual location, instead of "every document has a location." > To think of "the document" as a thing bound to a location in the same > way that one thinks of "the machine" as a thing bound to a location > is, in my opinion, to commit a category error that hopelessly muddles > all further thought on the subject. The same is true of machines. If DNS does not allow me to set up a machine in Tokyo and Johannesburg with the same name a one in California, to serve the same information, then DNS (or DNS implementation) is incomplete. >The notion that there is One True > Copy of a text stopped being accurate with the invention of the > printing press, and we stopped referencing documents that way even > before then. The biggest problem with URLs is that in attempting to > implement hypertext they misrepresent the idea of text itself. I don't understand that at all. URLs point to *one of* the locations of a document. That isn't a misrepresentation, it is just under-powered technology. URNs will point to all of the locations of a document, but in the end, they will resolve to URLs, just as domain names resolve to a particular IP address (Paul ducks) of potentially many that may be bound to a particular domain name. Am I still misunderstanding you? Paul Prescod Date: Thu, 28 Nov 1996 13:01:37 +0000 To: "Deborah A. Lapeyre" , Paul Prescod From: Martin Bryan Subject: Re: FPIs Cc: w3c-sgml-wg@w3.org At 13:29 27/11/96 -0800, Deborah A. Lapeyre wrote: > >On Wed, 27 Nov 1996, Paul Prescod wrote: > >> But PUBLIC identifiers put that redirection under the control of end-users. >> There are numerous techniques for doing redirection on the server side. > >And that is why they are critical to me. Not that there may be lookup >but that there must be and on the client side. I can't agree that lookup should be on the client side. >But perhaps that is exactly what we are trying to avoid. >A URL is all on the front end. An FPI is >by definition NOT on the front end and guarantees indirection. >Are we trying to forbid indirection and force front-endedness? >Is that the objection? Hopefully not. An interesting statement that was made at the W3C Internationalization and Multilingualism Symposium last week was that persistent URLs (PURLs) needed to be stored in a "library" that guaranteed long term access to the PURL. The idea is that the library would redirect the PURL to the current storage location for the relevant file. Consider what this means. A library can be looked at as a "set of catalogued references to objects stored in a set of local storage units". The catalogue provides both the indirection and the means of identifying where multiple copies of an object can be found. It also allows the same object to be identified in more than one way, e.g. by author name or by title. Consider if everyone wanting to create a reference to a paper on SGML decided, instead of referencing the file directly, to reference the entry for the paper in Robin Cover's bibliography. This would then point to the server(s) currently containing copies of this paper. If one wanted to create a link to anything about the subject you could do so by pointing to the public catalogue, whose URL would be much more persistant than any maintained at the individual sources. What does this tell us about SGML catalogs? Firstly it suggests they are currently stored in the wrong place. They are currently stored in the relocatable servers or in clients: I contend that they should be stored in an SGML Open Catalogue Library or some similar form of long-term digital library. Secondly it suggests that the FPIs used to identify the objects to be indirected do not need to be unique. There could be more than one way of identifying the same file using an FPI (e.g. an unregistered name when the file was first created, and a set of registered ones used for later references to the same file). It also implies that different catalogues in the same library can provide different ways of referencing the same object. >P.S. >Because of ownership, accidental name duplication is very easy to avoid. >Both registered and unregistered (the 99% case) provide simple but very >real duplication protection. (It is easy to screw up your own stuff but >very hard to screw up someone elses if you follow the rules at all.) > Funny, I now seemed to have covered Debbie's last point as well! You don't need ownership of 'your catalog', and you don't need to avoid name duplication in FPIs. What you actually want to do is to decouple the catalogue entry from its owner and encourage identifier duplication. What you need to do first, however, in encourage the use of indirection, which is the whole point of URNs, URCs, etc. They all need a directory/catalogue mechanism in some form of "library" to be able to work (as does the DNS service needed to resolve URLs). 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/ Date: Thu, 28 Nov 1996 13:01:35 +0000 To: Joe English , w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: CSS vs. DSSSL-O At 12:02 27/11/96 -0800, Joe English wrote: >I think we should also consider using architectural >forms for specifying presentation for XML documents. >A simple "XML online display architecture" -- most >likely based on HTML -- would be sufficient for many >user applications, and would probably be significantly >easier than either DSSSL or CSS. I'm afraid we tried this back in 1991 when we developed British Standard 7402: Guide to specifying electronic typographic markup (though in those days we didn't know of the term 'architectural forms'"). While it works for simple monolingual documents based on a single writing direction it does not provide a mechanism that will work across the whole range of ISO 10646 characters, or that provides a general purpose solution to specifying typography. If our goal is to supply a universal mechanism then we are going to have to deal with DSSSL at some time and, as the CSS guys found out last week, accept that a greater degree of sophistication is needed to cope with handling text presentation/ ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Thu, 28 Nov 1996 09:41:15 -0600 From: Len Bullard To: Jon Bosak CC: w3c-sgml-wg@w3.org Subject: Re: Simple solution? Pub. Idents. vs URN. Jon Bosak wrote: > To think of "the document" as a thing bound to a location in the same > way that one thinks of "the machine" as a thing bound to a location > is, in my opinion, to commit a category error that hopelessly muddles > all further thought on the subject. The notion that there is One True > Copy of a text stopped being accurate with the invention of the > printing press, and we stopped referencing documents that way even > before then. The biggest problem with URLs is that in attempting to > implement hypertext they misrepresent the idea of text itself. That is right. The idea of a "record of authority" is still with us. It is the legal master copy. I consider that a document management problem, and then a location problem. len From: lee@sq.com Date: Thu, 28 Nov 96 10:52:52 EST To: w3c-sgml-wg@w3.org Subject: Re: MIME type for XML > | I'm glad you're thinking of this, Jon, but isn't it premature > | to register the MIME type before the spec is finished? > > The ERB doesn't think so. Neither do I -- it may well take the best part of a year. The IETF doesn't usually rush things (and nor should it). Lee From: Charles@sgmlsource.com (Charles F. Goldfarb) To: w3c-sgml-wg@w3.org Subject: Re: FPIs Date: Thu, 28 Nov 1996 19:10:37 GMT On Wed, 27 Nov 1996 18:26:22 -0800, bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) wrote: >2. If you start creating FPIs that begin "-//SUN::SUNSOFT" then you >can count on spending the next few years of your life in court with >our trademark lawyers. Sun undoubtedly has an ISBN publisher's prefix. Why not just prefix it to your FPIs and use the standard the way it is supposed to be used? Your present approach is reminiscent of a B western where the powerful rancher takes over a part of the unfenced common pasturage and threatens anyone who "trespasses" on it. Beware ... Roy Rogers is still alive and well (and living in Victorville, California). -- 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: Thu, 28 Nov 1996 11:22:54 -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: Simple solution? Pub. Idents. vs URN. [Paul Prescod:] | > Domain name resolution is when I'm given one of a possibly unlimited | > number of names for a machine and I need to find the one machine | > that it refers to. | > | > Document resolution is when I'm given the name of a document and I | > need to find one of its possibly unlimited number of copies. | | Not so. The W3C Addressing/Activity page describes how it is already | possible for one domain name address to point to multiple IP addresses. So | domain name resolution is *also* sometimes a many to one, one to one, or | one to many mapping. That this process is currently difficult, and underused | is a bug in DNS and DNS systems, not in the basic DNS problem space. I didn't know that, and if I had, I would have written what I said differently. But it doesn't change the point I was trying to make. | > To think of "the document" as a thing bound to a location in the same | > way that one thinks of "the machine" as a thing bound to a location | > is, in my opinion, to commit a category error that hopelessly muddles | > all further thought on the subject. | | The same is true of machines. If DNS does not allow me to set up a machine in | Tokyo and Johannesburg with the same name a one in California, to serve the | same information, then DNS (or DNS implementation) is incomplete. The parallel between the multiple copies of a document and the multiple mirrors of a machine is logically incorrect. The key fact upon which everything else depends is that texts are fundamentally different from every other thing in the world. They occupy a different level of reality and follow different rules. This is not some crackpot notion of mine (I have a few of those, but this is not one of them). There happens to have been some intense analysis of this question over the last few decades, and I'm simply reporting some of what I remember. Consider two parallel cases. You and I each have a copy of a book, let us say Burton's Anatomy of Melancholy, and you and I each have a computer that has been assigned the name boethius.eng.sun.com (that's actually the name of my machine at work; let's suppose that it's the name of yours, too). Let us further hypothesize that my copy of Burton is ever so different in its physical characteristics from yours; mine is in three octavo volumes, two of which have been repaired with some tape, in a green cloth binding, and was published in 1893, whereas yours (let us imagine) is in a single leather-bound quarto volume published in 1925. And let us suppose by contrast that the two computers are as physically alike as two computers possibly can be: the same system configuration, the same peripherals, even the same data, right down to the last bit. We'll even have duplicate serial number tags put on them. But while our copies of Burton are as physically different as can be imagined, and our copies of boethius are as physically similar as can be imagined, the fact is that we are in possession of the identical text, but we are not in possession of the identical computer. And the reason is that by "text" we do not mean its physical incarnation. This is how texts are different from everything else in the world. Here's the proof. According to the Law of Identity, two things, A and B, are identical if, and only if, everything that can truly be predicated of A can truly be predicated of B, and vice versa. Let us apply this test to our parallel. Suppose I say to you that in Burton's Anatomy of Melancholy, Part III, Sect. IV, Mem. II. Subs. VI (Burton was an early user of TEI location addressing), he says that the Cure of Despair can be summed up in the statement Be not solitary, be not idle. If you check your copy, you will find my statement to be true. However dissimilar the physical realizations may be, we are in possession of the identical text. But if I say to you that the top of the second hard drive housing of boethius.eng.sun.com is adorned with a small clay bird that my daughter gave me as an office-warming present, and you check your installation, you will find this not to be true. However similar their physical realizations may be, we are not in possession of the identical computer. (The fact that they do not occupy the same physical space and therefore do not share the same GPS coordinates would guarantee this anyway, but I wanted to make a nice illustration.) Thinking of copies of texts as being parallel to copies of machines is a category error because the predicates that we are logically allowed to apply to texts are different from the predicates that we are logically allowed to apply to everything else. We may predicate of a text, for example, that it is well-written, or reeks of sentiment, or evokes the nineteenth century, or indicates that the author had an unhappy childhood, or supports my claim to the throne of the Kingdom of Belgravia. We cannot predicate these things of the file referred to by a URL or of the pile of paper upon which the document may be printed. The point is that machine identifiers and document identifiers are doing logically distinct things. At the end of the DNS trail, a domain name identifies some physical object or objects. At the end of the FPI trail, the FPI (if properly implemented; take ISBNs as the canonical example) does not identify a physical object but rather any of a possibly unlimited number of realizations of a nonphysical object. Yes, an FPI resolver has to be able to deliver you a physical thing that you can read, but that thing is *not* what is being identified by the FPI; the thing that's being identified is the text itself, and the text itself does not have a physical location. All of this would be completely irrelevant and certainly out of place in this discussion if it weren't for my inability to escape the feeling that a failure to understand the distinction between the text and its realizations is at the root of a great deal of difficulty in solving the document location problem. Since my misgivings do not point directly to a solution, however, this thread should probably be taken as no more than a piece of free holiday philosophizing. Jon From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Paul Prescod Cc: w3c-sgml-wg@w3.org Subject: Re: SGML and XML Date: Thu, 28 Nov 1996 19:23:59 GMT On Wed, 27 Nov 1996 21:54:33 -0500, Paul Prescod wrote: > I am particularly interested in the whitespace handling. At SGML '96 an informal discussion led to a technique that conforms to ISO 8879 as it is today, but causes whitespace to be handled almost as requested on this list, but without the funky attributes. Whitespace would be handled as follows: 1. In element content, all whitespace is ignored. 2. In data content, all whitespace is preserved. The SGML technique for accomplishing this result has two steps: 1. Declare a new SEPCHAR function character in the XML concrete syntax, using a character number that is not expected to occur naturally. Call this "newsep". : 2. In a shortref map used by the document element, map RE to NEWSEP. That's it. If you're unhappy with SGML's built-in whitespace handling, you can use this technique today. If we choose to use it for XML, it will be simple to explain, easy to implement, and totally conforming. -- 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: Thu, 28 Nov 1996 11:47:01 -0800 (PST) From: Terry Allen To: bosak@atlantic-83.eng.sun.com, papresco@calum.csclub.uwaterloo.ca Subject: Re: Simple solution? Pub. Idents. vs URN. Cc: w3c-sgml-wg@w3.org Paul Prescod writes: >URNs will point to all of the locations of a document No. URNs will not point at all. Resolution of URNs may make it possible to discover some of the locations of copies of the thing named by the URN, but not necessarily (and very likely certainly not) all of those locations. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Date: Thu, 28 Nov 1996 12:02:03 -0800 (PST) From: Terry Allen To: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org Subject: Re: Simple solution? Pub. Idents. vs URN. I agree with the drift of what Jon has to say by way of free holiday philosophizing, although some of his examples need cleaning up. However, I limit myself to playing ISBN police (this was necessary during earlier phases of the URI work, too): > At the end of the FPI trail, the FPI (if properly implemented; take ISBNs as the canonical example) does not identify a physical object but rather any of a possibly unlimited number of realizations of a nonphysical object. ISBNs precisely do identify classes of identical physical objects. The paperback and hardback realizations of the same text (nonphysical object) printed exactly the same way commonly have different ISBNs. Furthermore, sloppy publishers sometimes do not change the ISBN of a book when they issue a revised edition. ISBNs are about the worst possible illustration of URNs. Take Social Security Numbers, DUNS numbers, California license plate numbers, the names of the states of the U.S., anything but ISBNs as examples. ISBNs refer to objects, not to texts. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Date: Thu, 28 Nov 1996 12:11:00 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: tallen@fsc.fujitsu.com CC: w3c-sgml-wg@w3.org Subject: Re: Simple solution? Pub. Idents. vs URN. [Terry Allen:] | ISBNs precisely do identify classes of identical physical objects. | The paperback and hardback realizations of the same text (nonphysical | object) printed exactly the same way commonly have different ISBNs. | Furthermore, sloppy publishers sometimes do not change the ISBN of a | book when they issue a revised edition. ISBNs are about the worst | possible illustration of URNs. You're right, that was a terrible example. Legal citations might have been better. Jon From: lee@sq.com Date: Thu, 28 Nov 96 16:16:36 EST To: papresco@calum.csclub.uwaterloo.ca, Charles@sgmlsource.com Subject: Re: SGML and XML Cc: w3c-sgml-wg@w3.org > Whitespace would be handled as follows: > > 1. In element content, all whitespace is ignored. > 2. In data content, all whitespace is preserved. Note that without a DTD it is not possible to distinguiish element and data content. Furthermore, this behaviour makes it impossible to write a conforming XML program that copies its input to its output unchanged, just as this is impossible in SGML right now -- no matter how many virgins you use to tempt those unicorns :-) :-) The distinction between whitespace that is returned by the parser (i.e. emphatically not ignored) but that is not treated as data, and whitespace thhat is treated as data, is a useful one, I think. The ability to disable SGML RS/RE processing in the SGML Declaration is really what's wanted. That wasn't discussed before, as there seemed no possibility of any changes to SGML. I am not sure that we should reopen the RS/RE discussions unless there are substantial changes. No, I am sure that we _shouldn't_. The mere fact that it took so much heated discussion shows that it is too complex, and even the current XML draft is not considered clean and elegant in this regard by everyone involved. If SGML can be changed to disable RS/RE processing, or if Charles' kludge with SHORTREF works, perhaps we're OK. We do have to get the same whitespace behaviour with and without a DTD, so element content and data content is not a distinction XML can make, I think. Lee Date: Thu, 28 Nov 1996 13:40:27 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: Simple solution? Pub. Idents. vs URN. I take the body of the above discussion (enjoyable though it is) as strong evidence that for now, XML should stay with the two modes of addressing that it has built in: URL and ID/IDREF. Every discussion of FPI's and UR[^L]'s that I have heard has quickly passed out of my comprehension and into a desolate area full of ringing assertions about document metaphysics and the eschatology of network addressing. Which is all very entertaining but not, I submit, our job. URL's and ID/IDREF, particularly when extended with some basic HyTime mechanisms, have an important virtue; they demonstrably work, and there is the software to prove it. XML is not here to be a partisan of hypotheses about the way advanced document processing ought to be done in the future; its goal is to specify a simple set of practices that (a) are comprehensible (b) are compliant with international standards and (c) work. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Thu, 28 Nov 1996 13:42:35 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: SGML and XML At 04:16 PM 28/11/96 EST, lee@sq.com wrote: >We do have to get the same whitespace >behaviour with and without a DTD, so Why? - Tim Date: Thu, 28 Nov 1996 16:50:40 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: SGML and XML Cc: w3c-sgml-wg@w3.org At 2:23 PM 11/28/96, Charles F. Goldfarb wrote: >The SGML technique for accomplishing this result has two steps: > >1. Declare a new SEPCHAR function character in the XML concrete syntax, using a >character number that is not expected to occur naturally. Call this >"newsep". : >2. In a shortref map used by the document element, map RE to NEWSEP. > >That's it. If you're unhappy with SGML's built-in whitespace handling, you can >use this technique today. If we choose to use it for XML, it will be simple to >explain, easy to implement, and totally conforming. Unfortunately this does not work for XML, as it is not possible to tell the difference between mixed content and element content when parsing without a DTD. It also unfortunately requires throwing away a character code point. Especially for 8-bit character sets, that might be a high price to pay. Isn't there some chance that we could get a way to specify the behavior wanted rather than an arcane workaround? I want to be able to turn off RS/RE handling, and turn all whitespace into SEPCHARS without having to make arcane restrictions on what other, non-whitespace, characters can appear in a document. Is that too much to ask? Also, it's not clear to me that RS/RE are visible to shortrefs at the beginning of an element. I thought SHORTREF applied to document data, not ignored characters, but I could well be wrong, as I have avoided delving into the mysteries of shortref (like why a shortref cannot include the letter "B"). -- 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 \__________________________ From: Ken Holman To: "'w3c-sgml'" Subject: FPI's in NOTATION declarations Date: Thu, 28 Nov 1996 17:12:17 -0500 Not necessarily a bad example when FPI's are used in the NOTATION declaration. One thing to remember is that the FPI registered owner identifier, when using the ISBN registered owner prefix, is typically manufactured from the ISBN Publisher's Prefix only, but can be meaningfully manufactured with a full ISBN. A full ISBN can be used in an FPI to refer to a concept by pointing to an instance of publication of that concept. The NOTATION declaration for TeX could be: or There are two possible because the first is the paperback and the second is the hardcover. In these cases one is not trying to dereference a location, rather, just trying to dereference a concept or specification. I don't think that a SYSTEM identifier with an URL would suffice for this. This would require XML production [69] ExternalId, which is used in production [77] NotationDecl, to support 'PUBLIC' as well as the currently hardwired 'SYSTEM' value (or, of course, add something new to NotationDecl so that other references to ExternalId in the specification are not affected). ............ 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: gkholman@CanadaMail.com -----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: Thursday, November 28, 1996 15:11 >To: tallen@fsc.fujitsu.com >Cc: w3c-sgml-wg@w3.org >Subject: Re: Simple solution? Pub. Idents. vs URN. > >[Terry Allen:] > >| ISBNs precisely do identify classes of identical physical objects. >| The paperback and hardback realizations of the same text (nonphysical >| object) printed exactly the same way commonly have different ISBNs. >| Furthermore, sloppy publishers sometimes do not change the ISBN of a >| book when they issue a revised edition. ISBNs are about the worst >| possible illustration of URNs. > >You're right, that was a terrible example. Legal citations might have >been better. > >Jon > > From: lee@sq.com Date: Thu, 28 Nov 96 17:18:59 EST To: tbray@textuality.com Subject: Re: SGML and XML Cc: w3c-sgml-wg@w3.org > At 04:16 PM 28/11/96 EST, lee@sq.com wrote: > >We do have to get the same whitespace > >behaviour with and without a DTD, so > > Why? - Tim A document that worked with a DTD shouldn't stop working without one, I think. Well-formed should be a proper subset of valid. No? Date: Thu, 28 Nov 1996 17:24:53 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Simple solution? Pub. Idents. vs URN. At 1:40 PM 11/28/96, Tim Bray wrote: >I take the body of the above discussion (enjoyable though it is) >as strong evidence that for now, XML should stay with the two modes >of addressing that it has built in: URL and ID/IDREF. Every discussion >of FPI's and UR[^L]'s that I have heard has quickly passed out of my >comprehension and into a desolate area full of ringing assertions about >document metaphysics and the eschatology of network addressing. Which is >all very entertaining but not, I submit, our job. URL's and ID/IDREF, >particularly when extended with some basic HyTime mechanisms, have an >important virtue; they demonstrably work, and there is the software to >prove it. All I was asking, and will continue to ask, is that we add language to the XML standard so that when URNs are deployed, XML will be compatible with them. The URN group has finally finished with the "ringing assertions" (took at least 3 years, by my rough estimate). This is an easy way to throw a crumb to people who believe (rightly or wrongly) that FPIs do them some good. We have had several testimonials to their use, and no real argument against their use than that "they don't work." It seems to me that a claim that something works, made by someone who uses it is stronger evidence than a claim by someone else that "No it doesn't really work, you are deluded". I think that we _ought_ to add FPIs in the same as we have them in SGML, but instead I am proposing a compromise which will let the IETF URN group deploy a resolution framework, that we simply agree (in advance) to use. Easy, no? > >XML is not here to be a partisan of hypotheses about the way advanced >document processing ought to be done in the future; its goal is to specify >a simple set of practices that (a) are comprehensible (b) are >compliant with international standards and (c) work. I have not seen any arguments or evidence that FPIs are not any of these things. There is a good argument that SGML Open Catalogs are to heavyweight to be a requirement of XML, but I have not seen one for the proposition that we should _exclude_ the use of persistent identifiers when they are available over the internet! Let's just change "URL" in the XML spec to "URL or URN" everywhere. This may help the URN effort as well, by getting some users lined up at the door. -- David PS I promised some information on URN status, here are the 3 recent, important docs in that effort. (There are 2 other requirements documents, also worth reading, but perhaps more "philosophical".) Here are the current drafts for URNs: Internet-Draft Ryan Moats draft-ietf-urn-syntax-01.txt AT&T Expires in six months November 1996 URN Syntax Filename: draft-ietf-urn-syntax-01.txt Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers. This document sets forward the canonical syntax for URNs. Support for both existing legacy and new namespaces is discussed. Requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. Title : Conventions for the Use of HTTP for URN Resolution Author(s) : R. Daniel Filename : draft-ietf-urn-http-conv-00.txt Pages : 6 Date : 11/21/1996 The URN-WG was formed to specify persistent, location-independent names for network accessible resources, and resolution mechanisms to retrive the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal [1]. That proposal does not get the client software all the way from the URN to the resource. Instead, it gets the client from a URN to a "resolver", which is a system that can then tell the client where the resource is. The NAPTR draft defines a "resolution protocol" to be the protocol used to speak to a resolver in order to obtain the resource, its location(s), or other information about the resource. The NAPTR proposal allows different resolution protocols to be used for commuicating with resolvers. This draft establishes conventions for encoding URN resolution requests and responses in HTTP 1.0 (and 1.1) requests and responses. The primary goal of this draft is to define a convention that is simple to implement and will allow existing HTTP servers to easily add support for URNresolution. We expect that the resolution databases that arise will be useful when more sophisticated resolution protocols are developed later. Title : Resolution of Uniform Resource Identifiers using the Domain Name System Author(s) : R. Daniel, M. Mealling Filename : draft-ietf-urn-naptr-01.txt Pages : 13 Date : 11/21/1996 Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Name to Location, Name to Description, Name to Resource, ...) to be offered. In conjunction with the SRV RR proposal [3], the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-naptr-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-naptr-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Thu, 28 Nov 1996 16:23:30 -0600 From: Len Bullard To: Jon Bosak CC: tallen@fsc.fujitsu.com, w3c-sgml-wg@w3.org Subject: Re: Simple solution? Pub. Idents. vs URN. Jon Bosak wrote: > > [Terry Allen:] > > | ISBNs precisely do identify classes of identical physical objects. > | The paperback and hardback realizations of the same text (nonphysical > | object) printed exactly the same way commonly have different ISBNs. > | Furthermore, sloppy publishers sometimes do not change the ISBN of a > | book when they issue a revised edition. ISBNs are about the worst > | possible illustration of URNs. > > You're right, that was a terrible example. Legal citations might have > been better. > > Jon Ah, but it is interesting how many real world examples of URNs you can come up with regardless of how usable they are. Please, do philosophize on with some more illustrations. How are URNs and SGML catalogs related? What happens if an SGML catalog contains more than one of these kinds of examples? How and where does a URN begin to break down? How does the URL make this less likely to happen? A URN is cited in VRML now. I will get the text and post it for comparison after the TurkeyFestFever ends later tonight. BTW, just in the translations provided, I can show where two books have different contents. The printed copy of the Quran has a chapter called "The Booty" whereas the text Jon provided calls this "The Spoils of War". So, physical? Are translations different objects logically? len From: lee@sq.com Date: Thu, 28 Nov 96 19:22:09 EST To: w3c-sgml-wg@w3.org Subject: Re: FPI's in NOTATION declarations Ken Holman wrote: > A full ISBN can be used in an FPI to refer to a concept by pointing to > an instance of publication of that concept. The NOTATION declaration for > TeX could be: > > TeXbook//EN"> [...] However, leaving aside the idea that the notation is supposed to refer to the program that will process the data, for practical purposes (avoiding intellectual elegance for a moment) one could do and there would be no substantive difference, except that the URL can be resolved right now today algorithmically, whereas the FPI can't. (the SGML OPEN catalog can be used to turn an FPI into a URL, though). > In these cases one is not trying to dereference a location, rather, just > trying to dereference a concept or specification. I don't think that a > SYSTEM identifier with an URL would suffice for this. Possibly not, but since dereferencing a concept has no practical application that I can see, I don't care. You could use a URL for that too -- concept://computing/text-formatting/programs/TeX would do if you don'tneed to dereference it. I don't think it's useful to talk about FPIs that you don't want to dereference (even indirectly) since any string at all would do equally well, so a URL would do. So let's focus on the cases where the FPI isn't just a string you want to be unique (which you can do reliably with a URL) but instead on other uses. [1] compatibility with HTML [2] server-side indirection [3] client-side indirection [4] client-side file inclusion (what else?) [1] I think FPIs have one major application for XML: would become legal XML, so that there could be documents that were legal in both XML and HTML, which is not possible right now. Actually if the XML PI is illegal in HTML 2.0 and the SGML declaration differs in other ways, perhaps that's not sufficient. [2] you can get this already with URLs. [3] neither FPIs nor system IDs give you this on their own. Combined with the SGML OPEN CATALOG mechanism, you can get client side indirection if you know the public identifier in advance and hard-wire it into a file. This is useful in practice mostly because SGML tools are so badly broken; we vendors should all be embarrassed and ashamed at the thought that SGML OPEN was needed in order to allow interchange of SGML files even to the limited extent we have today. There is no reason why a client-side URL lookaside table could not be used to give this functionality with URLs. This could work like the Apache Alias directive: Alias "system-id" "other-system-id" where both system IDs are URLs. However, I would rather see this as a separate document and be suggested than see it as required. It's not needed for a spreadsheet file load, nor for many other XML applications. [4] (client-side file inclusion) If you download a file using a URL, relative paths will work fine for file inclusion. You can generate them automaticallyif you have a tool to do it, or write one. The same look-aside mechanism as for (3) (askance.map??) might be useful. If you mantain a large site, you may want indirection of links. You can do that by putting all the link entity definitions in a central file, though, using existing XML mechanisms. Many people are asking for FPIs because they are a mechanism for doing something they need to do. But there are other possible mechanisms. The only argument that sways me here is the compatibility with HTML one. Am I missing something? Lee Date: Thu, 28 Nov 1996 22:49:54 -0500 To: lee@sq.com, w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: FPI's in NOTATION declarations At 07:22 PM 11/28/96 EST, lee@sq.com wrote: >Ken Holman wrote: >> > TeXbook//EN"> >[...] > >However, leaving aside the idea that the notation is supposed to refer >to the program that will process the data, for practical purposes (avoiding >intellectual elegance for a moment) one could do > >and there would be no substantive difference, There are substantive differences. The first is that the first namespace is formally organized and "bigger" than DNS, IANA or Internic. The second is that FPIs can be "redirected" by the information consumer or maintainer, where as URLs can only be redirected by the information provider. If you are trying to validate an SGML document on a notebook on a plane, that might be a useful ability to have. I suppose you could redirect URLs, but that seems like a nasty semantic mixup. If an identifier has a machine name in it, then the information should, at least logically, come >from the machine (even if a cache "represents" that machine). >Possibly not, but since dereferencing a concept has no practical application >that I can see, I don't care. You could use a URL for that too -- > concept://computing/text-formatting/programs/TeX >would do if you don't need to dereference it. Some people feel strongly that there should be a syntactic differentiation between *names* and *locations*. A concept cannot have a URL. It can only have a name, or perhaps a URN. I think that the first time you "click" on a "concept:" you'll wish that they were distinct also. Anyhow, a major benefit of having URLs *and* FPIs is redundancy. I think that they should usually be used together. >[3] client-side indirection >[3] neither FPIs nor system IDs give you this on their own. Combined with > the SGML OPEN CATALOG mechanism, you can get client side indirection > if you know the public identifier in advance and hard-wire it into a file. > This is useful in practice mostly because SGML tools are so badly broken; > we vendors should all be embarrassed and ashamed at the thought that > SGML OPEN was needed in order to allow interchange of SGML files even > to the limited extent we have today. Isn't that what SGML Open is for? Anyhow, I don't really understand what you mean aobut SGML tools being badly broken. The problem FPIs partially solve is *hard*. FPIs provide a partial solution that URLs do not. > There is no reason why a client-side URL lookaside table could not be > used to give this functionality with URLs. > This could work like the Apache Alias directive: > Alias "system-id" "other-system-id" > where both system IDs are URLs. As I stated before, I think that this is attempting to make URLs into something they are not. I don't really feel comfortable having clients redirect URL accesses. With a separate syntax it is clear from the document that a redirection is possible, if your tool supports it. Paul Prescod From: lee@sq.com Date: Thu, 28 Nov 96 23:40:47 EST To: lee@sq.com, papresco@calum.csclub.uwaterloo.ca, w3c-sgml-wg@w3.org Subject: Re: FPI's in NOTATION declarations There are several things that are being confused here: [A] whether to allow PUBLIC "some string" syntax in XML; [B] if such syntax is used, whether to make use of it; [C] if such syntax is used, whether to retain SYSTEM identifiers; [D] if such syntax is used, how to interpret the string; [E] if the string is to be used and interpreted, whether to use the SGML OPEN CATALOG file format, or a subset of it, to convert the string into a sequence of data octets [F] whether to use PUBLIC "some other string" for defining NOTATIONS; these strings are in SGML not used in the same way as the strings used for identifying entity references, and are not usually resolved with the SGML OPEN CATALOG mechanism. I suggest that it doesn't matter what strings are used for [F]; they can be FPIs if you like. There is an SGML OPEN draft for handling NOTATION, but it is only a draft right now. Let's leave NOTTIONs aside for now -- they are not part of hyperlinking (although not unrelated, like other ways of specifying link types). I think that for [A], HTML compatibility may be a good reason to vote Yes, but that for [B], I have still seen no compelling reasons. The strongest has been Debbie & Paul P. wanting to be able to change the meaning of FPIs on the client side. This is convenient if you have a local copy of something (URN-like), and not very SGMLish if your copy differs from the "authoritative" copy. In both cases, you should really be overriding a SYSTEM identifier. If you are referring to the Latin 1 entities and their esteemed colleagues, though, I agree that it is convenient to have a local copy, and this can save a not inconsiderable delay in network latency right now. The difficulty is in having a sufficiently small set of features to do what is needed without losing too much functionality. So, here is my question: What mechanisms are proposed for including SDATA entity sets? I have just agreed to chair an SGML OPEN group trying to come up with a way of specifying the replacement text for SDATA entities; if that can be system independent, it may be very useful in a future version of XML. In the meantime, it is likely that you will need to have your own version of the Latin 1 entities, with replacement text suited for your local system. So how do you find it? Is it useful to be able to override other FPIs? Please give real, concrete examples. If your name isn't Paul Prescod :-), you can stop reading now... Lee Paul Prescod > Lee wrote: >> >> and there would be no substantive difference, > > There are substantive differences. > > The first is that the first namespace is formally organized and "bigger" > than DNS, IANA or Internic. What does bigger mean? I don't know how to interpret you here. The IETF is a recognised international standards body. The FPI namespace is no larger than dns --- they are both countably infinite, discounting practical length limitations... I am not sure why the size matters, though, as long as they're big enough. > The second is that FPIs can be "redirected" by the information consumer or > maintainer, where as URLs can only be redirected by the information > provider. I already pointed out that this isn't necessarily true. Also, you are making an assumption about FPIs -- that the user can affect their resolution. There is nothing in ISO8879 that mandates that -- quite the reverse, if anytyhing. I haven't checked the FPI standard, as I don't have access to a copy right now (sorry). > I suppose you could redirect > URLs, but that seems like a nasty semantic mixup. If an identifier has a > machine name in it, then the information should, at least logically, come > from the machine (even if a cache "represents" that machine). (1) URLs do not contain machine names except by coincidence. They start with Internet domain names. (2) A URL is a coordinate in cyberspace. To put it another way, a URL is indeed a resource's location, but that needn't be a resource that exists. > Some people feel strongly that there should be a syntactic differentiation > between *names* and *locations*. Possibly. We will have that with URNs. > A concept cannot have a URL. It can only > have a name, or perhaps a URN. I think this shows that you are confused about URLs -- but we should take that discussion offline. It is not meaningful to say that a concept has a URL. It is meaningful to say that you can use a URL to represent a concept, though. If you must have it point at something, point at a textual description. > I think that the first time you "click" on a > "concept:" you'll wish that they were distinct also. I was referring to URNs, not the HREF attribute of an HTML element. You are going to have a hard time dereferencing your TeX Book example FPI too, if you "click on it". Obviously that isn't what it is for. > Anyhow, a major benefit of having URLs *and* FPIs is redundancy. I think > that they should usually be used together. We don't need redundant syntax. We need a minimal language that people actually implement. > >[3] client-side indirection > [...] > Isn't that what SGML Open is for? You mean the CATALOG TR, I assume, rather than the organisation? > The problem FPIs partially solve > is *hard*. FPIs provide a partial solution that URLs do not. No. FPIs plus the SGML OPEN catalog plus URLs provide a partial solution. FPIs by themselves are nothing but structured strings, just like URLs, URNs, telephone numbers and those knotted Mayan things :-) > > There is no reason why a client-side URL lookaside table could not be > > used to give this functionality with URLs. > > As I stated before, I think that this is attempting to make URLs into > something they are not. I don't really feel comfortable having clients > redirect URL accesses. With a separate syntax it is clear from the document > that a redirection is possible, if your tool supports it. But then every XML program needs to support the SGML OPEN catalog, and we have to work out how to associate an SGML OPEN catalog with every XML file, and how to do that in the presence of CGI, and how to store multuple XML document sets in the same directory without CATALOG conflict, and document it all, and still be under 20pp. I am not opposed to solving the problems that need to be solved, but only to confusing functionality and requirements with mechanism. If this is what we need to do, we'll do it. Lee Date: Thu, 28 Nov 1996 22:49:52 -0500 To: Tim Bray , w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: Simple solution? Pub. Idents. vs URN. At 01:40 PM 11/28/96 -0800, Tim Bray wrote: >I take the body of the above discussion (enjoyable though it is) >as strong evidence that for now, XML should stay with the two modes >of addressing that it has built in: URL and ID/IDREF. Every discussion >of FPI's and UR[^L]'s that I have heard has quickly passed out of my >comprehension and into a desolate area full of ringing assertions about >document metaphysics and the eschatology of network addressing. There are simple principles at work. A URL is chosen based on where a document is located. Sometimes people want to give documents more permanent names. Within a closed system this can be done through FPIs. I suggest the following wording: "The PublicID is optional. The Literal that follows the keyword PUBLIC is called the entity's public identifier. It is a persistent name for the entity. User agents that have a mechanism for resolving persistent names may use the public identifier to locate the document. Other user agents may use the system identifier." This is a simple "hook" for people who have solved the persistent name problem within a particular system. SGML systems already support this hook, of course. When Web systems have a global resolution, we will be ready. We can register an FPI: namespace and register our documents within it. It doesn't cost us anything to allow those who use public identifiers, or who want to give it a shot to have a syntax for doing so. > XML is not here to be a partisan of hypotheses about the way advanced > document processing ought to be done in the future; its goal is to specify > a simple set of practices that (a) are comprehensible (b) are > compliant with international standards and (c) work. Within some (many!) systems, FPIs meet all of those goals. Paul Prescod Date: Thu, 28 Nov 1996 22:47:04 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: Charles@sgmlsource.com CC: w3c-sgml-wg@w3.org Subject: Re: FPIs [Charles Goldfarb:] | >2. If you start creating FPIs that begin "-//SUN::SUNSOFT" then you | >can count on spending the next few years of your life in court with | >our trademark lawyers. | | Sun undoubtedly has an ISBN publisher's prefix. Why not just prefix it | to your FPIs and use the standard the way it is supposed to be used? I have my own ideas about how the standard is supposed to be used. | Your present approach is reminiscent of a B western where the powerful | rancher takes over a part of the unfenced common pasturage and | threatens anyone who "trespasses" on it. Beware ... Roy Rogers is | still alive and well (and living in Victorville, California). My point was that you can make your own publisher prefix without getting permission from, or paying an annual fee to, a naming authority. Any corporation or trademark owner can use their intellectual property rights to assert control over the use of their name in an FPI, not just companies the size of Sun. FPIs can in practice serve as unique identifiers in the absence of naming authorities. Jon Date: Thu, 28 Nov 1996 16:04:52 -0800 From: eduardo.gutentag@Eng (Eduardo Gutentag) To: w3c-sgml-wg@w3.org, Charles@sgmlsource.com Subject: Re: FPIs > From Charles@sgmlsource.com Thu Nov 28 11:26:58 1996 > From: Charles@sgmlsource.com (Charles F. Goldfarb) > To: w3c-sgml-wg@w3.org > Subject: Re: FPIs > Date: Thu, 28 Nov 1996 19:10:37 GMT > Organization: Information Management Consulting > On Wed, 27 Nov 1996 18:26:22 -0800, bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) > wrote: > > >2. If you start creating FPIs that begin "-//SUN::SUNSOFT" then you > >can count on spending the next few years of your life in court with > >our trademark lawyers. > > Sun undoubtedly has an ISBN publisher's prefix. No, we don't. SunSoft Press has one, and so does JavaPress, but not Sun Microsystems Inc., or SunSoft or SMCC - our publications (the ones you receive when you buy a Sun workstation, or by special order) do not carry ISBN numbers. > Why not just prefix it to your > FPIs and use the standard the way it is supposed to be used? In what way does "-//SUN::SUNSOFT" deviate from the standard? I would think that a deviation from the standard would be to use "+//SUN::SUNSOFT". But let me put this another way. We really want to be able to start our FPIs with "+//SUN::SUNSOFT". How do we accomplish this? What authority is there today to register this? "Real soon now" doesn't quite cut it. > > Your present approach is reminiscent of a B western where the powerful rancher > takes over a part of the unfenced common pasturage and threatens anyone who > "trespasses" on it. Beware ... Roy Rogers is still alive and well (and living in > Victorville, California). Oh please. In what way is the string "SUN::SUNSOFT" common pasturage in the age of trademarks? Eduardo > -- > Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 > 13075 Paramount Drive * Saratoga CA 95070 * USA > International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime > Prentice-Hall Series Editor * CFG Series on Open Information Management > -- > > From: Martin Cottreau To: "'w3c-sgml-wg@w3.org'" Subject: RE: Simple solution? Pub. Idents. vs URN. Date: Fri, 29 Nov 1996 09:29:37 -0500 > XML is not here to be a partisan of hypotheses about the way advanced=20 > document processing ought to be done in the future; its goal is to = specify > a simple set of practices that (a) are comprehensible (b) are > compliant with international standards and (c) work. Within some (many!) systems, FPIs meet all of those goals. Paul Prescod I disagree. FPI do not qualify as "a simple set of practices". Design goal number 4 for XML is "It shall be easy to write programs = which process XML documents." (according to the SGML '96 proceedings). = FPI violate that goal as well, as anyone who has pored through SP's = code knows. The Web has it's own ways to identify objects: let's use them (URLs now, = URIs later). Once XML is a success, then we can improve the Web based = on our experiences in "standard" SGML implementations. I think Tim Bray's a) b) and c) points are great and should be used as = an acid test for discussions. Can XML be work without FPI? Yes. Then, = because they are not easily implementable, let's move on and define some = linking syntax. Date: Fri, 29 Nov 1996 09:36:38 -0500 To: Terry Allen From: Murray Maloney Subject: Re: MIME type for XML Cc: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org At 03:33 PM 27-11-96 -0800, Terry Allen wrote: >I'm glad you're thinking of this, Jon, but isn't it premature >to register the MIME type before the spec is finished? > >If a MIME type is needed for demos, let's use text/x-xml So, how about text/x-ml **************************************************************** Murray Maloney email: murray@sq.com Technical Director http://www.softquad.com SoftQuad Inc. P.O. Box 2025 Phone: +1 416 544-3010 20 Eglinton Avenue West, 12th Floor Fax: +1 416 544-0300 Toronto, Ontario, Canada M4R 1K8 also: murray@torfree.net Advisor, Yuri Rubinsky Insight Foundation Member, International Committee for Accessible Document Design Sponsor Member, Davenport Group Member, W3C Advisory Committee Member, International World Wide Web Conference Committee Member, W3C HTML Editorial Review Board and SGML Working Group **************************************************************** From: Ken Holman To: "'eduardo.gutentag@eng.sun.com'" Cc: "'w3c-sgml'" Subject: RE: FPIs Date: Fri, 29 Nov 1996 11:06:59 -0500 [Eduardo Gutentag] > >In what way does "-//SUN::SUNSOFT" deviate from the standard? It doesn't at all, and in fact, it shows consistent usage of owner-name components and proper use in SGML. >I would think >that a deviation from the standard would be to use "+//SUN::SUNSOFT". > >But let me put this another way. We really want to be able to start our >FPIs with "+//SUN::SUNSOFT". How do we accomplish this? What authority >is there today to register this? "Real soon now" doesn't quite cut >it. The "real soon now" that I mentioned isn't in the context of being able to register arbitrary strings ... it is in the context of ISO/IEC having an authorized Registrar "real soon now". According to ISO/IEC 9070:1991, the Registration Authority assigns numbers that are used in the specific format of my example: "+//ISO/IEC 9070/RA::A00004", specifically, the "A00004" string for Microstar. ISO has already assigned ANSI as the Registration Authority. ANSI is in negotiation (it may have even been completed by now) with GCA for GCA to be the Registrar (this was announced at SGML'95). The GCA Registry is at http://www.gca.org/publicid/index.htm and outlines the process proposed to ANSI, and the list of organisations currently assigned numbers. (Owners of copies of ISO/IEC 9070:1991(E) will discover some minor discrepancies that are being addressed by ISO/IEC JTC 1/SC 18/WG 8.) So there is no _naming authority_ (9070 definition 3.9) that is "there today to register this" to make "SUN::SUNSOFT" a _registered owner prefix_ (9070 clause 5.2). The note with ISO 8879:1986 Production [82] states that "+//" is used with minimum data that "could be a citation of a national or industry standard, or some other unique identifier assigned in accordance with ISO 9070". The string "+//SUN::SUNSOFT" does not qualify, but then, my understanding is that notes are not necessarily normative. The note with 8879 production [83] states that "-//" is used with minimum data that "could be a (presumably unique) designation created by a trade organisation or other user community, or by an individual". The 9070 clause 5.3 says that unregistered owner names are prefixed "UNREGISTERED::" (correctly used by GCA for their temporary owner names and by James Clark in his DSSSL extensions used in James' Awesome DSSSL Engine). So, technically, even though "-//SUN::SUNSOFT" does not meet the precise criteria set out by 9070, it does meet the criteria in [83]'s note in 8879 "by an individual". So, my read is that "-//SUN::SUNSOFT" is quite acceptable for SGML use (and Jon's point about trademark is so obvious I apologize for my blanket statement before), but "+//SUN::SUNSOFT" is not. ....... 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: gkholman@CanadaMail.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAjHOimAAAAEEAK47HbDtZZB8hJBk+r9Zh7m7QxdFHTaz/m200QQ7J9XX4QYs h6hsuP6ZqBJXyLdmIVMEwR6Ry6oxjKMd6BRJ8OGScD89eIghgbrpMX+900NxM0x2 v3yWO9ki2gKRPrn4vlCXznnmcmsyke0G02T2LefXbgZHyVSqDSOLy8nwuN7dAAUR tClHLiBLZW4gSG9sbWFuIDxhYjk0NUBmcmVlbmV0LmNhcmxldG9uLmNhPg== =IN3T -----END PGP PUBLIC KEY BLOCK----- Date: Fri, 29 Nov 1996 10:14:39 -0600 From: Len Bullard To: w3c-sgml-wg@w3.org Subject: Re: Simple solution? Pub. Idents. vs URN. [Paul Prescod] > The Web has it's own ways to identify objects: let's use them (URLs now, URIs later). Once XML is a success, then we can improve the Web based on our experiences in "standard" SGML implementations. That doesn't always work. Legacy builds it's own momentum and the fait accompli becomes the rule of practice. If the FPI provides capabilities which XML users need, must have, then now is exactly the time to discuss it because it will be very difficult to introduce later. The Sounds Good Maybe Later (SGML) approach has consistently failed in the past. > I think Tim Bray's a) b) and c) points are great and should be used as an acid test > for discussions. Can XML be work without FPI? Yes. Then, because they are not > easily implementable, let's move on and define some linking syntax. I think the Web starts with the URL. The URN has a lot of work behind it. So do FPIs and credible members of the list are asking for it per Jon's instructions to open the issue now. No, let's not descend into long and circular debates, but let's list the requirements, make sure we can do without the FPI if we think it is indeed to hard to implement or will not be supported by a system component that even if hard to build, is only built once, or provided by a system vendor (e.g, is in the tool kit that comes from the platform vendor like MFC objects or Active-X/OLE objects). Tim's points are great, but other than keeping up on the track of system requirements vs document management theory, we still must pursue the FPI until we know that we can safely punt. len bullard From: Martin Cottreau To: "w3c-sgml-wg@w3.org" Subject: RE: Simple solution? Pub. Idents. vs URN. Date: Fri, 29 Nov 1996 12:35:14 -0500 [Len Bullard] >[Paul Prescod] [Martin Cottreau], actually. I just quoted Paul in my original e-mail, but the formatting didn't make that clear. Sorry. >I think the Web starts with the URL. The URN has a lot of work behind >it. >So do FPIs and credible members of the list are asking for it per Jon's >instructions to open the issue now. No, let's not descend into long >and circular debates, but let's list the requirements, make sure we >can do without the FPI if we think it is indeed to hard to implement >or will not be supported by a system component that even if hard to >build, is only built once, or provided by a system vendor (e.g, >is in the tool kit that comes from the platform vendor like MFC >objects or Active-X/OLE objects). Tim's points are great, but >other than keeping up on the track of system requirements vs >document management theory, we still must pursue the FPI until >we know that we can safely punt. >len bullard There are applications of XML that don't require FPIs, the biggest one simply being a replacement for HTML, so people will stop putting processing information in comments. It's not all singing and all dancing, but simple XML with URL (for now...) and style sheets would solve a lot of people's problems right now. I agree we have to consider what impact not having FPI will have, but my gut feeling is that a) the ERB has already done this before deciding to drop them in the first place and b) the Web will evolve towards some sort of FPI mechanism. (wasn't that the point of the original e-mail in this thread?) We shouldn't try to redefine addressing on the Web: it's clear there are other activities within the W3C which may solve the problem. We have to concentrate on making XML easy and useful. According to Jon we only have a six month window to just get a new markup language out there. On FPI, I hope we punt. Date: Fri, 29 Nov 1996 14:05:15 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: FPI's in NOTATION declarations [Quick summary before the blow-by-blow: The issues about FPI/URN versus URL semantics we have been discussing are divisive. On the URN list I have watched years of such discussions with barely a position changed on the issues. If we take the URI approach, we will have a way to a truce, painlessly. Or we could add PUBLIC, but we will not ever get anything like consensus that this is useful, only acclaim form those who want it and acquiescence from those who believe it misguided. I add a new suggestion, that by allowing a _list_ of URIs in the SYSTEM ID, we can have all the advantages of PUBLIC, without the drawback of the new syntax. (I don't know what this drawback is, but some people obviously feel that there is one).] Prologue to the blow by blow: I have been on the URN list for at least 3 1/2 -4 years. As I remember, most of that time was taken up by discussions of how URLs and URNs are really the same thing, only "they work". Much of this discussion reflects an implementors assumption that there must be _one single_ resolution mechanism for names. The idea of names, however, is that the _do not_ depend on a single resolution mechanism. They are an attempt to _label_ resources. A unique label can help you to find something, but cannot guarantee that any particular resolution mechnism will work to find what you seek. This is in the nature of things. Nonetheless, many people find names to be useful. It seems self-evidently correct to me that we _need_ names. It also seems self-evidently mystical, unimplementable, and foolish to the other side. On the URN list I remember no-one changing their minds in years of discussion of these issues. That experience motivates my proposal that we enable URI's in XML, and lobby for an FPI URN syntax now -- the URN proposals are mature enough that we could do this pretty safely. Then those of us who want names would have them. We can then banish the philosophical issues from the XML effort, without shorting either side permanently. The only thing that is wrong with this proposal, is that we lose SGML's fail-safe (a SYSTEM identifier to be used if you can't resolve the PUBLIC identifier). We could keep my compromise proposal and still get this benefit, by allowing more than one URI in our SYSTEM field. The rule would be that _any_ of the URIs in the field could be used, depending on application preference. -- David At 11:40 PM 11/28/96, lee@sq.com wrote: >There are several things that are being confused here: > >[A] whether to allow PUBLIC "some string" syntax in XML; >[B] if such syntax is used, whether to make use of it; >[C] if such syntax is used, whether to retain SYSTEM identifiers; >[D] if such syntax is used, how to interpret the string; >[E] if the string is to be used and interpreted, whether to use > the SGML OPEN CATALOG file format, or a subset of it, to convert > the string into a sequence of data octets >notation discussion deleted >I think that for [A], HTML compatibility may be a good reason to >vote Yes, but that for [B], I have still seen no compelling reasons. >The strongest has been Debbie & Paul P. wanting to be able to >change the meaning of FPIs on the client side. This is convenient if >you have a local copy of something (URN-like), and not very SGMLish >if your copy differs from the "authoritative" copy. In both cases, you >should really be overriding a SYSTEM identifier. Why should you have to change a document to read or preocess it, if you have a copy of a uniquely named resource, and a unique name referring to that resource in the document? You are making a hidden assumption that FPIs don't work by assuming that the local copy will be different. Given the number of people who have already claimed that this procedure _works_ for them, the assumption is not only hidden, but unwarranted (in the sense that counterexamples exist). >If you are referring to the Latin 1 entities and their esteemed colleagues, >though, I agree that it is convenient to have a local copy, and this >can save a not inconsiderable delay in network latency right now. But there are lots of things that have the same properties as the SDATA entities, in different contexts: The TEI DTDs, the CALS DTDs, DocBook, etc. etc. This is one of the things people naturally do. >The difficulty is in having a sufficiently small set of features >to do what is needed without losing too much functionality. > >So, here is my question: > What mechanisms are proposed for including SDATA entity sets? > > I have just agreed to chair an SGML OPEN group trying to come up > with a way of specifying the replacement text for SDATA entities; > if that can be system independent, it may be very useful in a > future version of XML. I should be useful in a current version of XML -- I am waiting for David Birnbaum to come up to date, so he can comment on the desirability of describing characters by strings rather than by numbers. For that matter, SDATA entities fit nicely with the DSSSL character model, which has an open set of characters denoted by strings, doesn't it? > In the meantime, it is likely that you will need to have your own > version of the Latin 1 entities, with replacement text suited for > your local system. This may or may not be the case: some systems use the ISO SDATA text already! > So how do you find it? by matching FPIs according to _some_ resolution system. The resolution system is _NOT_ a part of XML, because names are intentionally decoupled >from resolution systems. > Is it useful to be able to override other FPIs? > Please give real, concrete examples. > >If your name isn't Paul Prescod :-), you can stop reading now... Sorry, but if it's on the list, it's fair game. >Paul Prescod >> The second is that FPIs can be "redirected" by the information consumer or >> maintainer, where as URLs can only be redirected by the information >> provider. > >I already pointed out that this isn't necessarily true. >Also, you are making an assumption about FPIs -- that the user can affect >their resolution. There is nothing in ISO8879 that mandates that -- >quite the reverse, if anytyhing. I haven't checked the FPI standard, >as I don't have access to a copy right now (sorry). redirecting HTTP URLs is certainly possible, but URLs do have a semantics defined, which states a particular resolution mechanism, which is dependend on DNS names, specific data transfer protocols, etc. An FPI does not have _one_ resolution mechanism, so it can be resolved by the user un-"aided" by hardired resolution mechanisms that may not be convenient (like IP connections from a notebook). >> I suppose you could redirect >> URLs, but that seems like a nasty semantic mixup. If an identifier has a >> machine name in it, then the information should, at least logically, come >> from the machine (even if a cache "represents" that machine). >(1) URLs do not contain machine names except by coincidence. > They start with Internet domain names. >(2) A URL is a coordinate in cyberspace. To put it another way, a URL > is indeed a resource's location, but that needn't be a resource > that exists. 1. if you read the URL spec, it tells you how to resolve the name, and it involves DNS. DNS is _not_ a stable namespace, and does _not_ guarantee that DNS names will not be reassigned. 2. If we resolve some URLs by a different mechanism, that is location-independent, and resolution mechanism independent, then we simply have FPIs under another name. >> Some people feel strongly that there should be a syntactic differentiation >> between *names* and *locations*. > >Possibly. We will have that with URNs. Yes, but the current XML spec does not allow URNs. That is one way to address this problem. That is a fix that I have been re-iterating, and re-iterating. I am willing to act like a broken record, but would rather not. >> A concept cannot have a URL. It can only >> have a name, or perhaps a URN. > >I think this shows that you are confused about URLs -- but we should >take that discussion offline. >It is not meaningful to say that a concept has a URL. It is meaningful >to say that you can use a URL to represent a concept, though. >If you must have it point at something, point at a textual description. >> I think that the first time you "click" on a >> "concept:" you'll wish that they were distinct also. >I was referring to URNs, not the HREF attribute of an HTML element. >You are going to have a hard time dereferencing your TeX Book example >FPI too, if you "click on it". Concept is not a valid URL protocol. The fact that that prefix is called a protocol prefix tells you something about the semantic intent of the field, too. Paul is making the point that URLs are supposed to index a resource via a resolution mechanism. Obviously we can use any string as a name, but URLs are not defined to work that way, and the distinction between name assignment and access protocol assignment is felt to be useful by other people. >Obviously that isn't what it is for. Exactly, that is why we need FPIs or URNs, and not just URLs. >> Anyhow, a major benefit of having URLs *and* FPIs is redundancy. I think >> that they should usually be used together. > >We don't need redundant syntax. We need a minimal language that people >actually implement. So why not be compatible with URNs which are in the process of acquiring at least 2 distinct resolution protocols... >> The problem FPIs partially solve >> is *hard*. FPIs provide a partial solution that URLs do not. > >No. FPIs plus the SGML OPEN catalog plus URLs provide a partial solution. >FPIs by themselves are nothing but structured strings, just like URLs, >URNs, telephone numbers and those knotted Mayan things :-) Incan strings. FPIs provide the administrative mechnism for name assignment. The lookup problem is separate. Neither URLs, Quipus (Knotted strings), DNS names, or telephone numbers have an administrative infrastructure supporting persisten unique names. >> > There is no reason why a client-side URL lookaside table could not be >> > used to give this functionality with URLs. >> >> As I stated before, I think that this is attempting to make URLs into >> something they are not. I don't really feel comfortable having clients >> redirect URL accesses. With a separate syntax it is clear from the document >> that a redirection is possible, if your tool supports it. > >But then every XML program needs to support the SGML OPEN catalog, >and we have to work out how to associate an SGML OPEN catalog with >every XML file, and how to do that in the presence of CGI, and how >to store multuple XML document sets in the same directory without >CATALOG conflict, and document it all, and still be under 20pp. No, every XML program that wants to support catalogs must support catalogs. >I am not opposed to solving the problems that need to be solved, but only >to confusing functionality and requirements with mechanism. >If this is what we need to do, we'll do it. The URN requirements docs have a good explanation of the issues. -- 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, 29 Nov 1996 14:51:46 -0500 To: lee@sq.com, lee@sq.com, papresco@calum.csclub.uwaterloo.ca, w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: FPI's in NOTATION declarations At 11:40 PM 11/28/96 EST, lee@sq.com wrote: >> The first is that the first namespace is formally organized and "bigger" >> than DNS, IANA or Internic. > >What does bigger mean? I don't know how to interpret you here. >The IETF is a recognised international standards body. >The FPI namespace is no larger than dns --- they are both countably >infinite, discounting practical length limitations... >I am not sure why the size matters, though, as long as they're big enough. Bigger in that URLs are *by definition* attached to a protocol. "The Internet Assigned Numbers Authority (IANA) will maintain a registry of URL schemes. Any submission of a new URL scheme must include a definition of an algorithm for accessing of resources within that scheme and the syntax for representing such a scheme." FPIs can name things without reference to a particular resolution protocol or method. So a "concept:" URL is not a URL...it is a URN, but does not follow the URN syntax. It is a syntactic/semantic mixup. >> The second is that FPIs can be "redirected" by the information consumer or >> maintainer, where as URLs can only be redirected by the information >> provider. > >I already pointed out that this isn't necessarily true. I think that from a user interface, usability and "correctness" point of view, having information consumers redirect URLs is wrong. Software can redirect to a cache if it is confident that the cache is correct. Since a URL must have a protocol (and usually a machine name) embedded within it, resolving a URL without using that protocol/machine name is a mistake. >Also, you are making an assumption about FPIs -- that the user can affect >their resolution. There is nothing in ISO8879 that mandates that -- >quite the reverse, if anytyhing. I haven't checked the FPI standard, >as I don't have access to a copy right now (sorry). ISO8879 does not mandate it, but it allows it. According to Goldfarb' annotation: "The system uses the other information available to it to determine the actual storage location identifier." Whereas according to the URL spec, http URLs must point to objects which can be resolved according to the http specification. >(2) A URL is a coordinate in cyberspace. To put it another way, a URL > is indeed a resource's location, but that needn't be a resource > that exists. " This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and *access* of resources via the Internet." " This document describes the syntax and semantics for a compact string representation for a resource *available* via the Internet." "The HTTP URL scheme is used to designate Internet resources *accessible* using HTTP (HyperText Transfer Protocol)." >> Some people feel strongly that there should be a syntactic differentiation >> between *names* and *locations*. > >Possibly. We will have that with URNs. But we don't have to wait for URNs. Within closed systems, FPIs do that now. XML FPIs may or may not be useful "across the Internet", but they are immediately useful within systems like that which Jon uses. >It is not meaningful to say that a concept has a URL. It is meaningful >to say that you can use a URL to represent a concept, though. A URN, yes. A URL, no. >I was referring to URNs, not the HREF attribute of an HTML element. >You are going to have a hard time dereferencing your TeX Book example >FPI too, if you "click on it". But you *wouldn't* click on it because it is obviously a *name*. But software quite rightly usually has a direct link from URLs to protocol handlers (perhaps at the OS level). I can imagine clicking on a "concept:" link and having a browser say: "concept:" protocol not installed. >> Anyhow, a major benefit of having URLs *and* FPIs is redundancy. I think >> that they should usually be used together. > >We don't need redundant syntax. We need a minimal language that people >actually implement. How hard is it to read the word PUBLIC, skip the following string (the public identifier) and use the string after that (the URL)? >> >[3] client-side indirection >> >[...] > >> Isn't that what SGML Open is for? > >You mean the CATALOG TR, I assume, rather than the organisation? No, I mean the organisation. Don't they exist to help SGML vendors interoperate? I don't think that there is anything wrong with SGML vendors *not* interoperating in areas where there are no standards. I just wish SGML Open could do more. >> The problem FPIs partially solve >> is *hard*. FPIs provide a partial solution that URLs do not. > >No. FPIs plus the SGML OPEN catalog plus URLs provide a partial solution. FPIs provide a partial solution within an organization or software system, as they always have. They were useful before SGML OPEN catalogs (didn't YOU use them?). SGML OPEN standardizes a resolution scheme, to make them a little more useful by standardizing a resolution system. URN resolvers will make them a lot more useful, by standardizing a global resolution protocol. URLs are, in my opinion, unrelated, except as a useful part of a resolution protocol at some point in the future. FPIs allow you to name things, so that if you happen to have a resolution system (as every SGML user in the world *does*) then you can take advantage of it. If you don't, you can use the URL. >FPIs by themselves are nothing but structured strings, just like URLs, >URNs, telephone numbers and those knotted Mayan things :-) FPIs are like URNs and telephone numbers, but not URLs or people's addressess. I'm not knowlegable about Mayan things, so I'd better not express an opinion. >> As I stated before, I think that this is attempting to make URLs into >> something they are not. I don't really feel comfortable having clients >> redirect URL accesses. With a separate syntax it is clear from the document >> that a redirection is possible, if your tool supports it. > >But then every XML program needs to support the SGML OPEN catalog, >and we have to work out how to associate an SGML OPEN catalog with >every XML file, and how to do that in the presence of CGI, and how >to store multuple XML document sets in the same directory without >CATALOG conflict, and document it all, and still be under 20pp. I am NOT proposing that we should specify a resolution protocol for FPIs anymore than you are proposing a resolution protocol for "concept:" URNs. I AM proposing that people should be able to name their entities and refer to them by name within systems that support entity names (such as all existing SGML systems, URN prototypes, etc.). When you deliver your document over the Internet, though, it darn well better have *URLs* in it, if you want Netscape and IE to be able to do useful things with it. But within your corporation, or within a larger community, like TEI, you can name things and allow "smart" consumer software to resolve the names, where available. Paul Prescod Date: Fri, 29 Nov 1996 12:07:48 -0800 (PST) From: Terry Allen To: dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: FPI's in NOTATION declarations David Durand writes: > I add a new suggestion, that by allowing a _list_ of URIs in the SYSTEM ID, we can have all the advantages of PUBLIC, without the drawback of the new syntax. (I don't know what this drawback is, but some people obviously feel that there is one).] I don't know what the drawback is, either, if the content of PUBLIC is defined as something to be resolved as a URN. However, why change the existing SYSTEM syntax when you can presently have both (in SGML): ]> &pcont; That allows me to write, today, references that can be resolved either way, and will let me avoid having to retrofit all my XML when the XML spec accepts URNs, as it will surely have to if it is to be useful on the Internet. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Date: Fri, 29 Nov 1996 17:00:12 -0500 To: Martin Cottreau , "w3c-sgml-wg@w3.org" From: Paul Prescod Subject: RE: Simple solution? Pub. Idents. vs URN. At 12:35 PM 11/29/96 -0500, Martin Cottreau wrote: >There are applications of XML that don't require FPIs, the biggest one >simply being a replacement for HTML, so people will stop putting >processing information in comments. It's not all singing and all >dancing, but simple XML with URL (for now...) and style sheets >would solve a lot of people's problems right now. And how would an optional FPI extension to the syntax change that? >I agree we have to consider what impact not having FPI will have, >but my gut feeling is that a) the ERB has already done this before >deciding to drop them in the first place and b) the Web will >evolve towards some sort of FPI mechanism. >(wasn't that the point of the original e-mail in this thread?) The Web's FPI mechanism under development is explicitly designed to support namespaces like "FPI:", and to "grandfather in" any existing namespace (phone numbers, license plates, ISBN numbers, FPIs, etc.) In other words, we can put Public Identifiers in the standard today, or put an identical construct in a year from now, and in the meantime, the people who are already using them in the SGML community will be without them, for no good reason. All I am asking for (and I *think* that this is what other are asking for) is a "hook" for public names, not a standard for how to resolve them. >We shouldn't try to redefine addressing on the Web: it's clear there >are other activities within the W3C which may solve the problem. I am not trying to redefine addressing on the Web. FPIs are for use *off of* the Web. They are for internal systems, and inter-company systems, for user groups and application groups. Every document that is published on the Web should have URLs with the FPIs. >We have to concentrate on making XML easy and useful. According >to Jon we only have a six month window to just get a new markup >language out there. I'm not sure what is so special about the next six months, but I highly doubt that an extra paragraph in the spec about an optional, non-parsed, black-box-string, ignore-it-if-you-don't-understand-it string would slow us down much. Think of it as an "addressing processing instruction". >On FPI, I hope we punt. SGML punted on FPIs 10 years ago. It made them optional, and made the mechanisms for resolving them optional and system-specific. That was the right decision then, and it is the right decision now. The fact that people are using them successfully is evidence enough that they are right, and there is *never* a case where the existence of a public identifier makes the parsing or use of a document harder. Paul Prescod Date: Fri, 29 Nov 1996 16:41:16 -0600 From: Len Bullard To: Martin Cottreau CC: "w3c-sgml-wg@w3.org" Subject: Re: Simple solution? Pub. Idents. vs URN. Martin Cottreau wrote: > [Martin Cottreau], actually. I just quoted Paul in my original e-mail, but > the formatting didn't make that clear. Sorry. My fault. I snipped badly. Apologies. > There are applications of XML that don't require FPIs, the biggest one > simply being a replacement for HTML, so people will stop putting > processing information in comments. They will anyway and call it SGML. XML won't replace HTML. It is another text type to enable the application writer or user to choose markup. HTML will evolve on its on and so will the users. No issue. Simple XML with URL (for now...) and style sheets > would solve a lot of people's problems right now. This is so. This will happen. > I agree we have to consider what impact not having FPI will have, > but my gut feeling is that a) the ERB has already done this before > deciding to drop them in the first place and b) the Web will > evolve towards some sort of FPI mechanism. > (wasn't that the point of the original e-mail in this thread?) I don't think so. Evolving the Web with XML might be a laudable result, but isn't much of a design requirement. What I hear Debbie, Jon, Ken and others saying is that the FPI provides functionality they need, some of which, depends on formal registry practices and SGML Open standards for catalogs. Does this undo the URL? Does this preclude the use of the URL? Do the URN and the FPI/catalog conflict? > We shouldn't try to redefine addressing on the Web: it's clear there > are other activities within the W3C which may solve the problem. > We have to concentrate on making XML easy and useful. Right. However, we have on the table, the opportunity to define hyperlinking types that do not yet exist on the Web. Part of that task requires us to ask where the current Web initiatives are, how XML fits with these, and how can our new definitions fit into the existing systems as built and as proposed. XML as a language may spawn many small applications (as is the case for SGML) which share certain features, but are completely different in others. Sharing the hyperlinking definitions is a plus because they are fundamental to the controls and relationships. > On FPI, I hope we punt. Some of the community is saying they need these options. Why, instead of keeping all of XMLs design under the ERB draft, are non-normative appendixes not being prepared by those who need this capability? I don't know why certain options in XML are not exactly that: optional conformance features. You have DSSSL and DSSSL-O. HyTime has conformance options. Any good design has these for the special case capabilities. Why not XML? Is the FPI incompatible with Web addressing? Further, XML is being conceived modularly. Can the modules be separately conforming in the way SGML/DSSSL/HyTime are? James says the FPI is hard to implement. So, it is something not everyone should be required to implement. But this seems to be a system implementation restriction and I don't think we are here to restrict implementors. Why not FPI and URL/URN/etc.? len bullard Date: Fri, 29 Nov 1996 18:19:07 -0500 To: Tim Bray , w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: SGML and XML At 01:42 PM 11/28/96 -0800, Tim Bray wrote: >At 04:16 PM 28/11/96 EST, lee@sq.com wrote: >>We do have to get the same whitespace >>behaviour with and without a DTD, so > >Why? - Tim On the other hand, if we have the option of changing SGML (slightly!) so that we can, Why Not? I would vote for a syntactic distinction between element content and mixed contents *in instances* so that DTD and DTD-less parsers can get the same parse in this regard. Paul Prescod Date: Fri, 29 Nov 1996 18:18:57 -0500 To: dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: FPI's in NOTATION declarations At 02:05 PM 11/29/96 -0500, David G. Durand wrote: >I >add a new suggestion, that by allowing a _list_ of URIs in the SYSTEM ID, >we can have all the advantages of PUBLIC, without the drawback of the new >syntax. (I don't know what this drawback is, but some people obviously feel >that there is one).] I think that the idea of allowing multiple URIs in a reference is a good one. It provides a fallback for network failure. But I also think that we should keep the SGML public identifier syntax that hundreds of products and systems already support. Paul Prescod Date: Fri, 29 Nov 1996 18:19:15 -0500 To: Martin Cottreau , "'w3c-sgml-wg@w3.org'" From: Paul Prescod Subject: RE: Simple solution? Pub. Idents. vs URN. EAt 09:29 AM 11/29/96 -0500, Martin Cottreau wrote: >I disagree. FPI do not qualify as "a simple set of practices". >Design goal number 4 for XML is "It shall be easy to write programs which >process XML documents." (according to the SGML '96 proceedings). FPI > violate that goal as well, as anyone who has pored through SP's code knows. SP's FPI handling is explicitly *not* required by the SGML standard. James Clark's users needed the FPI facility that the SGML standard *allows* and James Clark implemented it. Other conforming SGML systems may have a different FPI resolution mechanism or none at all. At least SGML users and vendors have the choice, which they have overwhelmingly taken advantage of. We should give XML users the same choice (especially since so many of them will be SGML users who already depend on their FPI based systems). Paul Prescod Date: Fri, 29 Nov 1996 18:19:09 -0500 To: lee@sq.com, papresco@calum.csclub.uwaterloo.ca, Charles@sgmlsource.com From: Paul Prescod Subject: Re: SGML and XML Cc: w3c-sgml-wg@w3.org At 04:16 PM 11/28/96 EST, lee@sq.com wrote: >> Whitespace would be handled as follows: >> >> 1. In element content, all whitespace is ignored. >> 2. In data content, all whitespace is preserved. > >Note that without a DTD it is not possible to distinguiish element and >data content. Furthermore, this behaviour makes it impossible to >write a conforming XML program that copies its input to its output unchanged, >just as this is impossible in SGML right now -- no matter how many virgins >you use to tempt those unicorns :-) :-) > >The distinction between whitespace that is returned by the parser (i.e. >emphatically not ignored) but that is not treated as data, and whitespace >that is treated as data, is a useful one, I think. We agree! We can use roughly the same language as for comments: "Comments ... are not part of the document's character data; an XML processor may, but need not, make it possible for an application to retrieve the text of comments. For compatibility, the string "--" (double-hyphen) may not occur within comments." "An XML processor may, but need not, make it possible for an application to retrieve the collapsed or removed whitespace." The situations are equivalent. Whitespace in element context is there for the benefit of those reading the source, like comments. Paul Prescod Date: Sat, 30 Nov 1996 00:19:17 -0500 From: gtn@ebt.com (Gavin Nicol) To: bosak@atlantic-83.eng.sun.com CC: w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com Subject: Re: Revised XML registration I would recommend having charset be required, and also having an optional language field. Date: Sat, 30 Nov 1996 00:32:51 -0500 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@w3.org Subject: Re: SGML and XML >>We do have to get the same whitespace >>behaviour with and without a DTD, so > >Why? - Tim Otherwise systems that do/do not have DTD's will produce different results for exactly the same documents. That will effectively mean that for *canonical* forms, one must always have a DTD. Date: Sat, 30 Nov 1996 08:39:45 +0000 To: dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: FPI's in NOTATION declarations At 14:05 29/11/96 -0500, David G. Durand wrote: >I add a new suggestion, that by allowing a _list_ of URIs in the SYSTEM ID, >we can have all the advantages of PUBLIC, without the drawback of the new >syntax. (I don't know what this drawback is, but some people obviously feel >that there is one).] All you need to do for this is adopt the WG8 Formal System Identifiers approach, which already allows this and more. ---- 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: Paul Prescod Subject: Formal System Identifiers To: mtbryan@sgml.u-net.com (Martin Bryan) Date: Sat, 30 Nov 1996 07:18:49 -0500 (EST) Cc: dgd@cs.bu.edu, w3c-sgml-wg@w3.org > > At 14:05 29/11/96 -0500, David G. Durand wrote: > > >I add a new suggestion, that by allowing a _list_ of URIs in the SYSTEM ID, > >we can have all the advantages of PUBLIC, without the drawback of the new > >syntax. (I don't know what this drawback is, but some people obviously feel > >that there is one).] > > All you need to do for this is adopt the WG8 Formal System Identifiers approach, > which already allows this and more. [HyTime Annex D] is almost 500 lines. Do you want the whole thing? Isn't that a little bit of overkill if the only thing we avoid is adding PUBLIC to the XML spec? Paul Prescod References: [HyTime Annex D]http://www.sil.org/sgml/hi1anfsi.txt Date: Sat, 30 Nov 1996 13:45:00 -0500 To: Murray Maloney From: "Keith M. Corbett" Subject: Re: MIME type for XML Cc: Terry Allen , bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org At 09:36 AM 11/29/96 -0500, Murray Maloney wrote: >At 03:33 PM 27-11-96 -0800, Terry Allen wrote: >>I'm glad you're thinking of this, Jon, but isn't it premature >>to register the MIME type before the spec is finished? >> >>If a MIME type is needed for demos, let's use text/x-xml > >So, how about text/x-ml Be sure to check that the ML folks are not using it. (Q: what MIME content-type is generally associated with computer program sources?) /kmc From: lee@sq.com Date: Sat, 30 Nov 96 19:26:57 EST To: Charles@sgmlsource.com, bosak@atlantic-83.eng.sun.com Subject: Re: FPIs Cc: w3c-sgml-wg@w3.org > My point was that you can make your own publisher prefix without > getting permission from, or paying an annual fee to, a naming > authority. Of course, when you discover that the European division of Sun Life's software division has been using SUN:SUNSOFT as an owner identifier for several years, you'll wish there had been a registry, and all the trademark lawyers in Washington couldn't win you that battle :-) This is why the ISBN is used. I'm not sure whether it will be a problem in practice that an ISBN isn't very obviously hierarchical, so that FPI name servers may each have to know about the entire namespace. Is there any further hierarchy than publisher, private-space? At any rate I agree with Charles here that you should not try and invent your own standard. Lee From: Charles@sgmlsource.com (Charles F. Goldfarb) To: lee@sq.com Cc: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@w3.org Subject: Re: FPIs Date: Sun, 01 Dec 1996 08:11:49 GMT On Sat, 30 Nov 96 19:26:57 EST, lee@sq.com wrote: >> My point was that you can make your own publisher prefix without >> getting permission from, or paying an annual fee to, a naming >> authority. At the time 9070 was published, I checked with the U.S. ISBN agency and was told (in writing) that they would support our use of publisher prefixes for registered owner identifiers, and that there was no fee for the assignment of a prefix. You do not have to be a publisher to obtain one. > >Of course, when you discover that the European division of >Sun Life's software division has been using SUN:SUNSOFT as an owner >identifier for several years, you'll wish there had been a registry, and >all the trademark lawyers in Washington couldn't win you that battle :-) Exactly! Using "-//SUN::SUNSOFT" as an unregistered, not guaranteed unique prefix is perfectly o.k. Where Sun departs from the standard is in trying to claim that it owns the prefix. Only registered owner prefixes can be owned. >This is why the ISBN is used. I'm not sure whether it will be a problem >in practice that an ISBN isn't very obviously hierarchical, so that FPI >name servers may each have to know about the entire namespace. Is there >any further hierarchy than publisher, private-space? An ISBN publisher prefix is a two-level hierarchy, region and publisher. I think there are 10 regions (the first digit). > >At any rate I agree with Charles here that you should not try and invent >your own standard. And there is no need to. Even if GCA-assigned ISO 9070 prefixes are not yet available, ISBN prefixes are. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Paul Prescod Cc: dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@w3.org Subject: Re: FPI's in NOTATION declarations Date: Sun, 01 Dec 1996 08:46:21 GMT On Fri, 29 Nov 1996 18:18:57 -0500, Paul Prescod wrote: >At 02:05 PM 11/29/96 -0500, David G. Durand wrote: >>I >>add a new suggestion, that by allowing a _list_ of URIs in the SYSTEM ID, >>we can have all the advantages of PUBLIC, without the drawback of the new >>syntax. (I don't know what this drawback is, but some people obviously feel >>that there is one).] > >I think that the idea of allowing multiple URIs in a reference is a good >one. It provides a fallback for network failure. The Formal System Identifier (FSI) syntax allows multiple alternative Storage Object Specifications. URI and/or URL can be Storage Managers, and individual multiple alternative URIs and/or URLs can then be Storage Object Specifications within a single FSI. >But I also think that we should keep the SGML public identifier syntax that >hundreds of products and systems already support. We could do both. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- From: Charles@sgmlsource.com (Charles F. Goldfarb) To: Paul Prescod Cc: mtbryan@sgml.u-net.com (Martin Bryan), dgd@cs.bu.edu, w3c-sgml-wg@w3.org Subject: Re: Formal System Identifiers Date: Sun, 01 Dec 1996 08:46:23 GMT On Sat, 30 Nov 1996 07:18:49 -0500 (EST), Paul Prescod wrote: >> >> At 14:05 29/11/96 -0500, David G. Durand wrote: >> >> >I add a new suggestion, that by allowing a _list_ of URIs in the SYSTEM ID, >> >we can have all the advantages of PUBLIC, without the drawback of the new >> >syntax. (I don't know what this drawback is, but some people obviously feel >> >that there is one).] >> >> All you need to do for this is adopt the WG8 Formal System Identifiers approach, >> which already allows this and more. > >[HyTime Annex D] is almost 500 lines. Do you want the whole thing? Isn't that >a little bit of overkill if the only thing we avoid is adding PUBLIC to the >XML spec? We don't need the whole thing, any more than we needed all of 8879. -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- Date: Sun, 01 Dec 1996 09:23:19 -0500 To: Charles@sgmlsource.com, Paul Prescod From: Paul Prescod Subject: Re: Formal System Identifiers Cc: mtbryan@sgml.u-net.com (Martin Bryan), dgd@cs.bu.edu, w3c-sgml-wg@w3.org At 08:46 AM 12/1/96 GMT, Charles F. Goldfarb wrote: >>> >I add a new suggestion, that by allowing a _list_ of URIs in the SYSTEM ID, >>> >we can have all the advantages of PUBLIC, without the drawback of the new >>> >syntax. (I don't know what this drawback is, but some people obviously feel >>> >that there is one).] >>> >>> All you need to do for this is adopt the WG8 Formal System Identifiers approach, >>> which already allows this and more. >> >>[HyTime Annex D] is almost 500 lines. Do you want the whole thing? Isn't that >>a little bit of overkill if the only thing we avoid is adding PUBLIC to the >>XML spec? > >We don't need the whole thing, any more than we needed all of 8879. We used the "essential" parts of 8879. It doesn't make sense to make reference to HyTime Annex D if all we want from it is the ability to specify multiple storage identifiers. Paul Prescod