Date: Mon, 17 Feb 1997 03:30:36 -0500 From: lee@sq.com To: w3c-sgml-wg@w3.org Ooops, sorry, I missed this message before... David Durand suggested: > Perhaps we should leave the resolution strategy to the client, as I can > imagine rather complex, but very sensible strategies. In this case, note that if you give both PUBLIC and a SYSTEM Id, you can be pretty certain that some clients won't be able to resolve it properly, some will fail altogether, and some will do what you wanted. In no case will a remote end user know that the right thing has happened, unless you have an HTML file that points to the SGML file and tells users how to set their preferences! What should happen if _both_ PUBLIC resolution and SYSTEM resolution would return a DTD, but it would be different? This is not an obscure case. For any DTD without a version number in its FPI, I'll go so far as to say that it's the _normal_ case! Obviously if you make ncompatible changes to a DTD, you need to change the FPI. Sometimes I have a #FIXED attribute at the start of a document that contains the DTD version... if I change the DTD, I _have_ to change the document before using the old document with the new DTD... and it's always a really good clue to other errors if I see giving the error DTD-REVISION is a FIXED attribute and must have the value "3.1" Having said all that... for _intranet_ use, Panorama 2.0 now has an option for whether "local" copies of a DTD that you have set up in your own copy of Panorama should override remote ones with the same PUBLIC ID, and also whether to bother looking for Catalog. Only one combination of these preferences works reliably over the web, though. David Durand said: > Depending on how the software caches data, the optimal strategy may be > very complex. I'm now thinking we should not get in the way of processing > agents defining their own strategies _however_ they want to. We need to define a single fixed precedence order for interoperability. If people need to do something different in a particular environment, that's fine, but if there browsing the web, It All Has To Work Automatically. Every Time. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 15 Feb 1997 16:18:55 +0000 (GMT) From: Peter Flynn Subject: Re: Winning battles but losing the war To: w3c-sgml-wg@w3.org At 13:03 13/02/97 -0600, Alex Milowski wrote: >In addition, has anyone noticed that XML *doesn't* show up on the main >web document at http://www.w3.org. You have to dig down in the SGML link >to find XML. It would be a great benefit to have an XML link since we do >have a 1.0 *standard*. This may change once the FAQ is up and running. ///Peter -- > to discover 1000s of internal "homepages" that grew overnight > like magic mushrooms on a rich motherlode of corporate horseshit. Copyright 1996, IBM. All Rights Reserved %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 15 Feb 1997 20:10:49 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: ERB terminology votes The ERB met Sat. Feb. 15th. Present: Bosak, Bray, DeRose, Magliery, Maler, Paoli, Sperberg-McQueen. All decisions were unanimous. We spent most of the time on the issue of terminology detail. Although this was not articulated formally, some underlying design principles seem to have guided us: 1. We should re-use Web terminology where appropriate (thanks to Dan for this input) 2. We should not be afraid of lengthier English compound constructions as opposed to single words, when this makes things easier to understand and explain (thanks to Liora) 3. We should distinguish clearly between terms for the underlying Platonic concepts and those for the syntactic constructs (thanks to Henry) We had discovered that, even at this late date, there was still room for confusion as to which bits were which; so Steve and I, inspired by Henry, cooked up a simple picture that was very helpful: Click here |------------------------------p0-----------------------------------------| |------------------------p1----------------------------------| |----------p2-------------------| |----p3------------------| |----p4-------------| |p5| Thank you for clicking to get here. |------------------------------q0-----------------------------------| |------------------------q1----------------------------| 1. The relationship which the " Subject: Re: 2.4: Link recognition by processor fiat? To: w3c-sgml-wg@w3.org >2.4: Should we allow that processors can decide that something is a link for > their own unspecified reasons, e.g. hardwired knowledge of their own > private element types, or external interaction? Yes. I see no reason why a browser shouldn't decide to scan content for otherwise unmarked URLs or email addresses, and make them into links. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 15 Feb 1997 01:01:33 +0000 (GMT) From: Peter Flynn Subject: Re: What to do given both SYSTEM and PUBLIC? To: w3c-sgml-wg@w3.org At 20:11 11/02/97 -0800, Joe English wrote: >If and when the URN group and/or SGML Open and/or the W3C SGML ERB >hammers out the details of how to do automatic FPI/URN resolution, >it would do an indirect PUBLIC ID -> SYSTEM ID mapping based on whatever >strategy they/we finally come up with. (But quite frankly, I don't >expect to see this happening in my lifetime.) This is pretty much what I always wanted to do for publicly-available DTDs, and I'm wondering if the introduction of XML might be the right time to revive it. What I was looking at was a simple repository, mirrored wherever people wanted, running httpd and ftpd, plus any other useful schemes (gopher? :-) and serving up DTDs on request by following the only standard mapping I have ever seen used in real life to any large extent: You want: -//Foo, Inc//DTD Wondrous Document Type//EN You request http://wherever.org/Foo._Inc/DTD/Wondrous_Document_Type ie the algorithmic resolution used by sgmls, psgml, and others. You can fiddle around with a /registered and /unregistered prefix, perhaps, and obviously /language subdirectories, and perhaps an implicit file type, but the objective is a simple unambiguous 1:1 mapping to handle the 99.9% majority of cases. And a mechanism for POs to submit new DTDs. Then browsers in need of a DTD just do the relevant translate on the FPI and hit the closest server up for the file. Or is this just too easy and I've missed something major? ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Feb 1997 16:15:18 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: XML catalog draft At 11:00 PM 2/11/97, lee@sq.com wrote: >> IC, thus causing it to "fail". I can't think of >> a case where someone who _has_ working public resolution, would prefer to >> use the system ID -- andif they did, it seems they could always ensure that >> any given public ID (or all) would fail to resolve. > >Panorama uses SYSTEM in preference to PUBLIC, and I think this is the >right behaviour. If you don't want the SYSTEM identifier used, >don't give it. What's it for if not to override the PUBLIC resolution? System is fallback for PUBLIC that fails. But as my conversation with Murray showed, it's probably better to tell authors that the two had _better_ be equivalent as applications get the choice of resolution mechanisms. I think my example was quite realistic, and shows that some SYSTEM IDs should be handled before some PUBLIC IDs, and vice versa.... > >> >> > "http://www.foo.org/bar/"> >> > >This is an interesting idea. Better to combine them: > ??? I don't understand. I was intending to give one construct with two variant forms (exactly parallel to Entity declaration forms). >By the way, you forgot the ? at the end of the PI. So do I. So does everyone >else. This syntax won't fly,. well, if _we_ are confused, it is likely from interference with our knowledge of SGML syntax, in which case it won't be that widespread a problem. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 14 Feb 1997 16:33:18 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 1.5: Discuss link characteristics? At 5:42 PM 2/11/97, len bullard wrote: >Steven J. DeRose wrote: >> >> I find that tempting, but a bit too strong. There are at least a few cases >> where the destination depends on other factors, such as implicit links, >> links that depend on user configuration or environment data, etc. Take a >> look at any IETM, or any expert-system-assisted maintenance manual, or >> anything that supports stretchtext. Well, much as I hate to disagree with steve, I think we should either not accomodate such needs, or hedge them with restrictions if we do accomodate them. We should not allow turing-complete languages for determining link destinations. I won't repeat the arguments, but it is clear that web-analysis software is a growth industry. We should make it easier, not harder. Computable links make it harder, and are pretty _unnecessary_ on the web, as far as I've seen. >Right. Depends on the application. The problem of XML link >(and every dammed hypertext standard anyone has tried to >create to date) is that we can't put a hotspot/clink/meatball >(you choose) in running text, expect it to act as a control, >look like a bold font, and pretend to be "just another declaration". Yes. All of those properties should be separately specified, not encoded in the document. > >Action="gosub" is "pernicious" but action="submit" is somehow Ok? They're both pernicious -- but we have to live with microbes and viruses as well as macro-fauna... >Picking victims again aren't we? One can declare a process, or process >a declaration. SGML doesn't care. XML shouldn't either. Yes, but SGML provides no _special_ facilities for processing. This was the point, and I've yet to see any pratical or theoretical reason to abondon this for linking when we agree that it is a good idea for other presentation features. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sat, 15 Feb 97 13:06:27 EST To: w3c-sgml-wg@w3.org Subject: Re: XML catalog draft When PUBLIC and SySTEM are both given, writes Murray Altheim, > [first look at the SYSTEM Identifier] Then, > if the SYSTEM fails, resort to the more generalized process of a catalog > lookup using PUBLIC. > > I believe Panorama has the same behaviour. No. If you give a SYSTEM Identifier, Panorma looks only at that, and ignores the PUBLIC identifier for the purposes of fetching the DTD. The PUBLIC ID is still used as a lookup key in ENTITYRC for navigator definitions and stylesheets. If the SYSTEM ID doesn't work, Panorama gives up. Probably all ViewPort applications are the same, although it's possible in theory for a VP application to change this behaviour. Author/Editor is the same: if the SYSTEM ID is given and doesn't work, the user is asked to specify a "rules file" (the compled DTD) in a pop-up file finder dialogue box. If you treat the SYSTEM ID is being the thing that tells you how to resolve the PUBLIC ID, this is the only approach possible. If the author has specified how to find the DTD, we shouldn't use another one. The whole problem with PUBLIC is that different people use it for different things, and the standard gives no clear guidance. I still think we should avoid PUBLIC. I have yet to see any clear examples that require it. Paul Prescod has come close, with a teaching environment using SGML where the students don't have network access, but it is not clear to me that that example applies to a version of SGML developed especially for web use. In other words, the requests for PUBLIC seem to come from SGML users rather than Web users, and stem largely from backwards compatibility. Jon's system at Sun is interesting, but could equally well be done with URLs as far as I can see. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sat, 15 Feb 97 13:30:28 EST To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? > Hmm, seems I was right - we do *not* have a consensus on this one. I think this is inevitable. There is no consensus on how PUBLIC should be interpreted. Different peole want it as a hook for different things. It's a recipe for disaster. If we open the can of PUBLIC worms, we have to say: * what to do if you are givena PUBLIC Id and no SYSTEM Id * what to do if you are given both * what to do if you are given both and the resulting files are different * give at least one way in which I can put an XML file on the web and someone else 6 months in the future with some new application can use that file, whether or not it has a PUBLIC Identifier. Otherwise... Some people will implement systms that ignore the PUBLIC ID, as David Durand and Paul Prescod suggest, and always require a SYSTEM Id. Some people will implement systems in which the SYSTEM Id is ignored, as Paul Grosso suggests, when both are given. Some people will implement systems in which the SYSTEM ID is used for some things and the PUBLIC for others, as per Panorama today. Some people will implement systems that require end users to edit local configuration files before they can use documents containing PUBLIC Ids, as per Author/Editor today. No document will work on all systems. If we give a set of rules for which to prefer, as I have several times said, we will end up with interoperability, and you will then be safe to use XML in systems where you have no control over the recipient, rather like HTML today. If we don't have PUBLIC at all, this problem goes away. I would rather wait six to twelve months before adding PUBLIC. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 15 Feb 1997 14:05:50 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: XML FAQ Lines: 21 As part of a project on electronic conferencing and publishing I shall shortly be releasing CML on CDROM, along with tutorials, examples, a Java-based CML/XML browser (JUMBO) and some links to public XML pages. I have written a short introduction to structured documents and their processing (from my point of view :-) which is aimed at people who have never heard of SGML. I'd be grateful for any corrections of fact or misrepresentations :-) in the draft at http://www.venus.co.uk/omf/cml/doc/tutorial/xml.html (The CDROM is being distributed by the Royal Society of Chemistry who are committed to SGML-based publishing and to CML/XML. We expect about 5000-10000 to be distributed so that it will reach many libraries. I don't yet know whether there will be spares - probably :-) P. -- Peter Murray-Rust, (domestic net connection) Virtual School of Molecular Sciences, Nottingham University, UK http://www.ccc.nottingham.ac.uk/~pazpmr/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sat, 15 Feb 97 14:35:52 EST To: w3c-sgml-wg@w3.org Subject: Re: 2.3: Link Recognition by PI or other signal? > 2.3 Should we provide a PI or other signaling mechanism whereby a document > can specify that particular elements ought to be processed as link > elements? This should be deferred until yuou've decided what mechanisms are available -- it's the same as the idea of having a summary of mechanisms, which was also deferred. It's useful to be able to do this, though. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sat, 15 Feb 97 14:34:36 EST To: w3c-sgml-wg@w3.org Subject: Re: 2.4: Link recognition by processor fiat? > 2.4: Should we allow that processors can decide that something is a link for > their own unspecified reasons, e.g. hardwired knowledge of their own > private element types, or external interaction? Yes. Example: an encyclopaedia with a dictionary available may let you right-click on any word and get the dictionary definition, even if the word wasn't explicitly marked up. Example: user-defined annotations and links Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 15 Feb 1997 15:30:39 +0000 (GMT) From: Peter Flynn Subject: Re: Winning battles but losing the war To: w3c-sgml-wg@w3.org At 11:47 12/02/97 -0500, you wrote: >I attended that meeting and tried to put in a plug >for XML whenever I could. The W3C folks tried hard >to downplay SGML and XML, but they did not manage >to keep me quiet. It seems clear that they consider >XML a bit of a threat and are trying to minimize >its role. I'm puzzled. I thought XML development was a W3C activity. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 16 Feb 1997 21:24:38 +0000 (GMT) From: Peter Flynn Subject: Re: XML catalog draft To: w3c-sgml-wg@w3.org > really cool on your screen -- although I am not sure how many > different socks you can weave with fixed length weaving patterns :-( Ask the authors of dvi2passap (TeX-to-knitting-machine driver :-) ///Peter -- > to discover 1000s of internal "homepages" that grew overnight > like magic mushrooms on a rich motherlode of corporate horseshit. Copyright 1996, IBM. All Rights Reserved %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 15 Feb 1997 20:10:44 -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: 1.5: Discuss link characteristics? [Martin Bryan:] | The most important thing about CSS is the C (the SS is a pain!). We | need something like C-DSSSL-O and an equivalent C-Interact. For the | latter we need a way for servers to send down a pointer to a default | behaviour and have users say "replace the default behaviour with this | behaviour" (a catalog for Java applets?). I absolutely disagree with this. The SS part of CSS has some merit as an efficient way to specify non-structure-driven typography, but the C part is totally bogus -- not because there is anything wrong with the idea of reader control, but because diddling with stylesheets is the wrong way to go about it. The basic idea of "cascading" is that the publisher specifies a stylesheet and the user specifies a stylesheet and the stylesheet that finally gets applied is somehow halfway between the two. Setting aside all the problems involved in defining the right compromise under every conceivable set of circumstances, this approach simply misunderstands what users need and want. I've been in the publishing business all my adult life and am a whole lot more sensitive to typographical issues than the average reader. But when I pick up an issue of Wired magazine, for example, I don't say to myself, "Gee, I wish I could change this typeface to Garamond and adjust this gradient fill over here." No, I say, "Jesus, I wish I could make the type a lot bigger and get that horrible background to go away so that I could read this." And that's exactly what I say about documents like that on the Web. Even as someone who has spent a lot of time thinking about formatting, I have no desire whatsoever to change the design; all I want to be able to do is to read it comfortably. And in my experience, this level of control is all that the overwhelming majority of users want, too. This is not a stylesheet problem. This is an accessibility problem. And diddling with stylesheets is a horribly inefficient way to solve it. The efficient way is to provide buttons or menu controls that simply let the user scale up all the type sizes and make the wallpaper go away. If you give people that much, not one in a thousand will want anything more, and even that one will bless you for making the UI for the typical case so much easier to use. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 16 Feb 1997 21:24:30 +0000 (GMT) From: Peter Flynn Subject: Re: XML catalog draft To: w3c-sgml-wg@w3.org At 17:23 07/02/97 -0500, Liam Quinn wrote: [...] >What is the catalog _for_? It is for turning a PUBLIC ID into a SYSTEM ID. >That is _all_ it is for. You now have to solve the problem of finding >the CATALOG in the first place, or you have not solved the required >problem. This is where the algorithmic method scores, and I have always been surprised that catalogs are apparently preferred. >If I say, I'd like a SYSTEM ID, telling me I can get one in a CATALOG file >that I don't have is similar, except I need a SYSTEM ID to get the CATALOG, >whereas I need money to get the brandy (usually -- anyone willing to swap >brandy for PUBLIC identifiers??) I'd swap some for a browser that could be configured to obey a user- specified preference for SYS vs PUB and local vs URL. >If SGML users are keeping files around called catalog.soc that are not >SGML OPEN catalogs, that's their problem. This will get you flamed by the Gureaux of Indirection :-) >There are no files on the web -- a URL is not a filename. Now, they >usually map into filenames, but given the following URL to an XML file, >how do I get to the catalog? > http://some.where.com/cgi-bin/documentation/bk12/ch3;level=novice What I said. If it returns a valid XML instance, then it has a DOCTYPE declaration (doesn't it? or subset, in which case a DTD may not arise) with an FPI or a SYSTEM id which is (we hope) a URL. If it's a URL, go get it; if it's a filename, blame the author; if it's an FPI, I still maintain we need a network-accessible {resolver|repository}, a "persistent location in cyberspace" that people can (usually :-) rely on to do the job. LIke you go to rtfm.mit.edu for FAQs... >> > It's still not perfect, but we have backward compatibility issues. >> > Let's do it right for XML. >> >> What is "right"? Your experience with this issue will be useful to us. Panorama is (IMHO) excellent but lacks the ability to recover gracefully >from failed resolution. If it can't find the DTD by catalog or mapping, it should be able to have the user say "It's over here --->{URL}". It also needs a way for the user to say "obey me: fetch the catalog file and fetch the DTDs you resolve from it, and don't try to use cached copies or pretend you can't resolve it: just DO it". I'll (probably unfairly) take this opportunity to {beg|plead} with SQ to bring out a revised Panorama Free which will work with Netscape and MSIE, and has the few resolving buglets fixed. This could be (a) the biggest lead they have to selling the full copy, and (b) would be a great way for us to start showing what XML (under the guise of some other SGML for the moment) can do. > them. This means that if you open > /users/liam/docs/barefoot/ankle1.xml > and it refers to > SYSTEM "walking.dtd" > then an XML application ought tolook for > /users/liam/docs/barefoot/walking.dtd > but if exactly the same unchanged bytestream had been downloaded as > http://www.sq.com/people/liam/ankle1.xml (this is a fake URL) > then the same XML application should resolve "walking.dtd" as > http:://www.sq.com/people/liam/walking.dtd I would have thought this too obvious to need mentioning, but maybe we do need to provide this level of hint. ///Peter -- > to discover 1000s of internal "homepages" that grew overnight > like magic mushrooms on a rich motherlode of corporate horseshit. Copyright 1996, IBM. All Rights Reserved %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 16 Feb 1997 21:24:35 +0000 (GMT) From: Peter Flynn Subject: Re: XML catalog draft To: w3c-sgml-wg@w3.org At 17:18 07/02/97 -0800, Jon Bosak wrote: >This is just a sketch, but consider: [networked resolution outline] >This isn't enough to build a resolution mechanism, but it's enough to >think that building one might be possible. Is there anything >basically wrong with the idea? Nothing, except that this is basically what X.500 tried to do when applied as a routing mechanism with network directory information. That hasn't flown much so far, partly because of the expense, and partly because it has to be 100% populated to work properly. What you describe is a great template but I think the management factors need a lot of work (persuade people it's worth it), and at first sight it looks like it could create a lot of request-response network traffic. ///Peter -- > to discover 1000s of internal "homepages" that grew overnight > like magic mushrooms on a rich motherlode of corporate horseshit. Copyright 1996, IBM. All Rights Reserved %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 17 Feb 97 09:23:31 CST From: Michael Sperberg-McQueen Subject: Re: XML catalog draft To: W3C SGML Working Group On Mon, 10 Feb 1997 20:45:01 -0500 Tim Bray said: >I think we should: > > - allow a PUBLIC keyword/string as appropriate I agree, *if* we also require, or at least recommend, a basic resolution mechanism. Developers with clever new ideas can always add their resolution code as extensions, and take the market by storm. Users should however be able to tell a system "I don't want your (*%&*$^&) extensions, just do the standard thing". Which requires having a standard thing the user can count on. Hence my preference for requiring a standard resolution method. People with existing working systems that use different resolution methods (special directory names, sequential search through the net, the I Ching, sortes Vergilianae, what have you) can continue to use them. If these systems do not support the standard resolution method, they won't interoperate with other XML systems, and so they shouldn't claim to be XML conformant. If they want to be XML conformant they should do some work to ensure interoperability. If we can't bring ourselves to require anything at all, preferring to make developers like us at the expense of users, who will curse the days we were born, at least we should have the nerve to make a recommendation.) > - make a decision as to what should be done when both PUBLIC and > SYSTEM are there PUBLIC before SYSTEM. (Answer to Lee: the system ID is there as a fallback for when I process the document with parsers that don't support socats, and in some cases don't support PUBLIC at all. It is not there to override the PUBLIC id.) (Answer to David: good point about complex resolution strategies. Provide them as a user-selectable option, if you like, but don't *REQUIRE* XML users to live through the same incompatibility hell that SGML users currently put up with. The simple strategy PUBLIC before SYSTEM works and judicious catalog handling can make it work precisely as I like, all the time, as long as the system looks for a local catalog before looking for the catalog that came with the document. Judicious catalog handling would be a lot easier if the socat were an SGML document instance, but that's apparently water under the bridge now.) > - provide a pointer to TR9401 in the write-up on the PUBLIC > identifier, saying that this is one proven-in-practice way to > resolve them I like Paul Prescod's idea (seconded by Jon and others) of publishing the subcommittee draft (with extensions) as a separate W3C WD on catalogs and catalog-based resolution. > - provide support to catalogs by providing a special PI, as > recommended by a couple of WG-ers, to help define the BASE and > thus find the catalog Right. But local catalogs need to come first, or I'll never get my ICADD-enhanced HTML, I'll always get the naked ICADD-deficient HTML on people's servers. > - investigate the problem of what seems like the unnecessary > restrictions on MINIMUM LITERAL; I don't think it's legitimate to > say that a PUBLIC identifier can't be a URN, which this would do. Right. Until and unless WG8 changes the character set for minimum literals, we can't change the set allowed in PUBLIC identifiers. I assume that '#' is forbidden in minimum literals because ISO 646 allows pound-sterling to occur at the same location (or did when 8879 was published; I assume it still does but haven't seen the current 646). Since in general I think the principle of allowing, in minimum literals, only what is really safe across systems, this seems like a good decision by WG8, and a really stooopid one by the designers of URLs. Now that we are stuck with trying to achieve compatibility with this stoopid choice, I think maybe 8879 should allow #. Implementors will know, or should know, to be able to handle pound-sterling as well. ---- Reading the thread on the catalog draft persuaded me we need several things I have not yet found on the net: - a clear tutorial on URL syntax, explaining the canonical positions on URL structure, meaning of '#', '?', ';', etc., preferably with references to the RFCs that actually define the stuff - a clear tutorial on the FPI syntax defined by ISO 9070, for those of use who understand the FPI syntax of 8879 but not 9070. If anyone can suggest URLs where such tutorials can be found, you'll have my undying gratitude. (URLs for clear treatments of MIME and MIME/SGML would also be gratefully accepted.) -C. M. Sperberg-McQueen %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: Ken Holman To: "'w3c-sgml-wg@w3.org'" Subject: RE: What to do given both SYSTEM and PUBLIC? Date: Mon, 17 Feb 1997 11:04:18 -0500 Even though repeating oneself doesn't make an argument any better than the last time, I feel I need to respond to Lee's post. If we don't have PUBLIC at all, there is no way to build system independence. If you want to take control out of the recipient's hands, go ahead and use SYSTEM, but if the sender's system is different than the recipient's system then the recipient gets the problems, not the sender. For those of use who try to _never_ use SYSTEM, the PUBLIC identifier relieves the sender from the problems (or desires) of the recipient. You go ahead and only use SYSTEM, I'll go ahead and only use PUBLIC. What's the problem? >---------- >From: lee@sq.com[SMTP:lee@sq.com] >Sent: Saturday, February 15, 1997 13:30 >To: tbray@textuality.com; w3c-sgml-wg@w3.org >Subject: Re: What to do given both SYSTEM and PUBLIC? > >... >If we open the can of PUBLIC worms, we have to say: >* what to do if you are givena PUBLIC Id and no SYSTEM Id The same thing as if a SYSTEM id points to something that isn't there. >* what to do if you are given both See if the recipient (the one in control of the file, having received it) can satisfy the PUBLIC identifier. If the recipient cannot, then rely on the sender's SYSTEM identifier. >* what to do if you are given both and the resulting files are >different Ignore that fact, because if the recipient doesn't want to control the resolution of the identifier, they need not supply a catalog. >* give at least one way in which I can put an XML file on the web and > someone else 6 months in the future with some new application can > use that file, whether or not it has a PUBLIC Identifier. If the file is marked up with PUBLIC identifiers, then the recipient can modify their catalog as required for the changed environment 6 months after the sender created the file. A lot can change in 6 months. The sender may not know that you have taken a copy of the file, so they cannot tell you how their system has changed, necessitating changes in the SYSTEM identifier. The recipient, on the other hand, can tell from reading the identifier what is required in the catalog to satisfy the PUBLIC reference, modify the catalog appropriately, and use the (perhaps read-only) file without touching the file contents. With only SYSTEM identifiers, it will be necessary to physically modify the file to point to changed locations, thus the recipient is not working with an unmodified file ... how can one guarantee that they haven't otherwise corrupted the information? How can one implemented these modifications if they do not have permissions to change the physical SGML file, when with PUBLIC all they need do is use their own catalog? > >Otherwise... > >Some people will implement systms that ignore the PUBLIC ID, as >David Durand and Paul Prescod suggest, and always require a SYSTEM Id. Such systems will require recipients to modify the sender's files when identifier changes are necessary. >Some people will implement systems in which the SYSTEM Id is ignored, >as Paul Grosso suggests, when both are given. I believe this is not quite what Paul suggests, as I believe that the SYSTEM id is not ignored if the PUBLIC identifier cannot be resolved. I believe that this is the most defensable position. >Some people will implement systems in which the SYSTEM ID is used for >some things and the PUBLIC for others, as per Panorama today. This seems difficult to defend. >Some people will implement systems that require end users to edit local >configuration files before they can use documents containing PUBLIC >Ids, >as per Author/Editor today. If the sender also sends a catalog that allows the file to be used with the sender's system dependencies, the recipient can immediately be as successful as if the sender used SYSTEM identifiers throughout the document. The recipient can be more successful with the untouched document if it only takes a modification to the recipient's catalog to remove the sender's system dependencies. >No document will work on all systems. Documents will gracefully outlive the systems that they are built upon if PUBLIC identifiers are used. ... >If we don't have PUBLIC at all, this problem goes away. >I would rather wait six to twelve months before adding PUBLIC. I don't think we can wait. ....... Ken -- G. Ken Holman mailto:gkholman@microstar.com Chief Technology Officer Microstar Software Ltd. http://www.microstar.com +1(613)596-2233 3775 Richmond Rd., Nepean, Ontario CANADA K2H-5B7 Personal: Box 266, Kars, Ontario CANADA K0A-2E0 mailto:gkholman@CanadaMail.com +1(613)489-2987 PGP: http://www.cyberus.ca/~holman/gkholman.pgp %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 17 Feb 97 09:52:18 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? > From: lee@sq.com > Date: Sat, 15 Feb 97 13:30:28 EST > If we open the can of PUBLIC worms, we have to say: > * what to do if you are givena PUBLIC Id and no SYSTEM Id > * what to do if you are given both > * what to do if you are given both and the resulting files are different > * give at least one way in which I can put an XML file on the web and > someone else 6 months in the future with some new application can > use that file, whether or not it has a PUBLIC Identifier. Net the fact that the XML catalog proposal left practically everything optional/recommended--we could make things required, but the subcommittee got the sense that the ERB and WG didn't want to set any hard requirements in this area--I thought the XML catalog proposal did answer the first three questions above (and your fourth question isn't a question to be answered by a catalog proposal--it's not even clear it's a real question at all). Given the application has decided to use the XML catalog in the external identifier resolution process, the proposal gives (or meant to give) the following answers: > * what to do if you are given a PUBLIC Id and no SYSTEM Id Use the PUBLIC id--what wlse would you expect? > * what to do if you are given both Use the PUBLIC id. (If that fails, the proposal doesn't forbid trying the system id--the proposal doesn't discuss fallback/recovery mechanisms.) If the proposal fails to make this clear, we can reword it. If the ERB decides to prefer system ids, we can change this decision easily without affecting any of the rest of the catalog proposal, but there are many good arguments for preferring public ids, and the subcommittee decided to write the proposal so as to prefer public ids. > * what to do if you are given both and the resulting files are different Why are you asking this question? How did you discover the "resulting files" are different? You must have retrieved both--why? Though nothing prevents an application from retrieving both (perhaps some "external id consistency checking application might want to do this), this is a red herring as far as resolution is concerned. Once you've successfully retrieved something, you've resolved it--end of resolution. So the answer is the same as the answer to the second question. > Otherwise... > > Some people will implement systms that ignore the PUBLIC ID, as > David Durand and Paul Prescod suggest, and always require a SYSTEM Id. > > Some people will implement systems in which the SYSTEM Id is ignored, > as Paul Grosso suggests, when both are given. > > . . . I'll let Durand and Prescod speak for themselves, though given that both of them as well as myself were on the subcommittee that produced the proposal, it seems a simplification at best to make the above characterizations of our positions. I can say that your characterization of my position is inaccurate. For external identifiers in which both a PUBLIC and SYSTEM id are given, I suggest that the application first attempt to resolve the PUBLIC id. In the event that this resolution fails, I would want the SYSTEM id to be tried, though the XML catalog proposal does not require this behavior. We could explicitly recommend this behavior in the proposal if we wish. paul %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 17 Feb 1997 11:46:31 -0500 To: w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: RE: What to do given both SYSTEM and PUBLIC? Forgive me if this is a repost. Doesn't look from my end as though it went out the first time. -Dave At 5:06 PM 2/11/97, Kurt Conrad wrote: >I lean towards giving the public identifier precedence. > >The knee-jerk argument is "why bother" with public identifiers if the system >IDs take precedence. If I can't rely on the catalogs that I create, why >should I invest the effort to maintain them. This would be especially true >in an organizational setting, where such catalogs are increasingly likely to >be managed as shared resources to improve consistency across a collection of >documents. If as a publisher, I don't want the 'standard' component, I should >not code a reference to it. The original intent with SGML, as Goldfarb has explained it more than once, was that the system identifier is king; if it's not present, then the system is to try and impute one with whatever information (like a public identifier) it does have. If I understood correctly, the scenario he envisioned was that one would rarely use both, and if both were present it was because for some reason someone wanted to (presumably temporarily) override the standard system mechanism for resolving the public identifier. SGML's primary original purpose was to be a common interchange format, not only between systems sharing the same storage resources but between disparate systems with wildly different storage resources and organization formats thereof. And a system identifier on one system is not typically of much use on another. Under Goldfarb's scenario, if you're sending a document "off-site", you have a moral obligation to strip out your local system identifiers so as to avoid confusing the entity manager on the receiving system. (But many don't, so the receiver has to.) Point 1. "System identifier" is prime is not just a knee-jerk, lazy reaction. Point 2. The intended XML situation is complicated by the fact that "disparate" systems may be sharing storage systems via the web. From our point of view, a system identifier that is not a URL *should* have been stripped. (Will all who put XML on the web be so considerate?) But if the system identifier *is* a URL, should we have the capability to override it? I think so, and that's why I think the "original scenario" as described above is not the way to go. I think one should be able to override locally, and so, I favor: o If both identifiers are present, try to resolve the public identifier using the local system (catalog, whatever). o If bot are present but the public identifier has no resolution on the local system, then try the system identifier. Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 17 Feb 1997 08:56:43 -0800 (PST) From: Terry Allen To: U35395@UICVM.UIC.EDU, w3c-sgml-wg@w3.org Subject: Re: XML catalog draft Michael wrote: | - a clear tutorial on URL syntax, explaining the canonical positions | on URL structure, meaning of '#', '?', ';', etc., preferably with | references to the RFCs that actually define the stuff Don't know about "clear", but the latest draft of URL syntax revision is ftp://ds.internic.net/internet-drafts/draft-fielding-url-syntax-03.txt | - a clear tutorial on the FPI syntax defined by ISO 9070, for | those of use who understand the FPI syntax of 8879 but not 9070. Maybe even the *text* of 9070? A standard for public naming ought to be public. Dr Mason? | If anyone can suggest URLs where such tutorials can be found, you'll | have my undying gratitude. (URLs for clear treatments of MIME and | MIME/SGML would also be gratefully accepted.) ftp://ds.internic.net/rfc/rfc1874.txt The rest of the MIMESGML work ended up in MHTML. 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 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 17 Feb 1997 16:40:16 +0000 (GMT) From: Peter Flynn Subject: Re: What to do given both SYSTEM and PUBLIC? To: w3c-sgml-wg@w3.org > There is no consensus on how PUBLIC should be interpreted. > Different peole want it as a hook for different things. > > It's a recipe for disaster. No it's not, it's quite clear-cut: > If we open the can of PUBLIC worms, we have to say: > * what to do if you are given a PUBLIC Id and no SYSTEM Id 1. Resolve it, either algorithmically or using a catalog. If that doesn't work then you do indeed have a problem, and the browser can't be blamed for the deficiencies of the author in failing to provide the right info. > * what to do if you are given both 2. Browser-configurable preference. > * what to do if you are given both and the resulting files are different 3. Never occurs: you use the one you get first from (2) above. If you've resolved one successfully, why on earth would you want to fetch the other one? > * give at least one way in which I can put an XML file on the web and > someone else 6 months in the future with some new application can > use that file, whether or not it has a PUBLIC Identifier. That doesn't make sense: the question is surely, how can someone use that file whether or not it has _some kind of identifier_, sys or pub? If you provide no identifier, then the instance has to be well-formed only, and the question falls. > Otherwise... > > Some people will implement systms that ignore the PUBLIC ID, as > David Durand and Paul Prescod suggest, and always require a SYSTEM Id. > > Some people will implement systems in which the SYSTEM Id is ignored, > as Paul Grosso suggests, when both are given. > > Some people will implement systems in which the SYSTEM ID is used for > some things and the PUBLIC for others, as per Panorama today. > > Some people will implement systems that require end users to edit local > configuration files before they can use documents containing PUBLIC Ids, > as per Author/Editor today. > > No document will work on all systems. It strikes me that the authors of such systems need some serious help. Perhaps (as often looks all too frighteningly obvious) they've never actually had to _use_ their software to do a job of work. I'm delighted to see that at long last this problem is being taken seriously. > If we give a set of rules for which to prefer, as I have several times > said, we will end up with interoperability, and you will then be safe > to use XML in systems where you have no control over the recipient, > rather like HTML today. > > If we don't have PUBLIC at all, this problem goes away. > I would rather wait six to twelve months before adding PUBLIC. We may have to agree to disagree on this, but I'm willing to be persuaded. The problem is that the PUBLIC identifier is the "real" (ie formal) name of my DTD. I don't care what filename you give your locally-cached copy, or what filename someone calls their version available via a URL. What is crucial is that if I identify my document as being "-//Davenport//DTD DocBook V3.0//EN" then that is what it is, nothing more and nothing less. Trying to fudge the issue of public DTDs without PUBLIC identifiers, trying to rely on someone's localised concept of what they might want to call the DTD file on the third Tuesday after the full moon, is a guaranteed recipe for disaster. Where private DTDs are concerned, by all means stick with SYSTEM ids. I just cannot believe that people seriously mean that a browser is capable of doing the right thing when given when there must be 100 or more DTDs all claiming to be that. Where we agree 100% is that we need a set of rules, and they're nearly all binary choices, so it's just a large nest if if-then-elses. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 17 Feb 1997 16:54:11 +0000 (GMT) From: Peter Flynn Subject: Re: 1.5: Discuss link characteristics? To: w3c-sgml-wg@w3.org Jon Bosak writes: > I've been in the publishing business all my adult life and am a whole > lot more sensitive to typographical issues than the average reader. [...] > about documents like that on the Web. Even as someone who has spent a > lot of time thinking about formatting, I have no desire whatsoever to > change the design; all I want to be able to do is to read it > comfortably. And in my experience, this level of control is all that > the overwhelming majority of users want, too. Coming from a similar background, I have the greatest sympathy for this point of view. Unfortunately what the users want is not up for consideration by the browser manufacturers, as they're not the ones paying the piper. The business is being driven by whichever departments of corporate buyers happen to have the cash, and if they want BLINK and FONT then they're going to get it, and to hell with whether its readable or not...for the moment: things will change. Did you realise that Mosaic still -- after all this time -- breaks a line after a left parenthesis when the next byte is an STAGO, so putting your email address in inside (parens) can appear very odd. Despite the complaints, this appears to go unfixed forever. Stylesheets and overrides are one small way in which the individual user can influence appearance: they may be evil, but it's a start. We will never get back to the position where all typeset material has passed thru the hands of a professional compositor, but if we can provide (or encourage programmers to provide) better tools, then we may be able to demonstrate a better way of working. What we need right now is someone to do for XML what Marc started to do for HTML: write a browser. My 11-yr-old has started to learn C in the belief that he can write a better browser than Netscape. I have only mildly tried to dissuade him :-) ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 17 Feb 1997 09:54:49 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 6. Addressing & process model issues The picture again: Click here |------------------------------p0-----------------------------------------| |------------------------p1----------------------------------| |----------p2-------------------| |----p3------------------| |----p4-------------| |p5| Thank you for clicking to get here. |------------------------------q0-----------------------------------| |------------------------q1----------------------------| Note that a. the linking element p1 is contained in a document, p0 b. the locator, p3, is segmented in standard URL fashion into p4 and p5. c. the resource, q1, is contained in a document, q0 This raises three issues, two strongly linked. If you'd like to address one of these, please use either 6.1 or 6.2 below for your subject line. 6.1 Are linking element source documents interesting? Since a link is asserted by an element, the element by definition must appear in a document. Let's call this the "linking element source document". In many cases, the identification and address of the source document are of great interest in correct processing of a link. Among other things, authentication and authority issues are of great import when the link is to something like financial information. In laypersons' terms: who said so? Does the linking element source doc need to be discussed in the XML link spec, and do we need to specify any particular required behavior or metadata concerning it? 6.2 Locator fragments and traversal process model In the web, when processing "http://x.com/y/z.html#SEC1", the server returns all of z.html, and the client navigates to an be used around element names in tags, but if you prefer you can use some other method, whith no way to signal this in the file, and by prior arrangement with the recipient arrasnge for interoperability". I.e. it won't work. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 17 Feb 1997 11:19:11 -0800 (PST) From: Terry Allen To: w3c-sgml-wg@w3.org Subject: re 6.2 Tim Bray wrote: N.B., 6.1 is dependent on 6.2.b | 6.1 Are linking element source documents interesting? [ ... ] | 6.2 Locator fragments and traversal process model | | In the web, when processing "http://x.com/y/z.html#SEC1", the server | returns all of z.html, and the client navigates to an Subject: Re: 6. Addressing & process model issues To: w3c-sgml-wg@w3.org >This raises three issues, two strongly linked. If you'd like to address >one of these, please use either 6.1 or 6.2 below for your subject line. I'm using 6. because my response is the same for both 6.1 and 6.2: >6.1 Are linking element source documents interesting? >6.2 Locator fragments and traversal process model Both of these would be great to have, but I simply don't see how we can specify this and still get the cow out of the field and home. In a highly cross-referenced business like research, 6.1 would blow your socks off, and in an era of expensive bandwidth but cheap cycles, 6.2 would be very useful, but both of these are large matters and I'm not convinced we have the resources and time right now to fix them. If XML gets off the ground, maybe they can be bolted onto it at a later stage. ///Peter -- > to discover 1000s of internal "homepages" that grew overnight > like magic mushrooms on a rich motherlode of corporate horseshit. Copyright 1996, IBM. All Rights Reserved %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 17 Feb 1997 22:50:59 +0000 (GMT) From: Peter Flynn Subject: Re: ERB terminology votes To: w3c-sgml-wg@w3.org At 20:10 15/02/97 -0800, Tim Bray wrote: >We had discovered that, even at this late date, there was still room for >confusion as to which bits were which; so Steve and I, inspired by >Henry, cooked up a simple picture that was very helpful: I find this very useful indeed, thanks. All I would add is p6: >Click here >|------------------------------p0-----------------------------------------| > |------------------------p1----------------------------------| > |----------p2-------------------| > |----p3------------------| > |----p4-------------| |p5| |----p6---| as this resolves the interesting ontological debate as to whether the link is in fact the assertion, or whether the link already existed and the linking machinery merely *describes* it: the answer is in the semantics of p6. In the example above, it's an assertion, as "Click here" does not possess any prior identifiable relation with p3. If the content of p1 had said "See section 1 of my book", then the link had prior existence, and the machinery simply describes or implements it. My $0.02, beer to follow. > There is an interesting debate, in the case of the example, as to > whether one or two resources are involved. Strictly by the terms of http://www.w3.org/pub/WWW/Architecture/Terms, I would say p1 _is_ an "addressable resource" but only (a) because is contains an identifier attribute (NAME="foo") and (b) in limited terms, because addressing via CDATA attributes is usually restricted to HTML, and we are expressly not limiting ourselves to "the Web" here. I think this one _will_ fly. ///Peter -- > to discover 1000s of internal "homepages" that grew overnight > like magic mushrooms on a rich motherlode of corporate horseshit. Copyright 1996, IBM. All Rights Reserved %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 17 Feb 97 17:21:21 CST From: Michael Sperberg-McQueen Subject: Re: 2.2 a-b: Link Recognition by Reserved GI? To: W3C SGML Working Group On Wed, 12 Feb 1997 16:53:59 -0500 Tim Bray said: >The ERB schedule calls for voting on these Feb. 19th. >I've take the liberty of grouping a few here that seem totally related. > >2.2.a Should we allow link recognition via a reserved GI? No. (If systems decide to assume that a GI of 'tlink' or whatever it ends up being called in the final spec *is* a tlink in the sense of the spec, that's error recovery in the absence of a required declaration. And I'm not sure it's such a great idea even as error recovery.) >2.2.b If so, what should the set of GI's be? The empty set. -CMSMcQ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 17 Feb 97 17:35:56 CST From: Michael Sperberg-McQueen Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? To: W3C SGML Working Group On Wed, 12 Feb 1997 16:53:57 -0500 Tim Bray said: >2.1.a Should we allow link recognition via a reserved attribute? I assume this means "as described in sec. 2.1 of the draft of 31 January", so xxx is identified as a 'tlink'. Yes. And (hard minimalism) this should be the only sanctioned mechanism. There is no way around allowing this; there is no need for anything more. >2.1.b If so, should we generalize this and say that it's an AF? Only if (a) it really is an architectural form (I remain so thoroughly confused by every HyTimer's attempts to explain AFs that I decline to express an opinion) and (b) we can say what architectural forms are in terms clear enough to stand on their own. On second thought (see next question) no, we should not say so, even if both conditions hold. >2.1.c If so, should we provide an introduction to AF's? Essential, unless there is more tutorial information, of better quality, for allowing people to learn about AFs than I have yet had the good fortune to encounter. We should *also* refer to 10744, of course. Come to think of it, if we *don't* call it an AF, we don't need to explain what AFs are, and we can save ourselves the trouble. A brief note in the appendix titles Notes for Rocket Scientists will suffice; refer to the Extended Facilities Annex there and say wisely but inscrutably "The alert reader will have noted that these are architectural forms as defined in ...". >2.1.d If we allow such recognition, what should the attribute be, and > what should be the values for each element type we define? It should be named 'XML-form' (lose the trailing hyphen, at all events), and it should allow the specification not only of the GI of the architectural form but also the specification of which attributes in the actual DTD correspond to which attributes of the AF. If you think it makes sense to allow users to name their own element types, but not the attributes, think again. The values should be whatever names we give the architectural forms and their attributes. I'd be happy if they were recognizable words, or recognizable abbreviations of words, in some human language, which rules out [a-zA-Z]link. I realize this means 90% of the serious proposals are gone; sorry. -C. M. Sperberg-McQueen ACH / ACL / ALLC Text Encoding Initiative University of Illinois at Chicago tei@uic.edu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 17 Feb 97 17:54:22 CST From: Michael Sperberg-McQueen Subject: Re: 2.3: Link Recognition by PI or other signal? To: W3C SGML Working Group On Wed, 12 Feb 1997 17:11:53 -0500 Tim Bray said: >2.3 Should we provide a PI or other signaling mechanism whereby a document > can specify that particular elements ought to be processed as link > elements? Working through mail thread by thread has its disadvantages. Having read the threads about recognition via GI and attribute and commented before seeing this one, I now have to modify my views. Rats. I think reserved attributes may be the best way to go, but they are best handled with multiple attlist declarations. When and if ISO changes SGML to allow multiple ATTLIST decls, that will be the only mechanism needed. In the meantime, I agree with Paul Grosso and Hasse Haitto that a PI is a good mechanism, and with Paul Grosso that it can be viewed as a substitute for using multiple attlist declarations. (But then, I thought DTD summaries were a good idea, too; this feels very similar.) -CMSMcQ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 17 Feb 1997 20:45:45 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: XML catalog draft | I still think we should avoid PUBLIC. I have yet to see any clear | examples that require it. Paul Prescod has come close, with a | teaching environment using SGML where the students don't have network | access, but it is not clear to me that that example applies to a | version of SGML developed especially for web use. In other words, the | requests for PUBLIC seem to come from SGML users rather than Web | users, and stem largely from backwards compatibility. Jon's system at | Sun is interesting, but could equally well be done with URLs as far as | I can see. No. The whole system depends on the links being specified in terms of location-independent names. That's how they continue to work even when the usual source of a document goes down or the document is moved to another server. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 18 Feb 1997 10:23:53 +0100 To: From: haitto@synex.se (Hasse Haitto) Subject: RE: What to do given both SYSTEM and PUBLIC? lee@sq.com wrote: >I still think we should avoid PUBLIC. I have yet to see any >clear examples that require it. ... To the contrary, using PUBLIC should be encouraged. Its benefits are obvious, and I don't see why one should deny XML such a useful construct. As far as examples go, well, PUBLIC gives you location independence (as pointed out by e.g. Jon), and it improves maintainability (updating a catalog entry is preferable to editing corresponding DTDs or document type subsets referring to a particular entity) . An XML application's catalog is - arguably - under end-user control; this will generally not be the case for URLs in XML documents. ... >Probably all ViewPort applications are the same, although >it's possible in theory for a VP application to change >this behaviour. Just to clarify - Synex ViewPort gives precedence to the public identifier over the system id, *not* the other way around. And yes, an integrator can intercept the entity resolution at either level. Cheers, Hasse %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Tue, 18 Feb 97 09:22:05 GMT To: w3c-sgml-wg@w3.org Subject: Re: 6. Addressing & process model issues 6.1 I agree with Peter, this is vastly too complicated. What in principle is the answer if the linking element is in a grove for a document D1, but actually came via an external entity with a URL pointing to some other document D2 (regress ad infinitum)? Forget it. 6.2 The example introducing this is over-specialised to browser applications. Parsing locators (== specifying their semantics given a particular locator language) is certainly WITHIN our remit; specifying how they should be processed is not, because that takes is over into LINK semantics, which is a different thing altogether. In my view things like client/server balance of responsibilities are so contingent on Application type and technology state as to be completely out of bounds for the kind of standard we're trying to produce. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 18 Feb 1997 15:04:09 +0000 (GMT) From: Peter Flynn Subject: XML FAQ: some questions To: w3c-sgml-wg@w3.org Cc: pflynn@curia.ucc.ie A couple of unanswered questions that I'd like to pre-empt: BTW is there a more recent spec that 961114? I trawled the logs but I couldn't see a reference. 1. What *may*, and what *must* precede the root element in a well-formed XML document? The spec isn't very clear on which PIs are compulsory and which are optional. 2. How may entities be used in XML? ie whether general entities can be included and to what depth. 3. The restriction in WF documents on what elements may occur within what others is not clear (3.2): As a consequence of this, for each non-root element C, there is one other element P such that C is in the content of P, but is not in the content of any other element that is in the content of P. Then P is referred to as the parent of C, and C as the child of P. Here's a non-root element C which we call PARA in some DTD or other. There is _an_other element (not _one_ other) P which we call SECT. PARA is in the content of SECT. So far so good. But SECT has in its content also an element called NOTE. NOTE has PARA in its content model. In other words: +----- stuff +--- HEAD | | +----- stuff +--- PARA docroot -| | +--- HEAD +----- SECT ---+--- NOTE ---+ | | +--- PARA | +--- stuff ... Is this permitted? 3.2 seems to say not: C can only be in the content of P and may not reoccur anywhere on the same branch of the tree. This is going to be an impossible restriction. Or have I misread it? ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Tue, 18 Feb 97 12:32:45 EST To: w3c-sgml-wg@w3.org Subject: RE: What to do given both SYSTEM and PUBLIC? Hasse wrote: > Just to clarify - Synex ViewPort gives precedence to the public > identifier over the system id, *not* the other way around. This is a change between Panorama 1.5 and Panorama 2.0 that I wasn't aware of, and that turns out to be causing support problems already. If XML has PUBLIC and SYSTEM, it's essential that XML says which has precedence. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? Date: Tue, 18 Feb 1997 12:52:39 -0800 From: Joe English lee@sq.com wrote: > If we open the can of PUBLIC worms, we have to say: > > * what to do if you are givena PUBLIC Id and no SYSTEM Id If this happens, it means that the document's author has assumed that the recipient already knows how to resolve the PUBLIC id. So the recipient's software should try to resolve it. If the PUBLIC id can't be resolved, then the document's author's assumption was incorrect. We don't need to specify error recovery in this case. > * what to do if you are given both Try to resolve either one. If that fails, try the other. It doesn't matter which one you try first. (If the software does not know how to automatically resolve PUBLIC ID's -- which I suspect most software will not, since _nobody_ is sure how to do this yet -- then naturally it should try the SYSTEM ID first. Is there a need to put this in the spec though? It seems like common sense to me.) > * what to do if you are given both and the resulting files are different This means that somebody somewhere has made a mistake. We don't need to specify error recovery in this case. > * give at least one way in which I can put an XML file on the web and > someone else 6 months in the future with some new application can > use that file, whether or not it has a PUBLIC Identifier. ?!? How is using the file six months in the future any different from using the file right away? I don't understand the question. > Otherwise... > > Some people will implement systms that ignore the PUBLIC ID [...] Fine. I expect that PUBLIC IDs will be used more for identification ("the official name of this resource is...") than for resolution anyway. > Some people will implement systems in which the SYSTEM Id is ignored [...] Such systems will naturally have to be very good at automatically resolving PUBLIC IDs, which will be tricky, since nobody knows how to do this at all yet. > Some people will implement systems in which the SYSTEM ID is used for > some things and the PUBLIC for others [...] > Some people will implement systems that require end users to edit local > configuration files [...] > No document will work on all systems. I don't see how this conclusion follows from the premises. If the author provides both PUBLIC and SYSTEM id's, the document should work on any system, regardless of which of either or both the system in question uses. --Joe English jenglish@crl.com %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 18 Feb 97 14:47:38 CST From: Michael Sperberg-McQueen Subject: Re: XML FAQ: some questions To: W3C SGML Working Group On Tue, 18 Feb 1997 10:09:27 -0500 Peter Flynn said: >A couple of unanswered questions that I'd like to pre-empt: > >BTW is there a more recent spec that 961114? I trawled the logs >but I couldn't see a reference. Not yet. Soon, we hope. >1. What *may*, and what *must* precede the root element in a > well-formed XML document? The spec isn't very clear > on which PIs are compulsory and which are optional. I read productions 27-31 as meaning: - the root element must be preceded by a prolog - the prolog must begin with an XML declaration i.e. - the prolog may contain PIs, comments, one document type declaration, and white space, following the XML declaration Which part of this isn't clear from the spec? >2. How may entities be used in XML? ie whether general > entities can be included and to what depth. Yes, general entities may be used. No depth restriction is made. >3. The restriction in WF documents on what elements may occur > within what others is not clear (3.2): > > As a consequence of this, for each non-root element C, > there is one other element P such that C is in the content of P, > but is not in the content of any other element > that is in the content of P. > Then P is referred to as the parent of C, and C as the child of P. > > Here's a non-root element C which we call PARA in some DTD or other. > There is _an_other element (not _one_ other) P which we call SECT. > PARA is in the content of SECT. So far so good. > But SECT has in its content also an element called NOTE. > NOTE has PARA in its content model. The paragraph quoted is referring to the elements (instances), not to their types; to actual containment, not potential containment. A PARA contained directly within a NOTE has exactly one parent element: the NOTE. The fact that other PARA elements have or can have parents with GIs other than NOTE does nothing to change the nature of the parent-child relationship. -C. M. Sperberg-McQueen ACH / ACL / ALLC Text Encoding Initiative University of Illinois at Chicago tei@uic.edu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 18 Feb 1997 22:36:16 +0100 To: w3c-sgml-wg@w3.org From: haitto@synex.se (Hasse Haitto) Subject: Re: What to do given both SYSTEM and PUBLIC? Joe English wrote: ... >> * what to do if you are given both > >Try to resolve either one. If that fails, try the other. >It doesn't matter which one you try first. The SGML handbook says (p. 379) that "The system identifier can be omitted if the system can generate it from the public identifier and/or other information available to it." So the actual storage location ought to be deducable >from the public identifier, not the other way round. XML should not differ from SGML on this point. Agreeing on precedence is required if one wishes to be able to override a system identifier (Jon gave a good example in designing redundancy into documentation systems). Cheers, Hasse %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 18 Feb 97 16:18:15 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? > From: Joe English > > . . . > > (If the software does not know how to automatically resolve > PUBLIC ID's -- which I suspect most software will not, since > _nobody_ is sure how to do this yet -- . . . > > . . . > > Such systems will naturally have to be very good > at automatically resolving PUBLIC IDs, which will be > tricky, since nobody knows how to do this at all yet. > > . . . Regardless of what we decide wrt catalogs, Public IDs, and XML, I don't understand Joe's comments above that "nobody knows how to [resolve PUBLIC IDs] at all yet." The first version of the SGML Open TR9401 describing catalogs was published in spring of 1994. At the time it was published, there were already two systems that had implemented it. A fair number of SGML tools now support TR9401. Users have been using SO catalogs for almost three years. Granted, there may well be other ways to resolve Public IDs; there are tools that don't implement TR9401; and flexible, dynamic, internet-wide resolution that handles mirrors and fallbacks goes beyond the scope of TR9401. I am not in the business of defending TR9401 against all comers, but I do think Joe's statements are poor reflections of reality. paul %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: Paul Prescod Subject: Re: What to do given both SYSTEM and PUBLIC? To: jenglish@crl.com (Joe English) Date: Tue, 18 Feb 1997 19:45:52 -0500 (EST) Cc: w3c-sgml-wg@w3.org > (If the software does not know how to automatically resolve > PUBLIC ID's -- which I suspect most software will not, since > _nobody_ is sure how to do this yet -- then naturally it > should try the SYSTEM ID first. I'm not sure how the latter follows from the former. If software does not know how to look up the public identifier, it should use the system ID first and last. There is nothing to specify. But if software knows about both, I would urge that the public identifier should be tried first. a) It will probably be faster (since it will be a catalog lookup more often than a network transaction using a still-under-development URN protocol). b) It provides opportunity for client-side overriding. c) It could allow "smarter" caching (e.g. Document 1 says it needs http://www.w3c.org/HTML.3.2.dtd and Document 2 says that it needs http://www.htmlhelpers.org/html.3.2.dtd, but the two documents have the same public identifier. The browser should know its already got the right document). Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Tue, 18 Feb 97 20:21:50 EST To: w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? > But if software knows about both, I would urge that the public > identifier should be tried first. > > a) It will probably be faster (since it will be a catalog lookup more > often than a network transaction using a still-under-development URN > protocol). No, the still-under-dev. URN protocol is for FPIs, as an alternative for CATALOG; the SYSTEM ID is a plain old URL or file. You still have to fetch the remote CATALOG, which _then_ tells you how to use http (say) for the DTD. So the SYSTEMlookup is likely to be much faster. For performance, do SYSTEM first. For generality, do PUBLIC first. > b) It provides opportunity for client-side overriding. Not unless you allow the user to override the CATALOG fetching. I am assuming that a remote catalog is fetched by some unspecified mechanism (e.g. http) and that the *viewer* user cannot easily override it, short of actually editing a configuration file or something else equally unacceptably arcane to the average home owner :-)... > c) It could allow "smarter" caching If two SYSTEM URls are the same, the existing URL manager will cache them, modulo pragma no-cache and the expiry time from HTTP. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: Paul Prescod Subject: Re: What to do given both SYSTEM and PUBLIC? To: lee@sq.com Date: Tue, 18 Feb 1997 22:47:21 -0500 (EST) Cc: w3c-sgml-wg@w3.org > > But if software knows about both, I would urge that the public > > identifier should be tried first. > > > > a) It will probably be faster (since it will be a catalog lookup more > > often than a network transaction using a still-under-development URN > > protocol). > > No, the still-under-dev. URN protocol is for FPIs, as an alternative for > CATALOG; the SYSTEM ID is a plain old URL or file. I haven't seen anything to indicate that the URN protocol will be limited to FPIs. I would presume it will support all public identifiers. But I think I wasn't clear in my sentence above. I was making the point that for the near future, Public Identifier lookup should be as fast as getting a catalog, which should be comparable in speed to retrieving a graphical "bullet". At some point in the future, we may implement some more complicated URN-based lookup system, and that may be slow. I was just pointing out that we should not presume public identifier lookup will be slow based on a hypothetical URn system. What I didn't say and should have is that public identifiers should encourage many cache hits that would now be misses. This feature, together with the fast retrieval of catalogs, should speed up the resolution of objects. More on both of these points below. > You still have to fetch the remote CATALOG, which _then_ tells you how > to use http (say) for the DTD. So the SYSTEMlookup is likely to be > much faster. For performance, do SYSTEM first. For generality, do > PUBLIC first. The browser can get the catalog immediately while downloading the document. It might even get it before downloading the document. The server could also send the catalog before the client asks for it. I believe HTTP 1.1 allows the server to specify what the client will need and send it before the client asks for it. Either way the overhead of getting a catalog is minimal. It is especially minor if you don't set up a separate connection for it. I would hope that a separate connection for every file will go the way of the dodo very soon. In fact, we should SERIOUSLY consider standardizing an archive format like SDIF-for-the-Web of JAR-for-XML. I am really sick of having to manually figure out what SGML entities, DTDs, and stylesheets go with a particular SGML document. Let's correct that for XML. Wouldn't it be nice to be able to take a single file, with all of the formatting, catalog and entities and use it in Author/Editor/XML or AdeptXMLitor. > > b) It provides opportunity for client-side overriding. > Not unless you allow the user to override the CATALOG fetching. I am > assuming that a remote catalog is fetched by some unspecified mechanism > (e.g. http) and that the *viewer* user cannot easily override it, short > of actually editing a configuration file or something else equally > unacceptably arcane to the average home owner :-)... As long as we allow the user agent to choose its own resolution mechanism, or override our default resolution mechanism, it may present a nice, GUI user interface to the user for overriding public identifier lookups. Heck, it could let the user reroute system identifier looks to an ODBC database in Visual Basic. =) The important thing is that we provide the hook to allow them to use their imagination in this regard. > > c) It could allow "smarter" caching > If two SYSTEM URls are the same, the existing URL manager will cache > them, modulo pragma no-cache and the expiry time from HTTP. Sure. But the example I gave is where they would not be the same. How many copies of popular DTDs and stylesheets will be littered across the Web? Nobody wants to depend on someone else's computer for their document to parse correctly, but neither does it make sense to treat two different copies of html.3.2.dtd differently. The public identifier gives a standard way for tagging a document with a system independent name. Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 19 Feb 1997 02:50:14 +0000 (GMT) From: Peter Flynn Subject: Re: XML FAQ: some questions "Michael Sperberg-McQueen" at Feb 18, 97 02:47:38 pm To: U35395@UICVM.UIC.EDU (Michael Sperberg-McQueen) Cc: w3c-sgml-wg@w3.org Mike S-McQ writes: > On Tue, 18 Feb 1997 10:09:27 -0500 Peter Flynn said: > >1. What *may*, and what *must* precede the root element in a > > well-formed XML document? The spec isn't very clear > > on which PIs are compulsory and which are optional. > > I read productions 27-31 as meaning: > - the root element must be preceded by a prolog > - the prolog must begin with an XML declaration > i.e. > - the prolog may contain PIs, comments, one document type > declaration, and white space, following the XML declaration > > Which part of this isn't clear from the spec? Sorry, I was less than precise in rewording what I was sent. It related to what NAMEs are {required|allowed} in an XML PI in the Prolog? VERSION and RMD seem to be required, ENCODING is obviously dependent, EMPTY I believe has been taken away (so one correspondent said, anyway), are TEXT, NOTEXT, DEFAULT, and IDINFO still in? > > Then P is referred to as the parent of C, and C as the child of P. > The paragraph quoted is referring to the elements (instances), not > to their types; to actual containment, not potential containment. > A PARA contained directly within a NOTE has exactly one parent element: > the NOTE. The fact that other PARA elements have or can have > parents with GIs other than NOTE does nothing to change the > nature of the parent-child relationship. Aaaaaah. Sound of light dawning. Perhaps something about ocurring in the instance could be introduced to make this clear. Many thanks. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 04:28:20 -0500 To: w3c-sgml-wg@w3.org From: Harvey Bingham Subject: Re: 1.5: Discuss link characteristics? [Accessibility] At 20:10 1997/02/15 -0800, you wrote: > >This is not a stylesheet problem. This is an accessibility problem. >And diddling with stylesheets is a horribly inefficient way to solve >it. The efficient way is to provide buttons or menu controls that >simply let the user scale up all the type sizes and make the wallpaper >go away. If you give people that much, not one in a thousand will >want anything more, and even that one will bless you for making the UI >for the typical case so much easier to use. > Jon, you're right on. Give the user controls to shape the presentation as needed for particular means of understanding. Hear, hear. Let the information work with speech readers for the blind. Give it logical organization and linearized presentation usually. Allow asides with easy return. See, see. Provide large type for the low-vision. Allow legible font substitution in place of decorative ones. Add a much larger range of point size than MSIE [about 8-14 pt], even more than 72 pt max of NSN. Allow reverse video as one friend prefers. Get rid of wallpaper and other chart-junk [credit Ed Tufte]. Identify ALT text for all images. Allow color shifting to help the color-blind. Make the accessibility controls accessible. >Jon > Regards/Harvey %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 09:58:25 -0500 (EST) To: w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? From: John_Lavagnino@Brown.edu I suggest that XML allow either a system identifier or a public identifier in a DOCTYPE, but not both. It seems clear from our discussions here that in current and future practice there will always be differing ideas about which to prefer when both appear, based on instinct, experience, and the demands of the situation---and that this divergence of views is not founded in ignorance of SGML or failure to think the problem through, but rather on the range of possible uses for this kind of multiple specification of where to get an entity. To me it looks like a natural for the category of: useful but troublesome SGML features that we prohibit, at least for now, until there's some compelling reason to add them back in despite the possibility for confusion and difficulty of implementation. John Lavagnino %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 10:04:40 -0500 (EST) To: w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? From: John_Lavagnino@Brown.edu To make clearer what I proposed on this topic just now: let's keep both SYSTEM and PUBLIC but drop the SGML option of mixing them. So yes to and but no to John Lavagnino %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 11:08:51 -0500 To: w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: What to do given both SYSTEM and PUBLIC? At 12:52 PM 02/18/97 -0800, Joe English wrote: >If this happens, it means that the document's author >has assumed that the recipient already knows how to resolve >the PUBLIC id. So the recipient's software should try to >resolve it. If the PUBLIC id can't be resolved, then the >document's author's assumption was incorrect. We don't need >to specify error recovery in this case. So far I agree.... > > >> * what to do if you are given both > >Try to resolve either one. If that fails, try the other. >It doesn't matter which one you try first. So two systems that do opposite things are both conforming? That seems very ODA-like (I take that as a negative): "your system can do either the logical structure, or the layout, or both" -- so immediately you end up with non-interoperable yet conforming systems. We should at *least* do what SGML Open did and requir systems to support both and give a way to configure the choice, even if we can't come to a single decision. > >(If the software does not know how to automatically resolve >PUBLIC ID's -- which I suspect most software will not, since >_nobody_ is sure how to do this yet -- then naturally it >should try the SYSTEM ID first. Is there a need to put >this in the spec though? It seems like common sense to me.) If it never tries the PUBLIC because it doesn't know how, then it seems odd to me to say that it should "try the SYSTEM ID first" -- One could just as well say it "tried" the PUBLIC ID first and failed (remarkably quick failure, that), and then went on to the SYSTEM. Your local uncertainty principle at work. > > >> * what to do if you are given both and the resulting files are different > >This means that somebody somewhere has made a mistake. >We don't need to specify error recovery in this case. I'll buy that; but you'll likely never *discover* the error, since if you successfully resolve one ID it is unlikely you'll bother with the other. >Such systems will naturally have to be very good >at automatically resolving PUBLIC IDs, which will be >tricky, since nobody knows how to do this at all yet. Overly strong, I think. There are many schemes that are known to work, and it is more a question of choosing than of determining feasibility. Walk into any bookstore with an ISBN in hand, for example, and in a few seconds (maybe a minute if they're on a slow modem) you'll know all the publication info, and probably what shelf it's on if it's there, or which branch of the same bookstore chain has it. Or send email to a DNS address, and usually it gets there. Table lookup is not a big deal, even for huge tables; and there is a lot of knowledge in CS on how to distribute such tables. Steve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 11:59:52 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 2.3: Link Recognition by PI or other signal? At 2:10 PM -0800 2/12/97, Tim Bray wrote: >The ERB schedule calls for voting on these Feb. 19th. > >2.3 Should we provide a PI or other signaling mechanism whereby a document > can specify that particular elements ought to be processed as link > elements? yes. _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 11:42:32 -0500 To: "Steven J. DeRose" , w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: What to do given both SYSTEM and PUBLIC? At 11:08 AM -0500 2/19/97, Steven J. DeRose wrote: >At 12:52 PM 02/18/97 -0800, Joe English wrote: >>Try to resolve either one. If that fails, try the other. >>It doesn't matter which one you try first. >So two systems that do opposite things are both conforming? That seems very >ODA-like (I take that as a negative): "your system can do either the logical >structure, or the layout, or both" -- so immediately you end up with >non-interoperable yet conforming systems. We should at *least* do what SGML >Open did and requir systems to support both and give a way to configure the >choice, even if we can't come to a single decision. >>> * what to do if you are given both and the resulting files are different >> >>This means that somebody somewhere has made a mistake. >>We don't need to specify error recovery in this case. > >I'll buy that; but you'll likely never *discover* the error, since if you >successfully resolve one ID it is unlikely you'll bother with the other. It means that authors who intend to use both SYSTEM and PUBLIC are duty-bound to either use (and test) a programmatic solution that ensures they are identical, or must test the document with both public-preferred and SYSTEM-preferred resolution in place. In other words, it's like broken link testing -- a pain, but one that enables sensible implementation strategies... So yes, author error may cause conforming implementations to do different things. This is no worse than the C statement j = j++ + j++; which can return a variety of values and have a variety of side-effects on conforming C compilers. In this case, since the author has control, it's probably better to just do _something_ instead of worrying about doing the _right thing_. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 12:01:43 -0500 To: Tim Bray , w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 2.4: Link recognition by processor fiat? At 2:10 PM -0800 2/12/97, Tim Bray wrote: >The ERB schedule calls for voting on these Feb. 19th. > >2.4: Should we allow that processors can decide that something is a link for > their own unspecified reasons, e.g. hardwired knowledge of their own > private element types, or external interaction? We can't prevent processors from doing this, but if they do it's not XML linking. We are in the business of defining a way to recognize links, not a blanket endorsement for other ways of marking links. We should not talk about this at all, even to forbid such recognition, even though it is a bad idea. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 11:57:32 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? At 1:52 PM -0800 2/12/97, Tim Bray wrote: >The ERB schedule calls for voting on these Feb. 19th. >I've take the liberty of grouping a few here that seem totally related. > >2.1.a Should we allow link recognition via a reserved attribute? If we can use separate attribute declarations in the internal subset to add the attribute. This requires small changes in XML (require processing of delcarations in internal subset, allow multiple attlist definitions). >2.1.b If so, should we generalize this and say that it's an AF? Yes, but _no_ attribute renaming. We should explain what notation and features we are using directly, but not that we are "comaptible" with HyTime AFs and refer tot he standard for those who are intersted. Reading about HyTime _must not_ be a prerequisite for XML linking. >2.1.c If so, should we provide an introduction to AF's? No, we should just describe what _we_ are requiring. The HyTime revision includes masses of stuff that we don't need, and thus shouldn't talk about. I am not a fan of the HyTime AF conventions, and don't see that there has been enough practical experience with AF use to make a good definition of a general AF facility. We need a "flag attribute", to enable the AF (or a PI if we can't get the separate attlists -- I point to my earlier proposals without repeating them). We need attribute declarations for the elements themselves. We should not have linkends as sub-elements (incompatible w/ HyTime, and not much gain, but we'll get to that issue later), or Linkgroups (no gain to anyone, despite people's intuition that it makes implementation easier). Therefore we can leave the content models of all linking elements to the user of the AFs, and further simplify the AF features we are using, and thus the linking standard. >2.1.d If we allow such recognition, what should the attribute be, and > what should be the values for each element type we define? I have forsworn naming suggestions. _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 97 10:49:47 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? > From: Paul Prescod > > In fact, we should SERIOUSLY consider standardizing an archive format like > SDIF-for-the-Web of JAR-for-XML. I am really sick of having to manually > figure out what SGML entities, DTDs, and stylesheets go with a particular > SGML document. Let's correct that for XML. Wouldn't it be nice to be able > to take a single file, with all of the formatting, catalog and entities and > use it in Author/Editor/XML or AdeptXMLitor. It sure would! The SGML Open TR9401 catalog (see "Issue B" of TR9401) can be used to do this. A catalog can be created that points to all the bits and that has a DOCUMENT entry to point to the entity in which parsing shall start. If you point an application to such a catalog (and nothing else), the application should have all it needs to work. [Vendor-specific disclaimer: at the present time, ArborText's Docarch tool is currently needed to handle such a situation since you must first "Import" the various doctype files and "Generate" a compiled doctype. Once the compiled doctype is created, you can then point Adept itelf to such a catalog. Improvements in this process are planned.] Another alternative (and one I would support) is some sort of MIME-SGML interchange standard. The experimental RFCs 1872, 1873, 1874 outline one such method. Whether using a TR9401 catalog and/or a MIME solution, there needs to be some "packing" and "unpacking" process that determines what all is needed in the package, finds and collects all the bits, and generates the interchange package and/or catalog or expands the interchange package back into a bunch of files appropriately placed and named. That is, defining a packing mechanism doesn't solve the problem if it still requires manual effort to create or process the package. I wouldn't add such packing/unpacking requirements to XML, so the definition of XML and the solution to interchange packaging seem to be separable issues. paul %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: Paul Prescod Subject: Re: What to do given both SYSTEM and PUBLIC? To: paul@arbortext.com (Paul Grosso) Date: Wed, 19 Feb 1997 12:42:54 -0500 (EST) Cc: w3c-sgml-wg@w3.org > Whether using a TR9401 catalog and/or a MIME solution, there needs > to be some "packing" and "unpacking" process that determines what > all is needed in the package, finds and collects all the bits, and > generates the interchange package and/or catalog or expands the > interchange package back into a bunch of files appropriately placed > and named. That is, defining a packing mechanism doesn't solve the > problem if it still requires manual effort to create or process the > package. I wouldn't add such packing/unpacking requirements to XML, > so the definition of XML and the solution to interchange packaging > seem to be separable issues. I agree that it can be specified separately, I just hope it is specified. The SGML world seems to have come up with several elegant solutions to this problem of packaging entities: mime-SGML, SDIF, TR9401, etc. Whereas the "Java world" as represented by Sun just chose a solution based on readily available software (.zip with no compression) and got on with it. I would really like it if we could just choose a solution and "get on with it." I don't care if it is as simple and inelegant as "tar" (in fact, I would prefer a system that was as simple as tar). If, as you suggest, the solution is specified as a separate document, "XML-Package", then it can be replace at any future time with "XML-OLE" or "XML-Bento" or whatever else is more advanced. Paul Prescod %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Wed, 19 Feb 97 13:20:34 EST To: w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? > Whereas the "Java world" as represented by Sun just chose a solution based > on readily available software (.zip with no compression) and got on with > it. I would really like it if we could just choose a solution and "get > on with it." I don't care if it is as simple and inelegant as "tar" (in fact, > I would prefer a system that was as simple as tar). I agree. But please do note that downloading a single zip file with all the documents, images, dtds and style sheets is likely to be scads slower than downloading the same thing in html with HTTP 1.1 or HTTP NG, because the browser can download images at the same time as it is downloading the style sheet and the document. Putting everything in a tar precludes parallel processing, and that's a real problem. Try the Opera browser for Windows if you want to see how fast an HTML browser can go. If netscape is a porsche, opera is concorde :-) I hope we don't require the use of a single packaged file. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 15:03:15 -0500 To: dgd@cs.bu.edu (David Durand), "Steven J. DeRose" , w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: Re: What to do given both SYSTEM and PUBLIC? At 11:08 AM -0500 2/19/97, Steven J. DeRose wrote: >At 12:52 PM 02/18/97 -0800, Joe English wrote: >>Try to resolve either one. If that fails, try the other. >>It doesn't matter which one you try first. >So two systems that do opposite things are both conforming? That seems very >ODA-like (I take that as a negative): "your system can do either the logical >structure, or the layout, or both" -- so immediately you end up with >non-interoperable yet conforming systems. One of my cars requires that I select the gear ratio from a limited numberof choices. The other one gives me only a small amount of control over what gear ratio it selects automatically by a built-in algorithm. If you get a Volvo 960 (and undoubtably many others) you can choose to have absolute control over the gear ratio selection or to let the built-in algorithm make the selection. All three possibilities are useful, make for useful product differentiation, and I for one would be upset if someone felt that they had to mandate which kind of vehicle I owned. Yet they are not directly interoperable systems; I can't count on a user interfacing correctly with one if he or she has developed his or her inteface for the other. (Note: this is an analogy, not an exact parallel. Don't give me grief just because the analogy can be overextended to the point where there are differences.) Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 19 Feb 1997 21:24:46 +0000 (GMT) From: Peter Flynn Subject: Re: What to do given both SYSTEM and PUBLIC? To: w3c-sgml-wg@w3.org Joe English wrote [...] > (If the software does not know how to automatically resolve > PUBLIC ID's -- which I suspect most software will not, since > _nobody_ is sure how to do this yet -- . . . [...] > Such systems will naturally have to be very good > at automatically resolving PUBLIC IDs, which will be > tricky, since nobody knows how to do this at all yet. This puzzles me a bit. Emacs psgml-mode resolves FPIs faultlessly and I've been using that method increasingly over the last year. For software that doesn't support it, but uses socats, I have entries for the FPIs. Can someone who knows more about the background say why resolving "-//Foo, Inc//DTD Wonderful Document Type//EN" into /usr/local/lib/sgml/Foo,_Inc/DTD/Wonderful_Document_Type is A Bad Thing, as it seems most people decry it (leave aside the Win3.x and VM/SP users who don't have access to long filenames, as those systems clearly have a problem, and leave aside the problem of write access to /usr/local/lib/sgml, as that part of the filetree is parameterizable). ///Peter -- > to discover 1000s of internal "homepages" that grew overnight > like magic mushrooms on a rich motherlode of corporate horseshit. Copyright 1996, IBM. All Rights Reserved %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 20:53:22 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Java-based XML browser and implementation comments Lines: 116 I have just completed a preliminary distribution kit for my XML/CML browser JUMBO (Java Universal Markup Browser for Objects) and you are welcome to have a play. The points relevant to the WG are: - it is completely portable and installation-free (thanks to Java/Netscape). All you need is Netscape 3 or MSIE equivalent. You don't even need to know that Java exists, just how to click. - it makes use of 'links' in two examples. These are: (a) 1->many unidirectional link (the endpoint is a set of tokens in an Element (actually atoms in a molecule)) (b) a link that points to endpoints in two different elements (Obviously I am waiting with great enthusiasm to see the XML way of doing it properly and will start recoding as soon as some white smoke emerges). - it has a prototype of an element-based graphical editor (i.e. one element can be dragged to be a child or sibling of a non-ancestor. Or an element can be dragged to the trash. Similarly elements can be dragged to the clipboard and legacy files imported to the clipboard. There is a crude check on content validation, but I would hope to bolt NXP in to do the validation. - there are some examples of XML. - there are legacy files converted to XML-in-memory which can then be written out as XML. I would be very grateful for feedback and bug reporting. (I don't need to know that my skill as a GUI builder could be improved - I didn't intend to develop one :-) and it just happened.). The system takes about 30 seconds to install after download from: http:://www.venus.co.uk/omf/cml/moltest.tar.gz (please don't announce this) You then have to gunzip and untar - Winzip will do this for you. Then you have to click on index.html. (BTW you don't need to know any chemistry since I have also included scene1.sgm from Julius Caesar :-) (The linking demos are functgroup.html and vamp.html). [Note. I have run this on Netscape 3 on SUN, SGI, Mac, W95 and it works surprisingly well. (It was this lack of portaibility that meant I had to abandon costwish.) However there still are a number of problems on some platforms. The window handling is especially variable as are the speeds - you may be surprised which machine I rank bottom. So it may happen that you get crashes or poor performance - some of this may be due to client-side settings which are beyond me. the upside, I hope is that 5000 copies will be distributed shortly.] Installation experiences ------------------------ These XML files are WF (and *were* valid against cml.dtd and sgmls). I have not yet managed to validate them against NXP as there is a lot of editing to do. The CML distribution included: - CML.DTD which 'includes' TecML.DTD which 'includes' HTML20.DTD 'inclusion' is through parameter entities. - an SGML.DECL (at least that can be junked :-) - a Catalog using PUBLIC entities for: = the DTDs = various EntitySets (e.g. IsoLatin1). - about 10 files of attribute values and content models which are 'included' (this is so I can edit these files rather than the DTD.) Why do it this way? Because I need their contents for the postprocessor. I have only been converting for a few hours, and I'm still struggling with bits of the spec, using NXP as an arbiter. The things I have discovered are: - all the comments need changing. This cannot always be done automatically. - the conditional sections require no white space round the PEReference (trivial now that I know, but it took a while to spot it). - the tag model (the '- -' or '- O' - whatever it's called) needs excising. - the loss of PUBLIC is a total pain. When I set up the stuff about 12-18 months ago, I decided to use the catalog because it was the 'proper way', and I came to believe in this. (My own view about PUBLIC is very simple and naive - it tells you *what document to use* (not where to get it). I think this is important.) So all the references to Entity sets, etc are through PUBLIC. They all have to be changed. - the CATALOG needs changing (no ENTITY allowed, no '--') - the entity sets need changing (no '--', no SDATA). The main point is that I thought that XML was a subset of SGML and 5 minutes with vi would fix the files. Not so. I think people will not be very happy to have to have two version of files for entity sets. I suspect there will be a real need for tools that 'convert SGML to XML'. Because I need my DTD construction to be flexible, it's hairy and I would prefer to keep it in 'SGML', converting to XML when necessary or on the fly. Is there a tool which 'normalises' DTDs (i.e. resolves all the parameter entities) and outputs a 'processed' DTD? (While I'm on that, is there a tool which can parse the DTD so it can be used by a program?). A general conclusion is that you will need to give a good deal of help to people who want to convert from SGML. There are bits which aren't obvious and bits which you might expect to be there and aren't. This conversion is not just the document instances, it's the whole lot. (This isn't meant to sound negative... but it will be even harder for PhaseII). NB. I am not sure where the decision process is in Phase II, but I am right in assuming that it will contain most of Appendix A, and that the syntax will be essentially the same?? I particularly don't want to lose anything in A.1.1.2. If so, I can start hacking some primitive internal search tool. It may be premature, but are *groves* almost certainly a part of XML-phaseII? (4.5) or is it simply allowed to build a query tool based on Appendix A? If not, someone is going to need to give me a tutorial as 10179 is not a Webhacker-friendly document. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Wed, 19 Feb 97 16:57:09 EST To: w3c-sgml-wg@w3.org, John_Lavagnino@Brown.edu Subject: Re: What to do given both SYSTEM and PUBLIC? John_Lavagnino@Brown.edu wrote: > To make clearer what I proposed on this topic just now: let's keep > both SYSTEM and PUBLIC but drop the SGML option of mixing them. That's sensible, although there would then be no standard XML way of processing a document with PUBLIC -- you'd have to use a resolution mechanism to get a CATALOG file and then a TD, and we haven't got one. Maybe we can live with that? Just don't use PUBLIC if you want things to work for other people? It would be like a sort of processing instruction. > [...] no to > > This is illegal anyway in SGML, unfortunately. If you could give multiple external identifiers, our priority problem would be solved, as we could say that it's left to right -- i.e., in your example, foo.dtd would be preferred, but had PUBLC been first, it'd've been the other way round. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 19 Feb 1997 22:00:07 +0000 (GMT) From: Peter Flynn Subject: Re: 2.3: Link Recognition by PI or other signal? To: w3c-sgml-wg@w3.org At 11:59 19/02/97 -0500, David Durand wrote: >At 2:10 PM -0800 2/12/97, Tim Bray wrote: >>The ERB schedule calls for voting on these Feb. 19th. >> >>2.3 Should we provide a PI or other signaling mechanism whereby a document >> can specify that particular elements ought to be processed as link >> elements? > >yes. I agree. Essential. AFs revisited :-) ///Peter -- > to discover 1000s of internal "homepages" that grew overnight > like magic mushrooms on a rich motherlode of corporate horseshit. Copyright 1996, IBM. All Rights Reserved %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 16:13:48 -0600 From: Len Bullard To: Peter@ursus.demon.co.uk CC: w3c-sgml-wg@w3.org Subject: Re: Java-based XML browser and implementation comments Peter Murray-Rust wrote: > > I have just completed a preliminary distribution kit for my XML/CML > browser JUMBO (Java Universal Markup Browser for Objects) and you are > welcome to have a play. The points relevant to the WG are: > The main point is that I thought that XML was a subset of SGML and 5 > minutes with vi would fix the files. Not so. I think people will not > be very happy to have to have two version of files for entity sets. I > suspect there will be a real need for tools that 'convert SGML to XML'. [snip] > A general conclusion is that you will need to give a good deal of help > to people who want to convert from SGML. There are bits which aren't obvious > and bits which you might expect to be there and aren't. This conversion is > not just the document instances, it's the whole lot. (This isn't meant > to sound negative... but it will be even harder for PhaseII). That is bad news. If XML is a complete break with SGML, then there is trouble ahead. The San Diego conference could have some rough moments if the attendees are knowledgeable. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 19 Feb 1997 22:26:50 +0000 (GMT) From: Peter Flynn Subject: Re: What to do given both SYSTEM and PUBLIC? To: w3c-sgml-wg@w3.org Paul Prescod writes: >Whereas the "Java world" as represented by Sun just chose a solution based >on readily available software (.zip with no compression) and got on with >it. I would really like it if we could just choose a solution and "get >on with it." I don't care if it is as simple and inelegant as "tar" (in fact, >I would prefer a system that was as simple as tar). I agree, but the solution needs to be acceptable to authors and implementors. If it doesn't make sense to them, it won't fly, and right now, the dingdong over PUB vs SYS comes out as a straight play between FPIs and URLs. I can guess which one NS and MS are going to pick. Sun did an excellent job on packaging, except picking the filetype ".zip" for something that conflicted majorly with the established practice (read: expected behavior), which was a really crass thing to do. Let's not make the same mistake. ///Peter -- > to discover 1000s of internal "homepages" that grew overnight > like magic mushrooms on a rich motherlode of corporate horseshit. Copyright 1996, IBM. All Rights Reserved %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 16:29:42 -0600 From: Len Bullard To: Peter Flynn CC: w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? Peter Flynn wrote: > > Paul Prescod writes: > > >Whereas the "Java world" as represented by Sun just chose a solution based > >on readily available software (.zip with no compression) and got on with > >it. I would really like it if we could just choose a solution and "get > >on with it." I don't care if it is as simple and inelegant as "tar" (in fact, > >I would prefer a system that was as simple as tar). > > I agree, but the solution needs to be acceptable to authors and implementors. Hmm. You could find some and ask them. Of course, the love of the ear is to hear what it heard before. That question usually sets off the platform wars. Gzip is popular because free, but not a great way to pack up multiple files, so in reality, just compression. Pkzip can pack multiple files and compress, but it's not free. What Lee said should be considered: fat packets piss off the NetLords. Small, "guaranteed overnight deliveries" are the way of the web. > If it doesn't make sense to them, it won't fly, and right now, the dingdong > over PUB vs SYS comes out as a straight play between FPIs and URLs. I can > guess which one NS and MS are going to pick. Don't let them pick. Pick smart here. Pick the one that can be implemented fastest in XML 1.0. URLs are well-defined and can do the first set of jobs. Public are what is needed for absolute independence. Now, when is it often necessary to be independent at transfer? When is it necessary in local storage? When is it necessary when archiving? > Sun did an excellent job on > packaging, except picking the filetype ".zip" for something that conflicted > majorly with the established practice (read: expected behavior), which was > a really crass thing to do. > Let's not make the same mistake. You mean there is another mistake we can make? len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 19 Feb 1997 23:19:50 +0000 (GMT) From: Peter Flynn Subject: Re: What to do given both SYSTEM and PUBLIC? To: w3c-sgml-wg@w3.org At 16:57 19/02/97 -0500, Liam Quinn wrote: >John_Lavagnino@Brown.edu wrote: > >> To make clearer what I proposed on this topic just now: let's keep >> both SYSTEM and PUBLIC but drop the SGML option of mixing them. > >That's sensible, although there would then be no standard XML way of >processing a document with PUBLIC -- you'd have to use a resolution >mechanism But you have to do this with all apps of SGML: it's what a PUBLIC id is _for_. >to get a CATALOG file and then a TD, and we haven't got one. I still don't see the problem with being directive about this: means very simply: `This document is constructed according to this DTD: "-//Foo, Inc//DTD Ab Fab Stuff//EN". If you can resolve this with an algorithm or a catalog, because you've encountered it before and stored or cached it, or because your smart[ass :-] system already knows about it, fine, go right ahead and use it. If not, the file is here: "ftp://ftp.foo.com/dtds/abfab.xxx"', where "xxx" can be open-ended, but we define some common ones "dtd" "ent" "socat" etc, so that authors with complex or multi-file DTDs can provide sequenced catalog entries starting with an SGML Declaration (whoops, we don't use them) and ending with the last character entity file. Or whatever. This is simple, straightforward, and will work. If an author has made up a DTD and has no FPI, use SYSTEM and the app will _have_ to go fetch it. If authors are careless enough to provide obscure FPIs and no system ids, they deserve all the opprobrium they get :-) ///Peter -- > to discover 1000s of internal "homepages" that grew overnight > like magic mushrooms on a rich motherlode of corporate horseshit. Copyright 1996, IBM. All Rights Reserved %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 19 Feb 1997 23:19:48 +0000 (GMT) From: Peter Flynn Subject: Re: Java-based XML browser and implementation comments To: w3c-sgml-wg@w3.org At 20:53 19/02/97 +0000, Peter Murray-Rust wrote: [...] >on the fly. Is there a tool which 'normalises' DTDs (i.e. resolves >all the parameter entities) and outputs a 'processed' DTD? (While I'm >on that, is there a tool which can parse the DTD so it can be used by a >program?). Yes, NORMDTD by Richard Light. DOS program, some small bugs, but it flattened the whole of the TEI for me, which was massive. Copy at ftp://ota.ox.ac.uk/pub/ota/TEI/software/normdtd1.exe The output of some linemode parsers (eg sgmls and sp) was in part designed for input into subsequent processors, I think. ///Peter -- > to discover 1000s of internal "homepages" that grew overnight > like magic mushrooms on a rich motherlode of corporate horseshit. Copyright 1996, IBM. All Rights Reserved %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 19 Feb 1997 23:26:54 +0000 (GMT) From: Peter Flynn Subject: Re: What to do given both SYSTEM and PUBLIC? To: w3c-sgml-wg@w3.org At 16:29 19/02/97 -0600, you wrote: [implementors] >Hmm. You could find some and ask them. Of course, the love of the ear >is to hear what it heard before. That question usually sets off the >platform wars. Gzip is popular because free, but not a great way to >pack up multiple files, so in reality, just compression. Pkzip can >pack multiple files and compress, but it's not free. But there are zips which are both free and compress. >should be considered: fat packets piss off the NetLords. Small, >"guaranteed overnight deliveries" are the way of the web. Pshaw. I _have_ overnight delivery on my connection right now, it's so damn slow... >Don't let them pick. Pick smart here. No. we tried that with HTML and it was ignored because the programmers didn't want the hassle of learning SGML. Picking smart is no guarantee of anything, unfortunately. >Pick the one that can be implemented fastest in XML 1.0. *That*'s more like it. Even if it stinks. >> Let's not make the same mistake. > >You mean there is another mistake we can make? No, we're all perfect here, aren't we...aren't we...? :-) ///Perter -- > to discover 1000s of internal "homepages" that grew overnight > like magic mushrooms on a rich motherlode of corporate horseshit. Copyright 1996, IBM. All Rights Reserved %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 15:25:53 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 6. Addressing & process model issues [Sorry, I sent this but didn't see it; my apologies if you get 2.] The picture again: Click here |------------------------------p0-----------------------------------------| |------------------------p1----------------------------------| |----------p2-------------------| |----p3------------------| |----p4-------------| |p5| Thank you for clicking to get here. |------------------------------q0-----------------------------------| |------------------------q1----------------------------| Note that a. the linking element p1 is contained in a document, p0 b. the locator, p3, is segmented in standard URL fashion into p4 and p5. c. the resource, q1, is contained in a document, q0 This raises three issues, two strongly linked. If you'd like to address one of these, please use either 6.1 or 6.2 below for your subject line. 6.1 Are linking element source documents interesting? Since a link is asserted by an element, the element by definition must appear in a document. Let's call this the "linking element source document". In many cases, the identification and address of the source document are of great interest in correct processing of a link. Among other things, authentication and authority issues are of great import when the link is to something like financial information. In laypersons' terms: who said so? Does the linking element source doc need to be discussed in the XML link spec, and do we need to specify any particular required behavior or metadata concerning it? 6.2 Locator fragments and traversal process model In the web, when processing "http://x.com/y/z.html#SEC1", the server returns all of z.html, and the client navigates to an Subject: Mailing list broken? I at least lost a whole bunch of WG messages over the weekend. I know because they include one that I sent. Also, I seem to have miss Peter Murray-Rust's JUMBO announcement. If you sent something to the WG over the weekend and you think it was important, you might want to retransmit. - Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 16:04:23 -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: Mailing list broken? | I at least lost a whole bunch of WG messages over the weekend. I know | because they include one that I sent. Also, I seem to have miss Peter | Murray-Rust's JUMBO announcement. If you sent something to the WG | over the weekend and you think it was important, you might want to | retransmit. - Tim Flaky as the mailing list is, I don't think it's broken -- I've been seeing a fair number of messages. It was awful quiet over the weekend, however, so it's possible that there was an interruption of service. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 00:35:40 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: implementation comments Lines: 37 In message <330B7B1C.7062@hiwaay.net> Len Bullard writes: > Peter Murray-Rust wrote: [...] > > A general conclusion is that you will need to give a good deal of help > > to people who want to convert from SGML. There are bits which aren't obvious > > and bits which you might expect to be there and aren't. This conversion is > > not just the document instances, it's the whole lot. (This isn't meant > > to sound negative... but it will be even harder for PhaseII). > > That is bad news. If XML is a complete break with SGML, then > there is trouble ahead. The San Diego conference could have some > rough moments if the attendees are knowledgeable. An example (from "ISO 8879-1986//ENTITIES Added Latin 1//EN") (BTW I use the FPI to identify the document, not its location): There are about 100 such records in the file: ^^^^^ ^^ ^^ The fields underlined are not parsable in XML. This means that either it is not possible to use the ISO entity sets in XML (which seems a pity), or they must be transformed (?who would validate them) or maybe there is some cunning way round this problem My personal opinion is that the SGML comment (which is ubiquitous in DTDs, entities , etc.) will be the thing that causes most problems as the change to --* *-- is not immediately obvious to those who haven't been involved in the discussions. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 97 18:58:15 CST From: Michael Sperberg-McQueen Subject: Re: What to do given both SYSTEM and PUBLIC? To: W3C SGML Working Group On Wed, 19 Feb 1997 12:09:59 -0500 David Durand said: >At 11:08 AM -0500 2/19/97, Steven J. DeRose wrote: >>At 12:52 PM 02/18/97 -0800, Joe English wrote: >>> (someone asked): >>>> * what to do if you are given both and the resulting files are >>>> different (Joe English) >>>This means that somebody somewhere has made a mistake. >>>We don't need to specify error recovery in this case. (Steven J. DeRose) >>I'll buy that; but you'll likely never *discover* the error, since >>if you successfully resolve one ID it is unlikely you'll bother with >>the other. (David Durand) > It means that authors who intend to use both SYSTEM and PUBLIC are >duty-bound to either use (and test) a programmatic solution that ensures >they are identical, or must test the document with both public-preferred >and SYSTEM-preferred resolution in place. What on earth are you guys *talking* about??!! Why on earth would it be an error? Are you seriously suggesting that if Peter Flynn's TEI Lite documents point the user to a copy of the TEI Lite DTD on Peter's server in Ireland, but my local catalog file points the XML processor to a copy on my hard disk, and the XML system finds it there, that Peter and I have together committed an error? The URLs http://www.ucc.ie/curia/dtds/teilite.dtd and file:///sgml/public/tei/derived/teilite.dtd are certainly not the same, and don't point to the same file. But they are certainly both copies of the TEI Lite DTD, and I don't see why anyone at all, let alone the three normally awake people I've just quoted, should think it's an error for the public identifier and the system identifer to point at different files. I thought part of the point of public identifiers was to make it possible to detect the case in which you don't need to (re-)transmit the DTD because the recipient of the document instance already has it? Or are we planning to use this method to push up the byte count of SGML flowing across the Web? All those thousands of copies of ISO Latin 1, ISO Pub, ISO Num, etc.,... What gives? -C. M. Sperberg-McQueen ACH / ACL / ALLC Text Encoding Initiative University of Illinois at Chicago tei@uic.edu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 20:29:59 -0500 From: Tony Graham To: w3c-sgml-wg@w3.org Subject: Java-based XML browser and implementation comments Peter Murray-Rust writes: > Is there a tool which 'normalises' DTDs (i.e. resolves > all the parameter entities) and outputs a 'processed' DTD? (While I'm > on that, is there a tool which can parse the DTD so it can be used by a > program?). Try the perlSGML package by Earl Hood at http://www.oac.uci.edu/indiv/ehood/perlSGML.html. It provides functions for parsing a DTD, then once you've parsed the DTD you can use numerous other functions that return lists or arrays containing information about elements and attributes. It also comes with several example applications, such as dtd2html which reads a DTD then produces documentation in HTML. Regards, Tony Graham ======================================================================= Tony Graham, Consultant Mulberry Technologies, Inc. Phone: 301-231-6931 6010 Executive Blvd., Suite 608 Fax: 301-231-6935 Rockville, MD USA 20852 e-mail: tgraham@mulberrytech.com ======================================================================= %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 21:17:16 -0600 From: len bullard To: Peter Flynn CC: w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? Peter Flynn wrote: > > At 16:29 19/02/97 -0600, you wrote: > [implementors] > >Hmm. You could find some and ask them. Of course, the love of the ear > >is to hear what it heard before. That question usually sets off the > >platform wars. Gzip is popular because free, but not a great way to > >pack up multiple files, so in reality, just compression. Pkzip can > >pack multiple files and compress, but it's not free. > > But there are zips which are both free and compress. True. SGMLer's have a horror of working software though. It is more pure to declare than do. > >should be considered: fat packets piss off the NetLords. Small, > >"guaranteed overnight deliveries" are the way of the web. > > Pshaw. I _have_ overnight delivery on my connection right now, it's so > damn slow... Yes, now imagine it as a snake trying to swallow a stylesheet, a DTD, a document instance, a catalog, a few miscellaneous applets. > >Don't let them pick. Pick smart here. > > No. we tried that with HTML and it was ignored because the programmers > didn't want the hassle of learning SGML. Picking smart is no guarantee > of anything, unfortunately. Possibly. Some are complaining on the VRML list that the failure to nail down a scripting language is the reason we now have so many incompatible "world" files. Others say picking Java would have given VRML to Sun, or JavaScript, giving it to Netscape. So we have VRMLScript which is JavaScriptByAnotherName, and still have all these Java applets. Some say, "let the market forces and hot content decide" which of course is no decision and guarantees the incompatibilities continue because market forces created them originally and will continue to create them. The sun still rises. Truth is, we decide. > >Pick the one that can be implemented fastest in XML 1.0. > > *That*'s more like it. Even if it stinks. Well, I'd hoped for something that didn't remind me of my band, but if there is a gig, working equipment is better than none, and Peavy amps may buzz, but they still work when dropped from a moving truck. It doesn't have to be perfect. It has to work and get us to XML 2.0. It should also be cheap and easy. > >> Let's not make the same mistake. > > > >You mean there is another mistake we can make? > > No, we're all perfect here, aren't we...aren't we...? :-) Just Durand. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 19 Feb 1997 11:59:26 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 2.2 a-b: Link Recognition by Reserved GI? >The ERB schedule calls for voting on these Feb. 19th. >I've take the liberty of grouping a few here that seem totally related. > >2.2.a Should we allow link recognition via a reserved GI? We should allow a PI style declaration that all AFs should apply to GIs with the same name. So you have to daclare that GIs are significant, but a 1-line addition to your file lets you use the most simplistic markup method. _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 20 Feb 1997 09:18:33 +0000 (GMT) From: Peter Flynn Subject: Re: implementation comments To: w3c-sgml-wg@w3.org > An example (from "ISO 8879-1986//ENTITIES Added Latin 1//EN") > (BTW I use the FPI to identify the document, not its location): :-) > There are about 100 such records in the file: > > > ^^^^^ ^^ ^^ > The fields underlined are not parsable in XML. Ewww. This hadn't dawned on me: comments in existing dtds and ent files. In this case, it can be fixed with sed "s|--.*--||" but do we know if the comments are an integral (ie compulsory) part of the ISO char ent files? ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 10:39:34 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: SERIOUS concerns about implementation Lines: 126 This contains a contentious suggestion and I apologise if I have missed something obvious - I am not an expert in the management of existing SGML systems and I simply post the concerns of a typical webhacker. I have spent the last 12 hours trying to get EXISTING SGML files to work with XML and am now deeply worried that the syntax of XML Phase I is seriously flawed and it will be very difficult to market. (The good news is that I think it's *technically* very easy to mend.) [Please forgive the loose terminology in contrasting 'SGML' with 'XML'] If you install Panorama there is a directory called catalog, with about 35 files which are a mixture of popular *.dtd and *.ent. EVERY SINGLE FILE WILL BREAK XML UNLESS THE SYNTAX IS CHANGED. (I can think of no simple kludge for this problem.) If XML goes ahead with 961114, then the only solution is to have a modified version of every file which works with XML. (This file will also work with SGML, of course, but it would need the *supplier* to authorise a change.) The problem arises from (at least) the following: is illegal in XML is illegal in XML (I don't know whether there are any PIs in the distribution, but there could be. %Foo; is not supported XML must be able to interoperate with these files UNCHANGED The good news is that all these files are easy to parse (i.e. *I* can do it, I think). They all have identifiable tokens and (although I haven't tried to parse DTDs - I only do documents at present - it looks 'trivial'). Why was introduced? Presumably it is possible for someone to write something with embedded '--' that is difficult to parse. I doubt very much if this happens in any of the DTDs or entity sets. If it *does* we have to write better parsers, or put pressure on the 0.1% of people who write poor DTDs. I assume was introduced for the same reason. That someone might write 1.0"> or something like that. This is still easy to parse if the rules say that the quotes are required. I am sure that it is *possible* to create some monster that breaks our syntax, but in practice it won't be a problem. I don't understand the forbidding of PUBLIC ENTITYs at all. I found it a non-issue until this debate started. You get a DTD from (say) Panorama which requires an EntitySet. It is *identified* by an FPI. Panorama even send you this file *in the same directory*. The catalog tells what its name is. Even I have managed to write code that resolves this. My simple understanding is that FPIs identify the document just like an ISBN identifies a book. Up until now it has been *my* responsibility to get the document. Panorama helps me by downloading lots of them. I assume that most of you in practice have a directory full of commonly used DTDs and Entity Sets which you use every day. [The problem only arises when someone MODIFIES a document which purports to be the true document with a given FPI. I assume that not only is this bad practice, it may also break copyright, particularly if it is retransmitted]. The result of this is that EVERY file I have been working with up to now (document instances, DTDs, catalogs, EntitySets) are broken w.r.t XML. I have to modify them, often by hand. The rest of the world is not going to like this XML should interoperate with existing DTDs/catalogs/entitySets as far as possible. If not possible XML should make accommodation for parsing problems in very commonly-used WELL-FORMED documents. (In a very small number of cases there may be grey areas - but you have lots of these with SGML anyway - ambiguous content, whitespace, etc. - these are far more likely to give problems). Rescind Rescind Allow the use of PUBLIC ENTITYs and other similar constructions in DTDs. There remain other problems which I am not expert enough to make comments on. I flag up two: The '- -', '- o' fields in ELEMENT. (I don't know its name). You have to be able to skip these if you parse an existing DTD. SDATA in entitySets. I don't know what it does, but it should be kludgeable. -------------------------- One point to bear in mind is that unless you constantly think about implementation, you are going to run into problems. I have seen several languages die because no one bothered to think of implementation - it was assumed to be easy. It is always harder than you think, which is why I urge caution on Phase II. I know that it is very antisocial to suggest major revisions at a late stage and I am a believer in communal discipline. If I have missed something obvious please forgive this posting. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 20 Feb 1997 15:02:54 +0000 (GMT) From: Peter Flynn Subject: Re: SERIOUS concerns about implementation To: w3c-sgml-wg@w3.org Peter Murray-Rust writes: > If you install Panorama there is a directory called catalog, with about > 35 files which are a mixture of popular *.dtd and *.ent. > EVERY SINGLE FILE WILL BREAK XML UNLESS THE SYNTAX IS CHANGED. It's hard enough to get Panorama to work with normal SGML :-) But this is very useful information, Peter, thanks for identifying it. > Why was introduced? I have a sneaking suspicion it was introduced because C programmers can't get a handle on comments /* unless they have an asterisk */, and as they are the target audience for implementations, this was done to persuade them that XML is not as hard as SGML :-) > > The result of this is that EVERY file I have been working with up to now > (document instances, DTDs, catalogs, EntitySets) are broken w.r.t XML. I > have to modify them, often by hand. > I think the intention was (?is?) that XML can be parsed by SGML parsers, but there was no intention that it should go the other way round. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 10:58:02 -0500 To: Peter Flynn From: masonjd@ornl.gov (James David Mason) Subject: Re: implementation comments Cc: w3c-sgml-wg@w3.org At 09:18 AM 2/20/97 +0000, you wrote: >> An example (from "ISO 8879-1986//ENTITIES Added Latin 1//EN") >> (BTW I use the FPI to identify the document, not its location): > >:-) > >> There are about 100 such records in the file: >> >> >> ^^^^^ ^^ ^^ >> The fields underlined are not parsable in XML. > >Ewww. This hadn't dawned on me: comments in existing dtds and ent files. >In this case, it can be fixed with sed "s|--.*--||" but do we know if >the comments are an integral (ie compulsory) part of the ISO char ent >files? > >///Peter The comments are not mandatory -- they're just about universal, though. The source of these things is, of course, Annex D.4 of ISO 8879. And it's not just one file but quite a few in a typical installation. The annex is not normative text, but files containg this public text have been copied by almost every vendor (a quick look around my disk found copies from WordPerfect and Adobe/Frame and two copies from SoftQuad). There are further examples of this sort in ISO/TR 9573, Techniques for Using SGML. Given the near ubiquity of files that look lile the Annexes, maybe XML ought to reexaine the decisions on the things Peter points out above. (I, for one, think the "--* *--" delimiter is more junk to type -- and it makes me have to hit a shift key, too. I have enough sense to distinguish between when I'm typing text and use " -- " as an em-dash and when I'm typing code and putting in comments.) Jim Mason Dr. James D. Mason (ISO/IEC JTC1/SC18/WG8 Convenor) Lockheed Martin Energy Systems Information Management Services SGML Systems Development 1060 Commerce Park, M.S. 6480 Oak Ridge, TN 37831-6480 U.S.A. Telephone: +1 423 574-6973 Facsimile: +1 423 574-0004 Network: masonjd@ornl.gov http://www.ornl.gov/sgml/wg8/wg8home.htm %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 97 10:29:30 CST From: Michael Sperberg-McQueen Subject: Re: SERIOUS concerns about implementation To: W3C SGML Working Group On Thu, 20 Feb 1997 06:35:10 -0500 Peter Murray-Rust said: > >If you install Panorama there is a directory called catalog, with about >35 files which are a mixture of popular *.dtd and *.ent. >EVERY SINGLE FILE WILL BREAK XML UNLESS THE SYNTAX IS CHANGED. I'm sorry to see members of the WG taken by surprise on this topic. I for one thought it was obvious long ago, and never hidden or disguised, that the restrictions on comments, entity types, content models, and attribute declarations would require the preparation of XML-compatible versions of standard entity sets from ISO and elsewhere, as well as of XML-compatible versions of standard DTDs like Docbook, TEI, and HTML. So I'm neither surprised nor shocked by Peter Murray-Rust's discovery, though I am alarmed to see that some members of the WG seem surprised by it. The preparation of XML-compatible versions of these files is (a) not hard, and (b) something that need be done only once. It seems to me a very small price indeed to pay for the simplifications we get in declaration syntax and entity handling. So, with respect, I suggest that any proposals to - start allowing comments in arbitrary SGML declarations - return to the use of -- -- com delimiters - remove the restrictions on content models which will make many existing DTDs break with XML parsers - restore the SDATA entity type need some further motivation before we reopen these questions. We knew when we made the original decision that existing SGML DTDs and entity sets use these constructs. We knew that eliminating the constructs would mean making new XML-compatible versions of the files we all use. Nothing has changed. Is there a reason to revisit the decisions? -C. M. Sperberg-McQueen University of Illinois at Chicago %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Thu, 20 Feb 97 11:55:59 EST To: w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? > >That's sensible, although there would then be no standard XML way of > >processing a document with PUBLIC -- you'd have to use a resolution > >mechanism > > But you have to do this with all apps of SGML: it's what a PUBLIC id > is _for_. People are meaning different things by "resolution". Joe's point was that if you receive an XML document over the web and you don't have the DTD, your XML software hass to figure out automatically how to fetch tbe DTD, and do it, with no user intervention. > I still don't see the problem with being directive about this: > "ftp://ftp.foo.com/dtds/abfab.dtd"> If we end up using CATALOG to link to style sheets too, this may make sense, since then we'll need the public ID to associate the style sheet with all documents using a given DTD (and that particular catalog). If we don't, the public ID isn't really needed in this case, and you're best off with a normal URL cache. If some systems use the PUBLIC ID in some way to fetch DTDs, and some future system fetches a different DTD than the one you specified, e.g. because they happened to use the same public ID as you, there may of course be problems... PS: > At 16:57 19/02/97 -0500, Liam Quinn wrote: Actually, there is a Liam Quinn at Waterloo who posts to the HTML groups about SGML, but I am Liam Quin (one "n")... this is a source of confusion for some people, I know... Lee -- Liam Quin, lee@sq.com | lq-text freely available Unix text retrieval Senior Technical Consultant | FAQs: Metafont fonts, OPEN LOOK UI, OpenWindows SoftQuad Inc. +1 416 544-9000 | xfonttool (Unix xfontsel in XView) http://www.softquad.com/ | the barefoot programmer %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 11:03:31 -0600 From: Len Bullard To: Michael Sperberg-McQueen CC: W3C SGML Working Group Subject: Re: SERIOUS concerns about implementation Michael Sperberg-McQueen wrote: > > On Thu, 20 Feb 1997 06:35:10 -0500 Peter Murray-Rust said: > > > >If you install Panorama there is a directory called catalog, with about > >35 files which are a mixture of popular *.dtd and *.ent. > >EVERY SINGLE FILE WILL BREAK XML UNLESS THE SYNTAX IS CHANGED. > > I'm sorry to see members of the WG taken by surprise on this topic. > > The preparation of XML-compatible versions of these files is (a) not > hard, and (b) something that need be done only once. It seems to me a > very small price indeed to pay for the simplifications we get in > declaration syntax and entity handling. Those will have to be explained to an existing user base who possess some rather expensive tools and substantial SGML legacy. All they actually want is an SGML browser and database tools for the Internet. > Is there a reason to revisit the decisions? It is a sideways compatibility issue. Moving to XML is not an upgrade to SGML. It is a crab walk into a different standard, language and system. So, deciding to do it raises serious issue of maintenance and tools. These changes, unless explained with hefty benefits, will result in the rejection of XML by some users. The problem is that the early adopters of XML will likely come from the SGML community who have an immediate need. Typically, I've seen this problem met by freeware for conversion. >From VRML 1.0 to 2.0, many syntax changes occurred that looked gratuitous. SGI, Sony, and some editor vendors responded with automatic conversion routines. Mileage varies. The difference in this situation is the size of the legacy to be considered, and the impact on the existing base of tools. I am not surprised. But, unless met with explanations that are the changes are practical and beneficial, there will be some serious questions raised by the SGML user community. Newbies won't care. This will be hard where the nature of the changes or the accruing benefits are either esoteric or so technical the audience gives up and looks for alternatives. len bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 09:31:51 -0800 (PST) From: "Deborah A. Lapeyre" Subject: Re: implementation comments To: James David Mason cc: w3c-sgml-wg@w3.org I'm REALLY glad to see other folks concerned about the comments, but I do feel we have already lost on this one. We, as an industry, can cope. At Mulberry, we see two big problems for us personally: 1) All those standard sets of SDATA entities 2) Our "house-style", which embedded comments concerning every attribute, within the ATTLIST Declaration, before the attribute definition. On the comment issue, we figured: 1) One of the vendors would undertake to produce an XML conformant version of the standard ISO special-character general entities (maybe SGML Open can volunteer) and we would all replace. Since this is only a comment definition, we need not maintain 2 sets, only replace the one we have. (In the days before the SGML Open catalogue agreement, we kept as many sets as we had software packages; this is not as uncomfortable as that was.) 2) Every SGML DTD we have ever written would have to be modified, but we're pretty sure that it could be done programatically, and only once. So the comments will require work, but are no big deal. Unfortunately, there are still other reasons that every SGML DTD will need to be re-written for XML, the peskiest being the omissability indicators. If the syntax could just be written to ignore ANYTHING found in that position (after the first ps following the element name and before the "(" of the content model ... ). Sigh. As XML is shaping up, I see no alternatives for an SGML shop but to: 1) Generate XML DTDs on the fly from SGML DTDs, as you need them; or 2) Maintain duplicate XML/SGML DTDs (Ouch); or 3) Generate both XML and SGML DTDs from another source (we're working on this, actually). And while I see this as inconvenient I don't see it as any sort of a show-stopper. It looks like XML will be, like all standards, an imperfect compromise. That's OK. --Debbie ======================================================================= 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 ======================================================================= %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Thu, 20 Feb 97 12:51:25 EST To: w3c-sgml-wg@w3.org Subject: Re: SERIOUS concerns about implementation I concur completely with Michael. No-one has ever said that existing legacy SGML (or HTML) files will be valid XML files. They won't. The conversion is automatic and trivial. The came from me, and is a sort of transition syntax: you can use this in SGML today, as any SGML parser will accept it as a comment that just happens to contain the stars. If'when SGML is enhanced to allow different start and end comment delimiters, this comment syntax lets you include -- in comments. Also, yes, it looks familiar to C programmers, and there are a lot of us. > On Thu, 20 Feb 1997 06:35:10 -0500 Peter Murray-Rust said: > > > >If you install Panorama there is a directory called catalog, with about > >35 files which are a mixture of popular *.dtd and *.ent. > >EVERY SINGLE FILE WILL BREAK XML UNLESS THE SYNTAX IS CHANGED. No, none of these files will break. They are all SGML files, and are not for use with XML. I expect that a future Panorama may well handle both XML and SGML... > I suggest that any proposals to > - start allowing comments in arbitrary SGML declarations > - return to the use of -- -- com delimiters > - remove the restrictions on content models which will make many > existing DTDs break with XML parsers > - restore the SDATA entity type > need some further motivation before we reopen these questions. I agree. All the changes were made for good reason. XML is a subset of SGML, but that doesn't mean that a subset of existing SGML files are XML files. > Is there a reason to revisit the decisions? No. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Thu, 20 Feb 97 13:23:05 EST To: w3c-sgml-wg@w3.org Subject: SDATA [was: Re: SERIOUS concerns about implementation] Peter@ursus.demon.co.uk (Peter Murray-Rust) > Not everyone will initially understand the reason for two sets of > entity sets which differ only by asterisks and they may occasionally muddle > them up. If this is recognised and accepted, that's fine. Furthermore, (1) we don't have SDATA entities at all in XML, so none of the ISO entity sets can be used; (2) Unicode is used, so the replacement text of character entities has to be quite different anyway. Since we aren't using SDATA, we can't rely on applications mapping "[third ]" into anfraction, but must change into Once this has been done for the (large) subset of ISO entities supported by Unicode, you'll just refer to the new public IDs and through the unspecified magic of CATALOGs everything will work :-) > My own position is that my DTD (CML) is (now) not interoperable with XML. Nor is it ever likely to be (sorry). Converting the entity sets and DTDs is a good idea, and should be done, once the language has settled down a little more. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Thu, 20 Feb 97 13:35:18 EST To: w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? > What on earth are you guys *talking* about??!! > > Why on earth would it be an error? > Are you seriously suggesting that if > Peter Flynn's TEI Lite documents point the user to a copy of the TEI > Lite DTD on Peter's server in Ireland, but my local catalog file points > the XML processor to a copy on my hard disk, and the XML system finds it > there, that Peter and I have together committed an error? not if the resulting bytestreams are identical, no, When I asked the question, I said what should happen if the results were different -- not if the same file was stored in different places. E.g. Priscilla has modified TEI Lite, and expects the SYSTEM ID to be used, but retains the same PUBLIC ID so as not to have to download style sheets. But Daniella's software ignores SYSTEM, uses PUBLIC to fetch the catalog directly from the TEI server in Romania, and gets a different DTD as a result. Me, I'd say Priscilla should have changed the PUBLIC ID if she had been more PUBLIC-ID-savvy and had her SGML University Diploma, but as she was really an HTML hacker and didn;t understand all this, she tried it until it worked, and did The Wrong Thing. No amount of user education will ever fix this unless and until there are no new users. PUBLIC IDs only work in practice when they are used with care, thought and undersanding. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 12:48:29 -0600 From: Len Bullard To: "Deborah A. Lapeyre" CC: James David Mason , w3c-sgml-wg@w3.org Subject: Re: implementation comments Deborah A. Lapeyre wrote: > > As XML is shaping up, I see no alternatives for an SGML > shop but to: > 1) Generate XML DTDs on the fly from SGML DTDs, as > you need them; or > 2) Maintain duplicate XML/SGML DTDs (Ouch); or > 3) Generate both XML and SGML DTDs from another > source (we're working on this, actually). > > And while I see this as inconvenient I don't see it as any > sort of a show-stopper. It looks like XML will be, like all > standards, an imperfect compromise. That's OK. The other alternative is to ignore XML syntax, adopt XML or adopt and modify XML linking, then use an SGML conforming system. Not as easy to build; probably easier to sell. Faced with keeping up what appear on the surface to be gratuitous incompatibilities, forcing translation at the customer site, and breaking the back of the SGML standard support and ISO support, it might not be the horrible option it seems to be otherwise. No, I am not suggesting the WG revisit the decisions. I am saying, that alternative is always there and when choosing, the familiar evil is typically the popular one. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 17:23:21 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: SERIOUS concerns about implementation Lines: 79 In message <199702201642.LAA01649@www10.w3.org> Michael Sperberg-McQueen writes: > On Thu, 20 Feb 1997 06:35:10 -0500 Peter Murray-Rust said: [... PM-R's material deleted ...] I said that I am prepared to accept communal discipline and I don't intend to post further on this topic unless asked :-) > > I'm sorry to see members of the WG taken by surprise on this topic. I got the impression from 2-3 mails that this had surprised people and I am sorry if I have raised an issue that had been put to bed. > > I for one thought it was obvious long ago, and never hidden or > disguised, that the restrictions on comments, entity types, content > models, and attribute declarations would require the preparation of > XML-compatible versions of standard entity sets from ISO and elsewhere, > as well as of XML-compatible versions of standard DTDs like Docbook, > TEI, and HTML. So I'm neither surprised nor shocked by Peter > Murray-Rust's discovery, though I am alarmed to see that some members of > the WG seem surprised by it. My reaction is that it will create a lot of work and potentially some confusion. Not everyone will initially understand the reason for two sets of entity sets which differ only by asterisks and they may occasionally muddle them up. If this is recognised and accepted, that's fine. > > The preparation of XML-compatible versions of these files is (a) not > hard, and (b) something that need be done only once. It seems to me a > very small price indeed to pay for the simplifications we get in > declaration syntax and entity handling. I accept that for large well-financed organisations this isn't a problem. Nor is it a problem for people who are developing a complete XML solution without any reference to existing SGML. The problem will hit those who (like me) are on the fringes of the SGML community and who have to make do with what bits and pieces they can pick up. My own position is that my DTD (CML) is (now) not interoperable with XML. The problem is not primarily technical. The components that CML interoperates with belong to other organisations who own the copyright and for each of which I shall have to get permission to alter and redistribute the material. Whilst I am sure this will come in time, it's not something that a single individual is likely to make much headway with. Therefore, I cannot legally distribute my material in XML-form (unless I have misunderstood this). I will predict that what will happen is that people will develop XML software which has switches on the command line, that allow it to read 'SGML' entity sets, rather than the confusion of interoperating with 'SGML' sets and 'XML' sets in neighbouring directories. > > So, with respect, I suggest that any proposals to > > - start allowing comments in arbitrary SGML declarations > - return to the use of -- -- com delimiters > - remove the restrictions on content models which will make many > existing DTDs break with XML parsers > - restore the SDATA entity type > > need some further motivation before we reopen these questions. We knew > when we made the original decision that existing SGML DTDs and entity > sets use these constructs. We knew that eliminating the constructs > would mean making new XML-compatible versions of the files we all use. > Nothing has changed. Is there a reason to revisit the decisions? No :-) But it would be a useful thing for those of us who are trying to develop software to have the definitive XML versions of the common DTDs and entity sets. At present my XML development is stalled until this happens. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 20 Feb 1997 23:30:52 +0000 (GMT) From: Peter Flynn Subject: Re: SERIOUS concerns about implementation To: w3c-sgml-wg@w3.org At 10:29 20/02/97 -0600, MSMcQ wrote: [ent sets] >I for one thought it was obvious long ago, [...] >So I'm neither surprised nor shocked by Peter >Murray-Rust's discovery, though I am alarmed to see that some members of >the WG seem surprised by it. I just hadn't gotten round to thinking about it. I knew my DTDs would need editing, but as you say, you only need do it once. >Nothing has changed. Is there a reason to revisit the decisions? No, but it should remain true to say that a carefully-edited set of ent files and dtds will remain usable with standard SGML tools. ///Peter -- > to discover 1000s of internal "homepages" that grew overnight > like magic mushrooms on a rich motherlode of corporate horseshit. Copyright 1996, IBM. All Rights Reserved %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: W3C SGML Working Group Subject: Re: What to do given both SYSTEM and PUBLIC? Date: Thu, 20 Feb 1997 12:45:03 -0800 From: Joe English Michael Sperberg-McQueen wrote: > >>> (someone asked): > >>>> * what to do if you are given both and the resulting files are > >>>> different > (Joe English) > >>>This means that somebody somewhere has made a mistake. > >>>We don't need to specify error recovery in this case. > (Steven J. DeRose) > [...] > (David Durand) > [...] > (Michael Sperberg-McQueen) > What on earth are you guys *talking* about??!! > > Why on earth would it be an error? Are you seriously suggesting that if > Peter Flynn's TEI Lite documents point the user to a copy of the TEI > Lite DTD on Peter's server in Ireland, but my local catalog file points > the XML processor to a copy on my hard disk, and the XML system finds it > there, that Peter and I have together committed an error? No, precisely the opposite. As long as the XML user agent gets the same _text_ via the PUBLIC and SYSTEM id's, all is well and there's no error. > The URLs > http://www.ucc.ie/curia/dtds/teilite.dtd and > file:///sgml/public/tei/derived/teilite.dtd are certainly not the same, True -- > and don't point to the same file. but if the resources denoted by both URLs have the same content, I would say that they denote the same _entity_. By my interpretation, a PUBLIC identifier in principle specifies an entity, not a SYSTEM identifier. (In practice this is usually accomplished by mapping the PUBLIC ID to a SYSTEM ID, but this doesn't affect the "true meaning" of the PUBLIC ID.) PUBLIC and SYSTEM identifiers are analogous to URNs and URLs, respectively; one denotes the name of an entity and the other denotes (one of) its address(es). If an external identifier includes both a PUBLIC ID and a SYSTEM ID, the author has in effect asserted that "the entity I mean has this name, and can be found at that location". It is the author's responsibility to make sure that the resource at that location is in fact the one with this name. Likewise, it is the user's responsibility to make sure that local catalog entries for a particular name (PUBLIC ID) resolve to the correct entity (e.g., don't map TEI Lite's FPI to DocBook's public text). If these conditions are met, then it doesn't matter if an XML user agent tries to resolve the PUBLIC ID or the SYSTEM ID first; the result will be the same in both cases (modulo download time, and potential network failure, of course). I don't want to get too deep into the ontological nature of files and entities and what it means for two of them to be the same, so I'll leave it at that... %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org Subject: Re: What to do given both SYSTEM and PUBLIC? Date: Thu, 20 Feb 1997 11:30:21 -0800 From: Joe English paul@arbortext.com (Paul Grosso) wrote: > > From: Joe English > > (If the software does not know how to automatically resolve > > PUBLIC ID's -- which I suspect most software will not, since > > _nobody_ is sure how to do this yet -- . . . > > Regardless of what we decide wrt catalogs, Public IDs, and XML, > I don't understand Joe's comments above that "nobody knows how > to [resolve PUBLIC IDs] at all yet." What I meant was: it's not possible to write a program that will, given an arbitrary FPI, return the public text denoted by that FPI. Of course, given an FPI _and a TR9401 catalog_ this is trivial; or given an FPI and the URL of the resource from which the FPI was referenced (so that a catalog can be retrieved a la Panorama) it's also doable. But the more general problem of mapping FPIs to public text, given no information other than the FPI itself, is at present insoluble. > [...] > I am not in the business of defending TR9401 against all > comers, but I do think Joe's statements are poor reflections of reality. Yes, I did slightly overstate the case :-) The point I wanted to make was that PUBLIC ID's are useful even if they *can't* be automatically resolved. The best example of this is in document type declarations. When an XML user agent sees it gets three pieces of information. First, the element type name of the document element; second, the PUBLIC identifier of the DTD to which the document conforms; and third, a SYSTEM ID by which the formal part of the DTD can be retrieved. The first is redundant since there's going to be a tag coming up next anyway as XML forbids tag omission; the third is in many cases unnecessary since the formal part of the DTD isn't required to parse the rest of the document. The second is the most, if not the only, important piece of information that an XML UA can get out of the whole declaration. It tells the program that the document is of the same type as one beginning with and that it's of a different type than one beginning with Even this is not terribly important for Joe's and Frank's private DTDs, but for shared, community-specific document types like CML -- which is precisely the sort of application for which XML holds the most promise -- it's critical. A PUBLIC identifier in the declaration is the most reliable way for a document to communicate to (say) a CML-aware user agent that it is a CML document, and not some other XML document type that happens to also be called CML. It doesn't matter in this case if the UA can't resolve the FPI; it doesn't need the _formal_ part of the DTD anyway. What matters is the _informal_ part, and a PUBLIC identifier is the only way to identify that. --Joe English jenglish@crl.com %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 20:20:14 +0000 To: w3c-sgml-wg@w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Re: SERIOUS concerns about implementation >I concur completely with Michael. > >No-one has ever said that existing legacy SGML (or HTML) files will be >valid XML files. They won't. I aggree. But I *do* wish we could stop referring to SGML files as "legacy". Surely SGML->XML is a "down-translation" not an "up-translation". Sean %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 18:38:44 -0600 From: len bullard To: "Digitome Ltd." CC: w3c-sgml-wg@w3.org Subject: Re: SERIOUS concerns about implementation Digitome Ltd. wrote: > > >I concur completely with Michael. > > > >No-one has ever said that existing legacy SGML (or HTML) files will be > >valid XML files. They won't. So what? > I aggree. But I *do* wish we could stop referring to SGML files as "legacy". > Surely SGML->XML is a "down-translation" not an "up-translation". > > Sean And the language in fact obscures what the most likely application of XML is: a delivery format on the Web for SGML. len bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 15:08:29 -0500 To: w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: DRAFT: Summary of ERB conference call The following is a summary of the ERB's telephone conference of 2/19/97, ending with a question to the WG: We considered questions 2.1 through 2.4. 2.1.a Should we allow link recognition via a reserved attribute? The ERB is strongly leaning to yes. 2.1.b If so, should we generalize this and say that it's an AF? 2.1.c If so, should we provide an introduction to AF's? We achieved consensus that we should provide clear self-sufficient documentation; readers should not have to understand the extended facilities annex to understand what we are talking about. We should not go further: no general introduction to AFs. We should mention at least once that it *is* an AF; with the reference to HyTime probably. 2.1.d If we allow such recognition, what should the attribute be, and what should be the values for each element type we define? This remains undecided. We are leaning toward XML-Link, but the nature of values must remain uncertain until we decide about the constructs the values are naming. There is some thought of having xml-tlink and xml-ilink as attributes, whose value has *all* the information we need, eg something roughly like xml-tlink="url (http://www.uic.edu/orgs/tei/p3) id (foo) child (3 p)" (This is an illustrative example ONLY. It is NOT a proposal.) 2.2.a Should we allow link recognition via a reserved GI? This remains hotly in question; see below. It should be noted that the HyTime TC introduces some of this effect by default: a GI that matches the name of an active architectural form, defaults to being of that form. 2.2.b If so, what should the set of GI's be? The same as the keyword values of xml-link attribute (if it has keyword values ...) 2.3 Should we provide a PI or other signaling mechanism whereby a document can specify that particular elements ought to be processed as link elements? This remains unclear; see below. If the proposed SGML TC fails for any reason and we never have multiple attlists, this is the way to go (this appears to be the consensus, or at least the majority view). 2.4: Should we allow that processors can decide that something is a link for their own unspecified reasons, e.g. hardwired knowledge of their own private element types, or external interaction? The consensus was that we should not forbid, discourage, encourage, or mention this more than necessary. --- Overall: We almost all agree that the best long-term solution is to allow multiple ATTLIST decls, so a document can start ]> This documents that the tei element is a tlink in XML terms. We think we can have multiple attlists when the TC passes. It's not clear what to do in the meantime. Choices include: 1 Play it Safe. Document the magic attribute and go no further yet. To use it with validating systems, you'll have to monkey with the actual DTD. XML docs will otherwise be verbose. After the TC passes, we'll add documentation for doing it with multiple attlists, so you don't have to monkey with the DTD. 2 Count on Utopian ATTLISTs. Document the magic attribute *and* the use of multiple attlists. After the TC passes, XML will be kosher. Until it passes, it's non-conforming (although individual documents can choose to be SGML-conformant or not). If the TC fails, we have to go back and add a PI. 3 Stopgap PI. If we can't stand the verbosity of Playing it Safe, and can't risk counting on Utopian ATTLISTs, we need a stopgap. The simplest seems to be to define a PI for the necessary function, e.g. or In the short term, we have no verbosity problems. In the long term, after the TC passes, we withdraw the PI and use only multiple attlists. If the TC fails, we change nothing. Drawbacks: planned obsolescence of this syntax may be hard to enforce. Once we have XML legacy data, removing the PI in version 2 may be hard. (Of course, xml link won't be *final* until november or so, we should know by then. Until November, we should -- by definition -- not have legacy data. All xml data made before then is experimental and has no claim on our protection.) 4 GI escape hatch. Like playing it safe, but to avoid the verbosity problem we at least allow GIs to be recognized. so in the long term you can be terse with multiple attlists; in the short term, by using magic gis. The ERB requests that the WG consider the question of how best to deal with this signalling issue, given the options and tradeoffs (and any others the WG may perceive). Steve (with copious thanks to Michael and his notes) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 20:40:14 -0500 To: W3C SGML Working Group From: dgd@cs.bu.edu (David Durand) Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? At 5:35 PM -0600 2/17/97, Michael Sperberg-McQueen wrote: >On Wed, 12 Feb 1997 16:53:57 -0500 Tim Bray said: >>2.1.a Should we allow link recognition via a reserved attribute? > >I assume this means "as described in sec. 2.1 of the draft of >31 January", so xxx is identified as >a 'tlink'. > >Yes. And (hard minimalism) this should be the only sanctioned >mechanism. There is no way around allowing this; there is no need >for anything more. I don't remember what I said, but I like this (but only if attlists can be split, if not, we _have_ to use PIs to implement a new declaration). >Come to think of it, if we *don't* call it an AF, we don't need to >explain what AFs are, and we can save ourselves the trouble. A >brief note in the appendix titles Notes for Rocket Scientists will >suffice; refer to the Extended Facilities Annex there and say >wisely but inscrutably "The alert reader will have noted that these >are architectural forms as defined in ...". On balance this is the best approach. AFs simply mean elements that are processad based on attributes, that satisfy some constraints. And we don't need to drag HyTime in to explain that. > >>2.1.d If we allow such recognition, what should the attribute be, and >> what should be the values for each element type we define? >It should be named 'XML-form' (lose the trailing hyphen, at all >events), and it should allow the specification not only of the >GI of the architectural form but also the specification of which >attributes in the actual DTD correspond to which attributes of the >AF. If you think it makes sense to allow users to name their own >element types, but not the attributes, think again. I'm not sure about this. I agree that it seems to make sense, but then why not redefine the XML-FORM attribute -- and then we're 5 times more meta- than we need for the task. I still incline to keep the attnames short and just fix them. I like the flexibility of the other, but I can't yet feel that it's worth having to explain an "attribute-mapping attribute" to the unfortunate reader of the spec. > >The values should be whatever names we give the architectural forms >and their attributes. I'd be happy if they were recognizable words, >or recognizable abbreviations of words, in some human language, >which rules out [a-zA-Z]link. I realize this means 90% of the >serious proposals are gone; sorry. But if we could find a reason to use blink it would be so amusing! The return of the repressed, with a vengeance! -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 21:01:51 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: SERIOUS concerns about implementation At 8:20 PM +0000 2/20/97, Digitome Ltd. wrote: >I aggree. But I *do* wish we could stop referring to SGML files as "legacy". >Surely SGML->XML is a "down-translation" not an "up-translation". Afraid not. You lose no information in going from SGML to XML, unless you have somehow managed to come up with a way to use SHORTREF that could not be equivalently expressed with tags. It is a cross-translation, since any SGML DTD and any XML DTD should be able to operate at the same level of abstraction. Actaully, there are a few exceptions: as far as I can tell, the only place where we lose information with the current draft is in some rare content model with mixed content, in SDATA, where a meaningful string must be hand-translated to a numeric code, and separately documented, and (hopefully not for long), with PUBLIC, where a location independent perpetually valid identifier must be replaced with a method that depends on a particular technical infrastructure for resolution. As this is a follow on to the previous thread and SDATA was raised by someone else, I will repeat my plea that we allow a way to use strings for undefined characters instead of undefined code points. In the absence of a resolution mechanism, they are equivalent, but SDATA has key advantages: compatible with established SGML practice (CoST and SP for instance), and potentially provide supereior information to a user. SDATA also extends easily and obviously to implementation of a registration mechanism in the future -- Private use characters do not. I am not a number, I am an undefined character! -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 10:02:47 +0700 To: w3c-sgml-wg@w3.org From: James Clark Subject: Loss of information going from SGML to XML At 21:01 20/02/97 -0500, David Durand wrote: >At 8:20 PM +0000 2/20/97, Digitome Ltd. wrote: >>I aggree. But I *do* wish we could stop referring to SGML files as "legacy". >>Surely SGML->XML is a "down-translation" not an "up-translation". > >Afraid not. You lose no information in going from SGML to XML, ... > Actaully, there are a few exceptions: as far as I can tell, the only >place where we lose information with the current draft is in some rare >content model with mixed content, in SDATA, where a meaningful string must >be hand-translated to a numeric code, and separately documented, and >(hopefully not for long), with PUBLIC, where a location independent >perpetually valid identifier must be replaced with a method that depends on >a particular technical infrastructure for resolution. Also you lose information about external data entities: data attributes are lost along with the distinction between NDATA, SDATA and CDATA entities. James %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 22:20:11 -0600 From: len bullard To: David Durand CC: w3c-sgml-wg@w3.org Subject: Re: SERIOUS concerns about implementation David Durand wrote: > > At 8:20 PM +0000 2/20/97, Digitome Ltd. wrote: > >I aggree. But I *do* wish we could stop referring to SGML files as "legacy". > >Surely SGML->XML is a "down-translation" not an "up-translation". > > Afraid not. You lose no information in going from SGML to XML, unless you > have somehow managed to come up with a way to use SHORTREF that could not > be equivalently expressed with tags. It is a cross-translation, since any > SGML DTD and any XML DTD should be able to operate at the same level of > abstraction. That is right. SGML and XML conversions/translations don't lose information except where application restrictions (e.g, linktypes) put restrictions on the developer. Those restrictions are necessary to the interoperability of the tools. XML is a subset of SGML. In fact, it would be a matter of interest to know how the SGML grove plan compares to a grove plan derived for XML. I spent some part of the day reading Dan Connoly's architecture papers. XML definitions for hyperlinks should be documented in the terms of that glossary if they are not already. The current uri.bunyip discussions between TimBL, Dan, Larry Masinter, Martin Duerst, et al are most illuminating. This is a quote from Larry Masinter: "This all got better for me when I just admitted that the definitions were circular, and decided that it was OK. What's a resource? Something that has a URI. What's a URL? Something that locates a resource. What's a URN? Something that names a resource. If you can name it, it's a resource. Different resources have different names. A single resource might have multiple names. You can't "get" a resource, you can only interact with it. One way to interact with a resource is to obtain an entity that is a representation of the resource at a given point in time. This isn't smalltalk, it's webtalk. "Web" for me is defined not by HTTP and HTML, but by this fundamental architectural point, that some entities contain URIs that locate/name other entities." That's a clear as it gets. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 97 22:56:09 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: DRAFT: Summary of ERB conference call > From: "Steven J. DeRose" > > The following is a summary of the ERB's telephone conference of 2/19/97, > ending with a question to the WG: > > > We think we can have multiple attlists when the TC passes. It's not clear > what to do in the meantime. Choices include: > > 3 Stopgap PI. If we can't stand the verbosity of Playing it Safe, and can't > risk counting on Utopian ATTLISTs, we need a stopgap. The simplest seems to > be to define a PI for the necessary function, e.g. > > > > or > > > > In the short term, we have no verbosity problems. In the long term, after > the TC passes, we withdraw the PI and use only multiple attlists. > If the TC fails, we change nothing. > > Drawbacks: planned obsolescence of this syntax may be hard to enforce. > Once we have XML legacy data, removing the PI in version 2 may be hard. > (Of course, xml link won't be *final* until november or so, we should know > by then. Until November, we should -- by definition -- not have legacy > data. All xml data made before then is experimental and has no claim on our > protection.) > > The ERB requests that the WG consider the question of how best to deal with > this signalling issue, given the options and tradeoffs (and any others the > WG may perceive). I like the so-called "Stopgap PI" with content that looks just like an attlist would. I don't see the "legacy" problem as very problematic. Before the TC passes, you must have: ]> and after it passes, you can still have the above or you can have ]> with the latter form preferred. Why care about enforcing obsolescence? That would be like getting upset that people still use ISO 8879-1986 instead of ISO 8879:1986 in FPIs. paul %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 23:46:05 -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: SERIOUS concerns about implementation | > I aggree. But I *do* wish we could stop referring to SGML files as | > "legacy". Surely SGML->XML is a "down-translation" not an | > "up-translation". | | And the language in fact obscures what the most likely application | of XML is: a delivery format on the Web for SGML. Which is (surprise!) what we're trying to do here. Is it time to point to our activity statement again? http://www.w3.org/pub/WWW/MarkUp/SGML/Activity Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 23:54:27 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 3.2.b Locators in attributes or elements? The ERB schedule calls for voting on Feb. 26 on these items. 3.2.b Should the locators of a general link be packaged in attributes as in HyTime, or as child elements as in the initial draft? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 23:53:49 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 3.1.a All linkage info in markup not data? The ERB schedule calls for voting on Feb. 26 on these items. 3.1.a Should we have a principle that all linkage information is encoded in GIs and/or attribute values, never in character data? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 23:54:48 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 3.3 XML Analogue of HTML " Subject: 3.1 b-h: Link contents question matrix The ERB schedule calls for voting on Feb. 26 on these items. It seems to me that these can sanely only be discussed collectively. It is multi-part and multi-dimensional, but none of the parts seem really orthogonal to any of the others. If people wish to take up sub-questions in detail, this is welcome. I encourage creativity and discipline in the use of subject lines to enhance the usefulness of the discussion. Dimension 1: Which pieces of information should be specified for possible inclusion in linking elements? b. Type c. Role d. locator e. caption f. behavior g. locator scheme (e.g. URL, FPI, TEI locator) h. others [nominations encouraged] For each of the pieces of information to be included in linking elements, the following questions apply: (i) should it be optional or required? (ii) should it be associated with links or allowed to vary per locator? (iii)should it be carried in the GI, in an attribute name, or in an attribute name-value pair? (iv) should we predefine a set of values? (v) if so, should we provide a mechanism for "subclassing"? (vi) should we allow the use of values other than those predefined or subclasses thereof? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 23:54:21 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 3.1.i exclude other information? The ERB schedule calls for voting on Feb. 26 on these items. 3.1.i Should we allow links to contain other information than that described in the spec? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 23:54:25 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 3.2.a Name for generalized multilink The ERB schedule calls for voting on Feb. 26 on these items. 3.2.a What should the generalized multiway link be called? Multilink, General Link, Independent link, anything else? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 23:54:41 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 3.2 c-d Content of linking elements? The ERB schedule calls for voting on Feb. 26 on these items. 3.2.c Should we provide a content model for general links, and if locators live in subelements, for them? 3.2.d Should we allow these links to contain anything other than the PCDATA and, perhaps locator subelements? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 20 Feb 1997 23:53:36 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: 3.a List link required? The ERB schedule calls for voting on Feb. 26 on these items. 3.a. The initial draft does not have any construct analogous to the "List Link" construct in Eliot's proposal. Do we need one? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 21 Feb 1997 09:03:54 +0000 (GMT) From: Peter Flynn Subject: Re: What to do given both SYSTEM and PUBLIC? To: w3c-sgml-wg@w3.org Joe writes: > What I meant was: it's not possible to write a program that will, > given an arbitrary FPI, return the public text denoted by that FPI. OK, I was using "resolve" in a quite different sense: "work out what file to find this DTD/ent, but stopping short of actually retrieving it" One thing that niggles is that all the mechanism for doing it is very nearly in place. If the ISO 9070 Registrar held a publicly-accessible list of POIs and their servers, this would encourage registration, and "+//Foo, Inc//..." could easily be resolved as (eg) {ftp|http|whatever}://foo.com/... Are there any plans for this (anyone from the GCA here)? Unregistered owners would of course need to provide a SYSTEM id :-) ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 21 Feb 1997 09:24:37 +0000 (GMT) From: Peter Flynn Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? To: w3c-sgml-wg@w3.org David Durand writes: > And we don't need to drag HyTime in to explain that. Amen. > >>2.1.d If we allow such recognition, what should the attribute be, and > >> what should be the values for each element type we define? > > >It should be named 'XML-form' Do we propose an AF for what users and authors currently call "forms" (ie fill-in forms a la HTML
)? I foresee infinite confusion here. I don't much care what name is picked, but no leading or trailing hyphens. > But if we could find a reason to use blink it would be so amusing! Maybe Eve could revisit "butt" wrt "link" with a view to this :-) ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 12:43:16 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: In lieu of multiple attlists: LINK? At 21:08 20.02.97 +0100, Steve DeRose wrote: >We almost all agree that the best long-term solution is to allow multiple >ATTLIST decls, so a document can start > > xml-link CDATA #fixed "xml-tlink" > > ]> > >This documents that the tei element is a tlink in XML terms. > >We think we can have multiple attlists when the TC passes. It's not clear >what to do in the meantime. Choices include: > >1 Play it Safe... >2 Count on Utopian ATTLISTs... >3 Stopgap PI... >4 GI escape hatch... > How about: 5 A Restricted Subset of Implicit LINK: ]> A tad more verbose than the "ideal" solution given above, but 100% kosher SGML that will give the application all the information it requires. For widely-used, public DTDs like TEI, the link attribute set and the link set declaration would be stored externally: Before anyone objects that the LINK feature has been jettisoned forever >from XML, let me point out that the situation we have here is analagous to that of SHORTTAG and the use of the NET delimiter to enable self-identifying EMPTY elements: - The use of the NET delimiter was a way of ensuring that XML documents remained fully SGML-conformant (given the correct SGML declaration). It requires the use of the SHORTTAG feature but that does not imply that any other facilities provided by SHORTTAG automatically become part of XML... - The use (a restricted subset of) implicit link would be a way of ensuring that XML documents remain fully SGML-conformant (given the correct SGML declaration). It requires the use of the LINK feature but that does not imply that any other facilities provided by LINK automatically become a part of XML... The restrictions (compared with complete implicit link) could be (as draconian as): 1. Only one link type declaration is allowed. It must be called "xml-link" and it is by definition an "active" link type for an XML application. 2. The combined external and internal link type declaration subset can only contain one link attribute set, one link set declaration (named #INITIAL) and no ID link set declaration. 3. The link attribute set can only contain attribute definition list declarations (i.e. no entity declarations). 4. Only fixed attributes may be declared. 5. The source element specification in the link rules (of the link set declaration) consists only of the associated element type (i.e. no USELINK, POSTLINK or link attribute specification) This would give us something midway between simple and implicit link: A way of associating fixed attributes with any element type (not just the document element), but without implicit link's context sensitivity. It seems to me that this is PRECISELY the kind of use for which LINK was originally intended: the association of processing with structure in a modular and eXtensible way. It provides the perfect, SGML-compliant way of making existing documents XML-processable without having to modify the DTD or document, and without having to invent new syntax. Surely this is a no-brainer? Best regards, Steve -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 21 Feb 1997 11:53:14 +0000 (GMT) From: Peter Flynn Subject: Re: 3.1.a All linkage info in markup not data? To: w3c-sgml-wg@w3.org > 3.1.a Should we have a principle that all linkage information is encoded in > GIs and/or attribute values, never in character data? It would make parsing (and thus the writing of XML apps) much easier if this was so, and I think that's what we should encourage. Providing an additional way to do something just complicates it, unless there is some serious tangible benefit. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 06:41:28 -0600 To: w3c-sgml-wg@w3.org From: Robert Streich Subject: Re: SDATA [was: Re: SERIOUS concerns about implementation] At 01:23 PM 2/20/97 EST, lee@sq.com wrote: >Once this has been done for the (large) subset of ISO entities supported by >Unicode, you'll just refer to the new public IDs and through the unspecified >magic of CATALOGs everything will work :-) I question your use of "large" here, Lee. I made some preliminary looks into this late last year and my impression was that Unicode had support for just over *half* of the ISO SDATA entities. I suppose you could still call that "large," but it seems rather misleading. Yes, I've seen lots of hand-waving on Unicode's private use areas, but on that issue I'll claim to be from Missouri--I'll believe it when I see it. bob Robert Streich streich@slb.com Schlumberger voice: 1 512 331 3318 Austin Research fax: 1 512 331 3760 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 06:50:18 -0600 To: w3c-sgml-wg@w3.org From: Robert Streich Subject: Re: SERIOUS concerns about implementation At 09:01 PM 2/20/97 -0500, David Durand wrote: >At 8:20 PM +0000 2/20/97, Digitome Ltd. wrote: >>I aggree. But I *do* wish we could stop referring to SGML files as "legacy". >>Surely SGML->XML is a "down-translation" not an "up-translation". > >Afraid not. You lose no information in going from SGML to XML, unless you >have somehow managed to come up with a way to use SHORTREF that could not >be equivalently expressed with tags. It is a cross-translation, since any >SGML DTD and any XML DTD should be able to operate at the same level of >abstraction. This seems a strange comment coming from you, David. Any time you reduce a grammar, you reduce expressibility. Any time you reduce expressibility, you lose information. bob Robert Streich streich@slb.com Schlumberger voice: 1 512 331 3318 Austin Research fax: 1 512 331 3760 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 06:41:36 -0600 To: w3c-sgml-wg@w3.org From: Robert Streich Subject: Re: SERIOUS concerns about implementation At 05:23 PM 2/20/97 GMT, Peter Murray-Rust wrote: > [trimmed] >My own position is that my DTD (CML) is (now) not interoperable with XML. >The problem is not primarily technical. The components that CML interoperates >with belong to other organisations who own the copyright and for each of >which I shall have to get permission to alter and redistribute the material. >Whilst I am sure this will come in time, it's not something that a single >individual is likely to make much headway with. Therefore, I cannot >legally distribute my material in XML-form (unless I have misunderstood >this). > [trimmed] I wouldn't worry too much, yet, Peter. I saw long ago that XML would be untenable as a data format for managing source docs and that we would have to adopt on-the-fly conversion if we chose to use it at all for delivering documentation over the net. I'm sure that there will be PD tools available to do just that since, so far, it doesn't seem to be too difficult of a transformation. bob Robert Streich streich@slb.com Schlumberger voice: 1 512 331 3318 Austin Research fax: 1 512 331 3760 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 08:18:45 -0600 From: len bullard To: Jon Bosak CC: w3c-sgml-wg@w3.org Subject: Re: SERIOUS concerns about implementation Jon Bosak wrote: > > | > I aggree. But I *do* wish we could stop referring to SGML files as > | > "legacy". Surely SGML->XML is a "down-translation" not an > | > "up-translation". > | > | And the language in fact obscures what the most likely application > | of XML is: a delivery format on the Web for SGML. > > Which is (surprise!) what we're trying to do here. Right. Sort of a Duh, but in the blizzard of alligators, it is good to remember which particular swamp is being drained. > Is it time to point to our activity statement again? > > http://www.w3.org/pub/WWW/MarkUp/SGML/Activity Sure, but in preparing the FAQ, public announcements, pleas for shareware, the gotchas should be pointed out. It looks trivial, but it is quite a bit of work to translate all of this, change the relevant policy documents, etc. Then they get to learn about all of the linking features, processing specs. Busy two years ahead. Peter MR is pointing out something of interest and that is, without tools that do the chores, the concepts are trivial, but the grunt work isn't. Two tracks: translation for XML tools of existing SGML, and output from SGML tools where the work continues in SGML, but the delivery format is XML. Later, as the WG8 works out the details for the TC and establishes an SGML-Lite built on XML, all of the information about how SGML -> XML translations occur should be stated with a minimum of fuss. We've taught them so long that the DTD is sacrosanct, PIs are Bad, etc, now we have to be ready to calm the waters. Get out the long staff. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 08:25:13 -0600 From: len bullard To: Peter Flynn CC: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Peter Flynn wrote: > > David Durand writes: > > > And we don't need to drag HyTime in to explain that. > > Amen. Dead wrong. First, "drag in" is inflamatory not helpful. If it is an arch form, then referencing ISO 10744 does not hurt. Second, when SGML Lite is established by ISO, it makes the relationship clear and concise. Y'all are wandering into the weeds of religion and personal animosities. It won't help. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Fri, 21 Feb 97 15:01:28 GMT To: w3c-sgml-wg@w3.org Subject: Re: 3.1.a All linkage info in markup not data? > 3.1.a Should we have a principle that all linkage information is encoded in > GIs and/or attribute values, never in character data? Yes. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Fri, 21 Feb 97 15:03:11 GMT To: w3c-sgml-wg@w3.org Subject: Re: 3.1.i exclude other information? > 3.1.i Should we allow links to contain other information than that > described in > the spec? If you mean link elements (:-), then yes, on the AF implicit model, it makes sense to allow me to have non-XML attributes on my linking elements. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Fri, 21 Feb 97 15:05:43 GMT To: w3c-sgml-wg@w3.org Subject: Re: 3.2.b Locators in attributes or elements? > 3.2.b Should the locators of a general link be packaged in attributes > as in HyTime, or as child elements as in the initial draft? I liked the child elements approach, especially as that means many (most) of the attributes in each locator sub-element will be the same as ones in in-line link elements (or whatever they are to be called). ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Fri, 21 Feb 97 15:23:03 GMT To: w3c-sgml-wg@w3.org Subject: Re: 3.2.a Name for generalized multilink > 3.2.a What should the generalized multiway link be called? Multilink, > General Link, Independent link, anything else? Multilink will do, xml-mlink for short. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Fri, 21 Feb 97 15:21:36 GMT To: w3c-sgml-wg@w3.org Subject: Re: 3.3 XML Analogue of HTML " 3.3.a Should we have a type of link that tries to be a nice clean superset of > HTML's Anchor? Yes, but that doesn't mean I go for reserved GIs, since (following Paul's example) would do the trick. > 3.3.b If so, what should we call it? As above, xml-link, with xml-mlink for non-inline-links. > 3.3.c If 3.2.b goes the way of child elements for locators, should the "A" > link have a single child element for consistency with that, or no such > element for consistency with HTML? See my comments on 3.2.b -- I like having the attributes on the xml-link element itself, with similar names to the ones appearing on each locator sub-element of xml-mlinks. > 3.3.d Should we regard such an "A" link as involving one or two resources? It must be two, surely, so applications can treat links and mlinks the same for most purposes. > 3.3.e If it involves two resources, is it a problem that there is no obvious > place to put locator metadata for the "implied" resource? My draft proposal had a solution for that. As far as I can see the only such metadata is not locator metadata at all, but resource (aka endpoint) metadata, of which the only two proposed so far are role and caption. I'd vote for using 'role' and 'caption' for the explicitly located reference (i.e. the one specified using 'href' and 'hrtype'), and using 'irole' and 'icaption' for the implicit resource (which doesn't need 'href' or 'hrtype'). > 3.3.f SHould we provide a content model for "A" links? No. Just as I can explicitly locate any sub-tree of a document, I should be able to contain and implicitly locate any sub-tree, if I write my DTD to allow it. > 3.3.g Should we allow "A" links to contain anything other than PCDATA? Yes, see above. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Fri, 21 Feb 97 15:40:31 GMT To: w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: Link contents question matrix > Dimension 1: Which pieces of information should be specified for > possible inclusion in linking elements? > > b. Type > c. Role > d. locator > e. caption > g. locator scheme (e.g. URL, FPI, TEI locator) All of those, i.e. NOT 'behaviour', and no others. > For each of the pieces of information to be included in linking > elements, the following questions apply: > > (i) should it be optional or required? All optional except locator. > (ii) should it be associated with links or allowed to vary per locator? Type is per link element, locator and scheme per explicit resource (i.e. one in (simple) links, one per locator element in mlinks); caption and role per resource (i.e. two in links (see previous message about name collision) and one per locator element in mlinks). > (iii)should it be carried in the GI, in an attribute name, or in an attribute > name-value pair? All in av-pairs. > (iv) should we predefine a set of values? Type: no, just a syntax, as before: a(.a)* Role: ditto. Locator scheme: a minimum set, not closed. Locator: no, just a syntax per scheme, by reference to relevant standard Caption: CDATA > (v) if so, should we provide a mechanism for "subclassing"? Implicit in answers above. > (vi) should we allow the use of values other than those predefined or > subclasses thereof? Duck. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Fri, 21 Feb 97 15:31:36 GMT To: w3c-sgml-wg@w3.org Subject: Re: 3.2 c-d Content of linking elements? Oops, too late I realise I'm not clear on the space of link element types. Are there two, namely 'XML Analogue of HTML " 3.2.c Should we provide a content model for general links, and if locators > live in subelements, for them? Yes for subelements of general link ELEMENTS, no for the rest of the content. > 3.2.d Should we allow these links to contain anything other than the PCDATA > and, > perhaps locator subelements? Yes, by parity of argument with in-line links. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 21 Feb 1997 16:19:25 +0000 (GMT) From: Peter Flynn Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? To: w3c-sgml-wg@w3.org I wrote: > > > And we don't need to drag HyTime in to explain that. > > > > Amen. Len says > Dead wrong. > > First, "drag in" is inflamatory not helpful. If it is an > arch form, then referencing ISO 10744 does not hurt. I didn't mean to be rude about HyTime. I meant we don't want lengthy screeds about it in the XML spec. Referencing it is fine. > Y'all are wandering into the weeds of religion and personal > animosities. No, none intended. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 21 Feb 1997 16:29:27 +0000 (GMT) From: Peter Flynn Subject: Re: SERIOUS concerns about implementation To: w3c-sgml-wg@w3.org Len writes: > > Is it time to point to our activity statement again? > > > > http://www.w3.org/pub/WWW/MarkUp/SGML/Activity > > Sure, but in preparing the FAQ, public announcements, > pleas for shareware, the gotchas should be pointed out. Yes please...if anyone spots pet gotchas for the FAQ, I'd be grateful for them. v.3 should be out this weekend at http://www.ucc.ie/xml/ ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 12:42:42 -0500 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@w3.org Subject: Re: 3.1.a All linkage info in markup not data? >3.1.a Should we have a principle that all linkage information is encoded in > GIs and/or attribute values, never in character data? If information==definition, yes. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 12:59:28 -0500 To: w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: 3.2.b Locators in attributes or elements? At 03:05 PM 02/21/97 GMT, Henry S. Thompson wrote: >> 3.2.b Should the locators of a general link be packaged in attributes >> as in HyTime, or as child elements as in the initial draft? > >I liked the child elements approach, especially as that means many >(most) of the attributes in each locator sub-element will be the same >as ones in in-line link elements (or whatever they are to be called). There is one syntactic advantage i see to the element approach: It provides a way to attach additional information to each linkend. If, for example, the user wants to add an explainer^H^H^H^H^H^H^H^H^H^H^H label to each linkend, it's a lot cleaner to do it with subelements: Try combining them LABELs into one element! Obviously doable by introducing internal syntax (prohibit semicolon or something and pack 'em up). But ugly. Steve %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 12:59:27 -0500 To: w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: 3.1.a All linkage info in markup not data? At 11:53 PM 02/20/97 -0800, Tim Bray wrote: >The ERB schedule calls for voting on Feb. 26 on these items. > >3.1.a Should we have a principle that all linkage information is encoded in >GIs and/or attribute values, never in character data? No. Unenforceable, and sometimes it's useful anyway, such as for supporting links from every word to dictionaries/glossaries/etc, for links from 'the current selection', etc. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 12:59:26 -0500 To: w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: SERIOUS concerns about implementation At 06:38 PM 02/20/97 -0600, len bullard wrote: >> I aggree. But I *do* wish we could stop referring to SGML files as "legacy". >> Surely SGML->XML is a "down-translation" not an "up-translation". I don't think vertical terms are applicable. Since the element structures of both forms are the same, I don't think there's vertical motion involved at all. It would seem very odd to me to say that global changes of approximately ]\)/--> to and ]\)> to are "down-translation". They seem purely horizontal; certainly none of the real information has changed; only the syntactic details of its representation. Certainly we wouldn't call re-vamping an SGML file to use a new delimiter set "down" or "up" translation; and that's all that's really going on here (the only difference being a clearl trivial one, that SGML doesn't presently let us change COMO and COMC separately). %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 12:59:27 -0500 To: Robert Streich , w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: SERIOUS concerns about implementation At 06:50 AM 02/21/97 -0600, Robert Streich wrote: >This seems a strange comment coming from you, David. Any time you reduce a >grammar, you reduce expressibility. Any time you reduce expressibility, you >lose information. We should probably define "expressibility" before trying to evaluate these axioms. Reducing SGML's grammar to document ::= char* would certainly add to expressibility in one sense, but drastically subtract >from it in another. so when we say 'expressibility' or 'expressiveness' or 'expressive power', we need to know whether we mean: * maximizing the number of ways i can say the same thing. * minimizing the inconsistencies with which the same thing can be said * making the maximum number of strings valid * making the minimum number of strings valid * making the language easiest to use so as to minimize errors * having the most 'custom' settings so everyone can make non-similar- appearing syntaxes that all still conform. * maximizing the range of structurally distinct data that can be represented. or something else. the last one is the one i'd prefer; I don't consider being able to do the same thing (namely, start a P element) in all these ways "expressiveness", except in the way clothing designers use the term (all are valid SGML given the right context, and I haven't even used variant delimiters):

Hello, world &my.starttag.entity; &#RE;&#RS; Oh, I suppose we should also define "information" before we evaluate whether it's gained or lost. In Information Theory (see anything by Claude Shannon), it would be hard to show that any of the above differ in information content, though they might differ in the entropy with which a certain quantitiy of information is being transmitted. S %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Henry S. Thompson" Date: Fri, 21 Feb 97 18:21:09 GMT To: w3c-sgml-wg@w3.org Subject: Re: 3.1.a All linkage info in markup not data? sjd wrote: > At 11:53 PM 02/20/97 -0800, Tim Bray wrote: > >3.1.a Should we have a principle that all linkage information is encoded in > >GIs and/or attribute values, never in character data? > > No. Unenforceable, and sometimes it's useful anyway, such as for supporting > links from every word to dictionaries/glossaries/etc, for links from 'the > current selection', etc. I THINK if we clarified the question to be "should we provide a mechanism in the minimum supported locator schemes for using link element content as part of a locator" you might agree the answer was 'NO', but that leaves the door open in an unstated way for non-minimum-supported schemes to do so. ht %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org Subject: Re: 3.2.b Locators in attributes or elements? Date: Fri, 21 Feb 1997 10:42:12 -0800 From: Joe English Tim Bray wrote: > The ERB schedule calls for voting on Feb. 26 on these items. > > 3.2.b Should the locators of a general link be packaged in attributes > as in HyTime, or as child elements as in the initial draft? To allow maximum flexibility in DTD design, I would prefer that both be allowed (in fact I'd like to see this in HyTime too...). If it has to be one or the other, I'd vote for putting them in atttributes (partly for compatibility with HyTime, and partly because that seems like the simplest and easiest to use). --Joe English jenglish@crl.com %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 19:32:40 +0000 To: w3c-sgml-wg@w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Re: 3.1.i exclude other information? > 3.1.i Should we allow links to contain other information than that > described in > the spec? Yes. What would be gained by not allowing other info? Sean %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 19:32:37 +0000 To: w3c-sgml-wg@w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Re: 3.1.a All linkage info in markup not data? > 3.1.a Should we have a principle that all linkage information is encoded in > GIs and/or attribute values, never in character data? > Yes. Sean %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 13:58:32 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: In lieu of multiple attlists: LINK? At 12:43 PM +0100 2/21/97, Steve Pepper wrote: >Before anyone objects that the LINK feature has been jettisoned forever >from XML, let me point out that the situation we have here is analagous to >that of SHORTTAG and the use of the NET delimiter to enable self-identifying >EMPTY elements: Yes, but it's at least _arguable_ the people agree on what SHORTTAG means, and how it is to be interpreted. LINK introduces a whole new syntax, and is widely avoided even within the SGML community (it is, of course, popular with some SGML users). No-one defended LINK before, and we already have 2 ways to continue avoiding it, so why resurrect it now... We don't need any new syntax to solve the problem we have, so we should not use any, especially something as controversial as LINK. >Surely this is a no-brainer? Yes, reject. -- David (knee-jerk) Durand _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 14:29:14 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? At 8:25 AM -0600 2/21/97, len bullard wrote: >Peter Flynn wrote: >> >> David Durand writes: >> >> > And we don't need to drag HyTime in to explain that. >> >> Amen. > >Dead wrong. > >First, "drag in" is inflamatory not helpful. If it is an >arch form, then referencing ISO 10744 does not hurt. >Second, when SGML Lite is established by ISO, it makes >the relationship clear and concise. I meant that if we are taking a significantly shrunken subset of HyTime Architectural Forms [for instance, I think we can and should avoid any restrictions on content models], then it may be simpler to explain what we are doing directly, rather than pointing at HyTime, and explaining the differences. If you are defining a scripting language containing only the commands "if-then-else", expressions, variable assignment and "while" loops, pointing to C++ and saying what to ignore is not a productive explanatory strategy. You might mention that C++ compaitibility is a goal, but that would be additional information for the intersted, not part of the core explanation. "Drag in" was intended to say that making normative reference to irrelevant information is bad. In a separate message (maybe the same, for all I remember) I clearly advocated retaining a reference to HyTime, and it's AF facilities. I personally think it was a mistake to try to standardise them for applicability beyond HyTime, but they exist and we should not hide that fact. I'm not trying to supress the HyTime links -- HyTime has been very influential in forming how at least some of us think about this stuff -- but I do want to make XML, and XML linking stand on their own, without normative references to ISO standards. >Y'all are wandering into the weeds of religion and personal >animosities. It won't help. No personal animosity intended, nor religious argument either. I'm religious about separating declaration and processing (though if we don't define sufficiently powerful processing, I agree with you, we are SOL). I'm certainly not religious about HyTime either way. In fact, I'm aggressively agnostic. I think you may mistrust me because I'm so ready to question HyTime's specific solutions, but I don't regret having spent the time on it that I have, nor do I think it should be supressed. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 14:14:45 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: SERIOUS concerns about implementation At 6:50 AM -0600 2/21/97, Robert Streich wrote: >At 09:01 PM 2/20/97 -0500, David Durand wrote: >>Afraid not. You lose no information in going from SGML to XML, unless you >>have somehow managed to come up with a way to use SHORTREF that could not >>be equivalently expressed with tags. It is a cross-translation, since any >>SGML DTD and any XML DTD should be able to operate at the same level of >>abstraction. > >This seems a strange comment coming from you, David. Any time you reduce a >grammar, you reduce expressibility. Any time you reduce expressibility, you >lose information. In the information-theoretical sense this is obviously true, but in terms of the practical problem of preserving information that is usefully used to control processing, the case is less clear. I did make a few exceptions, and James pointed out another, data attributes, which I aleways forget because I've never used them... My point was that almost all of the "extra expressivenes" of SGML provides syntactic options for things that can be recorded in other ways. >From my experience, only Public and SDATA are things that I've ever had occcasion to used. Data attributes seem as if they are the kind of thing that doesn't move well across systems, but I may be wrong there -- it seems to me that I can get equivalent effects with NOTATION, though maybe not as elegantly. If it's a down-translation, it's not very far down, and I find it hard to imagine an SGML document that could not be converted into an equivalent XML document without losing information. So if change the definition of information, and instead ask for an effective information-preserving transformation from SGML->XML, I would say that it always exists. So that you need not lose information in moving >from SGML to XML. The same is not true (in a meaningful sense) for RTF, or Postscript, for instance... -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 14:36:23 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 3.1.a All linkage info in markup not data? At 12:59 PM -0500 2/21/97, Steven J. DeRose wrote: >At 11:53 PM 02/20/97 -0800, Tim Bray wrote: >>The ERB schedule calls for voting on Feb. 26 on these items. >> >>3.1.a Should we have a principle that all linkage information is encoded in >>GIs and/or attribute values, never in character data? > >No. Unenforceable, and sometimes it's useful anyway, such as for supporting >links from every word to dictionaries/glossaries/etc, for links from 'the >current selection', etc. Sorry. I think we should say that all _XML-linking_ information is encoded in GIs or attribute values. With generic markup people can _implement_ any behavior that they can define -- but we are defining behaviors that people can count on -- and links in CDATA are not such behaviors unless we define how they work. I think the fact that people can implement other linking mechanisms goes without saying, but we should be explicit about exactly what is permitted by XML linking. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 14:41:28 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 3.2.b Locators in attributes or elements? At 12:59 PM -0500 2/21/97, Steven J. DeRose wrote: >>> 3.2.b Should the locators of a general link be packaged in attributes >>> as in HyTime, or as child elements as in the initial draft? My feeling is no, we should use attributes. Now to comment on Steve's answer, because it may illumuninate my own. >At 03:05 PM 02/21/97 GMT, Henry S. Thompson wrote: >> >>I liked the child elements approach, especially as that means many >>(most) of the attributes in each locator sub-element will be the same >>as ones in in-line link elements (or whatever they are to be called). > >There is one syntactic advantage i see to the element approach: It provides >a way to attach additional information to each linkend. If, for example, the >user wants to add an explainer^H^H^H^H^H^H^H^H^H^H^H label to each linkend, >it's a lot cleaner to do it with subelements: > > > HREF="http://www.ebt.com//u/sjd/bio.htm"> > HREF="http://lit.org//milton/paradise_lost.htm#27966" > LABEL="In this passage Milton clearly alludes to D. Steele."> > HREF="http://lit.org//dsteele/yet_another.htm" > LABEL="See, they both talk about people."> > > >Try combining them LABELs into one element! Obviously doable by introducing >internal syntax (prohibit semicolon or something and pack 'em up). But ugly. I agree that this syntax is better for explainers, but it's less-compatible with the "new" HyTime as I understand it, and it means that we have to talk about content models which I would like to leave completely open to the user. So, although I love explainers (Labels), and have spent years arguing that they should be supported by Hypertext systems, I'd rather lose them and keep the syntax simpler and more flexible. It will also keep our Mini-AF description much shorter and more understandable, as all we need to specify are attributes, and we don't even need to raise the confusing questions of what meta-content models mean and require. -- David "Explainer Apostate" Durand _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 11:42:32 -0800 (PST) From: Bill Smith Subject: Re: Loss of information going from SGML to XML To: w3c-sgml-wg@w3.org Yes XML isn't full SGML but that is by design not accident. While we have lost "expressive" power, like being able to omit tags, we have something that itself is far simpler to express and will make it possible for information delivered over the web to "express" itself. This is what we should focus on not bemoaning the fact that "information" is lost in a "down translation" from SGML. XML *is* SGML. No down translation required - as long as you stay within the lines. If you can't live without the great intricacies of SGML, tar, gzip, and ftp work quite well for delivering a wad of SGML over great distances. Unfortunately, full-up SGML isn't particularly amenable to the Web and that's why we're here. XML is designed to bring the benefits of SGML to the Web in a manner that can be understood by mere mortals. This will allow more information to be delivered in meaningful ways than is possible with current web practice. I don't view this as information loss, but rather information gain. We aren't down translating SGML, we're uptranslating the Web. Sorry to take up your time with this but I've been a bit frustratedby this topic. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 21:29:38 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: Re: In lieu of multiple attlists: LINK? At 19:58 21.02.97 +0100, David (knee-jerk) Durand wrote: >At 12:43 PM +0100 2/21/97, Steve Pepper wrote: > >>Before anyone objects that the LINK feature has been jettisoned forever >>from XML, let me point out that the situation we have here is analagous to >>that of SHORTTAG and the use of the NET delimiter to enable self-identifying >>EMPTY elements: > >Yes, but it's at least _arguable_ the people agree on what SHORTTAG means, >and how it is to be interpreted. I have never felt the need to ask the question "what does LINK mean", only "what does it do?". As to interpretation: Isn't it patently obvious that the example I gave should be interpreted as meaning nothing more or less than "associate the semantics of xml-link with the xref element type"? > LINK introduces a whole new syntax, and is >widely avoided even within the SGML community (it is, of course, popular >with some SGML users). LINK just gives us a modular, extensible wrapper for the multiple attribute definition lists everyone seems to want. The syntax is dead simple, especially in the restricted form I suggested and there is free working software out there that will handle it. > No-one defended LINK before, and we already have 2 >ways to continue avoiding it, so why resurrect it now... I was late joining this list and have spent several weeks catching up. I wasn't aware that LINK had been proposed, discussed and rejected, otherwise I wouldn't have "resurrected" it. Is this the case? If so, I apologise. >We don't need any new syntax to solve the problem we have, so we should >not use any, especially something as controversial as LINK. The syntax isn't new. It dates from 1986 (earlier, actually). And I don't regard LINK as controversial. Merely little understood and much maligned. Aside from knee-jerk reactions, what are the objections? Steve -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 14:38:04 -0600 From: Len Bullard To: Peter Flynn CC: w3c-sgml-wg@w3.org Subject: Re: SERIOUS concerns about implementation Peter Flynn wrote: > > Len writes: > > > > Is it time to point to our activity statement again? > > > > > > http://www.w3.org/pub/WWW/MarkUp/SGML/Activity > > > > Sure, but in preparing the FAQ, public announcements, > > pleas for shareware, the gotchas should be pointed out. > > Yes please...if anyone spots pet gotchas for the FAQ, I'd > be grateful for them. v.3 should be out this weekend at Just quickly glancing, XML isn't an "application of SGML". I think it is a proper subset. HTML is an application of SGML, and could be an application of XML. That is, perhaps, one way to get the point across. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 14:35:04 -0600 From: Len Bullard To: Peter Flynn CC: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Peter Flynn wrote: > > I wrote: > > > > And we don't need to drag HyTime in to explain that. > > > > > > Amen. > > Len says > > > Dead wrong. > > > > First, "drag in" is inflamatory not helpful. If it is an > > arch form, then referencing ISO 10744 does not hurt. > > I didn't mean to be rude about HyTime. I meant we don't want lengthy > screeds about it in the XML spec. Referencing it is fine. Not screeds: just the proper references. > > Y'all are wandering into the weeds of religion and personal > > animosities. > > No, none intended. Ok. The rest of this isn't aimed at you, Peter, or anyone in particular. The other side of this, we will need all the personal, public, private and professional support we can get. The SGML community is our natural ally. Another duh, but worth remembering. That is simply political. What is not political are the policy documents out there, that is, the ISO, government, company, etc. that do reference ISO. Where the alliance is strong and not encumbered by weasel wording or other strange and unneccessary considerations, we whose job it is to see that XML is adopted as a preferred delvery format for SGML can do that a lot easier where the references are clear. HyTime/SGML can do us a lot of good. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 14:54:37 -0600 From: Len Bullard To: "Steven J. DeRose" CC: w3c-sgml-wg@w3.org Subject: Re: SERIOUS concerns about implementation Steven J. DeRose wrote: > > At 06:38 PM 02/20/97 -0600, len bullard wrote: > > >> I aggree. But I *do* wish we could stop referring to SGML files as "legacy". > >> Surely SGML->XML is a "down-translation" not an "up-translation". > > I don't think vertical terms are applicable. Since the element structures of > both forms are the same, I don't think there's vertical motion involved at all. Umm... I didn't say that. That is Sean's comment. I say it is a crab-walk, meaning, same thing, just sideways movement. :-) We'll have to be clear about XML and SGML. I think subset is the best description although the crabwalk bit has to be explained too. Narrowing the features and fixing some holes that open up when one does is about it. Also, a few things like minimization were removed because that complicated using XML without a DTD. That won't be precise enough. I have to review the FAQ in detail. I think it necessary to say, "we are not fixing SGML; we are subsetting it to make it easier to apply for those cases where the full requirements of SGML are too burdensome, but otherwise, this is still SGML. What we are doing with the linking is a different matter. Here we have a subset and/or application of HyTime that is easier to understand and develop and will provide a much more powerful linking capability than is currently in use on the Internet." len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org Subject: Re: 3.2.b Locators in attributes or elements? <2.2.32.19970221175928.00be7998@pop> Date: Fri, 21 Feb 1997 13:54:44 -0700 From: Dave Hollander How would (should?) this work for non-string lables? Dave > At 03:05 PM 02/21/97 GMT, Henry S. Thompson wrote: > >> 3.2.b Should the locators of a general link be packaged in attributes > >> as in HyTime, or as child elements as in the initial draft? > > > >I liked the child elements approach, especially as that means many > >(most) of the attributes in each locator sub-element will be the same > >as ones in in-line link elements (or whatever they are to be called). > > There is one syntactic advantage i see to the element approach: It provides > a way to attach additional information to each linkend. If, for example, the > user wants to add an explainer^H^H^H^H^H^H^H^H^H^H^H label to each linkend, > it's a lot cleaner to do it with subelements: > > > HREF="http://www.ebt.com//u/sjd/bio.htm"> > HREF="http://lit.org//milton/paradise_lost.htm#27966" > LABEL="In this passage Milton clearly alludes to D. Steele."> > HREF="http://lit.org//dsteele/yet_another.htm" > LABEL="See, they both talk about people."> > > > Try combining them LABELs into one element! Obviously doable by introducing > internal syntax (prohibit semicolon or something and pack 'em up). But ugly. > > Steve > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 16:08:12 -0500 (EST) From: Sam Hunting To: w3c-sgml-wg@w3.org Subject: Re: In lieu of multiple attlists: LINK? Yes, but it's at least _arguable_ the people agree on what SHORTTAG means [as opposed to LINK], and how it is to be interpreted. I have never felt the need to ask the question "what does LINK mean", only "what does it do?". As to interpretation: Isn't it patently obvious that the example I gave should be interpreted as meaning nothing more or less than "associate the semantics of xml-link with the xref element type"? LINK introduces a whole new syntax, and is > >widely avoided even within the SGML community (it is, of course, popular > >with some SGML users). Let's talk about the syntax and the design goals, and not worry about popularity. There are four alternatives to Steve's proposal: >1 Play it Safe... >2 Count on Utopian ATTLISTs... >3 Stopgap PI... >4 GI escape hatch... Compare Steve's Proposal to Stopgap PI as already proposed by Paul -- which of the 10 design goals does Steve's proposal not meet? Just possibly, (5) the number of optional features. But compare implementing multiple attlists using a simplified LINK to implementing them using a hac.. stopgap PI. The first: clear syntax that is "formal and concise" and expressible and checkable using SGML. The second: syntax that, if formal, can only be understood by special-purpose, non-SGML that understands what's unside the processing instruction. I'm not sure that's a good precedent to set. Once blessed by the XML standard, PIs, doubtless in proprietary formats, will proliferate like kudzu all over everything. So much for design goal 6.... LINK just gives us a modular, extensible wrapper for the multiple attribute definition lists everyone seems to want. The syntax is dead simple, especially in the restricted form I suggested and there is free working software out there that will handle it. Agreed! No-one defended LINK before, and we already have 2 ways to continue avoiding it, so why resurrect it now... I'm not sure the argument from history impresses. If it meets the design goals now, for issues we have not hitherto addressed, then what's the problem? We don't need any new syntax to solve the problem we have, so we should >not use any, especially something as controversial as LINK. I too am new to the list -- avoidance of controvery is a design goal for XML? Doesn't the PI proposal propose a new syntax -- just one that only a special purpose tool can make use of, and that builds in theneed to convert XML data when the "real" solution comes to be? If Steve's proposal meets the design goals, why not use it now? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 14:58:30 -0600 From: Len Bullard To: "Steven J. DeRose" CC: Robert Streich , w3c-sgml-wg@w3.org Subject: Re: SERIOUS concerns about implementation Steven J. DeRose wrote: > > Oh, I suppose we should also define "information" before we evaluate whether > it's gained or lost. In Information Theory (see anything by Claude Shannon), > it would be hard to show that any of the above differ in information > content, though they might differ in the entropy with which a certain > quantitiy of information is being transmitted. Shannon? Alright, Steve! Better than Plato and almost as abstract. James made good points though in that he precisely stated what is given up in the crabwalk from SGML to XML. Again, a comparison of grove plans would be useful. Eliot? len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 15:17:27 -0600 From: Len Bullard To: David Durand CC: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? David Durand wrote: > I meant that if we are taking a significantly shrunken subset of HyTime > Architectural Forms [for instance, I think we can and should avoid any > restrictions on content models], then it may be simpler to explain what we > are doing directly, rather than pointing at HyTime, and explaining the > differences. Then what am I to make of Eliot's assertion that XML Linking is conforming HyTime. I admit that I don't have the time to work out the details of that. I also don't like restrictions on content models. It is a lot less ugly as deRose has shown to use them for linking information. > If you are defining a scripting language containing only the commands > "if-then-else", expressions, variable assignment and "while" loops, > pointing to C++ and saying what to ignore is not a productive explanatory > strategy. You might mention that C++ compaitibility is a goal, but that > would be additional information for the intersted, not part of the core > explanation. > > "Drag in" was intended to say that making normative reference to > irrelevant information is bad. That is the sticking point. Is it irrelevant? > I do want to make XML, and XML linking stand on > their own, without normative references to ISO standards. I'm not sure if that goal has any utility. Whereas, gratuitous references are not useful, normative references establish a chain of authoritative information. That does have utility. WG8 is very likely to build the SGML Lite over XML and that is a win-win for all of us. > No personal animosity intended, nor religious argument either. I'm > religious about separating declaration and processing (though if we don't > define sufficiently powerful processing, I agree with you, we are SOL). I'm > certainly not religious about HyTime either way. In fact, I'm aggressively > agnostic. I think you may mistrust me because I'm so ready to question > HyTime's specific solutions, but I don't regret having spent the time on it > that I have, nor do I think it should be supressed. Oh, I don't distrust the questions at all. I wish we had all been doing this some years ago online and in this fevered way. But that is past. What I want to see now is a clear authoritative chain of standards expressed as running code and embraced as COTS applications. Then we can all go watch deRose ice skate. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 15:24:09 -0600 From: Len Bullard To: David Durand CC: w3c-sgml-wg@w3.org Subject: Re: 3.1.a All linkage info in markup not data? David Durand wrote: > > At 12:59 PM -0500 2/21/97, Steven J. DeRose wrote: > >At 11:53 PM 02/20/97 -0800, Tim Bray wrote: > >>The ERB schedule calls for voting on Feb. 26 on these items. > >> > >>3.1.a Should we have a principle that all linkage information is encoded in > >>GIs and/or attribute values, never in character data? > > > >No. Unenforceable, and sometimes it's useful anyway, such as for supporting > >links from every word to dictionaries/glossaries/etc, for links from 'the > >current selection', etc. > > Sorry. I think we should say that all _XML-linking_ information is encoded > in GIs or attribute values. With generic markup people can _implement_ any > behavior that they can define -- but we are defining behaviors that people > can count on -- and links in CDATA are not such behaviors unless we define > how they work. This is a restriction we can live with in XML 1.0. Maybe longer. > I think the fact that people can implement other linking mechanisms goes > without saying, but we should be explicit about exactly what is permitted > by XML linking. "Permitted" might be the sticking word. All XML Linking can say is what a conforming application must guarantee. What is done beyond that by use of other attributes or element types is not something XML enables. Otherwise, we are stuck trying to provide the mechanisms for extensions to XML Linking when in effect, that should be an issue for XML 2.0 once XML 1.0 has been shaken like a rag doll in the dog's mouth with a kid pulling on it. We are the dollmaker, not the dog or the kid. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Cc: w3c-sgml-wg@w3.org Subject: Re: Loss of information going from SGML to XML Date: Fri, 21 Feb 1997 14:26:57 -0700 From: Dave Hollander To: w3c-sgml-wg@w3.org Thanks Bill! Please, keep things in perspective. Exaggerations like "XML is not SGML therefore it is no good" help no one. Lets not forget what, in my opinion is the real point, that XML is designed to increase the audience for SGML. The new audience has shown by their behavior that they are unwilling to make the commitment that full SGML requires. Yet, HTML has shown that an audience is there. Hopefully XML will help those whose "expressive" needs have outgrown HTML or any other fixed tag-set language. And because it is a proper sub-set of SGML, XML instances are instantly ISO-8879 compliant. All at a cost of *some* SGML users doing a relatively (relative to may of the translations they already do) simple transform. BTW, during the ERB meetings I often asked the question: what will this do to the expressive power? I was willing to give up a whole lot more that I had to. Dave PS. Here is Bill's text in 70 column format for those who do not have auto-wrap software. : Bill Smith > > Yes XML isn't full SGML but that is by design not accident. While we > have lost "expressive" power, like being able to omit tags, we have > something that itself is far simpler to express and will make it > possible for information delivered over the web to "express" itself. > This is what we should focus on not bemoaning the fact that "information" > is lost in a "down translation" from SGML. > > XML *is* SGML. No down translation required - as long as you stay > within the lines. > > If you can't live without the great intricacies of SGML, tar, gzip, and > ftp work quite well for delivering a wad of SGML over great distances. > Unfortunately, full-up SGML isn't particularly amenable to the Web and > that's why we're here. XML is designed to bring the benefits of SGML to > the Web in a manner that can be understood by mere mortals. This will > allow more information to be delivered in meaningful ways than is > possible with current web practice. > > I don't view this as information loss, but rather information gain. We > aren't down translating SGML, we're uptranslating the Web. > > Sorry to take up your time with this but I've been a bit frustratedby > this topic. > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 16:45:50 -0500 (EST) From: Sam Hunting To: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? I do want to make XML, and XML linking stand on their own, without normative references to ISO standards. I'm not sure if that goal has any utility. Whereas, gratuitous references are not useful, normative references establish a chain of authoritative information. That does have utility. David: If that is your goal, then what am I to make of Design Goal (3) "XML shall be compatibble with SGML"? What's more normative than "shall"? More ISO than SGML? Len: I agree. The kind of work I do is long-lived. For the sake of the integrity of my client's content, I want a stable reference point. Normative references, warts and all, provide that. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 15:41:23 -0600 From: Len Bullard To: Dave Hollander CC: w3c-sgml-wg@w3.org Subject: Re: Loss of information going from SGML to XML Dave Hollander wrote: > > Thanks Bill! > > Please, keep things in perspective. Exaggerations like "XML is not SGML > therefore it is no good" help no one. Lets not forget what, in my > opinion is the real point, that XML is designed to increase the audience > for SGML. The new audience has shown by their behavior that they are > unwilling to make the commitment that full SGML requires. Umm... has anyone actually said "XML is not SGML" or is that an exaggeration? Peter MR expressed discomfort with the number and amount of changes he was making to CML to be XML compliant. Since he is one of the very first to try this, we should be cognizant of his reaction. He supports this XML, so consider that for those for whom a case has not been made, for whom benefits are hard to demonstrate, that reaction will occur often. Ignoring the reaction is exactly the same mistake as ignoring the behavior of the audience you cite. That is the customer base speaking. Being on the ERB should make you more aware of the problem, not less. Otherwise, why are you there? len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: streich@austin.sar.slb.com Date: Fri, 21 Feb 1997 15:55:59 -0600 To: w3c-sgml-wg@w3.org Subject: Re: Loss of information going from SGML to XML dmh@hpsgml.fc.hp.com wrote: > Please, keep things in perspective. Exaggerations like "XML is not SGML > therefore it is no good" help no one. I think this is the exaggeration. I don't remember writing or reading "therefore it is no good." The point was that information is lost going >from SGML to XML. The point was made in the context of having information in SGML that did not fit "within the lines" of XML, i.e., where a down-translation was required. This is not a qualitative statement, just fact. Does the loss of information matter? Depends on the context doesn't it? I didn't qualify my statement as to the "goodness" or "badness" of XML. Please don't do so for me. bob %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: "Christopher R. Maden" Date: Fri, 21 Feb 1997 21:58:16 GMT To: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? [Sam Hunting] > > I do want to make XML, and XML linking stand on their own, without > normative references to ISO standards. > > > David: If that is your goal, then what am I to make of Design Goal > (3) "XML shall be compatibble with SGML"? What's more normative than > "shall"? More ISO than SGML? The proverbial CS bachelor's degree holder should be able to take the XML spec(s) and implement. They should not need to write checks to the ISO. Bibliographic references are certainly appropriate, as are "BTW, this is what HyTime calls ..." or "For SGML geeks, the differences are...". Saying, "To understand this, read ISO 10744 Technical Corrigendum 1," is a Bad Thing. -Chris -- Christopher R. Maden One Richmond Square DynaText SIT Technical Support Providence, RI 02906 USA Inso Corporation +1.401.421.9550 (voice) Electronic Publishing Solutions +1.401.521.2030 (facsimile) %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: cbullard@hiwaay.net Cc: w3c-sgml-wg@w3.org Subject: Re: Loss of information going from SGML to XML <330E1683.684C@hiwaay.net> Date: Fri, 21 Feb 1997 15:34:47 -0700 From: Dave Hollander Len, That Peter MR is an early indicator of how XML will be received by the SGML audience, is a point well taken. Perhaps we should consider a "Guide to Moving from SGML to XML" to help prevent surprise and confusion. Befor we consider changing the design based on one person's reaction we should first understand the nature of the reaction which the wg list did. Then, we should consider if this case is compatible with the design goals. As I recall Peter's initial dismay/confusion, it was that he would have to make changes, not the nature of them. The design never assumed that existing SGML applications would be XML complient, just that it would be straight forward to make the application complient. Since Peter's case is not really what we were designing for, then we should consider how XML is described and what types of support various audiences will need. Here, Peter's case has really helped. Not only should the nature of the transform be described, there needs to be work with various vendors and standards bodies to address the issues with entities. Given the nature of the group, we must rely on the market to address these needs. Dave %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 97 16:18:38 CST From: Michael Sperberg-McQueen Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? To: W3C SGML Working Group On Fri, 21 Feb 1997 16:46:31 -0500 Sam Hunting said: > >I do want to make XML, and XML linking stand on >their own, without normative references to ISO standards. > > ... >David: If that is your goal, then what am I to make of Design Goal (3) >"XML shall be compatibble with SGML"? What's more normative than >"shall"? >More ISO than SGML? I think this discussion is beginning to show signs that the participants are missing some of each other's basic assumptions, though those assumptions seem clear enough to some of the rest of us. If I understand Len and others aright, they worry that some people would like to conceal any relationship between XML Link and HyTime. This would be problematic for several reasons, among them the fact that some potential users will be worried if HyTime is *not* invoked, and (in some ways more important) it seems more honest to acknowledge our intellectual debts where we can. I believe there are certainly potential users for whom the mention of HyTime will cause fear, trembling, and a mad rush for the exit -- rightly or wrongly, HyTime has a fierce reputation as being very hard to understand and as making simple things so infernally complicated that it could not possibly be worth the trouble to understand it. This is a hard reputation to fight against (as I know to my sorrow, the TEI having a similar reputation in some circles). So it wouldn't surprise me if some of us did entertain the thought, from time to time, of completing an XML Link spec that never even mentioned HyTime. It won't happen, though. If Len is not stark raving mad (I try to keep an open mind), then noting the relation of XML Link to HyTime will help us with some potential adopters more than it will hurt us with others. At the risk of putting words in David's mouth, I think he is arguing a rather different point, namely whether the XML Link spec is to be a free-standing document which can be reliably understood on its own terms, or a document which refers to another document in such a way as to require that other document to be understood, before XML Link can be understood. A document that makes *normative* references to other documents cannot be understood without understanding those documents. In drafting the original XML language spec, we worked very hard to ensure that no *normative* reference to 8879 was necessary. There is (or should be) no point at which the XML language spec says "This works the way it does in 8879; see 8879 clause 42.42.42 for details." On the contrary, we did our best to make good on the claim that "This specification ... provides all the information necessary to understand XML version 1.0 and construct computer programs to process it." I claim that there *is* no normative reference to 8879 in the XML spec. The conformance of XML documents to 8879 follows as a logical consequence of the constraints given in the spec; it does not rely on a rule formulated as "You have to do whatever 8879 says you do." I believe David and some others are mostly arguing that we need to take the same approach with XML Link. It will *not* be a good idea to say something like "XML Link uses HyTime-style architectural forms as defined in the Extended Facilities Annex. See that document for notation and meaning of architectural forms." There are two reasons this would be a bad idea. (1) We want people to be able to understand XML Link by reading just the XML Link spec; any requirements, notation, and semantics we take over from HyTime should be documented fully in the XML Link doc. (2) HyTime AFs have a lot of machinery XML Link will probably not use. There is no need to refer your visitors to a map of the U.S. when all they want to know is where the guest bedroom is. We know from experience that if you define a simple subset of a complex standard by saying "Well, use this standard, but turn off the following features," the simple subset might as well not exist. For example: minimal SGML and basic SGML. No one can understand either one without understanding pretty much all of 8879. It is considerations like these, I think, that David has in mind when he wants to avoid normative references. I agree: normative references are for cases where you don't want to have to explain everything the reader needs to know. That should be avoided as far as humanly possible in all three of the XML-family specs. My two cents. -C. M. Sperberg-McQueen %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 16:55:22 -0600 From: Len Bullard To: Dave Hollander CC: w3c-sgml-wg@w3.org Subject: Re: Loss of information going from SGML to XML Dave Hollander wrote: > > Len, > > That Peter MR is an early indicator of how XML will be received by the > SGML audience, is a point well taken. Perhaps we should consider a "Guide to > Moving from SGML to XML" to help prevent surprise and confusion. Yes. It should be printed and given out at the XML GCA Meeting. > Befor we consider changing the design based on one person's reaction we > should first understand the nature of the reaction which the wg list > did. Then, we should consider if this case is compatible with the > design goals. I think it is compatible. Again, something to be fixed with software. Where we should be stirring up interest is in the universities: iow, put those mythical CS/BS students to work making some applets and perl scripts. Hey, there is a fellow in the UK building a MIDWriter, so they must have time on their hands. :-) > As I recall Peter's initial dismay/confusion, it was that he would have > to make changes, not the nature of them. The design never assumed that > existing SGML applications would be XML complient, just that it would be > straight forward to make the application complient. Right. But he is a great bellweather. > Since Peter's case is not really what we were designing for, then we > should consider how XML is described and what types of support various > audiences will need. Hmm. I think he is a good exemplar. He has an application for which he used SGML and TCL/TK as I recall. In fact, his interface is very similar to the kind of editors I advocate for SGML (wysiwyg and SGML are a tough marriage). So from my perspective at least, his application is ideal. It has a narrow domain of application, a well thought out interface, a good grasp of SGML, yet isn't hard over into the "SGML Way" which IMO, is what holds us back. We spend too much time being sheepdogs nipping at the heels of the developers. For good or evil, at least Andreesen et al had the good sense to tell us to go to hell over that. > Here, Peter's case has really helped. Not only > should the nature of the transform be described, there needs to be work > with various vendors and standards bodies to address the issues with > entities. Given the nature of the group, we must rely on the market to > address these needs. I disagree just a bit. A lot of us ARE the vendors, writers, marketeers. What we should note is the bellweather. How could the FAQ and addenda be improved to help someone making the transition? What are the cases where that transition would be desirable (e.g, want to use my SGML production tools but deliver in XML)? What pieces of software make that transition more productive? What is the effect of the crabwalk on the production cycle? I know it is still early, but with a conference coming up in San Diego, it's not too early to talk strategies for XML developers. Who are they? The mythical CS grad is too nebulous a target. Who is actually out there and what do they have to work with right now? Here is one: I think we will find that in many cases, the same people who use Visual Basic IV to develop applications, then use say, Active X Web components, may be the ideal candidates for XML developers if they just had the components. I say again, that tree object in VB IV looks a lot like the TCL/TK object Peter used. So, what is the case for an XML component that interfaces to the AddItem method? (providing they fix the security hole of course). These are just suggestions. The market may provide, but we can tell them a lot about ingenious cheap ways to do that. XML must be easy and cheap. Paoli wasn't wrong. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Fri, 21 Feb 97 17:36:11 EST To: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Christopher R. Maden wrote: > Saying, "To understand this, read ISO 10744 Technical Corrigendum 1," > is a Bad Thing. I agree -- saying "To understand this, read the HyTime standard" is in all but one case an oxymoron; this sentence is the exception. XML must stand (or crawl or wriggle or fall) alone. If it is _absolutely_ necessary tomention HyTime in the spec., please make it in a non-normative part such as a note or an annotated bibliography. You don't need to read GML [sic] docs to use SGML or AAP either. Most of the people using SGML today would rather be beaten on the soles of their feet with a dead fish than read the HyTime specs; most of the people using HTML today would rather watch. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 21 Feb 1997 22:25:35 +0000 (GMT) From: Peter Flynn Subject: Re: Loss of information going from SGML to XML To: Bill Smith Cc: w3c-sgml-wg@w3.org >>We aren't down-translating SGML, we're up-translating the Web. Neat. Should I make that the subtitle of the FAQ? ///Peter -- > to discover 1000s of internal "homepages" that grew overnight > like magic mushrooms on a rich motherlode of corporate horseshit. Copyright 1996, IBM. All Rights Reserved %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 17:17:15 -0600 From: Len Bullard To: Michael Sperberg-McQueen CC: W3C SGML Working Group Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Michael Sperberg-McQueen wrote: > I think this discussion is beginning to show signs that the participants > are missing some of each other's basic assumptions, though those > assumptions seem clear enough to some of the rest of us. Glad to know some of us read minds better than others. > If I understand Len and others aright, they worry that some people would > like to conceal any relationship between XML Link and HyTime. This > would be problematic for several reasons, among them the fact that some > potential users will be worried if HyTime is *not* invoked, and (in some > ways more important) it seems more honest to acknowledge our > intellectual debts where we can. There is no worry of that. > I believe there are certainly potential users for whom the mention of > HyTime will cause fear, trembling, and a mad rush for the exit -- rightly > or wrongly, HyTime has a fierce reputation as being very hard to > understand and as making simple things so infernally complicated that > it could not possibly be worth the trouble to understand it. This is > a hard reputation to fight against (as I know to my sorrow, the TEI > having a similar reputation in some circles). So it wouldn't surprise > me if some of us did entertain the thought, from time to time, of > completing an XML Link spec that never even mentioned HyTime. Fear is still fear. It is a bad way to reason. If some are caught in that fear, it is their own problem to be considered. > It won't happen, though. If Len is not stark raving mad (I try to keep > an open mind), then noting the relation of XML Link to HyTime will help > us with some potential adopters more than it will hurt us with others. Go ahead and close it. I am not stark. However, the normative reference is more than an acknowledgement of intellectual parentage. It is the authoritative reference for the boundaries of the development of the subset being adopted by XML. If it is not, and 8879 and 10744 are not boundaries, then XML is not the basis for SGML Lite and a competitor to XML will be developed. This isn't a situation we should enable by our fears or our tastes... or our ambitions. > A document that makes *normative* references to other > documents cannot be understood without understanding those documents. Nor is it bounded. But it can be understood. > In drafting the original XML language spec, we worked very hard to > ensure that no *normative* reference to 8879 was necessary. That is a mistake. Conformance to SGML is one of the most important features of XML. If that is not understood by now, then the ERB should resign en masse and let WG8 do this. > I claim that there *is* no normative reference to 8879 > in the XML spec. The conformance of XML documents to 8879 follows as > a logical consequence of the constraints given in the spec; it does not > rely on a rule formulated as "You have to do whatever 8879 says you do." They don't. We do. Conformance with SGML, that is, that XML is a wholly comforming subset of SGML is the primary constraint. That is why a TC has been offered by WG8's chair. That is not a light matter. If such conformance is abandoned, the chair of WG8 should reconsider that offer, and WG8 should continue with a separate and competing version. It will be ISO, authoritative, and something which those whose contracting agreements span nations and considerable investment will be made aware of. It will be XML that dies; not SGML. > I believe David and some others are mostly arguing that we need to > take the same approach with XML Link. It will *not* be a good idea > to say something like > > "XML Link uses HyTime-style architectural forms as defined in > the Extended Facilities Annex. See that document for notation > and meaning of architectural forms." If they wish to understand the full and authoritative definition of AFs, that is precisely what it should say. > There are two reasons this would be a bad idea. (1) We want people to > be able to understand XML Link by reading just the XML Link spec; > any requirements, notation, and semantics we take over from HyTime > should be documented fully in the XML Link doc. You gave up your credibility there, Michael. You nor your group has the authority to take over anything. That is exactly the problem with this work. As for having to read ISO 10744 or ISO 8879, they only have to do that if the XML subset is incomplete with respect to a developer's requirements. OTW, why would they read that? > (2) HyTime AFs > have a lot of machinery XML Link will probably not use. There is no > need to refer your visitors to a map of the U.S. when all they want to > know is where the guest bedroom is. If my visitor wishes to leave a guest bedroom and go to another state, that map is of use. If all they wish to do is sleep in the bedroom, why would one offer them that? It is a facile comparison and misses the point: ISO is authoritative. XML is a set of recommendations from a consortium working group. That is it's EXACT authoritative status. Don't confuse these issues. > We know from experience that if you define a simple subset of a > complex standard by saying "Well, use this standard, but turn off the > following features," the simple subset might as well not exist. > For example: minimal SGML and basic SGML. No one can understand > either one without understanding pretty much all of 8879. That is not the case. Whatever experience you have, you have not learned the lessons it provides. If you work in the industrial side of the SGML community, you know that the authoritative references are the ones that can be quoted in contracts. That is one reason why ISO HTML is greeted with relief. > It is considerations like these, I think, that David has in mind when > he wants to avoid normative references. I agree: normative references > are for cases where you don't want to have to explain everything the > reader needs to know. That should be avoided as far as humanly possible > in all three of the XML-family specs. No: they are the authoritative chain of references which enable contractual obligations of all parties. If you and your committee members cannot live with that, resign now. Otherwise, be aware of your obligations to your community. len bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 97 17:48:26 CST From: Michael Sperberg-McQueen Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? To: W3C SGML Working Group On Fri, 21 Feb 1997 17:17:15 -0600 Len Bullard said: >Michael Sperberg-McQueen wrote: >> I think this discussion is beginning to show signs [of >> misunderstandings] ... > >Glad to know some of us read minds better than others. If the shoe fits, wear it. I was trying to help clarify vocabulary for two parties who seemed on the verge of starting a flame war by systematically misinterpreting each others' messages. I don't read minds. But I do read the postings, possibly with more understanding for where David is coming from than you've exhibited, and possibly with more understanding of where you're coming from than David may have gleaned. If you'd rather have a flame war than a useful exchange of views, suit yourself. (And hand me that torch.) >> If I understand Len and others aright, they worry that some people >> would like to conceal any relationship between XML Link and HyTime. >> This would be problematic for several reasons, among them the fact >> that some potential users will be worried if HyTime is *not* >> invoked, and (in some ways more important) it seems more honest to >> acknowledge our intellectual debts where we can. > >There is no worry of that. If what I described is not what you're worried about, then I have misunderstood your earlier postings completely, and my attempt at mediation was ill founded. Sorry to have wasted everyone's time. >> I believe there are certainly potential users for whom the mention >> of HyTime will cause fear, trembling, and a mad rush for the exit ... >Fear is still fear. It is a bad way to reason. If some are caught >in that fear, it is their own problem to be considered. If we hope to persuade an audience of something, then their fear, reasonable or not, is not their problem but our problem. >However, the normative reference is more than an acknowledgement >of intellectual parentage. It is the authoritative reference >for the boundaries of the development of the subset being >adopted by XML. If it is not, and 8879 and 10744 are >not boundaries, then XML is not the basis for SGML Lite and >a competitor to XML will be developed. Fear is a bad way to reason, Len. You told us that a moment ago; you don't need to add a demonstration of it here. It's WG8, not you, who will decide what to put into a revised 8879. I know enough of its members that I am confident that they are capable of noticing that XML guarantees the SGML conformance of valid XML documents, and of valuing the increased accessibility SGML gains by having clear documentation of a useful subset. You insult their intelligence by suggesting otherwise. >> In drafting the original XML language spec, we worked very hard to >> ensure that no *normative* reference to 8879 was necessary. > >That is a mistake. Conformance to SGML is one of the most >important features of XML. If that is not understood by now, >then the ERB should resign en masse and let WG8 do this. Conformance to SGML was *accomplished* in XML. If you have not understood that by now, who should be resigning? It was not accomplished by reference; it was accomplished by hard work. It does not need to be guaranteed by a normative reference; it is guaranteed by the restrictions explicitly made in the XML spec. >> I claim that there *is* no normative reference to 8879 >> in the XML spec. The conformance of XML documents to 8879 follows as >> a logical consequence of the constraints given in the spec; it does not >> rely on a rule formulated as "You have to do whatever 8879 says you do." > >They don't. We do. Conformance with SGML, that is, that XML is a >wholly comforming subset of SGML is the primary constraint. That >is why a TC has been offered by WG8's chair. That is not a light >matter. If such conformance is abandoned, the chair of WG8 should >reconsider that offer, and WG8 should continue with a separate >and competing version. It will be ISO, authoritative, and something >which those whose contracting agreements span nations and considerable >investment will be made aware of. It will be XML that dies; not SGML. Len, if you ever see signs of XML abandoning the principle of SGML conformance, then perhaps remarks like this paragraph will be in order. Until you do, they are wildly off the mark. The point at issue is not whether XML documents are legal SGML; the point is how that result is accomplished and documented. You seem to wish we had accomplished it by providing a document that could not be understood without reference to 8879; I think it is good that we did produce a document that is comprehensible by itself. Since there are *already* SGML subsets designed for easy implementation which take the approach you seem to prefer, I suppose we can let the market decide. So far, after three months we have two publicly available XML parsers and an indeterminate number not yet public. After eleven years, how many publicly available Minimal SGML parsers do we have? Seems to me the market has already decided. >> I believe David and some others are mostly arguing that we need to >> take the same approach with XML Link. It will *not* be a good idea >> to say something like >> >> "XML Link uses HyTime-style architectural forms as defined in >> the Extended Facilities Annex. See that document for notation >> and meaning of architectural forms." > >If they wish to understand the full and authoritative definition of >AFs, that is precisely what it should say. Yes, of course. If any reader wishes to understand the full definition of anything, going to the place where it is defined is usually a good idea. Why someone interested in the full definition of architectural forms would be looking for a treatment of them in the XML Link spec is beyond me. But let's suppose they are reading the XML Link spec in the hopes of understanding not HyTime, and not SGML, and not CALS, and not the historical development of the Sanskrit passive, but -- for some reason -- XML Link itself. Why not allow them to understand the full and definitive account of XML Link by making that account complete and self-contained? The XML Link spec needs to provide a full definition of XML links; that includes the aspects of architectural forms used by XML Link. It should *not* delegate that task to 10744. > > There are two reasons this would be a bad idea. (1) We want people >to >> be able to understand XML Link by reading just the XML Link spec; >> any requirements, notation, and semantics we take over from HyTime >> should be documented fully in the XML Link doc. > >You gave up your credibility there, Michael. You nor your group has >the authority to take over anything. That is exactly the problem >with this work. ... I don't know whom you mean by 'my group', but any group defining a formal system has, as far as I can tell, the right to adopt concepts >from other systems. That's one way intellectual endeavors make progress: adopting good ideas from predecessor systems. The W3C SGML WG and ERB, in defining XML Link, have both the authority and the responsibility to take over useful concepts from wherever we find them. I don't know why my mention of this obvious fact offends you, or why you claim we don't have authority to define XML Link in whatever way we choose, for good or ill. > As for having to read ISO 10744 or ISO 8879, they only >have to do that if the XML subset is incomplete with respect to >a developer's requirements. OTW, why would they read that? We seem to differ in opinion here. Whether it's necessary to read 8879 and 10744 seems to me *not* a question of whether the *subset* is complete or incomplete, but a question of how complete the documentation of the subset is. Normative references are, as I understand the term, a sign that the documentation before the reader is itself not complete. Informative references are an entirely different matter. >> (2) HyTime AFs >> have a lot of machinery XML Link will probably not use. There is no >> need to refer your visitors to a map of the U.S. when all they want to >> know is where the guest bedroom is. > >If my visitor wishes to leave a guest bedroom and go to another >state, that map is of use. If all they wish to do is sleep in >the bedroom, why would one offer them that? It is a facile Good question. Perhaps you will answer the corresponding question about XML Link. If all the reader wishes to do is to understand how XML Link works, why would you and others insist that instead of explaining in the spec how XML Link works, we say instead "First, you must understand ISO 10744; then come back and you'll be able to understand the rest of this spec." >comparison and misses the point: ISO is authoritative. XML >is a set of recommendations from a consortium working group. >That is it's EXACT authoritative status. Don't confuse these issues. I don't believe I have confused them; I don't believe I've tried to discuss them at all. I don't believe they are relevant to this discussion, which centers on the question of whether XML documentation should itself contain full descriptions of salient constructs or should rely for those descriptions on other documentation such as ISO 10744 or ISO 8879. The specification for XML itself does not rely on 8879 in the way you now seem to require; why did you not mention this requirement when we were discussing that draft? >> We know from experience that if you define a simple subset of a >> complex standard by saying "Well, use this standard, but turn off the >> following features," the simple subset might as well not exist. >> For example: minimal SGML and basic SGML. No one can understand >> either one without understanding pretty much all of 8879. > >That is not the case. Can you name anyone who has understood 8879's definition of Basic or Minimal SGML without understanding the rest of 8879 first? I have been told the point of Basic and Minimal SGML was to simplify the task of creating low-end SGML systems. OK, where are those systems? > Whatever experience you have, you have >not learned the lessons it provides. If you work in the >industrial side of the SGML community, you know that the >authoritative references are the ones that can be quoted >in contracts. That is one reason why ISO HTML is greeted >with relief. It's always interesting to read about strange and unfamiliar customs and beliefs. Thank you. I feel like I'm reading an ethnological report. By the way, though, if industrial concerns are unable to do things without authoritative references to ISO standards, why are so many industrial concerns (a) on the Web, using HTML, and (b) using the internet at all, given that the TCP/IP family of protocols is so hopelessly incompatible with the relevant ISO standards? Since valid XML documents are by definition valid SGML documents, however, there is nothing to prevent the inclusion of references to ISO 8879 in a contract for an XML system. Why would there be? >> ... normative >> references are for cases where you don't want to have to explain >> everything the reader needs to know. That should be avoided as far >> as humanly possible in all three of the XML-family specs. > >No: they are the authoritative chain of references which enable >contractual obligations of all parties. If you and your committee >members cannot live with that, resign now. Otherwise, be aware >of your obligations to your community. If you mean we have an obligation to our community to make the XML spec incomprehensible and impenetrable, I respectfully and forcefully demur. -C. M. Sperberg-McQueen University of Illinois at Chicago %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 23:12:30 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: Loss of information going from SGML to XML Lines: 66 In message <199702212234.AA127644488@hpsgml.fc.hp.com> Dave Hollander writes: > > Len, > > That Peter MR is an early indicator of how XML will be received by the > SGML audience, is a point well taken. Perhaps we should consider a "Guide to > Moving from SGML to XML" to help prevent surprise and confusion. I think this is an excellent idea. (I'm not volunteering, because I don't know enough about the practice of SGML.) It's not as bad as perhaps came over. I can hack my own stuff easily enough. As is clear I represent the untested market which is (obviously) less well understood. That has to involve "Moving from HTML to XML", and I have started to try to address that. > > Befor we consider changing the design based on one person's reaction we > should first understand the nature of the reaction which the wg list > did. Then, we should consider if this case is compatible with the > design goals. > > As I recall Peter's initial dismay/confusion, it was that he would have > to make changes, not the nature of them. The design never assumed that > existing SGML applications would be XML complient, just that it would be > straight forward to make the application complient. If it helps, the problem was not that I had to make changes to my own material - I'd expected that. (I had a little whinge about having to change all the PUBLIC ENTITYs since that was an issue at the time and it seemed (and still does) unnecessary to remove them.) The problem was that it suddenly dawned that the whole of the standard existing SGML components were incompatible, and I got the impression (wrongly) that this had not been thought about. > Since Peter's case is not really what we were designing for, then we > should consider how XML is described and what types of support various > audiences will need. Here, Peter's case has really helped. Not only > should the nature of the transform be described, there needs to be work > with various vendors and standards bodies to address the issues with This is the key point. It's perfectly possible for Jane and Joe Doe to hack ISO12083 or 12200 or whatever and use it in privacy. It's a different matter when someone uses components which belong to someone else and which cannot interoperate however had you try and code round. For example, my DTDs include HTML2.0, and I asked Dan Connolly's permission (as author) to distribute it, and it was (of course) willingly given. However Dan wasn't at that stage clear what the precise copyright position was on HTML2.0. I cannot imagine getting a speedy response back from any standards body to the question "please can I make some (apparently minor) adjustments to your DTD". I work with (chemical) standards bodies and I would not contemplate editing any DTD and redistributing it. So the suggestion was mainly to get round the legal position by using the standard components. [I would also suggest that thought be given as to how an XML file identifies itself. If you have (say) two HTML2.0 DTDs (one 'SGML' and the other 'XML'), how do you know which is which? (apart from grepping for asterisks). Are they going to have a PI something like just to alert any software? And do they share the same FPI?] P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 18:30:48 -0800 (PST) From: Bill Smith Subject: Re: SERIOUS concerns about implementation To: w3c-sgml-wg@w3.org Len Bullard wrote: > I think it necessary to say, "we are not fixing SGML; we are > subsetting it to make it easier to apply for those cases > where the full requirements of SGML are too burdensome, but > otherwise, this is still SGML. What we are doing with the > linking is a different matter. Here we have a subset and/or > application of HyTime that is easier to understand and develop and > will provide a much more powerful linking capability than is > currently in use on the Internet." Why doesn't the same apply to XML itself: "Here we have a subset of SGML that is easier to understand and develop and provides more powerful markup than is currently in use on the Internet." This is a positive statement about both XML *and* SGML and is an accurate statement of what has been accomplished. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sat, 22 Feb 97 00:01:51 EST To: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Michael, a well-written (as always) response. I wish to add one small comment to sonething Len wrote: > It will be ISO, authoritative ISO has no authority on the Internet. Actually, people generally conform to ISO standards because they choose to, not because they are forced to -- that is, people who make decisions about whether to conform. The IETF has authority over networking protocols used on the Internet. It's a different world... SGML and ISO are tolerated where they are useful and not overly intrusive, not obeyed. Frankly, after X.400 and OSI networking, few network programmers can have much respect (if any) for any "authority" of ISO. It will take a long time to regain confidence. It will be necessary to show that the ISO standards are well and clearly written, that they have been well tested before being approved, and that they really work in practice, before that confidence can be regained. The current HyTime standard meets none of those requirements (if it did, perhaps the TC wouldn't be so badly needed). Neither does the SGML standard (sorry). I think that DSSSL comes close, and if it lacks anything it is in the area of testing; ISO doesn't have the IETF's concept of a trial implementation period. I wouldn't really have a problem with referring to DSSSL, even if it is (to me) a little overly legalistic. But I see no point in referring to HyTime, with or without TC. If by some happy coincidence it turns out that XML is expressible HyTime -- and Eliot assures us that any scheme whatsoever is so expresible if a grove plan be constructible -- then a separate document can explain that. An RFC for hyperlinking will carry immeasurably more weight in IETF and World Wide Web circles than any number of ISO standards. As I understand it, W3C recommendations become RFCs, so we have a route there. ISO standards may now (as of 1994) reference IETF standards track RFCs in their normative text, and vice versa. Sorry for a long reply. I am not trying (although it may seem like it) to put down ISO, which does a useful job; rather, I am trying to point out and expand a little upon a cultural difference. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sat, 22 Feb 97 00:16:05 EST To: tbray@textuality.com, w3c-sgml-wg@w3.org Subject: Re: 3.3 XML Analogue of HTML " 3.3.a Should we have a type of link that tries to be a nice clean superset of > HTML's Anchor? Not particularly. RFC1866 (and HTML 3.2) define a lot of things for HTML anchors. Including transclusion and pop-up footnotes, by the way (via REL and REV). We should allow a URL in an attribute to do something similar to HTML' A and IMG elements. > 3.3.b If so, what should we call it? n/a > 3.3.d Should we regard such an "A" link as involving one or two resources? That depends. involves one resource (the containing document) So does: which searches for a CDATA attribute NAME with value "boy". you shouldn't see this might implement transclusion... > 3.3.e If it involves two resources, is it a problem that there is no obvious > place to put locator metadata for the "implied" resource? Back to Liam's Taxonomy of Links again.... the is participating; if you need to identify the implicit link end document, you could have a BASE URL (which we will need anyway if we are going to rely on CATALOG) and/oror a base PUBLIC ID, if the meaning of a PUBLIC ID is pinned down appropriately. > 3.3.f SHould we provide a content model for "A" links? No. It's up to the DTD concerned. > 3.3.g Should we allow "A" links to contain anything other than PCDATA? Yes. You can put an H1 in an anchor in HTML today if you like (although not all HTML DTDs allow this), and you can certainly include images, emphasis etc. It wouldn't be a superset if you made this restriction. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sat, 22 Feb 97 00:18:23 EST To: w3c-sgml-wg@w3.org Subject: Re: 3.2 c-d Content of linking elements? > 3.2.c Should we provide a content model for general links, and if locators > live in subelements, for them? No. How can you possibly give content models for DTDs you don't have??? > 3.2.d Should we allow these links to contain anything other than the PCDATA > and, perhaps locator subelements? Yes. Why can't I link a whole table to a spreadsheet? I want to be able to include emphasised words, Greek phrases and pictures of my socks inside links. I can do all that in HTML today. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sat, 22 Feb 97 00:24:46 EST To: w3c-sgml-wg@w3.org Subject: Re: 3.2.a Name for generalized multilink > 3.2.a What should the generalized multiway link be called? Multilink, > General Link, Independent link, anything else? Multiway Link. It isn't independent -- it depends on the XML spec. :-) Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 21:58: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: New list: XML-DEV I am very pleased to announce the availability of a new mailing list devoted to issues of special interest to XML software developers. To subscribe to the new list, called XML-DEV, send a message to majordomo@ic.ac.uk with the line subscribe xml-dev name@address (where name@address is your actual email address) in the body of the message. To unsubscribe, send to majordomo@ic.ac.uk the message unsubscribe xml-dev To see other facilities available from the mail server, send a message containing just the word help An initial message to the list and an "info" blurb for the list appear below. On behalf of the XML community, I would like to thank Peter Murray-Rust of the Virtual School of Molecular Sciences (peter@ursus.demon.co.uk) for organizing the list and Henry Rzepa of the Department of Chemistry, Imperial College, London (rzepa@ic.ac.uk) for agreeing to serve as the list coordinator. The XML-DEV list is certain to become a major resource as XML moves toward realization. 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: Fri, 21 Feb 1997 17:07:26 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: xml-dev@ic.ac.uk Subject: Welcome and Thanks This is a test message to XML-DEV. I am very grateful to Henry Rzepa for setting this up at my request. Henry is the one who has to field the problems of bouncing addresses and so on. Henry has been extremely supportive of the development of CML and of SGML-based publishing in chemistry, but please route any SGML/XML queries to me rather than him. This list is hypermailed which means that every posting is available on the WWW. The great advantage is that it's possible to revisit the pages for factual information. Please choose your threads and subjects carefully. Note, of course, that all postings are public and that you should not post anything that you would prefer only a small group to know (e.g. the location of pre-alpha code). I have written an 'info' which should appear shortly - there is no detailed agenda, but a general belief that if we take a collaborative approach to developing components (of whatever sort) we can get prototypes and demonstrators working very soon. We benefit from knowing that we are all working from the same draft, with the same beta-release, or whatever. Topics should always relate to XML in some form, although they may spring from existing SGML applications and installations. It is probably not appropriate to post large chunks of material (code, document instances, etc.) to this list, but to post URLs instead. It may be useful to evolve a page where these are listed, but I'm not offering this on day 1 (volunteers?). The development of XML is very rapid and it is always helpful if resources can be uniquely identified (i.e. have IDs, date stamps, or different URLs). I am probably as guilty as anyone in this matter :-). Peter -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ INFO: XML-DEV is an informal unmoderated list to support those who are interested in the implementation and development of XML. XML is being developed as 'an extremely simple dialect' of SGML to 'enable generic SGML to be served, received, and processed on the Web in a way that is now possible with HTML'. Further information about XML or pointers to it can be found at: http://www.ucc.ie/xml/ (Peter Flynn's FAQ site) http://www.sil.org/sgml/ (Robin Cover's SGML page) The XML spec is still being actively developed. The latest draft is at http://www.textuality.com/sgml-erb/WD-xml.html This list is for those people actively involved in developing resources for XML. It is not restricted to members of the working group (WG), but many subscribers to XML-DEV will be actively working on implementing some part of the spec. Examples of what might be discussed: - the detailed implementation of the spec - resources such as documentation, test data, test results. - XMLification of components (DTDS, entity sets, catalogs, etc.) - APIs for software developers. - problems in implementation, and queries for XML-related resources - the use of existing SGML tools in creating XML resources. It is NOT appropriate to: - request general information on XML (use the FAQ) - discuss non-XML topics in SGML (use comp.text.sgml) - discuss revision of the spec (use the WG) The mail on this list is publicly hypermailed and all postings should be made with this in mind. The hypermail is seen as a useful resource for locating information, and for current awareness as to who is doing what. If there is sufficient volume, it may become valuable to abstract these pages from time to time. Peter Murray-Rust, Feb 21 1997 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Fri, 21 Feb 1997 22:47:14 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: WWW6 structured doc demo One of the reasons that I'm so happy Peter Murray-Rust started the new xml-dev list is because it gives me a way to coordinate the structured doc demo session at the World Wide Web conference in April. The demo will take place Thursday evening, April 10, just before Developer's Day at the conference. I'm inviting anyone who has running code that shows technology for structured document delivery to come give a brief demonstration. This includes everything from XML editors to fullblown XML+DSSSL Web browsers (there will be at least one of those at the demonstration). If you think that you will be able to demonstrate XML technology by April 10 or want to set me up to show it for you, please subscribe immediately to the xml-dev list so that you can be included in the discussion. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 22 Feb 1997 11:32:46 +0000 To: w3c-sgml-wg@w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Re: SERIOUS concerns about implementation > >>> I aggree. But I *do* wish we could stop referring to SGML files as "legacy". >>> Surely SGML->XML is a "down-translation" not an "up-translation". > >I don't think vertical terms are applicable. Since the element structures of >both forms are the same, I don't think there's vertical motion involved at all. Whatever the direction, I do not think the use of the word "legacy" for SGML will help our cause at all and I think we should stop using it. . It does not accurately portray the SGML/XML relationship . To SGML people, "legacy" is a state your data leaves when you place it in SGML. If having got it there is it now "legacy" with respect to XML what happens to all that open systems, future proofing, spiel I swallowed from the salesman? I'll buy into "foo"-translation where "foo" is anything other than "up" for describing SGML->XML. Sean %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 22 Feb 1997 12:02:49 +0000 (GMT) From: Peter Flynn Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? To: w3c-sgml-wg@w3.org Christopher Maden wrote: >The proverbial CS bachelor's degree holder should be able to take the >XML spec(s) and implement. They should not need to write checks to >the ISO. If you want to write programs for a specific environment, you have to get the docs and read them. If some of those docs come from a commercial organization, be it Microsoft or Apple or ISO, you have to ante up. The question of whether or not ISO should be charging for standards is a separate issue (I happen to agree with you that they should not, but we can't change this). >Bibliographic references are certainly appropriate, as are "BTW, this >is what HyTime calls ..." or "For SGML geeks, the differences are...". >Saying, "To understand this, read ISO 10744 Technical Corrigendum 1," >is a Bad Thing. Yes, but what we should be referring people to is not just the offical reference for standard X, but also to online document Y which is a pragmatic summary of the relevant bits (eg for implementors). It may be annoying to have to do this because ISO docs are so inaccessible to the average CS grad, but I think we just have to face it. What we must avoid at all costs is incorporating lengthy chunks of explanatory material of this nature inline in the XML Spec. Short bits, fine, otherwise link 'em. IMHO/YMMV. ///Peter -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 22 Feb 1997 12:02:57 +0000 (GMT) From: Peter Flynn Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? To: w3c-sgml-wg@w3.org At 17:36 21/02/97 -0500, Liam Quin wrote: >Most of the people using SGML today would rather be beaten on the >soles of their feet with a dead fish than read the HyTime specs; >most of the people using HTML today would rather watch^H^H^H^H^H be doing the beating :-) ///Peter -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 22 Feb 1997 08:50:37 -0600 From: len bullard To: Bill Smith CC: w3c-sgml-wg@w3.org Subject: Re: SERIOUS concerns about implementation Bill Smith wrote: > > Len Bullard wrote: > > > I think it necessary to say, "we are not fixing SGML; we are > > subsetting it to make it easier to apply for those cases > > where the full requirements of SGML are too burdensome, but > > otherwise, this is still SGML. What we are doing with the > > linking is a different matter. Here we have a subset and/or > > application of HyTime that is easier to understand and develop and > > will provide a much more powerful linking capability than is > > currently in use on the Internet." > > Why doesn't the same apply to XML itself: > > "Here we have a subset of SGML that is easier to understand and develop and provides more powerful markup than is currently in use on the Internet." > > This is a positive statement about both XML *and* SGML and is an accurate statement of what has been accomplished. I agree with that. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 22 Feb 1997 09:02:53 -0600 From: len bullard To: lee@sq.com CC: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? lee@sq.com wrote: > > ISO has no authority on the Internet. Actually, people generally conform > to ISO standards because they choose to, not because they are forced to -- > that is, people who make decisions about whether to conform. > > The IETF has authority over networking protocols used on the Internet. The IETF can suggest anything it wishes as can any private organization. Those who wish to agree and cooperate can, as with any standards body. > It's a different world... SGML and ISO are tolerated where they > are useful and not overly intrusive, not obeyed. No one has authority over the Internet since DoD ditched it. The fact is, all of these things are "only agreements" and are obeyed insofar are they are convenient. The IETF standards are full of conflicts. But what we are talking about is XML subsetting an ISO Standard, not putting YetAnotherRFC on the street. There is no they: we are they. Before we put into motion a work that can splinter the good work of SGML, consider putting some boundaries around that. Normative references do that. Tolerance is not at issue. Obedience is not at issue. Stable and cooperative development are. Normative references have a use in that they set the proper and useful boundaries and establish precedents for future good relationships. len bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 22 Feb 1997 09:23:06 -0600 From: len bullard To: Peter Flynn CC: w3c-sgml-wg@w3.org Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Peter Flynn wrote: > > At 17:36 21/02/97 -0500, Liam Quin wrote: > > >Most of the people using SGML today would rather be beaten on the > >soles of their feet with a dead fish than read the HyTime specs; > >most of the people using HTML today would rather watch^H^H^H^H^H > be doing the beating :-) and would bring that same lack of maturity and responsibility to any task they undertook, so, it's probably the fish that would suffer. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 22 Feb 1997 09:44:09 -0600 From: len bullard To: Michael Sperberg-McQueen CC: W3C SGML Working Group Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Michael Sperberg-McQueen wrote: > > If you mean we have an obligation to our community to make the XML spec > incomprehensible and impenetrable, I respectfully and forcefully demur. Turning down the torch.... The issue is normative and informative references. What I am asking for is normative reference where material is "taken over" from authoritative sources. Not intellectual borrowing, but real relationships are needed. Let's not debate the authority of IETF vs ISO: both have communities of interest and authoritative status. IETF has a more limited scope than ISO. ISO has a larger scope, but a diminished focus. But what we are doing here is not YetAnotherRFC. We are: 1. subsetting an decade old international standard 2. getting the benefits of the work that went into that standard 3. establishing precedent for work among the different and separately legitimized groups of individuals who make up the working groups of these organizations. The first issue has been considered. XML is a proper subset of SGML. Further, if the WG8 TC occurs, both XML and SGML and their substantially overlapping if not identical communities of users will benefit. The second issue is trickier. The problem of XML development as a separate language is the danger that incompatibilities will be introduced. The W3C has had little success controlling the actions of its members with regards to using W3C standards in this way. The XML editors and the working group have an obligation to protect ISO 8879 and any other standard which they "borrow from" or "take over". Normative references can do much to stop a corroding of both works later in their development by ensuring that the authoritative reference is given proper attribution. IOW, they might still screw with XML, but if they do, SGML testing is available to determine that. If one has to READ ISO 8879 or ISO 10744 to implement XML, then you are right, the spec needs clarification. But I have full confidence in the editors of XML that this situation will not occur. As for issue three, if this effort fails to respect all contributing parties, then it will do more to tear down any chance for such cooperation in the future. I may be mad (keep an open mind..), but I still understand that where I borrow, I have the responsibility to protect and return unharmed. XML may succeed, but it can also do, or be used to do, tremendous damage to a decade of work, the community that did the work, and one of the most successful standards in the world. The last I say with confidence because that is what all of us here have in common. len bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 22 Feb 1997 16:02:26 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: 3.1.a All linkage info in markup not data? Lines: 51 In message <3.0.32.19970220173725.00ac3a30@pop.intergate.bc.ca> Tim Bray writes: > The ERB schedule calls for voting on Feb. 26 on these items. > > 3.1.a Should we have a principle that all linkage information is encoded in > GIs and/or attribute values, never in character data? > As someone not familiar with the current representation of links (other than HTML) but who is almost certainly going to have to think about implementing the decisions :-) I'd like to make some general points which I hope the ERB will know what to do with. I hope very much that whatever comes out of Phase II will not limit the expressibility of the language (i.e. that we are not deliberately constraining authors from doing desirable things - sorry that's so woolly). As I have developed my DTDs I have kept finding the need to add more attributes for expressivity and I think that in novel applications of XML that will certainly be the case. Diversity of expression is a valuable creative outlet. On the other hand, everything in this spec has to be implemented, and fast. One possible choice is between: (1) and (2) In the first case we could create a class XMLLINK.java whilst in the second we would inherit LINKability: public class FOO implements XMLLINK {...} There would be a significant, but manageable coding overhead (I think) if both were allowed. (In systems with multiple inheritance, like C++, it might be possible to do it with less effort, but MI has its own problems). The overhead would (I think) be small compared with the implementation of XMLLINK itself, but in (2) there could be a greater burden on the programmer who will have to implement XMLLINK (though they can borrow code). It is easiest if *all* GIs may have XML-LINK attributes because then they can all be subclassed from XMLLINK.java. So my gut feeling to all these questions is that a general flexible solution is desirable and manageable, but that it's important to remember implementation whilst making these decisions. HTH P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 22 Feb 1997 14:02:09 -0500 To: Sam Hunting , w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David Durand) Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? At 4:45 PM -0500 2/21/97, Sam Hunting wrote: > >I do want to make XML, and XML linking stand on >their own, without normative references to ISO standards. > > > >I'm not sure if that goal has any utility. Whereas, >gratuitous references are not useful, normative references >establish a chain of authoritative information. That >does have utility. > On the internet, people scoff at the very thoguht of ISO standards because they are not willing to pay to read them. If we want XML to be accepted we must make the documents authoritative and self-standing. It is our job to make XML SGML conforming (or not). It is an implementor's job to follow what _We_ specify. We will not ease their task by making them read the ISO documents. That's the difference between an informative, and a normative citation. If it is normative, we require thaqt they read both. I think that this is socially, and politially unacceptable, and technically unnecessary. It is also implied by the goal of a 20page definition. If the definition is 20 pages, and makes nromative reference to 8879, we have made things _more complicated_ not _less complicated_. If we add the HyTime standard, we have compounded this problem by at least a factor of 2-3. > >David: If that is your goal, then what am I to make of Design Goal (3) >"XML shall be compatibble with SGML"? What's more normative than "shall"? >More ISO than SGML? Compatible means compatible. I can define language A as a subset of language B without making explicit reference to language B or its definition documents, so long as the definitions themselves meet the criterion. Clear enough now? -- David I agree that we should cite all relevant ISO documents for those interested in further background, or in need of features we are not providing that those standards do provide. Endorsement by the ISO is a feature that is variably rated by our target users. _________________________________________ 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 \__________________________ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 23 Feb 1997 01:21:00 +0000 (GMT) From: Peter Flynn Subject: XML FAQ v0.4 To: w3c-sgml-wg@w3.org I have applied all the corrections sent to me to date and put up v.0.4 of the FAQ. This seems stable enough to go public with now, although I still have it labeled "Draft", but I am also announcing it in comp.text.sgml, comp.infosystems.www.authoring.html, and comp.infosystems.www.browsers.misc (more suggestions welcome). ///Peter -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg From: lee@sq.com Date: Sat, 22 Feb 97 21:36:36 EST To: pflynn@curia.ucc.ie, w3c-sgml-wg@w3.org Subject: Re: XML FAQ v0.4 > I still have it labeled "Draft", but I am also announcing it in > comp.text.sgml, comp.infosystems.www.authoring.html, and > comp.infosystems.www.browsers.misc (more suggestions welcome). Announce it in the Heavens! I suggest at least comp.text and comp.databases; possibly also sci.lang and TEI-L. I'm not sure whether the databases crowd will see the connection, although I find it stunningly obvious. For that matter, the compiler theory group ought to be another one, but Ican't remember what it's called. Lee %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 23 Feb 1997 16:59:09 -0500 To: w3c-sgml-wg@w3.org From: davep@acm.org (Dave Peterson) Subject: Re: SERIOUS concerns about implementation At 12:51 PM 2/20/97, lee@sq.com wrote: * * * * * >No-one has ever said that existing legacy SGML (or HTML) files will be >valid XML files. They won't. * * * * * >No, none of these files will break. They are all SGML files, and >are not for use with XML. I expect that a future Panorama may well >handle both XML and SGML... * * * * * >I agree. All the changes were made for good reason. >XML is a subset of SGML, but that doesn't mean that a subset of existing >SGML files are XML files. There probably are existing SGML files that are XML files. Any XML file that includes its DOCTYPE declaration is both. At 2:38 PM 2/21/97, Len Bullard wrote: * * * * * >Just quickly glancing, XML isn't an "application of SGML". >I think it is a proper subset. HTML is an application of >SGML, and could be an application of XML. That is, perhaps, >one way to get the point across. We're losing sight of the subset/application spectrum. HTML (at least at any point in time) is intended to be a single, nonextendable markup language. Nonextendable in the sense that making any additions forms a new markup language, which is only (hopefully closely) related to the old. SGML at any point in time is intended to be extensible in certain ways. There are specific areas where choices may or must be made. These choices partition naturally into three groups: "Semantic" choices, which are generally of interest only to application designers and users; "structure" choices that are specified via a document type declaration, and "lexical" choices that are specified via an SGML declaration. At least by tradition you must make the lexical choices before you make the structure choices and semantic choices. Making all three is in SGML terms "defining an application". Additional restrictions that cannot be specified via the document type declaration or the SGML declaration are "application conventions". HTML (at least in some incarnations) is an application of SGML by this definition. XML is in the in-between grey area. We plan to lock in the SGML declaration; we plan to lock in some semantic roles (e.g., for linking); we plan to add additional restrictions that cannot be specified via the document type declaration or the SGML declaration. But we allow users to complete the process of making an SGML application. It seems to me that "subset" is an appropriate term for such a set of some-but-not-all of the decisions necessary to define an "application". According to this definition of "subset", an application is a subset in which all of the available decisions have been made. (Or almost all--one could presumably still add more more-restrictive "application conventions".) I pose three questions: Is this "subset" a useful concept? Is "subset" the right term? And is this what you all have meant by "subset" when you've used the term? Dave Peterson SGMLWorks! davep@acm.org %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 23 Feb 1997 15:08:23 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Normative refs to 8879/10744? At the moment, the first sentence of the abstract of the XML spec reads: Extensible Markup Language (XML) is an extremely simple dialect of SGML which is completely described in this document. The first paragraph of the section 1.0, Introduction, reads: 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. XML is an application profile or restricted form of SGML, the Standard Generalized Markup Language [ISO 8879]. It seems that we mostly agree that the the rest of the spec succeeds pretty well in making these sentences true. However, it is important (at least to me) that we avoid any perception (however idiotic) that we are working against SGML, and I at least become deeply irritated when I read demands for our resignation based on such imputations. Len, could you suggest a redraft of the two sentences above, or another set of modifications of the text of the spec, that would meet your goal of making the 8879 reference normative? Speaking only for myself, it seems that making the reference more normative would be uncontroversially good, if this could be done without giving the impression that anyone actually has to *read* 8879 or 10744 to do XML safely, correctly, and legally. -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 23 Feb 1997 19:22:58 -0600 From: len bullard To: Dave Peterson CC: w3c-sgml-wg@w3.org Subject: Re: SERIOUS concerns about implementation Dave Peterson wrote: > At 2:38 PM 2/21/97, Len Bullard wrote: > * * * * * > >Just quickly glancing, XML isn't an "application of SGML". > >I think it is a proper subset. HTML is an application of > >SGML, and could be an application of XML. That is, perhaps, > >one way to get the point across. > > We're losing sight of the subset/application spectrum. Could be. To me the boundary is the software that implements it. That is where an SGML design becomes a proper application in my book. XML retains SGML's meta-language aspects. We also design for the software/application boundary the commons data types that make interoperability easy. This is done within existing HTTP/URL semantics (sorry loose). What HTML demonstrates dramatically is how WELL this idea works when the element types are common. Extensions are the province of the DTD writer for their DTDs. XML lets them do that so they can use markup as requireed, but it recognizes that where XML must work in application software, the declaration of common data structures makes the software work. > It seems to me that "subset" is > an appropriate term for such a set of some-but-not-all of the decisions > necessary to define an "application". Not the one's that declare interoperable semantics. Those have to be shared. But that has always been the case with markup. Look at the CALS Table, HTML, etc. Unless XML systems share the application level as well as the subset level, they don't work. I see your point. > According to this definition of "subset", an application is a subset in > which all of the available decisions have been made. (Or almost all--one > could presumably still add more more-restrictive "application conventions".) > > I pose three questions: Is this "subset" a useful concept? Is "subset" > the right term? And is this what you all have meant by "subset" when > you've used the term? The subset is the syntax and feature restrictions. Application conventions are the special structures declared to enable interoperable software, eg, linking. That leaves the processing specs. Same deal: libraries. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 23 Feb 1997 19:35:58 -0600 From: len bullard To: Tim Bray CC: w3c-sgml-wg@w3.org Subject: Re: Normative refs to 8879/10744? Tim Bray wrote: > > At the moment, the first sentence of the abstract of the XML spec reads: > > Extensible Markup Language (XML) is an extremely simple dialect of SGML > which is completely described in this document. > > The first paragraph of the section 1.0, Introduction, reads: > > 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. XML is an > application profile or restricted form of SGML, the Standard Generalized > Markup Language [ISO 8879]. Good. What of ISO 10744? If architectural forms are used, what is the relationship? On HTML, Dan Connoly has made sure that HTML to that degree designers thought prudent, is an application of SGML. Will XML Links remain legal HyTime? I know some don't care about that. I do. > It seems that we mostly agree that the the rest of the spec succeeds > pretty well in making these sentences true. However, it is important > (at least to me) that we avoid any perception (however idiotic) that > we are working against SGML, and I at least become deeply irritated > when I read demands for our resignation based on such imputations. Yes. That was a stupid remark on my part. I apologize. The problem is drift. Does XML remain a subset in the sense the Dave suggests? How is that maintained? > Len, could you suggest a redraft of the two sentences above, or > another set of modifications of the text of the spec, that would meet > your goal of making the 8879 reference normative? No. I do have a question. What is the dynamic relationship? Does XML go on being a consortium specification for an application profile of an ISO specification? > Speaking only for myself, it seems that making the reference more > normative would be uncontroversially good, if this could be done without > giving the impression that anyone actually has to *read* 8879 or 10744 > to do XML safely, correctly, and legally. -T. That is exactly right. I suggest if you need the opinion that matters, ask Charles. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: 24 Feb 1997 02:38:50 +0000 (GMT) From: Peter Flynn Subject: Re: SERIOUS concerns about implementation To: w3c-sgml-wg@w3.org At 16:59 23/02/97 -0500, Dave Peterson wrote: [...] >I pose three questions: Is this "subset" a useful concept? Is "subset" >the right term? And is this what you all have meant by "subset" when >you've used the term? I've used "subset" in the FAQ where I think the word conveys sufficient of what you describe for it to make sense to the reader. I also use the phrase "application profile" once where it describes better the "gray area" you mention of XML being neither flesh nor fowl. How we describe it here and how we describe it to the world outside may be of importance to the acceptance of XML, so I'd appreciate it if anyone has better phraseology than I have used in the FAQ so far. XML's role as "SGML Lite" is currently easiest conveyed by the concept of "subset", I think, but if we can find a less loaded term it might be useful. ///Peter %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 23 Feb 1997 21:59:17 -0500 (EST) From: Sam Hunting To: "Henry S. Thompson" cc: w3c-sgml-wg@w3.org Subject: xlink, not multilink or xml-link On Fri, 21 Feb 1997, Henry S. Thompson wrote: > > 3.2.a What should the generalized multiway link be called? Multilink, > > General Link, Independent link, anything else? > > Multilink will do, xml-mlink for short. Why not just "xlink"? The initial "x" suggests: * graphically the multiway connections of the link * "X"ML * its (potential) "x"ternal nature %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 23 Feb 1997 20:07:33 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? [Various arguments regarding normative references, subsets, &c. deleted] This thread has become tedious and unproductive. One or the other is OK, but not both. Please take it offline. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 23 Feb 1997 20:16: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: Re: SERIOUS concerns about implementation We don't need any more on this subject. There are several key questions relating to linking in front of you. Given that the ERB will be deciding these questions Wednesday morning and that they probably won't be considering comments made after Tuesday afternoon, you have less than 48 hours to put on record whatever you have to say regarding the matters at hand. If you have time to post something to this list, it would be better spent addressing the questions before you than revisiting decisions already made. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 23 Feb 1997 20:19:03 -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: xlink, not multilink or xml-link [Sam Hunting:] | Why not just "xlink"? Because all reserved XML names start with "XML-". Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 23 Feb 1997 20:40:24 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: xlink, not multilink or xml-link At 09:59 PM 2/23/97 -0500, Sam Hunting wrote: >Why not just "xlink"? The initial "x" suggests: ... not to mention "Extensible". Yes! The collective thought process gives birth to another winner. Sign me up for xlink. -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sun, 23 Feb 1997 20:42:50 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Suggested new XML slogan "Live fast, die young, leave a good-looking standard." %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 13:27:54 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 3.2.b Locators in attributes or elements? At 23:54 20/2/97 -0800, Tim Bray wrote: >The ERB schedule calls for voting on Feb. 26 on these items. > >3.2.b Should the locators of a general link be packaged in attributes >as in HyTime, or as child elements as in the initial draft? > For in-line links they should be attributes, but for external links we should allow users to associate child elements with a default set of attribute values, e.g. Milton, J: Paradise Lost Martin's thoughts ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 13:27:56 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 3.3 XML Analogue of HTML "The ERB schedule calls for voting on Feb. 26 on these items. > >3.3.a Should we have a type of link that tries to be a nice clean superset of >HTML's Anchor? Yes >3.3.b If so, what should we call it? A - otherwise it (the element that is) is not a superset! >3.3.c If 3.2.b goes the way of child elements for locators, should the "A" >link have a single child element for consistency with that, or no such >element for consistency with HTML? It must allow any element that is embeddable within an HTML anchor. >3.3.d Should we regard such an "A" link as involving one or two resources? It is an in-line link. If it points to an internally named fragment identifier it refers to a single resource. If it contains a URL prefix for its fragment identifier, or consists of just the URL, there are two resources, that doing the pointing and the pointed to. >3.3.e If it involves two resources, is it a problem that there is no obvious >place to put locator metadata for the "implied" resource? Surely in-line links imply the contents of the link element as a resource. > >3.3.f SHould we provide a content model for "A" links? No - this has to be application specific >3.3.g Should we allow "A" links to contain anything other than PCDATA? They must be able to contain any element the application wants. There is one thing that seems to have been forgotten in the spec so far, which is vital if we are to provide a superset of the HTML Anchor element. That is the ability to map existing attribute names to XML ones. For example you must be able to state that the XML locator attribute value is to be taken from the href attribute (and perhaps that the name attribute is to be mapped to an ID attribute) For example, you need to have something like: so that the system knows that it should take the value of its XML locator element from the contents of the href attribute, the contents of its unique identifier from the name attribute (if it is present) and the content of its caption attribute from the contents of the element). ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 13:27:49 +0000 To: Steve Pepper , w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: In lieu of multiple attlists: LINK? At 12:43 21/2/97 +0100, Steve Pepper wrote: >It seems to me that this is PRECISELY the kind of use for which LINK was >originally intended: the association of processing with structure in a >modular and eXtensible way. It provides the perfect, SGML-compliant way >of making existing documents XML-processable without having to modify >the DTD or document, and without having to invent new syntax. Thats exactly why its there, and why for years people have been using it to allow fixed processing control attributes to be associated with elements. The question is, which of the XML link attributes are fixed and which of them must be user variable. So far all the examples have only shown the one fixable attribute, that showing the XML link type. But does this work with variable ones, such as locator and caption? Unfortunately I don't see how a strictly SGML-confornant link-based solution can deal with these. Therefore we are back at the concept of using PIs as a temporary fix untill multiple attlists are allowed. Here I have another problem. Whilst looks nice, aren't we supposed to be using and then repace the by >. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 13:27:43 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 1.5: Discuss link characteristics? Cc: bosak@atlantic-83.eng.sun.com At 20:10 15/2/97 -0800, Jon Bosak wrote: >[Martin Bryan:] > >| The most important thing about CSS is the C (the SS is a pain!). We >| need something like C-DSSSL-O and an equivalent C-Interact. For the >| latter we need a way for servers to send down a pointer to a default >| behaviour and have users say "replace the default behaviour with this >| behaviour" (a catalog for Java applets?). >>But when I pick up an issue of Wired magazine, for example, I don't >say to myself, "Gee, I wish I could change this typeface to Garamond >and adjust this gradient fill over here." No, I say, "Jesus, I wish I >could make the type a lot bigger and get that horrible background to >go away so that I could read this." > >This is not a stylesheet problem. This is an accessibility problem. You missed my point completely Jon As you yourself point out, the point of cascading options is to overcome accessibility problems. The key point in my message is the last quote. It is no good saying "use my applet to point to the spot you want more info on" to a blind person. Equally its no good saying "point to the red square in the green circle" to someone who is colour blind. They need some way to "make it bigger, with no background images and a sound explanation of each link". We must have user over-ridability of link behaviour if we are to make XML as universally acceptable as HTML. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 13:27:52 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 3.1.a All linkage info in markup not data? At 23:53 20/2/97 -0800, Tim Bray wrote: >The ERB schedule calls for voting on Feb. 26 on these items. > >3.1.a Should we have a principle that all linkage information is encoded in >GIs and/or attribute values, never in character data? > If by character data you mean embedded parsed character data the answer is yes. But the attributes as such must be CDATA to allow # to appear! There is one proviso. There should be nothing to stop you repeating the attribute information as the content of the link element. (Many of my links consist of a URL that is an active hotspot!) ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 13:27:59 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 3.1.i exclude other information? At 23:54 20/2/97 -0800, Tim Bray wrote: >The ERB schedule calls for voting on Feb. 26 on these items. > >3.1.i Should we allow links to contain other information than that >described in >the spec? For in-line links we must. For externally defined links we could reasonably restrict their model. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 13:28:01 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 3.2 c-d Content of linking elements? At 23:54 20/2/97 -0800, Tim Bray wrote: >The ERB schedule calls for voting on Feb. 26 on these items. > >3.2.c Should we provide a content model for general links, and if locators >live in subelements, for them? What are general links? > >3.2.d Should we allow these links to contain anything other than the PCDATA >and, >perhaps locator subelements? For in-line links we must allow more than PCDATA. For external links we could restrict contents to PCDATA + locator subelements. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 13:28:03 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 3.1 b-h: Link contents question matrix At 23:54 20/2/97 -0800, Tim Bray wrote: >Dimension 1: Which pieces of information should be specified for >possible inclusion in linking elements? > (Whatever happened to a in this list?) >b. Type (i) Required - must be a member of a set of XML-defined types (ii) One per link (iii) attribute name/value pair, e.g. linktype=xlink (iv) Yes (v) Yes (vi) No >c. Role (i) Optional (ii) One per locator (iii) attribute name/value pair, e.g. role=source (iv) No - but we could define a useful starter set (as per REV/REL in HTML) (v) N.A (vi) Yes >d. locator (i) Required (ii) One per locator (iii) attribute name/value pai, e.g. locator=.... (iv) N.A (v) N.A (vi) N.A >e. caption (i) Optional (ii) One per locator (iii) attribute name/value pai, e.g. purpose=.... (iv) N.A (v) N.A (vi) N.A >f. behavior (i) Optional (ii) One per link (iii) attribute name/value pai, e.g. behaviour=.... (iv) No - but we could define a (small) useful starter set (v) Yes (vi) Yes >g. locator scheme (e.g. URL, FPI, TEI locator) (i) Optional (ii) One per locator (iii) attribute name/value pai, e.g. scheme=.... (iv) No - but we should define a starter set as being TEI + whatever Internet offers (v) Yes (for MIME-types!) (vi) Not for 1.0, but we will need to later when DSSSL/SDQL becomes popular) >h. others [nominations encouraged] Up to implementations to add as required: should not be added to 1.0 definition ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 13:28:05 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 3.2.a Name for generalized multilink At 23:54 20/2/97 -0800, Tim Bray wrote: >The ERB schedule calls for voting on Feb. 26 on these items. > >3.2.a What should the generalized multiway link be called? Multilink, >General Link, Independent link, anything else? > XLINK gets my vote. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 13:28:07 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 3.a List link required? At 23:53 20/2/97 -0800, Tim Bray wrote: >The ERB schedule calls for voting on Feb. 26 on these items. > >3.a. The initial draft does not have any construct analogous to the "List >Link" construct in Eliot's proposal. Do we need one? > You will for version 2.0, later this year, but I expect its too scary for the time being. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 13:28:40 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: 6. Addressing & process model issues At 09:54 17/2/97 -0800, Tim Bray wrote: >In the ERB's terminology discussions, there was considerable time spent >on the issue of whether this locator fragmentation and process model are >artifacts of one particular addressing scheme, or are a general enough >pattern that XML Link should formalize (and include terminlogy for) >one or both of > > a) locator fragmentation into containing object locator and > contained locator specifier > b) a traversal process model with explicit server/client division of > labor > >What do you think? I, for one, would like to separate out the information about the object container locator and the contained located object. I think that doing this will help to make the calling of referenced documents from cache or alternative sources much easier. The example of xml-tlink="url (http://www.uic.edu/orgs/tei/p3) id (foo) child (3 p)" appeals to me particularly because of its clear split between the URL, ID and path navigation from ID components. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 08:12:03 -0600 From: Len Bullard To: w3c-sgml-wg@w3.org Subject: Re: 3.2.b Locators in attributes or elements? > >The ERB schedule calls for voting on Feb. 26 on these items. > > > >3.2.b Should the locators of a general link be packaged in attributes > >as in HyTime, or as child elements as in the initial draft? Not sure what general link is. Attributes for URLs are established practice and the same kind of structure is used in other SGML DTDs links. Information in child elements should be alternates or external linking information. Len Bullard Lockheed Martin %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 08:18:57 -0600 From: Len Bullard To: Martin Bryan CC: w3c-sgml-wg@w3.org Subject: Re: 3.1.a All linkage info in markup not data? > >The ERB schedule calls for voting on Feb. 26 on these items. > > > >3.1.a Should we have a principle that all linkage information is encoded in > >GIs and/or attribute values, never in character data? So, structures like the nameloc/nmlist or nested FCS links cannot be legal XML Links? Then it is not legal to state that a link can contain a series of IDs which are an aggregate of link targets? What is liking information? Does this mean that in the content of a link, (e.g, bar) bar is not linking information? len bullard lockheed martin %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 08:35:50 -0600 From: Len Bullard To: w3c-sgml-wg@w3.org Subject: Re: 3.3 XML Analogue of HTML " >The ERB schedule calls for voting on Feb. 26 on these items. > > > >3.3.a Should we have a type of link that tries to be a nice clean superset of > >HTML's Anchor? > > Yes. The A structure used in HTML is also used in other SGML applications. It is the simplest form of hyperlink in common use. > >3.3.b If so, what should we call it? Thing. ;-) Sorry, the name game isn't worth a lot of thought at this point. > >3.3.c If 3.2.b goes the way of child elements for locators, should the "A" > >link have a single child element for consistency with that, or no such > >element for consistency with HTML? No brainer. If you already have multiple child elements in other significant applications, restricting them in XML Link applications just narrows the applicability of XML Link. > >3.3.d Should we regard such an "A" link as involving one or two resources? The use of the term resource should be consistent with Dan Connoly's definition. By that definition, the number of resources should be consistent with the URL RFC. If you have a link that has multiple URLs, it has potentially, multiple resources it can locate. In VRML, as stated in earlier discussions, an anchor can contain multiple URLs. The processing of these (resolve which one) is application dependent. Again, it is used for precedence operations. > >3.3.e If it involves two resources, is it a problem that there is no obvious > >place to put locator metadata for the "implied" resource? A link element is not itself a resource unless it is the target of another URL. If an >3.3.f Should we provide a content model for "A" links? Since all XML Link information, the spec itself, is an application of XML, you can do as you please. Expect this application to diverge over time as HTML and other applications diverge. > >3.3.g Should we allow "A" links to contain anything other than PCDATA? XML A links can contain anything the designers of the XML Link Application wish to have there if the designers wish to create an XML Element Type named A. Other XML application designers may create XML Element Types named A for their applications. len bullard lockheed martin %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 08:39:30 -0600 From: Len Bullard To: w3c-sgml-wg@w3.org Subject: Re: 3.a List link required? > >The ERB schedule calls for voting on Feb. 26 on these items. > > > >3.a. The initial draft does not have any construct analogous to the "List > >Link" construct in Eliot's proposal. Do we need one? Yes if this is the only way to get a set of alternative link targets. len bullard lockheed martin %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 08:47:28 -0600 From: Len Bullard To: w3c-sgml-wg@w3.org Subject: Re: 3.1 b-h: Link contents question matrix > >Dimension 1: Which pieces of information should be specified for > >possible inclusion in linking elements? > >b. Type Yes. Required. > >c. Role Yes. Optional > >d. locator Yes. Required. > >e. caption Yes. Optional. > >f. behavior Yes. Optional. > >g. locator scheme Yes. Required. URL. Inclusions of other types should be considered for XML 2.0 contingent on the results of work in the URL working groups. Locator schemes outside the IETF definitions are not Internet locator schemes. Where a resource is identified by a scheme for which there is not a URL-based scheme (eg., FPI) it should not be considered a locator. It should be considered an identifier. The notion that an Identifer=Locator is not sound. > >h. others Not now. Let the implementors work with the above. Then determine what else is viable. len bullard lockheed martin %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 08:52:10 -0600 From: Len Bullard To: Martin Bryan CC: w3c-sgml-wg@w3.org Subject: Re: 3.1.i exclude other information? > >The ERB schedule calls for voting on Feb. 26 on these items. > > > >3.1.i Should we allow links to contain other information than that > >described in the spec? Only write rules you can test. It comes back to the definition of XML Link as an XML application language. You can reasonably restrict a metalanguage application but you cannot reasonably restrict the application of a metalanguage. len bullard lockheed martin %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 09:02:33 -0600 From: Len Bullard To: w3c-sgml-wg@w3.org Subject: Re: 6. Addressing & process model issues > >In the ERB's terminology discussions, there was considerable time spent > >on the issue of whether this locator fragmentation and process model are > >artifacts of one particular addressing scheme, or are a general enough > >pattern that XML Link should formalize (and include terminlogy for) > >one or both of > > > > a) locator fragmentation into containing object locator and > > contained locator specifier This is confusing. Does object = resource? This should be presented in terms of URLs. > > b) a traversal process model with explicit server/client division of > > labor It seems too early to do this without several implementations to look at. len bullard lockheed martin %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 10:53:09 -0500 From: gtn@ebt.com (Gavin Nicol) To: cbullard@hiwaay.net CC: w3c-sgml-wg@w3.org Subject: Re: 6. Addressing & process model issues >>> a) locator fragmentation into containing object locator and >>> contained locator specifier > >This is confusing. Does object = resource? This should be >presented in terms of URLs. I would personally say that a resource is an object that can be directly addressed. The real question is: what *are* the objects and resources? %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 11:07:09 -0500 (EST) From: Sam Hunting To: Tim Bray cc: w3c-sgml-wg@w3.org Subject: Re: xlink, not multilink or xml-link > At 09:59 PM 2/23/97 -0500, Sam Hunting wrote: > >Why not just "xlink"? The initial "x" suggests: > > ... not to mention "Extensible". Yes! The collective thought > process gives birth to another winner. Sign me up for xlink. -T. As Jon points out, it needs to begin with "XML-", being reserved. Sorry -- newbie mistake. However, for the pure sizzle, I'd think of changing the convention .... "xml-" anything doesn't exactly come trippingly off the tongue. Anyhow, if in newbie fashion I'm reopoening a can of worms,feel free to admonish me... %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 17:49:29 +0100 From: "Norbert H. MIKULA" To: w3c-sgml-wg@w3.org CC: bauwensb@rc.bel.alcatel.be, Peter@ursus.demon.co.uk Subject: Parameter entities allowed anywhere ? If I follow production 33 in WD-xml-961114 by the word then I am allowed to use PEReference only at the top-level of internal-subset. Do we want this ? And if not, do we put certain restrictions on it ? -- Best regards, Norbert H. Mikula ===================================================== = SGML, DSSSL, Intra- & Internet, AI, Java ===================================================== = mailto:nmikula@edu.uni-klu.ac.at = http://www.edu.uni-klu.ac.at/~nmikula ===================================================== %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 11:11:15 -0600 From: Len Bullard To: Gavin Nicol CC: w3c-sgml-wg@w3.org Subject: Re: 6. Addressing & process model issues Gavin Nicol wrote: > > >>> a) locator fragmentation into containing object locator and > >>> contained locator specifier > > > >This is confusing. Does object = resource? This should be > >presented in terms of URLs. > > I would personally say that a resource is an object that can > be directly addressed. > > The real question is: what *are* the objects and resources? Ok. Are these the same (definitively) resources as specified in Dan Connoly's glossary. I lurk on uri.bunyip, and it is difficult to sort what is meant by address, location, name, resource and object. I accept that a resource is an addressable object. But what is the definitive relationship among name, location and address? How are these sorted in the URL schemes, and how are they sorted in XML? Are they the same? One set of definitions in one place (presumably Dan's set) would make this easier to understand. len %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 09:42:59 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: xlink, not multilink or xml-link At 11:07 AM 2/24/97 -0500, Sam Hunting wrote: >> >Why not just "xlink"? > As Jon points out, it needs to begin with "XML-" Irrelevant; xlink still works. It's going to have to be XML-something; the spec currently uses XML-MLINK, and in the prose we say multilink. So it could be XML-XLINK and "extended link". I still like it. -T. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 10:22:52 -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: xlink, not multilink or xml-link [Tim Bray:] | At 11:07 AM 2/24/97 -0500, Sam Hunting wrote: | >> >Why not just "xlink"? | > As Jon points out, it needs to begin with "XML-" | | Irrelevant; xlink still works. It's going to have to be XML-something; | the spec currently uses XML-MLINK, and in the prose we say multilink. | So it could be XML-XLINK and "extended link". I still like it. -T. Sorry, I thought from the subject line for this thread that "xlink" was being proposed as an alternative to "xml-link". Now the proposal seems to be "xml-xlink" as an alternative to "xml-link", which is a different matter. I could go with xml-link for the XML version of a contextual link and xml-xlink for the XML version of an independent link. "Extended link" works for me, too, and I like the opposition of (plain old) link (like the kind you're already used to from HTML, only better) vs. xlink. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 22:37:03 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: Re: In lieu of multiple attlists: LINK? At 14:27 24.02.97 +0100, Martin Bryan wrote: >At 12:43 21/2/97 +0100, Steve Pepper wrote: > >>It seems to me that this is PRECISELY the kind of use for which LINK was >>originally intended: the association of processing with structure in a >>modular and eXtensible way. It provides the perfect, SGML-compliant way >>of making existing documents XML-processable without having to modify >>the DTD or document, and without having to invent new syntax. > >... > >The question is, which of the XML link attributes are fixed and which of >them must be user variable. So far all the examples have only shown the one >fixable attribute, that showing the XML link type. But does this work with >variable ones, such as locator and caption? Unfortunately I don't see how a >strictly SGML-confornant link-based solution can deal with these. I think we are talking about different things here. The LINK-based syntax that I am proposing is intended to tell an XML processor something useful about an existing document without having to edit either the document or the DTD. It's just a way to let (say) the TEI DTD say: "Hello, I'm the TEI DTD. You don't know me, but I have an xref element type which I'd like you to treat as if it were xml-link." Communicating this information can be accomplished without invalidating the document with respect to SGML, using the syntax I propose. You are talking about a scenario in which a user may want to specify different attribute values on different instances of an element type-- which obviously requires editing the document. Trouble is, as soon as you do that--and specify a value for an attribute which is "declared" using a magic PI--you no longer have an SGML compatible document. In short: The magic PI solution () doesn't give you any extra mileage. It's just yet more new syntax for something that already exists. Steve -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 15:15:39 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Pardon my stupidity >| At 11:07 AM 2/24/97 -0500, Sam Hunting wrote: >| >> >Why not just "xlink"? >| > As Jon points out, it needs to begin with "XML-" Uh, why was that, again? If we have a reserved attribute named "XML-LINK", used to select among somewhere between 2 and 5 different types of elements that make up the linking machinery, then we *own* this attribute. Why do we need to prefix the *values* with "XML-"? It seems like or are safe and unambiguous. I suspect there was a good reason for this that I managed to miss, and I can't dig it out of the correspondence. -Tim %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg To: w3c-sgml-wg@w3.org Subject: Re: Pardon my stupidity Date: Mon, 24 Feb 1997 16:24:23 -0800 From: Joe English Tim Bray wrote: > >| At 11:07 AM 2/24/97 -0500, Sam Hunting wrote: > >| >> >Why not just "xlink"? > >| > As Jon points out, it needs to begin with "XML-" > > Uh, why was that, again? If we have a reserved attribute named "XML-LINK", > used to select among somewhere between 2 and 5 different types of > elements that make up the linking machinery, then we *own* this attribute. > Why do we need to prefix the *values* with "XML-"? It seems like > > or > > are safe and unambiguous. > > I suspect there was a good reason for this that I managed to miss, and > I can't dig it out of the correspondence. -Tim This might be because of a misguided fear that if we prescribe a set of values for the XML-LINK architectural control attribute then we'll be invading users' namespace for enumerated attribute values, a la: This fear is misguided because nobody needs do it that way, declared value NAME works just fine: It could also be that the value of the XML-LINK attribute specifies an XML-LINK architectural form, and if we allow 10744-style architectural minimization (wherein GIs may be automatically interpreted as architectural form names) this would invade users' element type namespace. --Joe English jenglish@crl.com %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 16:22:11 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: ERB decisions on linking element recognition The ERB met Sat. Feb. 22. Present: all but Clark and DeRose. Discussion was on the subject of recognition of linking elements. The decisions we have apparently taken do leave us with some fairly serious concerns, so we are submitting both the decisions and the concerns to the WG on the theory that someone may convince us either that the concerns are overblown, or that they are understated and that we should proceed to a fallback position. I. Recognizing linking elements via attributes With respect to recognition of linking elements, the ERB has consensus that the best way to do this is with reserved attributes. The attribute name should probably be "XML-LINK". There is, however, a consequence which could lead to direct conflict between the desire for operational simplicity and that for document validity. The problem is, how to declare and provide a default value for the XML-LINK attribute? 1. The case where no markup declarations are provided: plan A: supply the attribute for each element that is a linking element. 2. The case where only the internal subset is to be provided: plan B: declare the attribute with a #FIXED default value in an To: w3c-sgml-wg@w3.org Subject: testing -- testing - please ignore -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 18:24:05 -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: Pardon my stupidity [Tim Bray:] | >| At 11:07 AM 2/24/97 -0500, Sam Hunting wrote: | >| >> >Why not just "xlink"? | >| > As Jon points out, it needs to begin with "XML-" | | Uh, why was that, again? If we have a reserved attribute named "XML-LINK", | used to select among somewhere between 2 and 5 different types of | elements that make up the linking machinery, then we *own* this attribute. | Why do we need to prefix the *values* with "XML-"? It seems like | | or | | are safe and unambiguous. You're right. I was still thinking (without thinking) that there would be GIs with the same names as the attribute values. Since we're not allowing those, the syntax you suggest should work fine. I like it. Jon %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 20:39:53 -0600 From: len bullard To: Tim Bray CC: w3c-sgml-wg@w3.org Subject: Re: ERB decisions on linking element recognition Tim Bray wrote: > > The ERB met Sat. Feb. 22. Present: all but Clark and DeRose. Discussion > was on the subject of recognition of linking elements. The decisions > we have apparently taken do leave us with some fairly serious concerns, > so we are submitting both the decisions and the concerns to the WG on > the theory that someone may convince us either that the concerns are > overblown, or that they are understated and that we should proceed to > a fallback position. If no WG8 support is provided, and LINKTYPE (a la pepper) is not acceptable, the stylesheet option (Allen and Milowski) would be my choice. Since we will be opening the processing spec phase soon enough, that would be a minimal path. It may be that we did this in reverse order. Understanding the options with the processing spec might make some aspects of the linking spec easier to understand and explain. my .0001 cent. len bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Mon, 24 Feb 1997 12:03:40 -0600 From: Len Bullard To: Michael Sperberg-McQueen CC: W3C SGML Working Group Subject: Re: 2.1 a-d: Link Recognition by Reserved Attribute? Michael (FYI): Since you thought acquisition policy was from a strange foreign culture, here is a sample of what your government requires. Strange, perhaps, but not foreign. These are from the Federal Acquisition Regulations. Documents such as this are authoritative. This is what a buyer has to know and try to understand with respect to systems they purchase. This is a very very tiny excerpt. This is why parenthetical standards are generally preferred. Something that is a proper subset typically is considered to be covered by the parent. To be parenthetical, the relationship is normative. The sum of what follows is basically, "prove by market research that XML products are commercial products which meet the goverenment's specifications as determined by the acquisition officer". In other words, let the buyer beware. Note carefully the provisions at the end about conflicting documents and the DoDISS. Tim has done a good job of convincing me that the relationship of XML to ISO 8879 is normative as stated. The bigger question will be "shall that remain the case"? The relationship to ISO 10744 is clearly informative and can be documented in an annex or appendix by simple statements which do not require or suggest that the reader has to consult that document to implement XML conforming systems (Membership To Be Determined by Testing Requirements). Then the market works out the next phase. Oddly enough, the way this reads to me, freeware is not a commercial product. len 11.002 Policy. (a) In fulfilling requirements of 10 U.S.C. 2305(a)(1), 10 U.S.C. 2377, 41 U.S.C. 253a(a), and 41 U.S.C. 264b, agencies shall-- (1) Specify needs using market research in a manner designed to-- (i) Promote full and open competition (see Part 6), or maximum practicable competition when using simplified acquisition procedures, with due regard to the nature of the supplies or services to be acquired; and (ii) Only include restrictive provisions or conditions to the extent necessary to satisfy the minimum needs of the agency or as authorized by law. (2) To the maximum extent practicable, ensure that acquisition officials -- (i) State requirements with respect to an acquisition of supplies or services in terms of -- (A) Functions to be performed; (B) Performance required; or (C) Essential physical characteristics; (ii) Define requirements in terms that enable and encourage offerors to supply commercial items, or, to the extent that commercial items suitable to meet the agency's needs are not available, nondevelopmental items, in response to the agency solicitations; (iii) Provide offerors of commercial items and nondevelopmental items an opportunity to compete in any acquisition to fill such requirements; (iv) Require prime contractors and subcontractors at all tiers under the agency contracts to incorporate commercial items or nondevelopmental items as components of items supplied to the agency; and (v) Modify requirements in appropriate cases to ensure that the requirements can be met by commercial items or, to the extent that commercial items suitable to meet the agency's needs are not available, nondevelopmental items. 11.101 Order of precedence for requirements documents. (a) Agencies may select from existing requirements documents, modify or combine existing requirements documents, or create new requirements documents to meet agency needs, consistent with the following order of precedence: (1) Documents mandated for use by law. (2) Performance-oriented documents. (3) Detailed design-oriented documents. (4) Standards, specifications and related publications issued by the Government outside the Defense or Federal series for the non-repetitive acquisition of items. (b) Agencies should prepare product descriptions to achieve maximum practicable use of recovered material and other materials that are environmentally preferable (see Subparts 23.4 and 23.7). 11.103 Market acceptance. (a) Section 8002(c) of Pub. L. 103-355 provides that, in accordance with agency procedures, the head of an agency may, under appropriate circumstances, require offerors to demonstrate that the items offered -- (1) Have either -- (i) Achieved commercial market acceptance; or (ii) Been satisfactorily supplied to an agency under current or recent contracts for the same or similar requirements; and (2) Otherwise meet the item description, specifications, or other criteria prescribed in the public notice and solicitation. (b) Appropriate circumstances may, for example, include situations where the agency's minimum need is for an item that has a demonstrated reliability, performance or product support record in a specified environment. Use of market acceptance is inappropriate when new or evolving items may meet the agency's needs. (c) In developing criteria for demonstrating that an item has achieved commercial market acceptance, the contracting officer shall ensure the criteria in the solicitation -- (1) Reflect the minimum need of the agency and are reasonably related to the demonstration of an item's acceptability to meet the agency's minimum need; (2) Relate to an item's performance and intended use, not an offeror's capability; (3) Are supported by market research; (4) Include consideration of items supplied satisfactorily under recent or current Government contracts, for the same or similar items; and (5) Consider the entire relevant commercial market, including small business concerns. (d) Commercial market acceptance shall not be used as a sole criterion to evaluate whether an item meets the Government's requirements. (e) When commercial market acceptance is used, the contracting officer shall document the file to -- (1) Describe the circumstances justifying the use of commercial market acceptance criteria; and (2) Support the specific criteria being used. 11.201 Identification and availability of specifications. (a) Solicitations citing requirements documents listed in the General Services Administration (GSA) Index of Federal Specifications, Standards and Commercial Item Descriptions, the DoD Index of Specifications and Standards (DoDISS), or other agency index shall identify each document's approval date and the dates of any applicable amendments and revisions. Do not use general identification references, such as "the issue in effect on the date of the solicitation." Contracting offices will not normally furnish these cited documents with the solicitation, except when-- (1) The requirements document must be furnished with the solicitation to enable prospective contractors to make a competent evaluation of the solicitation; (2) In the judgment of the contracting officer, it would be impracticable for prospective contractors to obtain the documents in reasonable time to respond to the solicitation; or (3) A prospective contractor requests a copy of a Government promulgated requirements document. (b) Contracting offices shall clearly identify in the solicitation any pertinent documents not listed in the GSA Index of Federal Specifications, Standards and Commercial Item Descriptions or DoDISS. Such documents shall be furnished with the solicitation or specific instructions shall be furnished for obtaining or examining such documents. (c) When documents refer to other documents, such references shall (1) be restricted to documents, or appropriate portions of documents, that apply in the acquisition; (2) cite the extent of their applicability; (3) not conflict with other documents and provisions of the solicitation; and (4) identify all applicable first tier references. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 25 Feb 1997 08:38:59 +0000 To: w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: ERB decisions on linking element recognition At 16:22 24/2/97 -0800, Tim Bray wrote: >- point out that it is not possible to duplicate external subset > markup declarations in the internal subset without compromising > SGML validity There might be a sneaky way of overcoming this restriction. If XML required that all ATTLISTs containing XML-LINK attributes must be declared as parameter entities, and then invoked in the DTD as a parameter entity reference, then the parameter entity definition could be repeated in the external and internal subsets without upsetting an SGML system because internal parameter entities would replace external ones. What you would end up with, for each XML-link element would be an entry in the internal subset of the form: ' > ' > ]> ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 25 Feb 1997 08:38:54 +0000 To: Steve Pepper , w3c-sgml-wg@w3.org From: Martin Bryan Subject: Re: In lieu of multiple attlists: LINK? At 22:37 24/2/97 +0100, Steve Pepper wrote: >The LINK-based syntax that I am proposing is intended to tell an XML >processor something useful about an existing document without having to >edit either the document or the DTD. It's just a way to let (say) the TEI >DTD say: "Hello, I'm the TEI DTD. You don't know me, but I have an xref >element type which I'd like you to treat as if it were xml-link." This can only be possible if the element concerned already has all the information required by an XML link processor in the appropriate form. The chances that an existing element will have user updatable scheme, locator, caption and behaviour attributes already, with those names, is extremely slim. (Hence my comments yesterday on the need to allow for the mapping of attribute names.) >Communicating this information can be accomplished without invalidating >the document with respect to SGML, using the syntax I propose. Yes, but what elements can they be used on? They cannot be used on the HTML A because this does not have any of the attributes listed above. It cannot be used on TEI links, because they do not have some of them. (Steve: If LINK could do the job I would be the first to support it - I am one of the few who have been showing how it can be used effectively for the last decade.) >You are talking about a scenario in which a user may want to specify >different attribute values on different instances of an element type-- >which obviously requires editing the document. Trouble is, as soon as you >do that--and specify a value for an attribute which is "declared" using >a magic PI--you no longer have an SGML compatible document. It is a fact that no 8879:1986 compliant tool will be able to process documents meeting ANY of the proposals made so far; PI, multiple processing or LINK processing. They will all baulk the minute one of the attributes defined by XML has to be added to an instance if it has not been defined as part of the element's first ATTLIST. >In short: The magic PI solution () doesn't give you any >extra mileage. It's just yet more new syntax for something that already >exists. What it buys you, if you start it with The ERB voted as follows: In favor of allowing recognition via GI: >Bray, Magliery, Maler, Kimber. Against: Bosak, Hollander, Paoli, >Sharpe, Sperberg-McQueen. Thus the measure fails. How can you *disallow* this? It is, after all, an application convention. Now, if the question is whether XML-Link processors *must* have the ability to recognise by GI, then the negative makes sense. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 25 Feb 1997 10:39:11 -0500 To: w3c-sgml-wg@w3.org From: "Steven J. DeRose" Subject: Re: ERB decisions on linking element recognition At 08:41 AM 02/25/97 -0500, Gavin Nicol wrote: >>The ERB voted as follows: In favor of allowing recognition via GI: >>Bray, Magliery, Maler, Kimber. Against: Bosak, Hollander, Paoli, >>Sharpe, Sperberg-McQueen. Thus the measure fails. > >How can you *disallow* this? It is, after all, an application convention. >Now, if the question is whether XML-Link processors *must* have >the ability to recognise by GI, then the negative makes sense. Applications on top of XML can do anything they want, of course. If they have their own links types that they recognize by virtue of dowsing, that's just fine. What I understand the resolution to mean is that such recognition is not part of XML: if it exists it is an application convention at another level. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 25 Feb 1997 10:09:54 -0600 From: Len Bullard To: "Steven J. DeRose" CC: w3c-sgml-wg@w3.org Subject: Re: ERB decisions on linking element recognition Steven J. DeRose wrote: > > Applications on top of XML can do anything they want, of course. If they > have their own links types that they recognize by virtue of dowsing, that's > just fine. What I understand the resolution to mean is that such recognition > is not part of XML: if it exists it is an application convention at another > level. This sounds like the "application engines" talked about in HyTime. Does the ERB intend to draft an extension mechanism similar to the way HyTime allows one to declare architectures to use with HyTime? IOW, XML is the base linking architecture, but it provides the way to enable others to be defined for application conventions? Or will this be something that remains defined in the HyTime annex? len bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Tue, 25 Feb 1997 14:56:46 -0500 From: gtn@ebt.com (Gavin Nicol) To: sjd@kirk.mit.edu CC: w3c-sgml-wg@w3.org Subject: Re: ERB decisions on linking element recognition >Applications on top of XML can do anything they want, of course. If they >have their own links types that they recognize by virtue of dowsing, that's >just fine. What I understand the resolution to mean is that such recognition >is not part of XML: if it exists it is an application convention at another >level. My point exactly. The wording is less than ideal. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 26 Feb 97 06:36:40 CST From: Michael Sperberg-McQueen Subject: Re: Parameter entities allowed anywhere ? To: W3C SGML Working Group On Mon, 24 Feb 1997 11:56:56 -0500 Norbert H. MIKULA said: >If I follow production 33 in WD-xml-961114 by the word >then I am allowed to use PEReference only at the top-level >of internal-subset. > >Do we want this ? And if not, do we put certain >restrictions on it ? If this is a correct reading of the grammar, then the document is wrong. There was no decision to restrict parameter entities to a single level of expansion, and the motivation for having p.e.s at all was to allow the use of current DTD construction methods. To be honest though I don't think this is a correct reading of production 33. There should probably be prose saying that PE references in the internal and external subsets are invisible to the grammar (in the sense that the replacement text has to fit where the reference goes, i.e. that you stay in the internal subset rule), except that references can only occur where the grammar say they can. (Except that that is also false; the grammar makes no pretense of saying where PE refs can occur within declarations. Perhaps it's the limitations of my technical training, but I have not found a clean way to describe the PE rules formally, and not much of a clean way to describe them informally, either. Any help from the assembled wise ones would be very useful. Thank you for calling attention to this problem. -CMSMcQ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Wed, 26 Feb 1997 15:04:27 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Call for participants: WWW6 workshop I will be coordinating an all-day workshop on "Delivering Structured Documents over the Web" that will be held in conjunction with the WWW6 Conference in Santa Clara, California on April 7, 1997. For a description, see http://www6conf.slac.stanford.edu/workshops/structure.html Workshop participation is by invitation only. If you would like to participate, please send me a brief statement (1-2 paragraphs) setting forth your position on what you think the best approaches would be to implementing structured document delivery on the Web in the areas of syntax (structured HTML, generic XML, SGML), linking (HyTime, XML-Link, Hyper-G), processing/scripting (Java, JavaScript, Active-X), and style (CSS, DSSSL, dsssl-o). I'm looking to assemble a group of knowledgeable people who are dedicated to enabling structured document delivery on the Web but have differing viewpoints on how that delivery should best be accomplished. Jon (bosak@eng.sun.com) ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 27 Feb 1997 12:14:22 +0100 From: "Norbert H. MIKULA" To: W3C SGML Working Group CC: Michael Sperberg-McQueen Subject: Re: Parameter entities allowed anywhere ? Michael Sperberg-McQueen wrote: > To be honest though I don't think this is a correct reading of > production 33. There should probably be prose saying that > PE references in the internal and external subsets are invisible > to the grammar (in the sense that the replacement text has to > fit where the reference goes, i.e. that you stay in the internal > subset rule), except that references can only occur where the > grammar say they can. (Except that that is also false; the > grammar makes no pretense of saying where PE refs can occur > within declarations. Perhaps it's the limitations of my technical > training, but I have not found a clean way to describe the PE > rules formally, and not much of a clean way to describe them > informally, either. Any help from the assembled wise ones would > be very useful. You were talking about prose in the standard. I am not too much of a person that is crazy about formal languages. However, IMHO the less prose in the XML standard the better. (But I think everybody will agree on this.....or not?) I do believe the less prose, the more implementors we will get. I have started to implement an SGML parser when I knew about SGML that it is something like Standard or was it Structured GML.... :-) Putting down the productions of the SGML handbook was pretty much straightforward, but then .... During the implementation of XML I tried to implement it the way it is prescribed in the standard literally (like a person without any SGML knowledge would do....) After all, one day we have to face the WWW crowd and guess how eager the will be to read through lots of potentially ambigous prose. When I tested XML first time against the XML test-instances I had to change the grammar lot. (Especiall many S were missing the current draft. Maybe, one day, I will have the time to put down all the *mistakes* I enountered) Finally, if you think that my interpretation of production 33 in the current draft is wrong ,or at least not correct :-), then I just would like to know how one can deduce that (%par;) works in XML. PS: Just playing devils advocate...... -- Best regards, Norbert H. Mikula ===================================================== = SGML, DSSSL, Intra- & Internet, AI, Java ===================================================== = mailto:nmikula@edu.uni-klu.ac.at = http://www.edu.uni-klu.ac.at/~nmikula ===================================================== %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 27 Feb 1997 12:27:05 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@w3.org Subject: Re: Parameter entities allowed anywhere ? Lines: 29 In message <33156C8E.37D6@utila.ifi.uni-klu.ac.at> "Norbert H. MIKULA" writes: > Michael Sperberg-McQueen wrote: > > To be honest though I don't think this is a correct reading of > > production 33. There should probably be prose saying that > > PE references in the internal and external subsets are invisible > > to the grammar (in the sense that the replacement text has to > > fit where the reference goes, i.e. that you stay in the internal I took the sense of 4.3(6) to mean that PEs were treated in the same way as other entities, though I agree that strictly 4.3 does not relate to PEs. The effect is important, of course. For example, I have included HTML2.0 in my DTDs by something like: %html20; Unless the PEs in HTML2.0 are processed, the construct fails. [...] IMO developing parsers and real examples are the best way to discover these problems and I am very grateful to Norbert for his effort. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Thu, 27 Feb 1997 13:45:14 -0600 From: Len Bullard To: Tim Bray CC: w3c-sgml-wg@w3.org, xml-dev@ic.ac.uk Subject: Current Markup Language Example Something to consider from a company producing Web applications for cellular phones. This is their web example for their Handheld Device Markup Language. This snippet produces a menu. Cust Status Orders Balance Isn't this what the behavior= optional attribute is good for? len bullard %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg Date: Sat, 1 Mar 1997 17:46:09 +0100 To: w3c-sgml-wg@w3.org From: Steve Pepper Subject: ERB decisions on the LINKTYPE proposal At 01:22 25.02.97 +0100, Tim Bray wrote (in his posting entitled "ERB decisions on linking element recognition"): >The ERB met Sat. Feb. 22. Present: all but Clark and DeRose. Discussion >was on the subject of recognition of linking elements. >... > >There was sharp dissension in the ERB on what to do given the >uncertainty on what WG8 will do. Several members, while respecting the >integrity and appropriateness of the syntax, and the prospect of explaining it, repellent. Nonetheless, the >of at least one member. The PI technique is nicer looking and easier to >explain, but requires extra implementation... I would like to thank the ERB for its serious discussion of my proposal, and Tim especially for his thorough report. However, I am disappointed that none of those members of the ERB that are opposed to the proposal have seen fit to explain their reasons in this forum. Is that not what this list is for? Up to now, the only counterarguments that have been presented have been David Durand's (by his own admission) knee-jerk objection that "LINK is widely avoided" and "controversial", and Martin Bryan's concern that the proposal doesn't provide all the flexibility that being in full control of the DTD and instance affords. Neither of these arguments disprove my contention that the LINK-based mechanism is a powerful and elegant way of rendering a very large class of existing documents XML-processable without having to modify either the DTD or the instance. (I do not suggest that this should be the *only* mechanism allowed: Obviously, specifying the attributes in the document and/or declaring them in the internal subset are suitable alternatives where the problem of multiple attlist declarations doesn't arise.) There remains the objection (brought to us second-hand by Tim) of "several members" of the ERB who "find the syntax [of the ]> LINK-based: (2) ]> Now, while I agree that we could and would have come up with a simpler syntax if all we wanted to do was declare additional attributes, I do not see that this is so verbose, complicated or hard to explain that it should be rejected for that reason alone. The only real difference lies in the two lines marked (1) and (2). The ONLY parts of these two lines which are variable (and need to be "explained") are the document type name ("tei.2") in line (1), and the list of element types ("xref") in line (2). EVERYTHING ELSE would be fixed in the xml-link spec. (Over and above this, a note explaining that the exact choice of syntax was governed by the requirement to keep XML 100% SGML conformant, would probably be in advisable.) That's all that is required, and it can be done with just one additional production. Remember too, that most of the people we will be explaining this to will be those that already have a substantial body of SGML-encoded information that they want to deliver using XML. They will have no problem appreciating the aptness of the LINK-based solution (unless, of course, they too suffer from mindless LINKophobia). People coming to XML from HTML will be in a position in which they have full control of their DTDs (if they use them) as well as their instances, and will be able to use the simpler mechanisms that Tim calls plans A and B. So please, members of the ERB: Present some well-founded counterarguments before rejecting this proposal out of hand. Regards, Steve -- Steve Pepper, SGML Architect, Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway http://www.falch.no/ tel://+47 2290 2733 fax://+47 2290 2599 "Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/ %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% w3c-sgml-wg