Date: Thu, 16 Jan 1997 20:21:31 +1100 From: Rick Jelliffe To: w3c-sgml-wg@www10.w3.org Subject: Re: back to XML: The "You Babe" problem ( Oops extra > by courtesy my idiot fingers.) > lee@sq.com wrote: > > > > > So I think we should reword the spec to require one of: > > > (a) &u-babe; > > > (b) &U-BABE; > > > (c) &u-BABE; > > > (d) &U-babe; > > > > I don't have a problem with allowing any of those forms. > > If you only allow one, probably (b). > > It should be &UBABE; because > > * The U stands for Unicode, and imitates the Unicode people's preferred > form of U+BABE. > * The - should be missing, because it adds a few extra K to any large > series of declarations, for no real benifit I can see. > * The BABE should be upper case because human typists have already > stuck their shift key down to get the &U > * For compatibility with the currrent SPREAD entities, available > http://www.allette.com.au/sgml/ercs/entities/spread.tar.gz > > The "u-" form is taken from a very old draft of SPREAD. After various > discussions, I changed it to the simpler "U" form, which is what found > its way into ISO/IEC 14755, 'Input Methods to Enter Characters > from the Repertoire of ISO/IEC 1-646 with a Keyboard or Other Input > Device', which has just been accepted, if my memory serves me well. > > To quote from that DIS: > > "In this standard, identification of specific character of the UCS > repertoire will be by means of symbols in the form Uxxxxxxxx." > The xx is hex. In that standard the hex is all uppercased, > though it urges case insensitivity. That standard also allows you > to elide leading 0s. That standard basically gives several methods > for input, including a chord entry method: shift + control > being held down, while the other hand types in the hex number I think. > > > > > I wish that something like �xbabe; could be allowed, though -- a > > relatively straight forward backward compatible extension to 8879 -- > > as per C, C++, Java, etc. > > I hope some system for Hex numbers finds its way into ISO 8879. Decimal > numbers are quite good for computers, but not very convenient for > humans :-) > > -ricko -- Regards Rick Jelliffe email: ricko@allette.com.au _______________________________________________________________ Allette Systems (Australia) email: info@allette.com.au Level 10, 91 York Street www: http://www.allette.com.au Sydney 2000 NSW Australia phone: +61 2 262 4777 fax: +61 2 262 4774 _______________________________________________________________ Date: Thu, 16 Jan 1997 10:48:46 +0000 To: w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: Permitting non-indirect links Eliot wrote: >Another way to represent this chain in the HyTime world would be to use >Formal System Identifiers to build the location chain (which would probably >please Martin "Mr. Entity" Bryan more): > >http://www.somewhere.com" > >/oii/en" > >alpha.html" > >]> > What, me want entities? If I could get away without having to use the entities I would. What I want is reusable IDs to the container parts you correctly identify. My only reservation was that I was not seeing host1 and chain2 as being valid HyTime. If you say they are I am as happy as a sandboy - (whatever that may be):-} >Where the "SOIbase" attribute points to the entity whose on system ID is to >be prepended to yours. Thus, the effective URL of the chain is >"http://www.somewhere.com/oii/en/alpha.html". > >Comes to the same thing and the semantics of URL interpretation are the >same, but some might prefer to use entities for this rather than location >addresses (for example, because they can put the SYSTEM IDs in catalogs). For those that don't want to use entities is there any way we can do this by stringing together attribute values? (Incidentally Eliot, this was exactly the point I was talking about that resulted in your private message asking me to explain the need.) ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Thu, 16 Jan 1997 10:48:43 +0000 To: lex@www.copsol.com (Alex Milowski), w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: Using HyTime Arcform stuff (was Re: Ephemeral XML?) Alex Milowski >We need..... the killer app! I was talking yesterday to the EDIFACT people at the European Board on EDI Standardization re something called EDI-Lite for Electronic Commerce on the Web. This could be going XML! ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Thu, 16 Jan 1997 10:48:30 +0000 To: w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: Permitting non-indirect links David Durand wrote: >>There are two problems with this appoach. One is the need to define entities >>for each part of each URL in the BOS or document, and the second is that >>each link has to look different so my second link has to read: >> > >They only have to look this different if it uses a different server, >different root path, different subject path, and different document path. I was just making it clear to other readers that the entity names you gave, which looked very nice for the first example, are not reusable for every URL as entities cannot be redeclared within docs. The result is that by the 100th source of files you get some pretty wierd entity names, and a chance of clashing with other entity names in the DTD. >Declaring entities is no harder than the extra elements that the HyTime >approach would require. I'm not saying it would be - remember that I have said before that entities in a BOS are a good way of assigning referencable names to files. The same applies to naming reusable fragments of file identifiers, if you are willing to live with parsing the entity declarations. The problem is that our DTD-less browser would be required to parse the entity declarations to get the URLs. I thought we wanted to avoid this. >>A more user friendly approach is: >> >>>URL-file="alpha.html" URL-fragment="X"> > >This seems syntactically equivalent to a hard-coded link. Where does the >indirection come in in this example? It is a hard-coded example: it was just a simple example to show how managed info on DNS names, path names at DNS and files within paths could be presented using attributes - the indirection came latter. >>This is the same as the capture on HoTMetaL, but instead of resolving the >>whole URL into a single string at capture stage it leaves the resolution to >>the point at which calling of the file is needed. > >I don't understand this sentence. The above example has a seriws of >hard-wired values, and seems utterly equivalent to the following: > The difference is that I can change one part of the hardwired string without changing the whole string: therefore changing all files that have moved directory or moved server becomes a lot easier. >I see the breakup of the URL into attribute values, but I don't see that >this does anything but save a programmer from writing a 50-line URL parser. The problem is that link management is done by real users, not programmers. We don't want to have to write a URL parser to change all relevant directory pathnames! >>With indirection of the strings to XML location address IDREFS (beginning >>xla for clarity) this would become: >> >>>XML-fragment=xla76345> > >Now we see some indirection, but how does it differ semantically from: > Only in that it points to id name space rather than entity name space. Id name space is created in the document instance, which must be parsed by the browser, whereas entity name space is created in the DTD, which is not necessarily parsed by the browser. >>>HyTime location ladders can specify this, and I think that the use of >>>relative URLs, along with the location facilities we have been talking >>>about, would actually let you do the equivalent with links. >> >>The problem is that HyTime location ladders don't seem to allow you to point >>to subsections of location sources. For example, can I do a location address >>just to a DNS, and then another just to a directory path at the DNS. I don't >>think I can using pure HyTime, but I would sure like to for XML link > >>management. > >You could do something like this, I think (Eliot: apologies for any >syntactic gaffes, but I am prety sure of the semantics) > > > > >We would need to define that relative URL semantics apply when a URL is the >locsrc for a URL. This makes sense. > >However, I don't like the HyTime solution that much, as locsrc has all the >decoupling problems of ilink, but offers less obvious value. The value of locsrc is its reusability. You only need to define it once and then reference it via the ID. This means you only have one entry to manage for each location source. This is a vast saving in management for heavily reused address components. It is also infinitely quicker to update, and generally a safer management approach. >I am not saying that it's worthless, but I think we can live without locsrc >and still have a _lot_ of power. > >As far as I know, the attribute value syntax that martin is proposing could >not be a valid HyTime location latter (though it could of course be a >query, since any markup at all can be defined as a query). > >So Martin's proposed markup is only HyTime compatible in the weakest way. I agree that the HyTime compatibility is weak, due to the problems stated above, but the problem of name space management in a DTD-less environment require that we rely on names in instances rather than names in DTDs. My concern in all this is not whether it is technically feasible, but whether it is realistically manageable over a long time period. As far as this goes I will continue to play devil's advocate and suggest alternate ways of doing things that might have better management potential. >>Similarly the SOIBase concept of formal system identifiers does not allow >>for segmentation of the base, which is what I am asking for. > >Entities can be used in the same way there too. But they cannot be used in catalogs: how do I move my URL locators to catalogs if they have entity declarations in them. Do I have to resolve them and then update them latter? Bang goes my management idea of leaving resolution of the URL until the point the file is actually called. >Now I know that entities are (over) used in SGML to make up for language >deficiencies, but I think that URL composition is actually a pretty natural >use of entities: certainly it would not take long to explain to authors. It would take no longer to explain how my four/five attributes map to the URL syntax: they are a direct mapping of the contructs in the URL RFC! And they do not change name for each URL locator, while the entity names would need to. >And although it is somewhat verbose, any indirection as powerful as Martin >seems to want is going to be verbose, so I don't feel that we're condemning >naive users to endless obscurity if we decide that entities are good >enough. If you consider the HoTMetal URL creation menu verbose then how come HoTMetaL is a leader in the field? All I am doing is say store the info HoTMetaL creates in its separate boxes as separate attributes until such time as you call the file, instead of resolving the complete URL the minute you close the attribute menu. The fact that URL definitions using ID locators is more verbose than doing an entitiy declaration is irrelvant to users. The IDs and associated declarations will be generated automatically by the editor without user intervention. The question is whether browser recognition of entity declarations takes longer than browser resolution of IDs. If the entity declarations have to be read as part of the DTD I would contend that at browser level HyTime location addressing may be faster than entity resolution! ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Thu, 16 Jan 1997 08:09:57 -0500 From: Paul Prescod To: Martin Bryan CC: w3c-sgml-wg@www10.w3.org Subject: Re: Permitting non-indirect links > >And although it is somewhat verbose, any indirection as powerful as Martin > >seems to want is going to be verbose, so I don't feel that we're condemning > >naive users to endless obscurity if we decide that entities are good > >enough. > > If you consider the HoTMetal URL creation menu verbose then how come > HoTMetaL is a leader in the field? All I am doing is say store the info > HoTMetaL creates in its separate boxes as separate attributes until such > time as you call the file, instead of resolving the complete URL the minute > you close the attribute menu. HoTMetaL has many things to reccommend it. Many HTML editors have that same kind of URL definition field, and I consider it a big mistake unless it is accompanied by a space where you can just type a URL. Most people get URLs from web browsers, search engines, the newspaper, television, etc. In none of those situations would the "domain name" be distinct from the "host name" or the "path" or the "protocol." All but the most technical authors just want to cut and paste an *opaque string*. In other words, there are good features in your proposal, especially maintenance benefits, but I think that making the argument from a *usability* standpoint is going to lose. There is nothing particularly usable about those little dialogs (and they show up in MANY HTML editors) except to the minority of the population that knows what a "protocol" is. Paul Prescod Date: Thu, 16 Jan 1997 09:20:36 -0500 From: gtn@ebt.com (Gavin Nicol) To: w3c-sgml-wg@www10.w3.org Subject: Slight change to XMLDecl productions... While I am still rather less than pleased by having the PI hack in the XML spec (or rather, having encoding be part of it), I accept that the probability of getting it removed is fairly small. So, in the interest of interoperability, I would like to propose a very small change: Currently "S" is defined with ideographic space as a component. As ideographic space is *not* part of ASCII, I would recommend using a production other than "S" as the separator in the XMLdecl; something limited to just space and tabs (though it will be easy for authors in Japan to make a mistake here, it's probably a reasonable tradeoff). Date: Thu, 16 Jan 97 08:26:31 CST From: Michael Sperberg-McQueen Subject: Re: back to XML: The "You Babe" problem To: W3C SGML Working Group On Wed, 15 Jan 1997 17:45:39 -0500 Christopher R. Maden said: >I'd still like to hear a counterargument to defining the reserved >Unicode stuff as case-insensitive, non-namespace-eating, looking-like- >charrefs, FUNCHARS (&#U-bABe;). The note describing the ERB's decision on this question (23 Oct 1996) says the following: C.5 if XML uses ISO 10646, should there be a special form of character reference using hexadecimal, not decimal, numbers, since most references to ISO 10646 and Unicode use hex, not decimal (9.5)? Agreed (Clark dissenting) to specify that XML documents may refer to characters in ISO 10646 using the form '&u-' or '&U-' followed by four hexadecimal digits, followed by semicolon. Rationale: Unicode and ISO 10646 documentation is in hexadecimal, not decimal, so this constitutes a small but important convenience and aid to reliability. The proposal to use '&u' was preferred to the '&#u' proposal since it is believed to allow SGML systems to handle these references (which appear to an SGML parser to be general entity references) using a default entity declaration. (Consult James Clark for details.) So much for the official version; what follows is my own thinking, for which the other members of the ERB are not responsible. I don't know how many current systems are in a position to set up a way of handling default entities that would allow them to handle these hex references correctly, but it appears at least possible within the framework of 8879. That's long-term solution no. 1: SGML parsers get Clever Default Entity Handling (motivated primarily, I assume, by XML and a public-spirited desire to be part of the Great Spread of SGML Across the Globe). Long-term solution no. 2: SGML97 gets hex character references. This has been proposed (it's in a U.S. position paper on the WG8 web site, for which I cannot now remember the URL), though there are some hitches finding a syntax which everyone agrees on and which doesn't involve re-interpreting some pathological cases in hypothetically existent current documents. If I understand the current state of play correctly, many think there is no alternative but the introduction of yet another delimiter, for hex/octal character reference open. If this works, it's much the best solution, and I hope you will ALL WRITE YOUR NATIONAL BODIES AND SAY YOU WANT IT. And what should we do in the short term? For SGML systems that cannot handle hex references using clever default-entity tricks, we seem to have the choice of (a) providing a standard set of entity declarations including all such characters, to be included in the DTD, (b) providing an SGML declaration defining all the possible hex references as names, (c) providing entity declarations or character-name declarations just for the characters actually present in the document, or (d) eliminating all such hex references by replacing them with decimal character references. All of these have disadvantages and (presumably) advantages; we just have to pick. Choices (a) and (b) seem likely to strain the symbol-table space of most parsers (I know that when writing code *I* for one often make simplistic assumptions like "The symbol table will fit within the address space of an IBM 3090" -- or even of a DOS machine). Choice (c) would seem to involve doing a one-off SGML prolog for each XML document, or for each set of XML documents, to be processed with a full-SGML system, which gives some people hives. Choice (d) requires running an preprocessor on XML before submitting it to a Full-SGML system, or at least to a sufficiently dim full-SGML system, and our goals seem to suggest it should not be the *required* or *recommended* solution: our goals say XML document instances should be legal SGML document instances, as they stand, without filtering, as long as they are provided with a suitable prolog. As I say, the thought that the required prolog might vary from instance to instance bothers some people a lot, but (c) seems the most plausible method of handling this in the short run, or even in the long run if SGML 97 doesn't have hex references and we are stuck with legacy parsers lacking Clever Default Entity Handling. In choice (c), I'm not sure it really matters whether the hex references are declared as entities or as character names (are they really all FUNCHARS? I don't have the standard handy) in theory, but in practice it seems easier to me if I can have a standard unchanging SGML declaration for XML documents, and confine my instance-specific tweaks to adding some declarations to the internal subset. Not a conclusive argument, but it does seem to me to outweight the advantage -- if it is one -- of case-insensitive hex references. If we do have case-sensitive references, here's my vote for uppercase. Uppercase is more visible, and lowercase hex looks funny. -C. M. Sperberg-McQueen Date: Thu, 16 Jan 1997 15:47:33 +0000 To: Paul Prescod From: Martin Bryan Subject: Re: Permitting non-indirect links Cc: w3c-sgml-wg@www10.w3.org At 08:09 16/1/97 -0500, Paul Prescod wrote: >HoTMetaL has many things to reccommend it. Many HTML editors have that same kind of URL >definition field, and I consider it a big mistake unless it is accompanied by a space >where you can just type a URL. I wasn't picking out HoTMetaL particularly here, only the fact that their menu matches the URL spec correctly. > Most people get URLs from web browsers, search engines, >the newspaper, television, etc. In none of those situations would the "domain name" be >distinct from the "host name" or the "path" or the "protocol." All but the most >technical authors just want to cut and paste an *opaque string*. A) We have agreed that there will need to be unmanaged URLs created by copy and paste b) An intelligent system should easily be able to break the copied URL into manageable components for storage in the link manager. > >In other words, there are good features in your proposal, especially maintenance >benefits, but I think that making the argument from a *usability* standpoint is going to >lose. There is nothing particularly usable about those little dialogs (and they >show up in MANY HTML editors) except to the minority of the population that knows what a >"protocol" is. The majority will not know, or care, how to manage their files: they simply cut and paste unmanageable strings that have no meaning as far as they are concerned. Only people who know the problems of managing URLs will need to worry about them being broken down into their logical components, just as only those who care about the structure of their text files will need to use SGML/XML. For the morons HTML will suffice. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Thu, 16 Jan 1997 12:16:09 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Permitting non-indirect links At 5:48 AM 1/16/97, Martin Bryan wrote: >David Durand wrote: >>>There are two problems with this appoach. One is the need to define entities >>>for each part of each URL in the BOS or document, and the second is that >>>each link has to look different so my second link has to read: >>> >> >>They only have to look this different if it uses a different server, >>different root path, different subject path, and different document path. > >I was just making it clear to other readers that the entity names you gave, >which looked very nice for the first example, are not reusable for every URL >as entities cannot be redeclared within docs. The result is that by the >100th source of files you get some pretty wierd entity names, and a chance >of clashing with other entity names in the DTD. > >>Declaring entities is no harder than the extra elements that the HyTime >>approach would require. > >I'm not saying it would be - remember that I have said before that entities >in a BOS are a good way of assigning referencable names to files. The same >applies to naming reusable fragments of file identifiers, if you are willing >to live with parsing the entity declarations. The problem is that our >DTD-less browser would be required to parse the entity declarations to get >the URLs. I thought we wanted to avoid this. Well, I want to avoid it because of the extra file-transfers, but if we are indirecting anyway, there is no problem there. And in any case, all of this can be done in the document instance, by putting the entity declarations into the internal subset. And if the internal subset declares and references a parameter entity with the redirected entity definitions, you can have the indirection, too! >>I don't understand this sentence. The above example has a seriws of >>hard-wired values, and seems utterly equivalent to the following: >> > >The difference is that I can change one part of the hardwired string without >changing the whole string: therefore changing all files that have moved >directory or moved server becomes a lot easier. I still don't understand. The global change that is going to update all the occurrences of /oii/en/, could update a URL or an attribute value just as easily. (Or the editor function could do it, doesn't matter). One way you're updating a substring in a URL everywhere, the other way, you're updating an atribute value everywhere. The difference in convenience seems marginal. >>I see the breakup of the URL into attribute values, but I don't see that >>this does anything but save a programmer from writing a 50-line URL parser. Link management doesn't seem to change on whit to me, just the work of the parser writer. And most people (not you) recycle URLs via cut-and-paste >from a browser -- they would be _dis_-advantaged by this approach. >> example of indirection using entities deleted. What's the real difference >> between the two? > >Only in that it points to id name space rather than entity name space. Id >name space is created in the document instance, which must be parsed by the >browser, whereas entity name space is created in the DTD, which is not >necessarily parsed by the browser. Internal subsets can be. If you are willing to do this indirection, the internal subset is a small price to pay. I'm also now convinced that the internal subset should always be parsed for entity and attribute declarations, anyway, as I'm arguing in a separate thread. >> >> >> >> >The problem is that the last location address is wrong as far as HyTime is >concerned as it does not point to a referencable entity. We would need DNS >and pathnames to be allowed as valid "entity-source-identifiers" for this to >work. There seems to be no reason why it should not, it just hasn't been >envisaged to date. These are all HyTime Queries, as any URL reference must be. HyTime does _not_ require that all links use entities, as long as you are willing to use some queries; Eliot and I are arguing that XML links _cannot_ make that requirement. >>We would need to define that relative URL semantics apply when a URL is the >>locsrc for a URL. This makes sense. >> >>However, I don't like the HyTime solution that much, as locsrc has all the >>decoupling problems of ilink, but offers less obvious value. >The value of locsrc is its reusability. You only need to define it once and >then reference it via the ID. This means you only have one entry to manage >for each location source. This is a vast saving in management for heavily >reused address components. It is also infinitely quicker to update, and >generally a safer management approach. Since we agree that the same reusability is also possible with entities (although less-elegantly), do we now agree that we don't need locsrc? >>As far as I know, the attribute value syntax that martin is proposing could >>not be a valid HyTime location latter (though it could of course be a >>query, since any markup at all can be defined as a query). >> >>So Martin's proposed markup is only HyTime compatible in the weakest way. Martin agreed with me, but I must say that this was a cheap shot. The URL links I am proposing are also queries, and the real advvantage is that they use the syntax already poularized by HTML, and the semantics defined by the URL standard (relative URLs are well-defined, and we don't need to explain how they work(). > .... but the problem of name space management in a DTD-less environment >require that we rely on names in instances rather than names in DTDs. My >concern in all this is not whether it is technically feasible, but whether >it is realistically manageable over a long time period. As far as this goes >I will continue to play devil's advocate and suggest alternate ways of doing >things that might have better management potential. Is it feasible to manage if we make applications parse the internal subset? This can be done as an option today via the RMD, though I think it should simply be made a requirement. I really think that locsrc is not worth implementing: the only thing that does argue for its feaibility is that most of the code to handle "raisins in a pudding" markup will be there for ilinks, so it could be re-used. But I'm strongly convinced that ilinks offer amazing power we just don't get any other way, and I'm not so convinced with respect to locsrc. >But they cannot be used in catalogs: how do I move my URL locators to >catalogs if they have entity declarations in them. Do I have to resolve them >and then update them latter? Bang goes my management idea of leaving >resolution of the URL until the point the file is actually called. I think you can get equivalent behavior with external entities. I feel like the ground keeps shifting under me, with new requirements added in every time. >>Now I know that entities are (over) used in SGML to make up for language >>deficiencies, but I think that URL composition is actually a pretty natural >>use of entities: certainly it would not take long to explain to authors. > >It would take no longer to explain how my four/five attributes map to the >URL syntax: they are a direct mapping of the contructs in the URL RFC! yes, but your explanation will be in addition to the explanation already required for the simple URL link, since we have agreed that we can't do without that. So you are adding a bunch of new attributes that duplicate the function of one attribute we already have, to add syntactic convenience that is not essential because entities and the single attribute can produce the same effects. > And >they do not change name for each URL locator, while the entity names would >need to. This is a red herring. Entities only change name when things are not shared (as do the attribute values). The number of names you have to make up is _exactly the same on the two proposals. Only the syntax of how they are used changes. (entities get concatenated in a single attribute value), multi-locsrc's (or whatever) get spread over several attributes. >If you consider the HoTMetal URL creation menu verbose then how come >HoTMetaL is a leader in the field? All I am doing is say store the info >HoTMetaL creates in its separate boxes as separate attributes until such >time as you call the file, instead of resolving the complete URL the minute >you close the attribute menu. I'm not sure how HoTMetal is doing against Front Page and its ilk, but that's not really the question. Currently we have a single href attrribute. We must continue to allow that simplicity. URL syntax may not be much good, but it is _not_ going away any time soon. Any multiple attribute solution will be _additional syntax_. If we are going to add syntax, it must enable something that would _could not_ do without that syntax. All the arguments we have had about convenience have not yet shown such an advantage. >The fact that URL definitions using ID locators is more verbose than doing >an entitiy declaration is irrelvant to users. The IDs and associated >declarations will be generated automatically by the editor without user >intervention. The question is whether browser recognition of entity >declarations takes longer than browser resolution of IDs. If the entity >declarations have to be read as part of the DTD I would contend that at >browser level HyTime location addressing may be faster than entity resolution! The code to support the two is _very_ different in size and complexity, and the incremental benefit of adding that complexity is an arguable improvement in the elegance of the markup, and no improvement in expressive power. I'm still completely unconvinced. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ From: lee@sq.com Date: Thu, 16 Jan 97 12:15:04 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: Permitting non-indirect links [HoTMetaL edit URL dialogue!] Martin Bryan wrote: [...] > If you consider the HoTMetal URL creation menu verbose then how come > HoTMetaL is a leader in the field? All I am doing is say store the info > HoTMetaL creates in its separate boxes as separate attributes until such > time as you call the file, instead of resolving the complete URL the minute > you close the attribute menu. I think there's something interesting to note here. I gave a paper about the design of HoTMetaL 1.0 at the World Wide Web conference in Chicago in 1994. There were authors of two other HTML editors giving similar papers. Someone in the audience asked each of us what support they had for editing URLs, and whether the users actually needed to understand the complex syntax of URLs. One said they thought people should just type URLs directly, and as any programmer can do that, it wasn't an issue. One said that they wanted to do something but couldn't see how (I may be oversimlifying here). And I showed the HoTMetaL Edit URL dialogue that we'd built. Some people, very familiar with the syntax, couldn't see why you'd want one. Others, especially the less technical, were delighted. The overall effect of HoTMetaL was that we changed the kind of people who could create web pages -- it wasn't just vi, emacs and notepad users any more. Whether that was good or bad for the web :-), it meant that HoTMetaL spread quickly, and also helped HTML, at a time when a great many PC users weren't sure if it was http://site/name or HTTP:\\SITE\FILE or even why there was a difference. I tell this long anecdote to remind us that similar considerations apply to XML and XML software. Lee .. Date: Fri, 17 Jan 1997 11:42:13 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: (my last word on) Permitting non-indirect links At 3:22 AM 1/17/97, Martin Bryan wrote: >At 12:16 16/1/97 -0500, David G. Durand wrote: >Currently we have a single href attrribute. >>We must continue to allow that simplicity. URL syntax may not be much good, >>but it is _not_ going away any time soon. Any multiple attribute solution >>will be _additional syntax_. If we are going to add syntax, it must enable >>something that would _could not_ do without that syntax. All the arguments >>we have had about convenience have not yet shown such an advantage. > >This is where we fundamentally disagree. The URL syntax does not describe a >"single attribute". It defines a set of components and shows how they can be >concetenated into a single string that must be decomposed on receipt into >the component parts, each of which must be processed separately. The href >attribute is simply a container in which the concatenated parts of a URL are >transmitted. Do not confuse the transmission container with the contents of >the envelope. What I am arguing for, as a devil's advocate, is the adoption >of a cleaner, if slightly more convoluted, design that recognizes the >fundamental differences between the component parts of a URL and allows them >to be managed separately. So you are arguing that we should eliminate the "single URL syntax" altogether? I think that that would be suicide for the levels of HTML compatibility we should strive for (ie. different but familiar-seeming; same low-level options remain almost as easy as they are in HTML). If we change the syntax of simple direct links we will lose >50% of our authoring audience right there. There will be no or few special XML tools until there is a proven market, so that they don't help with _intial_ acceptance. The "take your medicine, it's good for you" marketing approach is not a good one. > What is at question is whether pre-decomposition >would offer any advantages. I'm not certain it does, but I want these points >to be seriously thought about before we go blindly down a route that does >not bring the gains that existing web masters are desperately seeking and >which someone else will provide soon if we do not. Its a question of >marketing. If XML is proveably safer to manage (note I did not say easier) >then it will have a much much better chance of being accepted outside of the >existing SGML community. I think that we have something better: a management technique involving entities that enables such "provably safer" management, and does _not preclude_ the easier and compatible "href" linking-style. We could use locsrc to get the same effect, but the combination of equivalent power, additional verbosity, and an extra incremement of implementation difficulty seems to argue against it. I tend to think that the kind of guarantee that you are asking will appeal more to "the traditional SGML community" than to the webmasters that I've met. People like extra power, but they don't like having to unlearn things they already know (like hrefs). I'm done with this thread. I think we don't need additional syntax to enable the functions you have convinced people would be good; no one else seems to be listening; we agree on the arguments, and on the issues, but disagree on the final solution. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Fri, 17 Jan 1997 09:39:13 -0900 To: Martin Bryan , w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Permitting non-indirect links At 10:48 AM 1/16/97 +0000, Martin Bryan wrote: >Eliot wrote: [...] >>Where the "SOIbase" attribute points to the entity whose on system ID is to >>be prepended to yours. Thus, the effective URL of the chain is >>"http://www.somewhere.com/oii/en/alpha.html". >> >>Comes to the same thing and the semantics of URL interpretation are the >>same, but some might prefer to use entities for this rather than location >>addresses (for example, because they can put the SYSTEM IDs in catalogs). > >For those that don't want to use entities is there any way we can do this by >stringing together attribute values? I'm not sure what you mean by "stringing together attribute values". Do you mean the values of attributes specified on different location address elements (as in David's example) or attributes specified on the same element. If the latter, I'm having a hard time seeing the management benefit, although I could see the benefit in separating out the different semantic components of a URL string (except that, as has been pointed out in the "URL editing dialog" subthread, it may or may not be useful to provide that for a syntax as simple as URLs). There is no HyTime-direct way to say that you want an address to be cobbled together from a variety of attributes on the same element, but as I've been saying with stultifying frequency, you can always define a "query" that will give you the effect, however twisted such an approach might be. If XML Link wanted to include four attributes for decomposing URLs, it could certainly be made understandable to a sufficiently-functional HyTime engine (e.g., one that supported arbitrary SDQL queries or their equivalent). Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Fri, 17 Jan 1997 08:22:57 +0000 To: dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: Permitting non-indirect links At 12:16 16/1/97 -0500, David G. Durand wrote: >I'm not sure how HoTMetal is doing against Front Page and its ilk, but >that's not really the question. Currently we have a single href attrribute. >We must continue to allow that simplicity. URL syntax may not be much good, >but it is _not_ going away any time soon. Any multiple attribute solution >will be _additional syntax_. If we are going to add syntax, it must enable >something that would _could not_ do without that syntax. All the arguments >we have had about convenience have not yet shown such an advantage. This is where we fundamentally disagree. The URL syntax does not describe a "single attribute". It defines a set of components and shows how they can be concetenated into a single string that must be decomposed on receipt into the component parts, each of which must be processed separately. The href attribute is simply a container in which the concatenated parts of a URL are transmitted. Do not confuse the transmission container with the contents of the envelope. What I am arguing for, as a devil's advocate, is the adoption of a cleaner, if slightly more convoluted, design that recognizes the fundamental differences between the component parts of a URL and allows them to be managed separately. >>The fact that URL definitions using ID locators is more verbose than doing >>an entitiy declaration is irrelvant to users. The IDs and associated >>declarations will be generated automatically by the editor without user >>intervention. The question is whether browser recognition of entity >>declarations takes longer than browser resolution of IDs. If the entity >>declarations have to be read as part of the DTD I would contend that at >>browser level HyTime location addressing may be faster than entity resolution! > >The code to support the two is _very_ different in size and complexity, and >the incremental benefit of adding that complexity is an arguable >improvement in the elegance of the markup, and no improvement in expressive >power. I'm still completely unconvinced. I'm sorry, the code to support them has to be built into the system in any case as you have to decompose the URL to be able to handle its component parts when you get them. What is at question is whether pre-decomposition would offer any advantages. I'm not certain it does, but I want these points to be seriously thought about before we go blindly down a route that does not bring the gains that existing web masters are desperately seeking and which someone else will provide soon if we do not. Its a question of marketing. If XML is proveably safer to manage (note I did not say easier) then it will have a much much better chance of being accepted outside of the existing SGML community. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Fri, 17 Jan 1997 21:28:05 +0000 To: w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: Permitting non-indirect links Eliot Kimber wrote: >>For those that don't want to use entities is there any way we can do this by >>stringing together attribute values? > >I'm not sure what you mean by "stringing together attribute values". Do >you mean the values of attributes specified on different location address >elements (as in David's example) or attributes specified on the same >element. If the latter, I'm having a hard time seeing the management >benefit, although I could see the benefit in separating out the different >semantic components of a URL string (except that, as has been pointed out >in the "URL editing dialog" subthread, it may or may not be useful to >provide that for a syntax as simple as URLs). It was the latter. I was wondering that if we chose, for ease of creation/management reasons, to split up the URL definition so that we allowed separate attributes for the component parts we would then stab ourselves in the foot by not being able to use the component parts for addressing. For example, if we then need to address using queries as you suggest the loss in addressing would offset any gain in being able to manage the component parts more simply. What would be nice is there was a clever trick that would allow us to use IDs/entity names/xml-pointers for each of the component parts of a split-up URL, as I suggested earlier with something like: In this case the names point to the location source components strings in the entities/catalog/database without having to create the location ladder in HyTime directly - the location ladder is implicit in the XML attribute sequencing. Its not HyTime, but it is a possible shortcut to building location ladders that might help overcome the reluctance of the XML community to using the full power of HyTime's location source and location ladders. (Eliot: Having written this I came across the new rflocsrc attribute, which means that I may be able to do this and be HyTime compliant after all! Brilliant! Am I right in thinking that rflocsrc can be made to stack so that it handles the chain given above where URL-fragment references URL-file which references URL-path which references URL-DNS. It would really be cool if the URL-file name was the content of the element using the #CONTENT option you have allowed for!!) ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Fri, 17 Jan 1997 21:28:07 +0000 To: w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: (my last word on) Permitting non-indirect links At 11:42 17/1/97 -0500, David G. Durand wrote: >So you are arguing that we should eliminate the "single URL syntax" >altogether? Most definitely not >I think that that would be suicide for the levels of HTML >compatibility we should strive for (ie. different but familiar-seeming; >same low-level options remain almost as easy as they are in HTML). Agreed. What I'm suggesting is that we should add facilities in addition to the ones now available on the web to allow web managers to do what they cannot do with HTML _if they so wish_ or to carry on in the uncontrolled way they currently do if they are happier to work that way. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Fri, 17 Jan 1997 16:32:58 -0900 To: Martin Bryan , w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Permitting non-indirect links At 09:28 PM 1/17/97 +0000, Martin Bryan wrote: >(Eliot: Having written this I came across the new rflocsrc attribute, which >means that I may be able to do this and be HyTime compliant after all! >Brilliant! Am I right in thinking that rflocsrc can be made to stack so that >it handles the chain given above where URL-fragment references URL-file >which references URL-path which references URL-DNS. It would really be cool >if the URL-file name was the content of the element using the #CONTENT >option you have allowed for!!) That's the idea. But don't get too excited--it's only a proposed design and hasn't been approved yet (but I think it's a good idea, at least without having had time to think about the possible implications). Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" From: lee@sq.com Date: Sat, 18 Jan 97 18:24:58 EST To: eliot@isogen.com, mtbryan@sgml.u-net.com, w3c-sgml-wg@www10.w3.org Subject: Re: Permitting non-indirect links Eliot wrote: > There is no HyTime-direct way to say that you want an address to be cobbled > together from a variety of attributes on the same element, [but] > you can always define a "query" that will give you the effect, however > twisted such an approach might be. I for one care not one whit how "twisted" the XML hyperlinking facility appears in HyTime, nor even whether HyTime has to be modified before it can accommodate it. I _do_ care that it be simple and easy to explain. Since there is already a large well-used widely deployed hypertext system in the world, we will have to explain and justify every difference. Many, many. many times, to many people. I see strong reasons to use the existing URL syntax, and to allow for URNs when they settle down. Anything that makes simple links much more complex than Table of contents might as well be forgotten quietly now. Yes, I'd like to see indirection supported -- luckily, you can do this with entities: and store the entity definitions in a separate file. Yes, I'd like to see something like Panorama's "web files" -- a user-managed (or automatically downloaded) way of transporting a set of links and/or annotations -- in a separate ilinkish file. No, I don't want to write anything more complex. As has already been pointed out, a majority of people who use the web, and a majority of people who create HTML document, do not clearly understand the syntax of URLs, but use copy and paste. If you make them split them up just for the sake of a messier link (or cleaner, if you happen to like it), they will make more mistakes, and probably go back to HTML. Existing practice shows the need for simplicity. Lee From: lee@sq.com Date: Sat, 18 Jan 97 18:33:24 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: Permitting non-indirect links > Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK > What is at question is whether pre-decomposition > would offer any advantages. I'm not certain it does, but I want these points > to be seriously thought about [...] It doesn't. Note that a URL is actually a scheme identifier and then an opaque string. Some schemes are names of network protocols (e.g. http, ftp) and some are not (e.g. mailto). How are you going to break down http://www.somesite.xxx.yyy.zz:8086/cgi-bin/pcdocs/introduction.html (there's actually an implied query being run there) ftp://ftp.somewhere:liam:mypssword/~lee/.profile mailto:BITNET:U002097 AT EARC26%gateway5.earn.ac.uk smell:192,304,61,01,97,201 (this is for the perfume industry) when the meaning of *everything* to the right of the colon is determined by the handler for the given URL scheme? The only valid breakdown is type: URL scheme: http opaque string: //www.sq.cm/cgi-bin/pcdocs/introduction.html but this isn't useful. HoTMetaL cheats, and has (or used to have) a config file giving templates for the various schemes. Unless you want to keep a list of several hundred possible schemes and how they break down, with differing attribute sets, I would say that it is a bad idea to try this. Yes, people like the HoTMetaL approach -- but that isn't standardised; we have to update the code every now and again, too, to cope with new kinds of URL. Leave opaque strings as opaque. Lee Date: Sat, 18 Jan 1997 20:26:51 -0600 From: len bullard To: lee@sq.com CC: eliot@isogen.com, mtbryan@sgml.u-net.com, w3c-sgml-wg@www10.w3.org Subject: Re: Permitting non-indirect links lee@sq.com wrote: > > Eliot wrote: > > There is no HyTime-direct way to say that you want an address to be cobbled > > together from a variety of attributes on the same element, [but] > > you can always define a "query" that will give you the effect, however > > twisted such an approach might be. > Existing practice shows the need for simplicity. Consider that there are multiple hub-capable languages on the internet. More are being added. Most support URLs. That is granted. However, things can be more complicated than HTML (a specific application). VRML (another specific application) allows for links with multiple URLs. These are used to declare precedence to the VRML browser for a set of targets. XML is not an application: it as is SGML is a metalanguage. So, while we can always use or recommend application conventions, we still are left with either 1. Define a way to define links (meta) 2. Define the links (application). Decide what the requirements are. len From: Murata Makoto Date: Sun, 19 Jan 1997 16:14:05 +0900 To: gtn@ebt.com (Gavin Nicol) Cc: w3c-sgml-wg@www10.w3.org Subject: Re: Slight change to XMLDecl productions... Gavin Nicol writes: >Currently "S" is defined with ideographic space as a component. As >ideographic space is *not* part of ASCII, I would recommend using a >production other than "S" as the separator in the XMLdecl; something >limited to just space and tabs (though it will be easy for authors in >Japan to make a mistake here, it's probably a reasonable tradeoff). I don't quite understand your point. Could you give a little more details? Makoto Date: Sun, 19 Jan 1997 08:46:54 +0000 To: lee@sq.com, eliot@isogen.com, w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: Permitting non-indirect links At 18:24 18/1/97 EST, lee@sq.com wrote: >If you make them split them up just for the sake of a messier >link (or cleaner, if you happen to like it), they will make more >mistakes, and probably go back to HTML. No-one is suggesting that users need to split up URLs that are copied. What is being suggested is that the system using the copied URLs should be able to split them if it sees advantages in being able to manage links better in a split from. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Sun, 19 Jan 1997 08:46:56 +0000 To: lee@sq.com, w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: Permitting non-indirect links At 18:33 18/1/97 EST, lee@sq.com wrote: >Unless you want to keep a list of several hundred possible schemes >and how they break down, with differing attribute sets, I would >say that it is a bad idea to try this. I would like a generalized mechanism that will allow users to break the addresses into any set they find useful to manage, and specify the order they should be reconstructed in. Eliot has suggested that this should be done via Notations, but this would not work for URLs. Perhaps XML should hard-wire the URL example as it would be the most common one. >Yes, people like the HoTMetaL approach -- but that isn't standardised; >we have to update the code every now and again, too, to cope with new >kinds of URL. > >Leave opaque strings as opaque. Then XML will offer existing HTML users no better mechanism for link management than their already non-existent facilities. Why on earth should they change? ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Sun, 19 Jan 1997 06:28:58 -0500 From: Paul Prescod To: w3c-sgml-wg@www10.w3.org Subject: Re: Permitting non-indirect links Martin Bryan wrote: > Then XML will offer existing HTML users no better mechanism for link > management than their already non-existent facilities. Why on earth should > they change? While I believe that there is merit to your proposal, I do not think it is fair to say that anyone is suggesting that XML link should always be as utterly umanagable as HTML's. Entities, for instance, provide URL component reuse (though not as flexible as your proposed version). XML will probably allow indirectable links. XML will probably allow independant links. In my mind, the benefit to your idea is that, the link "base" can be in a different document instance (as I understand it). Will this have real-world value, though? Paul Prescod Date: 19 Jan 1997 15:12:59 +0000 (GMT) From: Peter Flynn Subject: Re: (my last word on) Permitting non-indirect links To: w3c-sgml-wg@www10.w3.org David Durand writes: I'm done with this thread. I think we don't need additional syntax to enable the functions you have convinced people would be good; no one else seems to be listening; we agree on the arguments, and on the issues, but disagree on the final solution. I'm listening and I agree with David. Priorities as I see them are a. provide the ability for it to be possible to create a well-formed XML instance that can be dealt with by existing HTML browsers (or with very minor mods to allow browser makers to claim some degree of XMLness - it may be important marketing-wise for them to be able to say this); b. provide the ability for conformant XML instances to use much more sophisticated facilities, at the penalty that these will only work with four-wheel browsers. (I don't happen to believe that we need to provide for badly-formed instances.) At some stage soon we are going to need a lucid and explanatory middle-ground document which explains what we are doing (and why XML is A Good Thing) for the consumption of webmasters and webmistresses who don't have the time or knowledge to go through the spec in detail, and it should include an even shorter and even less technical summary for the use of managers who simply want to be persuaded that this is something they need to ask for. ///Peter From: lee@sq.com Date: Sun, 19 Jan 97 13:38:31 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: Permitting non-indirect links > No-one is suggesting that users need to split up URLs that are copied. In the posting to which I responded, there was an example putting different parts of a URL into different attributes... e.g. (I forget the details) > What > is being suggested is that the system using the copied URLs should be able > to split them if it sees advantages in being able to manage links better in > a split from. I think that is very clearly an implementation issue and does not need to be part of the XML specification. Systems cn do whatever they like with XML files! :-) Lee From: lee@sq.com Date: Sun, 19 Jan 97 13:41:57 EST To: lee@sq.com, mtbryan@sgml.u-net.com, w3c-sgml-wg@www10.w3.org Subject: Re: Permitting non-indirect links I had said: > >Leave opaque strings as opaque. Martin replied: > Then XML will offer existing HTML users no better mechanism for link > management than their already non-existent facilities. Why on earth should > they change? I don't see any reasoning here :-) Counterexample; SoftQuad Panorama treats all system identifiers as URLS, with an implied scheme where necessary. But it also supports some HyTime link features, and multiple ways of achieving link indirection. Just because two cars use the same tyres doesn't mean that ther new one can't go faster than the old one. You are free to use entities if you like in XML: This is already more powerful than HTML. Lee To: w3c-sgml-wg@www10.w3.org Subject: Re: Permitting non-indirect links Date: Sun, 19 Jan 1997 12:15:20 -0800 From: Joe English lee@sq.com wrote: > > [Martin Bryan] > > What is at question is whether pre-decomposition > > would offer any advantages. I'm not certain it does, but I want these point > > to be seriously thought about [...] > > It doesn't. > > Note that a URL is actually a scheme identifier and then an opaque string. > Some schemes are names of network protocols (e.g. http, ftp) and some are > not (e.g. mailto). > [...] > The only valid breakdown is > type: URL > scheme: http > opaque string: //www.sq.cm/cgi-bin/pcdocs/introduction.html However, for some schemes the selector is not _completely_ opaque. For any scheme that uses the "generic-RL" format defined in RFC 1808 "Relative Uniform Resource Locators" (including http:, ftp:, file:, and, I think, gopher:), user agents can decompose the selector into network location, path, parameters, and query components; and the path component can be further decomposed by splitting it at each '/' character. I think that the Formal System Identifier definition was also designed to support relative locations in a way that's compatible with relative URLs (viz. the SOIBase attribute). Martin, would it serve your needs if instead of providing a mechanism for specifying URL components separately, XML allowed system identifiers to be specified relative to some base identifier, a la FSIs or the HTML3/HTML+ "base" attribute? --Joe English jenglish@crl.com Date: Mon, 20 Jan 1997 08:09:58 +0000 To: w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: Permitting non-indirect links At 12:15 19/1/97 -0800, Joe English wrote: >Martin, would it serve your needs if instead of providing a >mechanism for specifying URL components separately, XML >allowed system identifiers to be specified relative to >some base identifier, a la FSIs or the HTML3/HTML+ "base" >attribute? The HTML Base option works fine for links to locally owned data sets. These are relatively well catered for as far as shortcuts are concerned. Local links are also fairly easy to manage - you know their sources and their likely update cycles, or can arrange to track them. What are much more difficult to manage, because you can get no knowledge of them, are pointers to external data sources. The example I quoted earlier was NASA's decision to move the site for the Planatery Data System information, which required all links to the existing data set to be changed without being able to warn linkers of the change. The SGML Formal System Identifier use of SOIbase to identify the system source of the relevant file is a vast improvement here, but if it is used as specified in the standard you still have to change every entity reference pointing to the site when the site or directory moves. One way to alleviate this is to replace the SOIbase with a pointer to a HyTime location address. Now you only have one point at which you manage one address for each unique path at the site. You still have problems if the whole site moves. What I was trying to get people to look at is what it takes to manage web links, which introduce a special set of problems. The problem is that the time for directory name changes is shorter than that for site name changes, and that the two overlap. (PDS changed site without changing all of its directory structure, but did introduce some new structures.) The only way I can see to alleviate this is to set up location ladders so that you can manage the site name independently from the directory name. For XML I was suggesting that these names be separated at capture time so that we could set up implicit location ladders rather than have to use the full power of HyTime. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Mon, 20 Jan 1997 08:19:53 -0800 To: w3c-sgml-wg@www10.w3.org From: Ralph Ferris Subject: Re: Permitting non-indirect links At 06:33 PM 1/18/97 EST, Lee wrote: >The only valid breakdown is > type: URL > scheme: http > opaque string: //www.sq.cm/cgi-bin/pcdocs/introduction.html > >but this isn't useful. HoTMetaL cheats, and has (or used to have) a >config file giving templates for the various schemes. Actually, I did find a use for this, as I pointed out in a message I sent to the Davenport group almost two years ago. It was written at the height of the "HTML is all frenzy"; I was looking for a way to invert the process, using "real" SGML tools to reach the Web, rather than the other way around. I repeat the message here verbatim, if only for historical interest. --Ralph **************************************************************************** ********* Date: Wed, 1 Feb 1995 19:44:42 -0500 From: Ralph Ferris To: Multiple recipients of list Subject: Creating a non-HTML ``Home Page'' Hi Everyone: I've been experimenting with Author/Editor's support for entities and notations to see if I could use them to build a ``home page'' without HTML. What I found is that by defining Mosaic as a ``notation'' and assigning a URL to an entity, Mosaic can be launched with the URL as an argument from within Author/Editor. In other words, you can create a document in some DTD other than HTML (I used DocBook) and use it as a ``home page'' from within Author/Editor. For those of us who have always oppossed the embedding of HTML anchors/URLS within documents and advocated the use of entities instead, this experiment shows how it can be done with an existing product. Note by the way that you can't define an entity to be http://www.---; the entity manager will interpret the ``http:'' portion as the name of a file it can't find. The following instructions show what to do. In a broader sense, this experiment may also show something else: we don't need to take an ``HTML/Mosaic-centric'' view of the Web. We can start with whatever DTD is required and go out to the Web as needed. In fact, by defining other notations to invoke local scripts, other tools can be accessed as needed. In this scenario, Web browsers can be among these tools, rather than being the central tool(s) from which others are invoked. ********************************************************************** Launching Mosaic from Author/Editor on UNIX Systems 1. Defining Mosaic as a Notation Mosaic can be launched from within an Author/Editor document if Mosaic is first defined as a NOTATION. To do this, add a NOTATION declaration to DocBook and then compile the DTD with the new entry using RulesBuilder. (A quick work-around that doesn't require modifying DocBook is to use any of the existing notations in DocBook that you aren't already using. For example, if you aren't using TIFF, you can define TIFF as the notation that invokes Mosaic.) After you've entered Mosaic as a NOTATION in DocBook and recompiled, use the Notation pull-down menu to define the actions you want taken when the entity is selected: o Select ``Edit Notation Action's" o Select ``Mosaic'' from the list of ``Notation Names.'' o Enter the name or alias of the Mosaic executable, followed by ``http:%system;'' entry, e.g., xmosaic http:%system o From "Action Class", select "UNIX Launch." o Select ``New'' to register the notation. 2. Defining Entities After registering Mosaic as a NOTATION with Author/Editor, you can define figure entities that will invoke URLs. For example, to access the DSSSL-lite write-up by James Clark, use the Entities pull-down menu as follows: o Select "Edit Figure Entities" o Enter //www.jclark.com/dsssl/lite.html as the File Name. o Select "Notation" as the Content Type. o Select Mosaic as the Figure Type 3. Using Entities in Mosaic Notation In Author/Editor, entities are inserted from ``Insert Entity'' under the Entities pull-down menu. To invoke the action you have assigned to the entity, either double click on it or select it and invoke it from ``Perform Action'' under the Notation pull-down menu. In this case the action will be to launch Mosaic with the URL you've assigned to the entity as an argument. Date: Mon, 20 Jan 1997 14:36:06 -0600 From: Len Bullard To: w3c-sgml-wg@www10.w3.org Subject: Non-HTML URL Examples As the use of the URL in XML is being debated, it is worth noting some relevant facts: 1. The use of the URL in XML is not bounded by the use of the URL in HTML. It is bounded by the RFCs. No one disputes this although the argument has been presented several times that getting to far beyond HTML's use may impair XML marketability. That argument may be one of the reasons some mistakenly believe XML is a replacement for HTML. In fact, as argued next, XML can only define the way in which an XML designer expresses the URL use in the design. 2. XML is a metalanguage. HTML is an application. This is worth noting because as a metalanguage, an XML designer might choose to break up or use a URL in many ways not anticipated by other application designers. While this makes life hard for the XML software designer, it it nonetheless a fact of life for metalanguage applications. It may impair the interoperability of XML applications in the same way current SGML applications do not interoperate, that is, without a transform, it is meaningless to inline a TEI document into a MIL-PRF-87269 database. 3. If XML is indeed a metalanguage, it's URL and link definitions should be capable of declaring the following VRML examples. Whether this is *worth* declaring is an application issue. The point is, in the HyTime or TEI choices, the winner should be capable of declaring the following examples. Here are examples from VRML. First, VRML defines a URL as a field type. Specifically: url [ ] is an exposedField of type MFString An exposedField has an implied eventIn and eventOut (think of it as an input and output jack) to connect ROUTEs. There are several exposedFields in VRML and more can be added by PROTOtypes. An MF string is a space or comma delimited set of characters, typically, options. While the URL itself is defined by the RFC as has been described in other posts, the VRML application only cares that it is a string. This allows the semantics to be applied per node type. Thus: Inline { url ["myworld.wrl"] } where an inline file resembles an SGML subdoc in that it is an encapsulated namespace. A defined name is not recognized if instanced by a USE within the inlining file. A defined name within the inlining file is not recognized by an inlined file. The URL within the Inline can contain multiple URL strings that define a prioritized list of places to find the URL target. This list is used to provide a high-to-low redundant backup (e.g, local disk, local net, WAN, Web) for each reference. If a URL is resolved, it returns nodes which are children of the group parent of the Inline node. If empty, no action is taken (default). Implementations can use other rules such as using one URL to read high priority/high bandwidth, while using a lower priority on a slower line. The URL list can be changed using the set_url eventIn implied by the definition of the URL as an exposedField. Anchor { url [ ] parameter [ ] where the URL field is also an exposedField of type MFString and a prioritized list. It is the parameter field (also, an exposedField MFString) which contains additional strings used by the browser when a target page is read. These fields depend on the browser for functionality. The default is empty. The #syntax we are used to CAN be appended to the URL string, but it is restricted to name a Viewpoint in the target file. As in HTML, using ONLY #viewpoint is a camera view in the local file. Set_parameter eventIns are available because it is an exposedField. Last but most revealing is the following Script { url "myscript.js" or Script { url "javascript: function set_position(pos, time) { position = pos; } " field... eventIn eventOut } where a Script node can use the actual text of the script as long as the script notation is defined as shown, eg., javascript: for that language, etc. VRML does not REQUIRE support for any language. It only requires that the script be indicated as shown. These URL examples are provided in contrast to the use of HTML anchors as examples of common practice and to note that alternatives are used in common Internet languages, are learnable, and are being used everyday. Len Bullard Lockheed Martin C2 Integration Systems From: lee@sq.com Date: Mon, 20 Jan 97 16:26:30 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: Non-HTML URL Examples Len wrote: > 1. The use of the URL in XML is not bounded by the > use of the URL in HTML. It is bounded by the RFCs. > No one disputes this although the argument has > been presented several times that getting to > far beyond HTML's use may impair XML marketability. Hmm, I haven't heard that argument, although I know that you thought I was making it at one point. I certainly wasn't trying to! I _did_ say that we will be asked to explain why we did things differently from HTML, by a great many people who are using HTML and who start to consider XML. Where there are satisfactory answers (e.g. the improvements in comment syntax, or the new syntax for EMPTY elements) I don't think there will be any difficulty at all. If we were to adopt a syntax that was different without clear and adequate reason, I do see that it might be an impediment, not because XML must replace HTML, but because people coming to XML for _any_ reason are likely to be familiar with HTML. Where XML offers _more_ functionality than HTML, obviously this isn't an issue. Finally, note that some of the RFCs are written in the knowledge of others. For example, we agreed to omit many things from RFC1866 because they were covered elsewhere -- for example, MIME parameters on URLS in HTML, or the meaning of http-equiv fields which are covered by the HTTP spec. So the meaning of URLs (for example) has to be considered as deriving froma number of RFCs, not just one. You know that already, but it is worth reminding the list. Lee Date: Mon, 20 Jan 1997 15:36:16 -0600 From: Len Bullard To: lee@sq.com CC: w3c-sgml-wg@www10.w3.org Subject: Re: Non-HTML URL Examples lee@sq.com wrote: > > Len wrote: > > > 1. The use of the URL in XML is not bounded by the > > use of the URL in HTML. It is bounded by the RFCs. > > No one disputes this although the argument has > > been presented several times that getting to > > far beyond HTML's use may impair XML marketability. > > Hmm, I haven't heard that argument, although I know that you > thought I was making it at one point. I certainly wasn't trying to! Yes. Acknowledged. This wasn't posted at you, but to be clear because even if not explicit, from many postings, it is easy to imply even where the implication is mistaken. HTML is ubiquitous, but not limiting. I expect to be using it for a long time as I am a Microsoft user and developer and they are on public record for saying "we recognize the HTML is the backbone of the Internet". Since I don't choose the bricks for the house, I can't complain about the mortar. > I _did_ say that we will be asked to explain why we did things > differently from HTML, by a great many people who are using HTML and > who start to consider XML. Where there are satisfactory answers (e.g. > the improvements in comment syntax, or the new syntax for EMPTY elements) > I don't think there will be any difficulty at all. If we were to adopt > a syntax that was different without clear and adequate reason, I do > see that it might be an impediment, not because XML must replace HTML, > but because people coming to XML for _any_ reason are likely to be familiar > with HTML. True, but they are also likely to be familiar with SGML and IMO, that is where many early XML adopters are likely to come from. To me, this means that Where XML offers _more_ functionality than HTML, obviously this isn't > an issue. True. When selling it, that will be Item 1 at the top in 24 point Arial. > Finally, note that some of the RFCs are written in the knowledge of others. > For example, we agreed to omit many things from RFC1866 because they > were covered elsewhere -- for example, MIME parameters on URLS in HTML, > or the meaning of http-equiv fields which are covered by the HTTP spec. This is absolutely the case. I'm going blind reading them but I was already going blind. Age.... :-) > So the meaning of URLs (for example) has to be considered as deriving > from a number of RFCs, not just one. You know that already, but it > is worth reminding the list. Yes. Without knowing the full range of implications of the URL, MIME, the http protocols, etc., it is not possible to know where baby and bathwater part company. len Date: Mon, 20 Jan 1997 16:21:23 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Archives updated SGML WG mail for the first half of January has been extracted from my own mail and put into the following files: ftp://sunsite.unc.edu/pub/sun-info/standards/xml/wg/9701a.gz ftp://sunsite.unc.edu/pub/sun-info/standards/xml/wg/9701a.zip These files are also available by HTTP. I cannot guarantee that I received everything sent to the list, but these files contain everything that I did receive. The W3C archive for this group is publicly visible, so you are free share these with anyone who might be interested in our discussions. Jon Date: Tue, 21 Jan 1997 11:42:30 +0000 To: w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Multi-headed indirect links Given that nobody other than myself seems to be interested in indirect links, and that for direct links the only form that is getting any support is that of an opaque string, I ask myself whether the XML community has any interest in having multiheaded links? If so: What form would a multiheaded link take? A concatenated set of opaque strings embedded at the reference point in the text? If I want to point to a number of points in the same document do I have to repeat the full location information for each one? If I want to reference the same set of points at another point in the document do I have to repeat all the information for each link at that point as well? If there is some mechanism for using a short form of addressing how will this work when my multiheaded link needs to point to 6 places in this document and 6 places in that document? How can I say I want this bit of the text linked to the same points that that bit of text in this document and that bit of text in that document point to? ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Tue, 21 Jan 1997 07:26:29 -0600 From: len bullard To: Martin Bryan CC: w3c-sgml-wg@www10.w3.org Subject: Re: Multi-headed indirect links Martin Bryan wrote: > > Given that nobody other than myself seems to be interested in indirect > links, and that for direct links the only form that is getting any support > is that of an opaque string, I ask myself whether the XML community has any > interest in having multiheaded links? I thought everyone was interested in multiheaded links (if I understand that correctly). What I notice is that no design has emerged from the discussion. I see the same standoff that has existed between HyTime and TEI proponents for a number of years now. Given the schedule set forth, this is disappointing. Len Bullard Date: Tue, 21 Jan 1997 09:39:26 -0500 To: Michael Sperberg-McQueen , W3C SGML Working Group From: davep@acm.org (Dave Peterson) Subject: Re: questions on XML sgml decl's charsets At 6:35 PM 1/13/97, Michael Sperberg-McQueen wrote: > What was overlooked in the heat of the >moment (this was getting on toward the absolute deadline) was that the >machine in question was an ASCII machine, not a Unicode machine; of >course the 646 declaration was required for processing. But the >canonical SGML declaration should use Unicode. If all XML uses the same SGML declaration, and that declaration specifies ISO 10646, then all XML machines must be ISO 10646 machines. Or are we planning to allow different XML documents to have different SGML character sets? Note that specifying Unicode as the "document character set" (1) specifies what character numbers in numerical character references are to be interpreted as what characters, and (2) specifies what characters (however represented in the system character representation) are legal in the document. The interesting question is: How do you deal with a legal SGML character that your system has no internal representation for? I haven't thought that one through. In some cases, I suspect your entity manager could convert the character as stored in the storage representation into a numeric character reference. But that can break down if the character is used in markup. Hmmm.... ;-) Dave Peterson SGMLWorks! davep@acm.org Date: Tue, 21 Jan 1997 08:54:53 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Multi-headed indirect links At 07:26 AM 1/21/97 -0600, len bullard wrote: >Martin Bryan wrote: >> >> Given that nobody other than myself seems to be interested in indirect >> links, and that for direct links the only form that is getting any support >> is that of an opaque string, I ask myself whether the XML community has any >> interest in having multiheaded links? > >I thought everyone was interested in multiheaded links (if I understand >that correctly). What I notice is that no design has emerged from >the discussion. I see the same standoff that has existed between >HyTime and TEI proponents for a number of years now. This is simply not in any way true. The ERB is well under way in adapting my stickman proposal into a formal first draft of the XML Link discussion. This proposal (the only complete one provided by anyone in this discussion) includes the use of both URLs and TEI extended pointers. I trust Tim and Steve to do an excellent job of creating a short, readable, and complete design that satisfies the requirements expressed in these discussions, including the needs for both simplicity and convenience and sophistication and flexibility. At least within the ERB, the general design approach appears to be remarkably uncontroversial. As I have tried to make clear on any number of occasions, *there is no inherent conflict between HyTime and the TEI specification*. The two are quite synergistic: HyTime provides a general framework for structuring hypermedia and TEI provides additional structuring and descriptive semantics, as well as a very useful addressing notation that is well suited to the intended XML audience. And remember that nothing in the XML spec will *preclude* the use of other mechanisms. All the XML link spec will do is define a set of *required* semantics that all XML processors should provide. But if you want to do things that the XML link spec doesn't account for (like use additional HyTime facilities or SDQL queries or whatever) you're certainly free to. With the HyTime TC, it will, in all likelihood, be possible to define the *current* TEI design, in its entirety, as a conforming HyTime application without the need to modify anything about the design itself. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Tue, 21 Jan 1997 10:07:55 -0500 From: gtn@ebt.com (Gavin Nicol) To: murata@apsdc.ksp.fujixerox.co.jp CC: w3c-sgml-wg@www10.w3.org Subject: Re: Slight change to XMLDecl productions... >>Currently "S" is defined with ideographic space as a component. As >>ideographic space is *not* part of ASCII, I would recommend using a >>production other than "S" as the separator in the XMLdecl; something >>limited to just space and tabs (though it will be easy for authors in >>Japan to make a mistake here, it's probably a reasonable tradeoff). > >I don't quite understand your point. Could you give a little more details? Sure. We don't want to allow zenkaku space in the header because it will complicate parsing of the header, though this will make it easier for Japanese users to make illegal XML files. I have seen many Japanese users accidentally put zenkaku space into places where it was illegal according to the SGML declaration they were using. They got many erros that were *hard* for them to understand. -- BTW. How is KSP? I used to work there a few years ago on the 6th floor... Date: Tue, 21 Jan 1997 09:03:28 -0600 From: Len Bullard To: "W. Eliot Kimber" CC: w3c-sgml-wg@www10.w3.org Subject: Re: Multi-headed indirect links W. Eliot Kimber wrote: > > At 07:26 AM 1/21/97 -0600, len bullard wrote: > >Martin Bryan wrote: > >> > >> Given that nobody other than myself seems to be interested in indirect > >> links, and that for direct links the only form that is getting any support > >> is that of an opaque string, I ask myself whether the XML community has any > >> interest in having multiheaded links? > > > >I thought everyone was interested in multiheaded links (if I understand > >that correctly). What I notice is that no design has emerged from > >the discussion. I see the same standoff that has existed between > >HyTime and TEI proponents for a number of years now. > > This is simply not in any way true. The ERB is well under way in adapting > my stickman proposal into a formal first draft of the XML Link discussion. You could have fooled me. All we see on the list is the squabble, not the work underway, which I suppose we all sanction once presented. Not a good way to run a list, Eliot. Not at all. > This proposal (the only complete one provided by anyone in this discussion) That has been noted before by me. > includes the use of both URLs and TEI extended pointers. I trust Tim and > Steve to do an excellent job of creating a short, readable, and complete > design that satisfies the requirements expressed in these discussions, > including the needs for both simplicity and convenience and sophistication > and flexibility. At least within the ERB, the general design approach > appears to be remarkably uncontroversial. It's a pity that doesn't become more apparent to the list members who are not members of the ERB. A more open process is wanted and needed. > As I have tried to make clear on any number of occasions, *there is no > inherent conflict between HyTime and the TEI specification*. I did not say there was. I have said this does not appear to be the case. > But if you want to do things that the XML link spec doesn't > account for (like use additional HyTime facilities or SDQL queries or > whatever) you're certainly free to. You are putting words in my mouth. It is already crowded in there. > With the HyTime TC, it will, in all likelihood, be possible to define the > *current* TEI design, in its entirety, as a conforming HyTime application > without the need to modify anything about the design itself. Great. Put up a draft of a design we can all read and contribute to. Otherwise, shut down this list, open a company, sell a product and compete with it. Len Bullard Date: Tue, 21 Jan 1997 09:42:02 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Multi-headed indirect links At 09:03 AM 1/21/97 -0600, Len Bullard wrote: >W. Eliot Kimber wrote: >> This is simply not in any way true. The ERB is well under way in adapting >> my stickman proposal into a formal first draft of the XML Link discussion. > >You could have fooled me. All we see on the list is the squabble, >not the work underway, which I suppose we all sanction once >presented. Not a good way to run a list, Eliot. Not at all. This work only started as of last Wednesday's meeting, following the holiday hiatus when the ERB could not meet. I don't know what the editors' schedule is, but I would expect to see a draft pretty soon. My proposal has been out and available for a couple of weeks now, yet there's been very little direct comment it on it here in this list, which surprises me. I expected to see either a counter proposal or some comment on the proposal itself. Given that this was a proposal by a member of the ERB and that, in the absence of any other proposal it would almost certainly be taken as the base for any ERB-defined design, I don't see how the process could be any more open at this point. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Tue, 21 Jan 1997 11:12:36 -0400 To: "W. Eliot Kimber" From: murray@spyglass.com (Murray Altheim) Subject: Re: Multi-headed indirect links Cc: w3c-sgml-wg@www10.w3.org "W. Eliot Kimber" writes: >At 07:26 AM 1/21/97 -0600, len bullard wrote: >>Martin Bryan wrote: >>> >>> Given that nobody other than myself seems to be interested in indirect >>> links, and that for direct links the only form that is getting any support >>> is that of an opaque string, I ask myself whether the XML community has any >>> interest in having multiheaded links? >> >>I thought everyone was interested in multiheaded links (if I understand >>that correctly). What I notice is that no design has emerged from >>the discussion. I see the same standoff that has existed between >>HyTime and TEI proponents for a number of years now. > >This is simply not in any way true. The ERB is well under way in adapting >my stickman proposal into a formal first draft of the XML Link discussion. >This proposal (the only complete one provided by anyone in this discussion) >includes the use of both URLs and TEI extended pointers. I trust Tim and >Steve to do an excellent job of creating a short, readable, and complete >design that satisfies the requirements expressed in these discussions, >including the needs for both simplicity and convenience and sophistication >and flexibility. At least within the ERB, the general design approach >appears to be remarkably uncontroversial. Why can't this design be part of the general discussion (such as your stickman proposal) rather than a ERB proposal. This discussion has gone on a long time to now have the ERB make a draft proposal. Do we really have two groups operating independently here? >As I have tried to make clear on any number of occasions, *there is no >inherent conflict between HyTime and the TEI specification*. The two are >quite synergistic: HyTime provides a general framework for structuring >hypermedia and TEI provides additional structuring and descriptive >semantics, as well as a very useful addressing notation that is well suited >to the intended XML audience. [...] I'd almost responded to Len's message when yours came in, and I was about to remark that after reading through the materials I've either been able to gather or have been sent to me by you and others, I found that much of the documentation on HyTime to be frankly beyond me, while the TEI pointer specification seemed to make almost immediate sense. This may be one of those left-brain/right-brain things, but whatever conflict has been occurring in the dozens of messages, it's been damnedly difficult to follow, as I'm sure many of us will agree. Hearing that there is no essential conflict between HyTime and TEI makes me feel quite a bit better, but I don't understand why there has been such a longstanding conflict over this issue if the solution can be written by Tim and Steve so readily. From my standpoint the solution as you describe it sounds great but the process by which we get to a draft proposal seems rather opaque. >With the HyTime TC, it will, in all likelihood, be possible to define the >*current* TEI design, in its entirety, as a conforming HyTime application >without the need to modify anything about the design itself. Does this mean the XML ERB is planning to encompass the entire TEI link guidelines, with all of the P3 features? Isn't that much more than a minimal specification? It seems that XML ought to specify those parts of the HyTime and TEI grammars that are required of a minimal (or at least typical) XML application, not necessarily the extended pointer syntax, regex matching, etc. Can you give us an indication of how far into the more 'arcane' parts of HyTime and TEI will the proposed XML link specification go? I certainly like much of features I see, but it seems like a complete implementation would be overkill for XML. This of course goes back to the argument over XML being SGML-- or HTML++. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." Date: Tue, 21 Jan 1997 09:52:10 -0600 From: Len Bullard To: "W. Eliot Kimber" CC: w3c-sgml-wg@www10.w3.org Subject: Re: Multi-headed indirect links W. Eliot Kimber wrote: > > This work only started as of last Wednesday's meeting, following the > holiday hiatus when the ERB could not meet. I don't know what the editors' > schedule is, but I would expect to see a draft pretty soon. That is good news. I look forward to it. > My proposal has been out and available for a couple of weeks now, yet > there's been very little direct comment it on it here in this list, which > surprises me. It surprised me. I also expected either a counter proposal or a point for point analysis. On the other hand, what I saw there looked quite reasonable. The issue that seemed to be indirectly alluded to is the amount of syntax required for simple links. But I expected the proposal or debate from the list principals: aka, the ERB. > I expected to see either a counter proposal or some comment > on the proposal itself. Given that this was a proposal by a member of the > ERB and that, in the absence of any other proposal it would almost > certainly be taken as the base for any ERB-defined design, I don't see how > the process could be any more open at this point. That is the point. You can't see it. Scary. Nothing is certain. Because there was no formal "proposal submitted by E. Kimber on (date) has been adopted as the basis for the first draft etc.", no one knows whether they should focus on it, or wait for the next proposal. There is no "certainty" without such an announcement of intent. We cannot see or assume much about the ERB's business. Simply have Jon or whoever make such an announcement, and have the ERB members conduct debate in the open. That is an open process. That is a fundamental of list community design: open debate by the principals. We are not a chorus. Len Bullard Date: Tue, 21 Jan 1997 10:22:19 -0600 From: Len Bullard To: Murray Altheim CC: "W. Eliot Kimber" , w3c-sgml-wg@www10.w3.org Subject: Re: Multi-headed indirect links Murray Altheim wrote: > I'd almost responded to Len's message when yours came in, and I was about > to remark that after reading through the materials I've either been able to > gather or have been sent to me by you and others, I found that much of the > documentation on HyTime to be frankly beyond me, while the TEI pointer > specification seemed to make almost immediate sense. This may be one of > those left-brain/right-brain things, but whatever conflict has been > occurring in the dozens of messages, it's been damnedly difficult to > follow, as I'm sure many of us will agree. I think the lack of news, and the difficulty of the debate is what I am also frustrated with. This is not meant to be divisive, but because so many of us have so many projects, and now, a network that never sleeps, we need something that focuses our attention. Eliot's proposal was the only one posted. We can all focus on that, but because we don't know in a given period, what the ERB is focused on, we only thrash. The problem is, some of us are implementing and were already doing that before this started. Now we want to do the *right thing* and include XML support in our SGML Internet systems. So, it is highly frustrating to work in a group in which, not true but apparently, we wait until the principals agree before we know what it is we must sanction, implement or critique. The XML syntax decisions are easy compared to the hypermedia issues, so we are patient. > Hearing that there is no essential conflict between HyTime and TEI makes me > feel quite a bit better, but I don't understand why there has been such a > longstanding conflict over this issue if the solution can be written by Tim > and Steve so readily. Nor I. I can only surmise like most of America, we all shut down about Dec 22 and open back up about Jan 6. > From my standpoint the solution as you describe it > sounds great but the process by which we get to a draft proposal seems > rather opaque. Yep. It's like a "trust me, the scheme handles it all" system. Opaqueness is good for software and bad for human communication. This isn't aimed at anyone in particular, and certainly not Eliot who has made his proposal on the list and in the best spririt of cooperation. len Date: Tue, 21 Jan 1997 12:43:15 -0500 To: Martin Bryan , w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Multi-headed indirect links At 6:42 AM 1/21/97, Martin Bryan wrote: >Given that nobody other than myself seems to be interested in indirect >links, and that for direct links the only form that is getting any support >is that of an opaque string, I wanted to be quiet, but this is a gross misrepresentation of the state of affairs. The claim is that you have a syntax (entity references) that will give you the indirection that you want. While it's not elegant (it's actually kinda yucky), You have not presented anything that you can do with one syntax that you cannot do with the other. The issue of the locsrc is a different one, but if we can include an equivalent of the "BASE" attribute (and I think we should), then we can do the entitized equivalent of locsrc without the additional implementation overhead of locsrc. You may not be winning the argument about syntax, but I've seen no-one dismiss your concerns about enabling link management (by _some_ mechanism). >I ask myself whether the XML community has any >interest in having multiheaded links? If so: As Eliot and Len pointed out, this has not been in significant question for quite some time. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Tue, 21 Jan 1997 12:43:09 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: proposal process I must say that I'm sympathetic to Len in his comments on process, in contradistinction to the last time this kind of debate came up. While I have not put forth a "final solution" proposal, I've made several concrete proposals (including required architectural forms, suggested XML BOS algorithms, and terminology). Aside from the continuing arguments over design principles, I've enver gotten any reaction or feedback on any of these proposals. I've been waiting for the ERB to post a list of "design decision queries", as they did with XML, once they felt that the discussion had brought the issues out, and decisions were to be made. I find that it's very hard to try to make architectural or design suggestions in a final proposal, because so many of the tradeoffs and discussions have already happened by the time such a proposal is ready for even a preliminary presentation. This is one reason that I've not dealt with Eliot's proposal in depth or made an all-in-one counter proposal. I think that it is a bit premature to have such proposals. I also am not paid to do this (or paid at allfor that matter!), and I can't take a day and a half just to write something that _should_ be discarded. If the ERB propagates it working decisions in the form of a complete preliminary proposal before we have a directed design-decision by design-decision discussion, I predict that the final result will be strongly determined by the initial proposal. This may be good or bad, but it is likely to happen. Like a lot of other people here, I've got other things that are supposed to take a higher priority than XML, and I let the email traffic eat more time than I have, but crunching through a long draft line-by-line makes it much harder to fit into the schedule, than having an issue-by-issue discussion where you need not even talk about issues not of interest. Believe it or not, there are issues that I don't hold forth on! So I would ask that we get either a list of queries, or at least regular updates on decisions taken, so that we can try to have them reversed, if possible, even though that is a much harder process for everyone given that the ERB suffers the weariness of revisiting the "final" decision on issues multiple times. I think there is also strong inertia once a decision is taken, regardless of the quality of that decision -- It's more work to change your mind that to make it up in the first place. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Tue, 21 Jan 97 11:36:43 CST From: Michael Sperberg-McQueen Subject: Re: questions on XML sgml decl's charsets To: W3C SGML Working Group On Tue, 21 Jan 1997 09:39:26 -0500 Dave Peterson said: >If all XML uses the same SGML declaration, and that declaration >specifies ISO 10646, then all XML machines must be ISO 10646 machines. >Or are we planning to allow different XML documents to have different >SGML character sets? The spec says "The specific SGML declaration needed to enable SGML systems to process XML documents will vary from document to document" depending on the character encoding of the document's entities. It may also vary with the SGML system's understanding and implementation of 8879's rules for character handling, which seem to give rise to wildly varying interpretations. >The interesting question is: How do you deal with a legal SGML character >that your system has no internal representation for? I haven't thought >that one through. In some cases, I suspect your entity manager could >convert the character as stored in the storage representation into a >numeric character reference. But that can break down if the character >is used in markup. Hmmm.... ;-) Systems with no internal representation for strings of 16 and 32 bits would appear not to be capable of handling XML. Are there any such systems? N.B. whether they think the 16-bit string is a 'character' is a separate issue. Internal representation just means you can read it, store it, and write it without information loss. It does not mean you can display or print it. The unicode standard has what seems to me a good discussion of fallback behaviors in such conditions. -C. M. Sperberg-McQueen Date: Tue, 21 Jan 1997 11:33:57 -0600 From: Len Bullard To: "David G. Durand" CC: w3c-sgml-wg@www10.w3.org Subject: Re: proposal process David G. Durand wrote: > > I must say that I'm sympathetic to Len in his comments on process, in > contradistinction to the last time this kind of debate came up. Does this mean I can take this "A" off my chest now? It really clashes with my hobnailed boots. > I think there is also strong inertia once a decision is > taken, regardless of the quality of that decision -- It's more work to > change your mind that to make it up in the first place. Yes. And harder to convince the programmers to rewrite what they put to bed last week, particularly if they are under ISO 9000 covers. len From: Paul Prescod Subject: Re: Multi-headed indirect links To: mtbryan@sgml.u-net.com (Martin Bryan) Date: Tue, 21 Jan 1997 12:59:22 -0500 (EST) Cc: w3c-sgml-wg@www10.w3.org > Given that nobody other than myself seems to be interested in indirect > links, and that for direct links the only form that is getting any support > is that of an opaque string, I think that it is important to make the distinction between indirect links and indirect link *components*. An indirect link is just a link which points to a link, which points to a link, which points to an addressable object. You have proposed a mechanism for link components, for "roping together" address components from different parts of a document so that one component can change without others breaking. We all agree this is a good idea, but are not sure if it belongs in XML. I wonder if it can't be accomplished as a particular semantic of regular indirect links. Instead of "go to this link and then follow it", it would be "go to this link and then prepend it to the existing one and follow the new link." Paul Prescod Date: Tue, 21 Jan 1997 13:36:42 -0500 From: gtn@ebt.com (Gavin Nicol) To: davep@acm.org CC: U35395@UICVM.UIC.EDU, w3c-sgml-wg@www10.w3.org Subject: Re: questions on XML sgml decl's charsets >If all XML uses the same SGML declaration, and that declaration specifies >ISO 10646, then all XML machines must be ISO 10646 machines. Or are >we planning to allow different XML documents to have different SGML >character sets? The character repertiore is fixed, though we are allowing different coded encoding as input, which are to be translated using the appropriate BCTF/decoder into a set of bit combinations. >Note that specifying Unicode as the "document character set" (1) specifies >what character numbers in numerical character references are to be >interpreted as what characters, and (2) specifies what characters (however >represented in the system character representation) are legal in the >document. Yes. >The interesting question is: How do you deal with a legal SGML character >that your system has no internal representation for? I haven't thought >that one through. In some cases, I suspect your entity manager could >convert the character as stored in the storage representation into a >numeric character reference. But that can break down if the character >is used in markup. Hmmm.... ;-) SGML is silent on this issue, I believe (we went through this for HTML, and I invoked this silence as a way for saying older browsers would be conformant with the HTML I18N draft). I think we could make this a reportable error (not a fatal error). A more interesting question is what to do with characters that do not appear within the character repertoire we have defined... Date: Tue, 21 Jan 1997 13:43:17 -0500 From: gtn@ebt.com (Gavin Nicol) To: cbullard@hiwaay.net CC: eliot@isogen.com, w3c-sgml-wg@www10.w3.org Subject: Re: Multi-headed indirect links >> At least within the ERB, the general design approach >> appears to be remarkably uncontroversial. > >It's a pity that doesn't become more apparent to the list members who >are not members of the ERB. A more open process is wanted and needed. I agree at least partly with this sentiment. One reason for a limited WG mailing list is to avoid the noise caused by ignorance (ie. let's not repeat HTML-WG). I think both Len and I remember the VRML-VAG.... From: "Christopher R. Maden" Date: Tue, 21 Jan 1997 18:36:36 GMT To: w3c-sgml-wg@www10.w3.org Subject: Re: questions on XML sgml decl's charsets [Michael Sperberg-McQueen] > The spec says "The specific SGML declaration needed to enable SGML > systems to process XML documents will vary from document to > document" depending on the character encoding of the document's > entities. It may also vary with the SGML system's understanding and > implementation of 8879's rules for character handling, which seem to > give rise to wildly varying interpretations. I consider this a serious flaw in the spec. If the declaration's character set changes, the interpretation of numeric character references will also change. All XML documents must be parseable with a single SGML declaration. I don't believe that this is difficult. There may be entity managers that can't cope with a document whose encoding is not identical to the document character set, but I consider that a limitation of the system. > Systems with no internal representation for strings of 16 and 32 > bits would appear not to be capable of handling XML. I don't believe so. All the markup characters can be recommended in 8 bits - unsupportable data characters would have some fallback behavior when the document is translated from its native encoding to an 8-bit encoding. There would be data loss, but it should not be silent. -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) Date: Tue, 21 Jan 1997 12:52:47 -0600 From: Len Bullard To: Gavin Nicol CC: w3c-sgml-wg@www10.w3.org Subject: Re: Multi-headed indirect links Gavin Nicol wrote: > > >> At least within the ERB, the general design approach > >> appears to be remarkably uncontroversial. > > > >It's a pity that doesn't become more apparent to the list members who > >are not members of the ERB. A more open process is wanted and needed. > > I agree at least partly with this sentiment. One reason for a limited > WG mailing list is to avoid the noise caused by ignorance (ie. let's > not repeat HTML-WG). > > I think both Len and I remember the VRML-VAG.... As does Tim and we all have the archives. One thing I will give the VRML community credit for, particularly in draft 1.0, it was sometimes cold, but the list principals stayed on the list day and night hammering out the proposal, then spent a long time, helping the newbies understand. The formation of the VAG made some of us uncomfortable, and there was this tendancy to discard people's ideas only to see them resurrected later in a VAG member's posts without proper attribution. In the long run, a good spec and a profitable industry were formed. If one thing has characterized the VRML community, it has been a remarkable level of cooperation, not without flaws and even some wicked intrigues, but on the whole, open. Without malice and certainly without malevolence, I say to keep us involved, keep us informed. If Eliot's proposal is the core of the draft, then let's go over it in detail. It may be helpful. If it isn't, it is at least open ignorance and anyone who can't deal with that shouldn't work in a list community. It's like expecting a hearty round of applause after every song: it doesn't work that way. When a draft is being written, put it on a web page. If a draft is about to be written, give us an estimate of when we can begin to review it and the process for consolidation of comments. It's hard and time consuming. That is what the editors and ERB members signed up for. If not, that was painfully naive. Consider the impact: it will be a lot louder than the draft hitting the floor at SGML 96. len Date: Tue, 21 Jan 1997 11:48:25 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: proposal process [David Durand:] | If the ERB propagates it working decisions in the form of a | complete preliminary proposal before we have a directed | design-decision by design-decision discussion, I predict that the | final result will be strongly determined by the initial proposal. This | may be good or bad, but it is likely to happen. Let's review. On December 19, Tim Bray proposed a process for defining the goals and principles for Phase II of this activity. He started it off with a straw proposal for a list of design goals entitled Minimum Progress Required to Declare Victory. I reproduce that message at the end of this post for those who may have forgotten it. He attempted to define a process for refining his proposal as follows: | Sensible reactions to this proposal include: | - suggestions that we add facility X, because it's easy and useful | - suggestions that we add facility X whether it's easy or not because | it's such a basic need that we're wasting our time if we leave it out | - suggestions that we remove facility X, because it'll get us in trouble | - suggestions for compliance, at some level, with some existing standard | - meta-suggestions for good ways to structure this discussion | - comprehensive yet compact fully thought out proposals for a hyperlinking | facility, supported by multiple public-domain reference implementations Soon after he had made this proposal, Tim attempted to get participants to respond to specific points in a way that would create an organized list of design principles: | Martin, your contribution addresses two points in the MPRDV note, | which could either be identified by number (3.2sub2, 3.3) or name | (addressing un-ID'd objects, link-end to address sets.) To achieve | some sort of order in this discussion, it would help if people would | use the "Subject:" line to support discussion threads at a level | somewhat narrower than "Hyperlinks". This attempt to set up a discussion of goals in advance of specific proposals has largely been ignored by everyone, including those who are now complaining about a lack of process. After letting the conversation free-wheel for a while (a completely conscious decision for which I take full responsibility), Tim, concluding (I believe) that his original proposal would stand as our guide, moved the discussion forward by suggesting a concrete proposal in a message of December 29: | All this discussion has been quite educational, but the proportion of | it that I can relate to the problems that I as co-editor will soon be | facing is kind of low. | | I think it's time for a strawman. [...] Eliot responded to this a few days later with a very useful HyTime-based "house of sticks", and that's why we are now talking in terms of proposals. The ERB feels that we are now ready to look at an actual straw proposal, and the co-editors of the link draft are preparing one even as we speak. You should have their initial attempt before you within the next day or so. I'm sorry if anyone feels that there hasn't been enough time spent on a discussion of goals before considering specific proposals, but it certainly wasn't for a lack of opportunity. Looking back over the last month of discussion, I personally am of the opinion that we couldn't have made better progress without chewing on various aspects of the problem in the way that we have done, and I think that we are as ready as we will ever be to move forward within the organization of a specific plan. I don't know exactly what the draft co-editors will be presenting, but I am confident that it will take into account all the many insightful contributions made to this list (I would like to recognize Dave's work in particular, without which we could not have come as far as we have in understanding the issues) and that it will be the best starting point that we could hope for at this stage. Jon ######################################################################## Date: Thu, 19 Dec 1996 20:19:45 -0800 To: w3c-sgml-wg@www10.w3.org From: Tim Bray Subject: Hyperlinks: MPRDV In the meeting of Dec. 18, the ERB discussed how we might start moving forward on hyperlinking. Attempts to proceed as we did with the base XML language, i.e. agree on a statement of principles and start subsetting an existing standard, seem fraught with difficulty; in particular it seems very difficult to separate the meta-discussion of design goals from the discussion of implementation details and standards compliance. To help get things going, and after running this idea past the ERB, I am introducing a proposal entitled Minimum Progress Required to Declare Victory. The idea is to continue running with the XML premise; that you can do a lot with a little. In particular, we should be able to offer the Web community something subtantially better than they're used to without having to go very far. It should be borne in mind that to do a good job on specifying even a little, you have to fight through some surprisingly hairy problems (as witness our recent experience on this list). This is an attempt to spot the low-hanging fruit in the hyperlinking jungle. Sensible reactions to this proposal include: - suggestions that we add facility X, because it's easy and useful - suggestions that we add facility X whether it's easy or not because it's such a basic need that we're wasting our time if we leave it out - suggestions that we remove facility X, because it'll get us in trouble - suggestions for compliance, at some level, with some existing standard - meta-suggestions for good ways to structure this discussion - comprehensive yet compact fully thought out proposals for a hyperlinking facility, supported by multiple public-domain reference implementations This will presumably launch us on a fairly free-form discussion ranging from philosophy through implementation, which is no bad thing at this stage. At some point we will have to impose structure on the discussion and generate a draft and so on; this point will doubtless arrive before many of us are comfortable that we're ready. Speaking unofficially, but I think on behalf of the ERB, it seems that the breakneck pace at which we plowed through XML was on balance a good thing, and we'll try to stick with that. Having said all this, I should emphasize that while the ERB gave me the OK to post this and get things going, it is *not* a position of the ERB, and no hint should be taken that we are leaning in this direction or any other. Once again, it will be helpful if those responding use subject lines to help sort out threads. I'll place an HTML version of this at http://www.textuality.com/sgml-erb/mprdv.html ================================================================= Minimum Progress Required to Declare Victory 1. Background The Web is the largest working hypermedia instance. It supports one widely-used form of hyperlink, the or Anchor element. These links are unidirectional and [this is a basic design principle of the web] specify basically nothing about their target except its location. The links carry no typing or role information, beyond the unconstrained text that may be found between the and tags. HTML offers another hyperlink facility, the LINK header element, but it is not widely used. Web links support a variety of behaviors, governed by the interaction of the "scheme" part of the URL (http:, file:, ftp:, mailto:) and the logic in the "User Agent" (typically a browser). It might be argued that there are really a smaller number of behaviors (a) retrieve and display, (b) retrieve and save, (c) send mail; but the number of behaviors exceeds one. There are a variety of other standards that support hyperlinks, of which the most visible are HyTime, part of TEI, and in the area of object naming, the IETF URN work. None of these, at this moment, has overwhelming market acceptance, or credibility at the level enjoyed by SGML. HyTime has ISO's blessing, URN has the IETF's; TEI is used to encode many billions of bytes of text. 2. Minimum Progress on Deliverables The minimal deliverable is a smallish document (smaller than the XML spec) with an independent existence and name - for example, XHA for Extensible Hyperlink Architecture. The hyperlinking mechanisms should be applicable to XML of course, but also to SGML and (to the extent possible) to HTML. XHA should have no dependency on XML. However, we may choose to build special machinery into XML (reserved elements/attributes/archforms) to optimize support for XHA. 3. Minimum Progress on Hyperlink Enhancement The minimum set of hyperlink constructs should: 3.1 subsume the existing WWW Anchor semantics in a smooth and natural way. 3.2 provide a hyperlink mechanism with richness similar to that of the HyTime "ilink" construct. This means that the link - has a type, - has multiple ends, each of which has a role, and - may be located away from any of its ends, thus supporting links into read-only material. 3.3 support addressing at least by URL and ID attribute, alone or in combination. 4. Minimum Progress on Behavior The minimum set of behavior machinery should provide: 4.1 mechanisms for users to identify and describe behaviors associated with hyperlinks. 4.2 predefined behaviors equivalent to those already in wide use on the Net. 5. Minimum Progress on Link Roles The minimum set of link role machinery should provide: 5.1 mechanisms for users to identify and describe roles for link-ends. 5.2 predefined link roles equivalent to those already in wide use on the Internet Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Tue, 21 Jan 1997 19:49:06 +0000 To: dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: Multi-headed indirect links At 12:43 21/1/97 -0500, David G. Durand wrote: > >I wanted to be quiet, but this is a gross misrepresentation of the state of >affairs. A very deliberate one:-) >The claim is that you have a syntax (entity references) that will >give you the indirection that you want. While it's not elegant (it's >actually kinda yucky), To see how yucky try applying it to the four or five cases I asked about specifically - the bit of my message everyone is careful to ignore. >You have not presented anything that you can do with >one syntax that you cannot do with the other. Thats the difference between being elegant and being yucky - the same effect of keeping off the sun can be acheived with silk or rags:-) >The issue of the locsrc is a different one, but if we can include an >equivalent of the "BASE" attribute (and I think we should), then we can do >the entitized equivalent of locsrc without the additional implementation >overhead of locsrc. I have pointed out in other messages that BASE fails for multiheaded links. Show me how to use this idea with the examples I quoted. Incidentally why are the entitized equivalents of locsrce so much easier to implement than pointing to a separate element with an ID? ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Tue, 21 Jan 1997 15:50:26 -0600 From: len bullard To: Jon Bosak CC: w3c-sgml-wg@www10.w3.org Subject: Re: proposal process Jon Bosak wrote: > > [David Durand:] > > | If the ERB propagates it working decisions in the form of a > | complete preliminary proposal before we have a directed > | design-decision by design-decision discussion, I predict that the > | final result will be strongly determined by the initial proposal. This > | may be good or bad, but it is likely to happen. > > Let's review. Let's stick to the subject. Announce to the list when a proposal is adopted as a core for a draft. Point to web page where that draft or proposal can be found. That will do more to keep us orderly than cryptic MPRDV, chap2 or anything else. Free wheeling is discussion is good, needed and productive. ERB decisions to adopt proposals as drafts without informing the list formed and requested to discuss them simply leaves us hanging. Do that and we won't make wrong assumptions, and we won't have to repeat this discussion. Len Bullard Date: Tue, 21 Jan 1997 15:25:42 -0800 To: w3c-sgml-wg@www10.w3.org From: Tim Bray Subject: Re: proposal process You're right. We're taking too long to get the strawman out. Sorry. Following on the proposal, I expect some numbered lists of votable items to bring structure to the debate. I will say, however, that the unstructured debate has been very substantially enlightening, at least to me. One thing on our side; this is going to be shorter than XML. - Tim To: w3c-sgml-wg@www10.w3.org Subject: Base <1.5.4.32.19970121194906.00698294@mail.u-net.com> Date: Tue, 21 Jan 1997 16:54:17 -0700 From: Dave Hollander While structure and syntax of links is important, there are many other link concepts that need attention. Since base has come up again, I will start a new thread with an old complaint. The current web definition for "BASE" is not sufficient. There was a long thread in another list that identified that base is either,but not both: 1) the url fragment to be used to complete partial URLs 2) the url of the entity The tread did not reach agreement that the current web spec was not clear enough. There was agreement that the entity address was secondary. Areas of conflict: - Should base value *always* be displayed as the address of the document in browsers, hotlists, and other processing applications? - Should the base be used to identify an alias for the document? If not, how? - Should the application of the base value to a partial URL always imply a new entity? (there...not a single TEI/HyTime term used) Should not this group also be interested creating an othogonal definition for these concepts? Dave Hollander --------------- > >The issue of the locsrc is a different one, but if we can include an > >equivalent of the "BASE" attribute (and I think we should), then we can do > >the entitized equivalent of locsrc without the additional implementation > >overhead of locsrc. > > I have pointed out in other messages that BASE fails for multiheaded links. > Show me how to use this idea with the examples I quoted. From: lee@sq.com Date: Tue, 21 Jan 97 18:59:59 EST To: mtbryan@sgml.u-net.com, w3c-sgml-wg@www10.w3.org Subject: Re: Multi-headed indirect links [Martin] > How can I say I want this bit of the text linked to the same points that > that bit of text in this document and that bit of text in that document > point to? A bit of text doesn't point anywhere. There may be a piece of separately stored information that says that there is a link between that bit of text and my left ankle (say), in which case that information may be termed a link, and you can say that you want to make a new thre-ended link that shares both ends of the other link. I'm not sure how to create markup for that in a way that can be easily understood and explained, but, if that is deemed an essential requirement of an XML hypertext system, no doubt Eliot and/or Tim's proposal will show how to do it. If that bit of text is actually marked up- as one end of a link, you can point to the same place that it does if you like using a TEI extended pointer, if such things be supported. Lee From: lee@sq.com Date: Tue, 21 Jan 97 22:34:26 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: Base Dave Hollander wrote: > Areas of conflict: > - Should base value *always* be displayed as the address of the document > in browsers, hotlists, and other processing applications? No -- it's up to the application. Most want to display how you got there. > - Should the base be used to identify an alias for the document? It depends what you mean by an alias, I think. > If not, how? In HTML, one might do something like I suppose. > - Should the application of the base value to a partial URL always imply > a new entity? As opposed to what exactly? If the resulting URL is the same as that of the current document (however that's determined), following a link may be a null operation, or an HTTP HEAD or if-newer-than might be used to make sure the document hasn't changed since it was last downloaded. > Should not this group also be interested creating an othogonal definition > for these concepts? I don't think so. The goal is not to duplicate HTML, nor to hash out all the same issues. The goal is to end up with a simple, clean, esy to explain, easy to implement markup language derived from SGML that is particularly suitable for Internet use (see the Activity page!) So where we end up needing these concepts we will have to develop them. SoftQuad Panorama 2.x allows a processing instruction to specify a URL for the document containing it. It needn't be the same URL that was used to fetch the document, but it will be used for bookmarking, relative links, and fetching CATALOG files. Without that, it can be awfully difficult to serve up a multi-file object using CGI scripts! Lee Date: Wed, 22 Jan 1997 00:04:20 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: questions on XML sgml decl's charsets At 1:36 PM 1/21/97, Christopher R. Maden wrote: >[Michael Sperberg-McQueen] > >> The spec says "The specific SGML declaration needed to enable SGML >> systems to process XML documents will vary from document to >> document" depending on the character encoding of the document's >> entities. It may also vary with the SGML system's understanding and >> implementation of 8879's rules for character handling, which seem to >> give rise to wildly varying interpretations. > >I consider this a serious flaw in the spec. I think it's kind of unavoidable, since SGML character handling is such a mess (in practice) that I doubt we could find any 16 bit solution that would work on all systems -- possibly even any single declaration that would work on all systems. The elegant idea of a declaration as a document specific data specification has long been replaced by the ugly practice of the declaration as dependent on both processor and input, in my experience. I may be clueless here, but I thought the idea was that it should be possible to process XML with an SGML processor -- I don't remember any _requirement_ that you do it the same way with different SGML processors. Obviously it's not a good idea to have too many ways, but two declarations seems acceptable. Of course, this is a new way to see the basic point that dealing with character numbers at all is inherently fragile. We could solve this problem as well by structured use of SDATA (as we have made structured use of PI). >> Systems with no internal representation for strings of 16 and 32 >> bits would appear not to be capable of handling XML. > >I don't believe so. All the markup characters can be recommended in 8 >bits - unsupportable data characters would have some fallback behavior >when the document is translated from its native encoding to an 8-bit >encoding. There would be data loss, but it should not be silent. I'm being clueless again, but isn't there a way out for UTF-8 encoded files, if we stay away from numeric character references? As long as every character that can occur in UTF-8 is allowed in NAMECHAR we would be home free, wouldn't we? Is that possible, or do UTF-8 strings include all possible 8-bit character codes? It's clear that such a processor would not be able to detect references to Unicode characters not allopwed in the 16 bit declaration, but if we have only to worry about adding 8-bit high chars to the declaration, we might be OK. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Wed, 22 Jan 1997 00:04:16 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: proposal process replies I'm pretty satisfied as to the state of things at the moment. And, although I may not have sounded like it, I'm not worried that there are any plots going on. But I do think that the communication problem looks different from the outside than the inside of the ERB. If I had been aware that Eliot's draft was serving as a discussion draft within the ERB, I might have commented on it in a different and more intensive way. I chose to concentrate on the semantics implied by Eliot's draft, more-or-less ignoring all XML-syntactic and human-terminological issues. And I weighed it in the balance roughly the same as the many other threads on the list, and my own less polished proposals. My worry isn't that the unguided discussion has not been fruitful, but I would have rather known that issues were being listed and explicit yeas/nays solicited in advance of the drafting process. Alternatively, I would have felt better with a posting from the ERB as soon as they decided, to the effect that "Eliot's proposal looks like a good starting point, propose any revisions/objections now". Even better would have been a posting that this important issue of the starting point for a draft is up for a vote at such-and-such a time, and Eliot's proposal is the current candidate. From what Jon and Tim are saying I think that the intended effect is the same as what I wanted, but it is rather a shock to find out things that are well under way when you've been engaged in "warm-up" discussions. I know that fully documenting every word of ERB meetings would be sufficiently onerous to slow if not halt progree, and would be relatively useless besides. But the reports of ERB and editor decisions and actions really do help those of us on the outside feel involved. I look forward to seeing a proposal, and will sharpen up my exacto knives in anticipation. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Tue, 21 Jan 1997 23:08:37 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Multi-headed indirect links At 2:49 PM 1/21/97, Martin Bryan wrote: >At 12:43 21/1/97 -0500, David G. Durand wrote: >>The issue of the locsrc is a different one, but if we can include an >>equivalent of the "BASE" attribute (and I think we should), then we can do >>the entitized equivalent of locsrc without the additional implementation >>overhead of locsrc. > >I have pointed out in other messages that BASE fails for multiheaded links. >Show me how to use this idea with the examples I quoted. I don't remember the examples, but we should have the possibility of separate address elements (I think eliot and I both suggested it, and I think Eliot did as well). Given that, you simply need to use separate address elements (each with its own base). This is one reason to enable such indirection. And since it runs in the "forward" direction from the link, it's easy to code. >Incidentally why are the entitized equivalents of locsrce so much easier to >implement than pointing to a separate element with an ID? Pointing to an element with an ID requires first searching for that element and resolving it, before interpreting the link (a step back before the step forward, as it were). Entity resolution is something people already have. Relative URL resolution is something they already understand, and implementors also have the (trivial) code to implement it in hand. And, I'm not sure that it buys us _that_ much. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Tue, 21 Jan 1997 22:57:22 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Breathing together (Was: Re: Multi-headed indirect links) [Len Bullard:] | Because there was no formal "proposal submitted by E. Kimber on (date) | has been adopted as the basis for the first draft etc.", no one knows | whether they should focus on it, or wait for the next proposal. There | is no "certainty" without such an announcement of intent. We cannot | see or assume much about the ERB's business. Simply have Jon or | whoever make such an announcement, and have the ERB members conduct | debate in the open. That is an open process. That is a fundamental | of list community design: open debate by the principals. Oh, for heaven's sake. So that's what this is all about. Pardon me for not getting to this thread earlier, but I didn't expect to find a discussion of working group procedures under the heading "Re: Multi-headed indirect links". I detect in the later posts in this thread a suspicion that some clandestine discussion of link strategies has been going on in the ERB all unbeknown to the WG at large. The facts are as follows: * The ERB met on December 18 and did not meet again or communicate in any significant way until January 8. An examination of the WG archives for this period will show that the great bulk of the link discussion occured during a period when the ERB effectively did not exist. * The ERB meeting of January 8 was occupied entirely with issues relating to a proposed XML TC to 8879 that has been churning in the background since November and will probably continue to do so for some time to come. The decisions made during this meeting were reported by Tim Bray a day or two later. Linking was not discussed. * The next ERB meeting took place last Wednesday, January 15. The first part of that meeting was devoted to some more TC issues, and the result of that discussion (a decision about comment delimiters) was subsequently reported to the WG. At that point, the ERB explicitly took up the topic of linking for the first time. It was decided that the XML-LINK co-editors would put together a straw proposal for consideration by the WG based on (a) Eliot's HyTime-based draft, which was the only concrete proposal that had been made during the WG discussion, (b) the TEI extended pointer mechanism, which some people seemed to find promising, (c) all the rest of the discussion that had taken place in the WG during the period from December 18 through January 15, and (d) a general desire to keep things as simple as possible. Oh yes, we also briefly discussed ways of categorizing the areas that will need to be specified. I shared with the group some analysis I had done over the vacation, which concluded that we were badly overloading the term "link semantics" and that what we needed to deal with could be grouped under four heads, viz.: 1. Structure, or link topology 2. Location and addressing 3. Meaning, or relationship typology 4. Presentation a. Before link traversal b. After link traversal Steve D. observed that "During link traversal" should be added to point 4. Some ERB members felt that this taxonomy might be helpful; some (I think) preferred other ways of looking at the problem space. There was general agreement that this might be a good way to organize a specification, with point 4 probably falling into Phase III of our activity. That's it. That's the sum total of the ERB's discussion of linking, at least so far as I have managed to capture it in my notes. I'm sorry to disappoint anyone who was thinking that the ERB had this all figured out while the rest of the WG was groping around for a solution, but the banal reality is that we were just watching the give-and-take along with the rest of you. We have no idea what the editors are going to propose as a starting point for the discussion of specifics beyond the points listed above; we just have faith that they will do a good job putting together something that will provide a serviceable matrix for the more focused debate that we expect the WG to engage in for the next three months. Jon Date: Tue, 21 Jan 1997 17:06:46 -0800 (PST) From: Terry Allen To: dmh@hpsgml.fc.hp.com, w3c-sgml-wg@www10.w3.org Subject: Re: Base Dave Hollander writes: | While structure and syntax of links is important, there are many other | link concepts that need attention. Since base has come up again, I will | start a new thread with an old complaint. The current web definition for | "BASE" is not sufficient. | | There was a long thread in another list that identified that base is | either,but not both: | 1) the url fragment to be used to complete partial URLs | 2) the url of the entity | The tread did not reach agreement that the current web spec was not | clear enough. There was agreement that the entity address was secondary. draft-fielding-url-syntax-03.txt says: D. Embedding the Base URL in HTML documents It is useful to consider an example of how the base URL of a document can be embedded within the document's content. In this appendix, we describe how documents written in the Hypertext Markup Language (HTML) [3] can include an embedded base URL. This appendix does not form a part of the relative URL specification and should not be considered as anything more than a descriptive example. HTML defines a special element "BASE" which, when present in the "HEAD" portion of a document, signals that the parser should use the BASE element's "HREF" attribute as the base URL for resolving any relative URLs. The "HREF" attribute must be an absolute URL. Note that, in HTML, element and attribute names are case-insensitive. For example: An example HTML document ... a hypertext anchor ... A parser reading the example document should interpret the given relative URL "../x" as representing the absolute URL regardless of the context in which the example document was obtained. I'd say that points to (1) above, though I'm not quite sure what (2) means, and the example given is not entirely unambiguous (is "a" a directory or a filename? seems to be intended as a directory). It *is* clear that if there is no BASE in the HTML document, the URL employed to obtain the document can be used as (the starting point for determining?) the base URL. The definitive doc to date is RFC 1808 (ftp://ds.internic.net/rfc/rfc1808.txt). | Areas of conflict: | - Should base value *always* be displayed as the address of the document | in browsers, hotlists, and other processing applications? conflict between what? which document? do you mean base value or base value+relative URL as arrived at per RFC 1808? | - Should the base be used to identify an alias for the document? | If not, how? what is an "alias for the document"? which document? | - Should the application of the base value to a partial URL always imply | a new entity? I think the rather involved algorithm in RFC 1808 does not prohibit relative URLs that in fact point to the document containing them, and in fact I don't see how it can. But perhaps I misunderstand "imply a new entity." | (there...not a single TEI/HyTime term used) well, you did use "entity" instead of "resource" ... | Should not this group also be interested creating an othogonal definition | for these concepts? Certainly not. At least not for these concepts under these names; that's for the IETF to deal with. We should certainly clarify for ourselves whatever seems unclear, though. I don't see that we can prohibit the use of the BASE mechanism, or relative URLs, so if we have unresolved problems we should present them to the (newly formed) URL WG. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Date: Wed, 22 Jan 1997 07:30:38 -0600 From: len bullard To: Jon Bosak CC: w3c-sgml-wg@www10.w3.org Subject: Re: Breathing together (Was: Re: Multi-headed indirect links) Jon: I'm not sure any of us think something is going on in dark corners. Personally, two things: 1. Surprise that Eliot's proposal had been adopted as the core. 2. The way in which that became known. Timely news is the best news. "Open" is not just a a reaction to a closed door, but one in which the sound in the next room is only heard as a muffled murmur. Thanks for the summary. It is appreciated. >From a now forgotten song, "Ya gotta let it out, Captain." len To: w3c-sgml-wg@www10.w3.org Subject: Re: Base <199701220106.RAA13321@ishtar.fsc.fujitsu.com> Date: Wed, 22 Jan 1997 09:18:29 -0700 From: Dave Hollander While I am interested in the issues surrounding the overloading of base I am more interested in establishing a "standard" for the linkage concepts that have not been established as standard practice in the HTML community. Lee mentions the SoftQuad use of PI to contain a URL. Great for them, but I can not rely on that across vendors. Since concepts like these are so useful, can we not work to establish a consistent way to identify them to vendors so that they can create richer universal tools? One particular goal should be that this effort helps improve the ability to maintain links and a web of links. This goal seems to motivate much of the syntax discussion. However, simple assumptions about the role or meaning of a link greatly improve the ability to maintain a web. Why should meaning be taboo? On to the base case: I am very familiar with RFC 1808 (ftp://ds.internic.net/rfc/rfc1808.txt). having had to defend a particular web document that used base in a non-expected way. I am not always clear in my writing though, so I will try again to list the two possible interpretations of RFC 1808 in regards to base. Note, while Roy and others deny that the spec can be interpreted in multiple ways, many others did see the unambiguity. 1) (traditional) the value of the base is added to all relative URLs 2) the url value for the "resource" (the resource may be reached by multiple routes and may have multiple instances) The problem arises when a content provider is trying to give a better URL for use in hotlists than one of the many possible routes to the document. This may be done for maintenance reasons (a file spec is easier to maintain than a imagemap coordinate, or, as some on the list noted, for deception). > Terry Allen writes: > | Areas of conflict: > | - Should base value *always* be displayed as the address of the document > | in browsers, hotlists, and other processing applications? > > conflict between what? which document? do you mean base value or > base value+relative URL as arrived at per RFC 1808? Conflict in the discussion list. The spec is ambiguous as to how the base value should be applied beyond relative URL completion. The alternative roles for base in an application is not clear. > > | - Should the base be used to identify an alias for the document? > | If not, how? > > what is an "alias for the document"? which document? There can be multiple paths to a resource. The owner should not be held responsible for maintaining all of them, particularly since many may not even be under their control. How can the owner identify a prefered (aka maintained) identifier/url for the resource? > > | - Should the application of the base value to a partial URL always imply > | a new entity? > > I think the rather involved algorithm in RFC 1808 does not prohibit > relative URLs that in fact point to the document containing them, and > in fact I don't see how it can. But perhaps I misunderstand > "imply a new entity." The RFC does not specify if the object identified by BASE + RelativeURL + #loc (my external network connection is down and I can find the correct term for "#loc") is indeed the same resource as just using #loc in the current resource. This can result in a different entity if an explicit base value is not the same as the implicit base value (how the resource was reached). Dave Hollander From: Paul Prescod Subject: Re: Base To: dmh@hpsgml.fc.hp.com (Dave Hollander) Date: Wed, 22 Jan 1997 12:35:39 -0500 (EST) Cc: w3c-sgml-wg@www10.w3.org > > > While I am interested in the issues surrounding the overloading of base > I am more interested in establishing a "standard" for the linkage concepts > that have not been established as standard practice in the HTML community. > Lee mentions the SoftQuad use of PI to contain a URL. Great for them, > but I can not rely on that across vendors. Since concepts like these > are so useful, can we not work to establish a consistent way to identify > them to vendors so that they can create richer universal tools? > > One particular goal should be that this effort helps improve the ability > to maintain links and a web of links. This goal seems to motivate much of > the syntax discussion. However, simple assumptions about the role or > meaning of a link greatly improve the ability to maintain a web. Why > should meaning be taboo? > > > > On to the base case: > > I am very familiar with RFC 1808 (ftp://ds.internic.net/rfc/rfc1808.txt). > having had to defend a particular web document that used base in a > non-expected way. I am not always clear in my writing though, so > I will try again to list the two possible interpretations of > RFC 1808 in regards to base. Note, while Roy and others deny that the > spec can be interpreted in multiple ways, many others did see the > unambiguity. > > 1) (traditional) the value of the base is added to all relative URLs > > 2) the url value for the "resource" (the resource may be reached by > multiple routes and may have multiple instances) > > The problem arises when a content provider is trying to give a better > URL for use in hotlists than one of the many possible routes to the > document. This may be done for maintenance reasons (a file spec is easier > to maintain than a imagemap coordinate, or, as some on the list noted, > for deception). > > > Terry Allen writes: > > | Areas of conflict: > > | - Should base value *always* be displayed as the address of the document > > | in browsers, hotlists, and other processing applications? > > > > conflict between what? which document? do you mean base value or > > base value+relative URL as arrived at per RFC 1808? > > Conflict in the discussion list. The spec is ambiguous as to how the > base value should be applied beyond relative URL completion. The > alternative roles for base in an application is not clear. > > > > > | - Should the base be used to identify an alias for the document? > > | If not, how? > > > > what is an "alias for the document"? which document? > > There can be multiple paths to a resource. The owner should not be held > responsible for maintaining all of them, particularly since many may not > even be under their control. How can the owner identify a prefered > (aka maintained) identifier/url for the resource? > > > > > | - Should the application of the base value to a partial URL always imply > > | a new entity? > > > > I think the rather involved algorithm in RFC 1808 does not prohibit > > relative URLs that in fact point to the document containing them, and > > in fact I don't see how it can. But perhaps I misunderstand > > "imply a new entity." > > The RFC does not specify if the object identified by > BASE + RelativeURL + #loc (my external network connection is down and > I can find the correct term for "#loc") is indeed the same resource > as just using #loc in the current resource. This can result in a > different entity if an explicit base value is not the same as the > implicit base value (how the resource was reached). > > > Dave Hollander > > To: w3c-sgml-wg@www10.w3.org Subject: Re: Base Date: Wed, 22 Jan 1997 09:58:18 -0800 From: Joe English Dave Hollander wrote: > There was a long thread in another list that identified that base is > either,but not both: > 1) the url fragment to be used to complete partial URLs > 2) the url of the entity > The tread did not reach agreement that the current web spec was not > clear enough. There was agreement that the entity address was secondary. The same discussion came up on the HTML-WG list, and If I Recall Correctly the conclusion was that the document's base address (i.e., the value of the HREF attribute on the BASE element) only specifies a URL with respect to which relative URLs within the same document are to be resolved. That is, case (1) is correct (at least for HTML). Again IIRC it does *not* have the semantics of case (2). In particular, the BASE element does not specify a "preferred address" for bookmarking purposes, the browser's history list, a "reload" function, etc., nor is there any requirement that a document can even be retrieved through its BASE URL. > Areas of conflict: > - Should base value *always* be displayed as the address of the document > in browsers, hotlists, and other processing applications? IIRC, no -- in fact it should *never* be displayed as such. > - Should the base be used to identify an alias for the document? IIRC, no. > If not, how? As far as I know, no such mechanism exists for HTML. (It _can_ be done with HTTP response headers, though; I don't recall the exact mechanism offhand.) > - Should the application of the base value to a partial URL always imply > a new entity? Perhaps surprisingly, no! There was (and as far as I know still is) a problem with partial URLs consisting solely of a fragment identifier, as in . If a document contains the canonical rules for deriving an absolute URL from the relative URL "#there" would yield However, since there is no guarantee that the document itself actually lives at , that would leave no way for an HTML document with a BASE element to refer to a named anchor within the same document. Several people (myself included) urged the adoption of SGML's ID/IDREF mechanism to express this function, but IIRC due to lack of prior implementation it was decided that HREF attributes beginning with a '#' should be treated as a special case instead. (Again, this is just my recollection of the results of the discussion; I can't find any definitive answers in RFC 1866, 1808 or 1738, and I might be misremembering.) > Should not this group also be interested creating an othogonal definition > for these concepts? The BASE/SOIBASE mechanism should be sufficient for link maintenance, as long as it's possible to specify a BASE URI for individual entities instead of being constrained to a single base URI for the entire document (a la the HTML 2.0/3.2/Cougar BASE element); and XML documents will (presumably) be able to specify intra-document relations via ID/IDREF. Is there a need for documents to be able to state "I _really_ live at URL 'X', even if you downloaded me through some other location."? --Joe English jenglish@crl.com Date: Wed, 22 Jan 1997 13:52:34 -0500 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu CC: w3c-sgml-wg@www10.w3.org Subject: Re: questions on XML sgml decl's charsets >>I consider this a serious flaw in the spec. > >I think it's kind of unavoidable, since SGML character handling is such a >mess (in practice) that I doubt we could find any 16 bit solution that >would work on all systems -- possibly even any single declaration that >would work on all systems. The elegant idea of a declaration as a document >specific data specification has long been replaced by the ugly practice of >the declaration as dependent on both processor and input, in my experience. I should note that for HTML I18N (somewhat before BCTF) I took the view that the document character set defined the *characters* that were available to the parser, not the character *numbers* (ie. the character numbers were nothing but a shorthand name for the actual character). This works out well, because it doesn't constrain the parser implementation by requiring that it represent things with bit combinations of a given width. >Of course, this is a new way to see the basic point that dealing >with character numbers at all is inherently fragile. We could solve this >problem as well by structured use of SDATA (as we have made structured use >of PI). Part of the global glyph/character repositiory idea I have is basically just that: you refer to character by *name* rather than number. >I'm being clueless again, but isn't there a way out for UTF-8 encoded >files I think it's important not to confuse encodings and coded character sets. You should be able to have any encoding you like as input, and all numeric character references should still refer to the same character. For example, if you have ㌽ (SQUARE POINTO)in your UTF8 document, and you do a blinf encoding conversion to shift-jis, then that numeric character reference should still refer to SQUARE POINTO. Date: Wed, 22 Jan 1997 13:21:58 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Relationship Taxonomy Questions All, The ERB would like to ask the list to address the following questions relating to relationship (link) typing. The questions: Assuming that there is a distinction between link behavior and the relationship types that links represent, and in particular, a distinction between behavioral "primitives" and relationship "primitives": 1. Is it necessary or useful for XML to define some finite set of well-defined relationship types or primitives? Our presumption, as yet unproved, is that the interoperation of XML documents within some general purview (e.g., the Web, as opposed to domain-specific purviews, such as a particular intranet) requires some basic set of link types whose meaning is well defined and understood. This presumption is based in part on the opinion that typing links is in fact a useful thing to do for some types of information. We take it as a given that the set of possible relationship types is unbounded. 2. If the answer to question 1 is "yes", what is the list of types? 3. Given such a list, A. can these types be considered to be a set supertypes from which new types may be derived? B. If so, what mechanisms could or should be used to define such a class hierarchy? 4. Is there a preferred formalism, in terms of prose rhetoric, formal notation, or both, by which the meaning of relationship types should be expressed. NOTE: this formalism *cannot* consist only of behavior specification (although it may include a behavior specification). NOTE: The issue of behavior primitives is not open for discussion at this time. The behavior issue will be taken up after the base link representation syntax and link typing issues have been sufficiently resolved. Definition of terms: behavior What happens when some agent interacts with the link, either directly or by interaction with one of its link ends. Behavior includes all of what happens in user interfaces, and could also include behaviors of translators, processors, query engines, etc. In the general case, behavior is not permanently (and exclusively) bound to data objects (i.e., the SGML content vs. style model). However, some element types or base element type classes may have semantics that largely or exclusively suggest a particular behavior (e.g., ), although it is generally regarded as poor practice for most applications (partly because implementation of the suggested behavior cannot be universally enforced). In the SGML model, behavior can be considered an aspect of "style" or presentation and may be defined explicitly through "style sheets" or "processing specifications" or may be embedded into a particular browser or processor (e.g., HTML browsers pre CSS). In this broad definition of the term style, mechanisms such as scripts, controls, and plug-ins could all be considered aspects of style specification. At this point we are assuming that behavior will be specified both in some normative way in an XML specification and, at user option, through some as-yet-undetermined behavior specification system or systems (e.g. "link style sheet"). relationship A *semantic* association among two or more objects intended to describe the nature of the assocation. Relationship types may be thought of as analogous to element types in SGML, such that where element types classify data objects, relationships (and thus links) classify assocations among data objects. Like element types, relationship types can range from the very general ("linked") to the very specific ("Counterargument"). Our assumption is that links always represent relationships of some defined (albeit possibly very general) type. In the likely syntax design model, the link type will be named either through the element type of a link element or through an attribute that defines the type name. Relationships are distinguished by relationship type. In addition, some relationship description models may further describe relationships by naming the roles in the relationship (e.g., the HyTime hyperlink model). As for element types, some relationship types may largely or exclusively suggest a particular behavior (e.g, ). Such relationship types are poor practice only when their use fails to identify a more specific relationship type that would enhance the value of the information in the scope of its expected application and use (in other words, when you don't care about the link type, there's little value in being more specific than "link", but if your system expects and depends on typed links, you'd better type them). Relationships may be implicit in the data structure (i.e., the hierarchical relationships defined by SGML markup) or explicit through hyperlinks or other associative systems (i.e., relational databases). semantic The "meaning" associated with a type. The term "semantic" is dangerous because it is overloaded and can mean different things in different contexts. In this discussion, we are trying to clearly differentiate meaning, which is abstract, from behavior, which is concrete. In general, there is a one-to-one relationship between a type and its semantic, but a one-to-many relationship between a type and its possible behaviors. In other words, a type's semantic doesn't change, but that semantic may be interpreted into specific behaviors in a variety of ways depending on the use to which the type is put or the arbitrary whim of the behavior specifier. Cheers, Eliot. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Wed, 22 Jan 1997 11:36:50 -0800 (PST) From: Terry Allen To: dmh@hpsgml.fc.hp.com, w3c-sgml-wg@www10.w3.org Subject: Re: Base (I hold no brief for the mess Dave is concerned about, and have no intention of defending the URL RFCs ...) Dave Hollander writes: | Lee mentions the SoftQuad use of PI to contain a URL. Great for them, | but I can not rely on that across vendors. Since concepts like these | are so useful, can we not work to establish a consistent way to identify | them to vendors so that they can create richer universal tools? It may be out of scope, but we can figure that out as we go along. [ ... ] | I will try again to list the two possible interpretations of | RFC 1808 in regards to base. Note, while Roy and others deny that the | spec can be interpreted in multiple ways, many others did see the | unambiguity. | | 1) (traditional) the value of the base is added to all relative URLs | | 2) the url value for the "resource" (the resource may be reached by | multiple routes and may have multiple instances) One of the problems here is the wooly, Hydra-headed concept of "resource." But for the case of a particular document, | The problem arises when a content provider is trying to give a better | URL for use in hotlists than one of the many possible routes to the | document. This may be done for maintenance reasons (a file spec is easier | to maintain than a imagemap coordinate, or, as some on the list noted, | for deception). URNs offer a way to communicate "better URLs," and to avoid binding that information with the document as originally served. I think any attempt to get the full effect with URLs will be unsatisfactory, but it should be possible to get a partial effect, which is all you're asking for. | > Terry Allen writes: | > | Areas of conflict: | > | - Should base value *always* be displayed as the address of the document | > | in browsers, hotlists, and other processing applications? | > | > conflict between what? which document? do you mean base value or | > base value+relative URL as arrived at per RFC 1808? | | Conflict in the discussion list. The spec is ambiguous as to how the | base value should be applied beyond relative URL completion. The | alternative roles for base in an application is not clear. RFC 1808 isn't ambiguous on the use of base URLs beyond what it describes, it just doesn't deal at all with them. (Or am I missing something?) Not that that observations helps answer your (legitimate) questions. | > | - Should the base be used to identify an alias for the document? | > | If not, how? | > what is an "alias for the document"? which document? | | There can be multiple paths to a resource. The owner should not be held | responsible for maintaining all of them, particularly since many may not | even be under their control. How can the owner identify a prefered | (aka maintained) identifier/url for the resource? This is a matter of defining semantics, and it might be best to do it at the level of MIME type. For any given DTD, you should be able to specify that an element holds this information; for HTML it could have been one of the values of META or LINK, but that horse is out of the barn and the barn's burned down. For XML, this could be one particular link semantic communicated by means of an attribute the value of which is (one idea) an FPI or URN pointing to a well known description of the meaning of the attribute. It doesn't have to be done with BASE, and if I look out into the driving rain long enough I can begin to think of circs under which I would want different BASE and PREFERRED ADDRESS values (I say preferred addresses because the same issue arises for URNs.) | > | > | - Should the application of the base value to a partial URL always imply | > | a new entity? | > | > I think the rather involved algorithm in RFC 1808 does not prohibit | > relative URLs that in fact point to the document containing them, and | > in fact I don't see how it can. But perhaps I misunderstand | > "imply a new entity." | | The RFC does not specify if the object identified by | BASE + RelativeURL + #loc (my external network connection is down and | I can find the correct term for "#loc") is indeed the same resource fragment identifier | as just using #loc in the current resource. This can result in a | different entity if an explicit base value is not the same as the | implicit base value (how the resource was reached). RFC 1808 does define precedence of BASEs derived by different means, so at least there is no ambiguity here. But here's where that wooly monster "resource" bites me hard. Are you concerned that a different document will be fetched when the user clicks on than the one he already has, if BASE is supplied? If so, why? the combination of base and fragment ID was created by the author, perhaps deliberately. Or are you concerned that the same document is identified by the browser as two different ones? NB: RFC 1866 appears to indicate that in the above case () one doesn't use BASE: 7.4. Fragment Identifiers Any characters following a `#' character in a hypertext address constitute a fragment identifier. In particular, an address of the form `#fragment' refers to an anchor in the same document. Regards, Terry Date: Wed, 22 Jan 1997 12:41:04 -0800 (PST) From: Terry Allen To: eliot@isogen.com, w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions Eliot purports to ask a set of questions: | The questions: | | Assuming that there is a distinction between link behavior and the | relationship types that links represent, and in particular, a distinction | between behavioral "primitives" and relationship "primitives": In view of the definitions below it's hard to say whether this assumption is warranted. And you never define "primitives." | 1. Is it necessary or useful for XML to define some finite set of | well-defined relationship types or primitives? Assuming you mean something straightforward, no. Defining the semantics of relationships is not for a metalanguage. | Our presumption, as yet unproved, is that the interoperation of XML | documents within some general purview (e.g., the Web, as opposed to | domain-specific purviews, such as a particular intranet) requires some | basic set of link types whose meaning is well defined and understood. This What's a link type as opposed to behavioral and relationship primitives? What is the "meaning" of a "link type"? For that matter, what is a "link type"? Please give simple examples. And please leave out the red herring of an intranet; it will operate on the same architectural principles as the Intranet. | presumption is based in part on the opinion that typing links is in fact a | useful thing to do for some types of information. "presumption," "unproved," "opinion." I decline to share your premises because I can't figure out what you're saying. | We take it as a given that the set of possible relationship types is | unbounded. So obviously no subset of them will be satisfactory, and we need a general way to refer to them, whatever they are. | 2. If the answer to question 1 is "yes", what is the list of types? As I answered No to 1, I regard this question as irrelevant. | 3. Given such a list, | A. can these types be considered to be a set supertypes from which new | types | may be derived? | B. If so, what mechanisms could or should be used to define such a class | hierarchy? Same response. | 4. Is there a preferred formalism, in terms of prose rhetoric, formal | notation, or both, by which the meaning of relationship types should be | expressed. NOTE: this formalism *cannot* consist only of behavior | specification (although it may include a behavior specification). No. | NOTE: The issue of behavior primitives is not open for discussion at this | time. The behavior issue will be taken up after the base link | representation syntax and link typing issues have been sufficiently resolved. Cart before horse. The syntax serves to enable behavior; behavior should be established first. The linking discussion started off with a consideration of behavior, let's get back to it. We had inclusion, transclusion of parts, traversal, and one or two other items I don't see mentioned below. That's the work our links have to do; I have seen almost no discussion of how this work is to be done, concretely, in an interoperable way. | Definition of terms: | | behavior | What happens when some agent interacts with the | link, either directly or by interaction with one of its link ends. | Behavior includes all of what happens in user interfaces, and could also | In the general case, behavior is not permanently (and exclusively) | bound to data objects (i.e., the SGML content vs. style model). However, | some element types or base element type classes may have semantics | that largely or exclusively suggest a particular behavior (e.g., ), | although it is generally regarded as poor practice for most applications | (partly because implementation of the suggested behavior cannot be | universally enforced). | | In the SGML model, behavior can be considered an aspect of "style" or | presentation and may be defined explicitly through "style sheets" or | "processing specifications" or may be embedded into a particular | browser or processor (e.g., HTML browsers pre CSS). In this broad | definition of the term style, mechanisms such as scripts, controls, | and plug-ins could all be considered aspects of style specification. Or may be specified in a DTD or by labelling with well known semantics. This is not a real useful definition of behavior. "Generally regarded as poor practice" is your view, and you should label it as such. | At this point we are assuming that behavior will be specified both in | some normative way in an XML specification and, at user option, through | some as-yet-undetermined behavior specification system or systems (e.g. | "link style sheet"). Eh? the user gets to change the behavior of the links in the document I sent him? That's a new one. Though perhaps your overbroad definition of behavior renders the issue moot. | relationship | A *semantic* association among two or more objects intended to describe | the nature of the assocation. Relationship types may be thought of as | analogous to element types in SGML, such that where element types | classify data objects, relationships (and thus links) classify | assocations among data objects. Like element types, relationship | types can range from the very general ("linked") to the very specific | ("Counterargument"). | | Our assumption is that links always represent relationships of some | defined (albeit possibly very general) type. In the likely syntax | design model, the link type will be named either through the element | type of a link element or through an attribute that defines the type | name. | | Relationships are distinguished by relationship type. In addition, | some relationship description models may further describe relationships | by naming the roles in the relationship (e.g., the HyTime hyperlink | model). As for element types, some relationship types may largely or | exclusively suggest a particular behavior (e.g, ). Such | relationship types are poor practice only when their use fails to | identify a more specific relationship type that would enhance the value | of the information in the scope of its expected application and use | (in other words, when you don't care about the link type, there's little | value in being more specific than "link", but if your system expects | and depends on typed links, you'd better type them). "Poor practice" is religion, Eliot. One can argue just as well that on the Internet your system will work best if it does not depend on typed links. Were you asking questions or giving the answers? | Relationships may be implicit in the data structure (i.e., the | hierarchical relationships defined by SGML markup) or explicit through | hyperlinks or other associative systems (i.e., relational databases). Now I'm completely confused about what you think a relationship type is. Why is all this prose necessary to ask what started out as a simple question? | semantic | The "meaning" associated with a type. The term "semantic" is dangerous | because it is overloaded and can mean different things in different | contexts. In this discussion, we are trying to clearly differentiate | meaning, which is abstract, from behavior, which is concrete. In general, | there is a one-to-one relationship between a type and its semantic, but a what type? How did you arrive at this generality? | a one-to-many relationship between a type and its possible behaviors. | In other words, a type's semantic doesn't change, but that semantic may | be interpreted into specific behaviors in a variety of ways depending on | the use to which the type is put or the arbitrary whim of the behavior | specifier. Pardon me if I sound testy, but linking doesn't have to be discussed in the impenetrable way it has been on this list the past month. Please try again, Eliot. Best 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 To: w3c-sgml-wg@www10.w3.org Subject: Re: Base <199701221936.LAA29878@ishtar.fsc.fujitsu.com> Date: Wed, 22 Jan 1997 13:44:00 -0700 From: Dave Hollander Forgive me for diverting the attention of the group. I intended the discussion about base merely as an example of the issues that Elliot has so clearly articulated. I too have no intention of defending or attacking the RFC or any web practice except as necessary to better understand the needs that will drive the decisions of this group. Dave Hollander Date: Wed, 22 Jan 1997 16:12:32 -0600 From: Len Bullard To: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions With the understanding that some aspects of relationship linking are declared out of scope for this discussion, the following is submitted=20 as an example of prior work on the concepts of relationship forms=20 based on the HyTime ilinks of that period. This is from the=20 extant MID documentation at http://navycals.dt.nav.mil/mid This source has the virtue that it is implemented and works=20 based on the HyTime of that time. So where one wants both=20 relationship maintenance and behavioral interoperability, it=20 serves as an example of a viable approach. A requirement of that project was that both relationships and=20 abstract look and feel behaviors needed to be portable. =20 Since for that project, behaviors were either interface behaviors, therefore easy to specify based on current windowing systems practices, and application behaviors=20 with regards to traversal based on scripts, it was straightforward=20 to create both architectural forms and element types to meet the =20 requirement using HyTime constucts. Note that behavioral=20 specifications even where relationship linking is used depend=20 a great deal on how state variables are treated. Say, duh. ********** From MID Application Guide ************* Transitions can be specified by an author to occur between infoContainers, or within an infoContainer to render new panes or controls. Types of transitions may include goto, gosub, or spawn. The difference between these transition types lies in the way the application handles the state of the currently-rendered containers. For example, a button on a pane within the infoContainer might contain a script that implements a=20 goto transition to infoContainer "IC-1." In this case, all non-global variables (e.g., those set by the infoContainer, or by a pane in the infoContainer)would be cleared,=20 and the state space would be set to represent the variables of the target=20 infoContainer. In a similar case where a gosub was specified in place of the goto, the source InfoContainer variables would be maintained, and then restored at the completion of rendering of the target "IC-2." Using a spawn would instruct the application to simultaneously maintain both sets of state variables.=20 By these mechanisms, an author has the ability to control the appearance of an application, without undue restriction on the application's unique look and feel.=20 A get element specifies that information at a source be retrieved, and rendered at the point of the get. This element represents one of the most significant abilities of the MID design. The get allows source documents, delivered and maintained independently, to be bound to the presentation at run-time. It also allows source documents to be in various formats, and still be accessible to a MID instance. The power of HyTime location and linking facilities is what makes this capability both practical and standard.=20 The relationship element is a construct, based on a HyTime ilink, that allows authors to establish connections between various types of information in a document. Relationship can be used to implement hotspots in text and graphics. The relationships in a MID document are located in the pool. Because the relationship element is based on a HyTime architectural form (i.e., ilink), multiple elements can be relationships without being called "relationship." Each of the elements derived from the MID relationship element will define a specific type of relationship, with the instances of that element linking information that is related in the defined way. Rendering of the relationships is up to the application; often the anchors of the relationship links will be treated as hotspots that can be selected by users, and traversed according to the rules of HyTime ilinks.=20 Relationships are based on named connections between related information. This enables the author to specify the reason for a particular link, in addition to specifying which objects are linked. Thus, the nature of the relationship is=20 transported from source to end-user.=20 Gosub indicates that the state of the current infoContainer be saved and the target object rendered. Gosub targets may be of the following types: infoContainer, chain, pane, conditionalPane, alert, mid. Gosub is forbidden to an infoContainer that is nested in another chain. Gosub is forbidden to a pane or conditionalPane that is nested in another infoContainer's client area or paneGroup. Goto indicates that the current infoContainer be abandoned immediately and the new infoContainer launched. Goto targets may be of the following types: chain, infoContainer, mid. Goto is forbidden to an infoContainer nested in another chain. Return values from objects which are targets of goto are lost, because there is nothing waiting on the returned value. A goto which targets this MID document is equivalent to a restart of this MID document. Spawn indicates that control flow splits. Spawned targets may be of the following types: infoContainer, chain, pane, conditionalPane, mid. Both parent and child compete for focus in the application display space. Spawn is forbidden to an infoContainer nested in another chain. Spawn is forbidden to a pane nested in a client area. Return values from spawned objects are lost, because there is nothing waiting on the returned value. When a spawn is encountered, control stops in the calling script, the target is flowed until it reaches an idle state, then the caller continues until it reaches an idle state.=20 get Get expresses that the information at the source be collected, concatenated, and rendered at the point of the get. =20 If space is specified, the members of a target aggregate will be delimited by a single space before the data is concatenated. If normalize is specified, leading and trailing white space is removed, and multiple contiguous spaces are converted into a single space. --> A =91get=92 element may point at (i.e., have as its content source) anoth= er get element,=20 and so on in a chain of indirection to the final data relationship The relationship form conforms to the architecture for a HyTime ilink. It expresses an authored relationship between two identified objects. The application must provide its own element and attribute declarations for hyperlinking according to the HyTime standard. This pseudo-declaration is provided as a model for the HyTime ilink. The generic identifier of the relationship governs the relationship semantic. The traversal semantic of the relationship is governed by the traversal attribute. If traversal is set to be undefined, traversal decisions will be left up to the application. Attributes may be added to change traversal from hotspot marking (interrupt) to hotspot information by request only (polling). This would prevent hotspot clutter in an on-line index, for example. Application of relationship applies to hotspots in text and graphics.=20 In the case of graphics, the identification of an object to link to is via a notation=20 (i.e., names of objects/zones must be available through a notloc). A relationship of traversal type =91gosub=92 to a script will be treated like a function call, except that the script is lexically contained only within the MID instance, not within the other end of the relationship, and not at its own location within the SGML instance (because its container might not have been flowed). Note that relationship is an architectural form. Date: Wed, 22 Jan 1997 11:16:23 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Status of XML-LINK strawman At this morning's ERB meeting, the XML-LINK editors reported that heavy workloads have slowed down their completion of the draft that is designed to begin our organized discussion of linking. They have set themselves a deadline of next Monday to deliver their first attempt to the WG. The editors declined to get into the details but assured us that they have carefully been monitoring the recent WG debates and that the draft they deliver on Monday is unlikely to contain any surprises. In the meantime, Eliot has agreed to start an interesting topic that we feel will contribute substantially to our understanding of some issues that go beyond the more detailed focus of the last few weeks. Stay tuned. Jon Date: Wed, 22 Jan 1997 17:45:33 -0900 To: cbullard@hiwaay.net, w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Relationship Taxonomy Questions At 04:12 PM 1/22/97 -0600, Len Bullard wrote: >With the understanding that some aspects of relationship linking are >declared out of scope for this discussion, the following is submitted >as an example of prior work on the concepts of relationship forms >based on the HyTime ilinks of that period. This is from the >extant MID documentation at http://navycals.dt.nav.mil/mid > >This source has the virtue that it is implemented and works >based on the HyTime of that time. So where one wants both >relationship maintenance and behavioral interoperability, it >serves as an example of a viable approach. The MID is interesting, both in the design approach and the fact that it works and is freely available (your tax dollars at work). I'm not convinced that the MID approach of using of hyperlinks that represent direct transition types is necessarily the best way to design such a thing. However, since it works, I certainly can't say it's a failed design. My personal feeling is that this problem would be better served by providing semantic (rather than behavioral) types for the relationships among information units and then appling transitional rules based on the semantic types. For example, in a procedure (which is what IETMs present), information units (steps, subprocedures, part descriptions, etc.) can be related based on their roles in the procedure: prerequisite, optional, explanatory, supporting, alternate, etc. These types represent the way the author of the procedure thinks about the the information (you must perform step 1 before step 2, you cannot skip step 3, procedure X is a prerequisite for procedure Y) and reflects the reality of the procedure. These relationship types then naturally translate into particular behaviors based on the *regulatory* implications of these semantic relationship (the whole point of IETMs being to enforce the codified rules for how maintenance procedures must be performed--i.e., if a step is prerequisite for another step, it is against military rules not to perform that step). Thus, instead of scripting the playback of a procedure, its playback should be inherent in the rhetorical relationships in the information (or in one use-scenario view of it) relative to a set of relationship-to-behavior mappings (ie. military rules vs. shadetree mechanic rules). But this is not intended to start an argument over ITEM and MID design (at least not here), only to show that there are different ways to think about link types and the relationship of link types to behaviors. There is definitely a continuum between purely behavior-related link types and purely semantic link types. But note that even in the MID, even though you have a link type of goto, the specific user interface expression of that link type is dependent on the configuration of the IETM viewer, so the MID doesn't really standardize the behavior specification, it just adds another layer of abstraction that further isolates the details of a particular behavior implementation from the data to which the behavior is applied. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Wed, 22 Jan 1997 17:25:14 -0900 To: Terry Allen , w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Relationship Taxonomy Questions At 12:41 PM 1/22/97 -0800, Terry Allen wrote: >Eliot purports to ask a set of questions: > >| The questions: >| >| Assuming that there is a distinction between link behavior and the >| relationship types that links represent, and in particular, a distinction >| between behavioral "primitives" and relationship "primitives": > >In view of the definitions below it's hard to say whether this >assumption is warranted. And you never define "primitives." You're right, I didn't. I think by primitives we mean either discrete building blocks that are combined to form complete wholes (e.g. "style primitives" such as font size, color, family, slant, etc.) or, in the case of types, fundamental taxonomic types or classifications ("archetypes?") >from which more specific types can be derived. We discussed the possibility of "relationship primitives" that would be combined to create new types, but Steve D. convinced us it was not tractable (and quite possibly not useful), at least in this forum. >| 1. Is it necessary or useful for XML to define some finite set of >| well-defined relationship types or primitives? > >Assuming you mean something straightforward, no. Defining >the semantics of relationships is not for a metalanguage. You always have to define some level of semantics--even SGML defines the semantics of "markup" and "data", "element" and "attribute". However, many of us feel XML needs to also provide at least a little bit of semantics in the form of an architecture for the representation of very common constructs, possibly including some sort of "starter set" document type that people can use immediately to create documents without having to also engineer style sheets and so on. Defining such a starter set doesn't preclude the use of any other document types, it simply makes the cost of entry lower for those for whom the starter set is sufficient. >| Our presumption, as yet unproved, is that the interoperation of XML >| documents within some general purview (e.g., the Web, as opposed to >| domain-specific purviews, such as a particular intranet) requires some >| basic set of link types whose meaning is well defined and understood. This > >What's a link type as opposed to behavioral and relationship primitives? >What is the "meaning" of a "link type"? For that matter, what is a >"link type"? Please give simple examples. A link type, as indicated above, is a relationship type (at least in this proposed model of link representation). The two are synonymous, because links represent relationships. The meaning of a type is the description of the relationship. If I have a link type of "foo", you have no idea what it means. But if I say a foo relationship associates a pet to its master in order to express ownership of the pet by the master, then you know that foo means "owned by" (or "owns" or "ownership"--however you prefer to state these things). If I then say I have another relationship "bar" that associates pets with their trainers, you know that a "bar" relationship means "trained by". I have defined two relationship types ("foo" and "bar") and defined their semantics ("ownership" and "instruction"). In XML, these relationships might look like this: A boy and his dog Bassets are headstrong and hard to train. I then realize that not just pets are owned and instructed, so I decide to generalize these concepts and refine "foo" to mean simply "owns" and "bar" to mean simply "instructs", partly because I want to distinquish my relationship to my dog (who I both own and train) and my students, who I train but don't own. I further specialize my relationships by adding distinct roles. In the generalized "foo" relationship, the roles might be simply "owned" and "owner". In the "master-of" relationship, derived from foo, the roles might be "pet" and "master". If I know "master-of" is derived from "foo", I can tell that master-of is a kind of ownership relationship and that the pet must be the thing owned (because it corresponds to the supertype role "owned") and the master must be the owner. I might express this like this: Relates owners of things to the things they own. Relates instructors to the beings they instruct (their students). Relates people (masters) to the pets they own.

Stuff I own

Note that all of this discussion has *nothing* to do with behavior. When I actually create a document relating pets to owners, there are any number of behaviors I might want associate with the different types and roles, depending on my mood, the user of the information, etc. But the behaviors don't change the nature of the relationships described. >And please leave out the red herring of an intranet; it will operate >on the same architectural principles as the Intranet. I simply meant that on the Internet, you can't generally predict who will be accessing your information, nor can you expect people to look at the copious documentation on your carefully-crafted relationship types. However, within an intranet, the information may support a specific business process where the relationship types are both well understood and critical to the use of the information (things like resource-to-project relationships, enterprise organization relationships, domain-specific relationships (chemicals to products to safety regulations to customer orders)). The underlying infrastructure architecture may be the same, but the uses to which that instrastructure will be put are, I think, fundamentally different much of the time (and one of the reasons that I think intranets are where XML will really shine and where the big money is to be made with all this stuff--right Len?) [...] >| We take it as a given that the set of possible relationship types is >| unbounded. > >So obviously no subset of them will be satisfactory, and we need a >general way to refer to them, whatever they are. No classification scheme can ever be complete. We're only wondering if it's necessary or useful to build the beginnings of one for link types. [The presentation I enjoyed most at last year's Hypertext conference was the closing keynote by the woman who described her research into the sociology of classification. The basic messages were "every useful scheme needs an 'other'" and "every classification exercise has political and social implications and constraints". Since SGML (and by extension, at least in my world, hyperlinking) are mostly about defining classification schemes, I found this presentation very enlightening. I recommend hunting up the proceedings and reading it. I'd provide a citation if I knew where my proceedings were.] >Cart before horse. The syntax serves to enable behavior; behavior should >be established first. We (the ERB) don't agree. Our feeling is that behavior and syntax are independent. Because many applications of XML will need the semantics but will provide their own behavior specification mechanisms, we feel that doing semantics first is the proper order. For example, given an XML-defined way to describe link semantics, I can figure out to translate that into HyTime terms and provide the resulting documents to Panorama, HyBrowse, and DynaText, all of which provide their own mechanisms for defining behavior. Therefore, XML's definition of behavior is largely irrelevant to any use I might put XML to in the near term, but link types are not. >| In the SGML model, behavior can be considered an aspect of "style" or >| presentation and may be defined explicitly through "style sheets" or >| "processing specifications" or may be embedded into a particular >| browser or processor (e.g., HTML browsers pre CSS). In this broad >| definition of the term style, mechanisms such as scripts, controls, >| and plug-ins could all be considered aspects of style specification. > >Or may be specified in a DTD or by labelling with well known semantics. >This is not a real useful definition of behavior. "Generally regarded >as poor practice" is your view, and you should label it as such. >| At this point we are assuming that behavior will be specified both in >| some normative way in an XML specification and, at user option, through >| some as-yet-undetermined behavior specification system or systems (e.g. >| "link style sheet"). > >Eh? the user gets to change the behavior of the links in the document I >sent him? That's a new one. Though perhaps your overbroad definition >of behavior renders the issue moot. The only way you can *ever* ensure a particular behavior for a document is to render it through a closed system. As XML is designed specifically to enable the networked interchange of documents, any energy spent worrying about users changing behavior of presented documents is wasted. If you want "my way or nothing", use Acrobat. > >"Poor practice" is religion, Eliot. One can argue just as well that on >the Internet your system will work best if it does not depend on typed links. >Were you asking questions or giving the answers? Didn't I say that untyped (or rather, links with uselessly general types) links are fine when that's all you need? "On the Internet" is meaningless. You can only evaluate data with respect to the uses to which it is put. The Internet is a delivery infrastructure and implies no use scenarios whatsoever. When I'm pulling down finding aids from the Duke University Library over the Internet, I care very much that they've gone to great effort to create documents with rich semantics and typed relationships, because that information is intended to help me retrieve efficiently. When I'm pulling across the visual noise of the cool site of the hour, I don't care at all. We need typed and untyped links, always have, always will. >| semantic >| The "meaning" associated with a type. The term "semantic" is dangerous >| because it is overloaded and can mean different things in different >| contexts. In this discussion, we are trying to clearly differentiate >| meaning, which is abstract, from behavior, which is concrete. In general, >| there is a one-to-one relationship between a type and its semantic, but > >a what type? How did you arrive at this generality? It's the freakin' definition of type: a label for a set of semantics. Or would you prefer a Dadaist approach to type definition? Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Wed, 22 Jan 1997 16:29:36 -0800 (PST) From: Terry Allen To: eliot@isogen.com, tallen@fsc.fujitsu.com, w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions Executive summary: Plain Language still needed Eliot responds in good humor: | You're right, I didn't. I think by primitives we mean either discrete | building blocks that are combined to form complete wholes (e.g. "style | primitives" such as font size, color, family, slant, etc.) or, in the case | of types, fundamental taxonomic types or classifications ("archetypes?") | from which more specific types can be derived. We discussed the | possibility of "relationship primitives" that would be combined to create | new types, but Steve D. convinced us it was not tractable (and quite | possibly not useful), at least in this forum. Without examples, this isn't much help. | >| 1. Is it necessary or useful for XML to define some finite set of | >| well-defined relationship types or primitives? | >Assuming you mean something straightforward, no. Defining | >the semantics of relationships is not for a metalanguage. | You always have to define some level of semantics--even SGML defines the | semantics of "markup" and "data", "element" and "attribute". However, many Which are not relationships. I said "semantics of relationships." | of us feel XML needs to also provide at least a little bit of semantics in | the form of an architecture for the representation of very common | constructs, possibly including some sort of "starter set" document type | that people can use immediately to create documents without having to also | engineer style sheets and so on. Defining such a starter set doesn't | preclude the use of any other document types, it simply makes the cost of | entry lower for those for whom the starter set is sufficient. Certainly XML should not define XML DTDs. I don't know what you mean by "an architecture for the representation of very common constructs." | >| Our presumption, as yet unproved, is that the interoperation of XML | >| documents within some general purview (e.g., the Web, as opposed to | >| domain-specific purviews, such as a particular intranet) requires some | >| basic set of link types whose meaning is well defined and understood. This | >What's a link type as opposed to behavioral and relationship primitives? | >What is the "meaning" of a "link type"? For that matter, what is a | >"link type"? Please give simple examples. | A link type, as indicated above, is a relationship type (at least in this | proposed model of link representation). The two are synonymous, because | links represent relationships. The meaning of a type is the description of | the relationship. You never defined "relationship type," either. But see next. | If I have a link type of "foo", you have no idea what it means. But if I | say a foo relationship associates a pet to its master in order to express | ownership of the pet by the master, then you know that foo means "owned by" | (or "owns" or "ownership"--however you prefer to state these things). If I | then say I have another relationship "bar" that associates pets with their | trainers, you know that a "bar" relationship means "trained by". I have | defined two relationship types ("foo" and "bar") and defined their | semantics ("ownership" and "instruction"). So a relationship type is a relationship ("bar" is both a relationship and a relationship type). Then everything you write comes down to the assertion that links somehow represent relationships. I infer that you also want to key application behavior off the labels for relationships that you attach to links. XML 1.0 doesn't forbid you to do that, but I certainly don't want that to be required. And specifying a list of relationships is out of scope for XML, although it might be meritorious activity on its own. I at least don't want to tie XML to any particular set of relationship labels. [long example of a relationship Eliot is surely not proposing to be standardized deleted] | Note that all of this discussion has *nothing* to do with behavior. When I | actually create a document relating pets to owners, there are any number of | behaviors I might want associate with the different types and roles, | depending on my mood, the user of the information, etc. But the behaviors | don't change the nature of the relationships described. And I might want to do the reverse, assigning different behaviors to occurrences of the same relationship labels. Aside from that, these labels are really elements and attributes, and I can assign behavior directly to them if I want. You seem to be assuming one architecture among many possible ones. [...] | >| We take it as a given that the set of possible relationship types is | >| unbounded. | >So obviously no subset of them will be satisfactory, and we need a | >general way to refer to them, whatever they are. | No classification scheme can ever be complete. We're only wondering if | it's necessary or useful to build the beginnings of one for link types. | [The presentation I enjoyed most at last year's Hypertext conference was | the closing keynote by the woman who described her research into the | sociology of classification. The basic messages were "every useful scheme | needs an 'other'" and "every classification exercise has political and | social implications and constraints". Since SGML (and by extension, at | least in my world, hyperlinking) are mostly about defining classification | schemes, I found this presentation very enlightening. I recommend hunting | up the proceedings and reading it. I'd provide a citation if I knew where | my proceedings were.] I think that speaks for itself. This is definitely out of scope for a metalanguage. | >Cart before horse. The syntax serves to enable behavior; behavior should | >be established first. | | We (the ERB) don't agree. Our feeling is that behavior and syntax are | independent. Because many applications of XML will need the semantics but | will provide their own behavior specification mechanisms, we feel that | doing semantics first is the proper order. ? I need to be able to specify the behaviors that Len's MID example did (and did quite independently from its specification of relationships): traversal ( gosub | spawn | goto ) I need to know those behaviors will work interoperably, and I cannot rely on applications that "provide their own behavior specification". If the ERB thinks that's going to work, I ask it to reconsider. And I need whatever syntax is required to support specification of those behaviors (perhaps none at all). I can already specify relationship labels if I wish. | For example, given an XML-defined way to describe link semantics, I can Now what are "link semantics"? | figure out to translate that into HyTime terms and provide the resulting | documents to Panorama, HyBrowse, and DynaText, all of which provide their | own mechanisms for defining behavior. Therefore, XML's definition of | behavior is largely irrelevant to any use I might put XML to in the near | term, but link types are not. ? Given whatever way XML or XML users describe links, you will be able to translate it into whatever you want. | >| In the SGML model, behavior can be considered an aspect of "style" or | >| presentation and may be defined explicitly through "style sheets" or | >| "processing specifications" or may be embedded into a particular | >| browser or processor (e.g., HTML browsers pre CSS). In this broad | >| definition of the term style, mechanisms such as scripts, controls, | >| and plug-ins could all be considered aspects of style specification. | > | >Or may be specified in a DTD or by labelling with well known semantics. | >This is not a real useful definition of behavior. "Generally regarded | >as poor practice" is your view, and you should label it as such. | | >| At this point we are assuming that behavior will be specified both in | >| some normative way in an XML specification and, at user option, through | >| some as-yet-undetermined behavior specification system or systems (e.g. | >| "link style sheet"). | > | >Eh? the user gets to change the behavior of the links in the document I | >sent him? That's a new one. Though perhaps your overbroad definition | >of behavior renders the issue moot. | | The only way you can *ever* ensure a particular behavior for a document is | to render it through a closed system. As XML is designed specifically to The user cannot change the semantics of an HTTP URL, nor can he change the semantics of HTML's A element. If XML specifies traversal ( gosub | spawn | goto ) and that XML apps have to respect those semantics to be conformant, the user will not be able to change the behavior of my document in an XML app. | enable the networked interchange of documents, any energy spent worrying | about users changing behavior of presented documents is wasted. If you | want "my way or nothing", use Acrobat. Or Netscape, or Explorer, or Spyglass, etc. [ ... ] | >| semantic | >| The "meaning" associated with a type. The term "semantic" is dangerous | >| because it is overloaded and can mean different things in different | >| contexts. In this discussion, we are trying to clearly differentiate | >| meaning, which is abstract, from behavior, which is concrete. In | general, | >| there is a one-to-one relationship between a type and its semantic, but | > | >a what type? How did you arrive at this generality? | | It's the freakin' definition of type: a label for a set of semantics. Or | would you prefer a Dadaist approach to type definition? Oh, then "in general" is just useless verbiage. I see. Again, I invite to state plainly what it is you're asking for. I suggest that it should take no more than 20 lines, plus your list of your favorite relationships. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Date: Wed, 22 Jan 1997 20:03:00 -0500 To: w3c-sgml-wg@www10.w3.org From: davep@acm.org (Dave Peterson) Subject: Re: questions on XML sgml decl's charsets At 12:05 PM 1/13/97, Paul Grosso wrote: >Looking at the SGML decl in the appendix of the XML draft, I have >a few questions. (I'll admit up front that if there is anything >that boggles my mind more than BOSs, it's character sets.) >And how do all this square with the ERCS stuff WG8 recently approved? At the risk of screwing up once again trying to work from memory...I don't recall that the ERCS stuff involved the description of character sets at all--it dealt with alternate ways to make large numbers of characters name characters, name-start characters, or whatever. Dave Peterson SGMLWorks! davep@acm.org From: Paul Prescod Subject: Re: Relationship Taxonomy Questions To: tallen@fsc.fujitsu.com (Terry Allen) Date: Wed, 22 Jan 1997 21:44:53 -0500 (EST) Cc: eliot@isogen.com, tallen@fsc.fujitsu.com, w3c-sgml-wg@www10.w3.org > ? I need to be able to specify the behaviors that Len's MID example > did (and did quite independently from its specification of relationships): > > traversal ( gosub | spawn | goto ) > > I need to know those behaviors will work interoperably, and I cannot > rely on applications that "provide their own behavior specification". > If the ERB thinks that's going to work, I ask it to reconsider. And > I need whatever syntax is required to support specification of > those behaviors (perhaps none at all). I can already specify > relationship labels if I wish. You need to be able to make a gosub happen, just as document authors need to be able to make a "large heading" happen. But "the SGML way" (as you know better than anyone) is to think about the structure of the document before thinking about the "formatting behaviours" you intend to apply to it. Why not the same with linking behaviours? If we follow the formatting analogy to its conclusion, linking would be done by a processing specification, (stylesheet) just as formatting is. Which would mean that linking behaviour is part of our next section, not this one. (Maybe...the definition of stylesheet is vague enough to do it now or then). > The user cannot change the semantics of an HTTP URL, nor can he change > the semantics of HTML's A element. Semantics, no. Behaviour yes. A user could specify that "A" links are green, intead of blue. And when they are clicked on they are downloaded, but not displayed. In fact a web walker is a "user agent" that *does* implement link behaviour significantly different than a browser. >If XML specifies > > traversal ( gosub | spawn | goto ) > > and that XML apps have to respect those semantics to be conformant, > the user will not be able to change the behavior of my document > in an XML app. But what about the web-walker? Web-downloader? Search agent? Aren't those user agents? Can't they change the behaviour? What about tools that show you tables of contents for documents and their links. Can't I randomly choose a document from my "site link map" rather than going through a page and executing the "goto?" As far as whether we should specify some relationships up front, I have two contributions: #1. Maybe HyTime would be more widely used if it were less Meta and more language. That sounds like a slam against HyTime but it isn't. Scheme might be more widely used if it were less functional and more like Java, but then it wouldn't be useful for the important uses it is used for (whew!), like DSSSL. Maybe XML is where we take HyTime to the masses by being a little less meta. #2. HTML left the link relationships "wide open" and we are still waiting for people to decide on the relationships. I don't see a problem with <-XML-GOTO> or <-XML-STYLE-SHEET> or <-XML-NEXT-DOCUMENT>, etc. *Maybe* we could specify them in an appendix, or another document, but I think that they should be specified by this group. I would not have a problem with a "layered specifications" approach that defined a link architecture in a separate document that might or might not be required. Paul prescod Date: Wed, 22 Jan 1997 20:02:55 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: Relationship Taxonomy Questions (Executive summary: You can skip this.) Since silence from ERB members seems to be taken as indicating a hidden agenda, I guess I'll have to state for the record that I agree with almost everything that Eliot has said in his first couple of messages in this thread. (The odd phrasing at the end of that sentence is due to the fact that my postings are sometimes taking three or four hours to reach the list, so I don't know whether I will be agreeing with whatever Eliot is saying by the time this is read.) I will even go beyond that and venture a couple of opinions of my own, some of which Eliot may agree with and some of which he may not. 1. Contra some statements which have been made by various people over the last little while, it is not enough for XML to specify pure syntax. XML has to *interoperate*. No shared semantics, no interoperation. The interesting, deep, and dangerous question is, which semantics are the right ones to share? 2. I am quite convinced (and was before the ERB asked Eliot to start this thread) that it is vital to make a strong distinction between * Link structure or topology (one-to-one, one-to-many, etc.; independent, contextual, (possibly more)) * Linkend location/addressing * Link meaning, which to me is effectively the same as relationship typing (owner-of, parent-of, see-ref-to, etc.) * Link behavior, which can be divided into A. What the user sees: Presentation before link traversal Presentation during link traversal Presentation after link traversal B. What the system sees: State before link traversal State during link traversal State after link traversal I personally have never seen anything specified in connection with a link that could not be subsumed under some combination of these categories; if anyone else can think of something, I sure would like to know what it is. 2'. In particular, I think that it is of the utmost importance to distinguish meaning (relationship typing) from behavior (which includes presentation). I think that the analogy between semantic tagging vs. style information in SGML and relationship typing vs. link behavior is an apt and powerful one. So I am opposed to schemes that collapse the distinction, for example by using traversal types such as goto, etc., and prevent me from operating on meaning and presentation as separate aspects of the document, just as I would be opposed to collapsing the analogous distinction in SGML, and for essentially the same reasons. The preceding comments have added virtually nothing to this discussion, but I hope that I have satisfactorily discharged my obligation as a member of the ERB to put my position on record. Jon Date: Wed, 22 Jan 1997 22:08:08 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Relationship Taxonomy Questions At 09:44 PM 1/22/97 -0500, Paul Prescod wrote: >As far as whether we should specify some relationships up front, I have two >contributions: > >#1. Maybe HyTime would be more widely used if it were less Meta and more >language. That sounds like a slam against HyTime but it isn't. Scheme might >be more widely used if it were less functional and more like Java, but then >it wouldn't be useful for the important uses it is used for (whew!), like >DSSSL. Maybe XML is where we take HyTime to the masses by being a little >less meta. Exactly. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Wed, 22 Jan 1997 20:35:08 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: Relationship Taxonomy Questions [Paul Prescod:] | If we follow the formatting analogy to its conclusion, linking would | be done by a processing specification, (stylesheet) just as formatting | is. Which would mean that linking behaviour is part of our next | section, not this one. (Maybe...the definition of stylesheet is vague | enough to do it now or then). Mightily as I have striven to keep the discussion of stylesheets out of this phase of the Activity, it is apparent that we can't step around the question of whether link behavior should properly be specified in stylesheets; we will have to confront this issue before we can finish a link specification. But to maintain focus, it should be considered later as a separate question. Jon Date: Thu, 23 Jan 1997 04:38:45 -0800 To: w3c-sgml-wg@www10.w3.org From: Tim Bray Subject: Re: Base At 01:44 PM 22/01/97 -0700, Dave Hollander wrote: >Forgive me for diverting the attention of the group. I intended the >discussion about base merely as an example of the issues that Elliot >has so clearly articulated. Well sorry, Dave, but I don't think this issue should be un-raised. I went to bat for a clearer interpretation of BASE quite some time ago back when HTML-WG was still kind of useful; the discussion at that point taught me that there is no consensus as to what the specs mean and how this should be used; thus in the HTML world, it is de fact broken. At the time I was a robot writer and my robot was looking for help in de-duping, i.e. how many slightly-variant mirror copies of the Jargon file do you really want to index? But beyond this narrow interest, I then believed, and still do, strongly, that it would be useful for there to be a standard way for an object to assert "Here is the canonical address which I request to be used in retrieving the object you are now reading". Use in hot-lists and by crawlers being just two obvious applications. I think this would be a highly useful, cheap-to-specify, easy-to-implement item to put in XML-LINK. Any reason not to do this? - Tim Date: Thu, 23 Jan 1997 07:17:16 -0600 From: len bullard To: Jon Bosak CC: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions Jon Bosak wrote: > > So I am opposed to schemes that > collapse the distinction, for example by using traversal types such as > goto, etc., and prevent me from operating on meaning and presentation > as separate aspects of the document, just as I would be opposed to > collapsing the analogous distinction in SGML, and for essentially the > same reasons. So you oppose this bit of applet magic: getBrowser(aCompletelyDifferentApplet, "frame2", 0); Interesting. Puts you in a pretty small minority at Sun. len > The preceding comments have added virtually nothing to this > discussion, but I hope that I have satisfactorily discharged my > obligation as a member of the ERB to put my position on record. > > Jon Date: Thu, 23 Jan 1997 08:52:51 -0600 From: Len Bullard To: "W. Eliot Kimber" CC: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions W. Eliot Kimber wrote: > "Rats in the morning, rats in the afternoon...if they don't go away, I'll be > re-educated soon..." --Austin Lounge Lizards, "1984 Blues" "Imagination is more important than knowledge" said Mr. Einstein; on the other hand, eventually someone has to write code. E. Kimber - "The ERB would like to ask the list to address the following questions relating to relationship (link) typing.."" So ask. E. Kimber - "... the interoperation of XML documents without some general purview..." Abstract domain? "(eg. the Web as opposed to domain-specific purviews such as a particular intranet.." Those are application systems, not "purviews". One has a range of applications which currently interoperate based on the use of the URL specification and predefined schemes which in practice, work out to be network protocols. Within a given application framework, inter-object messaging is provided by the API for that framework.... err.. messages and functions. Also provided was a basic application language for defining a format oriented structure which included a set of hyperlink types whose functional implementation was specified by the scheme (get, post, etc.). "... requires some basic set of link types whose meaning is well defined and understood.." Implementable? "... typing links is in fact a useful thing to do for some types of information..." A non-abstract domain of links implementable in a system? Or abstract? "We take it as a given that the set of possible relationship types is unbounded.." Hmm. A domain without a range.: non-implementable. Perhaps an abstract class is meant here which roots the tree but is non-instantiable except in the subclasses. "Can these types be considered supertypes... used to define a class hierarchy.." Ok. If you want inheritance of data and methods, that sounds like a good idea. Not a new one to be sure. "Is there a preferred formalism by which the meaning of relationship types should be expressed ... can include a behavior specification." Ah. That's clear. Sure. On the system you propose as the domain, "The Web" that is Java and a some *useless* languages like... C++. So far, this becomes MID 0.1 a la Vancouver: how to recreate object-oriented programming with pointy brackets. We got badly beaten up for trying that by top members of the SGML community. That was why we punted to an application language that worked, met the requirements of the customers and got the "not invented here" folks off our backs. "The issue of behavior primitives is not open for discussion..." Lots of luck on that one. Interoperation is behavior usually achieved with messages and overloaded functions in OOPs. Portability is file schlepping. The joy for the programming community on the Web in seeing Java was they had a chance to get portability and interoperability. Given the rush to extend the virtual machines, that may be short-lived ecstasy. Sun says they can propose ways to overcome this, and we are all waiting for the licensing costs for that. Business as usual. A bit of computer science lore might help this discussion. This lore has the virtue of having been adopted by the community that has to write the code. Source: "Fundamentals of Data Structures", Horowitz and Sahni, 1977. A bit dated but clearer than what we have now. "Data type: kinds of data variables may hold, e.g, integer, real, logical, character.. language allows variables to name data of that type and provides a set of operations which meaningfully manipulates these variables... there are features which allow one to construct combinations of built-in types... structure... record... however it is not necessary to have such a mechanism.." "Data object: a term referring to a set of elements say D. For example, the data object integers refers to D={0, +-1, ...}... D may be finite of infinite and if D is very large, we may need to devise special ways of representing its elements..." The important bit: "The notion of a data structue as distinguished from a data object is that we want to describe not only the set of objects, but the way they are related. Saying this another way, we want to describe the set of operations which may legally be applied to elements of the data object. This implies we must specify the set of operations and show how they work." In short: "A data structure is a set of domains, a designated domain, a set of functions, and a set of axioms... the set of axioms describe the semantics of the operations... An implementation of a data structure is a mapping from d to a set of other data structures e.. this mapping specifies how every object of d is to be represented by the objects of e. Secondly it requires that every function of d must be written using the functions of the implementing data structures e... The triple (DFA) is referred to as an abstract data type ... precisely because the axioms do not imply a form of representation... the implementation of a data structure... is the process of refining an abstract data type until all of the operations are expressible in terms of directly executable functions." If y'all want this XML thing to be adopted, make sure the language is precise. Otherwise, we are back in Seattle with all of those blank stares. len Date: Thu, 23 Jan 97 09:23:54 CST From: Michael Sperberg-McQueen Subject: Re: Base To: W3C SGML Working Group On Thu, 23 Jan 1997 07:47:53 -0500 Tim Bray said: >At the time I was a robot writer and my robot was looking for help in >de-duping, i.e. how many slightly-variant mirror copies of the Jargon file >do you really want to index? But beyond this narrow interest, I then >believed, and still do, strongly, that it would be useful for there >to be a standard way for an object to assert "Here is the canonical >address which I request to be used in retrieving the object you are now >reading". Use in hot-lists and by crawlers being just two obvious >applications. I think this would be a highly useful, cheap-to-specify, >easy-to-implement item to put in XML-LINK. I half agree and half violently disagree. Maybe it's just the wording. >Any reason not to do this? - Tim Yeah: often there *is* no canonical address stuff should be retrieved by: if you're on the East Coast get it from the site in North Carolina; if on the West Coast, from the Petaluma site; if in Europe, from Oxford; if ... It seems to me that what one needs for deduping is a unique identifier: i.e. an (F)PI or a URN. Would the problem of deduping not be solved just by allowing a doc to say 'By the way, this is my FPI'? Or have I misunderstood? Michael > Date: Thu, 23 Jan 1997 07:33:12 -0800 (PST) From: Terry Allen To: papresco@calum.csclub.uwaterloo.ca, tallen@fsc.fujitsu.com Subject: Re: Relationship Taxonomy Questions Cc: eliot@isogen.com, w3c-sgml-wg@www10.w3.org Paul Prescod wrote: | > ? I need to be able to specify the behaviors that Len's MID example | > did (and did quite independently from its specification of relationships): | > | > traversal ( gosub | spawn | goto ) | > | > I need to know those behaviors will work interoperably, and I cannot | > rely on applications that "provide their own behavior specification". | > If the ERB thinks that's going to work, I ask it to reconsider. And | > I need whatever syntax is required to support specification of | > those behaviors (perhaps none at all). I can already specify | > relationship labels if I wish. | | You need to be able to make a gosub happen, just as document authors need | to be able to make a "large heading" happen. But "the SGML way" (as you know | better than anyone) is to think about the structure of the document before | thinking about the "formatting behaviours" you intend to apply to it. Why | not the same with linking behaviours? I need to be sure it happens, and mapping behavior to some label on a element is only one way to do it. There is more than one SGML way to skin a cat. And in response to Jon's clear statement, I certainly don't want to forbid him from taking this approach, and there is nothing in XML 1.0 to prevent him from using it, but I don't want to be *required* to use it. Put another way, I need to be able to bind link behavior to my document, and I want to be able to describe relationships that do not map to behaviors. | If we follow the formatting analogy to its conclusion, linking would be | done by a processing specification, (stylesheet) just as formatting is. | Which would mean that linking behaviour is part of our next section, not | this one. (Maybe...the definition of stylesheet is vague enough to do it now | or then). | | > The user cannot change the semantics of an HTTP URL, nor can he change | > the semantics of HTML's A element. | | Semantics, no. Behaviour yes. A user could specify that "A" links are green, | intead of blue. That is the rendering of the text content of the link, not the behavior we were talking about. | And when they are clicked on they are downloaded, but not | displayed. If part of my document's text is included through a link, *and the document is being displayed*, the included text must be displayed when downloaded so as to display the full text as I intended it, complete with safety warnings, etc. Else I can't rely on my data format to convey my content, and the XML format is useless for practical purposes, however interesting it may be for hypertext theory. | In fact a web walker is a "user agent" that *does* implement | link behaviour significantly different than a browser. It doesn't display any link behavior or the underlying document to the user, however. | >If XML specifies | > | > traversal ( gosub | spawn | goto ) | > | > and that XML apps have to respect those semantics to be conformant, | > the user will not be able to change the behavior of my document | > in an XML app. | | But what about the web-walker? Web-downloader? Search agent? Aren't those | user agents? Can't they change the behaviour? What about tools that show | you tables of contents for documents and their links. Can't I randomly They have to distinguish beween traversal and inclusion links, else they can't represent the document properly, even in outline. Note that we don't have text inclusion in HTML. | choose a document from my "site link map" rather than going through a page | and executing the "goto?" Your site link map is not my XML document. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Date: Thu, 23 Jan 1997 09:34:58 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Base At 04:38 AM 1/23/97 -0800, Tim Bray wrote: I then >believed, and still do, strongly, that it would be useful for there >to be a standard way for an object to assert "Here is the canonical >address which I request to be used in retrieving the object you are now >reading". Use in hot-lists and by crawlers being just two obvious >applications. I think this would be a highly useful, cheap-to-specify, >easy-to-implement item to put in XML-LINK. > >Any reason not to do this? - Tim The only time I can see this being a problem is when an object *doesn't have* a cannonical position, or the one it has changes frequently. But even then, you can use indirection (e.g., FPIs or URNs) to hide the change in actual location. I know the issue of putting document's public indentifiers inside them has been discussed in some forum in the past (I dimly remember discussing it with Steve DeRose). One problem with SGML is that document entities are not self describing in that they don't normally carry their own canonical names with them (i.e., their public identifiers). Thus, you must always have some other object that catalogs documents (i.e., a document management system, even if it's only an SGML Open catalog that lists all the documents in the "system". Of course, when the system is unbounded, that's a bit difficult. Let me add to this question: should the SGML standard add syntax to bind document entities to their external identifiers (which would, by the definition of external identifier, include both system IDs (and thus, potentially, URLs or URNs) and publid identifiers)? Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Thu, 23 Jan 1997 07:46:21 -0800 (PST) From: Terry Allen To: papresco@calum.csclub.uwaterloo.ca, tallen@fsc.fujitsu.com Subject: Re: Relationship Taxonomy Questions Cc: eliot@isogen.com, w3c-sgml-wg@www10.w3.org I wrote: >Put another way, I need to be able to bind link behavior to my document, and I want to be able to describe relationships that do not map to behaviors. I meant "behaviors that do not map to relationships" (also). Regards, Terry Date: Thu, 23 Jan 1997 09:54:44 -0900 To: cbullard@hiwaay.net From: "W. Eliot Kimber" Subject: Re: Relationship Taxonomy Questions Cc: w3c-sgml-wg@www10.w3.org At 08:52 AM 1/23/97 -0600, Len Bullard wrote: >Those are application systems, not "purviews". One has a range of >applications which currently interoperate based on the use of the URL >specification and predefined schemes which in practice, work out to >be network protocols. Len and I are using the term "application" in different ways. By "application" I mean it in the SGML and database sense, meaning a collection of data of specific types and semantics to which processing is applied, rather than the processors themselves. If I understand Len's use, he means the actual system used to implement the application. Many programmers don't make a distinction between these two uses: the software is inseparable from the data in their mind. But this is a self-defeating mindset because data tends to outlive software, thus binding data to software to closely ensures the obsolescance of the data. Within a given application framework, >inter-object >messaging is provided by the API for that framework.... err.. messages >and >functions. I think there's a basic disconnect here. The purpose of XML is to define *data representation languages*, not functional ("programming") languages. Hyperdocuments are not programs any more than relational databases are programs. Thus, issues of "API", "messaging", "functions", etc. are not relevant to the discussion of hyperlink *representation*. They are, of course, directly relevant to the issue of hyperlink *implementation*: applying behavior to links, just as they are to the issue of SGML document processing implementation in general. But there will be many different implementations for the same documents: that's the whole reason for using indirections like SGML in the first place. If you focus too quickly on implementation details without first defining the overall data model, you run a serious risk of building a self-limiting system. Remember: there's no difference between a hyperlink represented in an abstract data representation scheme and any other element type except the type of processing that *might* be associated with it. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Thu, 23 Jan 1997 10:14:43 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Relationship Taxonomy Questions At 07:33 AM 1/23/97 -0800, Terry Allen wrote: >Paul Prescod wrote: [...] >| And when they are clicked on they are downloaded, but not >| displayed. > >If part of my document's text is included through a link, *and the >document is being displayed*, the included text must be displayed when >downloaded so as to display the full text as I intended it, complete >with safety warnings, etc. Else I can't rely on my data format to >convey my content, and the XML format is useless for practical >purposes, however interesting it may be for hypertext theory. But you can't *ever* do this with SGML or XML or any other generalized format unless you control both the server and browser. Even on the Web I can change almost all aspects of the presentation of the pages I get, except for that stuff that's in an opaque format (controls, graphics, java scripts, etc.). If you want this level of control, downtranslate the XML to PDF and use Acrobat or do what Microsoft does and use SGML to construct closed CD-ROMs or define a specific protocol for delivering information that must be viewed exactly as intended (e.g., IETMs). No generalized data representation scheme can *ever* guarantee behavior of any sort--that can only be done by defining the specific presentation and delivery system and then ensuring that end users have no facility for modifying any part of the system--in other words, unless the data is delivered as a single, opaque, unconfigurable black box, all bets are off. Asking for the above is like expecting a security attribute to prevent people from looking at data they don't have clearance for. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Thu, 23 Jan 1997 10:16:49 -0900 To: Terry Allen , papresco@calum.csclub.uwaterloo.ca, tallen@fsc.fujitsu.com From: "W. Eliot Kimber" Subject: Re: Relationship Taxonomy Questions Cc: w3c-sgml-wg@www10.w3.org At 07:33 AM 1/23/97 -0800, Terry Allen wrote: >And in response to Jon's clear statement, I certainly don't want to >forbid him from taking this approach, and there is nothing in XML 1.0 >to prevent him from using it, but I don't want to be *required* to use it. > >Put another way, I need to be able to bind link behavior to my document, >and I want to be able to describe relationships that do not map >to behaviors. But nothing in this proposal prevents any of that. Your link types can be as general or as specific as you like. By the same token, the application of behavior need not take link types into account. For example, Panorama gives you *no mechanism* for conditioning link behavior based on type: anything that's a HyTime clink behaves in exactly the same way. HyBrowse, by contrast, provides a default behavior for all links, but lets you further condition behavior based on types and roles within types. DynaText lets you do any damn thing you want, including giving hyperlink behavior to elements that were not originally intended to be hyperlinks. All we're saying is that we don't want XML's link representation scheme to be *limited* to behavior-only links. We also recognize two facts: 1. Most people familiar with linking are not familiar with the use of typed links, because most systems either don't provide or support types at all or the support for types is weak or inconsistently implemented (e.g., the Web). 2. The use of typed links is a potentially very powerful information representation technique (witness relational databases) that adds significant added value to the use of SGML (and by extension, XML). Given these two facts, we presume that it would be a useful service of XML to both provide a well-defined and robust means of defining typed links and provide a starter set of such types to demonstrate their utility and power to the unaware. That doesn't mean that every link has to be a well-thought-out type and more than every element type in an XML DTD has be completely descriptive of its content. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Thu, 23 Jan 1997 08:26:45 -0800 (PST) From: Terry Allen To: eliot@isogen.com, papresco@calum.csclub.uwaterloo.ca, tallen@fsc.fujitsu.com Subject: Re: Relationship Taxonomy Questions Cc: w3c-sgml-wg@www10.w3.org Eliot: | All we're saying is that we don't want XML's link representation scheme to | be *limited* to behavior-only links. We also recognize two facts: What you were saying is that you want to specify a set of relationship labels. I think the taxomony of relationships is orthogonal to the mechanism for using them, and competition among different taxonomies should be encouraged, hence XML itself should not specify a taxonomy. You have not given a single example of a label you want to specify. Please do so. Regards, Terry Date: Thu, 23 Jan 1997 08:32:49 -0800 (PST) From: Terry Allen To: eliot@isogen.com, w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions Eliot, please reread this thread and contemplate how the Web works now, successfully distinguishing traversal links from inclusion links. Practical requirements are real and successful systems make it possible to implement them. >From w3c-sgml-wg-request@www10.w3.org Thu Jan 23 08:26 PST 1997 Date: Thu, 23 Jan 1997 10:14:43 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Relationship Taxonomy Questions At 07:33 AM 1/23/97 -0800, Terry Allen wrote: >Paul Prescod wrote: [...] >| And when they are clicked on they are downloaded, but not >| displayed. > >If part of my document's text is included through a link, *and the >document is being displayed*, the included text must be displayed when >downloaded so as to display the full text as I intended it, complete >with safety warnings, etc. Else I can't rely on my data format to >convey my content, and the XML format is useless for practical >purposes, however interesting it may be for hypertext theory. But you can't *ever* do this with SGML or XML or any other generalized format unless you control both the server and browser. Even on the Web I can change almost all aspects of the presentation of the pages I get, except for that stuff that's in an opaque format (controls, graphics, java scripts, etc.). If you want this level of control, downtranslate the XML to PDF and use Acrobat or do what Microsoft does and use SGML to construct closed CD-ROMs or define a specific protocol for delivering information that must be viewed exactly as intended (e.g., IETMs). No generalized data representation scheme can *ever* guarantee behavior of any sort--that can only be done by defining the specific presentation and delivery system and then ensuring that end users have no facility for modifying any part of the system--in other words, unless the data is delivered as a single, opaque, unconfigurable black box, all bets are off. Asking for the above is like expecting a security attribute to prevent people from looking at data they don't have clearance for. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" From: lee@sq.com Date: Thu, 23 Jan 97 11:42:14 EST To: tbray@textuality.com, w3c-sgml-wg@www10.w3.org Subject: Re: Base > "Here is the canonical > address which I request to be used in retrieving the object you are now > reading". Another equally valid interpretation has already been given -- "Here is the name by which I prefer to be known, even if it is not a valid address for me." In neither case can you be sure that two files with the same canonical address are in fact the same, since it is maintained by humans. I think it may give people a false sense of security, and I don't see that it helps a robot. I _do_ see that "here is the base against which partial URLs should be constructed if you have to go out and fetch another document" is useful, and if fact essential for use in environments where documents are stored in databases, or for serving up the result of a query. Panorama's processing instruction gives _an_ address by which the given document might have been fetched, and that will be used for bookmarks. It doesn't have to be in any sense canonical or blessed. Lee Date: Thu, 23 Jan 1997 10:30:01 -0600 From: Len Bullard To: "W. Eliot Kimber" CC: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions W. Eliot Kimber wrote: > > At 08:52 AM 1/23/97 -0600, Len Bullard wrote: > > >Those are application systems, not "purviews". One has a range of > >applications which currently interoperate based on the use of the URL > >specification and predefined schemes which in practice, work out to > >be network protocols. > > Len and I are using the term "application" in different ways. Third person. Yo! Over here! > By "application" I mean it in the SGML and database sense, meaning a > collection of data of specific types and semantics to which processing is > applied, rather than the processors themselves. If I understand Len's use, > he means the actual system used to implement the application. I meant "The Web". It is a system used on the Internet for hypermedia. There are others but they don't have quite it's level of acceptance. > Many > programmers don't make a distinction between these two uses: the software > is inseparable from the data in their mind. But this is a self-defeating > mindset because data tends to outlive software, thus binding data to > software to closely ensures the obsolescance of the data. Can be true, but do read the stuff at the bottom of the message, that is, what a *programmer* means by data object, data structure, etc. > >Within a given application framework, > >inter-object > >messaging is provided by the API for that framework.... err.. messages > >and > >functions. > > I think there's a basic disconnect here. The purpose of XML is to define > *data representation languages*, not functional ("programming") languages. Ok. SGML- - instead of HTML ++. But this is not a disconnect. Posting the MID example was really just a way to say, all of the problems being offered aren't new. The MID was one application language for solving them according to some strict requirements. One way to answer this is to actually post some requirements we can respond to because no matter how you do it, normative or non-normative, and even if the linktypes are abstract, you are still asking for an application language. That was the punt in HyTime that was hard to accept: that arch forms were not just another way to say predefined language constructs for inheritance. Meta schmetta: it's a class. > Hyperdocuments are not programs any more than relational databases are > programs. Join is an operation defined universally for relational databases. It has a predictable behavioral mapping. For interoperation, (the word lightly being tossed about), it eventually required something like the ODBC with its levels of conformance. You are in no position to say what hyperdocuments are. Examples of these are abundant and most of them include strict definitions for operations and display types. > Thus, issues of "API", "messaging", "functions", etc. are not > relevant to the discussion of hyperlink *representation*. Nice theory. Semantic graphs, nodes, edges, that sort of thing. Yes, this is what I wanted from HyTime in 1989. The confusion arose over whether the label on the arc meant an operation of some kind, and if not, how to preserve "look and feel" across applications. The buttons are part of the hyperdocument. > They are, of > course, directly relevant to the issue of hyperlink *implementation*: > applying behavior to links, just as they are to the issue of SGML document > processing implementation in general. Yes, and by that, most people define interoperation. So, what is being asked for here is not an interoperable data object, but a portable one? > But there will be many different > implementations for the same documents: that's the whole reason for using > indirections like SGML in the first place. If you focus too quickly on > implementation details without first defining the overall data model, you > run a serious risk of building a self-limiting system. But you may build one that runs dependably for some time and interoperates with others that aggree to the definitions of the API. ODBC allows relational databases to interoperate within specified conformance levels. > Remember: there's no difference between a hyperlink represented in an > abstract data representation scheme and any other element type except the > type of processing that *might* be associated with it. Yes. The MID team saw it that way too. What you and Jon seem to overlook is that the traversal type specification was optional. It also had that "other" thing. It was there for people who needed the level of predictability Terry is asking for (which was a strict requirement of MID), and who did not want to program Scheme/LISP to get it. What you will find if you dig long enough is that many people require that the data structures interoperate portably, and that look and feel the same. It is a very hard problem which at some point will forces one to include hard to pin down values like RGB triples, heat of the monitor using *white*, when is *white* white enough. Follow the VRML list for some of that. Hopefully, we don't need anything that deep, but in VRML, they do. I think what is being said here is the answer to the question, do we need a set of normative relationship types. The answer is No. By definition, those are domain issues and you cannot satisfactorily define a range for your domain. Without that, it is just CaPH again. Now, CaPH is a good thing, but it is specific about the Conventions bit. As I recall, the database folks made a good case that it only has one type: topic. Are you asking for that? len Date: Thu, 23 Jan 1997 08:49:45 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Relationship types While discussion continues on the issues raised by Eliot's post, allow me to pose a parallel but simpler set of questions. Assume that some syntax has been specified for labeling the relationship between link ends. Consider the following incomplete list of relationship types, lifted directly from existing proposals for HTML standardization: PARENT CHILD PREVIOUS NEXT IMPLIES Is it possible to agree on a basic list of such types? Is it useful to agree on a basic list of such types? If such a list were defined, would it be better to restrict the labels that could be applied to a relationship to the choices on the list, or would it be better to allow additional labels not on the list to be applied on an ad hoc basis? Jon From: lee@sq.com Date: Thu, 23 Jan 97 11:56:15 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions Eliot wrote: > Len and I are using the term "application" in different ways. By > "application" I mean it in the SGML and database sense, meaning a > collection of data of specific types and semantics to which processing is > applied, rather than the processors themselves. If I understand Len's use, > he means the actual system used to implement the application. Many > programmers don't make a distinction between these two uses: the software > is inseparable from the data in their mind. But this is a self-defeating > mindset because data tends to outlive software, thus binding data to > software to closely ensures the obsolescance of the data. This is an absurd claim, and I assume it should be taken as Religious Rhetorick, but if there is really a misunderstanding, it's worth clearing up. Calling a piece of software that processes data an application does not in any way imply that software and data are inseperable. It is merely a difference in terminology. Author/Editor is an application, in the common, normally-accepted, non-SGML meaning of the term, as is HyMinder, as is Adept, as is Microsoft Word, as is SoftQuad Panorama. Only some of these are also SGML Applications. So an application can preserve a distinction between data, data format and implementation if it wants. I assume that Eliot meant data format rather than data, or he really _is_ out to lunch. Eliot, I stand by my claim that too much HyTime rots the brain :-) Lee Date: Thu, 23 Jan 1997 10:52:16 -0600 From: Len Bullard To: Jon Bosak CC: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship types Jon Bosak wrote: > > Assume that some syntax has been specified for labeling the > relationship between link ends. Hmm. Application language. > Consider the following incomplete > list of relationship types, lifted directly from existing proposals > for HTML standardization: > > PARENT Is-a > CHILD Has-a > PREVIOUS goto > NEXT goto > IMPLIES This one is neat. It can be a pure arc, but in practice it is goto or gosub parameter. > Is it possible to agree on a basic list of such types? No unless you intend as HTML did, to define an application language. > Is it useful to agree on a basic list of such types? Utility is a characteristic of the domain of the requirements. > If such a list were defined, would it be better to restrict the labels > that could be applied to a relationship to the choices on the list, or > would it be better to allow additional labels not on the list to be > applied on an ad hoc basis? No application language based on SGML contructs has succeeded in restricting the addition of tags or attibutes to the language unless it is a *dead* language. That is why most SGML applications interoperate at the level of portable, validatible files. Has the DTD crept back into XML in a meaningful way? len From: Paul Prescod Subject: Re: Relationship Taxonomy Questions To: tallen@fsc.fujitsu.com (Terry Allen) Date: Thu, 23 Jan 1997 12:27:55 -0500 (EST) Cc: tallen@fsc.fujitsu.com, eliot@isogen.com, w3c-sgml-wg@www10.w3.org > If part of my document's text is included through a link, *and the > document is being displayed*, the included text must be displayed when > downloaded so as to display the full text as I intended it, complete > with safety warnings, etc. Else I can't rely on my data format to > convey my content, and the XML format is useless for practical > purposes, however interesting it may be for hypertext theory. If I want to willingly override your "link behaviour specification" to make your document not behave or look right, how is that any different than doing the same in a stylesheet? What if I define a stylesheet that displays "IMPORTANT-NOTICES" in 0 point font. The effect is the same. Your text is lost, it is my "behaviour specification" (stylesheet's) fault. I think you have convinced me that we should predefine a "Legal" link type (or link type attribute??) that says that the legal meaning of this document changes if the link is not followed. That link attribute could be applied to both the stylesheet and the "link process specification" in your example. > | In fact a web walker is a "user agent" that *does* implement > | link behaviour significantly different than a browser. > > It doesn't display any link behavior or the underlying document to > the user, however. That's right. So it may ignore the link behaviour specifier, just as it would ignore a stylesheet. I think that that is a good argument for keeping those behavioural definitions external to the document. > They have to distinguish beween traversal and inclusion links, else > they can't represent the document properly, even in outline. Note > that we don't have text inclusion in HTML. And without a stylesheet you can't represent the document properly, even in outline, either. Footnotes become "inlined". Index entries get inlined. Meta-information looks as if it is part of the title. Etc. > | choose a document from my "site link map" rather than going through a page > | and executing the "goto?" > > Your site link map is not my XML document. I meant my site link map to be a visual tool that surfs a website and builds a map of it, using/displaying as much or as little of the semantics of the site as I ask it to. Paul Prescod Date: Thu, 23 Jan 1997 12:57:18 -0400 To: bosak@atlantic-83.eng.sun.com (Jon Bosak) From: murray@spyglass.com (Murray Altheim) Subject: Re: Relationship Taxonomy Questions Cc: w3c-sgml-wg@www10.w3.org (Executive summary: Ramblings of the confused.) Jon Bosak writes: [...] >1. Contra some statements which have been made by various people over >the last little while, it is not enough for XML to specify pure >syntax. XML has to *interoperate*. No shared semantics, no >interoperation. The interesting, deep, and dangerous question is, >which semantics are the right ones to share? Some of the link discussion makes unclear to me the scope of the XML specification. I hope I'm not coming off of Planet 9 on this one, but here goes... An argument could be made that the necessary semantics for XML should extend not only to links and stylesheets, but to other features such as user feedback (forms/CGI), etc., where we begin to move into the realm of specifying HTML++. Rather than try to create a somewhat arbitrary threshold of interoperability on including a specific feature or syntax, why not create a simplified, structured method for sharing DTD components, plus a method of binding the necessary relationships, behaviors, or presentational information to the semantics described in those components? Are we looking for a specification for this binding, or beginning to move into the territory of specifying XML "features"? [If a DTD-less XML document is a subset of the functionality of, let's say, HTML, then we've haven't described a meta language, we've described an extensible subset of HTML. Non?] Rather than specify a recommended XML link syntax, an XML stylesheet syntax, an XML table syntax, we could devise the method whereby a document/DTD author can pull these components together in an structured (and simplified) manner. Sort of an "architectural forms for dummies" arrangement. We could still go ahead with creating or recommending existing modules (a TEI-like link spec and CALS tables come to mind), but would have then abstracted their connection from the core of the XML specification. A two-layer spec? Layer one describes the core XML syntax (basically what we have now in 1.0) plus a "behavior-sheet" syntax and a binding method between the two. Eliot's link semantics would be in the second layer, where we recommend specific behaviors, relationship semantics, etc. >The preceding comments have added virtually nothing to this >discussion, but I hope that I have satisfactorily discharged my >obligation as a member of the ERB to put my position on record. I kinda feel this message may need the same disclaimer. For the record, I was never one for conspiracy theories: just confused a bit by the process. Quoting Aleksandr Lebed in today's NY Times: "There's got to be a time when you stop stepping on the same rake." Whack. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." Date: Thu, 23 Jan 1997 17:43:01 +0000 To: w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: Relationship types At 08:49 23/1/97 -0800, Jon Bosak wrote: >Assume that some syntax has been specified for labeling the >relationship between link ends. Consider the following incomplete >list of relationship types, lifted directly from existing proposals >for HTML standardization: > > PARENT > CHILD > PREVIOUS > NEXT > IMPLIES > >Is it possible to agree on a basic list of such types? Not if this list could be taken as all you need rather than a possible starter set. The HTML Internationalization group is trying to get the current list extended to cover the relationship between translations. At least 20 different suggestions have been made so far this year, all of which would be perfectly valid link types. As with HTML you need a general mechanism that comes with a few suggestions as to how to use it. >Is it useful to agree on a basic list of such types? How long do you have for such an exercise. Here's just a few that I would like to see: Copyright notice Reuse permission request Machine translation of Human translation of Human-corrected machine translation of ASCII text version of EBCDIC version of PDF version of Issue date of Last-update date Last usable date Encryption key for Security clearance request Need I go on....and on.... and on.....? >If such a list were defined, would it be better to restrict the labels >that could be applied to a relationship to the choices on the list, or >would it be better to allow additional labels not on the list to be >applied on an ad hoc basis? Do you really want to restrict them? ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Thu, 23 Jan 1997 12:57:19 -0400 To: bosak@atlantic-83.eng.sun.com (Jon Bosak) From: murray@spyglass.com (Murray Altheim) Subject: Re: Relationship types Cc: w3c-sgml-wg@www10.w3.org bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: >While discussion continues on the issues raised by Eliot's post, allow >me to pose a parallel but simpler set of questions. > >Assume that some syntax has been specified for labeling the >relationship between link ends. Consider the following incomplete >list of relationship types, lifted directly from existing proposals >for HTML standardization: > > PARENT > CHILD > PREVIOUS > NEXT > IMPLIES > >Is it possible to agree on a basic list of such types? In English, possibly. Not much use for the rest of the world unless you as a non-English speaker don't mind learning the meanings of some rather complicated relationships in a foreign language. >Is it useful to agree on a basic list of such types? Not if you require a CHILD or NEXT behavior that doesn't match the guy in the next cubicle's CHILD or NEXT. Not if you can't guarantee that XML implementations will interoperably support the entire list. To see how far we might have to go in creating that list, we could look to an example of an attempt at encompassing the gamut of link types in Lee and Murray Maloney's HTML draft (to which I believe you were alluding). Quite a way it seems. >If such a list were defined, would it be better to restrict the labels >that could be applied to a relationship to the choices on the list, or >would it be better to allow additional labels not on the list to be >applied on an ad hoc basis? We know how far the linktypes draft got on the Web. Why? Possibly because it was both too restricting and too extensive -- you can't win it seems. Developers had to choose either the complete set or a subset, so for authors there was no common understanding of which were supported across popular implementations, and therefore no guarantee of interoperability, eg. it's dangerous to rely on if only NCSA Mosaic supports it. I didn't think XML was about restriction -- it's supposed to be a meta-language, right? Wouldn't a restricted list mark the beginning of a design stagnancy? Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." Date: Thu, 23 Jan 1997 12:08:55 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Relationship Taxonomy Questions At 08:26 AM 1/23/97 -0800, Terry Allen wrote: >Eliot: >| All we're saying is that we don't want XML's link representation scheme to >| be *limited* to behavior-only links. We also recognize two facts: > >What you were saying is that you want to specify a set of relationship >labels. I think the taxomony of relationships is orthogonal to the >mechanism for using them, and competition among different taxonomies >should be encouraged, hence XML itself should not specify a >taxonomy. I don't see how the conclusion of the last statement necessarily follows >from its beginning. I would say, with as much conviction: "I think the taxomony of relationships is orthogonal to the mechanism for using them, and competition among different taxonomies should be encouraged, hence XML itself should specify a taxonomy with which others can compete." >You have not given a single example of a label you want to specify. >Please do so. Ok, here's my personal approach to this problem. First, we have some basic structural relationships: 1. Hierarchy. In SGML, hierarchy is *completely* defined by element structure. In other words, a document is first and foremost a hierarchy of elements. NOTE: some elements may refer to their content by references to other entities (e.g., subdocuments). Nevertheless, the hiearchy is represented by the structure of the elements. [Before you say that SGML doesn't require it, it does if you apply the principle that if a standard provides a facility for something you should use that facility exclusively {a principle that I know from previous conversations Terry doesn't agree with}, then the above statement is definitely true. In any case, the above statement is a principle of the HyTime design, for good or ill.] 2. Content of. In SGML, content relationships are represented by containment. This containment may be syntactic (the stuff between start and end tags) or by reference (reference from an element to another data object designated as containing its content). In this model, "transclusion" is a "content-of" relationship, possibly expressed through use-by-reference ("content location" in HyTime terms). Note too that I'm making a distinction between "required transclusion" (which is what I think Terry means by the term) and a presentation style that happens to present one anchor at or in place of another anchor. The latter is not transclusion in the strict sense that I use it here and that I think it is meant by T. Nelson and Terry. This is one reason why HyTime distinguishes content location from hyperlinks: they differ in their degree of required processing. Transclusion says "this is my content just as surely as if it had occurred here directly" while hyperlinks say "go here or don't, I don't care". 3. Property of. In SGML, properties of elements are usually represented by attributes of elements, although they may be represented by subelements. Like content-of relationships, properties may be used by reference. Properties are characterized by being non-optional or otherwise essential to the interpretation of the object: take one away and you have a new object. [The distinction between properties and content is somewhat blurry, although it seems to be a useful one, at least for document representation. Obviously, it's up to a particular schema definition to define what are "properties" and what is "content".] These three relationship types are "priviledged" types in the sense that in SGML they have optimized syntaxes for their representation and are generally considered to be static properties of the objects that exhibit them. Of course, the term "static" doesn't mean "written in stone", it just means "stable over the period of a single processing session", however "processing session" is defined (might be a millisecond or millennium depending on the application). Thus the above relationships are distinguished from "hyperlink" relationships by being both priveledged and, generally, non-optional, in that you must resolve the above relationships in order to understand the data (e.g., produce a static rendering of it). All other relationships are "hyperlinks" in that they: 1. Do not define purely hierarchical relationships (parent, child, containment) 2. Are "optional" in that they need not be processed and the failure to do so will not change the basic meaning of the data. 3. Are generally intended to enable interactive traversal or retrieval of the data (but may be intended for other purposes as well, such as the control of processing for some specific output or the representation of relationships that are never directly exposed to the user). Given that, what would I consider to be a useful starter set of relationship types in the domain of general web delivery of general information? How about: - Similar-to - Different-from - Background-for - More-information - Citation-of - Annotation-of - Aggrees-with - Disagrees-with - Contrasts-with - Supplier-of - Source-of - Owner-of - Connected-to ("semantic-less" link, e.g., "A") These are all link types that would be useful to use with contextual links because they provide some clue about why the link connects where you are (or what it names in its content) to whatever it links to. I'm sure there are more I could think of if I cared to spend more time at it. I have chosen relationship names that imply a directionn mostly because contextual links usually have a directional nature (though they need not). Some these require a directionality because they are not reflexive (background-for, Citation-of), others are reflexive. If I was designing the reflexive versions primarily as independent links, I might use these names: - Resemblance - Difference - Annotation - Aggreement - Disagreement - Constrast - Ownership - Connection I have not included any "structural" link types because they aren't useful or necessary. The use of crafted hyperlinks purely for navigation purposes is unnecessary in this model because the purely navigational relationships (traversal of the hierarchy or among semantically-distinct parts of the hyperdocument) are inherent in the hyperdocument's structure. In other words, if you use SGML element structures to represent all hierarchy, you've done everything you need to do to enable the generation of whatever navigation aids you need (witness DynaWeb)--the only limiting factors are the presentation facilities of your tools and your implementation resources. This is not to say that a system of non-structural hyperlinks might not happen to be organized into a hierarchy, but that is a different application of hierarchy, distinct from the task of organizing the core content (the data to which the hyperlinks are applied). Note that by using content by reference (transclusion or content location, whichever you prefer or hate the least) you can apply new hierarchies to existing data, but in a way that is not hyperlinking as I've defined it above. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" From: lee@sq.com Date: Thu, 23 Jan 97 13:20:44 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship types Jon raised the quastion: > Assume that some syntax has been specified for labeling the > relationship between link ends. Consider the following incomplete > list of relationship types, lifted directly from existing proposals > for HTML standardization: > > PARENT, CHILD, PREVIOUS, NEXT, IMPLIES > > Is it possible to agree on a basic list of such types? > Is it useful to agree on a basic list of such types? Yes, it's useful. Note that NCSA Mosaic and Lynx both have special actions based on a number of such link type labels. > If such a list were defined, would it be better to restrict the labels > that could be applied to a relationship to the choices on the list, or > would it be better to allow additional labels not on the list to be > applied on an ad hoc basis? I strongly believe it's best to have a prefix that indicates use of a non-standard or private name space. Otherwise you can never add to the list without bereaking existing documents. The other approach (equally OK, I think) is to use -XML-NEXT and so on. (or we could drop the leading hyphen, as was done for PIs) The paper on rel-rev that Murray and I (mostly Murray) wrote is online as http://www.softquad.com/papers/draft-ietf-html-relrev-00.txt Note that this is an interenet draft that has expired. There was interest in taking it forward, but neither Murray nor I has had the time, and the lack of interest in the IETF by the two biggest browser vendors means that there's probably not much point. But it is worth reading, as is Tim Berners-Lee's writing on this subject in 1989, to gain a better understanding of how the web works. It's very tiring to hear how the web was designed to use untyped links from people who have obviously not bothered to read up on the design. It's also unfortunate that typed links don't have enough glitz to attract early implementation. Now that tools like FrontPage are becoming more common, people are beginning to understand the usefulness of distinguished links. Lee Date: Thu, 23 Jan 1997 13:48:37 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Relationship Taxonomy Questions (3 CCs deleted) At 7:33 AM 1/23/97, Terry Allen wrote: >I need to be sure it happens, and mapping behavior to some label >on a element is only one way to do it. There is more than one SGML >way to skin a cat. For such a guarantee, you must go outside the XML domain to a fixed browser. XML will have stlyesheets, so a user will be able to make your warning _INVISIBLE_. This is part of what we want for our markup, because markup is about _decoupling behavior_. (And user stylesheets are not just trivia, this is how we can support blind users for instance -- they _always_ use a substitute style sheet). >And in response to Jon's clear statement, I certainly don't want to >forbid him from taking this approach, and there is nothing in XML 1.0 >to prevent him from using it, but I don't want to be *required* to use it. Then implement your own acrobat-equibvalent (using XML-syntax if you like). Jon's statement is _exactly_ what we should be doing. We describe document element types instead of formatting behavior, and in exactly the same way we should describe document relationship types, not behavior. And don't throw out the reasonable-seeming, but irrelevant, objection that the notion of link-type is not well-defined. If you think link-types are abstract, try to give a formal definition of what an element type actually is. No one knows, but that doesn't mean that giving authors and users a way to label _what it means to them_ is not useful. >Put another way, I need to be able to bind link behavior to my document, >and I want to be able to describe relationships that do not map >to behaviors. Then you have more than one kind of realtionship: In SGML if you want some paragraphs to format differently, you have two choices: 1. If the formatting is related to the structure, write a stylesheet that algorithmically decides how to format, based on that structure. (E.g. first para of a chapter has no indent) 2. If the structure _cannot_ enable such a stylesheet, ipso-facto, you have different strucures and hence a new element type. Now this is baby DTD design, and would also be baby link-design if the world wasn't hell-bent on repeating every mistake in computing every single time anything new happens. Take the example of print-formatting of links. Behavioral specs are useless there (all of the MID types are at least, as far as I can tell). They are useless not because there isn't _some_ possible mapping into the primitives of print presentation, but because you can't determine from the behavior of a browser, what the behavior of a text-formatter should be. >| And when they are clicked on they are downloaded, but not >| displayed. > >If part of my document's text is included through a link, *and the >document is being displayed*, the included text must be displayed when >downloaded so as to display the full text as I intended it, complete >with safety warnings, etc. Else I can't rely on my data format to >convey my content, and the XML format is useless for practical >purposes, however interesting it may be for hypertext theory. This is the same argument that is made for TROFF over SGML. And it's just as fundamentally bogus, I'm afraid. Indirection does not make anything impossible or useless. >| In fact a web walker is a "user agent" that *does* implement >| link behaviour significantly different than a browser. > >It doesn't display any link behavior or the underlying document to >the user, however. It needs to understand that the links are different. A print formatter does all those things, and has the same problems under a behavioral implementation. Even behaviors such as transclusion that seem to map nicely, may have special cases depending on the semantics of the original link creation. >They have to distinguish beween traversal and inclusion links, else >they can't represent the document properly, even in outline. Note >that we don't have text inclusion in HTML. For instance transclusion of other people's work, may need to be rendered as a citation in some contexts. This could be determined (or at least enabled) by link types, but never by a behavioral spec. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Thu, 23 Jan 1997 13:48:48 -0500 To: Terry Allen , eliot@isogen.com, papresco@calum.csclub.uwaterloo.ca From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Relationship Taxonomy Questions Cc: w3c-sgml-wg@www10.w3.org At 8:26 AM 1/23/97, Terry Allen wrote: >What you were saying is that you want to specify a set of relationship >labels. I think the taxomony of relationships is orthogonal to the >mechanism for using them, and competition among different taxonomies >should be encouraged, hence XML itself should not specify a >taxonomy. Finally Terry has said something sensible on this topic. (Since Terry usually is sensible, this is less a surprise than the argument about link labels). Defining link types is as hard as defining a universal DTD. A lot of danger there. I'd rather stay out of it. didn't Murray Maloney's list get up to 40 types or more? I think Randy Trigg's thesis had 150 or so, but I don't have it available to check. On the other hand, a non-binding annex of useful names for common links might actually help people to understand (and thus use) link types. >You have not given a single example of a label you want to specify. >Please do so. I'm thinking something like maybe: internal-reference quote-external work cite-external-work footnote-or-annotation That list may already be too long, but as a list of suggestions it might be useful, and not as perniciously processing oriented as Len's "gosub". -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Thu, 23 Jan 1997 13:48:42 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Base At 9:34 AM 1/23/97, W. Eliot Kimber wrote: >Let me add to this question: should the SGML standard add syntax to bind >document entities to their external identifiers (which would, by the >definition of external identifier, include both system IDs (and thus, >potentially, URLs or URNs) and publid identifiers)? Yes. But SYSTEM IDs should not be included. In SGML, they are reserved for "non-portable" identifiers, so making documents self-identifying in this way would probably be a mistake, since it would only contribute to the portation of the explicitly non-portable. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Thu, 23 Jan 1997 13:48:47 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Relationship Taxonomy Questions At 7:46 AM 1/23/97, Terry Allen wrote: >I wrote: >>Put another way, I need to be able to bind link behavior to my document, >and I want to be able to describe relationships that do not map >to behaviors. > >I meant "behaviors that do not map to relationships" (also). As I noted, this is fundamentally against the "SGML" way. This argument is already over for document processing (at least in this group). We need not repeat it for link processing. Both links and document elements represent fuzzy "human-semantic" items that can be processed in different ways in different contexts. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Thu, 23 Jan 1997 13:53:27 -0500 From: gtn@ebt.com (Gavin Nicol) To: eliot@isogen.com CC: cbullard@hiwaay.net, w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions >Many programmers don't make a distinction between these two uses: the >software is inseparable from the data in their mind. But this is a >self-defeating mindset because data tends to outlive software, thus >binding data to software to closely ensures the obsolescance of the >data. Then again, data is just another form of programming... >I think there's a basic disconnect here. The purpose of XML is to define >*data representation languages*, not functional ("programming") >languages. The only difference is interpretation. What does the following tell you? (quote (+ 3 3)) or the following? 3 3 To: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions Date: Thu, 23 Jan 1997 11:16:01 -0800 From: Joe English bosak@atlantic-83.eng.sun.com (Jon Bosak) wrote: > 2. I am quite convinced (and was before the ERB asked Eliot to start > this thread) that it is vital to make a strong distinction between > > * Link structure or topology [...] > * Linkend location/addressing [...] > * Link meaning [...] > * Link behavior, which can be divided into > A. What the user sees: > Presentation before link traversal > Presentation during link traversal > Presentation after link traversal > B. What the system sees: > State before link traversal > State during link traversal > State after link traversal > > I personally have never seen anything specified in connection with a > link that could not be subsumed under some combination of these > categories; if anyone else can think of something, I sure would like > to know what it is. Another category of link behaviour is "transclusion" or "simultaneous presentation" linking. For example, HTML's can be thought of as a transcluding contextual link; and HyBrowse can be configured to transclude the contents of an ilink anchor at the point where another anchor appears (useful for inlining annotations, etc). Other types of links could specify simultaneous presentation, e.g., "whenever the user lands on Section 2.3, display Figure 4 in a pop-up window and play the audio file xyzzy.wav". With these types of links traversal is automatic, so there's no notion of presentation/state before/during/after traversal. > 2'. In particular, I think that it is of the utmost importance to > distinguish meaning (relationship typing) from behavior (which > includes presentation). I think that the analogy between semantic > tagging vs. style information in SGML and relationship typing vs. link > behavior is an apt and powerful one. Agree! --Joe English jenglish@crl.com Date: Thu, 23 Jan 1997 13:20:58 -0600 From: Len Bullard To: Joe English CC: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions Joe English wrote: > > bosak@atlantic-83.eng.sun.com (Jon Bosak) wrote: > > > I personally have never seen anything specified in connection with a > > link that could not be subsumed under some combination of these > > categories; if anyone else can think of something, I sure would like > > to know what it is. > > Another category of link behaviour is "transclusion" or > "simultaneous presentation" linking. it can also be thought of and practically implemented as a "get" and avoid a lot of garbage description. > With these types of links traversal is automatic, so there's > no notion of presentation/state before/during/after traversal. no. it is implied and documented by axiom, in SGML practice, the comments or DTD documentation. > > 2'. In particular, I think that it is of the utmost importance to > > distinguish meaning (relationship typing) from behavior (which > > includes presentation). I think that the analogy between semantic > > tagging vs. style information in SGML and relationship typing vs. link > > behavior is an apt and powerful one. And one not embraced by the majority of web applications. They may know something. len Date: Thu, 23 Jan 1997 09:23:03 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: Relationship types [Len Bullard:] | > PREVIOUS | | goto No. "goto" says "do something with regard to this link end." "PREVIOUS" says "know something with regard to this link end." Jon From: lee@sq.com Date: Thu, 23 Jan 97 14:57:00 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship types murray@spyglass.com (Murray Altheim) wrote: > bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: > >Is it possible to agree on a basic list of such types? > > In English, possibly. Not much use for the rest of the world unless you as > a non-English speaker don't mind learning the meanings of some rather > complicated relationships in a foreign language. User agents are free to use local translations in an interface, just as some user agents choose not to display the pointy brackets that surround a BR element in HTML... :-) The alternative is to use numbers, as per the MARC library cataloguing scheme, but in fact arbitrary sequences of letters are probably no harder to use than arbitrary sequences of numbers... Lee Date: Thu, 23 Jan 1997 13:57:22 -0600 From: Len Bullard To: Jon Bosak CC: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship types Jon Bosak wrote: > > [Len Bullard:] > > | > PREVIOUS > | > | goto > > No. "goto" says "do something with regard to this link end." > "PREVIOUS" says "know something with regard to this link end." previous = goto(). That is why those JavaScript function calls are in HTML. len From: lee@sq.com Date: Thu, 23 Jan 97 15:28:06 EST To: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org Subject: Re: Base David Durand writes: > But SYSTEM IDs should not be included. In SGML, they are reserved for > "non-portable" identifiers, No. They are system specific. They are not _required_ to be non-portable. SGML makes no promise that they are portable. but certainly does not say that any document using a portable SYSTEM identiifier is invalid!!! For XML, it would be possible and acceptable to requre specific forms of system identifiers in certain places, and in fact we have already done so by using URLs. Lee To: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions Date: Thu, 23 Jan 1997 12:23:23 -0800 From: Joe English Len Bullard wrote: > Joe English wrote: > > Another category of link behaviour is "transclusion" or > > "simultaneous presentation" linking. > > it can also be thought of and practically implemented > as a "get" and avoid a lot of garbage description. Ding! Thank you! I've been hunting for a good word to describe this sort of link, and "get" is just right: short, Anglo-Saxon, and to the point. Much better than the polysllabic obfuscatory Latinate terminology I've been using up to now. > > [Jon Bosak] > > > 2'. In particular, I think that it is of the utmost importance to > > > distinguish meaning (relationship typing) from behavior (which > > > includes presentation). I think that the analogy between semantic > > > tagging vs. style information in SGML and relationship typing vs. link > > > behavior is an apt and powerful one. > > And one not embraced by the majority of web applications. They > may know something. Wait a minute... I thought the whole premise of the XML effort was that the architectural foundation of the majority of Web applications -- HTML -- is not powerful enough to enable the kinds of applications the SGML community would like to see. Or does that premise only apply to HTML's fixed tag-set and not to its (admittedly primitive) hyperlink mechanism? --Joe English jenglish@crl.com From: lee@sq.com Date: Thu, 23 Jan 97 15:25:29 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions > "I think the taxomony of relationships is orthogonal to the > mechanism for using them, and competition among different taxonomies > should be encouraged, hence XML itself should specify a > taxonomy with which others can compete." I agree. > First, we have some basic structural relationships: > > 1. Hierarchy. In SGML, hierarchy is *completely* defined by element > structure. Well, I would say by containment rather than by hierarchy. Hierarchy is one possibly but not I think mandated interpretation of containment (at least not mandated by ISO8879:1986). > 2. Content of. In SGML, content relationships are represented by containment. I think this is a tautology, but agree that it is a relationship. > In this model, "transclusion" is a "content-of" relationship, possibly > expressed through use-by-reference ("content location" in HyTime terms). I don't agree with that at all. Transclusion is a means of presentation, and has nothing to do with the semantic relatioonship of the other end of the link. I might want to say Transclude (show inline) all of Eliot's comments marked as DISPUTATION but leave only external pop-up link icons to Eliot's AFFIRMATION links, as I don't need to read those right now. > Note too that I'm making a distinction between "required transclusion" > (which is what I think Terry means by the term) and a presentation > style that happens to present one anchor at or in place of another anchor. > The latter is not transclusion in the strict sense that I use it here > and that I think it is meant by T. Nelson and Terry. The presentation style is transclusion if you use it and not if you don't, I think. Xanadu gave/gives the user no choice but transclusion, so many people read Nelson as meaning that transclusion means mandatory presentation, but I am not sure that that's fair. It would be better, I think, to say that Ted Nelson says that transclusion is compulsory. But I have never met him. and have no idea whether he would in fact make such a distinction. He carries a camera with him everywhere, and somewhere probably still has film of a conversation he had with Yuri. > 3. Property of. In SGML, properties of elements are usually represented > by attributes of elements, although they may be represented by > subelements. Of course, not all attributes are best thought of in that way, and not all properties are so represented in practice. For example, most SGML systems implement some form of #INHERITED for styles (as does DSSSL) even though SGML lacks this feature. > The distinction between properties and content is somewhat blurry The O-O approach might be to say that the content is a properrty of the element. Mathematically, there is no difference between an attribute and content except that the meaning of markup within SGML attributes is not well defined, and they don't nest properly. Since SGML software often has restrictions on what you can put in or do with attributes, I have a rule of thumb that says that all displayed content should be content, not attributes, but I break it fairly often. > These three relationship types are "priviledged" types in the sense that in > SGML they have optimized syntaxes for their representation and are > generally considered to be static properties of the objects that exhibit > them. Of course, the term "static" doesn't mean "written in stone", it > just means "stable over the period of a single processing session", however > "processing session" is defined (might be a millisecond or millennium > depending on the application). That is certainly not true in an SGML editing program -- a single processing session might include an attribute changing value, perhaps automatically (e.g. being assigned an ID, or today's date) or being created or deleted. An element might be moved. If you were using a complex DSSSL specification that said that the first paragraph of each chapter appeared in the Overview section and not the actual chapter, inserting a paragraph at the start of a new chapter in an editor might be very disconcerting :-) You omitted the "followed by" relationship that is generally considered important in SGML, even if it isn't actually required by the standard (I think it probably is, but I am not sure): that the order of subelements ontained in a given location is significant, even if all the elements match the same GI in a content model. In other words, given MaryLaurenceBarney I can't shuffle the boys around and still conform -- there is an implicit "followed by" relationship between Laurence and Barney. Perhaps they are arranged in order of age, for example. Or in order of height. Or in reverse alphabetical order. A browser that displayed this as Mary: Barney Laurence would not be observing this relationship very helpfully. Sorry for stressing this so much -- I see it overlooked so often! A relational model does not have such implicit ordering, so that if you store SGML in a database (or HTML or XML), one element per "cell", you have also to store the ordering relation explicitly. Finally, note that SGML entity structure and marked section structure can break the SGML hierarchy -- you can do "> "> "> " &start-class; Mary &pupils; Laurence ∧ Barney &end-class; (well, that's a rather small class, but you get the idea) > Similar-to Different-from Background-for More-information > Citation-of Annotation-of Aggrees-with Disagrees-with > Contrasts-with Supplier-of Source-of Owner-of > Connected-to Resemblance Difference Annotation > Aggreement Disagreement Constrast Ownership > Connection Please _do_ see the draft that Murray and I wrote. If he isn't totally snowed under by e-mail, I am sure Steve DeRose can give us some references on this stuff too, and there's also literature on the subject of labelling parts of formal discourse, as well as Aristotlean Causes and other sorts of annotations. > The use of crafted hyperlinks purely for navigation purposes > is unnecessary in this model because the purely navigational relationships > (traversal of the hierarchy or among semantically-distinct parts of the > hyperdocument) are inherent in the hyperdocument's structure. What if your hyperdocument is contained in multiple SGML documents, perhaps not all sharing the same DTD? > Note that by using content by reference (transclusion or content location, > whichever you prefer or hate the least) you can apply new hierarchies to > existing data, but in a way that is not hyperlinking as I've defined it > above. It's also rather like inclusion by use of syntactic entity references, &big-class; Lee Date: Thu, 23 Jan 1997 14:34:52 -0600 From: Len Bullard To: Joe English CC: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions Joe English wrote: > > Len Bullard wrote: > > > Joe English wrote: > > > Another category of link behaviour is "transclusion" or > > > "simultaneous presentation" linking. > > > > it can also be thought of and practically implemented > > as a "get" and avoid a lot of garbage description. > > Ding! Thank you! I've been hunting for a good > word to describe this sort of link, and "get" > is just right: short, Anglo-Saxon, and to the point. > Much better than the polysllabic obfuscatory Latinate > terminology I've been using up to now. > > > > [Jon Bosak] > > > > 2'. In particular, I think that it is of the utmost importance to > > > > distinguish meaning (relationship typing) from behavior (which > > > > includes presentation). I think that the analogy between semantic > > > > tagging vs. style information in SGML and relationship typing vs. link > > > > behavior is an apt and powerful one. > > > > And one not embraced by the majority of web applications. They > > may know something. > > Wait a minute... I thought the whole premise of the XML > effort was that the architectural foundation of the > majority of Web applications -- HTML -- is not powerful > enough to enable the kinds of applications the SGML community > would like to see. Or does that premise only apply to > HTML's fixed tag-set and not to its (admittedly primitive) > hyperlink mechanism? It is. However, with server-side HTML or server-side SGML and a good hybrid object-relational database, the database handles most of that. Relationships as described by Eliot are old link database records, a la 1970. Useful, but not earth shaking technology. They have problems with metamorphosis in the name space (typically solved in hybrid DBs with unique ID maintenance of object instances) but that is a different problem. The problem is to figure out if hyperlink means: o data object o record o structure By all means put a non-normative set of relationship types in the spec. But these are domain-specific relationships. They are application conventions. Topics, if you will. Once you try to specify a class relationship (supertypes, subtypes) and expect inheritance and interoperation, you have to specify standard operations. As Eliot says, a hyperlink is just another element type instance. They belong in a DTD. Should those opeations be defined in the stylesheet/processing specification or as class methods? That is for the market to work out. However, if you expect these XML processors to interoperate, the easiest approach is to use some "pernicious" concepts >from real world systems. Your sponsors are already doing that. len Date: Thu, 23 Jan 1997 16:09:57 -0400 To: cbullard@hiwaay.net From: murray@spyglass.com (Murray Altheim) Subject: Re: Relationship Taxonomy Questions Cc: w3c-sgml-wg@www10.w3.org Len Bullard writes: [...] >> bosak@atlantic-83.eng.sun.com (Jon Bosak) wrote: >> > 2'. In particular, I think that it is of the utmost importance to >> > distinguish meaning (relationship typing) from behavior (which >> > includes presentation). I think that the analogy between semantic >> > tagging vs. style information in SGML and relationship typing vs. link >> > behavior is an apt and powerful one. > >And one not embraced by the majority of web applications. They >may know something. I believe a more accurate answer here is that the majority of Web applications only lex the documents, and therefore don't build parse trees that would enable more complex link relationships. This design decision may have been the result of the assumption of broken HTML markup and/or the inability of the programmers to create something as complex as nsgmls for WWW that could also provide error recovery. A whole lotta error recovery. Spyglass, Microsoft, Netscape and I'm sure most other Web browsers couldn't respond to a request to jump "within element with ID 'a25', to third child of type 'P' within the second child of type 'LI'" if you held a sharpened potato to their heads. And this ability is precisely (for me) one of the exciting promises of XML links. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." Date: Thu, 23 Jan 1997 16:35:20 -0400 To: lee@sq.com From: murray@spyglass.com (Murray Altheim) Subject: Re: Relationship types Cc: w3c-sgml-wg@www10.w3.org Liam Quin writes: >murray@spyglass.com (Murray Altheim) wrote: >> bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: >> >Is it possible to agree on a basic list of such types? >> >> In English, possibly. Not much use for the rest of the world unless you as >> a non-English speaker don't mind learning the meanings of some rather >> complicated relationships in a foreign language. > >User agents are free to use local translations in an interface, just >as some user agents choose not to display the pointy brackets that >surround a BR element in HTML... :-) I'm speaking particularly of document authors. If one is creating a new XML application (ie., DTD) and a source document in Japanese, it's a somewhat straightforward process to create a -like element called something appropriate in Japanese and link it to a -like behavior in a stylesheet. But the inclusion of link types would have to be in English if added as part of the core XML specification, unless we create some type of generalized binding, which is what I thought arcforms may be able to provide. >The alternative is to use numbers, as per the MARC library cataloguing >scheme, but in fact arbitrary sequences of letters are probably no harder >to use than arbitrary sequences of numbers... Agreed. But the idea of establishing only the binding between an open namespace of elements/attributes and an open namespace of behaviors/relationships/ presentational directives in a document which we may call a stylesheet, and not the specific GI names, etc. is what I thought a meta-language was about. Once we begin to specify specific, named relationships, we are into the realm of DTDs and application conventions, ala RFC 1866. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." Date: Thu, 23 Jan 1997 15:19:30 -0600 From: Len Bullard To: Murray Altheim CC: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions Murray Altheim wrote: > > Len Bullard writes: > >And one not embraced by the majority of web applications. They > >may know something. > > I believe a more accurate answer here is that the majority of Web > applications only lex the documents, and therefore don't build parse trees > that would enable more complex link relationships. I accept that as a fundamental. The question is why not and since Spyglass was the company responsible for Enhanced Mosaic, you should be able to tell me. On the other hand, ActiveCGM objects have an application layer which they use. VRML has a very powerful link type and script nodes with parameters. Only the SGML community believes it can do without these things and build interoperable software, and so far, it has blown away a decade long lead trying to do so. Fundamentally, the SGML community has talked much and built little with regards to WAN-capable hypermedia. I believe the inability to come to grips with the flaw in data-declaration-only specifications is part of the reason for that. Perhaps that is why in DSSSL there is little of SGML and a lot of Lisp. > This design decision may > have been the result of the assumption of broken HTML markup and/or the > inability of the programmers to create something as complex as nsgmls for > WWW that could also provide error recovery. A whole lotta error recovery. That is good. Historically, Marc Andreesen is also on record as saying, and his company saying, "we don't believe in SGML". Berners-Lee is on record as saying he didn't believe people would type in all those tags, and I believe, the original model target was RTF. That said, it is irrelevant. I think we all agree that XML will not be targeted to the HTML user. The problem is in defining the requirements of the user it is targeted at, and getting those requirements written in a clear language that can be used as a basis for implementation. > Spyglass, Microsoft, Netscape and I'm sure most other Web browsers couldn't > respond to a request to jump "within element with ID 'a25', to third child > of type 'P' within the second child of type 'LI'" if you held a sharpened > potato to their heads. And this ability is precisely (for me) one of the > exciting promises of XML links. Yes. On the other hand, getting a server to generate that for you isn't difficult, so they tell us in their literature. It's done by a process, of course. My point is simple: no normative linktypes. A way to express a linktype is already available. It is an element type. Will these interoperate? Only if the application programmer understands the behavior implied or noted. But those are application conventions and do not belong in the normative parts of the XML specification. If they are there, and they are not procedurally defined (that is, the operations for the data structure are not defined by function or axiomatically), then their originators deserve the good horse laugh the implementors will give them, and return to writing server-side scripts for LiveWire. len bullard To: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship types Date: Thu, 23 Jan 1997 14:07:11 -0800 From: Joe English Len Bullard wrote: > Jon Bosak wrote: > > [Len Bullard:] > > | > PREVIOUS > > | goto > > > > No. "goto" says "do something with regard to this link end." > > "PREVIOUS" says "know something with regard to this link end." > > previous = goto(). That is why those JavaScript function calls > are in HTML. Midas, an early Motif-based Web browser, took an interesting approach for its "history list". Instead of the conventional LIFO stack (where selecting a link pushes the current document and the "Back" button pops the last one), it built a "history tree" by intuiting a hierarchical structure from the links in each visited document. (I think the latest version of NCSA Mosaic for X, alas forever in beta, has a similar feature.) It worked pretty well, especially for Web collections that were in fact hierarchical in nature. After browsing a typical LaTeX2HTML-generated document, the history tree tended to evolve into a fairly good hierarchical, collapsible table of contents. There were flaws, of course; the process was purely heuristic and was sensitive to the initial browsing order (it couldn't distinguish between "next section", "first subsection", and "cross-reference to a completely different chapter" links, for example), but I couldn't help thinking that if more authors and HTML generators took advantage of the "REL" attribute, the Midas history tree would have made a powerful navigation aid. To sum up: no, "previous" is *not* equal to "goto", regardless of whether Netscape and JavaScript implement it that way. --Joe English jenglish@crl.com Date: 23 Jan 1997 22:12:37 +0000 (GMT) From: Peter Flynn Subject: Re: Relationship Taxonomy Questions To: w3c-sgml-wg@www10.w3.org At 07:33 AM 1/23/97 -0800, Terry Allen wrote: >If part of my document's text is included through a link, *and the >document is being displayed*, the included text must be displayed when >downloaded so as to display the full text as I intended it, complete >with safety warnings, etc. Else I can't rely on my data format to >convey my content, and the XML format is useless for practical >purposes, however interesting it may be for hypertext theory. Eliot replied: But you can't *ever* do this with SGML or XML or any other generalized format unless you control both the server and browser. Even on the Web I I obviously interpreted differently what Terry wrote. I understood him to mean a document X, part of which is composed of the whole or part of some other document Y, eg X para of mine para of mine <--------------- para taken from the middle of another doc (Y) para of mine etc Obviously it is possible to do this with only browser control: just it's inefficient in bandwidth to have to get the whole of doc Y, only to drop some of it on the floor. And I thought invisible transclusion was evil, anyway :-) No generalized data representation scheme can *ever* guarantee behavior of any sort--that can only be done by defining the specific presentation and [...] Right, but I didn't think we were trying to do this anyway. We're developing the infrastructure to allow browsers to extend their behavior. I think. ///Peter Date: Thu, 23 Jan 1997 17:23:48 -0400 To: cbullard@hiwaay.net From: murray@spyglass.com (Murray Altheim) Subject: Re: Relationship Taxonomy Questions Cc: w3c-sgml-wg@www10.w3.org Executive Summary: 1. digression on approach to XML/HTML language design/ generalized parser error handling, and 2. the XML target audience. >Murray Altheim wrote: >> Len Bullard writes: > >> >And one not embraced by the majority of web applications. They >> >may know something. >> >> I believe a more accurate answer here is that the majority of Web >> applications only lex the documents, and therefore don't build parse trees >> that would enable more complex link relationships. > >I accept that as a fundamental. The question is why not and since >Spyglass was the company responsible for Enhanced Mosaic, you should >be able to tell me. On the other hand, ActiveCGM objects have an >application layer which they use. VRML has a very powerful link >type and script nodes with parameters. Well, I can't speak for that development team, as I wasn't with the company at that time, nor even in the same location. I can say that for the Stonehand HTML Browser (which was based on nsgmls), we'd never gotten as far as creating a generalized error handler: sometimes errors would literally blow out the application. Then again, it wasn't a finished app. But ironically, such an error handler would basically be Mosaic. IOW, build a parse tree until an error and then dump the tree and do the Mosaic thing. Behavior had to match the rest of the market, so that was also an important design decision. Our responses to broken markup had to be the same as MSIE/Netscape, or we weren't competitive. So, there wasn't much use for the nsgmls parser on the open Web, given the miniscule number of valid documents. The market for the product was corporate intranets and the SGML community (where validity is assumed). Point being that there's no point in building a complex product that seldom gets used, particularly given the catch-22 of document authors not even being able to assume any real UA ability to handle any of that content. I think Spyglass' original interest in Stonehand's SGML browser was somewhat quelled when they figured out that they'd still need Mosaic. Pretty damned big footprint, too. [...] >> This design decision may >> have been the result of the assumption of broken HTML markup and/or the >> inability of the programmers to create something as complex as nsgmls for >> WWW that could also provide error recovery. A whole lotta error recovery. > >That is good. Historically, Marc Andreesen is also on record as >saying, and his company saying, "we don't believe in SGML". Berners-Lee >is on record as saying he didn't believe people would type in all >those tags, and I believe, the original model target was RTF. I think Spyglass' (or at least Stonehand's) view is more accurately stated as a pragmatic assessment of the HTML world as we knew it. Although sometimes I must admit feeling like one of the few in the company that does believe in SGML, especially now that we've moved into the 'device space'. >That said, it is irrelevant. I think we all agree that XML will >not be targeted to the HTML user. I don't know why you make that statement. The current "HTML user" is an enormously varied market, and I can think of enormous possibilities for XML where HTML just isn't cutting it. My belief is that authoring tools, REAL authoring tools will be required. Not PageMill-XML Lite. >The problem is in defining >the requirements of the user it is targeted at, and getting >those requirements written in a clear language that can be >used as a basis for implementation. I don't think we can assume a target user, just as Tim BL couldn't possibly know where the Web was headed in the beginning. >My point is simple: no normative linktypes. A way to express a >linktype is already available. It is an element type. Will these >interoperate? Only if the application programmer understands >the behavior implied or noted. But those are application conventions >and do not belong in the normative parts of the XML specification. Well, that is certainly what I'm trying to ascertain: where are we headed with this discussion? I honestly like much of what's been discussed. Eliot's recent description of relationship types (Thu, 23 Jan 1997 12:08:55 -0900 "Re: Relationship Taxonomy Questions"), the earlier discussion of TEI pointers, etc. all seem like very interesting fodder for XML links. But I wonder how much ends up in the spec. I still kinda like the idea of having a core spec and then adding recommendations as a separate layer, with some type of conformance mechanism for UAs to negotiate. In this way, alternative models could be developed and used, the whole idea behind meta-languages. >If they are there, and they are not procedurally defined (that is, >the operations for the data structure are not defined by function >or axiomatically), then their originators deserve the good horse laugh >the implementors will give them, and return to writing server-side >scripts for LiveWire. When we see Microsoft thumb their nose, we'll know. I must admit my ignorance of arcforms (it's on the reading list), but I thought we could define links more abstractly rather than a set of normative ones. Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." Date: 23 Jan 1997 22:24:22 +0000 (GMT) From: Peter Flynn Subject: Re: Relationship types 1997 10:52:16 -0600) To: w3c-sgml-wg@www10.w3.org Len Bullard writes: [Jon] > Is it possible to agree on a basic list of such types? No unless you intend as HTML did, to define an application language. > Is it useful to agree on a basic list of such types? Utility is a characteristic of the domain of the requirements. Not only useful but essential, if we are to avoid the HTML LINK problem (thinly documented early on, and so unimplemented until late). Can we avoid the phrase "basic list" because that implies a degree of universality which may not be present. "Sample list" or "example list" perhaps? ///Peter Date: Thu, 23 Jan 1997 16:15:48 -0600 From: Len Bullard To: Joe English CC: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship types Joe English wrote: > > To sum up: no, "previous" is *not* equal to "goto", regardless of > whether Netscape and JavaScript implement it that way. We have also implemented a history list. It is not a LIFO stack. Click on it, and one "goes to" the target. Previous and Next do not equate to a history list. It is a goto, a gosub, or a spawn. Simple state space management. A nice thing to have because without it, you will not have interoperation except for where a specific processsing specification and specification language is used. And you have to both have them and cart them around if you don't. Y'all want DSSSL. Fine. Good luck with the lisp programmers. The rest of us have C++ programmers. They will write their own stylesheets and we can compete over that. Marvelous. What can be done with XML can be done with SGML and no one has to get a consensus for that. Just a market. This is going overboard. Predefined linktypes do not belong in a normative section of XML. In a non-normative appendix, sure, have at. We can ignore that. Put them in a DTD, and they shouldn't be ignored. On the other hand, they must be defined axiomatically or by function else you will end up with the same problem experienced by the MIL-PRF-87269 DTD implementors with respect to the abuse of the type attribute. BTW: previous and next were declared in the early IADS and IDE/AS DTDs if the author wished to use them. But we took the requirement out to use them because a right mouse button and a history stack are adequate, and frames defaulted to their linear order. So do pages. So do infoContainers. It's an application issue. Simply give us a way to declare that it is a link, and what type it is. Otherwise, this is just the ERB becoming the HTML WG all over again and at least they admitted they were creating an application language. To paraphrase Eliot when bailing out, "I've said all I have to say, and if it is not clear, then obviously I can't express it well enough to make it clear." len bullard Date: 23 Jan 1997 22:31:25 +0000 (GMT) From: Peter Flynn Subject: Re: Relationship Taxonomy Questions Paul Prescod on 23 Jan 1997 12:27:55 -0500 (EST)) To: w3c-sgml-wg@www10.w3.org Paul Prescod writes: If I want to willingly override your "link behaviour specification" to make your document not behave or look right, how is that any different than doing the same in a stylesheet? What if I define a stylesheet that displays "IMPORTANT-NOTICES" in 0 point font. The effect is the same. Your text is lost, it is my "behaviour specification" (stylesheet's) fault. Same as buying a chainsaw and throwing away the instruction book, then claiming you didn't know it was dangerous to try to hold the blade while it was running. I think you have convinced me that we should predefine a "Legal" link type (or link type attribute??) that says that the legal meaning of this document changes if the link is not followed. That Ping. Get-Rich-Quick scam #97. Your lawyer has been notified :-) I like the concept but the terminology frightens me. ///Peter Date: Thu, 23 Jan 1997 16:37:04 -0600 From: Len Bullard To: Murray Altheim CC: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions Murray Altheim wrote: > > Well, I can't speak for that development team, as I wasn't with the company > at that time, nor even in the same location. I can say that for the > Stonehand HTML Browser (which was based on nsgmls), we'd never gotten as > far as creating a generalized error handler: sometimes errors would > literally blow out the application. Then again, it wasn't a finished app. > But ironically, such an error handler would basically be Mosaic. IOW, build > a parse tree until an error and then dump the tree and do the Mosaic thing. > Behavior had to match the rest of the market, so that was also an important > design decision. Our responses to broken markup had to be the same as > MSIE/Netscape, or we weren't competitive. Understood. When we built IADS and IDE/AS, we had a smart customer who understood where SGML began and stopped. We used the DTD for validation and the stylesheet for everything else. We fixed the linktypes and configured target types. We got beat up very badly by some members of the SGML community and went on about our business. Then along came HTML, there was money to be made, and the "SGMLWay" whatever the hell that means was abandoned after the gold rush. So yep, go with the market. > So, there wasn't much use for the nsgmls parser on the open Web, given the > miniscule number of valid documents. The market for the product was > corporate intranets and the SGML community (where validity is assumed). That was the web then and now. We can change that, but that will be an SGML product market. > Point being that there's no point in building a complex product that seldom > gets used, particularly given the catch-22 of document authors not even > being able to assume any real UA ability to handle any of that content. I > think Spyglass' original interest in Stonehand's SGML browser was somewhat > quelled when they figured out that they'd still need Mosaic. Pretty damned > big footprint, too. Can be. We stripped SGML first. sgmls wasn't available then, a good parser cost a fortune, and writing one wasn't reasonable. Once sgmls became available, we added it as a validation tool for authors. > I think Spyglass' (or at least Stonehand's) view is more accurately stated > as a pragmatic assessment of the HTML world as we knew it. Although > sometimes I must admit feeling like one of the few in the company that does > believe in SGML, especially now that we've moved into the 'device space'. We have your code here. We know. > >That said, it is irrelevant. I think we all agree that XML will > >not be targeted to the HTML user. > > I don't know why you make that statement. Because of the commitment of the principals in the web wars to HTML and all of the technology they have developed to support it. They may change, but I don't expect it soon unless there is good money to be made. > The current "HTML user" is an > enormously varied market, and I can think of enormous possibilities for XML > where HTML just isn't cutting it. No disagreement here. That is why I am at this dance. > My belief is that authoring tools, REAL > authoring tools will be required. Not PageMill-XML Lite. The HTML author will have to see an advantage. Other than the ones we know about archival, management, easy queries, etc., it is a hard case to make. Selling SGML to the inexperienced is where most of us got these ulcers we have. No, what I mean is that the immediate flesh and blood, has a few bucks, market for XML is in the SGML community that already knows what to do with these tools. Yes, I know: intranets are where the money is. Netscape has it written all over their homepage and I have the seventy pages of documents explaining how to do it with HTML. > I don't think we can assume a target user, just as Tim BL couldn't possibly > know where the Web was headed in the beginning. Then he is not a very forward looking man. Some of the rest of us knew immediately what it was and where it was heading. It wasn't that hard to figure out as it is a design we all tried a few times. We usually got beaten up for "gencoding". No, the brilliance of the web is the URL. That solved a lot of problems that no one could get the SGML community to agree on. > I wonder how much ends up in the spec. I still kinda like the idea of having > a core spec and then adding recommendations as a separate layer, with some > type of conformance mechanism for UAs to negotiate. In this way, > alternative models could be developed and used, the whole idea behind > meta-languages. That is my preference as well. I've been on record for some months now as favoring a spec with different layers of conformance. > When we see Microsoft thumb their nose, we'll know. Microsoft is on record as saying "HTML is the backbone of the Internet". However, marketing pronouncements don't mean that much to me. Sales do. As the joke goes, "when they scream hoedown, i hit the floor." > I must admit my > ignorance of arcforms (it's on the reading list), but I thought we could > define links more abstractly rather than a set of normative ones. So do I. In fact, that is the only kind that interests me because I can pretty well see what we will have if we don't, and have a good idea of what we can do if we do. len Date: Thu, 23 Jan 1997 16:36:44 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: Relationship Taxonomy Questions [Joe English:] | bosak@atlantic-83.eng.sun.com (Jon Bosak) wrote: | | > 2. I am quite convinced (and was before the ERB asked Eliot to start | > this thread) that it is vital to make a strong distinction between | > | > * Link structure or topology [...] | > * Linkend location/addressing [...] | > * Link meaning [...] | > * Link behavior, which can be divided into | > A. What the user sees: | > Presentation before link traversal | > Presentation during link traversal | > Presentation after link traversal | > B. What the system sees: | > State before link traversal | > State during link traversal | > State after link traversal | > | > I personally have never seen anything specified in connection with a | > link that could not be subsumed under some combination of these | > categories; if anyone else can think of something, I sure would like | > to know what it is. | | Another category of link behaviour is "transclusion" or | "simultaneous presentation" linking. For example, | HTML's can be thought of as a transcluding | contextual link; and HyBrowse can be configured to transclude | the contents of an ilink anchor at the point where another anchor | appears (useful for inlining annotations, etc). Other types | of links could specify simultaneous presentation, e.g., | "whenever the user lands on Section 2.3, display Figure 4 | in a pop-up window and play the audio file xyzzy.wav". I note that you have described the link behavior by describing the presentation. | With these types of links traversal is automatic, so there's | no notion of presentation/state before/during/after traversal. Then what the user sees and what the system sees is static, so A1=A2=A3 and B1=B2=B3. That wasn't my point. My point was that once you've completely described what the user sees and what the system sees, you have described the behavior. There isn't something else left over. My claim is that if there is some aspect of behavior left over, then you have not completely described what the user sees and what the system sees. Behavior is appearance: that's all there is, there ain't no more.* Jon * Memo to the Recording Angel: Please note that this is the only time in my life that I have ever consciously agreed with a position taken by the late B. F. Skinner. Date: Thu, 23 Jan 1997 22:18:04 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Relationship Taxonomy Questions At 3:19 PM 1/23/97, Len Bullard wrote: >My point is simple: no normative linktypes. A way to express a >linktype is already available. It is an element type. Will these >interoperate? Only if the application programmer understands >the behavior implied or noted. But those are application conventions >and do not belong in the normative parts of the XML specification. This is rather oversimplified. The addressing mechanisms we are defining would be unliekly to work well without explicit support in the form of syntactic and semantic definitions of how they should be coded and what they should designate. >If they are there, and they are not procedurally defined (that is, >the operations for the data structure are not defined by function >or axiomatically), then their originators deserve the good horse laugh >the implementors will give them, and return to writing server-side >scripts for LiveWire. I finally get it, I think. You don't belive that it's possible to implement the indirection from a link to the code to make behavior for the link. Or else you believe that in 10 years we will still have the same set of crippled user-interfaces that we have today, and that we won't want to change how our footnote links are interpreted without changing (pardon me) "every single ****ing document" we've ever created in the meantime. Our miserable single browser windows, measly displays, and pathetic and disorienting frames are going to be history practically tomorrow. XML can do better than to require specific browser behaviours when defining link types. It has to do better, if it is not to perpetuate in linking the mess that it hopes to save us form in document representation. Linking behavior is a "formatting property". -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Thu, 23 Jan 1997 22:17:57 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Relationship Taxonomy Questions At 2:34 PM 1/23/97, Len Bullard wrote: >The problem is to figure out if hyperlink means: > >o data object > >o record > >o structure These all seem the same to me. > >By all means put a non-normative set of relationship types >in the spec. But these are domain-specific relationships. >They are application conventions. Topics, if you will. On this we agree. >Once you try to specify a class relationship (supertypes, subtypes) >and expect inheritance and interoperation, you have to specify >standard operations. Why? What are the standard operations on Mammals and elephants required to support the statement "An elephant is a mammal". This is simply false. It is true, that as we do _not_ have to define operations, we will _not_ get much benefit from the magic OO dust that you are once again asking us to sprinkle on presentational markup. >However, if you expect these XML processors to interoperate, >the easiest approach is to use some "pernicious" concepts >from real world systems. Your sponsors are already doing that. Sure. Why don't we use raw TeX for markup too? It does better text layout than any of these crappy browsers. The prevelance of bad solutions does not make them less bad. XML is about data representation. XML stylesheets are about coupling operations semantics to representations. XML linking should also be about representation. This is not deep, just tacking labels on, and co-indexing executable functions to the labels later on. It's a good idea for links for the same reason that it is a good idea for texts. SGML/XML markup is just about ataching labels, and letting the processor take care of itself. This does not always make life easier in the short run. I can get better results quickly with a word-processor than an SGML system. It should be no surprise if linking were to show similar phenomena. I think that a XML version of HTML (with example stylesheets to make it work) will provide the simple semantics for simple needs. In linking as with document structure, XML will have much more under the hood for the long term. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Thu, 23 Jan 1997 22:18:08 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Relationship types At 4:35 PM 1/23/97, Murray Altheim wrote: >Agreed. But the idea of establishing only the binding between an open >namespace of elements/attributes and an open namespace of >behaviors/relationships/ >presentational directives in a document which we may call a stylesheet, and >not the specific GI names, etc. is what I thought a meta-language was >about. Once we begin to specify specific, named relationships, we are into >the realm of DTDs and application conventions, ala RFC 1866. This is correct. What I think Eliot was saying, and I _am_ saying is that it _may_ be worth defining some simple roles, non-normatively, to help people understand what they are for, and how to use them. It's an idea that some on this list seem not yet to have figured out, and it might help people to see it in action. It might also be pernicious to try to kick-start things in this way, for linguistic and social reasons, as well as for the obvious reason that we will probably make some incorrect decisions as to good link-types, and this might simply get in the way of our successors. Personally, I'd rather see effort made in making some good examples that show how link and anchor typing can do things beyond the reach of "goto" links. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Thu, 23 Jan 1997 22:17:49 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Base At 3:28 PM 1/23/97, lee@sq.com wrote: >David Durand writes: >> But SYSTEM IDs should not be included. In SGML, they are reserved for >> "non-portable" identifiers, >No. They are system specific. They are not _required_ to be non-portable. >SGML makes no promise that they are portable. but certainly does not say >that any document using a portable SYSTEM identiifier is invalid!!! A SYSTEM identifier is _always_ non-protable, because I am not _required_ to implement any semantics for SYSTEM identifiers. >For XML, it would be possible and acceptable to requre specific forms of >system identifiers in certain places, and in fact we have already done so >by using URLs. Eliot's query was about a potential SGML feature. So I answered in terms of SGML. Actually, in SGML there's a bit better case because of FSIs, but even there, it's thin. In XML I think the case is worse, since a URL is well-known to be a transient thing. But as this is not an XML issue, we should abandon it. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Thu, 23 Jan 1997 14:34:23 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: Relationship Taxonomy Questions [Terry Allen:] | And in response to Jon's clear statement, I certainly don't want to | forbid him from taking this approach, and there is nothing in XML 1.0 | to prevent him from using it, but I don't want to be *required* to use it. | | Put another way, I need to be able to bind link behavior to my document, | and I want to be able to describe relationships that do not map | to behaviors. I think that we're in complete agreement on this part. When I send you XML data ("you" being a human, a browser application, or a nonbrowser application), I want to be able to: 1. Specify the behavior without telling you what I mean, or 2. Say what I mean and let you figure out what to do with it, or 3. Specify the behavior and tell you what I mean, but require that you follow the specified behavior regardless of what you think about it, or 4. Specify the behavior and tell you what I mean and let you make up your own mind about whether to follow the specified behavior. As the content provider, I want all of these options. Note that what I have just said applies to both the linking and the non-linking parts of the document and for the same reasons. Jon Date: Thu, 23 Jan 1997 21:40:24 -0600 From: len bullard To: "David G. Durand" CC: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions David G. Durand wrote: > > At 3:19 PM 1/23/97, Len Bullard wrote: > >My point is simple: no normative linktypes. A way to express a > >linktype is already available. It is an element type. Will these > >interoperate? Only if the application programmer understands > >the behavior implied or noted. But those are application conventions > >and do not belong in the normative parts of the XML specification. > > This is rather oversimplified. No. Read Eliot's earlier posts on the subject. > The addressing mechanisms we are defining > would be unliekly to work well without explicit support in the form of > syntactic and semantic definitions of how they should be coded and what > they should designate. The addressing mechanisms who are defining? > I finally get it, I think. You don't belive that it's possible to implement > the indirection from a link to the code to make behavior for the link. Nope. I think is easier to implement a declaration on an attribute that hints at behavior than to drag a DSSSL spec through the Internet. > else you believe that in 10 years we will still have the same set of > crippled user-interfaces that we have today, and that we won't want to > change how our footnote links are interpreted without changing (pardon me) > "every single ****ing document" we've ever created in the meantime. Nope. I think a gosub is a gosub and a goto is a goto. State space, not user interface. Read the MID documents sometime. Altering the documents to get rid of optional attributes is not exactly rocket science. Even SGML, nor will XML enable us to do what you claim can be done. We change them everytime we rehost. With SGML, we change them a heckuva lot less. > Our miserable single browser windows, measly displays, and pathetic and > disorienting frames are going to be history practically tomorrow. XML can > do better than to require specific browser behaviours when defining link > types. Yes, and VRML has done both already. You should study it and understand what frameworks are, how they work, and why they work that way. Now. Today. Not ten years from now. > It has to do better, if it is not to perpetuate in linking the mess that it > hopes to save us form in document representation. > > Linking behavior is a "formatting property". So you say. But that is yet another religious assertion. len Date: Thu, 23 Jan 1997 21:52:18 -0600 From: len bullard To: "David G. Durand" CC: w3c-sgml-wg@www10.w3.org Subject: Re: Relationship Taxonomy Questions David G. Durand wrote: > > At 2:34 PM 1/23/97, Len Bullard wrote: > >The problem is to figure out if hyperlink means: > > > >o data object > > > >o record > > > >o structure > > These all seem the same to me. See Fundamentals of Data Structures... just so you and the guy writing the parser can have the same conversation. > > > >By all means put a non-normative set of relationship types > >in the spec. But these are domain-specific relationships. > >They are application conventions. Topics, if you will. > > On this we agree. Good. A Table of Contents is a terrible thing to waste. > >Once you try to specify a class relationship (supertypes, subtypes) > >and expect inheritance and interoperation, you have to specify > >standard operations. > > Why? What are the standard operations on Mammals and elephants required to > support the statement "An elephant is a mammal". a == b. > This is simply false. It is true, that as we do _not_ have to define > operations, we will _not_ get much benefit from the magic OO dust that you > are once again asking us to sprinkle on presentational markup. No magic, David. > >However, if you expect these XML processors to interoperate, > >the easiest approach is to use some "pernicious" concepts > >from real world systems. Your sponsors are already doing that. > > Sure. Why don't we use raw TeX for markup too? It does better text layout > than any of these crappy browsers. The prevelance of bad solutions does not > make them less bad. Could be. It's a nice safe academic position. Hell on someone selling systems though, and hell on those who have to use them. HTML won because it was easy. Some folks have made that point to me too many times to forget it. > XML is about data representation. XML stylesheets are > about coupling operations semantics to representations. XML is about a standard syntax for enabling designers to write quick and dirty application languages and parsers. XML stylesheets do not exist, nor do they have to. You want them to, and you want them to be something you like, but I am not bound by that nor is XML. At least, not yet. > XML linking should also be about representation. This is not deep, just > tacking labels on, and co-indexing executable functions to the labels later > on. It's a good idea for links for the same reason that it is a good idea > for texts. Goto(label). Considered pretty weak even in C. > SGML/XML markup is just about ataching labels, and letting the processor > take care of itself. This does not always make life easier in the short > run. I can get better results quickly with a word-processor than an SGML > system. Right. So? > It should be no surprise if linking were to show similar phenomena. I > think that a XML version of HTML (with example stylesheets to make it work) > will provide the simple semantics for simple needs. No doubt about it. The trick will be to get a user who never had to write a stylesheet before to do to do it now: for the cause. > In linking as with document structure, XML will have much more under > the hood for the long term. Two blank eyes stare back from under the hood of the robe of academic theory. They see... a 1970 database where a millenium object-oriented system should be. The poverty...ahh, the poverty. len To: w3c-sgml-wg@www10.w3.org Subject: Taxonomy List Date: Fri, 24 Jan 1997 08:57:24 -0700 From: Dave Hollander I have found the debate interesting but now it is bordering on redundant since I see little in the way of new ideas. Of course, you may disagree and if so, just keep the old string alive. To try to get a different view on the question, I am copying a string >from the html-wg that is discussing link relationships in LYNX. Can we focus on a list and try to build a case from example? (deductive vs inductive) I know any list is bound to get *very large*. That is not the point. Can any abstractions be found that withstand the scrutiny that this list has to offer? Home Up Next Previous (Prev) Top Child Sibling Parent Begin End First Last = all of these are content hierarchy structure relationships except for the name literal they seem quite common and well understood. There is the argument that not all entities have these relationships, so this class must not be required. Banner Navigator Help Bookmark Pointer = user aids? ToC Contents Index Glossary = all of these are indices that may/should/do contain references to this entity. Translation Bibliography = related by same information in different representation form. would we well applied to media "translations": text, video ... Copyright Origin Disclaimer Author Editor Publisher Trademark Meta = meta info about the entity Having tried this, I feel a little better. I think we should be able to come up with some system that will help make the online world a little tamer. Sure, this is beyond the pure land of meta-language. We knew that we would have to go there in discussing links and style. Yes, these "application" level details will make the standard less able to withstand the test of time. We should make sure that these sections are separable >from the body of the XML spec. Please, help build something or prove that it can not be done. Intellectual debate helps tune the thinking but proves nothing. Dave Hollander ------- Forwarded Message Date: Thu, 23 Jan 1997 19:37:08 -0800 (PST) From: Subir Grewal To: html-wg@www10.w3.org Cc: Lynx Development List Subject: Lynx and the LINK tag. A few notes on Lynx's handling of LINK tags. After reading Peter's note (that Lynx may not be handling all the standardized LINK REL/REV attributes) I was curious enough to glance at the Lynx code to see what was happening with LINK, I found it handles a lot more rel attributes than I thought it did, though I'm not sure whether it handles all of the standardized ones (but Fote's note gives me the impression these are all the attributes defined in the DTDs for 3.0 and 3.2). Here's my analysis of the scenario based on a cursory glance at the source code [1] - -----Begin snippet from src/HTML.c----- /* * Ignore anything not registered in the the 28-Mar-95 * IETF HTML 3.0 draft and W3C HTML 3.2 draft, or not * appropriate for Lynx banner links in the expired * Maloney and Quin relrev draft. We'll make this more * efficient when the situation stabilizes, and for now, * we'll treat "Banner" as another toolbar element. - FM */ - -----End snippet from src/HTML.c----- Now, extrapolating from the code that follows, I see that Lynx handles the following REL attributes for the LINK tag (basically creating a toolbar, using the attribute value as the linked text and the href value as the href for the linki. If there's no href the tag is ignored). Home ToC Contents Index Glossary Copyright Up Next Previous Prev Help Bookmark Banner Top Origin Navigator Child Disclaimer Sibling Parent Author Editor Publisher Trademark Meta Begin First End Last Pointer Translation Bibliography In addition it does something special with the following REL attributes: Home Help Index And Lynx recognizes the following REV attributes: owner made title (Owner is used while constructing the info '=' page, as far as I know that's equivalent to ' I think this should be: [21] Comment := '' Same for [22] Date: Tue, 28 Jan 1997 08:44:25 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: Anchor terminology [Tim Bray:] | Jon's proposal seems OK, except for I find the term "end-spec" | horribly unaesthetic. I do, too. I was just trying to be doggedly accurate. | How about "link", "pointer", and "target". Ropes are really a lousy | metaphor, and "end" is really not descriptive of what a pointy bit | does. Also, given the realities of the web, "pointer" and "target" | are quite accurate. I would like to use "pointer". (In fact, I thought after I sent the first message, "Why not pointer? That's the word I keep using in my head.") But "target" is too directional. "Pointing at link ends" is one thing; "traversing a link from one target to another" is just not English, not even technical English. Just as we will call pointers "pointers" whenever we're not making a special effort, we will call link ends "link ends". (The current draft is forced to use the term "endpoints" and then has to apologize for it.) I don't have the problem that Peter Flynn does with "traversal". It's a technical term for a technical thing, and it does no violence to the language. "This link has three ends, which are referenced by these three pointers. When you click on the end over here, you are presented a menu that allows you to choose which of the other two ends the link will traverse to." Works for me. Jon Date: Tue, 28 Jan 1997 08:46:02 -0800 (PST) From: Terry Allen To: w3c-sgml-wg@www10.w3.org Subject: TEI xptrs as URLs? How may TEI extended pointers be expressed as URLs? Regards, Terry Date: Tue, 28 Jan 1997 12:31:39 -0500 To: Peter Flynn From: "Eve L. Maler" Subject: Re: Anchor terminology Cc: w3c-sgml-wg@www10.w3.org At 10:44 AM 1/28/97 +0000, Peter Flynn wrote: >> (1) the basket that the pointy bits go in >> (2) the pointy bits that point at things >> (3) the things the pointy bits point at > >> How about "link", "pointer", and "target". > >That's the clearest explanation so far, facetious or not. The problem >we seem to face is that while _we_ can discuss this using (for example) >HyTime terminology, once we [re]enter the Real World [tm], we are going >to have to document this in terms that implementors and authors can >grasp easily, and that means link, pointer, and target. We are also >going to have to deal with the use of words like "source" and >"destination", as users will persist for some time in conceiving of >links as unidirectional: "Link" is fine (the only word we all seem to have settled on :-). "Pointer" is fine, too, though "address" might be better: Is a pointer potentially made of a chain or relative addresses, or is an address made of a chain of relative pointers? "Target" tends to imply directionality, and it seems useful to have a term for "link ends" that has no such implication. Then you can use "source" and "target" (or "destination") to define such terms as "bi/multi-directionality," and to discuss link traversal behavior intelligently. I'm not crazy about "link ends" because it sounds weird to talk about "source/starting/jumping-off *ends*," but everything else I can come up with is just as weak: "link locations," "link points," "linked-to places"... Sigh -- maybe "target" is best. >Personally I'd like to avoid the use of the word "anchor" altogether, >in documenting or publicising XML: it simply is not easily explainable >to the author or user. Anchors are things that stop ships going adrift, >and the only possible explanation in discussing hypertext linking is to >say that an anchor is the {pointer|start-point|source|beginning|jump-off} >of a link that holds the world steady while you follow (not "traverse", >please) the link to somewhere else: the clear implication being that >while the anchor holds, you can follow the link back again to where you >started. That's too much for many people to swallow: pointer is clearer. >"Double-ended pointer" is even clearer when we come to demonstrate >bidirectionality. (Not to mention the fact that HTML's
breaks this proper sense of "anchor.") I agree with avoiding the scarlet letter. Do we even need to have a term for elements that are explicitly supposed to be link ends? Can we just call them "link end elements" (or whatever we settle on for directionless targets)? Eve Date: Tue, 28 Jan 1997 13:40:39 -0400 To: "Eve L. Maler" From: murray@spyglass.com (Murray Altheim) Subject: Re: Anchor terminology Cc: w3c-sgml-wg@www10.w3.org "Eve L. Maler" writes: [..] >"Link" is fine (the only word we all seem to have settled on :-). > >"Pointer" is fine, too, though "address" might be better: Is a pointer >potentially made of a chain or relative addresses, or is an address made of >a chain of relative pointers? I like Jon's terminology, agreeing with most of the comments following. Regarding pointers and addresses, I would think the latter to be more understandable, given: Murray Altheim Spyglass, Inc. One Cambridge Center Cambridge Massachusetts 02142 USA ...is an address made of a chain of relative pointers. An address seems to me an opaque string, similar to a URL. Terry Allen wrote: >How may TEI extended pointers be expressed as URLs? My knowledge of TEI is rather minimal, so I wasn't sure if he was asking the manner, or the current usage of TEI extended pointers expressed as URLs. I was thinking we might borrow from the Web a "#" character and try: HREF/IDREF="http://www.foo.com/mydirectory/index.xml#ID%20(a25)%20CHILD(2%20 CHAP)" Since there's no way around escaping the spaces, it's going to look ugly unless we collapse all spaces something like: HREF/IDREF="http://www.foo.com/mydirectory/index.xml#ID(a25)CHILD(2/CHAP)" Murray ``````````````````````````````````````````````````````````````````````````````` Murray Altheim, Program Manager Spyglass, Inc., Cambridge, Massachusetts email: http: "Give a monkey the tools and he'll eventually build a typewriter." Date: Tue, 28 Jan 1997 14:17:28 -0500 From: gtn@ebt.com (Gavin Nicol) To: pgr@kirk.mit.edu CC: w3c-sgml-wg@www10.w3.org Subject: Re: Production 21 (and others) I think the comment syntax has changed to <--* *--> anyway.... To: w3c-sgml-wg@www10.w3.org Subject: Re: Anchor terminology Date: Tue, 28 Jan 1997 11:30:43 -0800 From: Joe English I find it puzzling that the XHL draft has replaced the HyTime terminology "contextual link" and "independent link" -- about which to my knowledge nobody has complained -- in favor of the _de novo_ "inline link" and "out-of-line link", yet it retains the terms "anchor" and "link end", which nobody seems to like. At the risk of introducing yet another set of terms that half the world will find objectionable (hyperlink terminology being an even more contentious issue than object-oriented terminology), may I suggest "reference" for what XHL calls a "link end", and "referent" for what it calls an "anchor"? These seem to me more intuitive (and the phrase "reference role" is nicely alliterative, plus easier to pronounce than "anchor role" which it would replace). "Reference" and "referent" no doubt already have an established meaning in some other context (probably OOP), but other than that I can't think of any drawbacks... --Joe English jenglish@crl.com Date: Tue, 28 Jan 1997 14:23:48 -0500 From: gtn@ebt.com (Gavin Nicol) To: tallen@fsc.fujitsu.com CC: w3c-sgml-wg@www10.w3.org Subject: Re: TEI xptrs as URLs? >How may TEI extended pointers be expressed as URLs? We've already shown some different possible syntaxes... one with TEI pointers as fragment specifiers and the other with the pointer as part of the URL itself (David and I had a length debate about these recently!!). Date: Tue, 28 Jan 1997 11:42:48 -0800 (PST) From: Terry Allen To: w3c-sgml-wg@www10.w3.org Subject: What's a Referrer? What's a Referrer? Section 4.2 reads: | Many addressing mechanisms assume the existence of some sort of a base | address whose value effects the interpretation of the address. To | formalize this, every HREF has a location source, an object or objects | which serves as the base address. In most cases the location source can "base address" needs definition. | be omitted and is implied to be the document element of the document | that contains the link. However, this implied location source can also | be specified as being the non-link element that refers to the link | element (the referrer). What does that last sentence mean? And if the "implied location source" (a.k.a. "base address", which is more homey) is specified, in what manner is it still implied? What is the reason for having both locsrc and implied-locsrc? And it seems as though the "base address" may vary with each occurrence of a link element. Do we need that? | The location source is specified using the the location-source | attribute. The format of the location-source string is not specified; to | be useful, clearly it must be in a form that can be processed by the | processor that can deal with the HREF and reference type to which it is | attached. If the location-source attribute is omitted, the location | source is implied according to the rule indicated by the IMPLIED-LOCSRC | attribute. This implies that every HREF value has a "base address", whether the author intended to employ such a mechanism or not. I wouldn't be surprised if that assumption screws up some addressing scheme, though I don't have one in mind. Perhaps this should be qualified such that a "base address" is implied only if HRTYPE is an addressing scheme that uses a relative addressing mechanism. Also, the punt on the format of the string is unsatisfactory. We won't get interoperability unless we can say what the format must be; if this varies with HRTYPE then reference should be made to some canonical statement of what a "base address string" is for that HRTYPE (for HRTYPEs the use of which is anticipated) or it should be said that the specification of HRTYPEs that use relative addressing must include an unambiguous specification of "base address string" for that HRTYPE. Note that HRTYPEs not mentioned in this spec will not be implemented by all implementors. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Date: Tue, 28 Jan 1997 11:53:43 -0800 (PST) From: Terry Allen To: gtn@ebt.com, tallen@fsc.fujitsu.com Subject: Re: TEI xptrs as URLs? Cc: w3c-sgml-wg@www10.w3.org Gavin responds: | >How may TEI extended pointers be expressed as URLs? | | We've already shown some different possible syntaxes... | one with TEI pointers as fragment specifiers and the other | with the pointer as part of the URL itself (David | and I had a length debate about these recently!!). I think one and only one syntax should be chosen (preferrably by the TEI folks rather than the SERB). Then it should be ascertained whether existing servers (no arguments about software that doesn't exist, please, or at least take them to another thread I can ignore) can deal with such URLs. If they can't, cut TEI pointers out of the xmllink spec because they won't work. If they can, require TEI pointers to be expressed as URLs and cut TEI pointers out of the xmllink spec (except for a reference to the separate specification of how you URLulate a TEI pointer) because it's not necessary to talk about types of URLs. Regards, Terry Date: Tue, 28 Jan 1997 15:02:34 -0500 From: gtn@ebt.com (Gavin Nicol) To: tallen@fsc.fujitsu.com CC: tallen@fsc.fujitsu.com, w3c-sgml-wg@www10.w3.org Subject: Re: TEI xptrs as URLs? >| >How may TEI extended pointers be expressed as URLs? >| >| We've already shown some different possible syntaxes... >| one with TEI pointers as fragment specifiers and the other >| with the pointer as part of the URL itself (David >| and I had a length debate about these recently!!). > >I think one and only one syntax should be chosen (preferrably by >the TEI folks rather than the SERB). I think both *type* have a place. Fragment ID's can be used for client-side sub-document addressing, and URL addressing can used to identify objects at a finer granularity than entities/documents. They could share a common syntax, I agree. Date: Tue, 28 Jan 1997 12:23:10 -0800 (PST) From: Terry Allen To: w3c-sgml-wg@www10.w3.org Subject: Entity and Element Addressing Entity and Element Addressing | 4.3 SGML Reference Types | SGML HREFs use standard SGML Element and Entity addressing mechanisms. | If the reference type is ENTITY, then the HREF must be an entity name | which references an external entity. "External entity" is defined in XML 1.0, s.v. 4.2.2, which should be referred to here (some readers will become confused and wonder whether they can use this mechanism to refer to é). I note from XML 1.0, s.v. 2.2, that in a well formed XML document, for each entity reference, the entity name must be declared in the doctype declaration (at that point, reference might be made to 2.9, in which the concept of internal and external subsets is introduced). S.v. 4.2.2, the system identifier must be a URL (should the sentence following the Validity Check following production 71 start "The SystemLiteral"?). It might be worth while pointing out that in xmllink, addressing by entity means addressing by URL using entities for indirection. Is ENTITIES allowed? | If the reference type is ELEMENT, | then the HREF must be the value of a unique identifier attribute within "Unique identifier attribute" isn't language I can find in XML 1.0. Is "ID value" intended? What of ELEMENTS, in the plural? (In other words, is this really IDREF/IDREFS?) | the current document. If the reference type is SGML, then the HREF must | contain an entity name interpreted as with ENTITY, followed by the | character "#", followed by the value of a unique identifier attribute | within the document referenced by the leading entity name. What happens when the system identifier for the entity already contains a #? What is the force of "leading" in "leading entity name"? 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 From: lee@sq.com Date: Tue, 28 Jan 97 21:48:39 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: Anchor terminology Peter Flynn said: > Personally I'd like to avoid the use of the word "anchor" altogether, > in documenting or publicising XML: it simply is not easily explainable > to the author or user. How about: Anchors (in the mere mortal non-HyTime sense) are active regions in documents. Lee Date: Tue, 28 Jan 97 22:11:10 CST From: Michael Sperberg-McQueen Subject: Re: Production 21 (and others) To: W3C SGML Working Group On Tue, 28 Jan 1997 10:22:45 -0500 Pierre G. Richard said: >On the draft I have (961114): > > [21] Comment := '' > >I think this should be: > > [21] Comment := '' Why? If we replace some of the expressions with named macros, it may make clearer why the draft doesn't have the second star -- or else make clearer to me why it *should*. If we define NH (= non-hyphen) as anything but a hyphen, and OH (= one-hyphen) as a string containing exactly one hyphen, at the beginning, and at least one other character -- in lex notation: NH [^-] OH "-"{NH}+ Then we have [21] Comment := "" [21] Comment := "" [21] Comment := "" and the material between the comment open and close delimiters is 'any sequence of characters that contains no double hyphens': i.e. 1 the string up to the first hyphen (= {NH}*), possibly empty 2 the string from the first hyphen up to but not including the second (= {OH}) n the string from the (n-1)th hyphen up to the nth hyphen (={OH}) Substrings 2..n are all taken care of by {OH}*; we don't need to go back to the first {NH}*. Does this make sense? But as Gavin has pointed out, the comment syntax has changed. Life would be simple if we could trust parsers to do the right thing given ambiguous or non-deterministic expressions: "" But we can't. And so the new rule has to be summarized as follows: "" Or, in simpler terms, NHS (Not Hyphen or Star) is any character not a hyphen or an asterisk: NHS [^-*] SH (Star and Hyphen) is an asterisk followed by an optional hyphen: a string of asterisks and hyphens that does not contain any double hyphens can be expressed as {SH}+ or "-"{SH}*, depending on whether it begins with a star or a hyphen. SH ("*""-"?) HS (hyphen and star) by contrast, is any string of hyphens and asterisks which *ends* in a hyphen and contains no double hyphens: HS ("*"|"-*")+ Finally, Misc is any string of characters that *ends* in a character other than star or hyphen: Misc {NHS}|("-"{SH}*{NHS})|({SH}+{NHS}) So we have, expanding gradually: [21] Comment := "" [21] Comment := "" [21] Comment := "" [21] Comment := "" [21] Comment := "" At least, I *think* this is right! The DFA for comments, by contrast, is really simple and easy to follow. It took me several tries (and, embarrassingly, several hours went to some really loony false trails) to get a regular expression that handles the obvious test cases. So I urge anyone with any interest in this kind of problem -- and everyone who is working on a parser! -- to check the expression above as carefully as you can. Now is the time to smoke out the errors, not later. -C. M. Sperberg-McQueen Date: Wed, 29 Jan 1997 08:27:38 -0500 From: gtn@ebt.com (Gavin Nicol) To: tallen@fsc.fujitsu.com CC: w3c-sgml-wg@www10.w3.org Subject: Re: Entity and Element Addressing >I note from XML 1.0, s.v. 2.2, that in a well formed XML document, >for each entity reference, the entity name must be declared in >the doctype declaration (at that point, reference might be made I am not convinced that this is a necessary check for well-formedness. Date: Wed, 29 Jan 1997 09:52:09 -0500 From: gtn@ebt.com (Gavin Nicol) To: U35395@UICVM.UIC.EDU CC: w3c-sgml-wg@www10.w3.org Subject: Re: Production 21 (and others) > "" Sigh... would that one could use exclusive start starts in the grammar... In an actual flex scanner, one would probably do something like: %x comment %% "<--*" BEGIN(comment); . "*-->" BEGIN(INITIAL); Date: Wed, 29 Jan 1997 07:19:54 -0800 To: w3c-sgml-wg@www10.w3.org From: Tim Bray Subject: Re: Entity and Element Addressing At 08:27 AM 29/01/97 -0500, Gavin Nicol wrote: >>I note from XML 1.0, s.v. 2.2, that in a well formed XML document, >>for each entity reference, the entity name must be declared ... > >I am not convinced that this is a necessary check for well-formedness. Hmm, it's a pretty fundamental point. If I see an undeclared reference it could have indicated anything from a single gaiji to the text of the Critique of Pure Reason; not knowing seems seems pretty evil. My conception of Well-Formedness has always been along the lines of "you can build the right parse tree". Now, we have partially ducked that by saying that you don't have to fetch & parse external text entities; but you do have to know what the reference is pointing at. What are the advantages to relaxing this restriction? And if there are lots of others who agree with Gavin on this, speak up. - Tim Date: Wed, 29 Jan 1997 10:24:26 -0500 From: gtn@ebt.com (Gavin Nicol) To: U35395@UICVM.UIC.EDU CC: w3c-sgml-wg@www10.w3.org Subject: Re: Production 21 (and others) Michael has the rule for comments: "" using flex as a test lexer, I tried the following successfully. "" I used the following as test data: <--* This is a big ugly comment *-> *--> Date: Wed, 29 Jan 1997 07:35:11 -0800 (PST) From: Terry Allen To: U35395@UICVM.UIC.EDU, w3c-sgml-wg@www10.w3.org Subject: Re: Production 21 (and others) Michael writes: [21] Comment := "" [21] Comment := "" [21] Comment := "" [21] Comment := "" [21] Comment := "" I'm sure the SERB had good reasons for the new comment syntax, but it certainly isn't simple and some of us will have to explain it to skeptics. Could we have a very short statement of what was wrong with SGML comment syntax that the XML comment syntax fixes, and why the XML solution was chosen? Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Date: Wed, 29 Jan 1997 10:56:13 -0500 (EST) To: w3c-sgml-wg@www10.w3.org Terry Allen on Tue, 28 Jan 1997 11:42:48 -0800 (PST)) Subject: Re: What's a Referrer? From: John_Lavagnino@Brown.edu Terry Allen wrote about a point which puzzles me too: namely, | What's a Referrer? In Section 4.2 the "implied location source" or "base address" for a link element can have one of two fixed values, DOCELEM and REFERRER. DOCELEM is the document element (of the document containing the link element, one assumes): that's clear enough. The REFERRER is "the non-link element that refers to the link element", which is puzzling, since in this scheme there's no apparent way for a non-link element to make a meaningful reference to a link element. My best guess on this is that the two sorts of base address we would want to see in this scheme (at least as our first options, perhaps to be supplemented by more) are really what the TEI extended pointer language calls ROOT and HERE: ROOT meaning the document element (for which this draft uses the attribute value DOCELEM), and HERE meaning the place where the link element is (rather than the place where some other element that somehow refers to it lives, which is what this REFERRER seems to be). If this is what's intended, or at least what makes sense as a specification, then perhaps the values ROOT and HERE would also be clearer than DOCELEM and whatever. ("Document element" is not one of those opaque or misleading SGML terms, but it is still less self-evident to the masses than "root element", which is the gloss that this draft provides.) John Lavagnino Women Writers Project, Brown University Date: Wed, 29 Jan 1997 08:01:38 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: XML for beginners | importance to us but the distillation of the ERB will need to be | presented in a manner where relative non-specialists can get | started in a gentle manner. | | What I said, Documentation, documentation, documentation. Yes, we're all for it. Anyone want to put together an XML FAQ for starters? Jon From: "Christopher R. Maden" Date: Wed, 29 Jan 1997 15:51:28 GMT To: w3c-sgml-wg@www10.w3.org Subject: Re: Production 21 (and others) [Gavin Nicol] > > > > *--> The regexp should bar *-- within a comment (and -- unless the TC passes in time). Even though, from XML's point of view, only *--> can end a comment, these are still SGML comments, and *-- as comc would still end the comment within the comment declaration. -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) Date: Wed, 29 Jan 1997 08:17:46 -0800 (PST) From: Terry Allen To: w3c-sgml-wg@www10.w3.org Subject: Entity Ignorance Tim Bray writes: | My conception of Well-Formedness has always been along the lines of | "you can build the right parse tree". Now, we have partially ducked | that by saying that you don't have to fetch & parse external text entities; | but you do have to know what the reference is pointing at. I'm sorry to have missed this point (4.3, number 8) first time around. This is unacceptable, and the rationale, "... may not be appropriate for other applications, in particular document browsing," is unconvincing. How can you browse a document if you can't see it all? How can you expect people to use a markup scheme if the results are undefined ("yeah, sure, you can use entities, but that text may just turn up missing")? As this makes entities essentially useless, why not get rid of them altogether? And how is this compatible with SGML? (I will not engage in any discussion about whether an author has the right to expect the integrity of his document to be repected by an comformant application; if you want to take that view, please change the subject line so I can ignore you.) Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Date: Wed, 29 Jan 1997 11:34:22 -0500 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@www10.w3.org Subject: Re: Entity and Element Addressing >My conception of Well-Formedness has always been along the lines of >"you can build the right parse tree". Now, we have partially ducked >that by saying that you don't have to fetch & parse external text entities; >but you do have to know what the reference is pointing at. Fine. My point is that even if entities are "missing", the result of a parse should be "well-formed" (ie. the tree is correct except for the missing nodes). >What are the advantages to relaxing this restriction? And if there >are lots of others who agree with Gavin on this, speak up. - Tim 1) It allows you to use entities, even when you don't have a declaration subset or DTD. 2) It can help to reduce packet sizes in a realtime environment. 3) It can make it easier to generate content dynamically. My ideas for entity resolution were posted long ago to this list. Basically, if all else fails (ie. no catalog, no declarations), then I would like to see clients looking for "foo" or "foo.xml" relative to the URL of the referring entity. A little extra robustness and flexibility. Date: Wed, 29 Jan 1997 11:50:44 -0500 From: gtn@ebt.com (Gavin Nicol) To: crm@kirk.mit.edu CC: w3c-sgml-wg@www10.w3.org Subject: Re: Production 21 (and others) >The regexp should bar *-- within a comment (and -- unless the TC >passes in time). Even though, from XML's point of view, only *--> can >end a comment, these are still SGML comments, and *-- as comc would >still end the comment within the comment declaration. Good point. The more restrictive form is: "" Hmm. What does that say about "]]>" in data... Date: Wed, 29 Jan 1997 08:44:25 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: 'XML browser' [Peter Murray-Rust:] | I'd like to suggest features of 'an XML browser' and a 'generic XML | application'; this also picks up the themes of 'killer apps' and | 'marketing' which have been raised by Jon and others. I appreciate | that implementation may be slightly off-topic but I have personally | found that it's very valuable to have an idea of what the final | product (e.g. XML is going to be used for and what it will look | like). I really like this line of thought, but given the need to stay focused on the XML linking stuff for the next couple of months, I (somewhat reluctantly) am going to rule this level of discussion out of bounds for the moment. Unfortunately there is no ideal place for it; there is no comp.text.xml list, and I don't know that we have arrived at the right time to start one. (Does someone want to set up an open XML mailing list? It's a lot of work.) Until some better alternative appears, I suggest that discussions like this one take place in comp.text.sgml. Jon Date: Wed, 29 Jan 1997 11:58:39 -0500 From: gtn@ebt.com (Gavin Nicol) To: tallen@fsc.fujitsu.com CC: w3c-sgml-wg@www10.w3.org Subject: Re: Entity Ignorance >And how is this compatible with SGML? SGML does not prescribe error recovery mechanisms for references to undeclared entitie, and one possible recovery strategy is to look for the entity using the name of entity: &bar; would result in a search for an entity named "bar", perhaps by looking in a catalog, relative to the referring entity, etc. I think this may end up being *more* robust in some ways, because people will have to implement a default behaviour for cases where entities are not declared, which they otherwise may not have to. This will also make it easier to parse entities in isolation. Date: Wed, 29 Jan 97 10:22:18 CST From: Michael Sperberg-McQueen Subject: Re: Production 21 (and others) To: W3C SGML Working Group On Wed, 29 Jan 1997 10:26:52 -0500 Gavin Nicol said: >Michael has the rule for comments: > > "" > >using flex as a test lexer, I tried the following successfully. > > "" > >I used the following as test data: Some of which should pass through OK, and some of which should raise errors. > > OK. > > > > <--* This is a big ugly comment *-> > *--> All errors: '--' os prohibited within XML comments, for compatibility with SGML, and even after the TC passes, which will (in its current form) allow for distinct como and comc delimiters (--* and *--), the string *-- will, as Chris Maden points out, remain illegal for compatibility reasons. Terry Allen asks for a rationale. What follows is mine; it's not inconsistent with what others on the ERB think, that I know of, but it goes well beyond what I know them to believe. I think it's fair to say the arguments against the change were primarily of the "why change it? it's not broken" variety: any change away from the reference concrete syntax may confuse people who are used to the RCS. No arguments were made in favor of the '--' toggle on its merits. The arguments in favor of changing the comment syntax were that a prohibition on '--' in comments which are *not* ended by '--' makes no sense and *is* clearly broken as designed. And since it's broken solely for reasons of compatibility, the question arises "What changes to SGML might remove this problem?" The discussion of this question seemed to make clear that the preferred solution would be to distinguish comment-open (como) from comment-close (comc) delimiters; this would enable XML to have distinct como and comc delimiters, with comc something other than '--'. In particular, Lee Quin's suggestion to use --* and *-- as como and comc seemed particularly good, since it can be (mis)interpreted in terms of the RCS without catastrophic error. So the TC which is expected to go to the appropriate ISO body calls for the introduction of como and comc delimiters. When the TC passes, we want to be able to remove the prohibition on '--' in comments. This is possible only if XML defines strings which can be used, in Full SGML systems, as the como and comc delimiters. So we need to do that, and we need to do it now, now after the TC passes. Of the various candidates for como and comc, --* and *-- won hands down: they are symmetrical, usable now, and not radically different from current practice. After the TC, XML can remove the prohibition on --, though not the prohibition on *--. And there will still be a minor inconvenience in that comments will still be unable to nest, though there is no reason, given distinct open and close delimiters, to forbid nesting of comments, and in practice it would be very convenient to be able to comment out a block of text without having to check first to see if it already contained any comments. (An IGNORE marked section can be used this way, but I persist in the belief that marked sections are not comments, and using them this way constitutes markup abuse.) Finally, it should be pointed out that although the deterministic regular expression for comments is complicated, the comment structure itself is very simple and easy to describe: Comments begin with ''. Within a comment, anything is legal except '--'. After the TC, these rules can change (and will, unless the ERB rescinds its decision of earlier this month) to: Comments begin with ''. Within a comment, anything is legal except '*--'. And at that point, the regular expression in the document can presumably change to something more like Gavin's proposal above (though not *exactly* the same, since Gavin allows '*--' if not followed by '>', which XML will have to continue to forbid, for compatibility reasons. I make the new rule out to be: "" Since *-- is much rarer in normal text than --, which in many people's ingrained habit is the expression of an em-dash, XML will be made perceptibly more user-friendly when the change is made. To make the change, however, it's necessary to change the XML comment delimiters. This was enough to persuade the ERB, including myself, that the change was a necessary and good idea. I hope it persuades you, too. -Michael Date: Wed, 29 Jan 1997 09:10:01 -0800 To: w3c-sgml-wg@www10.w3.org From: Tim Bray Subject: Re: Entity Ignorance At 08:17 AM 29/01/97 -0800, Terry Allen wrote: >I'm sorry to have missed this point (4.3, number 8) first time around. >This is unacceptable... Sorry, Terry. This was one of the single most debated points in the whole XML process; the ERB reversed itself no less than twice, under heavy (and justified) WG pressure. Hit the archive and relive the joy of debate. I think this one is (a) not going to change and (b) the correct decision. - Tim From: lee@sq.com Date: Wed, 29 Jan 97 10:47:00 EST To: w3c-sgml-wg@www10.w3.org, U35395@UICVM.UIC.EDU Subject: Re: Production 21 (and others) I would write this as comment := <--* comment_data *--> comment_data := (definition of cdata) If -- is still forbidden, I would list that explicitly in the text: Note: the string -- must not appear within comment_data in this revision of XML. Lee Date: Wed, 29 Jan 1997 11:17:38 -0600 From: Len Bullard To: Jon Bosak CC: w3c-sgml-wg@www10.w3.org Subject: Re: 'XML browser' Jon Bosak wrote: > > [Peter Murray-Rust:] > > | I'd like to suggest features of 'an XML browser' and a 'generic XML > | application'; this also picks up the themes of 'killer apps' and > | 'marketing' which have been raised by Jon and others. I appreciate > | that implementation may be slightly off-topic but I have personally > | found that it's very valuable to have an idea of what the final > | product (e.g. XML is going to be used for and what it will look > | like). > > I really like this line of thought, but given the need to stay focused > on the XML linking stuff for the next couple of months, I (somewhat > reluctantly) am going to rule this level of discussion out of bounds > for the moment. Unfortunately there is no ideal place for it; there > is no comp.text.xml list, and I don't know that we have arrived at the > right time to start one. (Does someone want to set up an open XML > mailing list? It's a lot of work.) Until some better alternative > appears, I suggest that discussions like this one take place in > comp.text.sgml. Noting the recent inquiries on CTS about what is XML and why should one care, such a discussion should be easy to start. When Peter originally posted his announcement about CML and his applications, I encouraged everyone to look. The use of the tree object and the windows for different processing of the language was excellent. This approach is used by some VRML editors to very good advantage (e.g, V-Realm Builder). Visual Basic 4 includes a tree object (outline object) with Add Item methods that should work well. So, yes, moving this XML As Applied thread to CTS would be most beneficial IMO. len bullard Date: Wed, 29 Jan 1997 12:54:00 -0500 From: gtn@ebt.com (Gavin Nicol) To: U35395@UICVM.UIC.EDU CC: w3c-sgml-wg@www10.w3.org Subject: Re: Production 21 (and others) >Finally, it should be pointed out that although the deterministic >regular expression for comments is complicated, the comment structure >itself is very simple and easy to describe: > > Comments begin with ''. > Within a comment, anything is legal except '--'. Very simple rule: "" > >After the TC, these rules can change (and will, unless the ERB rescinds >its decision of earlier this month) to: > > Comments begin with ''. > Within a comment, anything is legal except '*--'. You and I came up with exactly the same thing: "" Date: Wed, 29 Jan 1997 13:30:04 -0500 To: W3C SGML Working Group From: "Eve L. Maler" Subject: Re: Production 21 (and others) At 10:22 AM 1/29/97 CST, Michael Sperberg-McQueen wrote: ... >After the TC, XML can remove the prohibition on --, though not the >prohibition on *--. And there will still be a minor inconvenience in >that comments will still be unable to nest, though there is no reason, >given distinct open and close delimiters, to forbid nesting of comments, >and in practice it would be very convenient to be able to comment out a >block of text without having to check first to see if it already >contained any comments. (An IGNORE marked section can be used this way, >but I persist in the belief that marked sections are not comments, and >using them this way constitutes markup abuse.) ... Comments are supposed to be text that's meant for the eyes of source-file readers, and not legitimate document content that's temporarily not supposed to be output. "Commenting out" text in various markup languages is sometimes achieved by "comments" (especially where that's your only choice) and sometimes by "ignore regions." For example, in troff, you can use .\" or .ig, but as in SGML, .ig is much more appropriate for both practical and, uh, philosophical reasons. So I'd argue the other way around: Comments are not IGNORE marked sections, and using them to ignore blocks of document content constitutes markup abuse. So there. :-) Eve Date: Wed, 29 Jan 1997 10:32:31 -0800 (PST) From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@www10.w3.org Subject: Re: Entity Ignorance >Sorry, Terry. This was one of the single most debated points in the whole XML process; the ERB reversed itself no less than twice, under heavy (and justified) WG pressure. Hit the archive and relive the joy of debate. I think this one is (a) not going to change and (b) the correct decision. - Tim Then I'll just point out that 4.3.8 allows the entity to be ignored even when it has been served to the client, e.g., when it's bundled with the main document. Few sane publishers will find entities attractive in XML. Regards, Terry Date: Wed, 29 Jan 1997 20:31:15 +0000 To: w3c-sgml-wg@www10.w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Re: Production 21 (and others) [Eve Maler] >Comments are supposed to be text that's meant for the eyes of source-file >readers, and not legitimate document content that's temporarily not >supposed to be output. To the eyes of non-SGML software types, SGML comments are kinda weird cos they are constructs of the core language. In many programming languages they are stripped out by the initial lexical analysis phase. The upside of stripping them out during simple minded lexical analysis is the shear simplicity of it. The *downside* is that language processors that Read/Write the language loose the ability to re-create the comments on the other side. This raises the question - what are the constraints on XML aware applications when it comes to parsing->processing->writing XML. Is there something along the lines of a (much simplified) DSSSL Null Transformation??? A related question, in SGML two docs are considered equal if they produce the same ESIS stream. Will there be a similar concept in XML? Kinda useful in checking that an XML application interprets the document structure as intended... Sean Mc Grath digitome@io.ie Date: 29 Jan 1997 21:01:48 +0000 (GMT) From: Peter Flynn Subject: Re: Production 21 (and others) Allen on 29 Jan 1997 07:35:11 -0800 (PST)) To: w3c-sgml-wg@www10.w3.org "" [Hehe] Terry asks: I'm sure the SERB had good reasons for the new comment syntax, but it certainly isn't simple and some of us will have to explain it to skeptics. Could we have a very short statement of what was wrong with SGML comment syntax that the XML comment syntax fixes, and why the XML solution was chosen? It wasn't symmetric and I got the feeling that to sell XML to the programming community (who have to write the s/w), comments have to look like /* God intended them */ ///Peter Strong typing is for people with weak minds Date: 29 Jan 1997 21:04:11 +0000 (GMT) From: Peter Flynn Subject: Re: XML for beginners (bosak@atlantic-83.Eng.Sun.COM) To: w3c-sgml-wg@www10.w3.org | What I said, Documentation, documentation, documentation. Yes, we're all for it. Anyone want to put together an XML FAQ for starters? I suppose I asked for that :-) And I'm knee deep in writing a book, but what the hell, it'll fill in the hours between 4am and 7am... Suggestions for FAQs to me with a subject line: XML FAQ Now, what DTD shall we use for the FAQ...? ///Peter Date: 29 Jan 1997 21:22:06 +0000 (GMT) From: Peter Flynn Subject: Re: Entity and Element Addressing To: w3c-sgml-wg@www10.w3.org >What are the advantages to relaxing this restriction? And if there >are lots of others who agree with Gavin on this, speak up. - Tim 1) It allows you to use entities, even when you don't have a declaration subset or DTD. 2) It can help to reduce packet sizes in a realtime environment. 3) It can make it easier to generate content dynamically. Whoa. Pin (3) up on the board and ring it in red. Remember all the FAQs to the HTML WG and elsewhere asking why HTML didn't have an and we all said "but SGML _does_, just the browsers don't implement them". This is a Selling Point. >My conception of Well-Formedness has always been along the lines of >"you can build the right parse tree". I'm not sure about "right" yet: doesn't well-formedness mean you can build _a_ parse tree, deduced (in the absence of a DTD) from the symmetry and nesting of the markup? I'm sorry if this was thrashed to death before I came in, but it's one of those things we are going to have to be utterly unambiguous about. >Now, we have partially ducked >that by saying that you don't have to fetch & parse external text entities; >but you do have to know what the reference is pointing at. Do you mean...? "I have to be able to resolve the address implied by the entity reference even if I don't go fetch it now" or "I have to know what kind of object this purports to be, even if I don't go sniffing at the address right now" The first means more cycles at parse time; the second means authors will have to type their links. My ideas for entity resolution were posted long ago to this list. Basically, if all else fails (ie. no catalog, no declarations), then I would like to see clients looking for "foo" or "foo.xml" relative to the URL of the referring entity. A little extra robustness and flexibility. How I wish current SGML software did the same :-) ///Peter Date: Wed, 29 Jan 1997 17:35:53 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: What's a Referrer? At 11:42 AM 1/28/97, Terry Allen wrote: >What's a Referrer? > >Section 4.2 reads: > >| Many addressing mechanisms assume the existence of some sort of a base >| address whose value effects the interpretation of the address. To >| formalize this, every HREF has a location source, an object or objects >| which serves as the base address. In most cases the location source can > >"base address" needs definition. And it should be defined for each of the closed list of addressing modes that XML supports. I think we need to decide hwo things are going to work, so that we are guaranteed that and XML link in an XML linking document can at least be parsed, and its pointers resolved, by any XML linking application. If people need to extend XML-LINK they can make an extension and use a new architecture (and steal whatever they need from ours, if they want to). I think it should be crystal clear what is and is not XML-LINK, and that extensions should be clearly OUTSIDE the spec. >| be omitted and is implied to be the document element of the document >| that contains the link. However, this implied location source can also >| be specified as being the non-link element that refers to the link >| element (the referrer). > >What does that last sentence mean? I think it's supposed to refer to the previous element in the location chain (if the processor happens to implement indirect location pointers) > And if the "implied location source" >(a.k.a. "base address", which is more homey) is specified, in what >manner is it still implied? What is the reason for having both >locsrc and implied-locsrc? And it seems as though the "base address" >may vary with each occurrence of a link element. Do we need that? If we need locsrc at all, then it's worth having this. But I think we can probably do without locsrc. >This implies that every HREF value has a "base address", whether the >author intended to employ such a mechanism or not. I wouldn't be >surprised if that assumption screws up some addressing scheme, >though I don't have one in mind. Perhaps this should be qualified >such that a "base address" is implied only if HRTYPE is an >addressing scheme that uses a relative addressing mechanism. This should be cleared up by making explicit exactly what addressing schemes are supported, and how base addresses or whatever work with each. We should not have to worry about random new address scheme unless and until they are integrated into XML-LINK. >Also, the punt on the format of the string is unsatisfactory. We >won't get interoperability unless we can say what the format must be; >if this varies with HRTYPE then reference should be made to some >canonical statement of what a "base address string" is for that >HRTYPE (for HRTYPEs the use of which is anticipated) or it should >be said that the specification of HRTYPEs that use relative addressing must >include an unambiguous specification of "base address string" for >that HRTYPE. Note that HRTYPEs not mentioned in this spec will not >be implemented by all implementors. They should simply not be allowed in documents that claim to conform. Otherwise we have blown the no-options requirement out of the water by adding an infinite number of undeclared options for addressing mechanisms. I think we need 3 basic types: + URLs, as currently used. + Structural addressing, i.e. some method of navigating within an XML document that has a single URL. + A way to use SGML entities and IDs for linking (perhaps mostly for compatibility with the SGML world, perhaps because the options it offers for management via entities are usful in their own right). If people need something else, they should use something other than XML linking to meet their needs. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Wed, 29 Jan 1997 17:35:48 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: TEI xptrs as URLs? At 11:53 AM 1/28/97, Terry Allen wrote: >Gavin responds: >| >How may TEI extended pointers be expressed as URLs? >| >| We've already shown some different possible syntaxes... >| one with TEI pointers as fragment specifiers and the other >| with the pointer as part of the URL itself (David >| and I had a length debate about these recently!!). > >I think one and only one syntax should be chosen (preferrably by >the TEI folks rather than the SERB). I think I'll take a chance in speaking "for the TEI" in saying that the TEI does not try to specify such processing details. Michael can correct me if I'm wrong. > Then it should be ascertained >whether existing servers (no arguments about software that >doesn't exist, please, or at least take them to another thread >I can ignore) can deal with such URLs. Well, we have to talk about XML clients (and they don't exist), or else there is nothing to say. > If they can't, cut >TEI pointers out of the xmllink spec because they won't work. We are specifying semantics for applications, not servers (The upshot of the long discussion, I thought), so that TEI locators can work by definition. The effective algorithm for implementing them on a client is easy, even if it may be inefficient for large, prooly designed XML documents. >If they can, require TEI pointers to be expressed as URLs and cut >TEI pointers out of the xmllink spec (except for a reference >to the separate specification of how you URLulate a TEI pointer) >because it's not necessary to talk about types of URLs. If we use fragment specifiers, we can define them to do whatever we want, and it's not a new URL scheme, but part of the XML media type, if I understand the prior discussion. I think that we want to, and that we can, come up with a solution that works without placing requirements on anything other than the XML application. --- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Wed, 29 Jan 1997 17:24:31 -0500 From: gtn@ebt.com (Gavin Nicol) To: digitome@iol.ie CC: w3c-sgml-wg@www10.w3.org Subject: Re: Production 21 (and others) >This raises the question - what are the constraints on XML aware applications >when it comes to parsing->processing->writing XML. Is there something along >the lines of a (much simplified) DSSSL Null Transformation??? > >A related question, in SGML two docs are considered equal if they produce >the same ESIS stream. Will there be a similar concept in XML? Kinda >useful in checking that an XML application interprets the document >structure as intended... I have been arguing for some time now for the ability to validate an XML *parser*... this is needed very badly, or how can I trust my document to your database. Then again, this get's back to whitespace handling... Date: Wed, 29 Jan 1997 17:35:31 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Initial draft of XML-Link spec now available At 7:31 PM 1/27/97, Eve L. Maler wrote (lots of good things): >1.4 Terminology > I agree with Lee that the terminology is getting in the way. Definitely. > o The discussion of ALINKS in section 3.3 (how can an ALINK have only a > single link-end? shouldn't it have two?) I think so. This is a question of whether we want to interpret existing one-way links as having an "implicit" other way. I think that we should, as we then have a nice model, and we really remove all essential differences between link types Inline links become an obvious consequence of allowing a link to treat itselfs as an implicit referent. This might be profitably extended to multi-way links as well, which might be good for some kinds of multi-way comment, where the link could be sensibly embedded in one of the docments at a point of reference. > I agree with Lee about bi-directional versus multi-directional. so do I. Bi-directional seems confusing when applied to a link that is the hypertextual equivalent of the Place de la Concorde. > I really like the terms "in-line links" and "out-of-line links." In >fact, the salient feature of a link seems to be its linearity :-) and not >its directionality, so I wonder if it's better to have something like >ILLINK and OLLINK rather than ALINK and MLINK. I think you may be right, that these terms (in-line and out-of-line) are more self-explanatory than any others we have had. I don't like the element names you suggest, because they're too acronymic, and too similar. Maybe we should collapse the two elements, and simply have an attribute that can express that one linkend is the link element itself. >1.5 Types of Links > I don't see the difference between link formatting and link behavior. >For example, where is the link explainer "shown"? If it's balloon help, >that's definitely behavior, isn't it? Well, this brings us the long discussion just finished between Len and me. I think these are not only exactly the same thing, as you observe, but that separating them is actively harmful. We should offer link-behavior and link rendering as things that can be _based on_ link type, and pointer role (To use the terms I proposed in another message -- did they make sense?). There's no need to wire in non-generic markup unless we're going to acutally list behaviors. I may think that having any behavior marking in XML-link is a terrible idea, but if we do offer the option, it is meaningless unless we say _what_ behaviors can be specified, and _how_. Putting in hooks to user defined type strings has real value, as our document design experiences have shown us, but putting in hooks to an undefined scripting language is not useful at all. >2. Link Recognition > > First of all, *one* prefix needs to be chosen for all these >"architectural" purposes. Is it XML-, or XHL-, or -XML-, or -XHL-? Yes. I hope we will have the separate attribute lists to work with, so we can do this right. I think we should avoid hardwired element names, with or without the hyphens, and we can do that one of two ways.... Attributes are one way >The >leading hyphen now feels bizarre when it comes to element GIs, and suddenly >I feel a lot more willing to invade the user's namespace... Please, don't touch my namespace! > Can we officially consider PI "architectural form" summaries? One of our >XML design principles was to offer only one way to do things where >possible. I suspect that this won't fly for link recognition and other >types of "recognition." (In other words, this will obviously come up in >phase 3 too.) Are we willing to consider offering even more methods? If we can do attributes in the Doctype declaration, we can offer that one way... otherwise, I think we should offer the PI method as the one way to indicate these linking architectures. If we have to offer element names as a shortcut for the HTML crowd (and vile thought it is, I think the argument has much force), then we should stop at offering _two_ ways: PI/attributs and element name. Applications will remain free, as they always are with generic markup, to define other link architectures, so I don't see that XML link needs to be as flexible or extensible as, say, HyTime is. >2.3 Link Recognition by Other Means > > The spec should note that such links are not highly interoperable among >XML-aware applications. Since this is always an option for XML, we should just delete all references to other means. Let's define what XML link is, and leave what it might also be out. This helps simplify things too. >3.1 Information Associated with Links > > I'm getting confused here. There's info associated with whole links and >info associated with link ends. In the case of ALINK, they're all smooshed >together. Can the separation be made more clear, and (I can't believe I'm >asking this) can the formal specs be shown as architectural forms? I think this may be a good idea... > The "principle" of link info being in attributes is the first seriously >unclear text in the spec. "Markup" -> "attribute values" and "character >data" -> "element content", I think. Also, if this really is a principle, >it should be listed in a section at the top. > > Some other principles demonstrated by the spec: > > o Making the simple cases easy to mark up > o Enabling sophisticated link databases > o Requiring a "floor" of processing but not precluding new location > addressing, link typologies, etc. Great suggestions. There should be a little bulleted list of principles like this, up at the top of the definitions. > The "musts" and "mays" of attributes should be further clarified; this >should be normative. At the same time, we may want (in principle!) to >avoid #REQUIRED attributes, e.g. for TYPE and ROLE, and (who knows?) maybe >even for HREF. This seems a bad principle to me, I found myself occasionally wondering why more things were not required. > Can people make their own "master" types and roles? Or are they >constrained to making subtypes of the pre-defined starter sets we supply? >In talking with Terry, I've come to agree that we shouldn't prescribe *any* >minimum/starter set of types/roles. I agree after seeing the total dissimilarity of vocabulary and style of the lists that people have suggested here (I can remember at least Len's, Eliot's and mine). > This is an area for value to be added. The only thing we might do, is add some rules for implied values (like for instance numbers for pointer roles that are not specified in the document). This would mean that stylesheet authors would nto have to worry about missing values, as there would alway be _some_ values in question. If the implied values were well defined, it could even ease processing specifications by people who don't believe in roles and types -- they would just write stylesheets that used the (purely formal) default values. So behavior-only stylesheets would actually become fractionally esier. > Terry pointed out that in DocBook, we allow for subject-classifications of >content along the lines of "schemes" (such as the Library of Congress >Subject Headers), and suggested we use the same approach for link types. > >If this group really wants to suggest some possible link types, we should >(a) dictate a method for associating a link type with a scheme, (b) make >our list of types informative rather than normative, and (c) label our list >with a reserved scheme name. If we suggest link-types this kind of two-level mechanism is a very good idea. I now incline against predefining a set, though. >4. Addressing > > Is "documents, nodes, and regions" a complete list? > > For the special case of anchors that are themselves link elements, how >about having an attribute (or a BEHAVIOR attribute value) on the "calling" >link-end that indicates that the buck should stop at the next anchor? >Doesn't TEI have something for this? This is a place where the current spec falls on its face. The indirection behavior of HyTime is complex but can be useful. The single-level behavior of HTML and TEI is easy to understand, but can cause management problems that XML can only solve by the ugly use of entity values. But we need to decide either to live with indirection, or to live without it. This section 4 intorduction offers the worst kind of option -- An author can't assume that indirection is available, and an application has no way to tell if apparent indirection is intended or not (since it can't know what the author intended). I made an argument for a single level of pointer indirection, which is more than powerful enough, but no indirection at all is better than not knowing whether it is there or is not there. >4.5 TEI Locator Reference Types > > For non-query xenoforms, is the TEI locator reference type supposed to be >used with FOREIGN? This hardly seems fair to the inventors of other >location addressing methods. Is a section 4.7 needed for "Other" locator >reference types? Like Terry, I dislike the interaction between attribute values here, but I don't see a way around it, so far. I think that the HRTYPE attribute should be a fixed list of values. If people want to extend the list for a special purpose they will, but we should be unambiguous about what XML-LINK includes. I think, actually that we can live with The SGML type of reference, and URLs plus TEI locator fragment specifiers, as we discussed on the list. We might even be able to use purely syntactic means (like parenthesizing SGML references to distinguish them from URLs. If we changed the syntax of TEI locations to use a / as separator, rather than a space, we could avoid the escaping problem. e.g.: "http://foo.com/bar/bletch.xml#(ROOT/DESCENDANT(2/DIV1)/DESCENDANT(3/DIV2)" A little gross, but not too bad. > > What are the reasons for chucking regular expressions and links to spans? > Just for making the spec a manageable size? Links to spans is a real loss. There goes the ability to reference CD-based resources. It is also funny, because in the discussion of anchor types, the "regions" is explicitly mentioned, but we don't actually support it, for the obvious kind of textual region. I'm afraid that we also need some simple method for linking to two-dimensional (or n-dimensional) areas. In-line imagemaps are already an instance of a limited ilink (MLINK), and we should bear in mind that they were the first such link implemented on the web! This has a lot to do with the fact that we don't have any accepted technology to tag images. >5.1 Identifying Extended Link Groups > > Here's where I really start showing my considerable confusion about links >and BOSes and whatnot. Seems to me that you are actually whowing your understanding, as you seem essentially right to me... > If I have a document full of MLINKs for whatever purpose, and in the >course of its linking it points to a particular "content" document, why do >I want to have something in that "content" document that identifies where >the MLINK is stored? You don't. > This (a) makes a nasty interdependency, Yes, and threatens to muck with your markup, too, with its LINKS element. >(b) doesn't >cleanly allow the "content" document to conditionally point to different >"linking" documents, We may not be able to mandate this anyway, as I think people don't want to get into the situation where you browse to a starting document that changes your active linksets, and bounces you along to your starting place. We need some document somewhere that asserts the binding of a document to a linkset. >(c), if I'm not mistaken, can't be done in the >case of read-only "content" documents, which are the juiciest application >of using MLINKs in the first place. Actually, you can do it, but you have to start at some ancillary document, and then navigate to the read-only resource. (and this navigation might be an automatic part of the rendering of some links in the document). > In a sense, the "extended link group" information in a document is a >*contextual* link that binds the document to the interlinked set. Why not >make it an *independent* link by storing an "interlinked document set >manifest" in an MLINK itself, perhaps in a document of a special >XML-MANIFEST document type? (Terry has suggested that perhaps MIME could >be used instead; that's even further out of my depth.) I'm not sure that this buys us enough to be worth the complexity. This is essentially what I was trying to describe above. >5.2 LINKS and LINKSET Elements > > More confusion: > > I don't see how restricting the contexts where MLINKS can be found will >simplify anything, if they're sufficiently identified as MLINKS already. Nope, but it does pointless reduce the author's ability to put markup where wshe wants. >Also, if you only allow one LINKS element, it's hard to manage >"recombinant" document objects (e.g., as entities) that travel with their >own LINKS elements. And it's an _element_. I don't want people mucking with my DTD! > I'm also confused about the nature of LINKSET documents. A collection of >out-of-line links is one thing, but if you want to present it to the user >(as a guided tour or whatever), either it's going to be extracted from a >"link database" by some link-aware tool externally to the XML goings-on, >*or* it's going to be embedded in a guided-tour *document* that the user >will begin with as Step One. That's what I want to do! > Right? If this is true, then *any* document >should be allowed to contain collections of out-of-line links, along with >titles, instructions, and whatever other hoo-ha you want. Yes, you've made the argument beautifully... > If you had a >manifest stored externally to both this guided-tour document and the "tour >fodder," and the guided-tour links had an approprate type mapped to >appropriate behavior, then is there even a need for special LINKSET documents? Nope. If you want linkset documents you can make them, but I don't see how having them preprogrammed in helps much at all... And it we are going to specify XLGs we are going to have to explain what happens if other documents in a group specify XLGs. so Why not just have recusive traversal? This is the same argument we've already had, but I've still seen no technical explanation of why it's any harder to implement or control than external entity references. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Wed, 29 Jan 1997 17:35:43 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Entity and Element Addressing At 12:23 PM 1/28/97, Terry Allen wrote: >I note from XML 1.0, s.v. 2.2, that in a well formed XML document, >for each entity reference, the entity name must be declared in >the doctype declaration (at that point, reference might be made >to 2.9, in which the concept of internal and external subsets >is introduced). S.v. 4.2.2, the system identifier >must be a URL (should the sentence following the Validity >Check following production 71 start "The SystemLiteral"?). It might >be worth while pointing out that in xmllink, addressing by entity >means addressing by URL using entities for indirection. Is >ENTITIES allowed? It doesn't say so, so I assume not. Nor does ENTITIES seem that it would be useful in this case. >| If the reference type is ELEMENT, >| then the HREF must be the value of a unique identifier attribute within > >"Unique identifier attribute" isn't language I can find in XML 1.0. >Is "ID value" intended? What of ELEMENTS, in the plural? (In other >words, is this really IDREF/IDREFS?) I think so, but the language should be changed. We have also considered allowing references based on any attribute value -- this would be nice, but would need to be defined first. >What happens when the system identifier for the entity already >contains a #? What is the force of "leading" in "leading entity name"? I don't think that this matters, actually. If the system identifier identifies an XML document, then it presumably can't contain a '#', or it contains a # with some fancy XML-linking query semantics, so that the IDREF is applied relative to the result of following the pointer. Leading entity name seems to mean that the entity name is first in a string like: "Foo#id" With the entity declaration Did I get the example right? -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Wed, 29 Jan 1997 17:35:56 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: XML linking (my draft comments) I'm putting typos and a few textual corrections at the bottom, in case the editors care. Before I start being grumpy let me say that this is a great start! 1.5 Link formatting and link behaviors considered harmful. We may need to tell people that they can use link types, and pinter roles to determine processing (for rendering or user-interaction), but we do not need a separate way to do this. If we split these out, then for the spec to be effective, we need to describe exactly what behaviors can be specified (or maybe require a Java interpreter, and then specify an applet<->XML-processor exection interface). We also need to describe how to resolve conflicts among the 3 things. For instance, if the style sheet specifies a behaviour that conflicts with the behavior attribute, who wins? Or what are the ground rules under which they duke it out. If those behaviors change the formatting of the data, does the link-formatting spec win, the link behaviour code win, or the link behavior code chosen based on the linktype win? And are all these options so valuable that we need to waste any time thinking about the questions above. State that the type can be used to choose behaviors. Let people use the names of java applets as link types if they want to, but we don't need to get into the additional hell of trying to specify behaviors and rules for adjudicating among multiple hebavioral specs. 2.1 The attribute should be -XML-XHL or maybe -XHL-FORM for consistency with our reserved name strategy. Even -XHL- is more consistent, although the ugliest kitten of this rather unattactive litter. 2.2 Link recognition by element type is something that I pretty much hate. But I think we may need it, and I agree that -XML- is the syntax we agreed to use, but it kind of loses the point of making things easy on people, if we make them use a name that is so fundamentally hideous. I think requiring PIs to declare elements for linking is better. 2.3 This should be deleted. XML linking shoudl define a particular semantics. If it's not enough, you can use XML and your ingenuity to devise something better. I should be able to author a document and know that there's a test that will ensure that it _should_ work with other XML link processors, and that when it doesn't it is due to a bug, and not a "customization option". 3. ALINK bodies should be an implied endpoint of their links. If we make a generalized option for allowing _any_ 1 pointer of a link to be an implicit refrence to the link element itself, we're back down to one kind of link, and we get more useful MLINKS, too. If we can't make this easy to understand, though, we should forgo the elegant generality though, and make ALINKS into a special case. 3.1 The set of link-types should be non-mandatory, if we don't just gove up on it. I think we may end up givin up on it, just because deciding what they should be will be so taxing. Same for link-end roles (pointer roles, as I suggest we call them). BEHAVIOR and RENDER should be deleted. I've already argued this in other posts. If we keep them we need to define the difference between them, and give a list of the rendering and bahaviors that XML linking supports. An undefined, open list of behaviors in an undefined notation is not nearly as useful as such an undefined, open list of types. 3.2 Why are linkends sub-elements? I had just gotten used to Eliot's multiple attribute proposal, and it's much more compact, and doesn't require any mucking with the content model of the link element. The only thing I'd like to see inside of the link would be the explainers, as I can easily imagine that the user would want to use markup in explainers. If you can't use markup in epxlainers, I'm actually not sure how useful they are. A further advantage of having each linkend be an attribute, is that it looks like HTML. Someone also pointed out the lack of REV and REL attributes. At least one of these could be fused with the ANCHROLES attribute (maybe even renamed to REL?) that lists the attributes that point to the link referents. So we'd have REL="foorole barrole" and then, designating those elements. For example: In the special case of the A tag, we'd get: The above is in pidgin HyTime, but I just don't see what separate elements really buys us, especially if we do the _right thing_ and define a way to embed the 3 kinds of link we need into a single attribute value. I suggest: + type 1 (normal URLs): ptr="http://foo.bar.com/" ptr="http://foo.bar.com/#internal" + type 2 (SGML URLs): ptr="(ENTITY)" ptr="(entity#idref)" + type 3 (TEI URLs): ptr="http://foo.bar.edu/#(ROOT/DESCENDANT(1/DIV1)" an option to allow for future expansion womight be: ptr="http://foo.bar.edu/#(tei:ROOT/DESCENDANT(1/DIV1)" now the need to hang all those attributes off a linkend element is gone: ROLE moves into the renamed anchroles attribute. HREF moves into the link itself with a different syntax for each kind of reference. HRTYPE moves into the syntax for the references itself. BEHAVIOR and RENDER are gone for other reasons. TITLE is not explained in the spec, but appears to be the explainer -- it should move into an element, or be left for style/behavior designers to implement. Section 4.2 should be firmed up based on the final list of addressing schemes chosen. The process of stating concrete requirements on conrete addressing formats should also clarify this section. 4.3, 4.4, 4.5 These are the right list of addressing modes. I think we should close the list. If we're wrong, users can extend, and we can make XML-link 2.0, but these modes already provide a staggering amount of power, so we may not have to rush. 4.5 point 2. Why eliminate links to spans? I want to be able to link even to brain-damaged text files! It's not hard to implement, and it makes linking so much better. all other numbered points seem acceptable, though the loss of regexp is a shame. exntedable addressing schemes should not be a goal of XML linking at this time. 4. Last paragraph. Bad idea. We should rule indirection along pointer chains, in or out. I say we eliminate it, or strictly restrict it to one step of indirection. 5.1 This whole section needs rework. I don't see any benefit (other than ruling out the use of mlinks for parallel texts (which I would like) and for graphic callouts (which would be very popular). The extended link groups are underspecified. What happens if the documents I include have extended link groups in them? They should be recursive as well, so that we can meet the document management needs that Martin brought up. The current solution does not allow very much flexibility. The proposal of a specific element that the user mus include in their DTD is the most egregious case of namespace stomping that I've seen proposed. What happens if I have a LINKS element that does not meet this spec? Is it a reportable error (which means legitimate DTDs will become illegal), or a silently ignored one (which means that people using it will get hard-to-detect erroneous behavior)? What is the justiofication for restricting MLINKS in this way? Why is it so hard to detect them in the text? Appendix A. (did not really read. Remove stuff that will not be part of XML linking). ====== BEGIN LITTLE STUFF 1. Change the sentence Not all relationships are links: the relationship of a chapter.. ..next, or any non-explicit relationship[s], are not considered links here. to: Not all relationships are links: any non-explicit relationships, such as the relationship of a chapter.. ..next, are not considered links here. 1.1 XHA->XHL (or whatever) sect 4.2 para 1. change "effects" to "affects" I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Wed, 29 Jan 1997 17:35:27 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Anchor terminology At 11:30 AM 1/28/97, Joe English wrote: >I find it puzzling that the XHL draft has replaced >the HyTime terminology "contextual link" and "independent >link" -- about which to my knowledge nobody has complained -- >in favor of the _de novo_ "inline link" and "out-of-line link", >yet it retains the terms "anchor" and "link end", >which nobody seems to like. I don't have a problem with the terms in-line and out-of-line, per se, as these terms are pretty self-explanatory, but I agree that we retained the least attractive of the terms we have floated. I think we should avoid using the term anchor at all, as it has several technically distinct meanings in different communities. This is true to some extent of "link" as well, but people seem not confused by this, probably because it's _so_ common the people expect each system to have its own definition. That's the most important thing. My personal vote goes to this syncretic list from other people's suggestions: link: bag of pointy bits. pointer: a pointy bit with a suit on (so it looks more formal) referent: Something you get to via a pointy bit link type: What kind of a link you have (in semantic or operational terms) pointer role: What role does this particular pointer play in this link -- the label on an item in the bag. pointer type: The kind of addressing used by pointer to point at something else. Alternatively described: the notation used to write down the address a pointer uses to point at things. As for link topologies, I could happily got back to clink and ilink, and no-one here ever objected to those terms, but for the uninitiated, the current terms may be more descriptive. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Wed, 29 Jan 1997 17:35:20 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Entity Ignorance At 10:32 AM 1/29/97, Terry Allen wrote: >And so did Tim Bray: >>Sorry, Terry. This was one of the single most debated points in the >>whole XML process; the ERB reversed itself no less than twice, under >>heavy (and justified) WG pressure. Hit the archive and relive the joy >>of debate. I think this one is (a) not going to change and (b) the >>correct decision. - Tim > >Then I'll just point out that 4.3.8 allows the entity to be >ignored even when it has been served to the client, e.g., >when it's bundled with the main document. Few sane publishers >will find entities attractive in XML. I was one of the proponents of the current decision, and I still think it's correct, but Terry has a very valid point, that can perhaps be addressed without changing the basic decision significantly. Can we change the language to read something like the following: "If the entity is an external text entity, and the processor is not attempting to validate the XML document, the processor may, but need not include the entity's content. [This is what we say currently, but we can add a new requirement: ]. If the application, either cannot retrieve the entity, or chooses not to do so, the application must indicate to the user that data is missing, and (if possible) offer the oppotunity to fetch the missing data." I think the following explanation of why you'd rather not be _forced_ to fetch everything, should be able to stand as-is. -- David (not arguing applications and authors rights) I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Wed, 29 Jan 1997 15:59:54 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@www10.w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: Anchor terminology | My personal vote goes to this syncretic list from other people's | suggestions: | | link: bag of pointy bits. | pointer: a pointy bit with a suit on (so it looks more formal) | referent: Something you get to via a pointy bit Even though "referents" sounds exactly like "reference"? Jon From: David Durand Date: Wed, 29 Jan 1997 19:44:22 -0500 (EST) To: w3c-sgml-wg@www10.w3.org Subject: Re: Anchor terminology From: bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) (Quoting me): | My personal vote goes to this syncretic list from other people's | suggestions: | | link: bag of pointy bits. | pointer: a pointy bit with a suit on (so it looks more formal) | referent: Something you get to via a pointy bit Even though "referents" sounds exactly like "reference"? Jon a very good point. I was thinking that pointer referent is clear, but the plural is confusing. Maybe target is better after all. Link-end works for me, but I don't think of ropes, since links are now part of my primary ontology. Just so long as it's not anchor! -- David Date: 30 Jan 1997 00:47:48 +0000 (GMT) From: Peter Flynn Subject: XML FAQ To: w3c-sgml-wg@www10.w3.org OK, thanks to some swift responses by Eve, Jon, Peter M-R, and Tom Borgman, there's a skeleton at http://www.ucc.ie/xml/ but please keep the URL within this group until the doc is a bit fleshier. Most of the answers are placeholders and need rephrasing. I'll update every 2 days or so on the basis of what I receive and what I stumble across in discussion. I would aim to release the URL with DRAFT stamped on it within a couple of weeks, then see what the respnse is. ///Peter Date: Wed, 29 Jan 1997 18:54:08 -0600 From: len bullard To: David Durand CC: w3c-sgml-wg@www10.w3.org Subject: Re: Anchor terminology David Durand wrote: > Even though "referents" sounds exactly like "reference"? > > Jon > a very good point. I was thinking that pointer referent is clear, but > the plural is confusing. Maybe target is better after all. Link-end > works for me, but I don't think of ropes, since links are now part of > my primary ontology. > > Just so long as it's not anchor! Target. len From: lee@sq.com Date: Wed, 29 Jan 97 22:13:49 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: Entity Ignorance Terry wrote: > Then I'll just point out that 4.3.8 allows the entity to be > ignored even when it has been served to the client, e.g., > when it's bundled with the main document. Few sane publishers > will find entities attractive in XML. I think it's not as bad as you fear. Few successful clients will be insane. HTML makes display of the entire _document_ optional... :-) The idea behind the decision was to allow lazy evaluation -- e.g. a browser could show an "entity" box until you double click on it. But this was done before we discussed hyperlinks at all. If you have links that support optional transclusion, you don't need this feature. David suggests: > "If the entity is an external text entity, and the processor is not > attempting to validate the XML document, the processor may, but need not > include the entity's content. [This is what we say currently, but we can > add a new requirement: ]. If the application, either cannot retrieve the > entity, or chooses not to do so, the application must indicate to the user > that data is missing, and (if possible) offer the oppotunity to fetch the > missing data." I think this is fine. Note that for an undefined entitiy (the original example) you don't actually know whether it's external or not. This wording hence can only (I think) apply to defined but unreachable entities where a DTD was given. Lee From: lee@sq.com Date: Wed, 29 Jan 97 22:23:56 EST To: cbullard@hiwaay.net, dgd@cs.bu.edu Subject: Re: Anchor terminology Cc: w3c-sgml-wg@www10.w3.org For a reference/referent/target/comefrom/landing zone, I still prefer "active region" or a "zone". A link end can be a target, but it can also be where the archer places his feet, both the golf tee and the hole, sometimes both at once. For an annotation, for example, it's not really a target, but just a region of interest. Lee From: lee@sq.com Date: Wed, 29 Jan 97 22:33:36 EST To: w3c-sgml-wg@www10.w3.org Subject: Re: Production 21 (and others) Quoth Gavin: > "" But I think there is a flaw, as this will not match as it's interpreted as folows: > "" A B C D E F AAAAADDDBBB This isn't actually a good thing to try to do with a regular expression. For what it's worth, I tested this with perl (OK, so I'm dirty, but I'm barefooted too, so that's OK): perl -n -e 'if (//) { print; }' Lee From: lee@sq.com Date: Wed, 29 Jan 97 22:37:36 EST To: crm@ebt.com, w3c-sgml-wg@www10.w3.org Subject: Re: Production 21 (and others) Dhris Maden wrote: > The regexp should bar *-- within a comment (and -- unless the TC > passes in time). Even though, from XML's point of view, only *--> can > end a comment, these are still SGML comments, and *-- as comc would > still end the comment within the comment declaration. No. Using *-- as COMC would require SGML comments to look like Existing SGML systems will use -- to delimit comments, and it is pure happenstance (to them) that all XML comments start and end with an asterisk. In fact, banning -- within comments until the TC passes is sufficient, since *-- contains --. After the TC passes (I hope!), it is only necessary to state that comments don't nest, so tht --* cannot appear within a comment, since an SGML system can then handle the new syntax. Lee Date: Wed, 29 Jan 1997 22:12:28 -0600 From: len bullard To: lee@sq.com CC: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org Subject: Re: Anchor terminology lee@sq.com wrote: > > For a reference/referent/target/comefrom/landing zone, > I still prefer "active region" or a "zone". > > A link end can be a target, but it can also be where the > archer places his feet, both the golf tee and the hole, sometimes > both at once. > > For an annotation, for example, it's not really a target, > but just a region of interest. > > Lee Whatever. I'll check in from time to time to see how the baby is named. I really suggest we stick with something they understand already. I was cheerful with ilink and clink since we've been tossing these around for quite a while now. Ok, let's obsolete all the books so we can all write new ones. I'm sure Steve and David are happy to do YetAnotherUpdate to Making Hypermedia Work. :-) len Date: Wed, 29 Jan 1997 22:55:17 -0800 To: w3c-sgml-wg@www10.w3.org From: Tim Bray Subject: Redirect Pardon what may be an abuse of the group, but a substantial proportion of the people with whom I do non-email business are on this list, so: I've moved. New phone number: 604-708-9592 New FAX number (I *hate* FAXes): 604-871-0039 New address: 3495 Cambie Street, Vancouver, BC, Canada V5Z 4R3 Cheers, Tim Date: Thu, 30 Jan 1997 08:56:51 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Production 21 (and others) At 08:31 PM 1/29/97 +0000, Digitome Ltd. wrote: >A related question, in SGML two docs are considered equal if they produce >the same ESIS stream. Unless I'm very much mistaken, nothing in any of the system of standards making up SGML defines a formal or fixed definition of equality of documents. It is up to data owners to define their equality requirements. If ESIS is good enough, fine. Others only consider two documents to be the same if they are byte-for-byte identical. With property sets and groves it is possible to formally define your equality requirements by defining a grove plan that defines the subset of properties you care about. If you use the entire SGML property set, parse two documents into groves, then compare those two groves; the two groves will be equal IFF both documents are byte-for-byte identical (because the full SGML property set includes all the original data strings from the parsed document--the so-called "markup properties"). If, on the other hand, you use a grove plan that omits all the markup properties, then you get more or less "ESIS"-level equality. The key is you can choose. By the same token, programs that modify SGML documents can define what they do and don't preserve by publishing the grove plan that omits those properties they don't preserve (for example, most SGML editors don't preserve the markup properties for elements). [If they were really cool, tools would also support the definition of the grove plan you want it to use, letting you choose how you want to balance data preservation with performance--if I want every byte preserved, I should have that option, with the understanding that performance may suffer--this would allow, for example, SGML database tuning without requiring the database vendor to make unalterable optimization choices.] The HyTime TC also defines a string representation of groves (the "canonical grove representation (CGR) document type") intended to enable string comparisons of groves: parse two documents into groves, generate the CGR documents from each, run DIFF on those documents, see where they differ. XML can formally define its normative equality requirements by defining a grove plan against the SGML property set with which XML documents should be compared (for example, it could exclude the DOCTYPE property to allow the comparison of well-formed and valid documents for equality). Cheers, E. Date: Thu, 30 Jan 1997 10:09:26 -0500 To: w3c-sgml-wg@www10.w3.org From: davep@acm.org (Dave Peterson) Subject: Re: Production 21 (and others) At 10:37 PM 1/29/97, lee@sq.com wrote: >Dhris Maden wrote: >> The regexp should bar *-- within a comment (and -- unless the TC >> passes in time). Even though, from XML's point of view, only *--> can >> end a comment, these are still SGML comments, and *-- as comc would >> still end the comment within the comment declaration. > >No. Using *-- as COMC would require SGML comments to look like > Someone's getting confused here. Until/unless the TC is adopted, there is no such thing as COMC. Using "*--" as COM would require.... If the TC is adopted then there would be no COM, just COMO and COMC. And XML would use "--*" as COMO and "*--" as COMC. The reference concrete syntax (which only *must* be used in the SGML declaration) would use "--" as both COMO and COMC. SGML documents using the XML SGML declaration would use comments that look like except in the SGML declaration itself. >Existing SGML systems will use -- to delimit comments, and it is pure >happenstance (to them) that all XML comments start and end with an asterisk. Only for documents whose SGML declaration specifies "--" for both COMO and COMC. Any robust SGML system should be able to switch concrete syntaxes as specified in the SGML declaration, and any document whose SGML declaration specifies "--*" for COMO and "*--" will not use "--" to delimit comments. "Existing systems", presumably those that have not been updated to conform to the TC, will not be able to read an SGML document (which includes its SGML declaration) that is an XML document (which must use the XML SGML declaration). So to get an XML document into an "existing system", one will have to change the SGML declaration to something that the existing system can accept--but then it's no longer an XML SGML document, just an "almost-XML" SGML document. I'm not aware that anyone is expecting that, provided the TC is out in a timely manner, one will expect XML documents to *always* go cleanly into a system that doesn't implement the TC. Otherwise, why bother with the TC? You'd be requiring all the odious restrictions and workarounds that the TC is trying to eliminate. Dave Peterson SGMLWorks! davep@acm.org Date: Thu, 30 Jan 1997 10:36:23 -0600 From: Len Bullard To: w3c-sgml-wg@www10.w3.org Subject: Sample Question Will the following example be koscher XML? Hello World . .

Your IP address is write(request.ip) write("

Last time your were " + client.oldname + ".") Len Bullard Lockheed Martin From: "Christopher R. Maden" Date: Thu, 30 Jan 1997 17:18:19 GMT To: w3c-sgml-wg@www10.w3.org Subject: Re: Sample Question [Len Bullard] > Will the following example be koscher XML? No - it's not well-formed. > > > Hello World > . > . >

Your IP address is write(request.ip) > write("

Last time your were " + client.oldname + ".") Assuming and were closed properly, there is a

opened within that was not closed. I think that what is desired is: ...")]]> -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) From: David Durand Date: Thu, 30 Jan 1997 12:23:53 -0500 (EST) To: w3c-sgml-wg@www10.w3.org Subject: Re: Sample Question From: Len Bullard Will the following example be koscher XML? Hello World . .

Your IP address is write(request.ip) write("

Last time your were " + client.oldname + ".") It meets the syntax of XML, so naturally it will be. I sincerely hope that this group will not create a standard way to include exectuable code in the body of documents, since I think that is a DTD and application program issue, not a prerequisite for good markup and powerful linking functionality. And it _should_ be legitimate XML, too. Wouldn't we rather that Netscape had made a JavaScript tag and been able to supply a contional stylesheet to hide the script from people who can't or don't want to run javaScript? I think that kind of solution beats "parsed comments" blindfolded, in a straightjacket, without breaking a sweat. And with a different stylesheet, it's a code example suitable for putting in a table, and not a program suitable for execution! -- David Date: Thu, 30 Jan 97 10:23:46 CST From: Michael Sperberg-McQueen Subject: Re: Production 21 (and others) To: W3C SGML Working Group On Wed, 29 Jan 1997 22:34:33 -0500 Liam Quin said: >Quoth Gavin: >> "" > >But I think there is a flaw, as this will not match > > ... As Tim Bray said a few days ago in private mail, Oooooooh! My brain hurts... make it stop. Lee Quin's note made me look more carefully at the revised regular expression that Gavin Nicol and I had both independently come up with, and it too has problems. After a few more minutes (an hour, actually, all told) of struggle, I now have the following two regular expressions. Those with the Itch, please check these out! If it's so easy to get this wrong, we need as many checkers as possible. 1 an expression for XML as of now, forbidding '--' within comments [21] Comment := "" 2 an expression for the XML rule of the future, forbidding *-- but not -- within comments: [21] Comment-of-the-future := "" Since I'm not sure what the EBCDIC/ASCII translation is going to do to these, here's another version; I hope the circumflex is right in at least one of them: [21] Comment := "" [21] Comment-of-the-future := "" In case it's helpful, here is my derivation for the second rule, following the same logic as my derivation of the first rule, posted a day or so ago. First, define Misc as any string of characters ending in something other than a hyphen or a star, and containing no '*--': Misc [µ*]|(("*""-"?)+[µ-*]) And Star as any string of hyphens and stars ending in a star and containing no '*--' Star ("*"|"-*")+ Then a comment is a sequence of: - the start delimiter '' or [21] Comment := "" Expanding out, we get [21] Comment := "" Test cases: all these comments are legal in both rules. These are illegal under both rules: *--> -C. M. Sperberg-McQueen Date: Thu, 30 Jan 1997 16:51:26 GMT From: Peter@ursus.demon.co.uk (Peter Murray-Rust) To: w3c-sgml-wg@www10.w3.org Subject: Re: Entity and Element Addressing Lines: 110 I hope this isn't going over solved ground, but I'd like to check up about entities and the interpretation of 4.3. The spec uses the word 'include' which I take to mean 'copy the entire contents of the external entity' (normally a file) 'into the space vacated after removing the &...; string'. The spec emphasises the use of modularity in authoring (which I strongly support). Therefore a simple example would be: ]> &bib1; &bib2; &mol1; &mol2; Assume that the files have structures like: ... and ... and are 'valid', then the whole document is a valid CML document. The subsidiary files are not valid CML (they have no DOCTYPE) but they are WF and in all other respects valid. They are therefore valuable reusable components (but see below). This seems to be the intention of the draft. However it is also possible to create a valid document as (say) ... ]> &molfrag1; where molfrag1.txt contains something like: i.e. the starttag is in one file and the endtag in another. Whilst this is horrible, it is the sort of thing that a mindless text processor might do when sending chunks to a mailer with size restrictions. It would also be possible to have both the start and the endtags in the main document. I am not an expert on NOTATION but is seems that this is required if including a foreign file, e.g.

&mygif;
It therefore becomes difficult to say whether a document is or is not WF without looking at the entities. My motivation is that such document fragments may be useful both as entities and as link-ends - 'the things the pointy bits point to' (if I have that correct). In other words I might also wish to write something like: <-XML-LINK HREF="mol1.cml"> <-XML-LINK HREF="mol2.cml"> to reference the molecules. However the semantics are differnt. The second assumes that the application will find something with a well defined structure of _some_ sort in the files. I'm still not clear how it knows precisely what that structure _is_. If mol1.xml is a complete valid CML file (i.e. has a DOCTYPE statement and an accessible DTD) then I know, otherwise I have to guess. I _hate_ using file suffixes, and my preference would be to include a MIME type somewhere in the LINK. The nearest I can get is the HRTYPE attribute - but this isn't clear in the spec. If it's allowed, I'd suggest: <-XML-LINK HREF="mol1.cml" HRTYPE="application/x-cml"> However, if this is allowed then the use of entities fails (since the files all must have DOCTYPEs in them). So I really want to be able to omit the DOCTYPEs and use HRTYPE (or some other tool) to tell the application 'what is at the end of the pointy bit is a WF CML file and its nature is determined by its first element. Just assume there is a DOCTYPE at the front' Of course I have to make sure that the context into which the file is imported is sensible, but that's my problem! P. [BTW I am not a supporter of punctuation in NAMEs if it can be avoided. For example, I create Java classes for most of my Elements directly >from their names. -XML-LINK.java is illegal, and probably has to be contracted to XMLLINK.java. The (obvious?) underscore character doesn't seem to be used in XML names (?)] Peter Murray-Rust, (domestic net connection) Virtual School of Molecular Sciences, Nottingham University, UK http://www.ccc.nottingham.ac.uk/~pazpmr/ Date: Thu, 30 Jan 1997 11:44:27 -0600 From: Len Bullard To: David Durand CC: w3c-sgml-wg@www10.w3.org Subject: Re: Sample Question David Durand wrote: > > From: Len Bullard > > Will the following example be koscher XML? > > > > Hello World > . > . >

Your IP address is write(request.ip) > write("

Last time your were " + client.oldname + ".") > > It meets the syntax of XML, so naturally it will be. No quarrel with the reply, yet this will be the sort of example that will raise hell at the XML conference. It is existing practice supported with some expensive code and product marketing. We need to ferret out these jewels. Otherwise, the comment "anything you can do with XML can be done better with server side HTML" will be heard often. It might be pointed out that where data is *lively*, this approach works for small bits of data. When the data is writBig, and spread all over the place, this ancient rewrite script technique, gets very hard to maintain and expensive. We built precisely this for CASS using the Context scripting language. It still works but no one can maintain it any longer. While this is legal, if it breaks the common server-side scripting paradigm, we have to be ready to explain why a lot of people should be rethinking their practice and their acceptance of a WWW norm. Chris's To: lee@sq.com CC: w3c-sgml-wg@www10.w3.org Subject: Re: Sample Question lee@sq.com wrote: > > In general, HTML files will need to be filtered to become XML files. > The transformation is simple, and has been discussed at length on this list. Prepare to present it in detail in San Diego or on CTS in the interim. That example is straight out of the LiveWire Developer's Guide. http://developer.netscape.com/library/documentation/livewrie/getstart.html len From: "Christopher R. Maden" Date: Thu, 30 Jan 1997 18:03:40 GMT To: w3c-sgml-wg@www10.w3.org Subject: Re: Entity and Element Addressing [Peter Murray-Rust] > i.e. the starttag is in one file and the endtag in another. Whilst > this is horrible, it is the sort of thing that a mindless text > processor might do when sending chunks to a mailer with size > restrictions. See clause 2.1, "Logical and Physical Structure". Entities must each contain an integral number of elements, comments, processing instructions, and references, possibly together with character data not contained within any element in the entity, or else they must contain non-textual data, which by definition contains no elements. This would indeed be horrible, and is mercifully forbidden. (It is good to have an indexed version of the specification...) > [BTW I am not a supporter of punctuation in NAMEs if it can be > avoided. For example, I create Java classes for most of my Elements > directly from their names. -XML-LINK.java is illegal, and probably > has to be contracted to XMLLINK.java. The (obvious?) underscore > character doesn't seem to be used in XML names (?)] The underscore character is not a legal name character in the SGML reference concrete syntax, which XML tries to use as much as possible. Should _ be added as a name character? The link specification does not force you to use -XML-LINK as the element name; you can use attributes to communicate that elements of your own devising have a defined XML link role. -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) Date: Thu, 30 Jan 1997 14:00:00 -0500 From: gtn@ebt.com (Gavin Nicol) To: crm@kirk.mit.edu CC: w3c-sgml-wg@www10.w3.org Subject: Re: Sample Question Chris offers: ...")]]> another way of doing this is the way