Date: Mon, 16 Dec 1996 08:32:37 -0500 From: gtn@ebt.com (Gavin Nicol) To: jeanpa@microsoft.com CC: w3c-sgml-wg@w3.org Subject: RE: RS/RE, again (sorry) >well, for example because it is a very common behavior >of a *lot* of text applications to let the user choose the >number of characters which are allowed in a line. >Even :-) SGML tools such as Grif or Adept allows that. That seems to be quite different to the "must" assertion you made. Date: 16 Dec 1996 14:06:00 +0000 (GMT) From: Peter Flynn Subject: RE: RS/RE, again (sorry) To: w3c-sgml-wg@w3.org > >well, for example because it is a very common behavior > >of a *lot* of text applications to let the user choose the > >number of characters which are allowed in a line. > >Even :-) SGML tools such as Grif or Adept allows that. > > That seems to be quite different to the "must" assertion you > made. I can think of at least one system where you get no choice: VMS limits the length of a line in a text file to 256 chars. ///Peter Date: Mon, 16 Dec 1996 09:53:07 -0500 From: gtn@ebt.com (Gavin Nicol) To: pflynn@curia.ucc.ie CC: w3c-sgml-wg@w3.org Subject: RE: RS/RE, again (sorry) >> That seems to be quite different to the "must" assertion you >> made. > >I can think of at least one system where you get no choice: VMS >limits the length of a line in a text file to 256 chars. Does that mean that the line of text must have a newline at the end of it? Date: Mon, 16 Dec 1996 08:01:57 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Maximimum line lengths Look guys, let's not be pedantic. Modern operating systems have no architectural reqirement for arbitrary-length lines. However, many editing systems, de facto, do. Vi does [any sneers along the lines of "you'd edit structured documents with vi ?!?!?" will be taken as signs of uncultured ignorance]. Emacs, de facto, does. Some of the SGML editors do. Word doesn't. Some of the SGML editors don't. I gave a speech at the Usenix general meeting in 1988 wherein one of the major headings was: "\n Considered Harmful" I still haven't won that argument. Editors break lines. Elvis is dead. Deal with it. - Tim Date: 16 Dec 1996 15:50:35 +0000 (GMT) From: Peter Flynn Subject: RE: RS/RE, again (sorry) To: w3c-sgml-wg@w3.org > >I can think of at least one system where you get no choice: VMS > >limits the length of a line in a text file to 256 chars. > > Does that mean that the line of text must have a newline at the > end of it? I was a bit off-target in blaming VMS, it's actually some of the VMS systems software like the EDT editor which imposes the limit. But it is a serious problem for VMS users, that if they download a text file (eg an SGML instance) which has lines >256 chars, EDT won't let them edit it. And yes, "lines" for VMS, like for DOS, must end with a CRLF. A UNIX-style newline (LF) or a Mac-style linebreak (CR) is insufficient. FTP in text mode accommodates this happily, but HTTP just shovels bytes across the network. I don't know if UAs do any newline conversion based on the MIME type (eg text/plain or text/x-sgml). ///Peter From: dgd@cs.bu.edu (David Durand) Date: Mon, 16 Dec 1996 11:48:44 -0500 (EST) To: w3c-sgml-wg@w3.org Subject: Re: simplifying comments in SGML '97 I will remind people that the argument for changing comments is not simply that "ASCII em-dash" is a useful punctuation mark -- though that is certainly true -- but that the restriction has no justification in terms of XML. The only good thing about the current definition is that I expect most XML implementors won't care about SGML compatibility and will skip implementing this "feature", or at least make it optional. The issue is whether it is good user design to explicitly forbid something for no reason that makes sense within the system. Some of us feel strongly that users are should only get errors when they try to do something logically impossible or logically possible, but beyond the designed purpose of the system. In SGML syntax, the -- restriction in comments, while annoying, is rational. in XML, it is a meaningless restriction, a small wart on the language. Since we hope for XML to spread the gospel and practice of content-markup beyond our already-committed little community of SGML-folx, I think we will be served by making XML as inviting and wart-free as possible. This is (Tim Bray's?) stoopid test. I think we have spent so long worrying about SGML syntax details, that we sometimes reflexively assign them value that they do not have. We also underestimate the annoyance value of restrictions because we understand the real value of properly marked-up texts -- for those not yet as convinced as we are, small details can reinforce a pre-existing negative impression, and by strengthening rather than weakening a prejudice, hurt the case for decent markup. And let's not kid ourselves, the view of SGML in the Internet world is quite negative. In my experience, this is usually caused by a mixture of ignorance as the the point of SGML, and technical repugnance at the clarity, consistency, and implementation difficulty of the language definition. Date: Mon, 16 Dec 1996 12:01:08 -0600 From: Len Bullard To: David Durand CC: w3c-sgml-wg@w3.org Subject: Re: simplifying comments in SGML '97 David Durand wrote: > > And let's not > kid ourselves, the view of SGML in the Internet world is quite > negative. In my experience, this is usually caused by a mixture of > ignorance as the the point of SGML, and technical repugnance at the > clarity, consistency, and implementation difficulty of the language > definition. And the uncalled for public beating it took at the hands of the HTML religious zealots, value-pair practicioners, etc. Let's not reopen this discussion for any reason. All the wounds are still fresh. Who is kidding who... len bullard Date: Mon, 16 Dec 96 12:26:41 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: RS/RE, again (sorry) I have tried to re-read the last week's worth of postings on REs, and I'm still not sure I've internalized all the pros and cons. Nevertheless, I'm going to try to summarize some of my current thoughts. I want to be able to use HyTime treelocs and datalocs to address into my XML document, and I want the addresses that I created in my authoring tool that has/reads/uses the DTD to point to the same place when I bring the document up in a browser that doesn't have/read/use the DTD. Insofar as XML defines whitespace handling so that the datalocs resolve differently in the two cases, I think we have made a mistake. (There are other reasons I want whitespace handling to be identical with and without the DTD, but this is one obvious reason.) The above implies for me that we cannot leave the decision of what whitespace is significant to the style sheet. (We can and should leave the decision of what the application does with the significant whitespace up to the application in consultation with the style sheet. Therefore, deciding if an RE in data characters should be formatted as an interword space or if consecutive whitespace is collapsed should be a matter left to the style sheet and application, but whether the XML parser/grove constructor passes a given whitespace character on to the application as data must be well-defined in the XML spec without reference to the style sheet.) I really do not like having special attributes in the document instance. Having magic attributes that affect parsing feels quite wrong to me to say nothing of how kludgy it looks to have -XML-... attributes mentioned in the XML spec. It also means all tools that will use DTDs will have to know about these magic attributes, since they may be in the instance but not in the DTD (trust me, someone will use a DTD without -XML- attrs and generate some XML instance, send it to another tool that doesn't use DTDs, use that tool to insert -XML- attrs, then return it to the original tool and be surprised if that original tool complains about the -XML- attrs that are part and parcel of the XML standard itself). If we have defined the concept of well-formed XML precisely so that we can deal with XML instances without DTDs, then I suggest we refine the definition of well-formedness to include what we might call "normalized whitespacing." An XML document is well-formed (and therefore can be properly processed without reference to a DTD) *only* if it contains no (non-markup) whitespace that would be insignificant if it were parsed with reference to its DTD. The above paragraph doesn't have to mean that every RE is significant. As Tim posted recently, editors will break lines, "deal with it." (For those who want to debate whether this is really a requirement or not by making technical arguments, please accept the following: my customers require it--end of discussion. For what it's worth, my customers do not want record ends introduced in markup. We have actually had several customers submit "bugreports" when they find we have introduced a record end within a start tag.) What the previous paragraph does seem to mean is that whatever REs XML deems to be insignificant must be determined to be insignificant regardless of the content model since we may not have the DTD. For example, we can say (as I believe we have in the current XML draft) that an RE immediately following a start tag is insignificant thereby providing places editors and others can introduce record ends while still allowing all XML processors to interpret the results identically without requiring knowledge of the DTD. paul Date: Mon, 16 Dec 96 13:12:22 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: simplifying comments in SGML '97 > From: dgd@cs.bu.edu (David Durand) > > I will remind people that the argument for changing comments is not > simply that "ASCII em-dash" is a useful punctuation mark -- though that > is certainly true -- but that the restriction has no justification in > terms of XML. The only good thing about the current definition is that > I expect most XML implementors won't care about SGML compatibility and > will skip implementing this "feature", or at least make it optional. . . Hello! I expect most XML implementors *are* the SGML vendors. Look at this working group and ERB. I do not believe you do anyone a service by making "we/they" sorts of comments about XML/SGML. paul Paul Grosso VP Research, ArborText, Inc. and Chief Technical Officer, SGML Open Email: paul@arbortext.com From: "Christopher R. Maden" Date: Mon, 16 Dec 1996 22:15:20 GMT To: w3c-sgml-wg@w3.org Subject: Re: RS/RE, again (sorry) In attempting to draft an argument to Paul Grosso, I've run into a quandary. 1) In the absence of a DTD, we must assume mixed content for everything.[*] 2) This could create whitespace nodes in element content. 3) A dichotomy between "DTD-ful" and DTD-less parsing will make any sibling-based relationship difficult at best; this will affect some TEI or HyQ based hyperlinks, as well as sibling-based stylistic decisions. 4) The only way to avoid the dichotomy is to preserve these whitespace nodes even when a DTD is present. 5) Since SEPCHAR is thrown away in element content, every element must be made mixed content, and any element declaration without #PCDATA is illegal. This is clearly unacceptable. Once the addressing issues are considered, I don't think that either RE delenda est or Charles Goldfarb's shortref hack cuts it - Paul Prescod's suggestions of explicit mixed content delimiters or elimination of mixed content whitespace seem to be the only workable suggestions. They're icky, but I don't see another way. -Chris [*] There are proposals for heuristics to determine the difference, but I can think of a failure condition for any of the ones I've seen so far. -- http://www.ebt.com +1.401.421.9550 +1.401.521.2030 One Richmond Square, Providence, RI 02906 USA" NDATA SGML.Geek> To: w3c-sgml-wg@w3.org Subject: Mixed vs. element content (Was Re: RS/RE, again (sorry)) Date: Mon, 16 Dec 1996 15:52:21 -0800 From: Joe English Christopher R. Maden wrote: > 1) In the absence of a DTD, we must assume mixed content for > everything.[*] With you so far. > 2) This could create whitespace nodes in element content. I don't think so: if all element types have mixed content, then there is no element content in which whitespace nodes could appear! Actually there are two cases to consider: (A) The document creator does not provide a formal document type definition. In this case, the semantics stated in point (1) should apply, and by my reasoning there can be no whitespace in element content to worry about. (B) The document owner provides a formal document type definition, but the document consumer chooses to ignore it. This is the only case where I see a problem, but I don't think it's a very big one. I'll get to that in a moment... > 3) A dichotomy between "DTD-ful" and DTD-less parsing will make any > sibling-based relationship difficult at best; this will affect some > TEI or HyQ based hyperlinks, as well as sibling-based stylistic > decisions. However, it will _not_ cause a problem for a large class of applications; namely those in which extraneous whitespace is irrelevant (full-text indexers, web-walkers, etc.) or is dealt with separately by the application (CSS-based formatters, any formatter based on TeX or TeX-like algorithms, etc.) Extraneous whitespace _can_ cause a problem for DSSSL-based formatters, but I don't think that's a big problem either (please see below). > 4) The only way to avoid the dichotomy is to preserve these whitespace > nodes even when a DTD is present. That's one way to avoid it, but it's not the _only_ way. I propose the following: * If the author fails to provide a formal document type definition, then all whitespace is assumed to be significant (as per (1), above). * If the author does provide a formal document type definition, then applications must examine the DTD to determine where whitespace is significant. I think this will work. A large class of applications simply _do not care_ about the distinction between element and mixed content: they will produce the same results in either case. Applications in that class do not need to examine the DTD. Applications that do care about the distinction will need to examine the DTD. I do not see this as an onerous burden for any of the applications in this class that have been mentioned so far: all the ones listed so far will need to examine the DTD anyway (in order to process general entity declarations), and compared to the effort involved in (say) writing a DSSSL-O engine, parsing content models to see if they contain a #PCDATA token is just not that difficult. Back to case (A): if authors choose not to include a formal document type definition, then it will be up to them to take care of extraneous whitespace. There are several options; they could include whitespace-discarding rules in all relevant stylesheets, format their documents so that no extraneous whitespace appears in the first place, or provide a DTD, to name three. > 5) Since SEPCHAR is thrown away in element content, every element must > be made mixed content, and any element declaration without #PCDATA > is illegal. > > This is clearly unacceptable. Agreed, especially considering the production for "Mixed-content declaration" in section 3.2.1 of the XML spec, which limits content models containing #PCDATA to repeatable OR groups. --Joe English jenglish@crl.com 3245 146th Place S.E., Suite 270, Bellevue, WA 98007, USA Date: Mon, 16 Dec 1996 17:48:37 -0800 To: w3c-sgml-wg@w3.org From: Derek Denny-Brown Subject: Mixed vs. element content (Was Re: RS/RE, again (sorry)) Joe English wrote: >Christopher R. Maden wrote: >> 3) A dichotomy between "DTD-ful" and DTD-less parsing will make any >> sibling-based relationship difficult at best; this will affect some >> TEI or HyQ based hyperlinks, as well as sibling-based stylistic >> decisions. > >However, it will _not_ cause a problem for a large class of >applications; namely those in which extraneous whitespace >is irrelevant (full-text indexers, web-walkers, etc.) or >is dealt with separately by the application (CSS-based >formatters, any formatter based on TeX or TeX-like algorithms, >etc.) > >Extraneous whitespace _can_ cause a problem for DSSSL-based formatters, >but I don't think that's a big problem either (please see below). > >> 4) The only way to avoid the dichotomy is to preserve these whitespace >> nodes even when a DTD is present. > >That's one way to avoid it, but it's not the _only_ way. >I propose the following: > > * If the author fails to provide a formal document type > definition, then all whitespace is assumed to be significant > (as per (1), above). > > * If the author does provide a formal document type definition, > then applications must examine the DTD to determine where > whitespace is significant. > >I think this will work. A large class of applications simply >_do not care_ about the distinction between element and mixed >content: they will produce the same results in either case. >Applications in that class do not need to examine the DTD. I see this issue raising a distinction not unlike the issue addressed by the 'Required Markep Declaration' already provided for in the spec. Where the RMD says what is required to parse this document properly (or at all), we are now talking about what is required to properly parse white-space. I don't really like the -xml-space attribute, it does a reasonable job os the simple cases. (It still is a bit rough though, as this whole discussion has pointed out.) When a document (or it's DTD) is too complex for this simple tool to handle it, the document should just be able to demand that the DTD be processed in order for white space to be parsed properly. A DSSSL display engine would tell it's XML parser that it cares about white space, and the XML parser might thus be required to retrieve the DTD when it might not otherwise have needed it. Similarly, a server which servers complex XML documents, might normalize the documents such that white space processing was not neccessary (assuming it has access to the DTD). Somewhere, someone has to take into account white-space/RE handling. The indication is that the user can not always be expect to take on this burden, so someone else must carry it, in those cases where is significant. >Applications that do care about the distinction will need >to examine the DTD. I do not see this as an onerous burden >for any of the applications in this class that have been >mentioned so far: all the ones listed so far will need to >examine the DTD anyway (in order to process general entity >declarations), and compared to the effort involved in (say) >writing a DSSSL-O engine, parsing content models to see if >they contain a #PCDATA token is just not that difficult. This assumes that the issue with DTD's is the complexity of parsing and processing the DTD. If the issue is the bandwidth required for passing the DTD, then these arguements do not hold. Unfortunately, I have encoundered many documents where the DTD is an order of magnitude larger than the instance. (Whether this is bad design on the part of SGML or the document architect is irrelevant. I still believe it may be common) I am concerned that a document parsed as XML (as opposed to SGML) will require different HyTime location addressing, or a different DSSSL style sheet, than if the same document was parsed as SGML. Such a situation defeats a number of the goals of XML, mainly it's SGML compatibility. -derek "that which is not slightly distorted lacks sensible appeal: from which it follows that irregularity - that is to say, the unexpected, surprise, and astonishment, are an essential part and characteristic of beauty" - Charles Baudelaire Date: Mon, 16 Dec 1996 22:54:30 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: RS/RE, again (sorry) [Paul Grosso:] | If we have defined the concept of well-formed XML precisely so that we | can deal with XML instances without DTDs, then I suggest we refine the | definition of well-formedness to include what we might call | "normalized whitespacing." An XML document is well-formed (and | therefore can be properly processed without reference to a DTD) *only* | if it contains no (non-markup) whitespace that would be insignificant | if it were parsed with reference to its DTD. I rather like this idea, but what do you mean by "its DTD"? There are an infinite number of candidates. Jon Date: Mon, 16 Dec 1996 22:59:57 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org CC: bosak@atlantic-83.eng.sun.com Subject: Re: RS/RE, again (sorry) [Chris Maden:] | 3) A dichotomy between "DTD-ful" and DTD-less parsing will make any | sibling-based relationship difficult at best; this will affect some | TEI or HyQ based hyperlinks, as well as sibling-based stylistic | decisions. Sorry to be so slow here, but what's the connection with sibling relationships? My idea of a well-formed XML document is one for which there is just one possible tree structure; what's different about sibling relationships if a DTD is provided? Jon Date: Tue, 17 Dec 1996 08:18:50 -0500 To: w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: Mixed vs. element content (Was Re: RS/RE, again (sorry)) Is this a valid summary of your proposal: The spec should require the application to read the DTD for proper whitespace handling of element content. Many applications do not care about proper whitespace handling and can thus skip the DTD. Paul Prescod Date: Tue, 17 Dec 1996 08:18:47 -0500 To: Derek Denny-Brown , w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: Mixed vs. element content (Was Re: RS/RE, again (sorry)) At 05:48 PM 12/16/96 -0800, Derek Denny-Brown wrote: >I see this issue raising a distinction not unlike the issue addressed by the >'Required Markep Declaration' already provided for in the spec. > > >Where the RMD says what is required to parse this document properly (or at >all), we are now talking about what is required to properly parse >white-space. I don't really like the -xml-space attribute, it does a >reasonable job os the simple cases. (It still is a bit rough though, as >this whole discussion has pointed out.) When a document (or it's DTD) is >too complex for this simple tool to handle it, the document should just be >able to demand that the DTD be processed in order for white space to be >parsed properly. A DSSSL display engine would tell it's XML parser that it >cares about white space, and the XML parser might thus be required to >retrieve the DTD when it might not otherwise have needed it. Similarly, a >server which servers complex XML documents, might normalize the documents >such that white space processing was not neccessary (assuming it has access >to the DTD). But a "complex" document in this case is any document with whitespace in element content. Which is to say, probably most:

FOO

BAR

So if we go with a scheme of "required DTD downloading to handle 'complex' whitespace", either XML will get a "rep" as a hard to use language where you must type this:

FOO

BAR

or as a language where you must basically always download the DTD. Paul Prescod Date: 17 Dec 1996 14:30:16 +0000 (GMT) From: Peter Flynn Subject: Re: Mixed vs. element content (Was Re: RS/RE, again (sorry)) To: w3c-sgml-wg@w3.org Paul Prescod wrote: > Is this a valid summary of your proposal: > > The spec should require the application to read the DTD for proper > whitespace handling of element content. Many applications do not care about > proper whitespace handling and can thus skip the DTD. Surely it should be the other way round: many applications do not care about the DTD and can thus skip proper whitespace handling. ///Peter Date: Tue, 17 Dec 96 10:05:37 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: RS/RE, again (sorry) > From: bosak@atlantic-83.eng.sun.com (Jon Bosak) > > [Chris Maden:] > > | 3) A dichotomy between "DTD-ful" and DTD-less parsing will make any > | sibling-based relationship difficult at best; this will affect some > | TEI or HyQ based hyperlinks, as well as sibling-based stylistic > | decisions. > > Sorry to be so slow here, but what's the connection with sibling > relationships? My idea of a well-formed XML document is one for which > there is just one possible tree structure; Precisely what I would hope too. That was one of the reasons behind my earlier posting on this, part of which you quote below. > what's different about > sibling relationships if a DTD is provided? If whitespace is significant (i.e., contributes to the grove) in one case (e.g., whitespace in element content that is not known to be within element content when the DTD is not available and is therefore considered to be significant) and not in the other (i.e., when the DTD indicates the whitespace is in element content), then you will have what HyTime considers to be pseudo-elements in the first case and not in the second. For example, consider:

Paragraph one.

Paragraph two.

If
is known to have element content, then the

element whose content is "Paragraph two." is the second child of

whereas if the section has mixed content, that same

is the third child of

. A HyTime treeloc of 1 1 2 that should properly address the "Paragraph two."

element when

is known to have element content would instead address the " " pseudo-element when
is assumed to have mixed content. > From: bosak@atlantic-83.eng.sun.com (Jon Bosak) > > [Paul Grosso:] > > | If we have defined the concept of well-formed XML precisely so that we > | can deal with XML instances without DTDs, then I suggest we refine the > | definition of well-formedness to include what we might call > | "normalized whitespacing." An XML document is well-formed (and > | therefore can be properly processed without reference to a DTD) *only* > | if it contains no (non-markup) whitespace that would be insignificant > | if it were parsed with reference to its DTD. > > I rather like this idea, but what do you mean by "its DTD"? There are > an infinite number of candidates. By "its DTD" I really mean by any one of its infinite possible DTDs. In particular, a well-formed doc could never have whitespace that could be significant in any possible DTD and insignificant in any other possible DTD. It could only have whitespace that would always significant (e.g., in between two words) or that would always be insignificant (e.g., an RE immediately following a start tag or immediately preceding an end tag). Date: Tue, 17 Dec 96 09:45:58 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Grosso whitespace proposal It appears that (1) PaulP sent this only to me and not to the list and (2) he meant to send this to the list. Therefore, I am forwarding it. Apologies if either (1) and/or (2) is incorrect--I hope I am not committing some huge faux pas. ----- Begin Included Message ----- >From papresco@csclub.uwaterloo.ca Tue Dec 17 09:05:31 1996 Date: Tue, 17 Dec 1996 09:56:04 -0500 To: paul@arbortext.com (Paul Grosso) From: Paul Prescod Subject: Grosso whitespace proposal At 12:26 PM 12/16/96 CST, you wrote: >What the previous paragraph does >seem to mean is that whatever REs XML deems to be insignificant must be >determined to be insignificant regardless of the content model since we >may not have the DTD. For example, we can say (as I believe we have in >the current XML draft) that an RE immediately following a start tag is >insignificant thereby providing places editors and others can introduce >record ends while still allowing all XML processors to interpret the >results identically without requiring knowledge of the DTD. Every proposal we've seen has glitches, and I just wanted to make this one's explicit. a) The first may or may not be a big deal depending on your point of view, but that means that "well formed" XML documents cannot have a list or table formatted as they are typically formatted, where whitespace is introduced after the item/row end-tag. That might be a compromise we could live with. Is there a hack we could use to "escape" all of the whitespace up to the next tag? \ ...\ ...\ ...\ b) I'm a little uncomfortable giving users something that *looks* like what they are used to, but doesn't behave like it. It may well be better from a usability standpoint (though not a marketing one) to give them something that looks "funny". c) Who is going to check this well-formedness constraint? SGML parsers will happily eat the whitespace. Non-validating XML parsers will not read the DTD and so cannot notice whitespace in element content. We would need a new kind of parser: a validating XML parser *not* built on top of an SGML parser. (this is technically possible, but it is just more work) OTOH, perhaps this solution has the fewest glitches of the ones we have looked at. Paul Prescod ----- End Included Message ----- From: "Christopher R. Maden" Date: Tue, 17 Dec 1996 16:12:35 GMT To: w3c-sgml-wg@w3.org Subject: Re: RS/RE, again (sorry) [Jon Bosak] > [Chris Maden:] > > | 3) A dichotomy between "DTD-ful" and DTD-less parsing will make any > | sibling-based relationship difficult at best; this will affect some > | TEI or HyQ based hyperlinks, as well as sibling-based stylistic > | decisions. > > Sorry to be so slow here, but what's the connection with sibling > relationships? My idea of a well-formed XML document is one for > which there is just one possible tree structure; what's different > about sibling relationships if a DTD is provided? TEI and, I believe, HyQ, use sibling relationships for addressing; e.g., start at the element whose SGML ID is "foo" and traverse three nodes to the right. If DTD-less parsing creates spurious CDATA nodes, then the target of an address can be different from that for a DTD-ful parse. -Chris -- http://www.ebt.com +1.401.421.9550 +1.401.521.2030 One Richmond Square, Providence, RI 02906 USA" NDATA SGML.Geek> Date: Tue, 17 Dec 96 10:17:46 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: Grosso whitespace proposal > From: Paul Prescod > > At 12:26 PM 12/16/96 CST, you wrote: > >What the previous paragraph does > >seem to mean is that whatever REs XML deems to be insignificant must be > >determined to be insignificant regardless of the content model since we > >may not have the DTD. For example, we can say (as I believe we have in > >the current XML draft) that an RE immediately following a start tag is > >insignificant thereby providing places editors and others can introduce > >record ends while still allowing all XML processors to interpret the > >results identically without requiring knowledge of the DTD. > > Every proposal we've seen has glitches, and I just wanted to make this one's > explicit. > > a) The first may or may not be a big deal depending on your point of view, > but that means that "well formed" XML documents cannot have a list or table > formatted as they are typically formatted, where whitespace is introduced > after the item/row end-tag. That might be a compromise we could live with. This may be true (depending on how lists or tables are "typically formatted"). The way I would format a list or table or anything else is: only put blanks where I want them in my data and only break lines immediately after start tags or immediately before end tags. > > Is there a hack we could use to "escape" all of the whitespace up to the > next tag? > > \ > ...\ > ...\ > ...\ > I would not want to see us employ such a hack. The list could be formatted, for example: ... ... ... > > b) I'm a little uncomfortable giving users something that *looks* like what > they are used to, but doesn't behave like it. It may well be better from a > usability standpoint (though not a marketing one) to give them something > that looks "funny". (Not sure what you mean here.) > > c) Who is going to check this well-formedness constraint? SGML parsers will > happily eat the whitespace. Non-validating XML parsers will not read the DTD > and so cannot notice whitespace in element content. We would need a new kind > of parser: a validating XML parser *not* built on top of an SGML parser. > (this is technically possible, but it is just more work) I thought we had all agreed that validation required a DTD (and many of us believe that authoring is best done in the presence of a DTD too). With the DTD, the validator/authoring tool can tell which whitespaces are insignificant and remove them. Then, if necessary/desired, that tool can insert REs after start tags and before end tags to break up long lines. The resulting file would then be well-formed wrt whitespace. Browsers and other tools that handle XML without reference to a DTD would merely assume the file to be well-formed and would therefore consider all whitespace (except REs after start tags and before end tags) to be significant. Date: Tue, 17 Dec 1996 11:51:46 -0500 To: paul@arbortext.com (Paul Grosso), w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Parsing technology (was Re: Grosso whitespace proposal) At 9:45 AM 12/17/96, Paul Grosso wrote: >c) .... We would need a new kind >of parser: a validating XML parser *not* built on top of an SGML parser. >(this is technically possible, but it is just more work) Funny, this is the solution that I intend to adopt for all my document processing as soon as I finish my thesis. (because I may have to write the validating XML parser myself, but them's the breaks...). I'm not interested in working with the vagaries of SGML glitches, except when I'm being paid for it, but I would dearly like to use content markup all the 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, 17 Dec 1996 11:51:55 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Another requirement qualification. (*Not* a proposal, please read!) People don't seem to be interested in my project of listing requirements, constraints and proposd solutions, but I will persist, as I can no longer keep the proposals straight. Point 1. of my requirements list gives the "desire that parse trees be the same." Under that point, the following explanation should be added. As Chris Maden has reminded us, not having this will break treeloc and the untyped varieties of TEI extended location pointer, because sibling counts will differ, due to pseudo-elements in element content. TEI typed pointers are not affected, because you count elements of a specified type, and so stray pseudo-elements would not be a problem. So we need to add that as an important reason for requiring either identical parse trees, or typed tree locations. It would really be a shame if we define structural markup in a way that makes any class of structural links _less_ dependable than byte offsets! -- David PS. I would welcome additions to the list of "proposed techniques" so that we can understand the proposals. I will repost the modified document and keep it up to date, if people will contribute. At this point, I think everyone posting has made at least 1 different proposal, with various permutations of the same few techniques and goals, and doubtless others that I have omitted. When there are too many straw proposals, I think we must look to explicit goal-setting to make progress. -- 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, 17 Dec 96 10:50:12 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: Parsing technology (was Re: Grosso whitespace proposal) > From: dgd@cs.bu.edu (David G. Durand) > Subject: Parsing technology (was Re: Grosso whitespace proposal) > > At 9:45 AM 12/17/96, Paul Grosso wrote: No I didn't, and I'm not sure I would agree with that statement. Paul Prescod wrote that statement. > > >c) .... We would need a new kind > >of parser: a validating XML parser *not* built on top of an SGML parser. > >(this is technically possible, but it is just more work) > > Funny, this is the solution that I intend to adopt for all my document > processing as soon as I finish my thesis. (because I may have to write the > validating XML parser myself, but them's the breaks...). I'm not interested > in working with the vagaries of SGML glitches, except when I'm being paid > for it, but I would dearly like to use content markup all the time. Date: Tue, 17 Dec 1996 12:20:04 -0500 To: w3c-sgml-wg@w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Apology (was Re: Parsing technology) At 10:50 AM 12/17/96, Paul Grosso wrote ( I think I got it right this time): >No I didn't, and I'm not sure I would agree with that statement. All apologies. Sometimes this multi-level quoting gets confusing. And my post was pretty marginal anyway. Now back to our regularly scheduled program. -- 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 \__________________________ 3245 146th Place S.E., Suite 270, Bellevue, WA 98007, USA Date: Tue, 17 Dec 1996 09:26:08 -0800 To: Paul Prescod From: Derek Denny-Brown Subject: Re: Mixed vs. element content (Was Re: RS/RE, again (sorry)) Cc: w3c-sgml-wg@w3.org At 08:18 AM 12/17/96 -0500, Paul Prescod wrote: >The spec should require the application to read the DTD for proper >whitespace handling of element content. Many applications do not care about >proper whitespace handling and can thus skip the DTD. Taking into account such rules as ignoring RE's immediately following start tags or immediately preceeding end tags (some people seem to think this is in the spec, I didn't look very hard, but didn't see it right off... but something like that should be there), your summary is exactly what I mean. Whether a stylesheet is sensitive to extra whitespace/RE's is dependant on the style sheet, but there are a number of HyTime location addressing mechanisms which WILL break if pseudo-elements show up where they were not there before (or disappear for that matter). It has been mentions that some TEI locators will also break. I have no real problem with keeping the -xml-space attribute also. I just require that the parse tree for DTDless and DTDful parsing be the same, which is what I believe David Durand meant when he said he required that the "parse trees be the same." -derek (amused that somehow in the middle of a discussion on RE handling, hyper linking rears it ugly head, esp. given that hyper linking etc. is what we are scheduled to be discussing...) "that which is not slightly distorted lacks sensible appeal: from which it follows that irregularity - that is to say, the unexpected, surprise, and astonishment, are an essential part and characteristic of beauty" - Charles Baudelaire 3245 146th Place S.E., Suite 270, Bellevue, WA 98007, USA Date: Tue, 17 Dec 1996 09:33:05 -0800 To: Paul Prescod From: Derek Denny-Brown Subject: Re: Mixed vs. element content (Was Re: RS/RE, again (sorry)) Cc: w3c-sgml-wg@w3.org At 08:18 AM 12/17/96 -0500, Paul Prescod wrote: >But a "complex" document in this case is any document with whitespace in >element content. Which is to say, probably most: > > >

FOO

>

BAR

>
> >So if we go with a scheme of "required DTD downloading to handle 'complex' >whitespace", either XML will get a "rep" as a hard to use language where you >must type this: > >

FOO

BAR

> >or as a language where you must basically always download the DTD. In one of my versions of what I posted (I rewrote portions of it a number of times as my ideas solidified), and may not have made it off my computer, I mention that there should be some simple rules to allow from some whitespace/RE's to be ignored. i.e. ignoring RE's after a start tag, or the -xml-space attribute. I agree that we can not expect to treat all RE's as data. I am just worried that the proposals being brought forth will break HyTime when applied to XML. Given that I was actively involved with drafting the forthcoming HyTime TC, it is important to me that HyTime is not completely abandoned, when it need not be. (Not that I am wed to HyTime. It has it's flaws by the cartload, but It does do a number of things quite well, and I am hoping that the TC and eliot's book will bear that out....) -derek "that which is not slightly distorted lacks sensible appeal: from which it follows that irregularity - that is to say, the unexpected, surprise, and astonishment, are an essential part and characteristic of beauty" - Charles Baudelaire Date: Tue, 17 Dec 1996 13:40:25 -0500 To: paul@arbortext.com (Paul Grosso), w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: Grosso whitespace proposal At 10:17 AM 12/17/96 CST, Paul Grosso wrote: >> From: Paul Prescod >> >> a) The first may or may not be a big deal depending on your point of view, >> but that means that "well formed" XML documents cannot have a list or table >> formatted as they are typically formatted, where whitespace is introduced >> after the item/row end-tag. That might be a compromise we could live with. > >This may be true (depending on how lists or tables are "typically >formatted"). The way I would format a list or table or anything >else is: only put blanks where I want them in my data and only >break lines immediately after start tags or immediately before end tags. Do you mean that is how you would format a list in the new XML proposal, or that is how you would "normally" format lists, (which I presume you don't normally do by hand anyway)? All I meant in the poing above is that most documents on the Web seem to use this convention: .........
which is perfectly valid in SGML, and seems quite readable and reasonable to me. As I said, we could live without it, but should at least be aware that we are losing something. >> Is there a hack we could use to "escape" all of the whitespace up to the >> next tag? >> >> \ >> ...\ >> ...\ >> ...\ >> > >I would not want to see us employ such a hack. The list could be formatted, >for example: I tend to think the "hack" gives more freedom. Note that I mean "hack" in the sense of "SGML Hack" (like the other SGML declaration tricks we are using) and not hack from the end-users point of view. I think that such an escape mechanism, if it is possible would give typists freedom to format as they like and implementors a simple mechanism for distinguishing data-whitespace from formatting-whitespace. It seems like a good compromise to me: "you can continue to markup up as you have been, just put this character in before whitespace that you don't want displayed." Anyhow, there is probably no SGML way to do it, so it isn't worth worrying about. >> b) I'm a little uncomfortable giving users something that *looks* like what >> they are used to, but doesn't behave like it. It may well be better from a >> usability standpoint (though not a marketing one) to give them something >> that looks "funny". > >(Not sure what you mean here.) I mean that documents created according to your proposal would visually look as if they were following the SGML/HTML rules, but when you put whitespace in the "wrong" place, you would get an error message (or worse, different parse trees). Sometimes it is better to be obvious when you are doing something different than to change things subtly in this way. >> c) Who is going to check this well-formedness constraint? SGML parsers will >> happily eat the whitespace. Non-validating XML parsers will not read the DTD >> and so cannot notice whitespace in element content. We would need a new kind >> of parser: a validating XML parser *not* built on top of an SGML parser. >> (this is technically possible, but it is just more work) > >I thought we had all agreed that validation required a DTD (and many of us >believe that authoring is best done in the presence of a DTD too). With >the DTD, the validator/authoring tool can tell which whitespaces are >insignificant and remove them. Then, if necessary/desired, that tool >can insert REs after start tags and before end tags to break up long lines. >The resulting file would then be well-formed wrt whitespace. Browsers >and other tools that handle XML without reference to a DTD would merely >assume the file to be well-formed and would therefore consider all whitespace >(except REs after start tags and before end tags) to be significant. We're talking about different things. You specified that well-formed XML documents should not have whitespace between elements in element content. If this is a constraint on the documents, somebody is going to have to write a checker for it, or nobody will know if their documents are right or not. This checker cannot "check" the output of an SGML parser, because the SGML parser will already have removed the whitespace. The checker cannot use a non-validating XML parser, because without the DTD it won't know which whitespace is in the wrong place. So we need a new kind of parser for any apps that are going to load and validate XML documents. Anyone who wants to write a complete "validating XML parser" will have to modify an SGML parser, not just build on top of it. On the other hand, the "empty tag hack" may already require this. The penalty for messing up the validation of empty tag closes is going to be an obvious browser choke ("where's the end of this tag??"). The penalty for messing up the whitespace handling will be documents that are displayed subtly differently than you intended them. (it depends on your point of view which you consider worse...). As I said, these problems are fairly minor compared to the problems or inconveniences with the other proposals. Paul Prescod To: w3c-sgml-wg@w3.org Subject: Re: Mixed vs. element content (Was Re: RS/RE, again (sorry)) Date: Tue, 17 Dec 1996 10:31:02 -0800 From: Joe English Paul Prescod wrote: > Is this a valid summary of your proposal: > > The spec should require the application to read the DTD for proper > whitespace handling of element content. Many applications do not care about > proper whitespace handling and can thus skip the DTD. Yes. Peter Flynn wrote: > > Surely it should be the other way round: many applications do not > care about the DTD and can thus skip proper whitespace handling. I don't follow this line of reasoning... Applications only care about the DTD if they need information in it that is not available from the instance alone. Under my [*] proposal, the distinction between element content and mixed content would be one such piece of information. This is, after all, how it works in the base language SGML. [*] I believe that Derek Denny-Brown is proposing the same thing. Note that in XML there already is information in the DTD that is not available from the instance (the replacement text of non-predefined entities -- which DSSSL and HyTime engines will need, so we're not asking them to do a whole lot more work), and I'm willing to bet that before we've finished with hyperlinking [**] there will be even more information in this category (e.g., #FIXED attributes and/or architectural declarations). [**] Speaking of hyperlinking, does anyone have any ideas how this should be specified? We probably ought to start thinking about this... --Joe English jenglish@crl.com Date: Tue, 17 Dec 1996 12:00:02 -0900 To: Derek Denny-Brown , Paul Prescod From: "W. Eliot Kimber" Subject: Re: Mixed vs. element content (Was Re: RS/RE, again (sorry)) Cc: w3c-sgml-wg@w3.org At 09:33 AM 12/17/96 -0800, Derek Denny-Brown wrote: > ...I am just worried that the proposals being brought forth will break >HyTime when applied to XML. Given that I was actively involved with >drafting the forthcoming HyTime TC, it is important to me that HyTime is not >completely abandoned, when it need not be. I don't think it's a HyTime-specific issue, both because the problems are not unique to HyTime and because the use of HyTime is not dependent on how the parsing process is defined. All location addressing, whether HyTime-defined or not, operates on an abstraction of the data, not the original source data. This means that you have to choose your abstraction carefully, which is what we're really talking about in this whole RS/RE fracas. There are two levels of abstraction that we usually work with: 1. The immediate result of parsing. 2. The result of applying application-specific semantics to the results of parsing. There may be more levels of abstraction, but we haven't exposed those yet in our discussions of XML processing. Abstraction (1) is what HyTime and DSSSL call the "SGML document grove" or the "pGrove" (for parse grove). What can occur in this grove is completely defined by the SGML property set (published in the DSSSL standard and soon to be published again in the HyTime TC) and reflects simply applying the SGML parsing rules to the input document. It is roughly equivalent to "ESIS" except that the grove may be more complete and you have a formal way to say what you want to be in the grove (the "grove plan"). Abstraction (2) is what HyTime calls the "extended SGML document grove", or "epGrove". This is a new grove with HyTime-specific semantics applied. It uses the same propery set as the first but may either suppress or remove some things or may modify the content to reflect HyTime-specific semantics. Any application is free to create it's own extended document grove. XML processors will, presumably, provide their own XML-specific extended document groves to reflect XML-specific semantics (for example, that whitespace is collapsed when the -xml-space attribute is in effect). The -xml-space attribute is a good example of how this works in practice: an XML parser parses a document and creates a pGrove that contains all the data characters it found. If the document has no DTD, then this means all white space characters, not just those in what we know to be mixed content (white space that is not taken as data is held in "markup" properties, which are not, by definition of the SGML property set, content of the objects that exhibit them--thus these characters may be in the grove but they aren't part of the content of the elements in which they occur). An XML processor then operates on the pGrove to produce an XML epGrove in which the rules for -xml-space are applied, i.e., lists of white space character nodes in the content of elements where white space gets collapsed get replaced with single space character nodes. (Notice I didn't say "characters get replaced", the operations are on nodes in groves, not characters in strings, and each character is a node.) Any location addressing applied against XML documents would, presumably, be applied against the XML epGrove (or possibly a location-method-specific grove derived from the epGrove), not against the pGrove. Of course, the problem of knowing how to produce the XML epGrove consistently remains. However, having these two stages can make it clearer where the processing can happen and *why* using attributes to control it is not necessarily a hack because the attributes are *not* feeding back into the base parsing process (at least conceptually)--they are affecting the construction of application-specific groves and applications are free to use any information at their disposal to control grove construction. Note also that grove plans are not sufficient to solve this problem because grove plans only include or exclude entire classes of object or entire property values--they can't selectively exclude things: that requires a specific grove construction process. Note that there's absolutely no requirement that applications actually perform the grove constructions described above as discrete steps--most XML processors will go directly from source data to XML epGrove without first constructing the intermediate pGrove. But note also that HyTime (and DSSSL) can operate with equal ease on either grove and it could be possible to have both available and indicate which you actually want to address when doing addressing. (Whether this is practically useful or not, I wouldn't want to speculate at this point.) Finally, I'd like to point out that from a HyTime perspective (in the new grove-based world) any addressing notation that can be defined in terms of node lists selected from groves can be naturally integrated into a HyTime-based system. For example, TEI locators, whose grove-based results should be obvious given knowedge of the grove plan used, could be easily, meaningfully, and usefully used in conjunction with other HyTime-defined location addresses. Thus, it's not really useful to talk about "HyTime addressing" versus other forms of address: it's all the same stuff at its core and the problems posed by the data abstractions we're creating are the same. Thus the issue of, for example, whether we should prefer TEI locators over SDQL queries is an issue of appropriate syntax and user interface, not functionality [for what it's worth, I will probably end up prefering TEI locators over SDQL for XML use because it was specifically designed to meet the requirements we presume the main XML audience to have]. 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, 17 Dec 1996 08:20:30 -0800 From: bosak@atlantic-83.eng.sun.com (Jon Bosak) To: w3c-sgml-wg@w3.org cc: bosak@atlantic-83.eng.sun.com Subject: Re: RS/RE, again (sorry) I asked: | >[Chris Maden:] | > | >| 3) A dichotomy between "DTD-ful" and DTD-less parsing will make any | >| sibling-based relationship difficult at best; this will affect some | >| TEI or HyQ based hyperlinks, as well as sibling-based stylistic | >| decisions. | > | >Sorry to be so slow here, but what's the connection with sibling | >relationships? My idea of a well-formed XML document is one for which | >there is just one possible tree structure; what's different about | >sibling relationships if a DTD is provided? To which a kind correspondent replied: | A DTD-less parser will interpret element-content whitespace as a #PCDATA | node. A DTD-full parser will just strip it out. The number of nodes in your | document will change. | | | ... | ... | | | Each newline will be a node in one, and not the other. Allow me to wallow in ignorance a bit further. I'm finding it hard to visualize a situation in which I would want to address something based on pseudo-element relationships rather than "genuine" tree relationships. It's easy to imagine cases where I would want to refer to the TITLE descendant of my ancestor CHAPTER, for example, but I have never wanted to refer to the third linefeed in an element. I'm not saying that such situations are inconceivable, I'm just saying that I've never encountered one. Is this one of those cases where 90 percent of the complexity we're worrying about is being caused by a feature that in practice is used .001 percent of the time? Jon Date: Tue, 17 Dec 1996 15:21:32 -0500 To: w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: RS/RE, again (sorry) At 08:20 AM 12/17/96 -0800, Jon Bosak wrote: >Allow me to wallow in ignorance a bit further. I'm finding it hard to >visualize a situation in which I would want to address something based >on pseudo-element relationships rather than "genuine" tree >relationships. It's easy to imagine cases where I would want to refer >to the TITLE descendant of my ancestor CHAPTER, for example, but I >have never wanted to refer to the third linefeed in an element. No, but maybe to the "third node" in an element. If a linefeed is a node, your count will be different than if it is not. For instance, maybe you want a bullet on the "first" sub-element of a list item (usually a , but perhaps occasionally a ).

Foo

Bar
Is that node the whitespace before the paragraph, or the paragraph itself? Despite the hand-waving about the "stylesheet can handle it", I think it would be a constant annoyance. Paul Prescod Date: Tue, 17 Dec 1996 10:23:42 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Trying to sum up a bit On this whitespace bit, we're going to have to sum up, make some sort of compromise, and move forward. If I've been bad, when I die they're going to put me me in a room with the SGML WG for million-year arguments about RS/RE, with breaks every other millenium to discuss URNs and FPIs. 1. It is highly desirable that the many useful things you can do without DTD's (display, indexing) be done without DTD's. 2. Not having a DTD makes it impossible in principle to detect certain classes of cannot-possibly-be-data white space, i.e. in element content 3. Not being able to distinguish element from mixed content means that certain addressing constructs (e.g. those that depend on HyTime pseudo-elements) won't work in DTD-free mode if they take the DTD's view of what is mixed & what is element content. 4. This element-content white space, along with certain other classes of white space that are not data will inevitably be introduced as a result of normal usage (e.g. editors' line-breaks) and users will be irritated if these are considered data. Thus, it seems like there are a very small number of alternatives: 1. Require the DTD at all times. Pro: the problems go away. Con: the DTD is required at all times. 2. Work significant WS into the definition of well-formedness (Grosso) Adopt a tight set of rules for well-formed documents such that all white space, except RE's after tags, may safely assumed by a DTD-less processor to be significant. Pro: the problem goes away Con: 1. it's a lot harder to author XML without an XML-savvy tool 2. you can't test well-formedness without looking at a DTD 3. All non-markup bytes are signicant, whitespace or not (Durand) Pro: Everyone can understand the rules, it's easy to implement Con: You lose certain Hytime addressing facilities, and the application gets no help from the XML processor in ignoring WS that to the user is "obviously" irrelevant. 4. Use an mechanism *in the instance* to signal a DTD-less application what's going on. 4.1 The PI-based DTD summary (Sperberg-McQueen) 4.2 Explicit quoting of significant character data (Goldfarb) 4.3 -XML-SPACE 4.3.1 -XML-SPACE with one value, PRESERVE (Paoli) 4.3.2 -XML-SPACE with two values, PRESERVE/COLLAPSE (Current ERB) 4.3.3 -XML-SPACE with three values, PRESERVE/COLLAPSE/SUPPRESS (Bray) [which we might want to rename, if what we're really doing is signalling element content, mixed content, and verbatim content] 4.4 Escaping of non-significant WS (Prescod) Pro: Solves the problems Con: Requires extra work from authors, possibly duplicates DTD info with potential for loss of sync, and tends to look ugly & unnatural Under (4.3), there are some behavioral options: 4.3a1. the XML processor does what -XML-SPACE says, eats the whitespace or not, and consumes the attribute, not passing it to the application 4.3a2. the XML processor does what -XML-SPACE says *and* passes it on to the application 4.3a3. the XML processor merely passes -XML-SPACE along to the application, along with all the bytes of data; it is the application's job to do the right thing 4.3b1. A validating XML processor reading a DTD generates synthetic -XML-SPACE attributes for the application's consumption, based on its knowledge of mixed/element content 4.3b2. -XML-SPACE is only ever inserted by humans. Face facts, folk. There is just not a solution that is going to solve this problem and be free of some cost. And please remember the cost of explanation and education is very real. For myself, my preference would be (in descending order) #3, #4.3.3 (a3/b2), 4.3.2, 4.3.1. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 3245 146th Place S.E., Suite 270, Bellevue, WA 98007, USA Date: Tue, 17 Dec 1996 12:13:27 -0800 To: w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com From: Derek Denny-Brown Subject: Re: RS/RE, again (sorry) At 08:20 AM 12/17/96 -0800, Jon Bosak wrote: >I asked: > >| >[Chris Maden:] >| > >| >| 3) A dichotomy between "DTD-ful" and DTD-less parsing will make any >| >| sibling-based relationship difficult at best; this will affect some >| >| TEI or HyQ based hyperlinks, as well as sibling-based stylistic >| >| decisions. >| > >| >Sorry to be so slow here, but what's the connection with sibling >| >relationships? My idea of a well-formed XML document is one for which >| >there is just one possible tree structure; what's different about >| >sibling relationships if a DTD is provided? > >To which a kind correspondent replied: > >| A DTD-less parser will interpret element-content whitespace as a #PCDATA >| node. A DTD-full parser will just strip it out. The number of nodes in your >| document will change. >| >| >| ... >| ... >| >| >| Each newline will be a node in one, and not the other. > >Allow me to wallow in ignorance a bit further. I'm finding it hard to >visualize a situation in which I would want to address something based >on pseudo-element relationships rather than "genuine" tree >relationships. It's easy to imagine cases where I would want to refer >to the TITLE descendant of my ancestor CHAPTER, for example, but I >have never wanted to refer to the third linefeed in an element. I'm >not saying that such situations are inconceivable, I'm just saying >that I've never encountered one. Is this one of those cases where 90 >percent of the complexity we're worrying about is being caused by a >feature that in practice is used .001 percent of the time? the problem is that one tree would look like: --| "that which is not slightly distorted lacks sensible appeal: from which it follows that irregularity - that is to say, the unexpected, surprise, and astonishment, are an essential part and characteristic of beauty" - Charles Baudelaire 3245 146th Place S.E., Suite 270, Bellevue, WA 98007, USA Date: Tue, 17 Dec 1996 12:25:08 -0800 To: w3c-sgml-wg@w3.org, bosak@atlantic-83.eng.sun.com From: Derek Denny-Brown Subject: Re: RS/RE, again (sorry) (sorry for the last post... eudora maps Ctrl-E to send... not end of line...) At 08:20 AM 12/17/96 -0800, Jon Bosak wrote: >I asked: > >| >[Chris Maden:] >| > >| >| 3) A dichotomy between "DTD-ful" and DTD-less parsing will make any >| >| sibling-based relationship difficult at best; this will affect some >| >| TEI or HyQ based hyperlinks, as well as sibling-based stylistic >| >| decisions. >| > >| >Sorry to be so slow here, but what's the connection with sibling >| >relationships? My idea of a well-formed XML document is one for which >| >there is just one possible tree structure; what's different about >| >sibling relationships if a DTD is provided? > >To which a kind correspondent replied: > >| A DTD-less parser will interpret element-content whitespace as a #PCDATA >| node. A DTD-full parser will just strip it out. The number of nodes in your >| document will change. >| >| >| ... >| ... >| >| >| Each newline will be a node in one, and not the other. > >Allow me to wallow in ignorance a bit further. I'm finding it hard to >visualize a situation in which I would want to address something based >on pseudo-element relationships rather than "genuine" tree >relationships. It's easy to imagine cases where I would want to refer >to the TITLE descendant of my ancestor CHAPTER, for example, but I >have never wanted to refer to the third linefeed in an element. I'm >not saying that such situations are inconceivable, I'm just saying >that I've never encountered one. Is this one of those cases where 90 >percent of the complexity we're worrying about is being caused by a >feature that in practice is used .001 percent of the time? The problem might be better visualised.... Here is the element content parser, wher the RE's are ignored, thus there is a with 2 child nodes, each a element. -+-- | +-- Here is the parse with RE's significant. Note that there are now five subnodes of the . -+-- #PCDATA "\n" | +-- | +-- #PCDATA "\n" | +-- | +-- #PCDATA "\n" The (obvious) problem arises when you ask for the 2nd child of the element. The first parse will give you the second sub-element, while the second parse will give you a pseudo-element containing only a "\n". Without some way to indicate that this should be treated as element content, this could easily become a real mess. -derek "that which is not slightly distorted lacks sensible appeal: from which it follows that irregularity - that is to say, the unexpected, surprise, and astonishment, are an essential part and characteristic of beauty" - Charles Baudelaire Date: Tue, 17 Dec 96 14:20:07 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: Mixed vs. element content (Was Re: RS/RE, again (sorry)) > From: "W. Eliot Kimber" > > . . . > > There are two levels of abstraction that we usually work with: > > 1. The immediate result of parsing. > 2. The result of applying application-specific semantics to the > results of parsing. > > Abstraction (1) is what HyTime and DSSSL call the "SGML document grove" or > the "pGrove" (for parse grove). What can occur in this grove is completely > defined by the SGML property set (published in the DSSSL standard and soon > to be published again in the HyTime TC) and reflects simply applying the > SGML parsing rules to the input document. It is roughly equivalent to > "ESIS" except that the grove may be more complete and you have a formal way > to say what you want to be in the grove (the "grove plan"). > > Abstraction (2) is what HyTime calls the "extended SGML document grove", or > "epGrove". This is a new grove with HyTime-specific semantics applied. It > uses the same propery set as the first but may either suppress or remove > some things or may modify the content to reflect HyTime-specific semantics. > > Any application is free to create it's own extended document grove. XML > processors will, presumably, provide their own XML-specific extended > document groves to reflect XML-specific semantics (for example, that > whitespace is collapsed when the -xml-space attribute is in effect). > > . . . > > Any location addressing applied against XML documents would, presumably, be > applied against the XML epGrove (or possibly a location-method-specific > grove derived from the epGrove), not against the pGrove. > > . . . In terms of Eliot's enlightening discussion, I would state my feelings as follows: I would like to define well-formed XML so that the pGrove for any well-formed XML is equivalent to the epGrove against which we apply our location addressing. I'd like to avoid introducing an application-specific epGrove in between well-formed XML and addressing into that well-formed XML document. Date: Tue, 17 Dec 1996 12:52:18 -0800 (PST) From: Bill Smith Subject: Re: Trying to sum up a bit To: w3c-sgml-wg@w3.org Tim, thank you for attempting to bring this discussion to a close. Your summary is excellent and as to the point as can be given our lengthy discussion. I too prefer the "All non-markup bytes are signicant" approach with "-XML-SPACE" a second choice. Date: Tue, 17 Dec 1996 16:04:51 -0500 To: w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: Trying to sum up a bit Good summary Tim. As David has pointed out, it is good to keep evolving these things so that we do not go back to old points. Could you please add the answer to a couple of my questions, if you know them? At 10:23 AM 12/17/96 -0800, Tim Bray wrote: >On this whitespace bit, we're going to have to sum up, make some sort of >compromise, and move forward. Do we have anything to move forward *on*? Isn't the WG going to give us some starting document or starting point for hyperlinking discussion? Or just jump right in? >2. Work significant WS into the definition of well-formedness (Grosso) > >Adopt a tight set of rules for well-formed documents such that all white >space, except RE's after tags, may safely assumed by a DTD-less processor >to be significant. It doesn't make sense for this to be part of the well-formedness requirements. Anything that requires reference to a DTD should be a *validity* requirement. After all, some well-formed documents don't even have a DTD. >Pro: the problem goes away >Con: 1. it's a lot harder to author XML without an XML-savvy tool > 2. you can't test well-formedness without looking at a DTD This "con" becomes: "can't test validity without knowing where SSEP nodes were...many existing parsers don't tell you". >3. All non-markup bytes are signicant, whitespace or not (Durand) > >Pro: Everyone can understand the rules, it's easy to implement >Con: You lose certain Hytime addressing facilities, and the application > gets no help from the XML processor in ignoring WS that to the user > is "obviously" irrelevant. I think that in order to write stylesheets for this solution, you will end up having to list all of the element context or all of the mixed context elements in the stylesheet. Does anyone think that this is not the case? Isn't this a Big Deal that should be Discussed? >4. Use an mechanism *in the instance* to signal a DTD-less application > what's going on. > > 4.1 The PI-based DTD summary (Sperberg-McQueen) > 4.2 Explicit quoting of significant character data (Goldfarb) > 4.3 -XML-SPACE > 4.3.1 -XML-SPACE with one value, PRESERVE (Paoli) > 4.3.2 -XML-SPACE with two values, PRESERVE/COLLAPSE (Current ERB) > 4.3.3 -XML-SPACE with three values, PRESERVE/COLLAPSE/SUPPRESS (Bray) > [which we might want to rename, if what we're really doing is > signalling element content, mixed content, and verbatim content] What does an -XML-PRESERVE element do when applied to element content? Give a different parse tree for DTD-less parsers? Trigger an error in validating parsers? Both? Neither? Isn't significant whitespace the norm rather than the exception? Shouldn't it be the default? >Under (4.3), there are some behavioral options: > > 4.3a1. the XML processor does what -XML-SPACE says, eats the whitespace > or not, and consumes the attribute, not passing it to the application > 4.3a2. the XML processor does what -XML-SPACE says *and* passes it on to > the application > 4.3a3. the XML processor merely passes -XML-SPACE along to the application, > along with all the bytes of data; it is the application's job to > do the right thing Why not just let the parser do it, if it knows what needs to be done? Since we are not specifying a special message passing language for returning , why should we do so for insignificant whitespace? How are they different? Paul Prescod Date: Tue, 17 Dec 96 15:07:50 CST From: paul@arbortext.com (Paul Grosso) To: w3c-sgml-wg@w3.org Subject: Re: Trying to sum up a bit > From: Tim Bray > > Thus, it seems like there are a very small number of alternatives: > 1. Require the DTD at all times. > > Pro: the problems go away. > Con: the DTD is required at all times. > > 2. Work significant WS into the definition of well-formedness (Grosso) > > Adopt a tight set of rules for well-formed documents such that all white > space, except RE's after tags, may safely assumed by a DTD-less processor > to be significant. > Pro: the problem goes away > Con: 1. it's a lot harder to author XML without an XML-savvy tool I'll grant you the point, though I would qualify "a lot." It's easy to explain: don't put in whitespace if you don't mean it. If you are authoring in vi, for example, you don't hit space or tab unless you want it in data, and you only hit return after a start tag or before an end tag. True, pretty-indented SGML probably won't be well-formed XML for most document/DTD combinations. If one of the key reasons for well-formed, DTD-less XML is to make things easier for the perl hacker or whatever, I would think that putting restrictions on where whitespace could go would make things even easier for such script writers. > 2. you can't test well-formedness without looking at a DTD True, but as an author (person or tool), you can *guarantee* (though not test for) well-formedness without a DTD. You don't insert any whitespace you don't want to be significant. To satisfy line length requirements, you introduce REs (as you deem necessary) only after start tags or before end tags. > > 3. All non-markup bytes are signicant, whitespace or not (Durand) > > Pro: Everyone can understand the rules, it's easy to implement > Con: You lose certain Hytime addressing facilities, and the application > gets no help from the XML processor in ignoring WS that to the user > is "obviously" irrelevant. Does this mean that SGML tools will necessarily lose XML-significant whitespace when reading XML, or did we come up with an SGML trick to avoid this? > > 4. Use an mechanism *in the instance* to signal a DTD-less application > what's going on. > > 4.1 The PI-based DTD summary (Sperberg-McQueen) > 4.2 Explicit quoting of significant character data (Goldfarb) > 4.3 -XML-SPACE > 4.3.1 -XML-SPACE with one value, PRESERVE (Paoli) > 4.3.2 -XML-SPACE with two values, PRESERVE/COLLAPSE (Current ERB) > 4.3.3 -XML-SPACE with three values, PRESERVE/COLLAPSE/SUPPRESS (Bray) > [which we might want to rename, if what we're really doing is > signalling element content, mixed content, and verbatim content] > 4.4 Escaping of non-significant WS (Prescod) > > Pro: Solves the problems > Con: Requires extra work from authors, possibly duplicates DTD info with > potential for loss of sync, and tends to look ugly & unnatural When I compare the cons for 4 versus the cons for 2 (sure, I'm biased), I think--even without an XML savvy tool--4 requires more work for the author and more explanation for us, the spec writers, than 2. In addition, 4 has "possibly duplicates DTD info with potential for loss of sync, and tends to look ugly & unnatural." I guess you have to decide for yourself which is uglier and more unnatural: not being able to indent/pretty-print your source sgml or having -XML-SPACE attributes throughout your source sgml. Date: Tue, 17 Dec 1996 16:45:28 -0500 To: w3c-sgml-wg@w3.org From: Paul Prescod Subject: Blended Proposal I think that the following proposal is a compromise, but a reasonable one. It is a blend of existing proposals. It puts the ultimate whitespace responsibility in the author's court without forcing them to use huge, verbose attributes, or extra markup in the "common cases" of mixed content and element-content with-no-whitespace. --- I propose that we make significant whitespace the default, as per the Grosso, Delenda Est, etc. proposals, and provide a *simple*, *concise* mechanism for indicating that insignificant whitespace is being inserted (a variation on Paoli). This is different from my previous proposal where I required the curly braces to follow the content model of the DTD. Example: {

Foo

Bar

Baz

}
A non-validating XML parser would have to strip out the whitespace before handing the data to an application. Note that the UITEMs can have either mixed or element content, so the tag delimiters are not tied to the content models of the DTD. If you try to introduce whitespace in an element-content node, a validator should tell you that you must change the instance to either remove the whitespace or hide it with curly braces. Tools to validate adherence to my new proposal could not be written on top of SGML parsers unless the SGML parser returns "SSEP" nodes (most current ones probably do not). But they could be written. Parsers also have to be changed to check the stupid-net-trick for empty tags. --- The following special case can be removed if people do not think that changing from element-content to mixed-content should require special support. As David (I think) pointed out earlier, sometimes you want to change from element content to mixed content. I rebutted that this would change the meaning of your document and should not be done lightly (in either existing SGML, or XML as I proposed it). In my new proposal, both concerns are addressed: Although authors would never do this (nor need to know about it), it would be legal to put the curly braces around mixed content elements *as long as that content had no non-whitespace data characters*. Both kinds of XML parsers would remove these whitespace nodes. This is extra work for SGML-based parsers but not for new XML-based parsers. This is a concession to make it easier for people who change DTDs, not for authors. The point of this is that shifting from element content to mixed content isn't a problem until you want to *modify* the element's content (to add non-whitespace data). If you forget to change the "whitespace mode indicator" in the instance, you will get a well-formedness error: "Element using curly braces may not have data content." This will happen *very rarely* and is certainly no harder to figure out than the average SGML error message. It is obviously legal to use the traditional angle brackets around element-content elements if they contain no whitespace, and illegal if they do not. (as described above) Paul Prescod Date: Tue, 17 Dec 1996 16:53:38 -0500 To: paul@arbortext.com (Paul Grosso), w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: Trying to sum up a bit At 03:07 PM 12/17/96 CST, Paul Grosso wrote: >> 3. All non-markup bytes are signicant, whitespace or not (Durand) >> >> Pro: Everyone can understand the rules, it's easy to implement >> Con: You lose certain Hytime addressing facilities, and the application >> gets no help from the XML processor in ignoring WS that to the user >> is "obviously" irrelevant. > >Does this mean that SGML tools will necessarily lose XML-significant >whitespace when reading XML, or did we come up with an SGML trick >to avoid this? That's what Tim means when he says that "certain Hytime addressing facilities" breaks. Any tool that depends on having the same parse tree breaks. Right now that is HyTime, DSSSL, SDQL, TEI Locators and other addressing and stylesheet syntaxes. In the future, who knows? -- List of Principles This list of principles is presented in descending order of priority. We currently regard items #1 through #4 as "non-negotiable", required characteristics of any successful XML design. 3. XML shall be compatible with SGML. 1.Existing SGML tools will be able to read and write XML data. 2.XML instances are SGML documents as they are, without changes to the instance. 3.For any XML document, a DTD can be generated such that SGML will produce "the same parse" as would an XML processor. 4.XML should have essentially the same expressive power as SGML. Note: ... #3 and #4 indicate our intentions accurately, but it is not yet clear how best to formalize and explain the phrase "the same parse", or the phrase "essentially the same expressive power". These remain open questions; see point 8 also. --- I think that the HyTime TC (and DSSSL) formalize the concept of the "same parse", and proposal 3 breaks that compatibility. Paul Prescod Date: Tue, 17 Dec 1996 13:55:01 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: Trying to sum up a bit At 03:07 PM 12/17/96 CST, Paul Grosso wrote: >> 3. All non-markup bytes are signicant, whitespace or not (Durand) > >Does this mean that SGML tools will necessarily lose XML-significant >whitespace when reading XML, or did we come up with an SGML trick >to avoid this? Yes, there is the technique Charles thought up. But WG8 may choose to recognize this as a behavior that it would be well to bless in a TC, eliminating the need. - Tim Date: Tue, 17 Dec 1996 13:54:59 -0800 To: w3c-sgml-wg@w3.org From: Tim Bray Subject: Re: Trying to sum up a bit At 04:04 PM 12/17/96 -0500, Paul Prescod wrote: >Do we have anything to move forward *on*? Isn't the WG going to give us some >starting document or starting point for hyperlinking discussion? Or just >jump right in? The ERB has been largely tied up with (1) WG8 liaison to try to patch up some of our "for compaitibility" blemishes, (2) PUBLIC identifiers, and (3) RS/RE. I think we can now put these to bed; we will kick-start the hypertext discussion the same way we did base-XML, with a list of design goals, and a bunch of debating points. >What does an -XML-PRESERVE element do when applied to element content? Give >a different parse tree for DTD-less parsers? Trigger an error in validating >parsers? Both? Neither? An error for validating parsers, I'd say. Good point. >Isn't significant whitespace the norm rather than the exception? Shouldn't >it be the default? A religious issue. For web-heads, COLLAPSE is clearly the norm. But there should be a default. >> 4.3a1. the XML processor does what -XML-SPACE says... >> 4.3a2. the XML processor does what -XML-SPACE says *and* passes it on ... >> 4.3a3. the XML processor merely passes -XML-SPACE along to the application.. >Why not just let the parser do it, if it knows what needs to be done? 1. Most apps do it anyhow. 2. Less is more. 3. If you leave stuff in, the application can always take it out. But if you take it out, the app can never recreate the knowledge of where it was. - Tim Date: Tue, 17 Dec 1996 17:17:48 -0500 To: w3c-sgml-wg@w3.org From: Paul Prescod Subject: Re: Trying to sum up a bit At 01:55 PM 12/17/96 -0800, Tim Bray wrote: >At 03:07 PM 12/17/96 CST, Paul Grosso wrote: >>> 3. All non-markup bytes are signicant, whitespace or not (Durand) >> Pro: Everyone can understand the rules, it's easy to implement >> Con: You lose certain Hytime addressing facilities, and the application >> gets no help from the XML processor in ignoring WS that to the user ?? is "obviously" irrelevant. >> >>Does this mean that SGML tools will necessarily lose XML-significant >>whitespace when reading XML, or did we come up with an SGML trick >>to avoid this? > >Yes, there is the technique Charles thought up. But WG8 may choose to >recognize this as a behavior that it would be well to bless in a TC, >eliminating the need. Huh? I thought that Charles' trick was a way of mapping RS/RE to SEPCHAR, not of handling whitespace in element content. Now I'm totally confused. Are you saying that proposal 3 is that we should map all of the characters out of the set of SEPCHARs? How does this break HyTime then? Or is proposal 3 "when parsing without a DTD treat all whitespace as significant" and live with the fact that the parse tree is SGML incompatible. That doesn't break HyTime, but it throws away any kind of whitespace pretty printing. Paul Prescod Date: Tue, 17 Dec 1996 17:24:15 -0400 To: Tim Bray From: murray@spyglass.com (Murray Altheim) Subject: Re: Trying to sum up a bit Cc: w3c-sgml-wg@w3.org Tim Bray writes: [...] >3. All non-markup bytes are signicant, whitespace or not (Durand) > >Pro: Everyone can understand the rules, it's easy to implement ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Con: You lose certain Hytime addressing facilities, and the application > gets no help from the XML processor in ignoring WS that to the user > is "obviously" irrelevant. > >4. Use an mechanism *in the instance* to signal a DTD-less application > what's going on. > > 4.1 The PI-based DTD summary (Sperberg-McQueen) > 4.2 Explicit quoting of significant character data (Goldfarb) > 4.3 -XML-SPACE [...] >Face facts, folk. There is just not a solution that is going to solve >this problem and be free of some cost. And please remember the cost >of explanation and education is very real. For myself, my preference >would be (in descending order) #3, #4.3.3 (a3/b2), 4.3.2, 4.3.1. I've on several occasions written up responses to this thread, only to be pre-answered and re-confused by further discussions/questions. When you talk of the cost of explanation and education, you must also mention the cost of messy solutions (from an end-user perspective). I would hope we would avoid messy solutions AT ALL COSTS. The public view of XML will have a lot to do with how many messy solutions we create in the specification. Every instance of things like as a learning requirement on document authors is going to hurt the perception of XML as a solid specification, free of hacks, and relatively simple to learn and use. I don't even like the opening PI much, to be frank. If option #3 only causes problems with 'certain HyTime addressing facilities', then it seems that someone should concentrate on coming up with a solution for HyTime, not XML. I wouldn't assume too many users coming up from HTML or learning XML as an 'onramp to SGML' are going to be impacted much by difficulties with HyTime addressing facilities. If Jon is willing to admit to ignorance, I'll surely admit to plenty 'o ignorance. I don't even know what a HyTime addressing facility is, and I would hope I wouldn't need to know one from a Semantic Specific Result Instance, a Conceptual Output Instance, a Generic Language Translation Process Specification, a Formatting Output Specification Instance, or any other string longer than thirty characters. You won't find XML on any shelves if so. If someone needs this level of complexity, then, as we mention in the XML Q&A sheet, then don't use XML, use full-bore SGML. Based on my abhorrence of custom strings and excessive complexity, isn't there some way (if the cons of #3 are accurately stated) that we simply use some simple rules: >3. All non-markup bytes are signicant, whitespace or not (Durand) This is true only for the 'pGrove' (ala Kimber below)? In processing the pGrove, we make some assumptions about authors' intentions. Further processing is based on these assumptions: a. whitespace within an element is significant to that element* b. whitespace between elements is not significant c. whitespace after a start tag is eliminated (ie., not significant) d. whitespace preceding the end tag is normalized to a single space *Associated with item (a) is the fact that sans DTD, no document author can expect all whitespace to be significant in content, eg., one couldn't expect an XML UA to know about
 in HTXML without either a DTD or a
stylesheet to provide that information, preferably a stylesheet. Then,
maybe we could require

   SDAFORM  CDATA  #FIXED "Lit"

on all element content with significant whitespace and be done with it. :-)

I must reinforce Jon's assertion that when discussing child nodes of a
parse tree, most of us ignorant folks aren't going to be thinking of a
linefeed as the third element of an ancestor.

I'm with you Tim on #3 as a first choice. The other solutions seem to
clutter up the requirements on what is intended to be a simple spec.

Murray

```````````````````````````````````````````````````````````````````````````````
    Murray Altheim, Program Manager
    Spyglass, Inc., Cambridge, Massachusetts
    email: 
    http:  
           "Give a monkey the tools and he'll eventually build a typewriter."




                3245 146th Place S.E., Suite 270, Bellevue, WA 98007, USA
Date: Tue, 17 Dec 1996 14:34:25 -0800
To: w3c-sgml-wg@w3.org
From: Derek Denny-Brown 
Subject: Re: Trying to sum up a bit

At 01:54 PM 12/17/96 -0800, Tim Bray wrote:
>>Isn't significant whitespace the norm rather than the exception? Shouldn't
>>it be the default?
>
>A religious issue.  For web-heads, COLLAPSE is clearly the norm.  But
>there should be a default.

I like the idea of having some mechanism to declare defaulting behavior.
such a mechanism is redundant if the DTD is present, but it does make the
instance much easier to author.  On the other hand, it might lead to
confusion if the mechanism is too complicated.

>>> 4.3a1. the XML processor does what -XML-SPACE says...
>>> 4.3a2. the XML processor does what -XML-SPACE says *and* passes it on ...
>>> 4.3a3. the XML processor merely passes -XML-SPACE along to the application..
>
>>Why not just let the parser do it, if it knows what needs to be done?
>
>1. Most apps do it anyhow.  2. Less is more.  3. If you leave stuff in, the 
>application can always take it out.  But if you take it out, the app
>can never recreate the knowledge of where it was. - Tim

But there can be a difference between what the XML spec says is significant
and what a parser hands to the application.  Witness SP.  I do not think we
need declare what the parser returns, this is should not be an API
discussion group.  We sould declare what is _signicant_.  If a parser does
not pass along insignificant data when the application desires it, that is a
problem with the parser, and the application should use a different parser.
The point of theis discussion is to say that the whitespace is not
significant.. thus the application should only get it if it needs to.  Don't
burden the application, burden the parser, in those cases where the
application demands it.

-derek
"that which is not slightly distorted lacks sensible appeal: from which it
follows
 that irregularity - that is to say, the unexpected, surprise, and astonishment,
    are an essential part and characteristic of beauty" - Charles Baudelaire



Date: Tue, 17 Dec 1996 17:47:28 -0500
To: murray@spyglass.com (Murray Altheim), Tim Bray 
From: Paul Prescod 
Subject: Re: Trying to sum up a bit
Cc: w3c-sgml-wg@w3.org

At 05:24 PM 12/17/96 -0400, Murray Altheim wrote:
>I would hope we would avoid messy solutions AT ALL COSTS. The public view
>of XML will have a lot to do with how many messy solutions we create in the
>specification. Every instance of things like
>
>  
>
>as a learning requirement on document authors is going to hurt the
>perception of XML as a solid specification, free of hacks, and relatively
>simple to learn and use. I don't even like the opening PI much, to be
>frank. If option #3 only causes problems with 'certain HyTime addressing
>facilities', then it seems that someone should concentrate on coming up
>with a solution for HyTime, not XML. I wouldn't assume too many users
>coming up from HTML or learning XML as an 'onramp to SGML' are going to be
>impacted much by difficulties with HyTime addressing facilities.

As Eliot pointed out, HyTime is taking the rap for *all* addressing schemes
including the addressing schemes used in *all* style sheet languages. I
don't think it is esoteric to want to put a bullet on the first node in a
list item (and not others). I've had trouble with style sheet languages that
made that difficult or impossible before. Or to want every other node in a
list to have a dark background.

>If Jon is willing to admit to ignorance, I'll surely admit to plenty 'o
>ignorance. I don't even know what a HyTime addressing facility is, and I
>would hope I wouldn't need to know one from a Semantic Specific Result
>Instance, a Conceptual Output Instance, a Generic Language Translation
>Process Specification, a Formatting Output Specification Instance, or any
>other string longer than thirty characters. You won't find XML on any
>shelves if so. If someone needs this level of complexity, then, as we
>mention in the XML Q&A sheet, then don't use XML, use full-bore SGML.

Isn't XML supposed to be compatible with SGML? When an author decides to
start using his/her XML file as if it were "full" SGML, should they have to
rewrite scripts, stylesheets and hyperlinks? Just because of whitespace? The
fundamental question is whether the interpretation of the documents should
be different according to SGML parsers vs. non-validating parsers.

>>3. All non-markup bytes are signicant, whitespace or not (Durand)
>
>This is true only for the 'pGrove' (ala Kimber below)? In processing the
>pGrove, we make some assumptions about authors' intentions. Further
>processing is based on these assumptions:
>
>   a. whitespace within an element is significant to that element*
>   b. whitespace between elements is not significant

You can't do that. => You can'tdo that.

>   c. whitespace after a start tag is eliminated (ie., not significant)
>   d. whitespace preceding the end tag is normalized to a single space

I think that the other rules are okay, but the case of whitespace between
elements is common both in mixed and element content and authors mean
different things by it depending on the context.

>I must reinforce Jon's assertion that when discussing child nodes of a
>parse tree, most of us ignorant folks aren't going to be thinking of a
>linefeed as the third element of an ancestor.

Which is why we've got to get of that linefeed out of the parse tree. Rule
#3 puts it *in* the parse tree.

 Paul Prescod



From: "Christopher R. Maden" 
Date: Tue, 17 Dec 1996 22:46:38 GMT
To: w3c-sgml-wg@w3.org
Subject: Re: Trying to sum up a bit

[Tim Bray]

> Yes, there is the technique Charles thought up.  But WG8 may choose
> to recognize this as a behavior that it would be well to bless in a
> TC, eliminating the need.

That trick doesn't help.  The random character to which &#RE; is
mapped is still assigned to the SEPCHAR role, and so is eaten in
element content.

-Chris
-- 

http://www.ebt.com +1.401.421.9550 +1.401.521.2030
One Richmond Square, Providence, RI 02906 USA" NDATA SGML.Geek>



From: "Christopher R. Maden" 
Date: Tue, 17 Dec 1996 22:45:12 GMT
To: w3c-sgml-wg@w3.org
Subject: Re: Blended Proposal

[Paul Prescod]

> {
>     

Foo

>

Bar

>

Baz

> }
I don't think this can be made valid SGML. It appears to require to tag closing sequences and two tag end-tag opening sequences. With NET already used, only TAGC is left for closing a tag, and it can only be defined as one thing. The only end-tag opener is ETAGO, so that's not doable either. It's a nice idea, but I don't think it can be done. -Chris -- http://www.ebt.com +1.401.421.9550 +1.401.521.2030 One Richmond Square, Providence, RI 02906 USA" NDATA SGML.Geek> From: "Christopher R. Maden" Date: Tue, 17 Dec 1996 23:54:45 GMT To: w3c-sgml-wg@w3.org Subject: Re: Blended Proposal [Paul Prescod] > { >

Foo

>

Bar

>

Baz

> }
[Chris Maden] > I don't think this can be made valid SGML. It appears to require to > tag closing sequences and two tag end-tag opening sequences. With > NET already used, only TAGC is left for closing a tag, and it can > only be defined as one thing. The only end-tag opener is ETAGO, so > that's not doable either. [Paul Prescod] > I we have to do is make the "{" disappear. If it can't be done by > making it part of the end tag, it could be done by changing the > string to "{{" and making it a short reference that maps to > whitespace (or perhaps to a PI that the application can use to > verify that the construct is being properly used). I'll buy that. I hate shortrefs, but it does work. Question is, is it worth it? Are these delimiters the best way to go? I'm neutral on this now - what do others think? -Chris Date: Tue, 17 Dec 1996 21:06:54 -0500 From: gtn@ebt.com (Gavin Nicol) To: bosak@atlantic-83.eng.sun.com CC: w3c-sgml-wg@www10.w3.org, bosak@atlantic-83.eng.sun.com Subject: Re: RS/RE, again (sorry) >Allow me to wallow in ignorance a bit further. I'm finding it hard to >visualize a situation in which I would want to address something based >on pseudo-element relationships rather than "genuine" tree >relationships. It's easy to imagine cases where I would want to refer >to the TITLE descendant of my ancestor CHAPTER, for example, but I >have never wanted to refer to the third linefeed in an element. I'm >not saying that such situations are inconceivable, I'm just saying >that I've never encountered one. Is this one of those cases where 90 >percent of the complexity we're worrying about is being caused by a >feature that in practice is used .001 percent of the time? Such hyperlinking could be useful in solving a difficult problem: alignment in multilingual texts. That said, I still feel that 1) We are the "Masters of the XML Grove Plans (tm)", 2) There are no DSSSL or HyTime systems based on XML that have a lagre user base yet, 3) No matter what we do, many *existing* SGML systems will not be able to parse XML instances without (relatively minor) changes to said systems, and that 4) we really do desire parse results to be the same, independent of whether we have a DTD or not, that having all whitespace be significant still seems a reasonable way to go. I can live with -XML-???? attributes as a standardised application hinting mechanism, but feel it's not really necessary, and that authors should never *assume* that it will always have the desired effect. Date: Tue, 17 Dec 1996 21:17:36 -0500 To: w3c-sgml-wg@www10.w3.org From: Paul Prescod Subject: Re: Mixed vs. element content (Was Re: RS/RE, again (sorry)) At 08:45 PM 12/17/96 -0500, Gavin Nicol wrote: >I wonder how HyTime can break when used with XML when there is no >current practise in the field? Same for DSSSL, or whatever other >processor you have. Since XML is SGML (theoretically) we do have current practise. >So far, we have been trying like mad to make XML a pure subset of >SGML, to the extent of using hairy features of SGML to get it to >do what we want. To me, this means that unless *all* SGML systems >we care aboput are capable of supporting the features that XML >requires, the issue of whitespace-handling conformance is a non-issue, >as you're going to have to preprocess an XML document to get it >through your SGML system anyway. SGML systems can be updated. It is better that they be updated to support optional SGML features than proprietary W3C-XML features. >Why can't you have the preprocessor perform whitespace normalisation as well? Because SGML has the whitespace handling behaviour that we want (other than RS/RE). It allows insignificant whitespace in places where it is obvious to author and parser that they could not be data. It would make no sense for us to convert from a system that is less text-editor-friendly to a system that is more. If any conversion is involved it should be downconversion from SGML, using its reasonable whitespace handling rules (barring RS/RE) to XML (as was originally envisioned by many participants). Anyhow, we can all get what we want. If we use a simple syntax for triggering whitespace removal, then those who think that All Whitespace Should Be Significant can just choose not to ever use that syntax. Parser writers still have to implement it, but it would be fairly trivial. Paul Prescod Date: Tue, 17 Dec 1996 21:14:44 -0500 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@www10.w3.org Subject: Re: Trying to sum up a bit >3. All non-markup bytes are signicant, whitespace or not (Durand) Durand/Nicol/Maden >Pro: Everyone can understand the rules, it's easy to implement >Con: You lose certain Hytime addressing facilities, and the application > gets no help from the XML processor in ignoring WS that to the user > is "obviously" irrelevant. You don't "lose" them, because you don;t have them in XML yet anyway!! Date: Tue, 17 Dec 1996 21:20:47 -0500 From: gtn@ebt.com (Gavin Nicol) To: ddb@criinc.com CC: w3c-sgml-wg@www10.w3.org, bosak@atlantic-83.eng.sun.com Subject: Re: RS/RE, again (sorry) > -+-- #PCDATA "\n" > | > +-- > | > +-- #PCDATA "\n" > | > +-- > | > +-- #PCDATA "\n" > > >The (obvious) problem arises when you ask for the 2nd child of the >element. The first parse will give you the second sub-element, >while the second parse will give you a pseudo-element containing only a "\n". > >Without some way to indicate that this should be treated as element content, >this could easily become a real mess. I disagree. If you are asking for "element number two", you are using one of the most fragile forms of hyperlink anyway: one that is very much dependent on the *exact* structure/parser characteristics of the system. Such links are very useful in some situations, but if people are *really* worried about this problem, they shouldn't use them. Then again, given that we can define what actually appears within the grove in XML, such hyperlinks in XML will be "correct" anyway (ie. the second element *should* be the psuedo-element). Date: Tue, 17 Dec 1996 21:26:37 -0500 To: w3c-sgml-wg@www10.w3.org From: Paul Prescod Subject: Re: RS/RE, again (sorry) At 09:06 PM 12/17/96 -0500, Gavin Nicol wrote: >that having all whitespace be significant still seems a reasonable way to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >go. Can you please describe *exactly* what that means? At some points in this discussion it seems to mean that whitespace is treated *exactly* like data content (say "foo") with regards to validating XML parsers. So this: is going to trigger an error (if LIST allows only items, no #PCDATA) just as surely as this: foobarbazblam! At other points, there has been discussion of having a DTD-reading "filter" remove the whitespace. Which seems to imply that the former would be *valid* as long as the filter is applied before the validation takes place. In this case, the grove which is being validated is different from the grove that a DTD-less parser would use. What exactly do you mean by "all whitespace significant?" The former or the latter or something else? Paul Prescod Date: Tue, 17 Dec 1996 23:11:27 -0500 From: gtn@ebt.com (Gavin Nicol) To: papresco@calum.csclub.uwaterloo.ca CC: murray@spyglass.com, tbray@textuality.com, w3c-sgml-wg@www10.w3.org Subject: Re: Trying to sum up a bit >Isn't XML supposed to be compatible with SGML? If you can define "compatible with SGML" given the syntactical variance caused by the use of various features, we might be somewhere further along. My real point is that we are *already* invoking features that are not altogether widely supported in order to make the syntax of XML slightly more pleasant. Different whitespace handling is just one more... Date: Tue, 17 Dec 1996 23:38:39 -0500 From: gtn@ebt.com (Gavin Nicol) To: papresco@calum.csclub.uwaterloo.ca CC: w3c-sgml-wg@www10.w3.org Subject: Re: Mixed vs. element content (Was Re: RS/RE, again (sorry)) >>I wonder how HyTime can break when used with XML when there is no >>current practise in the field? Same for DSSSL, or whatever other >>processor you have. > >Since XML is SGML (theoretically) we do have current practise. If you can define "SGML", I might agree with you. Fact is, that SGML is a large number of incompatible languages anyway. If you can define "SGML", then please look to see if XML is "SGML" as you define it. >SGML systems can be updated. It is better that they be updated to support >optional SGML features than proprietary W3C-XML features. The point is that we are only using SGML features... >>Why can't you have the preprocessor perform whitespace normalisation >as well? > >Because SGML has the whitespace handling behaviour that we want (other than >RS/RE). Really? Even in the face of *all* the tricks one could pull with an SGML declaration? Date: Wed, 18 Dec 1996 00:04:16 -0500 From: gtn@ebt.com (Gavin Nicol) To: papresco@calum.csclub.uwaterloo.ca CC: w3c-sgml-wg@www10.w3.org Subject: Re: RS/RE, again (sorry) >>that having all whitespace be significant still seems a reasonable >>way to go. > >Can you please describe *exactly* what that means? .... > >At other points, there has been discussion of having a DTD-reading "filter" >remove the whitespace. Which seems to imply that the former would be *valid* >as long as the filter is applied before the validation takes place. In this >case, the grove which is being validated is different from the grove that a >DTD-less parser would use. I repeat my viewpoint: 1) The *parser* does not use a DTD, and so creates a pGrove (to use Elliot's term) in which *all* non-markup charaters occur (lot's of psuedo-elements). [pGrove -> pGrove] 2) For pure XML *validators* of the pGrove, the following: foo would cause an error if LIST couldn't contain #PCDATA. [pGrove -> validator] 3) For XML *validators* of the pGrove that are built to support legacy SGML systems, the following: foo would not cause an error (ie. "normal" SGML behaviour because they would perform some transformation of the pGrove). [pGrove -> validator -> epGrove]. I expect to see most new applications built around (1), and many others to use (3) to obtain the semantics they desire. A "parser" is something that tokenises the stream, and checks only the syntactic constraints imposed by the XML grammar. A "validator" is something that takes a pGrove, and checks that it comforms to the constraints imposed by the grammar as defined by a DTD. Date: Tue, 17 Dec 1996 18:24:43 -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: RS/RE, again (sorry) [Chris Maden, summarizing a number of replies to my question:] | TEI and, I believe, HyQ, use sibling relationships for addressing; | e.g., start at the element whose SGML ID is "foo" and traverse three | nodes to the right. | | If DTD-less parsing creates spurious CDATA nodes, then the target of | an address can be different from that for a DTD-ful parse. What this seems to add up to is that treeloc uses a different way of thinking about what a sibling is than I do. Frankly, I like my way better. I can see where defining pseudo-elements as nodes could be useful in addressing arbitrary spans of text, but if the price for resolving our problem is that the only elements that I can address in XML are the real ones, then that is a price I would be willing to pay. Jon From: Paul Prescod Subject: Re: RS/RE, again (sorry) To: gtn@ebt.com (Gavin Nicol) Date: Wed, 18 Dec 1996 08:34:08 -0500 (EST) Cc: w3c-sgml-wg@www10.w3.org It's becoming a little clearer. I'm starting to wonder if we're talking apples and oranges. Your proposal seems to define an application architecture (what components say what to what). But I don't understand how that translates into a *language* (what is valid, invalid, and what constructs mean). But in XML and SGML, the concept of "what is the parse" and "what is the validator" are not as interesting to users as "what is the parser going to return to the application" and "what is the validator going to report as correct." So separating the "parser" and the "validator" is only interesting to CS types. Although on other days I would find that fascinating, today I only care about the language. What do you want the specification to say about a "valid" XML document? That it has a different definition in different situations, depending on your legacy needs? That whitespace is allowed in #PCDATA content, or not? What do you want the specification to say about what the parser returns to the application? The same thing? Depends on what you want? Let the tools figure it out? Thanks for furthering my education... Paul Prescod Gavin said: > >>that having all whitespace be significant still seems a reasonable > >>way to go. > > > >Can you please describe *exactly* what that means? > .... > > > >At other points, there has been discussion of having a DTD-reading "filter" > >remove the whitespace. Which seems to imply that the former would be *valid* > >as long as the filter is applied before the validation takes place. In this > >case, the grove which is being validated is different from the grove that a > >DTD-less parser would use. > > I repeat my viewpoint: > > 1) The *parser* does not use a DTD, and so creates a pGrove (to use > Elliot's term) in which *all* non-markup charaters occur (lot's > of psuedo-elements). > [pGrove -> pGrove] > 2) For pure XML *validators* of the pGrove, the following: > > > foo > > > would cause an error if LIST couldn't contain #PCDATA. > [pGrove -> validator] > 3) For XML *validators* of the pGrove that are built to support > legacy SGML systems, the following: > > > foo > > > would not cause an error (ie. "normal" SGML behaviour because > they would perform some transformation of the pGrove). > [pGrove -> validator -> epGrove]. > > I expect to see most new applications built around (1), and many > others to use (3) to obtain the semantics they desire. > > A "parser" is something that tokenises the stream, and checks only > the syntactic constraints imposed by the XML grammar. > > A "validator" is something that takes a pGrove, and checks that it > comforms to the constraints imposed by the grammar as defined by a > DTD. Date: Wed, 18 Dec 1996 07:46:13 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: RS/RE, again (sorry) At 06:24 PM 12/17/96 -0800, Jon Bosak wrote: >[Chris Maden, summarizing a number of replies to my question:] > >| TEI and, I believe, HyQ, use sibling relationships for addressing; >| e.g., start at the element whose SGML ID is "foo" and traverse three >| nodes to the right. >| >| If DTD-less parsing creates spurious CDATA nodes, then the target of >| an address can be different from that for a DTD-ful parse. > >What this seems to add up to is that treeloc uses a different way of >thinking about what a sibling is than I do. How do you think of "sibling" that doesn't include the data characters in mixed content? Note that the SGML property set makes either every data character node (or other node type that can occur in the content of an element) or contiguous lists of data character nodes children of elements along with elements. There is no way to exclude data from the content tree without excluding those nodes completely from the grove. Having said that, it's certainly possible to define a query that ignores data nodes and only looks at element nodes in the content tree. E.g., in SDQL: ;; Function to address only subelements the element content tree: (define subelement-treeloc treepos (; function definition goes here--no idea how to do it off the top ; of my head. I guess you'd have a function that calculates the ; the subelement number of each subelement and recurses down each ; level of the tree by matching child numbers in the treepos ; specification, returning when it runs out of treepos values or ; fails to find a node. )) I'm sure there's the equivalent for TEI locators. (It would, I think, be an interesting exercise to define the SDQL functions that would implement the TEI locator syntax--hmmm, a person could learn both in one go with that exercise....) It would be possible for XML to define its own property set distinct from the SGML property set and define all XML processing in terms of that property set. However, that would *seriously* undermine the claim that XML is SGML as they would now have fundamentally different data models. I wouldn't recommend 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: Wed, 18 Dec 1996 10:01:23 -0500 From: gtn@ebt.com (Gavin Nicol) To: papresco@calum.csclub.uwaterloo.ca CC: w3c-sgml-wg@www10.w3.org Subject: Re: RS/RE, again (sorry) >It's becoming a little clearer. I'm starting to wonder if we're talking >apples and oranges. Your proposal seems to define an application >architecture (what components say what to what). But I don't understand >how that translates into a *language* (what is valid, invalid, and what >constructs mean). Very simple. The XML *language* as I look at it, is completely seperate from the language defined in a DTD. In other words, I am concerned primarily with the meta-language language definition, while you are primairly concerned with the language defined *using* the meta-language, which I leave to the "validator". >But in XML and SGML, the concept of "what is the parse" and "what is the >validator" are not as interesting to users as "what is the parser going to >return to the application" and "what is the validator going to report as >correct." So separating the "parser" and the "validator" is only interesting >to CS types. Although on other days I would find that fascinating, today I >only care about the language. This is very important for creating a clear language definition. I think users care about that. FYI. I am not a "CS type", but rather a "sociologist type"... I am concerned about rigourous definition only in so far as it affects the overall usability/dependability to the language. From: "Christopher R. Maden" Date: Wed, 18 Dec 1996 15:05:38 GMT To: w3c-sgml-wg@www10.w3.org Subject: Re: Trying to sum up a bit [Tim Bray] > 3. All non-markup bytes are signicant, whitespace or not (Durand) [Gavin Nicol] > Durand/Nicol/Maden Not any more, I'm afraid. If whitespace is data, there can be no element content, and if it's SEPCHAR, then it'll be eaten by a conforming parser. I think this issue needs to be put on hold until hyperlinking mechanisms have been defined. If the specified mechanisms don't change based on whitespace, this is irrelevant. However, I have a strong suspicion that any application with hyperlinking capabilities will need to read the DTD. -Chris -- http://www.ebt.com +1.401.421.9550 +1.401.521.2030 One Richmond Square, Providence, RI 02906 USA" NDATA SGML.Geek> From: Paul Prescod Subject: Re: RS/RE, again (sorry) To: gtn@ebt.com (Gavin Nicol) Date: Wed, 18 Dec 1996 11:36:25 -0500 (EST) Cc: w3c-sgml-wg@www10.w3.org > > >It's becoming a little clearer. I'm starting to wonder if we're talking > >apples and oranges. Your proposal seems to define an application > >architecture (what components say what to what). But I don't understand > >how that translates into a *language* (what is valid, invalid, and what > >constructs mean). > > Very simple. The XML *language* as I look at it, is completely > seperate from the language defined in a DTD. In other words, I am > concerned primarily with the meta-language language definition, while > you are primairly concerned with the language defined *using* the > meta-language, which I leave to the "validator". Fine. So in your opinion, should the "validator" be part of the XML specification or not? If so, does it really matter what the "parser" returns? All the user cares about is what is valid or not. If not, then it will be entirely valid (excuse the pun) for me to make a "validator" that says that "foo" is an appropriate separator character in element content so that this: foofoo

foo

bar
barbaz
is valid in element content. Or, I could go even farther and decleare that according to my applications' "validation scheme", all content everywhere is valid. Should we specify a single standardized validation scheme or not? If we do, what do you propose it should say about whitespace? If we do not, how can we claim to be even vaguly SGML compatible? As you mentioned in your last message, SGML's validation scheme would be just one of an infinite number of equally "valid" schemes. Paul Prescod Date: Wed, 18 Dec 1996 11:59:49 -0500 From: gtn@ebt.com (Gavin Nicol) To: papresco@calum.csclub.uwaterloo.ca CC: w3c-sgml-wg@www10.w3.org Subject: Re: RS/RE, again (sorry) >Fine. So in your opinion, should the "validator" be part of the XML >specification or not? Not part of the *language* specification. I do think we need pGroves and validator behaviour defined though. >If so, does it really matter what the "parser" returns? Yes, because it is the *foundation* of the entire application architecture. If it is not rigourously defined such that it is trivial to prove it correct, no other part of the system can be known to be correct. I like foundations of stone, not sand. >Should we specify a single standardized validation scheme or not? If we do, >what do you propose it should say about whitespace? If we do not, how can we >claim to be even vaguly SGML compatible? As you mentioned in your last >message, SGML's validation scheme would be just one of an infinite number >of equally "valid" schemes. I propose two: a "pure" XML validator, which does no transformation, of pGroves and another "SGML" validator, that removes whitespace according to "normal" SGML rules. I am not against whitespace removal at the application level, but am strongly against putting such functionality into the parser for the meta-language. From: Paul Prescod Subject: Re: RS/RE, again (sorry) To: gtn@ebt.com (Gavin Nicol) Date: Wed, 18 Dec 1996 12:48:00 -0500 (EST) Cc: w3c-sgml-wg@www10.w3.org > >Fine. So in your opinion, should the "validator" be part of the XML > >specification or not? > > Not part of the *language* specification. Well, XML is a language (as well as a meta-language), so I interpret this to mean: "XML should define the syntax of markup declarations and markup, but should not specify the meaning of the markup declarations or the constraints they place on the instance markup." Is that accurate? > I do think we need pGroves and validator behaviour defined though. Could you expand on that? Do you mean that you want to define what is and isn't valid, or how to "hook in" an arbitrary validator? > >If so, does it really matter what the "parser" returns? > > Yes, because it is the *foundation* of the entire application > architecture. If it is not rigourously defined such that it > is trivial to prove it correct, no other part of the system can > be known to be correct. I like foundations of stone, not sand. I don't think that languages with parsers that are of moderate complexity are "built on foundations of sand." The proposals for whitespace elimination in XML are not brain surgery: "look out for this attribute", "look out for this character", "watch for this list of tags." > >Should we specify a single standardized validation scheme or not? If we do, > >what do you propose it should say about whitespace? If we do not, how can we > >claim to be even vaguly SGML compatible? As you mentioned in your last > >message, SGML's validation scheme would be just one of an infinite number > >of equally "valid" schemes. > > I propose two: a "pure" XML validator, which does no transformation, > of pGroves and another "SGML" validator, that removes whitespace > according to "normal" SGML rules. So a document can be valid according to the SGML validator, but invalid according to the "pure" XML validator because it has whitespace in the wrong place? And both validators are "correct?" And when the same document is parsed and filtered through these two different systems, one could give a real "RE Delenda est" behaviour (for instance a browser written from scratch) and one could remove whitespace according to SGML rules. So the behaviour of the "parser" would be absolutely dead-simple (a tokenization), but the input to the formatting process would still be up in the air as far as the user is concerned. And both systems would be correct. It also isn't clear to me from your proposal above if the two that you propose are a) actually in the XML spec, or in some other spec and b) exclusively "valid." Is my foo-sep filter equally valid? Could I write up a spec for it and have my documents be "valid XML"? Or are only the two filters you propose in the actual spec? Paul Prescod Date: Wed, 18 Dec 1996 13:38:10 -0500 From: gtn@ebt.com (Gavin Nicol) To: papresco@calum.csclub.uwaterloo.ca CC: w3c-sgml-wg@www10.w3.org Subject: Re: RS/RE, again (sorry) >> Not part of the *language* specification. > >Well, XML is a language (as well as a meta-language), so I interpret this to >mean: "XML should define the syntax of markup declarations and markup, >but should not specify the meaning of the markup declarations or the >constraints they place on the instance markup." Close, though I would also have the parser perform simple validation of the gorss tag structure (ie. make sure all end tags are present in the right place etc.) >> I do think we need pGroves and validator behaviour defined though. > >Could you expand on that? Do you mean that you want to define what is and >isn't valid, or how to "hook in" an arbitrary validator? pGroves define what the validator has to work with. Validator definition would ential specifying what tasks a validator is to perform. >I don't think that languages with parsers that are of moderate complexity >are "built on foundations of sand." The proposals for whitespace elimination >in XML are not brain surgery: "look out for this attribute", "look out for >this character", "watch for this list of tags." These are all a) not necessary, and b) imply some feedback between the parser and whatever in interpreting the parser output. >>I propose two: a "pure" XML validator, which does no transformation, >>of pGroves and another "SGML" validator, that removes whitespace >>according to "normal" SGML rules. > >So a document can be valid according to the SGML validator, but >invalid according to the "pure" XML validator because it has >whitespace in the wrong place? And both validators are "correct?" Yes. A document that is valid according to the (stricter) XML validator would also be valid in the "SGML" validator, though the opposite may not be true. >And when the same document is parsed and filtered through these two >different systems, one could give a real "RE Delenda est" behaviour (for >instance a browser written from scratch) and one could remove whitespace >according to SGML rules. So the behaviour of the "parser" would be absolutely >dead-simple (a tokenization), but the input to the formatting process would >still be up in the air as far as the user is concerned. And both systems would >be correct. No. The parser would be very simple: it would tokenise, and check the gross structural soundness of an instance. Input to the formatting process is not "up in the air" because "the formatting process" would accept a pGrove. It could then *choose* which "validator" it preferred. >It also isn't clear to me from your proposal above if the two that >you propose are a) actually in the XML spec, or in some other spec >and b) exclusively "valid." Is my foo-sep filter equally valid? Could >I write up a spec for it and have my documents be "valid XML"? Or are >only the two filters you propose in the actual spec? I would say that these two validators be defined as part of the overall XML effort. The "pure XML" validator is simple, and the "SGML validator" not much more difficult. As you note, there could be others (after all, the application gets to choose), but with these two we get: a) A parser that is truly trivial to implement b) SGML whitespace compatability for those who really, really need it (and I do not think this group will be as large as some make out). c) A well-defined foundation upon which to build new application. To: w3c-sgml-wg@www10.w3.org Subject: Element vs. mixed content (Was Re: RS/RE, again (sorry)) Date: Wed, 18 Dec 1996 11:01:46 -0800 From: Joe English [ I keep changing the Subject: line because this discussion is *not* about RS/RE, and never really was... ] bosak@atlantic-83.eng.sun.com (Jon Bosak) wrote: > I'm finding it hard to > visualize a situation in which I would want to address something based > on pseudo-element relationships rather than "genuine" tree > relationships. You probably never would do this "by hand", but your software might want to do so on your behalf. For example, suppose you're reading an XML document in a GUI browser and want to add an annotation at a specific point in the document. One way a browser might implement this is to create a HyTime location ladder pointing to the element, range of elements, or span of data that you've selected with the mouse. In this case it doesn't matter whether your browser includes or discards whitespace in element content -- treeloc and pathloc work for any grove plan -- as long as it parses the document the same way every time. You only run into a problem if you want to share your annotations with somebody else whose software uses a different grove plan (i.e., your browser discards whitespace in element content and theirs doesn't, or vice versa.) > It's easy to imagine cases where I would want to refer > to the TITLE descendant of my ancestor CHAPTER, for example, This is basically how TEI XPTRs work. In this sense they are more robust than treeloc since they will locate the same element regardless of the grove plan (assuming it includes ELEMENT nodes, of course...) > Is this one of those cases where 90 > percent of the complexity we're worrying about is being caused by a > feature that in practice is used .001 percent of the time? Quite possibly. --Joe English jenglish@crl.com Date: Wed, 18 Dec 1996 11:17:13 -0800 To: w3c-sgml-wg@www10.w3.org From: Tim Bray Subject: ERB decisions on RS/RE and whitespace On December 18, the ERB took up the question of RS/RE and whitespace. All members were present except James Clark and Eve Maler. The vote in favor of the following was unanimous. XML processors, when operating without a DTD, are required to consider all bytes that are not markup to be data and to pass them to the application. When operating with a DTD, the processor may, but is not required to, pass on to the app white space known to be insigificant because it's in element content. In the case where it passes white space on, it must also inform the app that this is element content and so cannot be significant. The XML Specification will contain an appendix which provides a set of recommendations which, if followed by authors, will ensure that they get a parse tree that will be the same whether or not the DTD is taken into consideration. We didn't discuss the exact contents of this: it will include at least [a] no white space where it might be element content and [b] no defaulted attributes; careful attention will be required from everyone on the list to make sure we get this right. The -XML-SPACE attribute will be retained, but its role becomes advisory; an XML processor will always pass the data as noted above, and must also pass the value of -XML-SPACE when specified. The allowed values of -XML-SPACE change to "PRESERVE" and "DEFAULT". Formally -XML-SPACE (PRESERVE|DEFAULT) #IMPLIED PRESERVE is a signal from the author to the application that all the whitespace bytes are to be considered significant. DEFAULT means that the application's default handling is considered OK. The attribute's value is considered to be inherited by descendent elements of an element for which it's specified. For the root element, the default is DEFAULT. It is an error, in the context of a DTD, for an element with element content to have -XML-SPACE="PRESERVE". Further discussion of these issues is unlikely to be read by anyone in their right mind. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Wed, 18 Dec 1996 15:25:22 -0800 To: Paul Prescod , w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Trying to sum up a bit At 5:17 PM 12/17/96, Paul Prescod wrote: >At 01:55 PM 12/17/96 -0800, Tim Bray wrote: >>Yes, there is the technique Charles thought up. But WG8 may choose to >>recognize this as a behavior that it would be well to bless in a TC, >>eliminating the need. > >Huh? I thought that Charles' trick was a way of mapping RS/RE to SEPCHAR, >not of handling whitespace in element content. Now I'm totally confused. Are >you saying that proposal 3 is that we should map all of the characters out >of the set of SEPCHARs? How does this break HyTime then? Yes, and that makes RE after elements significant in _all_ mixed content, and insignificant outside it. >Or is proposal 3 "when parsing without a DTD treat all whitespace as >significant" and live with the fact that the parse tree is SGML >incompatible. That doesn't break HyTime, but it throws away any kind of >whitespace pretty printing. Bingo! But -- it is compatible for mixed content (via Charles' hack). Not for element content, but that compatiblity is impossible since element content cannot be distinguished from mixed content without a DTD, in any case. And yes, it does throw out pretty-printing (or require some explicit notification from the user as to the presence of such pretty-printing. -- 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, 18 Dec 1996 15:25:38 -0800 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Another proposal, and a requirement (was Re: Trying to sum up a bit) Summary: DTDs required for hyperlinking is an absolute anti-requirement. Another whitespace proposal, but this one keeps same parse trees and no unnatural markup. It may not preserve equivalence of application behavior across DTD-containing, and DTD-omitted instances, but can allows hyperlinking and indexing and database-like applications to work properly in all cases (and these are the examples we have to work with). Formatting (oddly) is the one that gets left in the cold because signficance of WS cannot be determined without a DTD. >I think this issue needs to be put on hold until hyperlinking >mechanisms have been defined. If the specified mechanisms don't >change based on whitespace, this is irrelevant. However, I have a >strong suspicion that any application with hyperlinking capabilities >will need to read the DTD. This is _not_ acceptable for HTTP delivery. We can answer that question now, because web delivery and browsing is one of the reasons DTD optionality was put in. I don't want to read any TEI/XML documents on the web if it isn't there. And linking cannot be optional if XML is to have a prayer of success. We must be able to have a fully-function Internetscape-explorer equivalent based on XML, without required DTDs. Otherwise people will just laugh at our "solution" to their problems. At 3:05 PM 12/18/96, Christopher R. Maden wrote: >Not any more, I'm afraid. If whitespace is data, there can be no >element content, and if it's SEPCHAR, then it'll be eaten by a >conforming parser. And we will just have to learn to live with that. I already have. Since an XML parser without a DTD can't tell if something is element content, we _can't_ be SGML compatible on this issue. An idea (yes, yet another permutation): All WS is passed through. All applications will be notified of all whiotespace, but SGML-based applications will be notified that they are "insignificant to the author". The parser (or grove transformer, or whatever) aill look at the DTD, and determine that these #PCDATA nodes contain only whitespace and are in element content, so they are "insignificant". The only case that anyone has shown where this ignoration is a significant problem is in formatting, and we can define that style-sheet input never contains insignificant whitespace unless it is explicitly requested. Validating XML parsers (which have a DTD) are _required_ to check all pseudo-elements in element content, and determine that they contain only-WS characters. They are free not to format differently based on those characters, but are required to count them (same as SGML is above). This is _not_ compatible, but seems to work properly for any case I can think of. It seems that we really only need to require of XML validation that it ensure that only WS characters occur in element content (when it can tell). And of SGML-based validators, that they be aware of the presence of whitespace in element content (but they need never process it, and they can always recognize it because of the DTD). So we could, without unnatural markup, produce the same parse tree, and process it correctly. If DTD-free XML formatters start reacting badly to whitespace, people will start leaving it out (many bets are off in such cases anyway). In all cases, however, the parse tree will be the same (and include all whitespace), and in all cases, DTD-posessing applications will know what characters are significant (but are required to make insignificant characters available to applications that care (like indexers and link-engines)). -- 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, 18 Dec 1996 15:25:28 -0800 To: bosak@atlantic-83.eng.sun.com (Jon Bosak), w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: RS/RE, again (sorry) Cc: bosak@atlantic-83.eng.sun.com At 6:24 PM 12/17/96, Jon Bosak wrote: >[Chris Maden, summarizing a number of replies to my question:] > >| TEI and, I believe, HyQ, use sibling relationships for addressing; >| e.g., start at the element whose SGML ID is "foo" and traverse three >| nodes to the right. >| >| If DTD-less parsing creates spurious CDATA nodes, then the target of >| an address can be different from that for a DTD-ful parse. > >What this seems to add up to is that treeloc uses a different way of >thinking about what a sibling is than I do. Frankly, I like my way >better. I can see where defining pseudo-elements as nodes could be >useful in addressing arbitrary spans of text, but if the price for >resolving our problem is that the only elements that I can address in >XML are the real ones, then that is a price I would be willing to pay. TEI (I can't speak to the HyTime TC) gets this right in that an unlabelled number addresses Nodes (including pseudo-data nodes), but you can also index labelled elements (2nd LI in this list) and that will not break. But you do need to be able to address arbitrary characters, so the pseudo-nodes should be addressible somehow... -- 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, 18 Dec 1996 13:37:14 -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: Mixed vs. element content (Was Re: RS/RE, again (sorry)) [Joe English:] | [**] Speaking of hyperlinking, does anyone have any ideas how | this should be specified? We probably ought to start thinking | about this... That discussion begins in the next couple of days. Stay tuned. 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: Fri, 20 Dec 1996 09:13:16 +0000 To: w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: Hyperlinks: MPRDV >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. There is a vital element missing here - the ability to address part of an object that does not have an ID (or a name attribute if we are to fully meet 3.1) associated with it. If we are going, as claimed in 3.2 to "support links into read-only material" we have to presume that the objects we are pointing to have not been named in a reasonable way. Therefore we need an addressing mechanism that can identify any part of any document. URL and ID are not sufficient, either alone or in combination. I would also argue strongly for letting a single anchor role point to mutliple locations, which is not possible when you say "has multiple ends, each of which has a role". Anchor roles can type location sets, just as the ilink construct allows you to type links. Incidentally, in the HyTime TC ilinks will become a deprecated form: the extended HyLink architectural form will subsume their role and would form a better basis for this work. (More on this later, if Eliot does not beat me to it!) Martin Bryan ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Fri, 20 Dec 1996 10:45:22 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Hyperlink behavior We must have similar clocks. When I sat down this morning, I knew that wanted to post a little things on Hyperlinks for XML, and then Tim's mail was waiting when I started up! The basic list is good, though I second Martin's comment -- we should not depend on the presence of IDs in documents, if indexing of read-only material is a goal. I must, unfortunately, disclaim knowledge of the new HyTime stuff -- I've not had a chance to look at it because all my markup-related time has been taken up with XML. We need to add a level of abstraction to HyTime and ensure that the specification of behavior of links is in the style sheet, and not in the document markup. We owe it to hypertext to implement what we know about declarative markup. And that means that we need "declarative linking"; the behavior of links must be separated from their pointing functions, and the document instance. As we separate document structure (markup) and document rendering (style sheets), we must separate link structure from link behavior . Link structure essentially associates some document parts with some metadata describing their relations (linktypes, and anchor roles). Link rendering associates the relations with behaviors. For example: travel to role x, when role y is clicked, pop up a menu of possible endpoints, visit endpoints in sequence, copy destination text to this location on demand (transclude), etc. We should be as simple as possible with this link-style language. I don't know if we can get away with just adding some stuff to DSSSL. We may also need to think about Javascript in this regard (It's a sloppy job, in my experience, but the implementations are there, so we may be better off with it even given its many many flaws) -- 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, 20 Dec 1996 07:38:31 -0800 To: w3c-sgml-wg@www10.w3.org From: Tim Bray Subject: Re: Hyperlinks: MPRDV 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". Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Fri, 20 Dec 1996 11:56:40 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Hyperlinks: 5. link roles Per Tim's reasonable suggestion, I am breaking up my commentary message into topical email-bites. At 8:19 PM 12/19/96, Tim Bray wrote: > >5.2 predefined link roles equivalent to those already in wide > use on the Internet We don't have any link roles on the internet, at the moment... We could grep through opentext or altavista for REV and REL attributes, but other than that we really have only one role: "unlabelled-destination". I don't object to this requirement, but I think it is content-free given the poor infrastructure in place. 5.3 Provision for link explainers. This is a critical issue for multi-end links, and not necessarily for 2-end links. You need a way to attach explanatory text to each link end that can explain the meaning of that link-end to the user. This is different from the role, as you may still want an explanation of how a general role (like REFUTES, say) is relevant to a specifc instance of a link. This is an old-fashioned, but tremendously powerful link-preview facility for authors and readers. -- 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, 20 Dec 1996 11:56:48 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Hyperlinks: (1. Background) Per Tim's reasonable suggestion, I am breaking up my commentary message into topical email-bites. At 8:19 PM 12/19/96, Tim Bray wrote: >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. I would say that the behaviors are more determined by browser: for instance (at least some versions of) Netscape would display ftp files that contained HTML, rather than downloading. And nowadays all browsers can change their behavior based on the content-type (or extension) of the file (regardless of the protocol used to fetch it). My point is only to agree that we need an tag, but that the semantics of what it does are pretty inconsistent and should not overly constrain us. Basically browsers currently guess what was intended, since there is no link-type information at all. -- 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, 20 Dec 1996 11:56:57 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Hyperlinks: 4. link behavior (incl new: 4.3) Per Tim's reasonable suggestion, I am breaking up my commentary message into topical email-bites. At 8:19 PM 12/19/96, Tim Bray wrote: > > >4.1 mechanisms for users to identify and describe behaviors associated with > hyperlinks. Separately from documents. >4.2 predefined behaviors equivalent to those already in wide use on the Net. 4.3 Some specification of aceptable default behaviors for links. Maybe this should be prescriptive, but probably it should be permissive: The user should be offered some opportunity to access the other linked document locations somehow. -- 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, 20 Dec 1996 11:56:53 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Hyperlinks: 3.3, agree with Martin; new req. 3.4, self-revealing links. Per Tim's reasonable suggestion, I am breaking up my commentary message into topical email-bites. At 8:19 PM 12/19/96, Tim Bray wrote: > >3. Minimum Progress on Hyperlink Enhancement > >The minimum set of hyperlink constructs should: >3.3 support addressing at least by URL and ID attribute, alone or > in combination. And offset, of some sort. Martin is right about limitations of read-only documents. 3.4 It must be possible to recognize links without a DTD. I think we can do this easily. Simply specify that an document that wants to work without a DTD should use the architectural form names as element names, or use explicit attributes wherevet the AF is being used. -- 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, 20 Dec 1996 11:09:54 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Hyperlink behavior At 10:45 AM 12/20/96 -0500, David G. Durand wrote: > We need to add a level of abstraction to HyTime and ensure that the >specification of behavior of links is in the style sheet, and not in the >document markup. I heartily agree with everything David said, except for the above, at which I bristle at only because HyTime does *NOT* have any built-in facility for defining hyperlink behavior. The closest it gets are the optional traversal rules which only define constraints on *movement* between anchors or between members of multi-object anchors (what we used to call "aggregate anchors" but which are not called "list anchors"). Some of these movement options have obvious natural behaviors (a "return only" anchor could naturally be presented in a restricted modal window) but these behaviors, or in fact any behavior, are explicitly *not* implied or required by these rules. They serve only to augment the data modeling facility of hyperlinks. For example, if your purpose in creating hyperlinks is to describe the relationships among the steps in a process, part of the data model of the process may be that movement from one step to the previous step is not allowed (the application we use when discussing traversal design is a Zork- or Dungeon-type game where doors between rooms are represented by hyperlinks. Traversal rules can be used to indicate things like doors that lock behind you (return not permitted) or traps (no further traversal). By "add a level of abstraction to HyTime" I assume David means the further specialization of HyTime forms to either simplify them or add XML-specific features, both of which are the way HyTime is supposed to be used. If, on the other hand, there is a deficiency in the HyTime design such that it is insufficiently abstract, I'd like to know because there's still time to change the TC if it's not a big change. However, I sincerely doubt that HyTime could get much more abstract. The HyBrowse browser (free from www.techno.com) demonstrates very nicely the power of being able to associate behavioral and presentation styles with hyperlinks based on link types and anchor roles. I urge everyone involved in this discussion to rush out and download it (Windows only for now, I'm afraid--they're not charging enough for it to support development of other platform versions). Peter Newcomb tells me that they are in the process of integrating the current SP version into it which will, in part, make it Internet enabled. HyBrowse does not yet reflect the HyTime TC. 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, 20 Dec 1996 11:28:52 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Summary of New HyTime Features in the TC All, As a service to those of you who either don't have access to the TC still under development or who, like David, don't have the time to read it (understandably--I barely have time to both work on the TC and XML), what follows is a brief summary of the things that are new or different in HyTime as a result of the TC (not counting all the new stuff in the SGML Extended Facilities). We have gone to a great deal of effort to ensure that HyTime is as flexible as possible, in part with an eye toward how it can be applied to Internet problems. The development of the grove formalism has made HyTime much more rigorous in its definitions and, as a side effect, potentially much more inclusive that it was before with a minimum of hand waving (something Steve DeRose and David Durrand very rightly objected to in the original HyTime standard). While I'm sure that many of these new features are more than XML needs as its minimum, I wanted to show everything so you know what's there that's new and interesting. Summary of HyTime TC Changes: 1. Grove-based definitions. All HyTime addressing functions are now defined as selections of nodes in groves. This means several important things: A. HyTime location addresses can be used to address any kind of data as long as you can produce a grove for it. B. Non-HyTime addressing schemes can be integrated with HyTime by defining the node lists they select. C. All addressing operations are defined rigorously in terms of groves which are in turn defined rigorously in terms of formal property sets. Thus, if we've done our job right, there should be no ambiguitity about what a particular location address will return if you know the property set and grove plan in effect. 2. The use of queries for addressing. Queries are now meaningfully integrated with other addressing mechanisms as long as the queries return nodes in a grove. What this means in practice is that your query system must provide a grove-based API for defining the query domain and returing the results. This should not be hard in most cases, as you presumably already have a definition of the data model and need only translate it into the SGML property set formalism. This means that any non-HyTime addressing scheme can be used in HyTime by defining it's grove-based results. E.g., TEI locators and URLs become queries that return nodes in groves. TEI locators return nodes in SGML document groves (or whatever else they are designed to address, URLs return nodes that are either entity nodes (representing documents or data entities) or element nodes (named A objects) within documents. 3. The new "refloc" facility. This lets you designate attributes as semantic references with which you can then use any addressing method you want, including queries, without using indirection. All the HyTime engine cares about is that the attribute is referential, it doesn't care how the reference is made as long as it gets a node list as a result of interpreting the reference (which it would do in the case of HyTime-defined addresses or the query processor would do for non-HyTime addresses). Refloc makes it possible to directly represent things like the HTML A element without change to instances. It essentially lets you apply HyTime to almost any rational way of doing addressing from elements. If you can do clever querries, you should be able to retrofit even the most twisted markup schemes. Refloc replaces the need for the notorious "not-clink" that was in the HyTime TC design for a while. 4. Redesigned independent links: hylink The new HyLink form enhances the ilink design as follows: A. single "linkends" attribute replaced by one referential attribute for each named anchor role. This makes the markup much clearer to users and enables the use of refloc to have different addressing methods for different anchors if you want. It also lets you do things like use refloc to fix a referential attribute to a treeloc that addresses a location address in the body of link or that addresses something in the link as one of the anchors. B. Notion of "aggregate links" replaced by notion of "list anchors". The whole aggloc/agglink business on location addresses is gone (replaced by the new agglink form). List anchors are anchors that can be satisfied by more than one object. You can define traversal rules for the members of a list ("list traversal"). (Agglink lets you do semanticless aggregation if you want to.) C. Can explicitly designate any anchor as being satisfied by the link element itself (as "self anchor"). This replaces the "omitted linkend" defaulting rule of ilink. D. New and improved link traversal rules. More complete and easier to understand (I hope). Any existing ilink can be made into a HyLink by adding attributes for addressing the anchor roles ("anchor-addressing attributes") and, possibly, modifying the anchrole attribute to reflect the new keywords (specifically, #AGG replaced by #LIST, #COR replaced by #CORLIST). 5. New agglink form for representing simple aggregation. Represents the case of simply grouping a bunch of things together under a single semantic label to enable traversal among them. Agglinks can be combined with hylinks to represent arbitrarily-complex levels of grouping. For example, to represent the relationship between a mother and her children, you might have a hylink with the anchor roles "mother" and "children". The children anchor might then be satisfied by agglink elements of the types "brothers" and "sisters". These agglinks would then address as aggregates the male children and the female children. Or you could just represent the aggregation relationship "brothers" by a brothers agglink by itself--you don't have to do something silly like define anchors roles "bother1 brother2 ...". Agglink is also useful when you really don't care about the anchor roles and just want to connect a bunch of stuff together. In other words you could have an agglink called "agglink" and leave it at that. 6. Clink unchanged on the surface but now derived directly from hylink with fixed anchor roles, so it picks up all the hylink attributes like link traversal and list traversal that it never had before. 7. Implied location sources: any location address element can omit its location source, in which case it is taken to be one of three possible things: the grove root, the principle tree root in the grove (i.e., the document element in SGML documents), or the "referrer", i.e., the non-address element that refers to the location address (or to the location ladder of which the location address is the top rung). These options can be fixed for a type or selected on an instance basis. The last option, "referrer", lets you have location addresses that are dynamic in that they address relative to the thing that uses them. This lets you do things like a "next" location ladder, similar to the "next" and "previous" options in TEI locators. (Now if we could just declare elements with fixed IDs we'd be in good shape....) 8. Generalized name-space location address. With groves, the notion of name-space is well defined. This means we can now address by name in any name space, not just ID or entity name. For example, in a grove for a vector graphic format that let you put names on graphic objects (as you can do in CGM Level 4), you could address those graphic objects by name using the HyTime name-space location address. The default name space is still the element name space (the "elements" property of the SGMLDOC object in the SGML property set), so nmsploc also provides a simpler syntax for doing what you use nameloc for today, e.g.: chapter-1. 9. Location sources can be data or subdocument entities. In the above nmsploc example, the locsrc attribute is declared as ENTITY and its value is the name of a document entity (a CDATA entity with a notation of SGML or a notation derived from SGML, e.g., XML). 10. New location address form: mixedloc. Mixed loc addresses whatever the location addresses in its content address. This lets you group location addresses together within a mixedloc element and then use the lot by referring to the mixedloc. Mixedloc was invented in part to model the old nameloc, but it should be useful in its own right. 11. New location address form: queryloc. Queryloc is a location address that uses a query and returns a node list. It is through queryloc that other addressing notations can be integrated. Queryloc replaces notloc: it's simply not meaningful to use a location address that doesn't return nodes in a grove, so notloc, which was defined as doing something HyTime didn't understand, is just not meaningful in the grove new world. At a minimum, you return a data entity node where the content of entity is opaque to HyTime (just as it would be if it were a bitmap image or some other unstructured data). Note that things like defining hotspots in graphics would be done as a queryloc, not as an FCSLoc, which has changed. In other words, you could, if you wanted to, define the various image mapping notations (ISMAP, client-side maps) as query notations and then just use them. All you'd need to define would be a simple property set representing the data objects and properties the image describes, e.g., selectable regions, their associated addresses, and so on. 12. New and improved FCSLoc: FCSLoc now actually addresses objects in finite coordinate spaces (rather than imposing FCSes onto objects, which was, frankly, bogus). An FCSLoc essentially applies a "marqui" selection bounding area to an FCSloc and addresses any events inside that bounding area (as determined by the selection precision set for the FCSLoc). The FCSloc returns either the events or the objects scheduled by the events. FCSLoc lets you hyperlink directly to whatever happens to occur in a region of an FCS. For example, if you had an event schedule that represented a historical time line, you could use an FCS to link to "1945" and therefore anything that occurs within 1945. You could then use that FCSLoc as the location source for a queryloc that selected particular nodes, say all element nodes whose subject attribute value was "art:socialist" to see what Soviet artists were doing in 1945. 13. New and improved dataloc: The old dataloc was somewhat bogus in that the definition of what it addressed wasn't very rigorous. We've fixed that by providing a generic "data tokenizer" mechanism. A data tokenizer is any process that parses character data and constructs a grove containing the resulting tokens. You can then address the tokens as node list using normal listloc. Thus you can use any tokenization method you want (for example, you might have a tokenizer that does grammatical analysis or one that knows how to tokenize some obscure national language). Dataloc combines a default tokenizer with a listloc to remove the need to explicitly specify the data tokenizer. The tokenization "filters" are any HyLex lexical types available to the document (we define a small set of "built-in" filters that systems can support without having to support full HyLex. Thus we have a general data tokenization mechanism and the same old dataloc (with a couple new options, like a "LINE" token) with no more hand waving or bogosity. I realize that many of these new features are beyond the scope of Tim's minimal requirements and I'm *NOT* suggesting that we necessarily use them in XML. I just wanted everyone to know what new things HyTime offers, because I think they're pretty exciting and could be useful to a lot of you. 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, 20 Dec 96 12:48:06 CST From: Michael Sperberg-McQueen Subject: Re: Hyperlinks: 3.3, agree with Martin; new req. 3.4, self-revealing links. To: w3c-sgml-wg@www10.w3.org On Fri, 20 Dec 1996 11:56:53 -0500 David Durand said: >At 8:19 PM 12/19/96, Tim Bray wrote: >>3. Minimum Progress on Hyperlink Enhancement >> >>The minimum set of hyperlink constructs should: >>3.3 support addressing at least by URL and ID attribute, alone or >> in combination. > >And offset, of some sort. Martin is right about limitations of read-only >documents. I agree strongly that reference to SGML elements not bearing IDs is very useful and not too hard to try to do. I agree also, though much less strongly, that reference to spans which are not SGML elements is useful. It's not nearly as easy, though, and may be a tar pit. (Offset measured in bytes? characters? Is a byte an octet or -- this is Unicode -- two octets? No, it's ISO 10646 -- four octets? Is NON SPACING UMLAUT + A one character or two? You mean a smart Unicode system that normalizes my document can break incoming links? Gee, thanks!) In fact, I think I'll put it the other way: this is almost surely a tar pit, though there may conceivably be a way to get arbitrary spans of content without petrifying ourselves in arguments about octet-counting, and if we can find that path, it might be worth while taking it. Neither of these, however, seems to me to fall into the class 'minimum progress needed to declare victory'. We can declare victory -- even more important, we can earn victory -- without either of these things. (If they were absolutely essential to all users, systems that lack them would have no users. The Web does have users; ergo, ...) -C. M. Sperberg-McQueen Date: Fri, 20 Dec 1996 13:58:40 -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: Hyperlinks: (1. Background) [Dave Durand:] | My point is only to agree that we need an tag Just to head off a possible misunderstanding, I don't think that there is any suggestion that XML specify that the element is a reserved element having the semantics of the same element in HTML; I believe that what is being proposed is that there be a way to specify that any arbitrary element type has the link semantics of the HTML . Jon Date: Fri, 20 Dec 1996 17:00:04 -0500 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@www10.w3.org Subject: Re: Hyperlinks: MPRDV >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. I would say that , , , etc. are also a form of hyperlink... Date: Fri, 20 Dec 1996 17:36:17 -0500 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu CC: w3c-sgml-wg@www10.w3.org Subject: Re: Hyperlink behavior It might be helpful if we can get a pointer to the latest HyTime stuff... Date: Fri, 20 Dec 1996 12:59:31 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Hyperlinks: 3.3, agree with Martin; new req. 3.4, self-revealing links. At 12:48 PM 12/20/96 CST, Michael Sperberg-McQueen wrote: >On Fri, 20 Dec 1996 11:56:53 -0500 David Durand said: >>At 8:19 PM 12/19/96, Tim Bray wrote: >>>3. Minimum Progress on Hyperlink Enhancement >>> >>>The minimum set of hyperlink constructs should: >>>3.3 support addressing at least by URL and ID attribute, alone or >>> in combination. >> >>And offset, of some sort. Martin is right about limitations of read-only >>documents. > >I agree strongly that reference to SGML elements not bearing IDs is >very useful and not too hard to try to do. > >I agree also, though much less strongly, that reference to spans >which are not SGML elements is useful. It's not nearly as easy, >though, and may be a tar pit. (Offset measured in bytes? characters? >Is a byte an octet or -- this is Unicode -- two octets? No, it's ISO >10646 -- four octets? Is NON SPACING UMLAUT + A one character or >two? You mean a smart Unicode system that normalizes my document >can break incoming links? Gee, thanks!) It's not a tar pit (I don't think) when defined in terms of groves because issues of character representation are resolved in the process of constructing the grove because each character becomes an individual node. Through the use of grove plans and, possibly, custom data tokenizers, you can define exactly how you want the data you're addressing represented. One of the things I *didn't* mention in my summary of TC changes is that span locations are now more clearly defined because of groves. 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, 20 Dec 1996 18:35:37 -0600 From: Len Bullard To: Gavin Nicol CC: tbray@textuality.com, w3c-sgml-wg@www10.w3.org Subject: Re: Hyperlinks: MPRDV Gavin Nicol wrote: > > >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. > > I would say that , , , etc. are also a form > of hyperlink... Thanks for beating me to this one. Yes. Objects and applets are what the MID considered, xenoforms, calls to external apps for which we could provide parameters. Eventually, we found we also needed to describe the behavior, (goto, gosub, spawn). Too much to do tonight. Glad this discussion has begun in earnest. len Date: Fri, 20 Dec 1996 16:56:31 -0800 To: w3c-sgml-wg@www10.w3.org From: Tim Bray Subject: Richer & richer semantics? I think we all agree that enriched hyperlink semantics are A Good Thing... the question is, what are the trade-offs? It is a basic requirement that anything we put into this be (a) tractable to implement and (b) easy to explain. It's not clear to me that a solution based on groves/grove-plans, or a query language, meets this requirement. It's also not clear that it doesn't, but this is a challenge that must be answered. One of the reasons that it must be answered is that a minimum solution, essentially just making a formalism for multi-way typed hyperlinks, is dramatically more than what the Web guys have, and can be put *instantly* to good use. Thus if we do a good job on that, we have a good chance of buying enough credibility to get some support to take us further down the path. On the other hand, if we produce something that is even one-tenth as difficult to understand as, for example, the current HyTime standard, and does not lend itself to instant implementations, nobody will notice or care. Hell, I want general transclusion a la Xanadu... Already, I think we've learned another chunk of Minimum Progress Required to Declare Victory: 5. Minimum Progress on Extensibility The chosen mechanisms should have the property that they not impede progress toward the addition of advanced hypermedia mechanisms up to and past general transclusion. Cheers, T. Date: Sat, 21 Dec 1996 08:15:33 +0000 To: Michael Sperberg-McQueen , w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: Hyperlinks: 3.3, agree with Martin; new req. 3.4, self-revealing links. At 12:48 20/12/96 CST, Michael Sperberg-McQueen wrote: >Neither of these, however, seems to me to fall into the class >'minimum progress needed to declare victory'. We can declare victory >-- even more important, we can earn victory -- without either of >these things. (If they were absolutely essential to all users, >systems that lack them would have no users. The Web does have >users; ergo, ...) Web users stick to HTML - why should they change to XML if XML's linking mechanism is no better than HTML's. Many of us web users are screaming at W3C to improve linking so we can manage our links better, and so that we can offer sensible hierarchies of possible information providers. If they don't improve HTML soon some of us are going to have to find an alternative. It would be nice if that alternative could be 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: Sat, 21 Dec 1996 07:00:32 -0600 From: Len Bullard To: Martin Bryan CC: w3c-sgml-wg@www10.w3.org Subject: Re: Hyperlinks: 3.3, agree with Martin; new req. 3.4, self-revealing links. Martin Bryan wrote: > > Web users stick to HTML - why should they change to XML if XML's linking > mechanism is no better than HTML's. Many of us web users are screaming at > W3C to improve linking so we can manage our links better, and so that we can > offer sensible hierarchies of possible information providers. If they don't > improve HTML soon some of us are going to have to find an alternative. It > would be nice if that alternative could be XML. Agreed. Unless we get a capability that is clearly superior to the current web situation, the alternative is to apply other current systems which are already superior and simply adopt protocols which can support them. SGML/XML should offer a set of hyperlinking and location models (yes, location models) which enable us to build up to a more capable system by implementing each part as needed. You won't oust HTML. Forget that. At the end of this, HTML must also be expressed as XML. It is already expressed as SGML so it is XML that must make a case for itself. A victory indicates someone wins and someone loses. If that is what you want, you are not designing a system; you are choosing victims. Subsetting HyTime (what it was designed for) is a better alternative than adopting it in non-conforming pieces then claiming to have solved the problem by superior means. So far, I have read no real objections to what Eliot is proposing. IMO, HyTime is baroque and has undergone many transformations that while making it stronger, have left many of us bewildered about what it is. A position paper that proposes how HyTime could be applied to XML hyperlinking is needed. Simply punting to the stylesheet revives the DSSSL vs The World wars carefully put to bed by wiser members of the SGML community a year ago. Len Bullard Lockheed Martin Date: Sat, 21 Dec 1996 08:11:29 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Hyperlinks: 3.3, agree with Martin; new req. 3.4, self-revealing links. At 07:00 AM 12/21/96 -0600, Len Bullard wrote: IMO, HyTime >is baroque and has undergone many transformations that while >making it stronger, have left many of us bewildered about what >it is. HyTime has not changed in its fundamentals. Appart from some much-needed design refinements, the only real difference between old HyTime and new HyTime is the grove-based underpinings by which everything (including DSSSL and SGML) are now defined. But the scope of application, what it does, and the way it does it, have not changed. 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: Sat, 21 Dec 1996 08:11:22 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Hyperlinks: 3.3, agree with Martin; new req. 3.4, self-revealing links. At 07:00 AM 12/21/96 -0600, Len Bullard wrote: >it is. A position paper that proposes how HyTime could be >applied to XML hyperlinking is needed. Simply punting to the >stylesheet revives the DSSSL vs The World wars carefully put >to bed by wiser members of the SGML community a year ago. I am preparing such a paper--expect to see it in a day or two (Jon and I are working out some editorial issues). 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: Sat, 21 Dec 1996 08:11:32 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Richer & richer semantics? At 04:56 PM 12/20/96 -0800, Tim Bray wrote: >I think we all agree that enriched hyperlink semantics are A Good Thing... >the question is, what are the trade-offs? It is a basic requirement that >anything we put into this be (a) tractable to implement and (b) easy to >explain. It's not clear to me that a solution based on groves/grove-plans, >or a query language, meets this requirement. It's also not clear that it >doesn't, but this is a challenge that must be answered. Tim's point is an important one. I've been focusing on groves in my recent discussions because I feel that *as a designer*, groves provide an essential and useful design formalism that makes it possible to talk about many previously-murky issues with a great deal more clarity (of which the DSSSL/HyTime rationalization is evidence). But it's not necessarily necessary to describe the final design in grove terms, even if *we* know that it *can be* defined in those terms, just as XML users don't have to know about SGML declarations even though we know that there is an SGML declaration that defines what XML needs [mostly]. Here is a note I added to the HyTime standard as part of the grove information therein: "Note: The grove formalism used by HyTime is needed for definitional purposes but need not be exposed to users and document authors under normal circumstances. The location addressing mechanisms have been designed so that their default behavior will almost always be what an author would intuitively expect." In other words, while we may need to use groves in discussing the design of XML-specific addressing, we need not expose it in the XML spec if it doesn't otherwise require it. If we say "XML recognizes exactly one way to view XML documents for the purposes of addressing" then there's no need to expose groves because you don't need to talk about different abstractions of documents (which is what groves provide). On the other hand, if we determine that it's a requirement to define ways that the same addressing mechanism can be applied to different abstract views of the same data, then we need groves. One of the purposes of XML is to define a set of severe constraints that enable the hiding of complexities required by more general facilities. This is a good thing as far as it goes and I whole-heartedly support the application of that principle to the discussion of XML linking. There's nothing we can do in the definition of an XML-specific linking and addressing scheme that can prevent or impede the application of full HyTime to XML documents. It would be preferable, I think, to define the XML-specific stuff in such a way that it is directly and cleanly definable as an application of HyTime, but I don't think we need to or should expose all the richness of function and attendant complexity of HyTime. We can certainly include a pointer to HyTime, just as we do to SGML, to say "if you want to do more sophisticate things, here's a way". The basic aspects of HyTime, as for SGML, are very simple and understandable by anyone willing to spend a few minutes to learn them. They are simple ideas and simple constructs that can be combined in very powerful ways. They are based on fundamental ideas of hypertext that predate HyTime by at least 20 years. 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: Sat, 21 Dec 1996 09:22:15 -0600 From: Len Bullard To: "W. Eliot Kimber" CC: w3c-sgml-wg@www10.w3.org Subject: Re: Hyperlinks: 3.3, agree with Martin; new req. 3.4, self-revealing links. W. Eliot Kimber wrote: > > At 07:00 AM 12/21/96 -0600, Len Bullard wrote: > IMO, HyTime > >is baroque and has undergone many transformations that while > >making it stronger, have left many of us bewildered about what > >it is. > > HyTime has not changed in its fundamentals. Appart from some > much-needed design refinements, the only real difference between > old HyTime and new HyTime is the grove-based underpinings by which > everything (including DSSSL and SGML) are now defined. But the scope > of application, what it does, and the way it does it, have not changed. I agree that this is so. What I mean is that in all of the name changes, new descriptions, and the the grove-based underpinnings (which are needed), it is like starting over in ferreting out the details. It isn't a bad thing, but I understand the frustration of some with this. I welcome the paper you are working on. After watching the HyTime process for some time, my intuition is that any attempt to do what HyTime does results in HyTime-Yet-Again. So, as XML is a simplification of SGML to make it more friendly to the current Internet pipes (hollow logs instead of PVC) and base of application writers, a similar simplification of HyTime should do the job. Umm... do we know what the job is yet? :-) len Date: Sat, 21 Dec 1996 10:15:10 -0800 (PST) From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@www10.w3.org Subject: Re: Richer & richer semantics? Tim Bray writes: >Hell, I want general transclusion a la Xanadu... which is another linking behaviour that the Web already has, perhaps unfortunately. For years now (that's eons in Web time) I've been complaining that involuntary transclusion works against the interests of copyright holders and dramatically reduces their desire to make copyrighted material available inthe Web environment. IMG was bad enough (from this angle); FRAMEs are dreadful (from this angle). I don't see any simple solution, and maybe linking is not the arena in which a solution should be sought. But if this group can find a way to construct links such that the server of the transcluded object can detect that it's being fetched for the purpose of transclusion, that would be an immense win. Awesome, even. Xanadu evades this matter by assuming that everyone has already signed on to a copyright protection and micropayment scheme. The real world is, of course, different. 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: Sat, 21 Dec 1996 15:02:13 -0500 To: Terry Allen From: "Keith M. Corbett" Subject: Re: Richer & richer semantics? Cc: tbray@textuality.com, w3c-sgml-wg@www10.w3.org Terry, are you also opposed to server cache? The publisher is only informed of the first hit on his server. I doubt that even a perfect extensible markup language would contribute much toward solving the problems you've raised. The underlying conflicts are social and economic, not technical. When a document crosses the line from content into user interface it's no longer information or speech, it's a program to drive a data processing terminal. That means, among other things, that all bits on open display are basically up for grabs. Open protocols facilitate stealing, closed ones facilitate hoarding. From this angle, IMG and FRAME are no more problematic than http GET. When http is illegal, only criminals will transport hypertext. New client/server protocols with micropayments might provide better incentives for publishers to remain open. Your publisher wants to publish a price list on their Web site and to enforce contracts expressed and implied; their clients want to preview the data and to negotiate through brokers on price and features and to enforce warranties on performance. They're going to want a refund when they don't get what they asked for. Semantic markup may help here, if publishers can point to a page and say "see it said right there we were *selling* the last page of the mystery novel". But that kind of thing will be as popular as shrinkwrapped license agreements and the fine print on car ads. Online page charges won't catch on unless the system is ubiquitous, easy, cheap, and enforcible. Combining commerce with high bandwidth may bring per-transaction costs down far enough to reduce the incentives for clients to "cheat". The newspaper distribution model may be the one to watch. When you're selling thousands of copies at 50c and leaving bundles out on the street you don't worry overmuch about people who clip articles and tack 'em up on their cubicle walls. The real money is in VOLUME. Hmm, that's where we came in with SGML. If we can get the lawyers and bean counters interested there may be some role for XML ... maybe combining AI and ecash ... I'm picturing some weird hybrid with DSSSL + agents + JEPI + EDI ... /kmc At 10:15 AM 12/21/96 -0800, Terry Allen wrote: >Tim Bray writes: > >>Hell, I want general transclusion a la Xanadu... > >which is another linking behaviour that the Web already has, >perhaps unfortunately. > >For years now (that's eons in Web time) I've been complaining >that involuntary transclusion works against the interests of >copyright holders and dramatically reduces their desire to >make copyrighted material available inthe Web environment. > >IMG was bad enough (from this angle); FRAMEs are dreadful >(from this angle). I don't see any simple solution, and maybe >linking is not the arena in which a solution should be sought. > >But if this group can find a way to construct links such that >the server of the transcluded object can detect that it's being >fetched for the purpose of transclusion, that would be an >immense win. Awesome, even. > >Xanadu evades this matter by assuming that everyone has already >signed on to a copyright protection and micropayment scheme. >The real world is, of course, different. > >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 > > > /kmc Date: Sat, 21 Dec 1996 12:21:41 -0800 To: w3c-sgml-wg@www10.w3.org From: Tim Bray Subject: Transclusion At 10:15 AM 12/21/96 -0800, Terry Allen wrote: >>Hell, I want general transclusion a la Xanadu... >which is another linking behaviour that the Web already has... >IMG was bad enough (from this angle); FRAMEs are dreadful... Don't want to be pedantic, but this after all is a discussion of hypermedia so we should get our terms straight. I *think* transclusion means inclusion, not just of another document, but of an arbitrary segment of another document, in Nelson's scheme all done by byte offset, but the key point is you're pulling in a piece of something else. I think what the web does now with and is inclusion rather than transclusion. All this is orthogonal to Terry's point that silently including someone else's stuff raises some difficult and important issues in the area of intellectual property rights. Since I dragged in Ted Nelson's name, it turns out he hasn't stopped thinking about this stuff... check out http://www.sfc.keio.ac.jp/~ted/ in particular the "transcopyright" idea. - Tim Date: Sat, 21 Dec 1996 13:45:53 -0800 (PST) From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@www10.w3.org Subject: Re: Transclusion Tim Bray writes: | At 10:15 AM 12/21/96 -0800, Terry Allen wrote: | >>Hell, I want general transclusion a la Xanadu... | >which is another linking behaviour that the Web already has... | >IMG was bad enough (from this angle); FRAMEs are dreadful... | | Don't want to be pedantic, but this after all is a discussion of hypermedia | so we should get our terms straight. I *think* transclusion means inclusion, | not just of another document, but of an arbitrary segment of another document, | in Nelson's scheme all done by byte offset, but the key point is you're | pulling in a piece of something else. I think what the web does now with | and is inclusion rather than transclusion. Fair enough. IMG could be thought of as tranclusion-in-whole. FRAMEs make the META information invisible (in Navigator's view of document properties), so might qualify as transclusion of a part. Either way, byte-offset transclusion is on its way both for HTML (there's a URL scheme proposed for it) and something similar will apparently be in XML (it's one of the desiderata). Whether inclusion or transclusion, it's one of the existing link behaviors ("include and interpret", e.g., render that GIF). Another is what happens with SCRIPT: "include and execute" (which is a little different from "include and interpret", perhaps). | All this is orthogonal to Terry's point that silently including someone | else's stuff raises some difficult and important issues in the area | of intellectual property rights. Having made that point, I don't want to clutter this list with further discussion of it. I respond below to Keith Corbett, but if anyone else wants to follow up, let's take the matter offline. Keith writes: | Terry, are you also opposed to server cache? The publisher is only informed | of the first hit on his server. Under some circumstances, yes. For example, I use HTTP-EQUIV to time out my book catalogue pages after a week. And separately, there's quite a bit of thinking going into how to arrange matters so that the publisher can obtain info about subsequent hits via HTTP. But in general, I know there is a problem, and that its basis is in part that the publisher has no way of even communicating terms of use and conditions of sale, much less of negotiating on them. Without such facilities enforcement of copyright is pretty hard. | I doubt that even a perfect extensible markup language would contribute | much toward solving the problems you've raised. The underlying conflicts | are social and economic, not technical. I am not pushing for a solution in XML, only bringing up the issue. I think the problem is precisely a technical one. It may well be that solutions should be sought outside of XML, but a technical solution will eventually be found. The publishers of music and movies will see to that. | When a document crosses the line from content into user interface it's no | longer information or speech, it's a program to drive a data processing | terminal. That means, among other things, that all bits on open display are | basically up for grabs. Open protocols facilitate stealing, closed ones | facilitate hoarding. From this angle, IMG and FRAME are no more problematic | than http GET. When http is illegal, only criminals will transport | hypertext. I don't see XML, HTML, or SGML as user interface, but as content that is interpreted by a data processing terminal, as you put it. Recall what Jon said about the outcome would be of misusing Sun's owner identifier: if they catch you they'll sue you (my words). I may be able to keep unauthorized use to a level I find acceptable by taking the same approach. That is, it may be sufficient for my needs to simply be able to know what is going on and to say what conditions attach to use of my intellectual property. I can't do that now. | New client/server protocols with micropayments might provide better | incentives for publishers to remain open. Your publisher wants to publish a | price list on their Web site and to enforce contracts expressed and | implied; their clients want to preview the data and to negotiate through | brokers on price and features and to enforce warranties on performance. | They're going to want a refund when they don't get what they asked for. | Semantic markup may help here, if publishers can point to a page and say | "see it said right there we were *selling* the last page of the mystery | novel". But that kind of thing will be as popular as shrinkwrapped license | agreements and the fine print on car ads. | Online page charges won't catch on unless the system is ubiquitous, easy, | cheap, and enforcible. Combining commerce with high bandwidth may bring | per-transaction costs down far enough to reduce the incentives for clients | to "cheat". The newspaper distribution model may be the one to watch. When | you're selling thousands of copies at 50c and leaving bundles out on the | street you don't worry overmuch about people who clip articles and tack 'em | up on their cubicle walls. The real money is in VOLUME. Yeah, forget micropayments. But I'm not talking about any specific business model or payment regime. The problem extends even to documents freely available to all comers: I don't want pieces of my (free) online books quoted without attribution, plagiarized, or enframed in context that misleads the reader wrt the rest of what I wrote. (And so I find most proposals for annotation schemes to be problematic.) I want something like the ability to say formally that transclusion may be performed only for fair use or pursuant to special agreement, and that transclusion must be signalled by the link type "get-for-transclusion" (whether that's communicated in HTTP or a URL or XML or some other way). Then I can refuse to serve in response to such requests (fair users can transcribe the content and have no need to transclude, at least if it's static), and have reason to sue if my intellectual property was linked to for transclusion without use of the appropriate link type. There are presumably scads of other ways to get something like the same result. | Hmm, that's where we came in with SGML. If we can get the lawyers and bean | counters interested there may be some role for XML ... maybe combining AI | and ecash ... I'm picturing some weird hybrid with DSSSL + agents + JEPI + | EDI ... You could encrypt your content and wrap it in a Java applet that displays it only in its own window, refusing to cooperate with other display agents. That's what the music and movie people will prefer, I suspect, and that *is* a user interface solution. But there has to be a better way. If we stumble across it in the course of XML link specification, wonderful. If not, well, that's okay. 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: 21 Dec 1996 22:22:34 +0000 (GMT) From: Peter Flynn Subject: Re: Hyperlink behavior To: w3c-sgml-wg@www10.w3.org David Durand writes: (and I too thank Tim for a very clear startup) The basic list is good, though I second Martin's comment -- we should not depend on the presence of IDs in documents, if indexing of read-only material is a goal. Are we attempting to provide pointers into non-SGML material as well? I must, unfortunately, disclaim knowledge of the new HyTime stuff -- I've not had a chance to look at it because all my markup-related time has been taken up with XML. Having looked at both the HyTime stuff and the TEI Extended Pointer Notation, I am now fairly convinced that the TEI mechanism currently has the edge, partly because it's easy to get across to newcomers, and partly because it is already implemented in Panorama. (Blame Mike S-M for this -- it was his presentation of it after SGML96 which swung my pendulum :-) Putting on the end-user's hat for a minute, I can see the following >from where I sit (and there are doubtless many others): Important o maintenance of existing HTML anchor mechanism o bidirectionality o point-by-ID } with resolution involving more o point-by-markup-tree } than a start-point like foo#bar o point-by-keyword } (ie start- and end-points) Nice-to-have o pointing into non-SGML, non-HTML documents o pointing into graphics, sound, video, 3d-space etc o pointing into other applications (eg databases) o tracking of who is pointing into your own stuff :-) Putting the design hat back on, we should probably not ignore the fact that the existing anchor mechanism of HTML does provide for substantially more functionality than most browser makers have seen fit to provide to date, and that ISINDEX, FORM, IMG, APP, APPLET, EMBED, OBJECT, STYLE, and even SCRIPT can also be regarded as hyperlinks in the sense that they state the existence of a link between point X in a document and some point Y in the external world. Finally, wearing the management headgear, I'd appreciate some advice >from those experienced inside the W3C as to the pressure for implementation. I assume it is not mission-critical, otherwise the major vendors would have brought forward their own solutions long ago. Without wishing them to betray any commercial confidence, can we assume that this green light from the ERB is an indication that there is no imminent announcement of a ready-made, working solution in the pipeline from any of the players? ///Peter Date: Sat, 21 Dec 1996 18:08:53 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org Terry Allen on Sat, 21 Dec 1996 10:15:10 -0800 (PST)) Subject: anchor awareness (was Re: Richer & richer semantics?) Terry Allen writes: > But if this group can find a way to construct links such that > the server of the transcluded object can detect that it's being > fetched for the purpose of transclusion, that would be an > immense win. Awesome, even. > > Xanadu evades this matter by assuming that everyone has already > signed on to a copyright protection and micropayment scheme. > The real world is, of course, different. Please bear with me to the end of this harangue, because it's relevant to several topics. I think Terry's remark highlights a key issue. A embryonic general solution to Terry's question, "Activity Policy Association," exists in HyTime. The fundamental idea is simple enough: you have a statement of the owner's policy -- a license statement -- which is unambiguously attached to the information. (In HyTime, the statement could be, in fact, an applet which enforces the policy, but I'm not proposing that XML endorse that refinement.) The licensed information serves as an anchor of what, in effect, is a special kind of link to an object that expresses the policy. And here is where we see a more fundamental issue that is relevant to the whole discussion of hyperlinking in XML. The question is: "Does an anchor know that it is an anchor?" The answers to lots of important questions depend on the answer to the above question, including: "Can an n-ended link be n-directional?" ( n >= 2, of course ) "Can a link appear elsewhere than any of its anchors?" "Can metadata (such as activity policies) be associated and re-associated with data without changing the data?" This question should not be easy for any voting member of the ERB to decide. Frankly, I don't know how I would vote; at this point I'd have to wait and see what came out of the discussion. On the one hand, if we say that anchors must be aware of their anchorishness even when the links that confer anchor status upon them are elsewhere, a many-headed Hydra monster arises. HyTime and the HyTime TC1, and DSSSL (especially with its grove notion) offer some cool answers for dealing with that monster that really work. But these concepts are hard to explain and hard to understand, and they scare implementers who haven't lived with the underlying ideas for awhile. For most people, they're extremely challenging ideas, frankly: as challenging as the object-oriented paradigm (which is mainly what it *is*, in fact). Even so, having lived intimately with the problem and discussion of anchor awareness and its implementation for years, I have this not-so-clever insight to share: Either we accept a basic paradigm change in the way we handle and think about pretty much every component of documents (i.e., we move to the grove paradigm), or we can't really implement anchor awareness. Sobering, isn't it? On the other hand, if (as in HTML) we say that all linking is unidirectional and all links have two ends, the starting end of which is where the link is, XML does not offer any functional improvement, in hyper terms, over HTML. That's OK, and we won't have to go on a Hydra-slaying mission, but I think there's a huge problem with this alternative, too. Will people switch from HTML to XML just because they get the totally intangible and abstract benefit of arbitrary structure and generic markup? I think, in most cases, not. It won't matter that XML is better for the long term if there's no compelling reason to switch over to it. A radical improvement in hyperfunctionality would, I think, certainly provide a compelling reason and turn the tide. I'm not sure what else, if anything, could do that as powerfully or certainly. God bless us, every one. <<-- Seasonal greeting doubly appropriate. --Steve Steven R. Newcomb President voice +1 716 271 0796 TechnoTeacher, Inc. fax +1 716 271 0129 (courier: 23-2 Clover Park, Internet: srn@techno.com Rochester NY 14618) FTP: ftp.techno.com P.O. Box 23795 WWW: http://www.techno.com Rochester, NY 14692-3795 USA Date: 22 Dec 1996 00:18:08 +0000 (GMT) From: Peter Flynn Subject: Re: Transclusion Allen on 21 Dec 1996 13:45:53 -0800 (PST)) To: w3c-sgml-wg@www10.w3.org Terry Allen writes: | and is inclusion rather than transclusion. [...] Whether inclusion or transclusion, it's one of the existing link behaviors ("include and interpret", e.g., render that GIF). Another To my earlier list of additional linking facilities should be added "involuntary occlusion" (the auto-replacement of one page with the next, using the well-known tricks with push and pull). "Include and interpret" is a little different from "replace and interpret" :-) | All this is orthogonal to Terry's point that silently including someone | else's stuff raises some difficult and important issues in the area | of intellectual property rights. At least at the moment it is largely detectable, in that an IMG or a whole HTML document-in-a-frame is visible as an identificable object (usually; discounting IMGs which are text coincidentally set in the user's default typeface). Silent inclusion of text fragments from another document in such a way as to be seamless to the reader, is a more problematic facility. I've no doubt many millions of people would like it, though. But in general, I know there is a problem, and that its basis is in part that the publisher has no way of even communicating terms of use and conditions of sale, much less of negotiating on them. Without such facilities enforcement of copyright is pretty hard. We had such a proposal, if my memory serves me right, on html-wg(?) a long time ago. It involved a #REQUIREd PERMIT attribute, whose value was a formatted CDATA string which could be chopped up into date, owner, ISBN, and a few other bits, and slotted into a standard copyright para, which would pop up over the center of the object and had to be cleared with an explicit click from the user. I think it was dismissed on the grounds that it predicated client behaviour :-) You could encrypt your content and wrap it in a Java applet that displays it only in its own window, refusing to cooperate with other display agents. That's what the music and movie people will prefer, I suspect, and that *is* a user interface solution. But there has to be a better way. If we stumble across it in the course of XML link specification, wonderful. If not, well, that's okay. Copyright usually has some legal force behind it somwehere. Used to be printing and publishing was too expensive for widespread largescale amateur breaches. But there's nothing yet to prevent Joe or Jill Codehack writing a browser that defeats our best intentions at policing links, and making it available. Conclusion: we need to bear it in mind, but it's not our job in writing XML to implement the politicians' or lawyers' work for them. Just to point out what they have to do. ///Peter Date: Sat, 21 Dec 1996 19:50:56 -0500 To: Terry Allen , tbray@textuality.com, w3c-sgml-wg@www10.w3.org From: papresco Subject: Re: Richer & richer semantics? At 10:15 AM 12/21/96 -0800, Terry Allen wrote: >Tim Bray writes: > >>Hell, I want general transclusion a la Xanadu... > >which is another linking behaviour that the Web already has, >perhaps unfortunately. > >For years now (that's eons in Web time) I've been complaining >that involuntary transclusion works against the interests of >copyright holders and dramatically reduces their desire to >make copyrighted material available inthe Web environment. If involuntary transclusion is not done on the client side it can be done on the server side. On the current Web, the alternative is to download other people's data. On a future web, the web server will probably do server-side transclusion *for you*. It is probably in the copyright holder's best interest to have it be done on the client, because at least they have a mechanism for communicating directly to the reader. So I would argue that we should put it in the XML standard. The only solution seems to be servers who ask: "who are you, why do you want this and under what conditions do you want it?" >IMG was bad enough (from this angle); FRAMEs are dreadful >(from this angle). I don't see any simple solution, and maybe >linking is not the arena in which a solution should be sought. I think that it requires usage-negotiation in the transport protocols, and is not a linking issue. Paul Prescod Date: Sat, 21 Dec 1996 19:32:28 -0600 From: Len Bullard To: w3c-sgml-wg@www10.w3.org Subject: Re: Transclusion Tim Bray wrote: > > All this is orthogonal to Terry's point that silently including someone > else's stuff raises some difficult and important issues in the area > of intellectual property rights. Not to mention excess server load. I've seen sites that protest silent linking and actively record hits to determine if their competitors are doing that. Copyright payment per initial hit is fine but a hit to a site that is included by a site that is already collecting fees has to include the payment to the included site (eg., divvy the subscription fees or create rings of sites under a single subscription similar to waiter and waitress tip pooling). Pornography sites prove the potential of pay for play. Look at the counters. It does work given compelling content. The model of freebies plus paid access by subscription works if profit, not necessarily rigid copyright enforcement is primary. Rigid copyright enforcement isn't possible now in other media and the Web doesn't change that as much as exacerbate the problem. The lawsuits against some pacific rim companies for copyright violations are legendary. So? We have direct broadcast. Problem? In one model, each site signs content like current record labels sign bands. The artist/server sites take on both publication and broadcast rights. They also collect payments and that is actually a problem for the current publishing culture. Direct pay to play eliminates royalty collection and distribution organizations, e,g., BMI, ASCAP, etc. Certain well vested groups are most unhappy about that. Right now, complex formulas are used to determine royalty distribution which enable top grossing artists to divide almost all royalties and starve independents. Server side accounting with direct deposit stops that cold. To get a feel for what is happening here, consider that the ftp lyrics sites are being contacted at this time by the music industry and being told to remove all published lyrics or be subject to legal redress. Between the ease of publication production and broadcast, and the distribution, whole segments of the industry peel away. That lowers costs enormously. The number of HANDS OUT FOR NO VALUE in the music industry alone would stun you. So, content acquisition costs come down unless as with the CD sales today, artificial means are used to keep prices high. As for XML helping with the copyright, perhaps catalogs and FPIs have another use? If XML includes the formal public identifier, and these are registered... hmmm... VRML uses a WorldInfo node for copyrights, so this looks like a per language issue. While we are off topic, a question: if content is streamed, is it cached? IOW, on a multimedia site, are some content types capturable and others not? len bullard Date: Sat, 21 Dec 1996 17:51:31 -0800 To: w3c-sgml-wg@www10.w3.org From: Tim Bray Subject: Re: anchor awareness (was Re: Richer & richer semantics?) I think that Steve was making an important point, but I think that I didn't really get it. So this is a request for amplification, with some questions >The question is: >"Does an anchor know that it is an anchor?" What does it mean for an anchor to know it's an anchor... and I guess, what exactly are you terming an anchor? Consider the following: Example 1: http://www.textuality.com/sgml-erb/mprdv.html not as an example, but in and of itself, embedded in the email you are now reading. I would assume this is not an anchor in the sense that you mean; 1-way www semantics make it a link-end but not an anchor. The person who placed mprdv.html at www.textuality.com and sent the URL out by email was consciously creating an anchor that in some sense knows it's an anchor since there is an httpd server that will give anyone a copy, no questions asked. On the other hand, when Example 2: appears in an HTML document, I assume you would call this an anchor that knows it's an anchor? It exists only to provide addressing hooks. Some form of the same argument could be applied to any element with an attribute that has been declared to be of type ID? On the other hand, (Example 3: ) with some analogue of ilink, where you can point into a document from outside using locaddrs or some such, you clearly have a case that what's being pointed-at does not and cannot in principle know it's an anchor... or am I missing your point? >The answers to lots of important questions depend on the answer to the >above question, including: >"Can an n-ended link be n-directional?" ( n >= 2, of course ) Huh? It is not obvious to me why this depends on anchor-self-knowledge. >On the one hand, if we say that anchors must be aware of their >anchorishness even when the links that confer anchor status upon them >are elsewhere, a many-headed Hydra monster arises. This seems waaaaaaay outside our scope. >On the other hand, if (as in HTML) we say that all linking is >unidirectional and all links have two ends, the starting end of which >is where the link is, XML does not offer any functional improvement, >in hyper terms, over HTML. Can we not have multiway ilink-style thingies and perhaps even a modest amount of locaddr and so on, without getting into major paradigm re-engineering? This is the key point - I had asserted that an ilink thing, particularly if you restrict to addressing by entity & ID attribute, was a low-hanging fruit that was easy to understand, easy to implement, and clearly better than today's HTML. Are you saying that (a) this is a can of worms, or that (b) it is not in fact better, or (c) have I just missed the whole point? Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Sun, 22 Dec 1996 11:11:15 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: anchor awareness (was Re: Richer & richer semantics?) At 05:51 PM 12/21/96 -0800, Tim Bray wrote: >I think that Steve was making an important point, but I think that I >didn't really get it. So this is a request for amplification, with some >questions > >>The question is: >>"Does an anchor know that it is an anchor?" > >What does it mean for an anchor to know it's an anchor... and I guess, >what exactly are you terming an anchor? Consider the following: In HyTime terminology, an "anchor" is an object (or list of objects) that is addressed by a hyperlink as a particular anchor role. This definition of "anchor" is slightly different from that used in HTML and in some other hypertext formalisms (e.g., the Dexter hypertext model). In HyTime, anything that can be addressed by any means can *potentially* be an anchor. As you can address things without explicit identifiers, things can be addressed without their knowledge. Also, in HyTime terms, a thing becomes an anchor only when a hyperlink addresses it, not before. Thus, putting an ID on something does not, in and of itself, make it an anchor. A hyperlinking element can be one of its own anchors (a "self anchor", meaning the link links to itself). To relate this to HTML, the A element is a hyperlink when the HREF attribute is used. It is a "contextual link" because it is also one of its own anchors. The other anchor is whatever the URL points to, which could be another entire page, a named A element, or something returned by a query (HyTime considers CGI scripts to be a form of query, using the notation of "query" to mean "anything that HyTime doesn't define directly"). >Example 1: http://www.textuality.com/sgml-erb/mprdv.html > >not as an example, but in and of itself, embedded in the email you >are now reading. I would assume this is not an anchor in the sense that you >mean; 1-way www semantics make it a link-end but not an anchor. Actually in this example, the URL is an anchor, but not a link. The link exists virtually in the mailer. In HyTime, it would be defined something like this: Links all occurrences of URL strings in body of mail message (reference marks) to the objects with that URL (reference subjects). Uses the Perl support of the mail program to resolve the addresses. Location source for both queries is current mail message. 0-937175-64-1" > @URLS = (); open(MAIL, "< current-message"); while () { chop; if (~/(("http:"|"ftp:"|"mailto:")[\w\d\.\/\-\~\?\#]+)/) { # Above regex probably flawed but you get the point. push($1,@URLS); } return(@URLS); # returns list of URLs addresssed @objects = (); foreach $url (@URLS) { push(&resolve_url($url), @objects); } return(@objects); In other words, you have a two-anchor link with two anchor roles, "refmark" and "refsub". In this case, the strings addressed by the "url-in-text" function are the "refmark" anchor. The objects with those URLs are the "refsub" anchor. Both anchors are lists in this case and defined using inter-dependent queries (a very useful technique). You probably wouldn't actually implement a mail program's functionality this way (but you could and it would make for a very interesting general facility to be able to define new links of this sort). But it shows how you can use links and queries to express the precise relationship of function (matching URLs in text and resolving them) to the relationship between the two funtions in a standard way. > The person >who placed mprdv.html at www.textuality.com and sent the URL out by email >was consciously creating an anchor that in some sense knows it's an anchor >since there is an httpd server that will give anyone a copy, no questions >asked. But the anchor doesn't know it's an anchor, it only knows it's a string. The application of linking semantics that make it an anchor are separate >from the string (and there's no requirement that they ever be applied even though the author may reasonably expect them to be most of the time--if I'm reading the mail with RN or something, the URL is not an anchor at that moment). >On the other hand, when > >Example 2: > >appears in an HTML document, I assume you would call this an anchor that >knows it's an anchor? It exists only to provide addressing hooks. Even though the *semantic* of the A element when the NAME attribute is used is to provide a point that *can* be linked to, as far as HyTime is concerned, it isn't an anchor until someone *does* link to it. In other words, just putting an ID on something doesn't make it an anchor. Or, said another way, because you can potentially address anything, everything is always potentially an anchor. Putting an ID on something doesn't make it more or less likely to be an anchor except to the degree that limits in your addressing functionality make it easier or harder to address things with particular properties. >On the other hand, (Example 3: ) with some analogue of ilink, where you can >point into a document from outside using locaddrs or some such, you clearly >have a case that what's being pointed-at does not and cannot in principle >know it's an anchor... or am I missing your point? I think Steve might be asking about three things: 1. Should we allow completely independent links (unilateral addressing of all anchors of a link). If we disallow it, then at least one anchor of every link will know it's an anchor because the link is always one of it's own anchors. I think we're all agreed that we need independent links. 2. Should the elements always indicate, in their syntactic representation, that they are anchors (e.g., an attribute called "anchored-by" that lists the addresses of those things that point at it). This could be reasonable in a tightly-controlled, closed system of documents, but is probably not reasonable or possible in a Web environment and I doubt that anyone would seriously propose it. 3. Should the *methods* associated with objects *always* be informed when they are addressed as an anchor? This is a bit more subtle, because it can be difficult or impossible to do this in all environments (e.g., when the anchors are addressed by a query against the entire Web). In other words, in the general case its useful or necessary to defer resolving some anchor addresses until the anchor is traversed to (or access to the anchor is otherwise requested). This means that there will always be anchors that do not know they are anchors at the time link is created, only at the time an attempt is made to address the anchor. The data represented by XML documents is dead and lifeless--it is just data. But there are always presumably processing methods associated with the data--browser styles, retrieval methods, whatever. Thus there will always be *something* that is "responsible" for the data objects and could potentially be informed about their anchor status. These methods might be specialized link management systems, e.g., HyTime engines, Xanadu systems, Hyper-G servers, etc. ["Dynamic" or "active" documents are, I presume, documents where the methods for certain data objects are tightly bound to the data object, e.g., a script embedded in an HTML document. However, such documents are no more or less active than documents to which the equivalent function is applied by external methods--in fact I'd argue they're *less* dynamic because the tight binding tends to limit you to only one possible behavior, instead of an infinity of possible behaviors.] Note that in the HyTime model where you have a HyTime engine, the method for any object can always interrogate the HyTime semantic grove to determine if the object is an anchor, because the HyTime semantic grove is where the information about all the links it is managing is maintained. Thus you should expect any general-purpose HyTime engine to have an "anchored-by?" function that will return a list of either all the links of which the object is an anchor. Given that list of links, you can then ask the HyTime engine about the other anchors of those links. [And note that since the HyTime semantic grove is a grove, it can be interrogated by DSSSL styles and transforms using normal DSSSL functions, so there's an obvious path to using DSSSL to apply presentation and/or behavior to HyTime-managed hyperlinks. Groves are so cool.] This is essentially what systems like Hyper-G/HyperWave or Xanadu do: maintain a database of what is linked to what. HyTime just defines a specific data model and some base semantics for it. No magic here, just standardization of typical practice (I'm not sure there's a enough concensus to say "standard practice"). 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: Sun, 22 Dec 1996 14:32:35 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org from Tim Bray on Sat, 21 Dec 1996 17:51:31 -0800) Subject: Re: anchor awareness (was Re: Richer & richer semantics?) (Tim Bray:) > I think that Steve was making an important point, but I think that I > didn't really get it. So this is a request for amplification, with some > questions > > >The question is: > >"Does an anchor know that it is an anchor?" > > What does it mean for an anchor to know it's an anchor... and I guess, > what exactly are you terming an anchor? Apologies for my lack of clarity. Long-established habits of thought (aka brain damage from overlong exposure to HyTime) are responsible. I should have defined my terms, and maybe a lesson here is that we need to agree on a set of definitions for the terms we use. I strongly urge the adoption of HyTime parlance simply because it's designed for maximum generality, it gets us out of the limiting rut that exposure to HTML has imposed on our thinking about hyperfunctionality, and it's easy to explain. I propose the following definitions, all of which are derived from HyTime: anchor Any thing(s) that serve(s) as any terminating point of any hyperlink. Unlike many other hypertext jargons, in HyTime, a thing is NOT an anchor unless it actually serves as a terminus of one or more extant hyperlinks. Just because something has a unique identifier, or because some address somewhere points at it, does not make it an anchor. Because of the universality of HyTime addressing, literally everything is potentially an anchor. I guess it's reasonable to say that things that have known addresses have, in some sense, more potential to be anchors than things that don't. But worrying about that detracts from the usefulness of the term, "anchor". Better to make a clean definition. Either it's linked, and therefore it's an anchor, or it isn't. link or hyperlink An element that expresses a relationship between n anchors. It may or may not contain or include all of the information necessary to address the anchors, but it always contains or includes sufficient information to obtain the addresses of all of the anchors, perhaps by indirect addressing and/or notations (such as URL notation). The fundamental thing about a link is NOT the address information, however. It's the relationship that the link expresses. The relationship expressed could be anything. Examples of relationships that we've been concerned about in recent notes include: * transclusion. (e.g.: insert anchor 2 at the position of anchor 1) * metadata. (e.g.: license notice and subject of license notice) * traversibility. (e.g.: "see also", for some (un)specified reason) anchor role (sometimes confusingly called "link end") One of the roles that anchors can play in the relationship expressed by the link. An anchor role (or link end) is a feature of a link type (i.e., of an abstract relationship). A link often confers different semantics upon each of its anchors. Each such semantic is expressed in the link element declaration, as an anchor role name. For instance, in an "html-a" link, the declared roles might be "origin" and "target." address Something (set of elements, attribute values, and/or other information objects, including but not limited to TEI addresses) that expresses the location of one or more things. > Consider the following: > > Example 1: http://www.textuality.com/sgml-erb/mprdv.html > > not as an example, but in and of itself, embedded in the email you > are now reading. First of all, your example is an address, not a link, and, as far as we can tell so far, not an anchor either. The thing your example points at is not an anchor either, because we don't know of any link to it yet. For discussion purposes, let me replace it with a slightly different example: Example 1a: ... Example 1a is a link (to be precise, a relationship with the semantic of unidirectional traversibility) which confers anchor status upon two objects: one anchor is the element shown in Example 1a, and the other anchor is the html file mprdv.html at Tim's web site. (I'll answer the rest of Tim's question in terms of Example 1a.) > I would assume this is not an anchor in the sense that you > mean; 1-way www semantics make it a link-end but not an anchor. I don't think we're communicating yet, but we'll get there if we're both patient and very careful (:^). Might I be correct in assuming that your definition of "link-end" maps to what I would call, "anchor considered as the origination of a traversal"? And that your definition of "anchor" might map to what I would call, "anchor considered as the target of a traversal?" If so, I agree with your statement. > The person who placed mprdv.html at www.textuality.com and sent the > URL out by email was consciously creating an anchor that in some > sense knows it's an anchor since there is an httpd server that will > give anyone a copy, no questions asked. I would say no, the target anchor doesn't know it's an anchor, because the semantics of Example 1a, as defined by HTML, do not require that conforming applications be able to report to users who start their browsing in mprdv.html the existence of the element ... in whatever document it happens to be, and to support traversability to that element. True bidirectionality of linking requires that applications cause *both* anchors of a two-ended link to "know" about the other anchor. That's what I meant by "anchor awareness": the awareness of the fact that an anchor has the status of being an anchor by virtue of the fact that it is linked, even when that link is in an as-yet-unbrowsed document and has never been traversed. > On the other hand, when > > Example 2: > > appears in an HTML document, I assume you would call this an anchor that > knows it's an anchor? It exists only to provide addressing hooks. No. HTML's semantics do not require that Example 2 "know" that it's an anchor in the sense that I'm trying to explain. Example 2 is just a potential anchor, like everything else. It happens to be easy to address, because it has a unique identifier, but that doesn't necessarily mean that any link actually addresses it. More to the point, HTML's semantics do not require that an HTML application be able to traverse from the element shown in Example 2 to the other anchor of any link that confers anchor status upon it. In HTML applications, ... links *always* know that they themselves are also anchors; that's defined by HTML and it's easy to implement. It's the other end that's hard to make aware of its status as an anchor. > On the other hand, (Example 3: ) with some analogue of ilink, where > you can point into a document from outside using locaddrs or some > such, you clearly have a case that what's being pointed-at does not > and cannot in principle know it's an anchor... or am I missing your > point? I think I'm saying precisely what you seem to think I couldn't possibly be saying! If XML's semantics so specify, XML applications *can* be made responsible for knowing the anchor status of pointed-at anchors. This is exactly the question my "anchor awareness" note asks the ERB to decide: "Should XML's linking semantics require XML applications to be responsible for knowing the anchor status of pointed-at anchors?" I'm also saying: * there are powerful arguments on both sides of this question; * it's not easy to implement; * it is implementable; * it pretty much requires implementers to move to the grove paradigm; and * true bidirectionality could be a compelling reason for users to move en masse from HTML to XML. > This seems waaaaaaay outside our scope. Maybe so. Maybe what I'm asking for is a decision on that question. It's too important a question not to consider, and the fact that HyTime already makes these demands on implementers, and the fact that there are working HyTime implementations out there, and the fact that there is now a standard cookbook object model for doing it (the HyTime property set and the DSSSL grove paradigm), all conspire to make the issue quite real and quite unavoidable. This decision is VERY important and fundamental, and it MUST be decided. > Can we not have multiway ilink-style thingies and perhaps even a > modest amount of locaddr and so on, without getting into major > paradigm re-engineering? This is the key point - I had asserted that > an ilink thing, particularly if you restrict to addressing by entity > & ID attribute, was a low-hanging fruit that was easy to understand, > easy to implement, and clearly better than today's HTML. Are you saying > that (a) this is a can of worms, Yes, I am indeed saying that it is a (vanquishable) Hydra. What's the use of ilink if none of the anchors know that they are linked? After all, an ilink is nothing more or less than a link whose own location can be different from [Independent of] the locations of *all* of its anchors. > or that (b) it is not in fact better, Not at all. True anchor awareness is impressively better. It makes many heretofore impossible things possible and even easy. It even addresses Terry's license notice problem in a meaningful and workable way. To paraphrase Terry, doing it successfully could be a home-run/slam-dunk for XML. > or (c) have I just missed the whole point? I think not. I surmise that you just couldn't believe I was proposing something that might make such stiff demands on implementers. Is there sufficient will among the voting members to confront (or at least size up) the Hydra monster of anchor awareness? --Steve Steven R. Newcomb President voice +1 716 271 0796 TechnoTeacher, Inc. fax +1 716 271 0129 (courier: 23-2 Clover Park, Internet: srn@techno.com Rochester NY 14618) FTP: ftp.techno.com P.O. Box 23795 WWW: http://www.techno.com Rochester, NY 14692-3795 USA Date: Sun, 22 Dec 1996 16:25:18 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org Subject: Re: anchor awareness (was Re: Richer & richer semantics?) (Eliot Kimber:) > To relate this to HTML, the A element is a hyperlink when the HREF > attribute is used. It is a "contextual link" because it is also one of its > own anchors. What Eliot said. I should have clarified in my response that in HyTime a link may or may not be one of its own anchors, but in HTML it is *always* one of its own anchors. A maximally "independent" link expresses a relationship in which it does not itself participate. This seems a bizarre concept to many people whose only experience with hypertext is HTML, but it is commonplace in the representation of relations in databases, for example. > I think Steve might be asking about three things: > > 1. Should we allow completely independent links (unilateral addressing of > all anchors of a link). If we disallow it, then at least one anchor > of every link will know it's an anchor because the link is always one > of it's own anchors. I think we're all agreed that we need independent > links. If such agreement exists, it's news to me, but I welcome it. (However, I can't believe that I could have missed the necessary discussion of the awesome implications of such a decision, yea or nay.) > 2. Should the elements always indicate, in their syntactic representation, > that they are anchors (e.g., an attribute called "anchored-by" that > lists the addresses of those things that point at it). This could be > reasonable in a tightly-controlled, closed system of documents, but > is probably not reasonable or possible in a Web environment and I doubt > that anyone would seriously propose it. I was certainly not proposing this. > 3. Should the *methods* associated with objects *always* be informed when > they are addressed as an anchor? I wasn't proposing an algorithm either, but this is closer to the mark. What you propose is a way for applications to implement anchor awareness, and that *is* what I'm talking about. > This is a bit more subtle, because > it can be difficult or impossible to do this in all environments (e.g., > when the anchors are addressed by a query against the entire Web). One of the problems with implementing anchor awareness is how to limit the number of links whose anchors the application is responsible for knowing about. HyTime's "bounded object set" notion is one way to do that. It's obviously impossible for any application to be aware of all the anchors of all the links that exist on the Web. > In other words, in the general case its useful or necessary to defer > resolving some anchor addresses until the anchor is traversed to (or > access to the anchor is otherwise requested). This means that there > will always be anchors that do not know they are anchors at the time > link is created, only at the time an attempt is made to address the > anchor. > The data represented by XML documents is dead and lifeless--it is just > data. But there are always presumably processing methods associated with > the data--browser styles, retrieval methods, whatever. Thus there will > always be *something* that is "responsible" for the data objects and could > potentially be informed about their anchor status. These methods might be > specialized link management systems, e.g., HyTime engines, Xanadu systems, > Hyper-G servers, etc. > ["Dynamic" or "active" documents are, I presume, documents where the > methods for certain data objects are tightly bound to the data object, > e.g., a > script embedded in an HTML document. However, such documents are no more > or less active than documents to which the equivalent function is applied > by external methods--in fact I'd argue they're *less* dynamic because the > tight binding tends to limit you to only one possible behavior, instead of > an infinity of possible behaviors.] Yes, yes, yes, yes. > Note that in the HyTime model where you have a HyTime engine, the method > for any object can always interrogate the HyTime semantic grove to > determine if the object is an anchor, because the HyTime semantic grove is > where the information about all the links it is managing is maintained. > Thus you should expect any general-purpose HyTime engine to have an > "anchored-by?" function that will return a list of either all the links of > which the object is an anchor. Given that list of links, you can then ask > the HyTime engine about the other anchors of those links. [And note that > since the HyTime semantic grove is a grove, it can be interrogated by DSSSL > styles and transforms using normal DSSSL functions, so there's an obvious > path to using DSSSL to apply presentation and/or behavior to HyTime-managed > hyperlinks. Groves are so cool.] Yes, yes, yes, yes. (I'd like to point out that I used the word "cool" to describe groves, at least in this thread, *before* Eliot did. But I admit I probably heard him say it out loud earlier still. Truly, groves are cool.) > This is essentially what systems like Hyper-G/HyperWave or Xanadu do: > maintain a database of what is linked to what. HyTime just defines a > specific data model and some base semantics for it. No magic here, just > standardization of typical practice (I'm not sure there's a enough > concensus to say "standard practice"). I would say there's appreciable consensus about the grove paradigm. SP does it, JADE does it, MarkMinder does it, and the next version of HyMinder is about to do it. Three international standards do it, and a fourth (SGML itself) will undoubtedly do it next year. (Come to think of it, Fujitsu Labs put a layer over old HyMinder in order to do DSSSL with it.) Alex Milowski is doing it. Several topflight people are talking about doing it. If you already have groves, it would be ridiculous to do any kind of hyperlinking without using the grove paradigm. If we assume the use of groves and property sets for expressing the object model of XML documents, the anchor awareness question becomes "merely" one of how elaborate the relationships involved in hyperlinking should be. I was asking the question from the other angle, assuming that we have NOT yet decided to use the grove paradigm for XML. Without groves, anchor awareness is a huge headache. I think a decision to do anchor awareness pretty much necessitates moving to the grove paradigm. (Lest there be any doubt in anyone's mind, I think moving to the grove paradigm is a good idea in any case. That still leaves the question of anchor awareness open, however.) --Steve Steven R. Newcomb President voice +1 716 271 0796 TechnoTeacher, Inc. fax +1 716 271 0129 (courier: 23-2 Clover Park, Internet: srn@techno.com Rochester NY 14618) FTP: ftp.techno.com P.O. Box 23795 WWW: http://www.techno.com Rochester, NY 14692-3795 USA Date: Sun, 22 Dec 1996 18:50:22 -0800 To: w3c-sgml-wg@www10.w3.org From: Tim Bray Subject: Re: anchor awareness (was Re: Richer & richer semantics?) I think we are making progress here. It seems obvious from Steve & Eliot's remarks that we might as well adopt the Hytime nomenclature and define "anchor" to be something that is actually participating in a link relationship. It's easy to explain and understand, and is totally unambiguous; definitely in the XML style. (And web-head friendly; an HTML anchor *is* in fact an anchor when it's being used; the fact that it's not when it's not doesn't really muddy the waters). A thousand words or so later, I *think* I understand Steve's question; but let's have another go-round to make sure. I think I'm not that untypical of the SGML- and Net- savvy people on this bus who are struggling with these questions, so I don't feel guilty at all about going around and around on this until the message gets through at least one thick skull (mine). If these issues are self-evident to everyone else but me, holler and I'll shut up. Let's launch some unmanned probes here, and if (as seems likely) any of them go completely off the rails, one of the experts can step in and say where. Probe 1: 1. Web links contain lots of ends that don't know they are anchors, thus 2. if we require all anchors to be self-aware, we won't be able to subsume the current Web mechanisms. Probe 2: 1. If we support N-way links with some anchors not being self-aware, there remains the question of whether we require *one* end to be self-aware, but 2. the benefits of self-awareness depend on an ability to state with confidence that all anchors are self-aware, so 3. there seems no particular benefit to forbidding what Eliot calls "completely independent" links. Probe 3: 1. Current web links are untyped, un-roled (in fact carry no metadata), and are either single-ended or are a completely opaque query, whereas 2. HyTime ilinks (OK, HyLinks real soon now) are multi-way and have several useful places to encode what I think of as per-link or per-anchor or per-role metadata, so 3. on the surface it seems that an ilink, even if it involved all sorts of non-self-aware anchors, would offer substantially greater utility and flexibility than what the Web offers. Probe 4: 1. Enforcing anchor-awareness is not done in terms of syntax, but in terms of allowed behavior during link traversal, so 2. The spec we're about to write would need to specify, not just a language, but processor behavior, just as the XML spec does. *If* I've understood the issues, I think I'm ready to take a position: no, we should not require universal anchor-awareness, because it's hard, and we can deliver significant benefits without it. Also, as a hypertext-theory-challenged web-head, I have derived significant benefit >from pointing freely at lots of other people's stuff; while I acknowledge that this creates problems in the area of intellectual property and so on (a) it seems unlikely that these problems are amenable to a technical solution, and (b) this semantic [publish and let anyone point to it anonymously] is something that is actively desired by many people. If Steve and I have a disagreement here, it seems to be crystallized in the following: Steve: >What's the >use of ilink if none of the anchors know that they are linked? After >all, an ilink is nothing more or less than a link whose own location >can be different from [Independent of] the locations of *all* of its >anchors. To which I'd answer; the use is that of the existing Web mechanisms, only made multidimensional, and with a place for metadata, and applicable to read-only media. The usefulness of the existing Web mechanisms is not open to realistic challenge; and multidimensionality and metadata seem, on the face of it, to be major steps forward. And easy to achieve. Follow-on questions... *if* we specify some self-aware anchor machinery, *and* we define behaviors for an XML processor for accessing these things, then: a) could an XML processor, by offering an anchor-retrieval mode that refuses to retrieve anything not self-aware in the approved way, act as a gateway that would deliver the benefits that Steve is discussing? b) could such machinery and behavior be described simply and compactly, with a degree of difficulty not greater than that of the XML spec? Sorry for the long-windedness. Cheers, Tim Bray tbray@textuality.com http://www.textuality.com/ +1-604-488-1167 Date: Sun, 22 Dec 1996 23:55:30 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org from Tim Bray on Sun, 22 Dec 1996 18:50:22 -0800) Subject: Re: anchor awareness (was Re: Richer & richer semantics?) (Tim Bray:) > Probe 1: > > 1. Web links contain lots of ends that don't know they are anchors, thus > 2. if we require all anchors to be self-aware, we won't be able to subsume > the current Web mechanisms. I don't understand how proposition 2 follows. First of all, the fact that we know something (for example, the fact that something serves as the anchor of a link that is elsewhere) doesn't require us to act on that knowledge. Secondly, there is no requirement that we regard HTML links as bidirectional. It would be silly to do so in most cases, I think, because they were written without such an intent. It would be as asinine as refusing to watch "Casablanca" in black and white, simply because a so-called "colorized" version now exists. And just because I have a color TV doesn't mean I can't see black and white films on it. In other words, the fact that XML applications could "know" the anchor status of every object does not preclude their emulating HTML applications by behaving as if they did not know the anchor status of the remote anchors of HTML links. > Probe 2: > > 1. If we support N-way links with some anchors not being self-aware, > there remains the question of whether we require *one* end to be > self-aware, but I don't see how this question is open to debate. If none of the anchors knows that traversal is possible, for example, there is no point in having a traversible link, because no traversal will ever be possible. There must, therefore, always be at least one anchor that knows that it is an anchor of a link, so that the link can be examined and the other anchors discovered, so, in turn, traversal can be initiated to those other anchors. > 2. the benefits of self-awareness depend on an ability to state with > confidence that all anchors are self-aware, so It depends which benefits we're talking about, but, in general, yes. > 3. there seems no particular benefit to forbidding what Eliot calls > "completely independent" links. Huh? Your point, and the logical connections between your propositions, all totally elude me. Sorry. Please try again. Taken at face value, though, I disagree with proposition 3. The benefit of forbidding completely independent links is that you need never face a situation in which at least one anchor must be aware of its anchor status even when the link that confers that status is elsewhere. It's a reasonable and very defensible position. > Probe 3: > > 1. Current web links are untyped, un-roled (in fact carry no metadata), > and are either single-ended or are a completely opaque query, whereas I would rather say that current web links have fixed types and fixed anchor roles (although the roles are not explicit). The type and roles are made explicit in the HTML spec, but the roles are not given names using HyTime syntax, obviously. Current web links are two-ended. I am having trouble understanding what purpose a single-ended link might possibly have, and so the sense what you are saying again eludes me. (*frustration*) (I don't know what "a completely opaque query" is, either. Sorry.) > 2. HyTime ilinks (OK, HyLinks real soon now) are multi-way and have > several useful places to encode what I think of as per-link or > per-anchor or per-role metadata, so > 3. on the surface it seems that an ilink, even if it involved all sorts > of non-self-aware anchors, would offer substantially greater utility > and flexibility than what the Web offers. Maybe you're right. I don't know; I haven't considered this possibility. At first blush, though, I tend to think the "greater utility" may be much less than "substantial". Can you think of any examples? > Probe 4: > > 1. Enforcing anchor-awareness is not done in terms of syntax, but in > terms of allowed behavior during link traversal, so ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I would agree with this statement if it said "...terms of required behavior in support of, e.g., link traversal, so" > 2. The spec we're about to write would need to specify, not just > a language, but processor behavior, just as the XML spec does. Yes. > *If* I've understood the issues, I think I'm ready to take a position: > no, we should not require universal anchor-awareness, because it's > hard, and we can deliver significant benefits without it. You haven't supported this conclusion by showing how (or even whether) these benefits are any greater than the benefits offered by HTML links. But, maybe HTML-style links are sufficient. If you're saying that HTML linking functionality is sufficient for XML, then you should say so explicitly. If that conclusion is the consensus, then I will be content; my request for a decision will have been satisfied. > Also, as a > hypertext-theory-challenged web-head, I have derived significant benefit > from pointing freely at lots of other people's stuff; while I acknowledge > that this creates problems in the area of intellectual property and so on > > (a) it seems unlikely that these problems are amenable to a technical > solution, and Too easy. You're confounding the question of whether systems can enforce the terms of licensing agreements (they can't), with the question of whether technical means can be used to associate legal notices regarding the terms of licensing agreements (they certainly can). > (b) this semantic [publish and let anyone point to it anonymously] is > something that is actively desired by many people. Of course. I'm certainly not proposing that we should do away with the semantics and capabilities of HTML links. Far from it. The question I'm asking is whether we should do more than that. > If Steve and I have a disagreement here, it seems to be crystallized in > the following: > > Steve: > >What's the > >use of ilink if none of the anchors know that they are linked? After > >all, an ilink is nothing more or less than a link whose own location > >can be different from [Independent of] the locations of *all* of its > >anchors. > > To which I'd answer; the use is that of the existing Web mechanisms, > only made multidimensional, and with a place for metadata, and applicable > to read-only media. The usefulness of the existing Web mechanisms is not > open to realistic challenge; and multidimensionality and metadata seem, on > the face of it, to be major steps forward. And easy to achieve. But what is the purpose of linking metadata to something if, from the perspective of that something, we don't know that such linking is going on? How do we retrieve such metadata? How do we know that there is metadata to be retrieved? As far as I can see, the only possible answer is: We can know this and retrieve the metadata if and only if our something is aware that it is the anchor of the link that specifies the association between the something and the metadata. It is NOT easy to achieve a situation in which new links can be created whose traversal-initiation anchors must be in read-only documents. (Also, what do you mean by "multidimensionality"? I'm stuck again, unable to figure out what "dimensions" have to do with this discussion. Sorry, Tim. Please be patient with me and try again. Do you perhaps mean "links with more than two anchors"?) > Follow-on questions... *if* we specify some self-aware anchor machinery, > *and* we define behaviors for an XML processor for accessing these things, > then: > > a) could an XML processor, by offering an anchor-retrieval mode that > refuses to retrieve anything not self-aware in the approved way, > act as a gateway that would deliver the benefits that Steve is > discussing? I don't get this question either. What on earth would be the point of refusing to retrieve something that, from its own perspective (a perspective you don't have unless you're already there, which you're not if you're trying to retrieve it) doesn't know that it's an anchor of the thing which is where you already are? In any case, no, such refusal would not deliver the benefits that I'm discussing. (Unless maybe I don't know what a "gateway" is.) Tim, at least one of us is definitely not understanding the other's thinking. I used to think it was just *you* who was not understanding *me*. I am now so boggled by your probe questions that I suspect it's both of us, or at least I. Can anybody help us out? I think the ox is in the ditch over here. --Steve Steven R. Newcomb President voice +1 716 271 0796 TechnoTeacher, Inc. fax +1 716 271 0129 (courier: 23-2 Clover Park, Internet: srn@techno.com Rochester NY 14618) FTP: ftp.techno.com P.O. Box 23795 WWW: http://www.techno.com Rochester, NY 14692-3795 USA Date: 23 Dec 1996 09:11:10 +0000 (GMT) From: Peter Flynn Subject: Re: anchor awareness (was Re: Richer & richer semantics?) To: w3c-sgml-wg@www10.w3.org Tim writes: > It seems obvious from Steve & Eliot's remarks that we might as well adopt > the Hytime nomenclature and define "anchor" to be something that is > actually participating in a link relationship. It's easy to explain and > understand, and is totally unambiguous; definitely in the XML style. (And > web-head friendly; an HTML anchor *is* in fact an anchor when it's being > used; the fact that it's not when it's not doesn't really muddy the waters). I'd feel happier documenting or teaching this if there was a phrase in there to explain that "anchor" in XML is no longer restricted to the old HTML sense of "jumping-off-point". Many millions of users have been taught (or have assimilated) that an anchor is a location you can return to using the BACK button (and I'm as guilty of this as anyone else because it's a quick and easy way to get the unidirectional dea across). Probe 1: fine. Probe 2: > 2. the benefits of self-awareness depend on an ability to state with > confidence that all anchors are self-aware Is this a binary choice, or do we have some growing list of benefits as the number of self-aware anchors grows (n --> N) ? Probe 3: fine. Probe 4: > 1. Enforcing anchor-awareness is not done in terms of syntax, but in > terms of allowed behavior during link traversal, so > 2. The spec we're about to write would need to specify, not just > a language, but processor behavior, just as the XML spec does. If this means binding a set of behaviours to (say) a specific set of element-and-attribute combos by prescription in the spec, then I don't see a problem. If it means "may" and "might" and "could" then I'm less happy about it, as we would make it easier to lose Probe 2.2 above. I think we need to be very explicit about the benefits that are achievable. If we can't spell them out in the spec (that may not be the right place for them) then we should have an Implementor's Notes document which does. IPR: > (a) it seems unlikely that these problems are amenable to a technical > solution, They can be solved at the technical level but require high-level enforcement (ie obeyable legislation). > (b) this semantic [publish and let anyone point to it anonymously] is > something that is actively desired by many people. I think that on the current Web "many" == "most". If there is a danger that people will equate XML with "you can't just point at anything any more" then there is a risk it will be ignored. Terry's arguments have convinced me that we do after all need to cover the IPR topic in the spec, but I don't know to what depth. ///Peter Date: Mon, 23 Dec 1996 08:45:59 -0500 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@www10.w3.org Subject: Re: Transclusion At 10:15 AM 12/21/96 -0800, Terry Allen wrote: >Don't want to be pedantic, but this after all is a discussion of hypermedia >so we should get our terms straight. I *think* transclusion means inclusion, >not just of another document, but of an arbitrary segment of another document, >in Nelson's scheme all done by byte offset, but the key point is you're >pulling in a piece of something else. I think what the web does now with > and is inclusion rather than transclusion. Nah. HTTP 1.1, and some HTTP 1.0 servers already allow sub-document addressing (mostly byte-range, but DynaWeb does structural chunking). Nothing in the WWW stops true transclusion at all. Date: Mon, 23 Dec 1996 09:00:18 -0500 From: gtn@ebt.com (Gavin Nicol) To: pflynn@curia.ucc.ie CC: w3c-sgml-wg@www10.w3.org Subject: Re: Hyperlink behavior >Having looked at both the HyTime stuff and the TEI Extended Pointer >Notation, I am now fairly convinced that the TEI mechanism currently >has the edge, partly because it's easy to get across to newcomers, and >partly because it is already implemented in Panorama. The other prime benefit is that it can *easily* be defined to be a special URL syntax (something I've noted a number of times in the past): http://www.ebt.com/foo.sgml/1/1/2 http://www.ebt.com/foo.sgml/chap=1/section=1/para=2 though we may like to use somewhat different syntax (ie. clearly label the exact specification type, define the sub-document address as a fragment ID, etc.). I've been trying to get something like the above adopted as a common way of sub-component addressing (because it can be used for GUI object adressing, OODB addressing, RDB addressing etc.) The first version of DynaWeb had support for both the above forms built into it... > Nice-to-have > o pointing into non-SGML, non-HTML documents > o pointing into graphics, sound, video, 3d-space etc > o pointing into other applications (eg databases) These can also be expressed as heirarchical pointers. Date: Mon, 23 Dec 1996 09:08:56 -0500 From: gtn@ebt.com (Gavin Nicol) To: papresco@calum.csclub.uwaterloo.ca CC: tallen@fsc.fujitsu.com, tbray@textuality.com, w3c-sgml-wg@www10.w3.org Subject: Re: Richer & richer semantics? >If involuntary transclusion is not done on the client side it can be done on >the server side. On the current Web, the alternative is to download other >people's data. On a future web, the web server will probably do server-side >transclusion *for you*. I do not see the distinction between client-side and server-side here... I would say the future really lies in peer-to-peer processing. Date: Mon, 23 Dec 1996 09:19:03 -0500 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@www10.w3.org Subject: Re: anchor awareness (was Re: Richer & richer semantics?) >>On the other hand, if (as in HTML) we say that all linking is >>unidirectional and all links have two ends, the starting end of which >>is where the link is, XML does not offer any functional improvement, >>in hyper terms, over HTML. > >Can we not have multiway ilink-style thingies and perhaps even a >modest amount of locaddr and so on, without getting into major >paradigm re-engineering? Point is that you can already do multi-ended links, and many other things, using clever servers: no special markup is needed, just special URL forms (in the area that is supposed to be opaque). It seems obvious to me, but if we really *are* going to specify some improved linking capabilities, we are going to end up specifying processing at almost every level of the WWW (markup, protocols, client & server). From: Charles@sgmlsource.com (Charles F. Goldfarb) To: "W. Eliot Kimber" Cc: w3c-sgml-wg@www10.w3.org Subject: Re: Summary of New HyTime Features in the TC Date: Mon, 23 Dec 1996 15:23:00 GMT Eliot, This is great stuff and deserves wider distribution. I particularly like the application examples. I would soft-pedal knocking the existing design; why should they trust you this time if you blew it last time. In any case, 20-20 hindsight is easy and things weren't as clear four years ago; all those designs had good reason for being. My detailed comments are interspersed below. In the future, could you please copy me explicitly on anything that you think I should see on the XML list? I can't monitor it for the next several weeks. (Just send me stuff like this, and anything you think I should comment on, either to you or to the list.) Thanks, Charles On Fri, 20 Dec 1996 11:28:52 -0900, "W. Eliot Kimber" wrote: >All, > >As a service to those of you who either don't have access to the TC still >under development or who, like David, don't have the time to read it >(understandably--I barely have time to both work on the TC and XML), what >follows is a brief summary of the things that are new or different in >HyTime as a result of the TC (not counting all the new stuff in the SGML >Extended Facilities). We have gone to a great deal of effort to ensure >that HyTime is as flexible as possible, in part with an eye toward how it >can be applied to Internet problems. The development of the grove >formalism has made HyTime much more rigorous in its definitions and, as a >side effect, potentially much more inclusive that it was before with a >minimum of hand waving (something Steve DeRose and David Durrand very >rightly objected to in the original HyTime standard). > >While I'm sure that many of these new features are more than XML needs as >its minimum, I wanted to show everything so you know what's there that's >new and interesting. > >Summary of HyTime TC Changes: > >1. Grove-based definitions. All HyTime addressing functions are now > defined as selections of nodes in groves. This means several > important things: > > A. HyTime location addresses can be used to address any kind of > data as long as you can produce a grove for it. > B. Non-HyTime addressing schemes can be integrated with HyTime > by defining the node lists they select. > C. All addressing operations are defined rigorously in terms > of groves which are in turn defined rigorously in terms > of formal property sets. Thus, if we've done our job right, > there should be no ambiguitity about what a particular > location address will return if you know the property set and > grove plan in effect. > >2. The use of queries for addressing. Queries are now meaningfully > integrated with other addressing mechanisms as long as the > queries return nodes in a grove. What this means in practice > is that your query system must provide a grove-based > API for defining the query domain and returing the results. This > should not be hard in most cases, as you presumably already have > a definition of the data model and need only translate it into > the SGML property set formalism. > > This means that any non-HyTime addressing scheme can be used in > HyTime by defining it's grove-based results. E.g., TEI locators > and URLs become queries that return nodes in groves. TEI locators > return nodes in SGML document groves (or whatever else they are > designed to address, URLs return nodes that are > either entity nodes (representing documents or data entities) or > element nodes (named A objects) within documents. > >3. The new "refloc" facility. This lets you designate attributes > as semantic references with which you can then use any addressing > method you want, including queries, without using indirection. Without *explicitly* using indirection. HyTime still has to be given the same information as it would for a queryloc, etc. > All the HyTime engine cares about is that the attribute is referential, > it doesn't care how the reference is made as long as it gets a node > list as a result of interpreting the reference (which it would do in > the case of HyTime-defined addresses or the query processor would > do for non-HyTime addresses). It needs to know the notation of the query or it can't invoke the processor for it. Don't pretend that this isn't a location address element; it is a shortcut for one. > Refloc makes it possible to directly represent things like the > HTML A element without change to instances. It essentially lets > you apply HyTime to almost any rational way of doing addressing > from elements. If you can do clever querries, you should be able > to retrofit even the most twisted markup schemes. > > Refloc replaces the need for the notorious "not-clink" that was in > the HyTime TC design for a while. > >4. Redesigned independent links: hylink > > The new HyLink form enhances the ilink design as follows: > > A. single "linkends" attribute replaced by one referential attribute > for each named anchor role. This makes the markup much clearer > to users and enables the use of refloc to have different > addressing methods for different anchors if you want. It also > lets you do things like use refloc to fix a referential attribute > to a treeloc that addresses a location address in the body of > link or that addresses something in the link as one of the > anchors. > > B. Notion of "aggregate links" replaced by notion of "list anchors". > The whole aggloc/agglink business on location addresses is gone > (replaced by the new agglink form). List anchors are anchors that > can be satisfied by more than one object. You can define traversal Please delete "satisfied by" everywhere in this summary. It is incorrect and unnecessary. "List anchors are anchors that can be more than one object." > rules for the members of a list ("list traversal"). (Agglink lets > you do semanticless aggregation if you want to.) > > C. Can explicitly designate any anchor as being satisfied by the > link element itself (as "self anchor"). This replaces the > "omitted linkend" defaulting rule of ilink. > > D. New and improved link traversal rules. More complete and > easier to understand (I hope). > > Any existing ilink can be made into a HyLink by adding attributes > for addressing the anchor roles ("anchor-addressing attributes") > and, possibly, modifying the anchrole attribute to reflect the new > keywords (specifically, #AGG replaced by #LIST, #COR replaced by > #CORLIST). > >5. New agglink form for representing simple aggregation. Represents the > case of simply grouping a bunch of things together under a single > semantic label to enable traversal among them. Agglinks can be > combined with hylinks to represent arbitrarily-complex levels of > grouping. For example, to represent the relationship between a mother > and her children, you might have a hylink with the anchor roles > "mother" and "children". The children anchor might then be satisfied > by agglink elements of the types "brothers" and "sisters". These > agglinks would then address as aggregates the male children and the > female children. Or you could just represent the aggregation > relationship "brothers" by a brothers agglink by itself--you don't have > to do something silly like define anchors roles "bother1 brother2 ...". > > Agglink is also useful when you really don't care about the anchor > roles and just want to connect a bunch of stuff together. In other > words you could have an agglink called "agglink" and leave it at that. > >6. Clink unchanged on the surface but now derived directly from hylink > with fixed anchor roles, so it picks up all the hylink attributes > like link traversal and list traversal that it never had before. > >7. Implied location sources: any location address element can omit its > location source, in which case it is taken to be one of three > possible things: the grove root, the principle tree root in the grove > (i.e., the document element in SGML documents), or the "referrer", i.e., > the non-address element that refers to the location address (or to > the location ladder of which the location address is the top rung). the location *path) of which the location address is the first step). > These options can be fixed for a type or selected on an instance > basis. > > The last option, "referrer", lets you have location addresses that > are dynamic in that they address relative to the thing that uses them. > This lets you do things like a "next" location ladder, similar to the > "next" and "previous" options in TEI locators. (Now if we could just > declare elements with fixed IDs we'd be in good shape....) > >8. Generalized name-space location address. With groves, the notion of > name-space is well defined. This means we can now address by name in > any name space, not just ID or entity name. For example, in a grove > for a vector graphic format that let you put names on graphic objects > (as you can do in CGM Level 4), you could address those graphic objects > by name using the HyTime name-space location address. > > The default name space is still the element name space (the "elements" > property of the SGMLDOC object in the SGML property set), so nmsploc > also provides a simpler syntax for doing what you use nameloc for > today, e.g.: chapter-1. > >9. Location sources can be data or subdocument entities. In the above > nmsploc example, the locsrc attribute is declared as ENTITY and its > value is the name of a document entity (a CDATA entity with a notation > of SGML or a notation derived from SGML, e.g., XML). This is a shorthand that causes construction of the necessary grove. (Avoid giving the impression that we have a whole bunch of special cases when we really have some well-designed shortcuts to a single construct.) > >10. New location address form: mixedloc. Mixed loc addresses whatever > the location addresses in its content address. This lets you > group location addresses together within a mixedloc element > and then use the lot by referring to the mixedloc. Mixedloc was > invented in part to model the old nameloc, but it should be useful > in its own right. > >11. New location address form: queryloc. Queryloc is a location address > that uses a query and returns a node list. It is through queryloc > that other addressing notations can be integrated. > > Queryloc replaces notloc: it's simply not meaningful to use a > location address that doesn't return nodes in a grove, so notloc, > which was defined as doing something HyTime didn't understand, > is just not meaningful in the grove new world. At a minimum, you > return a data entity node where the content of entity is > opaque to HyTime (just as it would be if it were a bitmap image > or some other unstructured data). > > Note that things like defining hotspots in graphics would be done > as a queryloc, not as an FCSLoc, which has changed. In other words, > you could, if you wanted to, define the various image mapping > notations (ISMAP, client-side maps) as query notations and then > just use them. All you'd need to define would be a simple property > set representing the data objects and properties the image describes, > e.g., selectable regions, their associated addresses, and so on. > >12. New and improved FCSLoc: FCSLoc now actually addresses objects in > finite coordinate spaces (rather than imposing FCSes onto objects, > which was, frankly, bogus). An FCSLoc essentially applies a > "marqui" selection bounding area to an FCSloc and addresses any > events inside that bounding area (as determined by the selection > precision set for the FCSLoc). The FCSloc returns either the > events or the objects scheduled by the events. > > FCSLoc lets you hyperlink directly to whatever happens to occur > in a region of an FCS. For example, if you had an event schedule > that represented a historical time line, you could use an FCS to > link to "1945" and therefore anything that occurs within 1945. > You could then use that FCSLoc as the location source for a queryloc > that selected particular nodes, say all element nodes whose > subject attribute value was "art:socialist" to see what Soviet > artists were doing in 1945. > >13. New and improved dataloc: The old dataloc was somewhat bogus in that > the definition of what it addressed wasn't very rigorous. We've fixed > that by providing a generic "data tokenizer" mechanism. A data > tokenizer is any process that parses character data and constructs > a grove containing the resulting tokens. You can then address > the tokens as node list using normal listloc. Thus you can use any > tokenization method you want (for example, you might have a tokenizer > that does grammatical analysis or one that knows how to tokenize > some obscure national language). Dataloc combines a default tokenizer > with a listloc to remove the need to explicitly specify the data > tokenizer. The tokenization "filters" are any HyLex lexical types > available to the document (we define a small set of "built-in" > filters that systems can support without having to support full > HyLex. > > Thus we have a general data tokenization mechanism and the same old > dataloc (with a couple new options, like a "LINE" token) with > no more hand waving or bogosity. > >I realize that many of these new features are beyond the scope of Tim's >minimal requirements and I'm *NOT* suggesting that we necessarily use them >in XML. I just wanted everyone to know what new things HyTime offers, >because I think they're pretty exciting and could be useful to a lot of you. > >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" > > -- Charles F. Goldfarb * Information Management Consulting * +1(408)867-5553 13075 Paramount Drive * Saratoga CA 95070 * USA International Standards Editor * ISO 8879 SGML * ISO/IEC 10744 HyTime Prentice-Hall Series Editor * CFG Series on Open Information Management -- Date: Mon, 23 Dec 1996 09:41:59 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: anchor awareness (was Re: Richer & richer semantics?) At 06:50 PM 12/22/96 -0800, Tim Bray wrote: >I think we are making progress here. > >It seems obvious from Steve & Eliot's remarks that we might as well adopt >the Hytime nomenclature and define "anchor" to be something that is >actually participating in a link relationship. It's easy to explain and >understand, and is totally unambiguous; definitely in the XML style. (And >web-head friendly; an HTML anchor *is* in fact an anchor when it's being >used; the fact that it's not when it's not doesn't really muddy the waters). Cool. Of course it scares me when Tim agrees with me this strongly :-) >Probe 1: > >1. Web links contain lots of ends that don't know they are anchors, thus >2. if we require all anchors to be self-aware, we won't be able to subsume > the current Web mechanisms. I suppose this is true, but I'm not sure it's useful. In other words, I can't imagine a workable system that would *always* require anchors to be aware of their anchor status (or said another way, that all servers must know which objects they *could* address are anchors at any given moment). Therefore I would say that XML cannot *require* that all anchors be "self aware" at all times, but neither should it assume that no anchors are ever self aware. In other words, XML should suggest a system where, from the point of view any given client examining a body of XML documents, as many anchors as practical are known *in advance of traversal to them*. For example, in an Intranet, it might be completely practical to have complete knowledge of all anchors in documents *within* the scope of the Intranet but knowledge of none or almost none for anchors outside it. This is the way Hyper-G works, for example. Clients communicating to servers within the Intranet are informed by those servers about all the anchors within the documents. When those clients traverse to an anchor whose address puts it outside the intranet, you get today's web behavior: you don't know what you're getting until you get there and the thing you got to didn't know (necessarily) that it was a target. >Probe 2: > >1. If we support N-way links with some anchors not being self-aware, > there remains the question of whether we require *one* end to be > self-aware, but >2. the benefits of self-awareness depend on an ability to state with > confidence that all anchors are self-aware, so >3. there seems no particular benefit to forbidding what Eliot calls > "completely independent" links. As there already exist Web-based systems that support (or could easily support) independent links, point three seems completely self evident (I'm thinking of Hyper-G, Aqui, systems buildable with HyMinder, etc.). I can't see what benefit there would be to forbidding such things even though we know they can't be used for all links. Point 2 is correct, so it's important when discussing these issues to distinguish scenarios where the system is closed or mostly closed (as in Hyper-G) or is completely open (as in the general Internet Web case). I personally think XML's greatest benefit will be in Intranets, where it is potentially possible to manage all the links and know all the anchors (at least those not addressed by pathalogical queries). Certainly within Internets there will be significant information management and analysis benefit to being able to apply new webs of links to existing documents (imagine an MS Project schedule as a web of hyperlinks anchored to a time-based coordinate space). For point 1, I don't think it requires discussion, because the requirement is inherent in the environment in which the link is expected to play. If you want to make the link available to the Internet masses, at least one anchor must be completely and irrevocably self aware, i.e., the link must be one of its own anchors (a "contextual link" in HyTime terms). When you are in an Intranet environment, it need not be. Note that any contextual link can be made independent by a 100% complete automatic process, so on one level, there's no conflict between contexual links and independent links. XML could also include an "invisible" linking element architectural form that is designed to be wrapped around anchors to enable the conversion of independent links into contextual ones [by "invisible" I mean that the linking element doesn't affect the contextual constraints of the things it surrounds, so that its presence or absence does not affect the semantic interpretation of the data (except to mark it as an anchor)]. >Probe 3: > >1. Current web links are untyped, un-roled (in fact carry no metadata), > and are either single-ended or are a completely opaque query, whereas By "single-ended" I assume you mean "contextual, binary links", meaning that only one anchor is explicitly addressed, the other being the link itself. Or do you mean that the anchor consists of a single object? Because HyTime allows anchors that are lists of objects, it's important to distinguish the number of distinct *anchor roles* from the number of objects addressed for any single role. It causes additional confusion when people are not used to thinking of anchor roles so they aren't used to thinking about grouping all the objects addressed by a role. Note that HyTime (with the TC) does have a hyperlink that represents simple, typeless, aggregation: the agglink element form. Certainly the link elements in HTML have very general types and no explicit anchor roles. Obviously this meets the requirements of a large number of Web users, but we also know it doesn't meet the requirements of a significant number of others. I think it's useful to make a distinction between "casual linkers" and "thoughful linkers". Sometimes it's enough just to make the connection, othertimes you really need strongly-typed links. The problem with the Web today is it supports the former well and the latter almost not at all. XML will help support the latter, but we shouldn't ignore the casual linkers either. >2. HyTime ilinks (OK, HyLinks real soon now) are multi-way and have > several useful places to encode what I think of as per-link or > per-anchor or per-role metadata, so >3. on the surface it seems that an ilink, even if it involved all sorts > of non-self-aware anchors, would offer substantially greater utility > and flexibility than what the Web offers. I think so. Even the ability to have greater than 2 anchors is a significant bonus. As an aside, I'd like to stipulate that for these discussions the shorthand "ilink" be taken to mean "any link that is potentially independent of its anchors" and not worry about the ilink/hylink distinction until we get into details of syntax. >Probe 4: > >1. Enforcing anchor-awareness is not done in terms of syntax, but in > terms of allowed behavior during link traversal, so Yes. >2. The spec we're about to write would need to specify, not just > a language, but processor behavior, just as the XML spec does. I'm not sure we need to specify the processor behavior (although it might be wise to do so). It might be enough to suggest various ways the behavior could be provided. >*If* I've understood the issues, I think I'm ready to take a position: >no, we should not require universal anchor-awareness, because it's >hard, and we can deliver significant benefits without it. Also, as a >hypertext-theory-challenged web-head, I have derived significant benefit >from pointing freely at lots of other people's stuff; while I acknowledge >that this creates problems in the area of intellectual property and so on I think this proposal contains two orthogonal proposals: A. Required anchor awareness is not a good thing and we shouldn't do it. B. Unilateral addressing (possibly without the anchor's awareness or permission) is a good thing and we should allow it. I agree with both propositions. >(a) it seems unlikely that these problems are amenable to a technical > solution, and Certainly no technical solution short of a one-world distributed operationing system and document manager can do this (Xanadu anyone?). But there are things we can add to XML to support contracts people might be willing to abide by, e.g., activity tracking policies. >(b) this semantic [publish and let anyone point to it anonymously] is > something that is actively desired by many people. So are free love and anarchy--that doesn't mean we should either condone or provide them :-). However, I think there's not much we (or probably anybody) can do about it. I'd prefer to let the big IP brains and politicians battle this one out--I think the most we can do is acknowledge the problem. Documents don't violate copyright laws, people do. >If Steve and I have a disagreement here, it seems to be crystallized in >the following: > >Steve: >>What's the >>use of ilink if none of the anchors know that they are linked? After >>all, an ilink is nothing more or less than a link whose own location >>can be different from [Independent of] the locations of *all* of its >>anchors. > >To which I'd answer; the use is that of the existing Web mechanisms, >only made multidimensional, and with a place for metadata, and applicable >to read-only media. The usefulness of the existing Web mechanisms is not >open to realistic challenge; and multidimensionality and metadata seem, on >the face of it, to be major steps forward. And easy to achieve. I agree with Tim here (and I suspect that Tim and Steve don't actually have a disagreement). By "multidimensional", I assume Tim means n-ary links with n>2. >Follow-on questions... *if* we specify some self-aware anchor machinery, >*and* we define behaviors for an XML processor for accessing these things, >then: >a) could an XML processor, by offering an anchor-retrieval mode that > refuses to retrieve anything not self-aware in the approved way, > act as a gateway that would deliver the benefits that Steve is > discussing? I'm not sure an XML processor needs to be this restrictive. It should just do as much as it can. >b) could such machinery and behavior be described simply and compactly, > with a degree of difficulty not greater than that of the XML spec? Don't know about the last bit, but probably. At it's basics it's not that hard: you're just managing a relational table that relates objects to the links they participate in and a table that relates links to their metadata. When we were working on the HyTime design this last summer, one of the things we did was try to express the grove model the Newcomb's had worked out for the HyTime property set as the equivalent relational tables. It wasn't too hard. I know there are some hard implementation problems in doing link management in a distributed networked environment (probably the same problems faced by any distributed system that requires concurrency in rapidly-changing data, i.e., transaction-support systems and parallel operating systems). But I don't think the basic data model or resolution algorithms are very complicated. And we can certainly simplify from the general HyTime model (which I have always assumed we'd do). Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 23 Dec 1996 08:45:40 -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: HTML vs. XML arguments, relevance of | Will people switch from HTML to XML just because they get the totally | intangible and abstract benefit of arbitrary structure and generic | markup? I must remind everyone that it is not the purpose of this activity to replace HTML. The idea is to provide an alternative to HTML for applications that need functionality beyond that provided by HTML while leaving HTML in place for applications that don't need the extra functionality. So arguments that begin with sentences of the form "Will people switch from HTML to XML just because" are irrelevent to the discussion. (This is not to say that people cannot have the replacement of HTML as a private agenda, just that that agenda has to stay private. It cannot be adduced in support of an argument for a particular design decision.) Jon Date: Mon, 23 Dec 1996 09:49:12 -0900 To: Charles@sgmlsource.com From: "W. Eliot Kimber" Subject: Re: Summary of New HyTime Features in the TC Cc: w3c-sgml-wg@www10.w3.org At 03:23 PM 12/23/96 GMT, Charles F. Goldfarb wrote: >>3. The new "refloc" facility. This lets you designate attributes >> as semantic references with which you can then use any addressing >> method you want, including queries, without using indirection. > >Without *explicitly* using indirection. HyTime still has to be given the same >information as it would for a queryloc, etc. Yes, of course. As it's explained in the TC, refloc is a shorthand that replaces explicit reference to the equivalent location address element. Every refloc option has an equivalent location address construction. >> All the HyTime engine cares about is that the attribute is referential, >> it doesn't care how the reference is made as long as it gets a node >> list as a result of interpreting the reference (which it would do in >> the case of HyTime-defined addresses or the query processor would >> do for non-HyTime addresses). > >It needs to know the notation of the query or it can't invoke the processor for >it. Don't pretend that this isn't a location address element; it is a shortcut >for one. Yes. >> >> B. Notion of "aggregate links" replaced by notion of "list anchors". >> The whole aggloc/agglink business on location addresses is gone >> (replaced by the new agglink form). List anchors are anchors that >> can be satisfied by more than one object. You can define traversal > >Please delete "satisfied by" everywhere in this summary. It is incorrect and >unnecessary. "List anchors are anchors that can be more than one object." Yes. I should have said "consist of" instead of "satisfied by". >> >>9. Location sources can be data or subdocument entities. In the above >> nmsploc example, the locsrc attribute is declared as ENTITY and its >> value is the name of a document entity (a CDATA entity with a notation >> of SGML or a notation derived from SGML, e.g., XML). > >This is a shorthand that causes construction of the necessary grove. Yes. This is made clear in the text of the standard. Reference to a data or subdocument entity is equivalent to referring to an explicit grovedef that names the entity as the grove source and uses the default grove plan for the entity (defined either by the entity declaration or by the notation's property set). >(Avoid giving the impression that we have a whole bunch of special cases when we >really have some well-designed shortcuts to a single construct.) Yes. The message here is that all the shortcuts in HyTime are defined in terms of HyTime primitives--there are no special cases or magic processing. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 23 Dec 1996 10:32:31 -0800 (PST) From: Terry Allen To: gtn@ebt.com, tbray@textuality.com Subject: Re: Transclusion Cc: w3c-sgml-wg@www10.w3.org Gavin, that was what Tim Bray wrote. >From w3c-sgml-wg-request@www10.w3.org Mon Dec 23 05:54 PST 1996 Date: Mon, 23 Dec 1996 08:45:59 -0500 From: gtn@ebt.com (Gavin Nicol) To: tbray@textuality.com CC: w3c-sgml-wg@www10.w3.org Subject: Re: Transclusion At 10:15 AM 12/21/96 -0800, Terry Allen wrote: >Don't want to be pedantic, but this after all is a discussion of hypermedia >so we should get our terms straight. I *think* transclusion means inclusion, >not just of another document, but of an arbitrary segment of another document, >in Nelson's scheme all done by byte offset, but the key point is you're >pulling in a piece of something else. I think what the web does now with > and is inclusion rather than transclusion. Nah. HTTP 1.1, and some HTTP 1.0 servers already allow sub-document addressing (mostly byte-range, but DynaWeb does structural chunking). Nothing in the WWW stops true transclusion at all. Date: Mon, 23 Dec 1996 11:04:21 -0800 (PST) From: Terry Allen To: tbray@textuality.com, w3c-sgml-wg@www10.w3.org Subject: Re: anchor awareness (was Re: Richer & richer semantics?) Tim Bray writes: | | It seems obvious from Steve & Eliot's remarks that we might as well adopt | the Hytime nomenclature and define "anchor" to be something that is | actually participating in a link relationship. It's easy to explain and | understand, and is totally unambiguous; definitely in the XML style. (And | web-head friendly; an HTML anchor *is* in fact an anchor when it's being | used; the fact that it's not when it's not doesn't really muddy the waters). Hytime-anchor is one way to view the matter. But to many in our target audience, is an anchor whether or not it's pointed to, and it isn't a Hytime-anchor unless it is pointed to. So if we say that "anchor" means "what Hytime calls an anchor" we will probably find it necessary to come up with a term to describe what "anchor" presently means to many people. It is useful to have a term for anchors-the-author-provided-in-case- anyone-wants-to-link-to-them. Now is foo a Hytime-anchor - if Tim's server is down? - if Tim removes the document? - if the URL were misspelled? And if byte range 1001--2001 in that document can be addressed, is that byte range (not distinguished by anything in the document itself) an anchor? (I'm just asking; these are things that will have to be explained.) 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: Mon, 23 Dec 1996 11:27:22 -0800 (PST) From: Terry Allen To: eliot@isogen.com, w3c-sgml-wg@www10.w3.org Subject: Re: anchor awareness (was Re: Richer & richer semantics?) Eliot responding to Tim: | >Probe 3: | > | >1. Current web links are untyped, un-roled (in fact carry no metadata), | > and are either single-ended or are a completely opaque query, whereas [ ... ] | Certainly the link elements in HTML have very general types and no explicit | anchor roles. Obviously this meets the requirements of a large number of | Web users, but we also know it doesn't meet the requirements of a | significant number of others. I think it's useful to make a distinction | between "casual linkers" and "thoughful linkers". Sometimes it's enough | just to make the connection, othertimes you really need strongly-typed | links. The problem with the Web today is it supports the former well and | the latter almost not at all. XML will help support the latter, but we | shouldn't ignore the casual linkers either. Let's distinguish between what the HTML markup allows and what is commonly implemented. From "-//IETF//DTD HTML 2.0//EN", and dealing only with the A element: " > I hold no brief for any of these beyond NAME and HREF, and in fact I think URN may be an error. However, any XML hyperlinking scheme will have smoother sailing if its proponents can explain (not here, but eventually, to the skeptical public) how it relates to these semantics. Even if they're mostly unimplemented, each of these attributes on A must be loved by somebody. 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: Mon, 23 Dec 1996 13:02:04 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: anchor awareness (was Re: Richer & richer semantics?) At 11:04 AM 12/23/96 -0800, Terry Allen wrote: >So if we say that "anchor" means "what Hytime calls an anchor" >we will probably find it necessary to come up with a term >to describe what "anchor" presently means to many people. It is >useful to have a term for anchors-the-author-provided-in-case- >anyone-wants-to-link-to-them. How about "element with an ID"? >Now is foo >a Hytime-anchor Which thing are you referring to? There are two anchors here: the A element itself and the object or objects addressed by the value of the HREF attribute. The A element is always an anchor because it is a contextual link and therefore one of its own anchors. I assume you mean the thing addressed by the value of the HREF attribute. The object addressed is an anchor as long as it exists (remembering that URLs, in particular, refer to locations and not objects, so the anchor is whatever object happens to be at that location--meaning that as long as *something* is at that location it will be the other anchor of the above link--this is where the subtle distinction between locations and names raised in the URL/URN discussion comes into play--in SGML it's the difference between addressing an entity only by system identifier and addressing it initially by public identifier, or addressing a book by ISBN or by physical location on the shelf.) > - if Tim's server is down? Yes, assuming the object still exists at the specified address. > - if Tim removes the document? No, assuming he doesn't put anything else at the same location. > - if the URL were misspelled? Depends on whether or not the URL still addresses something. If it does, that thing is the anchor. If not, there's no anchor and you have a broken link in this case. >And if byte range 1001--2001 in that document can be addressed, is that >byte range (not distinguished by anything in the document itself) an >anchor? Yes, if it is actually addressed by a hyperlink. 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" 3245 146th Place S.E., Suite 270, Bellevue, WA 98007, USA Date: Mon, 23 Dec 1996 11:59:24 -0800 To: "W. Eliot Kimber" From: Derek Denny-Brown Subject: Re: anchor awareness (was Re: Richer & richer semantics?) Cc: w3c-sgml-wg@www10.w3.org At 09:41 AM 12/23/96 -0900, W. Eliot Kimber wrote: >At 06:50 PM 12/22/96 -0800, Tim Bray wrote: >>Probe 1: >> >>1. Web links contain lots of ends that don't know they are anchors, thus >>2. if we require all anchors to be self-aware, we won't be able to subsume >> the current Web mechanisms. > >I suppose this is true, but I'm not sure it's useful. In other words, I >can't imagine a workable system that would *always* require anchors to be >aware of their anchor status (or said another way, that all servers must >know which objects they *could* address are anchors at any given moment). > >Therefore I would say that XML cannot *require* that all anchors be "self >aware" at all times, but neither should it assume that no anchors are ever >self aware. In other words, XML should suggest a system where, from the >point of view any given client examining a body of XML documents, as many >anchors as practical are known *in advance of traversal to them*. I think it might be usefull do define a hyperlink resolution capability requirement declaration for documents. level 0: an anchor is never self-aware (no real hyperlinking capability) level 1: an anchor is self aware only if it is itself also a declaration of a hyperlink (the HTML model) level 2: an anchor is self aware relative to it's own document only (it knows about links declared in it's document, but no-where else) level 3: an anchor is self aware for a specific bounded document set (HyTime model) A browser would have a specific resolution level to which it conformed, and would give a warning anytime a document requesting a higher resolution level was loaded. This provides a quick way for vendors to get into the game, (by starting off with implimentations which only support lower levels) but provides a clear migration path to more powerfull applications [snip] >I know there are some hard implementation problems in doing link management >in a distributed networked environment (probably the same problems faced by >any distributed system that requires concurrency in rapidly-changing data, >i.e., transaction-support systems and parallel operating systems). But I >don't think the basic data model or resolution algorithms are very >complicated. And we can certainly simplify from the general HyTime model >(which I have always assumed we'd do). Part of the issue with link management is that different users have differnt needs. If there were an easy way to provide tools to the simple cases and a clear migration path to the more sophisticated models, a user could start with the cheaper, simpler tools and only move on up the migration path as their needs demanded. Part of the whole equation is also how we intend to support locating... -derek "that which is not slightly distorted lacks sensible appeal: from which it follows that irregularity - that is to say, the unexpected, surprise, and astonishment, are an essential part and characteristic of beauty" - Charles Baudelaire Date: Mon, 23 Dec 1996 15:14:49 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org Terry Allen on Mon, 23 Dec 1996 11:04:21 -0800 (PST)) Subject: Re: anchor awareness (was Re: Richer & richer semantics?) > Hytime-anchor is one way to view the matter. But to many in our target > audience, is an anchor whether or not it's pointed to, > and it isn't a Hytime-anchor unless it is pointed to. > > So if we say that "anchor" means "what Hytime calls an anchor" > we will probably find it necessary to come up with a term > to describe what "anchor" presently means to many people. It is > useful to have a term for anchors-the-author-provided-in-case- > anyone-wants-to-link-to-them. I originally wanted to call such anchors "potential anchors" but I gave that up because everything, and every imaginable combination of everything, is potentially an anchor. The question hasn't come up since, but I still think it's a valid constructional idea in general and it's certainly an essential idea in the context of needing to generalize starting from ordinary HTML practice. How about "anticipated anchor" or "author-anticipated anchor"? > Now is foo > a Hytime-anchor > - if Tim's server is down? Yes, because whether the server is up or down does not change the HTML-defined semantic that this is a link which is also one of its own anchors. (This question seems a lot like asking whether a falling tree makes noise if nobody hears it. Epistemology, anyone?) > - if Tim removes the document? Yes, because no matter where the document may or may not be, the HTML semantic remains that this is a link which is also one of its own anchors. (The falling tree problem applies here too.) > - if the URL were misspelled? Yes, because no matter where the address leads or doesn't lead, the HTML semantic remains that this is a link which is also one of its own anchors. Now let's talk about the anchor status of mprdv.html. Assuming our application knows about the element foo , is the file mprdv.html on Tim's server a Hytime-anchor > - if Tim's server is down? Yes. (Too bad we can't get to it, though. It's an offline anchor for the moment.) > - if Tim removes the document? No, because, since it is addressed in terms of its location, if there is nothing at that location, there is nothing to confer anchor status upon. Wherever Tim has moved the document to, it is no longer having anchor status conferred upon it by this link, because the address used by this link doesn't actually refer to the document any more. > - if the URL were misspelled? No, because, since it is addressed in terms of its location, if there is nothing at that location, there is nothing to confer anchor status upon. Anchor status can be conferred only upon the objects that are actually addressed by the link. "A miss is as good as a mile." > And if byte range 1001--2001 in that document can be addressed, is that > byte range (not distinguished by anything in the document itself) an > anchor? Yes, if those bytes are the anchor of a link, and no if they're not. The fact that they are addressed is irrelevant unless the addressing mechanism is used by a link to confer anchor status upon those bytes. --Steve Steven R. Newcomb President voice +1 716 271 0796 TechnoTeacher, Inc. fax +1 716 271 0129 (courier: 23-2 Clover Park, Internet: srn@techno.com Rochester NY 14618) FTP: ftp.techno.com P.O. Box 23795 WWW: http://www.techno.com Rochester, NY 14692-3795 USA 3245 146th Place S.E., Suite 270, Bellevue, WA 98007, USA Date: Mon, 23 Dec 1996 12:28:03 -0800 To: w3c-sgml-wg@www10.w3.org From: Derek Denny-Brown Subject: locating capabilities vs. anchor awareness Hyperlinking and locating anchors and anchor awareness is all quite easy if the only mechanism for locating is ENTITY and IDREF. A number of people have expressed interest in using the TEI style linking (having never used seen TEI, that is difficult for me to evaluate. Anyone have a good reference for me where I could get some info/examples of TEI locators?). Another group (largely composed of HyTime TC1 editors no less) is carrying the HyTime torch. For this to succeed I believe that either one side needs to give in (and I pity the TEI people if they try to get the HyTime people to abandon HyTime) or some general mechanism needs to subsume both somehow. How difficult the anchor awareness problem is depends on the richness of the locator model intended to be used. David (and others) requested the ability to locate data which has no ID. How far do people want this to go? A full query model a.k.a. HyTime, where anything can be located and if HyTime can't then you just use an external handler with QueryLoc (which used to be NotLoc, for "Notational locator"). If a simple static locator model is used it greatly simlifies the process of problem of determining anchor awareness (talking as someone who has approched this from an implimentation angle). If general locators are used, allong the lines of HyTime's nameloc, treeloc, etc, do you allow document A to use document B's locators? This gets to be a messy situation (which is why I broke it out to a seperate level in my previous post about resolution levels),a nd can be difficult to implement, and costly to do in a general way (costly in terms of programmer time, cpu time, UI time/complexity, document complexity, etc). Much as I must agree with Steve and Eliot that the HyTime/DSSSL grove concept is "cool" (I was part of it's development, I hope I think it is cool...), I think that it is too much for what we are trying to do _right_now_. If we want a full model, then we should just use TEI or HyTime. So the question is, how much do people really demand? What can we trim? independent links apprears to be in the "in" box, but what about locating mechanisms. I have seen/heard almost no discussion regarding what capabilities people want (other than requests not to be limited by IDREF). The answer to this questoin is crutial to the answering Steven's questions. (None of which are easy. He an I have spent long hours "discussing" some of these issues to the point of sending the rest of the office into hiding.) I might propose as some starting requirements: - IDREF (obviously) - ENTITY (what does this really mean?) - inter-document IDREF (i.e. refering to an ID in a different document) - sub-element tree traversal (avoid the whole issue raised before over pseudo-elements messing the traversal by exlicitly ignoring them) - content (linking to the content of an element... but what does this mean? are subelements content?) I specifically avoided any attempt to do general, or complex queries. keep to the KISS method of design, for simpler explanation and implimentation. Anther questin is how should the locating mechanisms tie into the Linking mechanisms? Are they treated as one and the same, or is locating seperated, as in HyTime? -derek "that which is not slightly distorted lacks sensible appeal: from which it follows that irregularity - that is to say, the unexpected, surprise, and astonishment, are an essential part and characteristic of beauty" - Charles Baudelaire Date: Mon, 23 Dec 1996 14:14:04 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: locating capabilities vs. anchor awareness At 12:28 PM 12/23/96 -0800, Derek Denny-Brown wrote: >How difficult the anchor awareness problem is depends on the richness of the >locator model intended to be used. David (and others) requested the ability >to locate data which has no ID. How far do people want this to go? A full >query model a.k.a. HyTime, where anything can be located and if HyTime can't >then you just use an external handler with QueryLoc (which used to be >NotLoc, for "Notational locator"). This is a good point and we shouldn't lose sight of it. I tend to assume that queries will be used for addressing, both because it's right powerful and because the Web allows it today. But Derek's point is well taken: limiting our addressing power makes anchor-awareness much more tractible. In my hyperworld view [sorry Terry] I assume queries are allowed and therefore assume that there will be a class of anchors for which pre-knowledge of anchorness is unknowable. My impression is that Steve N. tends to the opposite world view, in which all anchors should be (and, ideally, must be) known in advance. I think these two views reflect focuses on different use scenarios, not fundamental differences about what hypertext is or how things like HyTime should work. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 23 Dec 1996 14:14:00 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: locating capabilities vs. anchor awareness At 12:28 PM 12/23/96 -0800, Derek Denny-Brown wrote: >Hyperlinking and locating anchors and anchor awareness is all quite easy if >the only mechanism for locating is ENTITY and IDREF. A number of people >have expressed interest in using the TEI style linking (having never used >seen TEI, that is difficult for me to evaluate. Anyone have a good >reference for me where I could get some info/examples of TEI locators?). >Another group (largely composed of HyTime TC1 editors no less) is carrying >the HyTime torch. For this to succeed I believe that either one side needs >to give in (and I pity the TEI people if they try to get the HyTime people >to abandon HyTime) or some general mechanism needs to subsume both somehow. Fortunately, you're incorrect in thinking there is a conflict between TEI and HyTime. There is not. With the TC, HyTime processing can now be integrated with any addressing scheme you care to support. All you have to do is define for the HyTime engine what sort of nodes you'll be returning, which you do by defining a property set and creating the appropriate software to provide a "grove view" of the data. If you're not using a HyTime engine, then just do what you would have done anyway. As I've said in other notes to this group, this should be almost trivial for TEI locators because they're both designed to address SGML documents and well documented (and implemented to some degree by at least two browsers). This means that defining how TEI locators address groves, SGML document groves in particular, should be very straight forward, and adapting the existing facilities to support whatever XML needs shouldn't be hard (it may already be inherent in those tools' functionality). Note that HyTime would consider TEI locators to be queries, no different in nature from any other query language you might want to use. I am already on record as probably preferring TEI locators as a good syntax for the XML target audience. But the use of TEI locators in an XML-specific, HyTime-derived linking and addressing architecture does not preclude the use of other HyTime facilities, such as basic name indirection, treelocs, datalocs, etc. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 23 Dec 1996 13:15:38 -0800 (PST) From: Terry Allen To: srn@techno.com, w3c-sgml-wg@www10.w3.org Subject: Re: anchor awareness (was Re: Richer & richer semantics?) Eliot writes: | >So if we say that "anchor" means "what Hytime calls an anchor" | >we will probably find it necessary to come up with a term | >to describe what "anchor" presently means to many people. It is | >useful to have a term for anchors-the-author-provided-in-case- | >anyone-wants-to-link-to-them. | | How about "element with an ID"? No, because A's NAME isn't an ID in HTML. It's just a CDATA label. That's true of HTML 3.2, also, and there will be nothing to stop people doing the same in XML (and for the same reasons), although in XML they may also use IDs (production 52). | >Now is foo | >a Hytime-anchor | | Which thing are you referring to? There are two anchors here: the A | element itself and the object or objects addressed by the value of the HREF | attribute. The A element is always an anchor because it is a contextual | link and therefore one of its own anchors. [ ... ] There's only one anchor here, the A element. The document pointed to isn't here. Steve answers the question I asked: (Steve:) | > Now is foo | > a Hytime-anchor | | > - if Tim's server is down? | Yes, because whether the server is up or down does not change the | HTML-defined semantic that this is a link which is also one of its own | anchors. (This question seems a lot like asking whether a falling tree | makes noise if nobody hears it. Epistemology, anyone?) See below for falling trees. | > - if Tim removes the document? | Yes, because no matter where the document may or may not be, the HTML | semantic remains that this is a link which is also one of its own | anchors. (The falling tree problem applies here too.) | | > - if the URL were misspelled? | Yes, because no matter where the address leads or doesn't lead, the HTML | semantic remains that this is a link which is also one of its own | anchors. Understood. | Now let's talk about the anchor status of mprdv.html. [ deleted as understood ] I understand that thinking about hypertext this way may have utility, but it is not easy to explain to the uninitiated, and it crosscuts the vulgar understanding of what an anchor is by making anchorness an epiphenomenon of link validity rather than a markup construct. That is, you have to know something exterior about the possible-anchor, which introduces the epistemological problem. And that problem is severe on the Internet. Just because link traversal fails, you don't know that the object pointed to doesn't exist. The server may be refusing to let you get to it, or it may be malfunctioning, or it may be incapable of executing your addressing instructions; it may not provide accurate error information, either. In fact, the server may be operating just fine, but for security reasons, it may make no reply at all to your (perhaps unauthorized) request for the object addressed. The criterion "there has to be something at the address," which can work in a closed system, isn't nearly so useful for the Internet. I suggest that we'll have a much easier time of it all round if we accept that the world understands "anchor" as a markup construct, and qualify Hytime-anchor as "Hytime anchor," or something similar. Right now, I know what Eliot and Steve mean by "anchor," because they always speak Hytime. But I don't know what anyone else means by "anchor" unless they gloss themselves. In any event, perhaps we ought to figure out what we actually want to do before worrying about the terminology, so long as we don't end up talking at cross purposes. 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: Mon, 23 Dec 1996 15:02:39 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: anchor awareness (was Re: Richer & richer semantics?) At 01:15 PM 12/23/96 -0800, Terry Allen wrote: >Eliot writes: >| >So if we say that "anchor" means "what Hytime calls an anchor" >| >we will probably find it necessary to come up with a term >| >to describe what "anchor" presently means to many people. It is >| >useful to have a term for anchors-the-author-provided-in-case- >| >anyone-wants-to-link-to-them. >| >| How about "element with an ID"? > >No, because A's NAME isn't an ID in HTML. It's just a CDATA label. >That's true of HTML 3.2, also, and there will be nothing to stop >people doing the same in XML (and for the same reasons), although >in XML they may also use IDs (production 52). Good point, although there's no reason the HTML NAME attribute *couldn't* be declared as an SGML ID--it has to be unique within the document. Of course, HTML has a very expansive definition of what constitutes a name or name start character... But I meant "ID" more in the generic sense of being uniquely identified. Certainly the NAME attribute in HTML has this semantic. Note that an HTML-specific pGrove for an HTML document could use the NAME value for A elements using the normal SGML property set because at the property set level the attribute value is just a string, not an SGML NAME (that's a distinction enforced by the parser before the grove is constructed). So as far as addressing is concerned, the HTML NAME attribute is just as good as an SGML ID. >I suggest that we'll have a much easier time of it all round if we >accept that the world understands "anchor" as a markup construct, >and qualify Hytime-anchor as "Hytime anchor," or something similar. >Right now, I know what Eliot and Steve mean by "anchor," because >they always speak Hytime. But I don't know what anyone else means by >"anchor" unless they gloss themselves. I agree that the term "anchor" in particular is way overloaded--unfortunately I can't think of any better term or terms to disambiguate anchors as HyTime means them from elements whose semantic is to be addressed as anchors. Perhaps it's because I've too deeply internalized HyTime.... Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 23 Dec 1996 14:27:52 -0800 (PST) From: Terry Allen To: eliot@isogen.com, w3c-sgml-wg@www10.w3.org Subject: Re: anchor awareness (was Re: Richer & richer semantics?) Eliot writes: | >No, because A's NAME isn't an ID in HTML. It's just a CDATA label. | >That's true of HTML 3.2, also, and there will be nothing to stop | >people doing the same in XML (and for the same reasons), although | >in XML they may also use IDs (production 52). | | Good point, although there's no reason the HTML NAME attribute *couldn't* | be declared as an SGML ID--it has to be unique within the document. Of | course, HTML has a very expansive definition of what constitutes a name or | name start character... Er, no. There is no requirement in RFC 1866 that A's NAME be unique within the document, and in fact the absence of such a requirement could eventually become a feature of HTML by facilitating n-ary links. And HTML's definition of a name start character is exactly the RCS's. So linking to is like linking to all elements with a particular value supplied for a particular attribute. (Although today in practice you get a link to only one of those elements.) 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, 24 Dec 1996 06:13:34 -0500 To: w3c-sgml-wg@www10.w3.org From: papresco Subject: Re: Richer & richer semantics? At 09:08 AM 12/23/96 -0500, Gavin Nicol wrote: >>If involuntary transclusion is not done on the client side it can be done on >>the server side. On the current Web, the alternative is to download other >>people's data. On a future web, the web server will probably do server-side >>transclusion *for you*. > >I do not see the distinction between client-side and server-side >here... I would say the future really lies in peer-to-peer >processing. What I meant to say is that if we leave transclusion and inclusion out of XML in order to avoid copyright violations, server vendors will implement proprietary transclusion tags and do the transclusion on the server side. Since we can't really restrict it we might as well make it convenient for those with legitimate uses. Paul Prescod Date: Tue, 24 Dec 1996 11:38:54 +0000 To: "Steven R. Newcomb" , w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: anchor awareness (was Re: Richer & richer semantics?) At 23:55 22/12/96 -0500, Steven R. Newcomb wrote: >(Tim Bray:) > >> Probe 1: >> >> 1. Web links contain lots of ends that don't know they are anchors, thus >> 2. if we require all anchors to be self-aware, we won't be able to subsume >> the current Web mechanisms. > >I don't understand how proposition 2 follows. . Current Web practices should not necessarily be the guide to XML practice. For example, what I as a Web user would love is a mechanism whereby I could ask the owner of a page I have pointed to for some reason not to delete, move or update the file without letting me know. This isn't anchor self-awareness as described by Steve Newcombe but is a form of link awareness that allows for good XML link management by indirection. Look at how useful the facility offered by Alta Vista to identify pages that point to your pages is. What XML needs is a simple mechanism for registering the fact that some link has identified part of one of your files as one of its anchors. If this was a compulsory feature of XML it would, in itself, go a long way in sorting out Ralph's vital copyright protection points. (We would probably need to add some messages to the HTTP header to do this though, but as this is an area being actively discussed at present this should not be too hard to arrange.) Happy Christmas one and all Martin Bryan ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Wed, 25 Dec 1996 19:23:40 -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: Anchor terminology Crosses grow Anchors; Bear, as thou shouldst do Thy Crosse, and that Crosse grows an Anchor too. But he that makes our Crosses Anchors thus, Is Christ, who there is crucifi'd for us. Yet may I, with this, my first Serpents hold, God gives new blessings, and yet leaves the old; The Serpent, may, as wise, my pattern be.... -- John Donne The conclusion I draw from the recent discussion of HyTime versus vernacular usages of the word "anchor" is that we would do well in this case to respect the vernacular. While I think that HyTime provides a very useful basis upon which to begin our discussion of linking, I don't think that we are constrained to use its sometimes obscure wording in forming our own specification. We can use HyTime-compatible syntax without using HyTime terminology. In particular, we can, as speakers of English, reclaim the term "link end" to mean what it should have meant in the first place and what any speaker of English would naturally think it means: one of the ends of a link. Therefore, I propose the following basic definitions: Link: An element that expresses one or more relationships between objects. Link end: One of the objects addressed by a link. Anchor: An element designed to serve as a link end. Under these definitions, what HyTime generically and confusingly calls an anchor (that is, anything that is addressed by some link somewhere) is unambiguously called a link end, putting the emphasis on the role of the link in determining whether something is, in fact, a link end, and anything that has been deliberately formed in such a way as to make it easy to link to (as, for example, an element to which an identifier has been assigned) is called what everyone who is not a HyTime expert would call it, viz., an anchor. I understand that this terminology will give megrims to every HyTime expert in the world. What I'm suggesting is that all ten of them can put up with the pain in the interest of creating a less rebarbative terminology for the teeming millions. Think of it as a Christmas present. Jon Date: Wed, 25 Dec 1996 20:52:10 -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: clink/ilink direction (Was: anchor awareness) I've been trying to assimilate the last few days of discussion on the question originally raised by Steve Newcomb: | "Does an anchor know that it is an anchor?" My first conclusion is that this is an unfortunate way to phrase the question (sorry, Steve). If I understand correctly, no HyTime anchor can be assumed to be self-aware even in the metaphorical sense because in the general case there may be nothing attached to the anchor to identify it as such. If a link addresses an unmarked span of characters somewhere in hyperspace then *something* is aware that the span is a HyTime anchor, but that something is surely not the unmarked character string but rather a HyTime application. If we are to attribute awareness in a metaphorical sense to something other than a program, then that awareness must belong to the link itself, not to the things it's addressing. So I suggest that we drop the whole self-awareness trope; it just gets in the way. If I ignore the issues that seem to have been created by this metaphor, and I ignore the other issues that seem to have been created by HyTime's idiosyncratic use of the word "anchor", then what stands out for me in this discussion is this statement by Steve: | One of the problems with implementing anchor awareness is how to | limit the number of links whose anchors the application is | responsible for knowing about. HyTime's "bounded object set" | notion is one way to do that. It's obviously impossible for any | application to be aware of all the anchors of all the links that | exist on the Web. A little later, in replying to a couple of questions from Tim Bray, Eliot Kimber amplified on this by saying | [I]t's important when discussing these issues to distinguish | scenarios where the system is closed or mostly closed (as in | Hyper-G) or is completely open (as in the general Internet Web | case). I personally think XML's greatest benefit will be in | Intranets, where it is potentially possible to manage all the | links and know all the anchors (at least those not addressed by | pathalogical queries). Certainly within Internets there will be | significant information management and analysis benefit to being | able to apply new webs of links to existing documents (imagine an | MS Project schedule as a web of hyperlinks anchored to a | time-based coordinate space). | | [...] If you want to make the link available to the Internet | masses, at least one anchor must be completely and irrevocably | self aware, i.e., the link must be one of its own anchors (a | "contextual link" in HyTime terms). When you are in an Intranet | environment, it need not be. What I'm hearing -- please correct me if I'm wrong -- is that we can implement contextual links for the open case (the Internet as a whole), thus modestly but usefully expanding the range of capabilities of the HTML , and then we have the further option of defining independent links that will work only in closed environments, AKA intranets. (Eliot goes on to suggest a method for wrapping an "invisible linking element architectural form" around anchors to "enable the conversion of independent links into contextual ones", but pending a fuller description, this sounds over-engineered to me.) A third option that doesn't seem to have been discussed much is that we can define ilinks whose scope is the same as the SGML ID space, or to put it loosely, ilinks that are used in the same document in which they are defined. I'm not sure how useful this would be. If we set aside the last possibility and Eliot's invisible wrapper scheme, then what we seem to be left with is a clear reason to define a contextual link mechanism for general Internet use in our first link specification document and a possible case to be made for defining an independent link mechanism for intranets that we may want to put in a first link specification document or may want to defer for a later version. Is that right? Jon Date: Thu, 26 Dec 1996 00:27:45 -0600 From: len bullard To: Jon Bosak CC: w3c-sgml-wg@www10.w3.org Subject: Anchors Aweigh Jon Bosak wrote: > ...what we seem to be left with is a clear reason to define > a contextual link mechanism for general Internet use in our first link > specification document and a possible case to be made for defining an > independent link mechanism for intranets that we may want to put in a > first link specification document or may want to defer for a later > version. > > Is that right? We need independent links for link management in a multihub hypermedia system where a hub language is any handled type that is hyperlink capable (multimedia). E.g, an Illustrated Parts Breakdown and the supporting graphic sequence (called a Figure, but multiple sheets) contain bi-directional content relationships which are more easily managed with independent links. We do it now with clinks. Hard to maintain. IMO&D, independent links are address records; clinks are controls with local address records. Confusion starts there. Self-awareness is not a good metaphor. Some contributions form the object-oriented community would help here (Derek? Gavin?) HyTime, TEI, FPI, URN, I don't care: ease of management of n-way links is what is needed. What would really help this discussion more than abstractions on linking would be set of IDLs for an XML handler. Define the XML handler public services. For object oriented programmers to build what we say we want, we have to tell them how much the XML spec defines the behavior of the system that handles it? What services do we want from that .dll? What is the XML handler interface to the framework? Location resolution is a framework feature. It's a protocol issue. Protocol implementation is a system implementation. Engineers know this and so demand that a proposal for a protocol always be backed up with the code that runs it. Fact of life these days. o Will XML hyperlinks be designed ad hoc? I have mine, you have yours, etc. That is the current situation with respect to SGML hypertext systems. We all have hyperlinks. o Are we to define minimum interoperability of hyperlink types? o Are we defining types of hyperlinks which are extensible semantically (attribute, GI, whatever) o Are we to develop a set of element types which are XML hyperlinks? (i hope not but it's the easiest punt) Given: If XML wants to define hyperlinks, XML has to provide an implementation of the protocols required to support the hyperlinks or ensure the hyperlinks fit within the constraints of existing protocols. OTH, hyperlinks are not locators. Do we have to design a protocol? Do we need a stateless or a stateful protocol? Both? WWW Today: URL with sub-file target parameters (e.g, #targetname, string du jour) or URL as address type for semantic, e.g, object, img, thingieDuJour). For comparison, here is a VRML anchor: Anchor { eventIn MFNode addChildren #tree operations eventIn MFNode removeChildren exposedField MFNode children exposedField SFString children [ ] #geometry, materials, lights, etc. exposedField SFString description "" #displayed text exposedField MFString parameter [] #value-pairs, eg, frame targets exposedField MFString url [] #get this, target, move-to-viewpoint field bboxCenter 0 0 0 #local space origin field bboxSize -1 -1 -1 #max size local space } We use a similar mechanism in IDE/AS where the link has goodies such as targetname (file), system handler (who gets this), system arguments (commands and command parameters (byte offsets, pixel positions, named objects) all used in the DDE dance). In some cases, (e.g., graphics) all documents of that content type are being handled by a single system (e.g., ImageMaster). Look's like a helper app but not really. It is actually a peer in the sense that it also handles a hub-capable data type where a hub-capable type has hyperlinks. Hub: any notation that is hyperlink capable. How does XML represent hyperlinking services to the other notation handlers? Other hubs? Could we just say, object handlers? o Is this an XML-definable content relationship? o Is this a Java or Active-X interface? Services of objects are defined by the framework. Are we offering an abstraction of that? One way to look at this is to ask, for n-way links what is as the minimal service set available to all hubs in the system? o What are the services of the objects of the framework in which XML handlers operate? o What are the services of the XML handler? o What are the requirements of the XML user that must be implemented in the XML handler services? Requirement: easier management of linked relations (e.g, independent links) Requirement: declare relations among content types without needing to know the handler type at the hyperlink or at least, where that is prioritized and/or negotiated (e.g, location ladders) Uni-directional links are hard to build and maintain for some content types. For example, the relationships between an IPB and the figure sequence to illustrate it are bi-directional. We end up coding every link twice in a domain whose range is bounded by topic, task, part, script, etc. On a good day, twice the maintenance, twice the headaches. The relationships to the procedures which use the IPB/graphic are indexed to the key numbers of the IPB/graphic where the key number names the relationship by local unique id (number list), not logical name. >From any content node in this system, there may be collections of nodes which support this with topics (description, task-direction, policy, e-mail, task recording (e.g, collaborative)). o An XML hyperlink designer might want a way to validate a referenced content type. o An XML hyperlink designer might want to say, in this IPB, this table always has a set of view types (graphic primitives in CGM, camera positions in VRML, bitmaps in whatever), or in this procedure, a collection is returned by a query whose parameters are output conditions of the last procedure o An XML hyperlink author might want to say, here is a list of URLs, (priority, aggregate, etc.) XML has to be able to support all of that because XML users need all of that. XML has to support not just the Web, but what the Web is becoming: a business for authoring to the street in one straight no-nonsense publishing path. When books emerged, it was not from academic struggle or desire. It was when certain merchants found it necessary to smuggle records in carts of linen across borders. Then the academics and the merchants had all the books they could have ever wanted. len bullard dec 25, 1996 Date: 26 Dec 1996 12:11:36 +0000 (GMT) From: Peter Flynn Subject: Re: Anchor terminology (bosak@atlantic-83.Eng.Sun.COM) To: w3c-sgml-wg@www10.w3.org Jon Bosak writes: Link: An element that expresses one or more relationships between objects. Link end: One of the objects addressed by a link. Anchor: An element designed to serve as a link end. Under these definitions, what HyTime generically and confusingly calls an anchor (that is, anything that is addressed by some link somewhere) is unambiguously called a link end, putting the emphasis on the role of the link in determining whether something is, in fact, a link end, and anything that has been deliberately formed in such a way as to make it easy to link to (as, for example, an element to which an identifier has been assigned) is called what everyone who is not a HyTime expert would call it, viz., an anchor. Can you run that past me again? You started off by proposing to define a link end as "one of [unspecified] the ends of a link" but it seems to have wandered into a definition of what (for want of more expressive terms) are conventionally called "source" and "target". I agree fully that it is high time we reclaimed some of the remoter linguistic vagrancies of HyTime, and that we need to do so in a language understanded of the people. My problem is that users tend to think of links in terms of direction, whether or not any directionality is implied: so "link end" still retains connotations of "target" and anchor retains connotations of "source". The point about an anchor is that it is something that stays fixed while you do something else like go ashore. Where the fleet of stars is anchored, And the young star-captains glow. (can't remember the author) The question is therefore whether and how we can fix this so that people will use and understand the terms as we wish them to, and I think you've made a vaulable start: I just want to get it really clear what you're implying. Think of it as a Christmas present. Think of it as evolution in action (my season's present to any San Franciscans on the list :-) ///Peter Date: Thu, 26 Dec 96 10:05:25 CST From: Michael Sperberg-McQueen Subject: Re: locating capabilities vs. anchor awareness To: W3C SGML Working Group On Mon, 23 Dec 1996 12:28:03 -0800 Derek Denny-Brown said: > ... A number of people have expressed interest in using the TEI >style linking (having never used seen TEI, that is difficult for me >to evaluate. Anyone have a good reference for me where I could get >some info/examples of TEI locators?). I believe Lou Burnard is currently working on a free-standing document describing TEI extended pointers, to make it unnecessary to consult the TEI Guidelines themselves. In the meantime, for the TEI Guidelines as a whole, try http://etext.virginia.edu/TEI.html http://dynaweb.ebt.com:8080/usrbooks/teip3/1.toc For chapter 14, on "Linking, Segmentation, and Alignment" try http://dynaweb.ebt.com:8080/usrbooks/teip3/25659 http://etext.virginia.edu/bin/tei-tocs?div=DIV1&id=SA -C. M. Sperberg-McQueen Date: Thu, 26 Dec 1996 10:15:00 -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 [Peter Flynn:] | I agree fully that it is high time we reclaimed some of the remoter | linguistic vagrancies of HyTime, and that we need to do so in a | language understanded of the people. My problem is that users tend to | think of links in terms of direction, whether or not any | directionality is implied: so "link end" still retains connotations of | "target" and anchor retains connotations of "source". Well, connotation is in the mind of the beholder, I guess. "Anchor" started out with a directional connotation (although I think with some historical investigation you might find some people who thought that "anchor" meant "source" rather than "target"), but the vernacular usage fostered by HTML calls both ends "anchors". is on one end and is on the other, and they are both (anchor) elements. Before the last few days of discussion, I might have agreed with you that there is a slight directional flavor to "link end", but now that I think of the ilink as the generic form from which clinks are derived, the only directionality that seems to inhere in the term "link end" (as a proposed replacement for what HyTime calls an anchor) is downward, i.e., from an ilink hovering out in hyperspace to all the thingies that it's addressing. Depending on how the relationships constituting the link are defined, some of those ends may have directional relationships with regard to other ends, but I don't feel that a specific direction is implied by the term "end" in itself. If I dropped a colander full of cooked spaghetti on the floor and was asked to provide the correct English word for the extremities of the mess, I would call them "ends", with no directionality implied except for a general feeling of movement from the center to the edges. The test for me is how comfortable I would feel using the term in various cases: "This link has two ends; this end is the source and this end is the target." "This link has multiple ends; one end is the XREF element itself, and the other ends are a group of things that it refers to." "This link is an independent link with a number of link ends that bear various relationships to each other; these relationships are defined by the attributes on the link." These all work for me. | The point about an anchor is that it is something that stays fixed | while you do something else like go ashore. Exactly. That's the connotation that I want to build on. Anchors as presently defined in HyTime don't have this quality; I could be looking at something that is not an anchor one second and becomes an anchor in the next one because someone in Tasmania has just completed a document containing a link to it. I'm much more comfortable saying that the thing has just become a link end than saying that it has just become an anchor. I suspect that people learning the terminology would often confuse "link end" with "anchor", but in the beginning this would be harmless, because all of the link ends a beginner would work with would, in fact, be anchors, i.e., elements that are embedded in documents specifically to serve as link ends. Only in advanced applications where link ends bear no identifying marks or scars would there be a real distinction between link ends and anchors, and at that point the difference in terminology would serve the purpose of making the student aware of the distinction. Jon Date: Thu, 26 Dec 1996 11:18:32 -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 In the following interchange with Peter Flynn -- | | directionality is implied: so "link end" still retains connotations of | | "target" and anchor retains connotations of "source". | | Well, connotation is in the mind of the beholder, I guess. "Anchor" | started out with a directional connotation (although I think with some | historical investigation you might find some people who thought that | "anchor" meant "source" rather than "target"), I meant, of course, to say 'some people who thought that "anchor" meant "target" rather than "source"'. Which demonstrates what I was trying to get across... Jon Date: Thu, 26 Dec 1996 11:26:46 -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: Anchors Aweigh I'm not in a position to answer any of the 20 or so questions in Len's message :-), but his IPB (illustrated parts bulletin) provides the paradigmatic example of a large class of real-life problems that a significant number of people would like to see solved. I think that it would be helpful for purposes of comparison if proposals for link methodologies would show how they intend to handle this case. Jon Date: Thu, 26 Dec 1996 17:06:28 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Anchor terminology At 10:15 AM 12/26/96, Jon Bosak wrote: >[Peter Flynn:] > >| I agree fully that it is high time we reclaimed some of the remoter >| linguistic vagrancies of HyTime, and that we need to do so in a >| language understanded of the people. My problem is that users tend to >| think of links in terms of direction, whether or not any >| directionality is implied: so "link end" still retains connotations of >| "target" and anchor retains connotations of "source". > >Well, connotation is in the mind of the beholder, I guess. "Anchor" >started out with a directional connotation (although I think with some >historical investigation you might find some people who thought that >"anchor" meant "source" rather than "target"), but the vernacular >usage fostered by HTML calls both ends "anchors". is on one >end and is on the other, and they are both (anchor) >elements. I would also note that the senses of the terms you use have been in use since the 60's in the Hypertext research community. And, of course, multi-ended links are frequently non-directional, so that the confusion (if it occurs), ill be unlikely to persist. -- 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, 26 Dec 1996 17:06:32 -0500 To: bosak@atlantic-83.eng.sun.com (Jon Bosak), w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: clink/ilink direction (Was: anchor awareness) Cc: bosak@atlantic-83.eng.sun.com At 8:52 PM 12/25/96, Jon Bosak wrote: >What I'm hearing -- please correct me if I'm wrong -- is that we can >implement contextual links for the open case (the Internet as a >whole), thus modestly but usefully expanding the range of capabilities >of the HTML , and then we have the further option of defining >independent links that will work only in closed environments, AKA >intranets. (Eliot goes on to suggest a method for wrapping an >"invisible linking element architectural form" around anchors to >"enable the conversion of independent links into contextual ones", but >pending a fuller description, this sounds over-engineered to me.) I think that this is too strongly negative, as to the utility of independent links. I see them as one of the really critical points of expansion for web functionality, since ilinks can be applied by anyone, to anything, without difficulty. In particular, if users wish to customize the web by adding useful navigation that meets their needs, they need merely instruct their browser to maintain an "ilink file" that will hold the links they choose to create, and enable them to be displayed in context. Such files could also be shared via the web, of course. It is true that this is more useful on intranets, because the presumption of stability and organization _may_ be more well-founded, but as infrastructure for annotaion, the creation of guided tours, and other external customization, it is extremely useful. >A third option that doesn't seem to have been discussed much is that >we can define ilinks whose scope is the same as the SGML ID space, or >to put it loosely, ilinks that are used in the same document in which >they are defined. I'm not sure how useful this would be. The HyTime folks, no doubt, all assume that this will be subsumed under any reasonbable architecture, and I agree. There is no reason to disallow any kind of intra-document linking that is possible for inter-document linking. The TEI, of course, already has this in the form of Correspondence maps. Such sets of links are quite meaningful in representing textual and linguistic commentaries, and analyses. >If we set aside the last possibility and Eliot's invisible wrapper >scheme, then what we seem to be left with is a clear reason to define >a contextual link mechanism for general Internet use in our first link >specification document and a possible case to be made for defining an >independent link mechanism for intranets that we may want to put in a >first link specification document or may want to defer for a later >version. I don't yet see any reason that ilinks should not be implemented. The issue of how software should be instructed to find ilinks to interpret relative to documents being processed is not really our problem (except for ilinks within one of the documents that they link). I agree that anchor awareness is not a concept to worry about. To some arguable extent, I think insistence on anchor awareness has helped to damage the hypertext research community. In any case, for "SGML on the Web," awareness is clearly not our problem. There is work being done on collaboration and awareness protocols, but markup has little to do with that. We should certainly be prepared to add facilities to XML to accomodate it should it ever be possible, but the fundamental problems of implementing such things over global networks are unsolved -- so we should not try to design markup that is only usable once they are solved. -- 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, 27 Dec 1996 09:21:18 +0000 To: bosak@atlantic-83.eng.sun.com (Jon Bosak), w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: Anchor terminology Cc: bosak@atlantic-83.eng.sun.com >While I think that HyTime provides a very useful basis upon which to >begin our discussion of linking, I don't think that we are constrained >to use its sometimes obscure wording in forming our own specification. >We can use HyTime-compatible syntax without using HyTime terminology. >In particular, we can, as speakers of English, reclaim the term "link >end" to mean what it should have meant in the first place and what any >speaker of English would naturally think it means: one of the ends of >a link. But as a naval man I always think of anchors at being the last link in the chain! Lets stick to old English usage, as expressed by our sailors if we are going to be consistent! Nelson's spokesman, Martin Bryan ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Fri, 27 Dec 1996 10:54:31 -0500 From: gtn@ebt.com (Gavin Nicol) To: cbullard@hiwaay.net CC: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh >What would really help this discussion more than >abstractions on linking would be set of IDLs for an XML handler. >Define the XML handler public services. Actually, this would be a *very* interesting approach to the problem. We could model the entire web in IDL. Great for compatibiliy (objects addressable as CORBA objects seems like a real win to me). The problem with this approach is that you *will* model the entire web (ie. you'll have to model documents, protocols, etc. etc.) unless you wish for "undefined" behaviour to creep in. >For object oriented programmers to build what we say we want, we have >to tell them how much the XML spec defines the behavior of the system >that handles it? What services do we want from that .dll? What is >the XML handler interface to the framework? Yes. Once we start defining behaviour, there is no end to it until you've defined the application. I think a *very* important decision is whether we wish to head down that path or not. As Len rightly notes, link resolution is a seperate problem to link specification. I believe that link resolution mechanism definition is not part of the charter for this group (unless I am quite wrong). If we start defining resolution mechnism behaviour/semantics, we'll end up reinventing the Internet. The beauty of a URL is it's opaqueness. Date: Fri, 27 Dec 1996 11:02:22 -0600 From: len bullard To: Gavin Nicol CC: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh Gavin Nicol wrote: > > >What would really help this discussion more than > >abstractions on linking would be set of IDLs for an XML handler. > >Define the XML handler public services. > > Actually, this would be a *very* interesting approach to the > problem. We could model the entire web in IDL. Great for compatibiliy > (objects addressable as CORBA objects seems like a real win to me). True, but there is also the Active X model. MS or no, it is clear that a stripped down COM model has a lot to offer and has a lot of support both in existing objects and in knowledgeable users. What I would like to see from the object-designers on the list is a rational comparison of XML hyperlinking goals and how these fit inside Active-X or Corba, what is apples/oranges, etc. It is likely I am conflating layers here. Grounding the discussion of hyperlinking in implementation proposals based on examples (eg., the IPB thing) would help some of us out of the terminology quagmire. I am also one of those who stumbled for years with HyTime terms until I realized the directional issue was part of the problem. Like others, I thought of the link as the control which pointed out to the target (with any number of notation conventions from local app name, file extension, magic number, etc.). In IDE/AS for example, the linkend attribute is heavily loaded with arguments for the target app as I noted previously. We can sort these out and ask if XML defines the way such a string should be built, but first, is this XML's charter? I think it is. > The problem with this approach is that you *will* model the entire web > (ie. you'll have to model documents, protocols, etc. etc.) unless you > wish for "undefined" behaviour to creep in. Gack! Not the WHOLE thing! ;-) What I was aiming at was the link semantics of the XML handler. We more or less know what the current crop of desktops are doing and we have listed those. We have a number of examples from SGML systems and applications that desire web-capability. >From these we ought to be able to say what, from a requirements point of view, current systems need to support initially. Creeping undefined behavior doesn't bother me as long as the defined behaviors are there and we can share the definitions unambiguously. Information systems creep. I'm used to that. > >For object oriented programmers to build what we say we want, we have > >to tell them how much the XML spec defines the behavior of the system > >that handles it? What services do we want from that .dll? What is > >the XML handler interface to the framework? > > Yes. Once we start defining behaviour, there is no end to it until > you've defined the application. I think a *very* important decision is > whether we wish to head down that path or not. I agree. Unfortunately, it is hard to define links without some notion of behavior. In MID, we had to attach attributes with values for gosub, goto, spawn, other. I never cared much for "other", but the first three were clear enough. Of course, we were dealing with a design in which an interoperable behavior spec was a primary deliverable. > As Len rightly notes, link resolution is a seperate problem to link > specification. I believe that link resolution mechanism definition is > not part of the charter for this group (unless I am quite wrong). If > we start defining resolution mechnism behaviour/semantics, we'll end > up reinventing the Internet. > > The beauty of a URL is it's opaqueness. Agreed. I presume most of the list members are receiving the uri.bunyip discussions of the revision of the URL specs. I posted the VRML example so others could see what is done with the term "anchor" in other specs including the operations fields for tree operations. VRML carefully separates internal behaviors and the sorts of things an external API does. However, VRML is an application language, not a meta language. So, I think it wise to be clear how far a behavioral spec goes in XML, and how much advanced hyperlinking XML must define vs what an application of XML defines. What must any three applications of XML share operating within the same desktop? BTW: I apologize for the weird spacing in that post. Cutting and pasting from WordPad to NS2.01 mailer is problematic. The new Nav4.0 mailer is much better. len Date: Fri, 27 Dec 1996 13:15:43 -0500 From: gtn@ebt.com (Gavin Nicol) To: cbullard@hiwaay.net CC: bosak@atlantic-83.eng.sun.com, w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh >> Actually, this would be a *very* interesting approach to the >> problem. We could model the entire web in IDL. Great for compatibiliy >> (objects addressable as CORBA objects seems like a real win to me). > >True, but there is also the Active X model. MS or no, it is clear >that a stripped down COM model has a lot to offer and has a lot of >support both in existing objects and in knowledgeable users. COM doesn't scale well to distributed systems. CORBA/OpenDoc is a better model. >What I would like to see from the object-designers on the list is a >rational comparison of XML hyperlinking goals and how these >fit inside Active-X or Corba, what is apples/oranges, etc. It >is likely I am conflating layers here. I don't think so. In many ways, defining links as objects is a good way to start, because then you can work back to the representation required at the protocol and definition ends of the system. >What I was aiming at was the link semantics of the XML handler. >We more or less know what the current crop of desktops are doing >and we have listed those. Sure, this is a good *starting* point. Date: Fri, 27 Dec 1996 09:07:53 -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: clink/ilink direction (Was: anchor awareness) [David Durand:] | I see them [ilinks] as one of the really critical points of | expansion for web functionality, since ilinks can be applied by | anyone, to anything, without difficulty. In particular, if users | wish to customize the web by adding useful navigation that meets | their needs, they need merely instruct their browser to maintain | an "ilink file" that will hold the links they choose to create, | and enable them to be displayed in context. Such files could also | be shared via the web, of course. I think that there is general agreement that ilinks are highly desirable. The question is whether enabling ilinks requires the application to know the entire grove, which in the general case would mean knowing the entire Web as a grove. Steve and Eliot seemed to be saying that it would be necessary for the application to know the grove; you seem to be saying that it would not. | I don't yet see any reason that ilinks should not be | implemented. The issue of how software should be instructed to | find ilinks to interpret relative to documents being processed is | not really our problem (except for ilinks within one of the | documents that they link). If I were an implementor I would say that this is handwaving. Given the depths of difficulty we have glimpsed during this discussion, I don't think it will be very convincing to say that finding ilinks is not our problem. It seems to me that finding ilinks is exactly our problem. Jon Date: Fri, 27 Dec 1996 17:04:16 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: clink/ilink direction (Was: anchor awareness) At 9:07 AM 12/27/96, Jon Bosak wrote: >I think that there is general agreement that ilinks are highly >desirable. The question is whether enabling ilinks requires the >application to know the entire grove, which in the general case would >mean knowing the entire Web as a grove. Steve and Eliot seemed to be >saying that it would be necessary for the application to know the >grove; you seem to be saying that it would not. Any method of link location must be able to address data. And if we want to support read-only media, as we have already said, then we need to address things without changing the document by creating explicit anchors. Web sites not under user-control are essentially read-only media, so this would be a requirement even if we had not already made it one. A "grove" is just a new name for what everyone else in the world calls a "parse tree". Now we could avoid parse trees by using byte offsets, but given that addressing bytes in markup does not usually make sense, we will need to have the parse tree anyway -- that's what structural addressing is founded on. As far as I can tell, the details of groves are irrelevant to XML, unless we decide that we have to explain how XML linking can be treated as HyTime linking. I think this is a fine idea, but a relatively low priority, as HyTime implementations are a micro-niche even within the SGML community. >| I don't yet see any reason that ilinks should not be >| implemented. The issue of how software should be instructed to >| find ilinks to interpret relative to documents being processed is >| not really our problem (except for ilinks within one of the >| documents that they link). > >If I were an implementor I would say that this is handwaving. Given >the depths of difficulty we have glimpsed during this discussion, I >don't think it will be very convincing to say that finding ilinks is >not our problem. It seems to me that finding ilinks is exactly our >problem. Finding ilinks is a matter of reading a document that contains ilinks. What we cannot describe is the policiy about what documents should be read in seraching for ilinks, or how those documents might be found. It may prove to be useful to require some ilink mechanisms of XML link managers, for instance (some _possible_ mechanisms we might want): + An XML link manager must be capable of processing several XML files together, notifying the application of any ilink endpoints that are found in any of the files, whose ilinks are also found in those files. + A user of XML linking software shall be able to create a database of ilinks that will persist as documents are processed. Ilinks in this list will be passed to the application when a document it addresses is processed. + An architectural form shall specify an external document whose ilinks are essential to the processing of the document containing the linkdb. An application that provides linking behaviour should obtain the referenced document and interpret its ilinks in relation to the original document. [note that I _don't like this suggestion]. + An XML link manager _must_ pass ilinks within a document to the application, and be prepared to interpret them. (essentially require internal links). The point of the list above is that there is an open set of reasonable ways to find documents to process together: the choice of which documents will be processed together is an application matter. But we _do_ need to say what an ilink means, and deal with the fact XML linking engines must be prepared to process multiple entities (whether serially or simultaneously does not matter) in order to correctly handle ilinks. Which documents are processed is not necessarily our concern. A comment on the depths of difficulty we have seen: Most of the difficulty seems to be understanding the HyTime model and terminology, not the basic hypertext functionality. I think that HyTime's tendancy to complicate the simpleis skewing the discussion. HyTime terminology is a strange mix of de novo terms and new meanings for old terms. But semantically, an ilink is no more complicated than a record in a database that contains external keys. And it has the same shortcoming: you have to "join" the ilink against a relevant document for it to be meaningful. We need not prespecify the joins that an XML linking engine should support, but we need to define the mechanisms to enable them. -- 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, 27 Dec 1996 17:16:04 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Anchors Aweigh At 1:15 PM 12/27/96, Gavin Nicol wrote: >>> Actually, this would be a *very* interesting approach to the >>> problem. We could model the entire web in IDL. Great for compatibiliy >>> (objects addressable as CORBA objects seems like a real win to me). >> >>True, but there is also the Active X model. MS or no, it is clear >>that a stripped down COM model has a lot to offer and has a lot of >>support both in existing objects and in knowledgeable users. > >COM doesn't scale well to distributed systems. CORBA/OpenDoc is a >better model. > >>What I would like to see from the object-designers on the list is a >>rational comparison of XML hyperlinking goals and how these >>fit inside Active-X or Corba, what is apples/oranges, etc. It >>is likely I am conflating layers here. > >I don't think so. In many ways, defining links as objects is a good >way to start, because then you can work back to the representation >required at the protocol and definition ends of the system. Actually, this seems a terrible way to start (or finish). Object models are fundamentally oriented to the definition of _behaviours_. I am firmly committed to the notion that we should think of links as delcarative information about relations between documents and document portions. We will probably require operational semantics for some techniques of locating document portions, but we should not assume that there is any single _right_ thing to do with a link and its endpoints, once located. Unsing HyTime as a mental model actually confuses things at this level, because HyTime defines not only a set of linking semantics (for describing abstract relationships), but also a set of generic multimedia presentation semantics. Just as we need to specify style sheets to make XML useful out of the box, we may need to specify presentation and user-interaction semantics for links -- but we should remember that these are radically different things. I would be tempted to put link behavior into our XML style sheets, but maybe a separate link style sheet will work better. In any case we should not conflate the presentation and interaction aspects of linking with the declarative, and "semantic relationship" aspect of linking. Even if you disagree with this philosophy (which is merely generic markup applied to links, after all), there are practical reasons to avoid this kind of semantic definition: For one thing no such definition has been widely accepted. Creating such an OO information archiotecture seems an interesting research problem to me; reason enough to shun it in a standards activity. >>What I was aiming at was the link semantics of the XML handler. >>We more or less know what the current crop of desktops are doing >>and we have listed those. > >Sure, this is a good *starting* point. For an interaction and linking style language: not for a link-definition language. -- 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, 27 Dec 1996 16:11:09 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Anchor terminology At 07:23 PM 12/25/96 -0800, Jon Bosak wrote: >While I think that HyTime provides a very useful basis upon which to >begin our discussion of linking, I don't think that we are constrained >to use its sometimes obscure wording in forming our own specification. >We can use HyTime-compatible syntax without using HyTime terminology. A mapping of XML terms to HyTime is only required if XML chooses to expose its derivation from HyTime in the spec. At a miminum, I would suggest an appendix that provides the mapping, or maybe a separate technical report that shows how XML can be derived from HyTime. >Therefore, I propose the following basic definitions: > > Link: An element that expresses one or more relationships between > objects. > > Link end: One of the objects addressed by a link. > > Anchor: An element designed to serve as a link end. I would prefer to just not use the term "anchor" at all. I don't think we need it if we agree to use "link end" in its place. We can always say "an HTML anchor" or "an identified object" or something. Note that the Dexter hypermedia model uses "anchor" to mean the address of a link end--it's a data object managed by the Dexter link management layer (I think--I can go look up the relevant papers if anyone cares), not something in the data linked. So there's a third usage of Anchor that is incompatible with either HyTime's or HTML's. >Under these definitions, what HyTime generically and confusingly calls >an anchor (that is, anything that is addressed by some link somewhere) >is unambiguously called a link end, putting the emphasis on the role >of the link in determining whether something is, in fact, a link end, >and anything that has been deliberately formed in such a way as to >make it easy to link to (as, for example, an element to which an >identifier has been assigned) is called what everyone who is not a >HyTime expert would call it, viz., an anchor. >I understand that this terminology will give megrims to every HyTime >expert in the world. What I'm suggesting is that all ten of them can >put up with the pain in the interest of creating a less rebarbative >terminology for the teeming millions. Ouch. Stop. You're hurting me. Note that HyTime does retain the term "link end", but it refers to the union of the members of an anchor, the anchor description (nee "end term") if any, and the anchor role name. It's a data object that occurs in the HyTime semantic grove but that has no direct syntactic analog (because it's constructed from several different syntactic bits). Thus, I think there's less conflict between "link end" used more informally as Jon suggests and HyTime's use of the term than one might think. >Think of it as a Christmas present. Do I have to send a thank-you note? 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, 27 Dec 1996 16:11:00 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: clink/ilink direction (Was: anchor awareness) At 08:52 PM 12/25/96 -0800, Jon Bosak wrote: >If we set aside the last possibility and Eliot's invisible wrapper >scheme, then what we seem to be left with is a clear reason to define >a contextual link mechanism for general Internet use in our first link >specification document and a possible case to be made for defining an >independent link mechanism for intranets that we may want to put in a >first link specification document or may want to defer for a later >version. > >Is that right? Yes. 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, 27 Dec 1996 16:11:06 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: clink/ilink direction (Was: anchor awareness) At 05:04 PM 12/27/96 -0500, David G. Durand wrote: > A "grove" is just a new name for what everyone else in the world calls >a "parse tree". Not exactly correct: groves are a new name for what everyone else in the world calls a direct graph data structure. It happens that one obvious application of directed graphs is the representation of parse trees, but that's not the only thing groves are used for. Groves are useful because the provide the following features on top of the basic directed graph of nodes concept: 1. Optimization for the representation of parsed SGML documents and things more or less like SGML documents. 2. A clear and convenient semantic distinction between "content" nodes and other nodes (thus the notion that a single grove contains multiple distinct "content trees", thus "grove"). 3. Provides a standardized abstraction mechanism divorced from the implementation issues. Thus, in the XML discussion, groves are useful because they are more complete than ESIS for discussing processing the results of parsing and they provide a common, implementation-independent data structure for discussing location addressing. We can't do either coherently without some sort of common abstraction. Groves exist. Ergo, why not use groves in our discussions? Now we could avoid parse trees by using byte offsets, but >given that addressing bytes in markup does not usually make sense, we will >need to have the parse tree anyway -- that's what structural addressing is >founded on. As far as I can tell, the details of groves are irrelevant to >XML, unless we decide that we have to explain how XML linking can be >treated as HyTime linking. I don't think they're irrelevant because I don't think you can discuss location addressing in an open environment without something like groves. We had to invent groves to solve exactly that problem in trying to rationalize DSSSL and HyTime. XML will have the same problem and will need the same solution. > Most of the difficulty seems to be understanding the HyTime model and >terminology, not the basic hypertext functionality. I think that HyTime's >tendancy to complicate the simpleis skewing the discussion. HyTime >terminology is a strange mix of de novo terms and new meanings for old >terms. But semantically, an ilink is no more complicated than a record in a >database that contains external keys. And it has the same shortcoming: you >have to "join" the ilink against a relevant document for it to be >meaningful. We need not prespecify the joins that an XML linking engine >should support, but we need to define the mechanisms to enable them. I think I've said more or less the same thing on a number of occasions: the parts of HyTime XML needs are *simple*. We haven't discussed anything for XML that isn't the simplest application of the most basic concepts of hyperlinking, ideas that have been around for going on 30 years and implemented in any number of ways (many lost during the great extinction of 1987 when the Hypercard commet hit and apparently obliterated the memory of most of the research done up to that 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: Fri, 27 Dec 1996 16:11:03 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: clink/ilink direction (Was: anchor awareness) At 09:07 AM 12/27/96 -0800, Jon Bosak wrote: >I think that there is general agreement that ilinks are highly >desirable. The question is whether enabling ilinks requires the >application to know the entire grove, which in the general case would >mean knowing the entire Web as a grove. Steve and Eliot seemed to be >saying that it would be necessary for the application to know the >grove; you seem to be saying that it would not. First, it's not about groves, but about the set of documents you might have to parse into groves and whether or not you need to do that in advance of allowing any link traversal. Second, I have been explicitly saying that you do *not* necessariliy need to have pre-parsed everything--there are cases where it is clearly impossible to do so. 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, 27 Dec 1996 16:26:02 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: anchor awareness (was Re: Richer & richer semantics?) At 02:27 PM 12/23/96 -0800, Terry Allen wrote: >Eliot writes: >| >No, because A's NAME isn't an ID in HTML. It's just a CDATA label. >| >That's true of HTML 3.2, also, and there will be nothing to stop >| >people doing the same in XML (and for the same reasons), although >| >in XML they may also use IDs (production 52). >| >| Good point, although there's no reason the HTML NAME attribute *couldn't* >| be declared as an SGML ID--it has to be unique within the document. Of >| course, HTML has a very expansive definition of what constitutes a name or >| name start character... > >Er, no. There is no requirement in RFC 1866 that A's NAME be unique within >the document, and in fact the absence of such a requirement could eventually >become a feature of HTML by facilitating n-ary links. And HTML's >definition of a name start character is exactly the RCS's. Ugh. I didn't realize that. I can see the benefit, although I would think that 999 times out of a 1000 the intent will be to uniquely identify parts of HTML documents, especially since none of the Web browsers I know of support multi-object link ends (at least IE and Netscape don't appear to). There is generally a distinction between a "label" and a "name", where labels need not be unique (ignoring programming languages that use unique labels) and names, which are unique within some name space. I would argue that HTML has confused these two and seriously undermined the general concept of NAME with the NAME attribute of the A element. Of course, since we don't have to worry about replacing HTML or even emulating it, it's a moot 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: Fri, 27 Dec 1996 18:57:57 -0600 From: len bullard To: Jon Bosak CC: w3c-sgml-wg@www10.w3.org Subject: Re: clink/ilink direction (Was: anchor awareness) Jon Bosak wrote: > > If I were an implementor I would say that this is handwaving. Given > the depths of difficulty we have glimpsed during this discussion, I > don't think it will be very convincing to say that finding ilinks is > not our problem. It seems to me that finding ilinks is exactly our > problem. > > Jon That's easy. It's a file. A collection. XML apps define food for applets. How do we identify to the handler that an ilink is needed? Conventionally, we have pointed at them with clinks. Unconventionally we have pointed backwards from the ilink into the document, a la an inverse index. Text that is anchored (still directional but into text not out), by the ilink does not know that it is linked. If it is a control, it knows that. This way, as many ilinks as we need can point to the same object. Is an ilink a: o syntactic device of XML? o a general form any language uses similar to required virtual interfaces? We can't well define linking for the system without considering behavioral scripting. We are in the SGML-narcicissm of data declaration. That limits our view, perhaps. To enable XML to easily work with scripts, we have to plan for that when we work on hyperlinking. One problem for us is to find a way to have script nodes that are easy for the XML engine to handle, and still maintain a data declaration approach. VRML uses a fairly neat technique. Like XML, it's just a node language of types. To create behavioral relationships, they declare route statements. They look like this: ROUTE TimerTalos.fraction_changed TO TalosOrbit.set_fraction # send the eventOut timer click to eventIn motion interpolator ROUTE TalosOrbit.value_changed TO TalosSystem.set_rotation # Send the motion interpolator event out to the event in # of the Space (vrml transforms coordinate systems of # objects) The nice thing about this, it's easy to understand. Works like a patchbay of timer, motion color, etc engines. It is easy to hook scripts because they are just another routed object of exposed events. Route to well-defined interfaces of events and properties. Easy to understand and also, minimal syntax! I bring it up because it is essentially an independent link other than not being addressable. I offer this example as an alternative kind of thinking on the problem of creating a scripted hub for XML multimedia. len Date: Sat, 28 Dec 1996 02:25:33 +0000 From: Lou Burnard To: U35395@UICVM.UIC.EDU CC: W3C-SGML-WG@www10.w3.org, lou@vax.ox.ac.uk Subject: Re: locating capabilities vs. anchor awareness On Mon, 23 Dec 1996 12:28:03 -0800 Derek Denny-Brown said: > ... A number of people have expressed interest in using the TEI >style linking (having never used seen TEI, that is difficult for me >to evaluate. Anyone have a good reference for me where I could get |>some info/examples of TEI locators?). | |I believe Lou Burnard is currently working on a free-standing |document describing TEI extended pointers, to make it unnecessary to c A first draft of a brief tutorial intro to the TEI extended pointer syntax is now available at http://users.ox.ac.uk/~lou/wip/XR.htm For authoritative information, it is still best to onsult the TEI Guidelines themselves. In the meantime, for the TEI Guidelines as a whole, try http://etext.virginia.edu/TEI.html http://dynaweb.ebt.com:8080/usrbooks/teip3/1.toc For chapter 14, on "Linking, Segmentation, and Alignment" try http://dynaweb.ebt.com:8080/usrbooks/teip3/25659 http://etext.virginia.edu/bin/tei-tocs?div=DIV1&id=SA -C. M. Sperberg-McQueen Date: Fri, 27 Dec 1996 21:39:59 -0500 From: gtn@ebt.com (Gavin Nicol) To: bosak@atlantic-83.eng.sun.com CC: w3c-sgml-wg@www10.w3.org, bosak@atlantic-83.eng.sun.com Subject: Re: clink/ilink direction (Was: anchor awareness) >I think that there is general agreement that ilinks are highly >desirable. The question is whether enabling ilinks requires the >application to know the entire grove, which in the general case would >mean knowing the entire Web as a grove. Steve and Eliot seemed to be >saying that it would be necessary for the application to know the >grove; you seem to be saying that it would not. In general, I would say you only really need to know any part of the Web during link creation, where you need to know which documents contain the link ends. The ilink data can then be stored in a database, which can be queried when a document is retreived. Date: Fri, 27 Dec 1996 22:04:03 -0500 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu CC: w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh >>I don't think so. In many ways, defining links as objects is a good >>way to start, because then you can work back to the representation >>required at the protocol and definition ends of the system. > >Actually, this seems a terrible way to start (or finish). Object models are >fundamentally oriented to the definition of _behaviours_. I am firmly >committed to the notion that we should think of links as delcarative >information about relations between documents and document portions. I agree that we should be focusing on definition, rather than behavioral aspects. I disagree that object models must fundamentally be oriented toward behaviour. At the simplest level, an object is just data and a set of methods for manipulating it. The simplest method set is simply a get/set group of methods for accessing and setting properties of the object. That said, the reason why I think it might be good to start thinking about object models is that it is a good way of clarifying what people want from links (ie. clarify the semantics that people attach to links, and then derive the required data members). We can then use to move back to the actual target of our WG: definition specifications. I never said I saw a set of IDL interfaces as being a the desired output from this WG, and ideed, even quired whether it was in our charter to do anything about semantic definition. >We will probably require operational semantics for some techniques of >locating document portions, but we should not assume that there is >any single _right_ thing to do with a link and its endpoints, once >located. Right, but there is nothing wrong with having some simple object definiton which shows what properties the object is to contain. >I would be tempted to put link behavior into our XML style sheets, >but maybe a separate link style sheet will work better. This is the model I advocate strongly, as some people on this WG are quite aware (Len, Martin, and Steve to name a few). >In any case we should not conflate the presentation and interaction >aspects of linking with the declarative, and "semantic relationship" >aspect of linking. Absolutely. I would prefer us to define a set of data which comprises a link, and leave interpretation to the application. >>>What I was aiming at was the link semantics of the XML handler. >>>We more or less know what the current crop of desktops are doing >>>and we have listed those. >> >>Sure, this is a good *starting* point. > >For an interaction and linking style language: not for a link-definition >language. I think we are violent agreement, but have a slightly different angle on things. All the things you outline above, are things that I most certainly agree with. My point is simply that unless we know what the objects are that we wish to define, it seems quite difficult to define them. The process of actually modelling links as objects, would give us a set of object definitions that would be *trivial* to convert between definition languages. I lergely do not care whether we define the objects in SGML, XML, PASCAL, C, IDL, LISP, or whatever. Once we have the object definitions, the rest is just syntax. The only advantage in using IDL, or something link it, is that we could also define some of the common semantics that people associate with a link (eg. link traversal). As I said though, ultimately, this would lead to us modelling the entire Web, which is not something I particularly want to do, though it is certainly a possible future. Date: Fri, 27 Dec 1996 23:21:06 -0600 From: len bullard To: Gavin Nicol CC: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh Gavin Nicol wrote: > > >>I don't think so. In many ways, defining links as objects is a good > >>way to start, because then you can work back to the representation > >>required at the protocol and definition ends of the system. > > > >Actually, this seems a terrible way to start (or finish). Object models are > >fundamentally oriented to the definition of _behaviours_. I am firmly > >committed to the notion that we should think of links as delcarative > >information about relations between documents and document portions. I agree. I disagree that object models are fundamentally oriented to behaviors. But if one starts there, behaviors are easy to describe or add. Really, it is a different angle on this discussion. There are a number of good object-oriented programmers here who can help move the hyperlinking discussion along by stating clearly from their point of craft what is needed to support XML hyperlinks. That is, in the data declaration of a hyperlink, what minimal pieces of information are there and are always there for any class of hyperlinks. > I agree that we should be focusing on definition, rather than > behavioral aspects. I disagree that object models must fundamentally > be oriented toward behaviour. At the simplest level, an object is just > data and a set of methods for manipulating it. The simplest method set > is simply a get/set group of methods for accessing and setting > properties of the object. Right. > That said, the reason why I think it might be good to start thinking > about object models is that it is a good way of clarifying what people > want from links (ie. clarify the semantics that people attach to > links, and then derive the required data members). We can then > use to move back to the actual target of our WG: definition > specifications. Right. > I never said I saw a set of IDL interfaces as being a the desired > output from this WG, and ideed, even quired whether it was in our > charter to do anything about semantic definition. I will be interested to see if we can avoid it forever. A >We will probably require operational semantics for some techniques of > >locating document portions, but we should not assume that there is > >any single _right_ thing to do with a link and its endpoints, once > >located. I understand. I repeat, the designers will be in there looking for Right, but there is nothing wrong with having some simple object > definiton which shows what properties the object is to contain. > > >I would be tempted to put link behavior into our XML style sheets, > >but maybe a separate link style sheet will work better. > > This is the model I advocate strongly, as some people on this WG are > quite aware (Len, Martin, and Steve to name a few). Which? Behavior in stylesheet or separate link stylesheet? Is the issue of link behavior in stylesheets, or links defined in stylesheets, the crux of the difference of approach by David and the Hytime approach? Jon Bosak mentioned to me in Seattle that some were coming to this project of the opinion that links should be defined in the stylesheet. If this is a proposal, it should be out on the table to be explored and contrasted with other proposals such as those from the HyTime supporters. That indicates that we CAN'T discuss hyperlinking separate >from stylesheets. > >In any case we should not conflate the presentation and interaction > >aspects of linking with the declarative, and "semantic relationship" > >aspect of linking. > > Absolutely. I would prefer us to define a set of data which comprises > a link, and leave interpretation to the application. As do I. Again, implied behavior is already there in HTML. How do we avoid it? > >>>What I was aiming at was the link semantics of the XML handler. > >>>We more or less know what the current crop of desktops are doing > >>>and we have listed those. > >> > >>Sure, this is a good *starting* point. > > > >For an interaction and linking style language: not for a link-definition > >language. Sounds good, but so far, how many existing applications work like that? This is an implementation implication and I think we should stop and look at this very carefully. An implied behavior in markup makes it easy to send an instance with no stylesheet. > All the things you outline above, are things that I most certainly > agree with. My point is simply that unless we know what the objects > are that we wish to define, it seems quite difficult to define > them. The process of actually modelling links as objects, would give > us a set of object definitions that would be *trivial* to convert > between definition languages. It is another way to look at the problem. > I largely do not care whether we define > the objects in SGML, XML, PASCAL, C, IDL, LISP, or whatever. Once we > have the object definitions, the rest is just syntax. The only > advantage in using IDL, or something link it, is that we could also > define some of the common semantics that people associate with a link > (eg. link traversal). Consider the case where the object has everything it needs to handle the XML document type and no separate stylesheet language is needed. Is that a valid application of XML? len Date: Sat, 28 Dec 1996 12:21:37 +0000 To: gtn@ebt.com (Gavin Nicol) From: Martin Bryan Subject: Re: Anchors Aweigh Cc: w3c-sgml-wg@www10.w3.org At 22:04 27/12/96 -0500, Gavin Nicol wrote: >>In any case we should not conflate the presentation and interaction >>aspects of linking with the declarative, and "semantic relationship" >>aspect of linking. > >Absolutely. I would prefer us to define a set of data which comprises >a link, and leave interpretation to the application. I second this. For stage one we need to learn how to identify what it is we need to link to and how to manage link definitions in a way that will preserve them over time. (This latter will be the killer part of a good linking mechanism.) Only when we have mastered this part of the problem should we consider how to 'standardize' the behaviour of links. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Sat, 28 Dec 1996 09:34:55 -0600 From: len bullard To: Martin Bryan CC: Gavin Nicol , w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh Martin Bryan wrote: > > At 22:04 27/12/96 -0500, Gavin Nicol wrote: > >>In any case we should not conflate the presentation and interaction > >>aspects of linking with the declarative, and "semantic relationship" > >>aspect of linking. > > > >Absolutely. I would prefer us to define a set of data which comprises > >a link, and leave interpretation to the application. > > I second this. For stage one we need to learn how to identify what it is we > need to link to and how to manage link definitions in a way that will > preserve them over time. (This latter will be the killer part of a good > linking mechanism.) Only when we have mastered this part of the problem > should we consider how to 'standardize' the behaviour of links. Everyone agrees that a data declared link is what we are after. XML is SGML and SGML gives us no other alternative. Selah. I don't think you can avoid behavior for long. At some point, implicitly or explicitly a link is used to do something. If you embed it in the text a la To: Martin Bryan , Gavin Nicol , w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh len bullard wrote: > > So far, this discussion seems to have only two alternatives: > TEI or HyTime and HyTime is a standard which Eliot assures us > is able to express TEI comfortably. > Sorry. Forgot two other implicit proposals: 3. Define a stylesheet linking language. 4. Do whatever Panorama does. 3 is not defined yet. 4 is not a definition. len bullard lockheed martin Date: Sat, 28 Dec 1996 09:49:42 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Anchors Aweigh At 09:34 AM 12/28/96 -0600, len bullard wrote: >TEI or HyTime and HyTime is a standard which Eliot assures us >is able to express TEI comfortably. Just to be pedantic: HyTime is a standard with which TEI can be integrated comfortably. TEI expresses itself and the interface between a HyTime engine and a TEI engine is well defined in terms of the property sets, groves, and grove plans both act on. Without reference to Tim's original post, I think the issues are: 1. What syntax(es) to use for representing addresses? 1.A HyTime location addresses (some or all) only (must include URLs as a query notation that must be supported, in addition to being used for entity external identifiers.). 1.B TEI locators only 1.C Some combination of 1.A and 1.B 1.D Only in style sheets 2. How to bind addresses to links 2.A direct only 2.B Indirect only 2.C Direct and indirect 3. Whether or not to define links that can be completely independent. 4. What syntax to use to represent links (probably separate from addresses). Here the choices seem to be: 4.A SGML elements of the HyTime model without trickery (ID/IDREF primary addressing method plus indirection) 4.B SGML elements of the HyTime model with refloc/queryloc stuff to make use of non-HyTime addresses easier for authors. 4.C SGML elements of some other model that can't be reconciled with HyTime (I don't think such a thing can be made, but I won't rule it out). 4.D Define only in style specifications 5. What formalism to use in defining links and link types: 5.A Strict requirement of HyTime's linktype/anchor role model 5.B No required model (no need to define link types or anchor roles) 5.C Both 5.A and 5.B (be formal or not, we don't care). Note this is HyTime as of the TC. 5.D Some other model that I'm not aware of 6. What base behaviors to define for links or link types, if any. 7. How to allow authors or users to define or modify link behaviors, if allowed at all: 7.A Style sheets only (e.g., DSSSL language for describing link behavior. 7.B Attributes on link elements 7.C Some other mechanism 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: Sat, 28 Dec 1996 11:39:05 -0600 From: Robin Cover To: w3c-sgml-wg@www10.w3.org Subject: XML and groves/property sets On December 22, Steven R. Newcomb wrote: > I would say there's appreciable consensus about the grove paradigm. > SP does it, JADE does it, MarkMinder does it, and the next version of > HyMinder is about to do it. Three international standards do it, and > a fourth (SGML itself) will undoubtedly do it next year. (Come to > think of it, Fujitsu Labs put a layer over old HyMinder in order to do > DSSSL with it.) Alex Milowski is doing it. Several topflight people > are talking about doing it. If you already have groves, it would be > ridiculous to do any kind of hyperlinking without using the grove > paradigm. If we assume the use of groves and property sets for > expressing the object model of XML documents, the anchor awareness > question becomes "merely" one of how elaborate the relationships > involved in hyperlinking should be. > > I was asking the question from the other angle, assuming that we have > NOT yet decided to use the grove paradigm for XML. Without groves, > anchor awareness is a huge headache. I think a decision to do anchor > awareness pretty much necessitates moving to the grove paradigm. If anyone has responded directly to this issue, I have missed the response in the flurry of year-end "anchor" discussions. Yes, I have heard that the concern for "anchor awareness" (expressed exactly in those terms, and perhaps even the concept) is not a concern shared by everyone. My question has to do specifically with XML's disposition toward groves and property sets, as explained in similar words by Eliot Kimber on Dec 23rd: > With the TC, HyTime processing can now be integrated with any addressing > scheme you care to support. All you have to do is define for the HyTime > engine what sort of nodes you'll be returning, which you do by defining a > property set and creating the appropriate software to provide a "grove > view" of the data. If you're not using a HyTime engine, then just do what > you would have done anyway. > > As I've said in other notes to this group, this should be almost trivial > for TEI locators because they're both designed to address SGML documents > and well documented (and implemented to some degree by at least two > browsers). This means that defining how TEI locators address groves, SGML > document groves in particular, should be very straight forward, and > adapting the existing facilities to support whatever XML needs shouldn't be > hard (it may already be inherent in those tools' functionality). I have heard several contributors stress "keeping it simple" for the sake of the HTML crowd -- wishing not to put the XML spec out reach by virtue of (using HyTime's sometimes) non-intuitive use of hypertext terms, and such. Fair enough. But the points made by both Eliot and Steve (I think) sound very worthy of the ERB's attention, and I hope they will be addressed -- ultimately in terms of reference to the HyTime TC, and particularly in terms of reference to groves and property sets: (1) If the HyTime TC and SGML Extended Facilities offer a framework for defining what we know we want/need in hypertext linking, including the critical issue of link semantics, then it makes sense to try to define -- at least for the benefit of *some* people, and for XML's later versions -- XML hypertext functionality in terms of groves and property sets. Design for the future, not for today: "today" is already past. (2) If the definition of XML's hypertext facilities in terms of the "groves and property sets" framework yields a specification that seems too difficult for the HTML crowd to uderstand, then (a) translate the language of that specification, defined at that higher level of abstraction, into language that's more accessible, but (b) don't let the difficulty of the design language tyrranize the ERB's efforts to "get it right for the future." I sense that some of the XML design is just too "backward looking" because a key design goal is to keep XML "simple." What people are doing on the Web *today* isn't necessarily simple: it's profoundly complex. I agree with Len that if XML doesn't offer an adequate framework for doing these complex things, developers will forge ahead, as always, with proprietary ad hoc solutions to their real problems. Just my 2 cents... Robin ------------------------------------------------------------------------- Robin Cover Email: robin@acadcomp.sil.org 6634 Sarah Drive Dallas, TX 75236 USA >>> The SGML Web Page <<< Tel: +1 (972) 296-1783 (h) http://www.sil.org/sgml/sgml.html Tel: +1 (972) 708-7346 (w) FAX: +1 (972) 708-7380 ========================================================================= Date: Sat, 28 Dec 1996 12:51:13 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org Subject: unmarked linkend awareness by XML engines (Jon Bosak:) >> | "Does an anchor know that it is an anchor?" > My first conclusion is that this is an unfortunate way to phrase the > question (sorry, Steve). If I understand correctly, no HyTime anchor > can be assumed to be self-aware even in the metaphorical sense because > in the general case there may be nothing attached to the anchor to > identify it as such. If a link addresses an unmarked span of > characters somewhere in hyperspace then *something* is aware that the > span is a HyTime anchor, but that something is surely not the unmarked > character string but rather a HyTime application. Exactly right. I wish I had said it that clearly. > So I suggest that we drop the whole > self-awareness trope; it just gets in the way. This discussion has indeed shown that "anchor awareness" was a confusing way for me to characterize the phenomenon I was ineptly trying to give a convenient, intuitive name. I disagree that the underlying question gets in the way of our discussion. I still see it as absolutely fundamental: "Will XML engines will be responsible for `knowing' that a linkend is a linkend when such a linkend is *not* marked up as a linkend?" I still haven't yet seen consensus explicitly emerge on this question, although there has been plenty of good and relevant discussion. (Dave Durand:) > But semantically, an ilink is no more complicated than a record in a > database that contains external keys. Right. > ...there is an open set of reasonable > ways to find documents to process together: the choice of which documents > will be processed together is an application matter. Right. > But we _do_ need to > say what an ilink means, and deal with the fact XML linking engines must be > prepared to process multiple entities (whether serially or simultaneously > does not matter) in order to correctly handle ilinks. Right. > Which documents are > processed is not necessarily our concern. I disagree with this assertion. If XML supports ilinks, there must certainly be a way of establishing a finite list of links for which the XML engine is responsible for knowing the anchors (er, "linkends"). (Otherwise, the XML engine must be responsible for all the XML links on the entire Web, which I think we all agree is an insupportable scenario.) This means establishing, somehow, a finite list of documents that contain such links. HyTime calls such a finite list a "Bounded Object Set" (BOS). In HyTime, the BOS is always application-definable, but it is also expressible interchangeably, as a suggestion, in terms of an arbitrarily pruned entity tree. If XML supports ilinks, or n-directional linking, or, therefore, what I have been imprecisely terming "anchor awareness," I think it's necessary to have a way of expressing this pruned entity tree (BOS) notion in XML, too. Best regards, --Steve Steven R. Newcomb President voice +1 716 271 0796 TechnoTeacher, Inc. fax +1 716 271 0129 (courier: 23-2 Clover Park, Internet: srn@techno.com Rochester NY 14618) FTP: ftp.techno.com P.O. Box 23795 WWW: http://www.techno.com Rochester, NY 14692-3795 USA Date: Sat, 28 Dec 1996 10:32:25 -0800 To: w3c-sgml-wg@www10.w3.org From: Ralph Ferris Subject: Re: anchor awareness (was Re: Richer & richer semantics?) >At 02:27 PM 12/23/96 -0800, Terry Allen wrote: There is no requirement in RFC 1866 that A's NAME be unique within >>the document, and in fact the absence of such a requirement could eventually >>become a feature of HTML by facilitating n-ary links. And HTML's >>definition of a name start character is exactly the RCS's. > >At 04:26 PM 12/27/96 -0900, Eliot Kimber wrote: >Ugh. I didn't realize that. I can see the benefit, although I would think >that 999 times out of a 1000 the intent will be to uniquely identify parts >of HTML documents, especially since none of the Web browsers I know of >support multi-object link ends (at least IE and Netscape don't appear to). > >There is generally a distinction between a "label" and a "name", where >labels need not be unique (ignoring programming languages that use unique >labels) and names, which are unique within some name space. I would argue >that HTML has confused these two and seriously undermined the general >concept of NAME with the NAME attribute of the A element. Note that the Object Proposal does introduce unique IDs: "OBJECT has the following attributes: ID Used to define a document-wide identifier. This can be used for naming positions within documents for use as destinations of hypertext links. An ID attribute value is an SGML NAME token. NAME tokens are formed by an initial letter followed by letters in the range a-z and A-Z (no accented characters), digits, "-" and "." characters. It may also be used by the user agent or objects in the document to find and communicate with other objects embedded in the document." Regards, Ralph E. Ferris Project Manager, Electronic Publications Fujitsu Software Corporation Date: Sat, 28 Dec 1996 17:58:52 -0600 From: len bullard To: "David G. Durand" CC: "W. Eliot Kimber" , w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh David G. Durand wrote: > > I am one of the object programmers on this list. One of the problems I > see with this is that I want to know what the data is, not how someone else > thinks they should design my applications. The object of the quest is to see if this is a way to define what any XML system should be able to handle vis a vis hyperlinks. The point was to avoid the Spy Vs Spy arguments of definitions by grounding it in a programming approach most of us understand and none of us own or have deep feelings about. > I would be more snaguine about > OO modelling of links if I had ever: > A. Seen an object model for hypertext that more than the author agreed > was reasonable. The VRML community did it over a summer. In less than a year, the apps were out and being used. It can be done. We have the somewhat more difficult problem of a markup approach as opposed to a purely "these ARE the objects" node set. > B. saw any proposed, meaningful applications of inheritance in defining > the semantics of the two kinds of links we are considering (multi-end > clink, multi-end ilink). Then they are non-instantiable. Abstract classes. > C. any reason to apply the operational aspects (methods) of OO > programming. We don't even need "set" methods in XML, so I don't see that > OO field lists, with "get" methods only, are any different from simple > lists of attributes. That is the idea I think would be useful to kick around if only to eliminate it from consideration. Eventually, we have to work with scripting so, defined interfaces to an abstract XML document type might be one way around the problem of lots and lots of XML document types, each with it's own, as David Megginson pointed out, "badly written parser". > We don't need to sprinkle OO magic dust over declarative linking to make > XML fly, we just need to decide on a syntax, and some simple metadata. (I > think this is Gavin's model, and I'm not surprised that if this is so, we > are in agreement again...) You could be right. This is an avenue to define something we could all count on working moreorless the same way every time, as well as establish a basis for a shared class of XML operations and data definitions. VRML made this approach work very well because it cuts away a lot of academic haggling and gets to an implementation in short fashion. That is why I can write play the current VRML 2.0 worlds complete with behaviors on any two browsers. I don't claim they all work perfectly, just that they work. If they worked perfectly, I'd consider that magic. you see, what I would really like is the HyTime contingent to explain how the Hytime terms, properties, groves, grove plans, etc. work in an object framework. I know it can be done with TEI, IADS, IDE/AS, DynaText, MIL-PRF-87269, the Philly DTD, MIL-PRF-28001 and every other DTD to which an element type for a link has ever been added. These systems don't interoperate. HTML and VRML do and they aren't even in the same syntax, but they agree on what a hyperlink is and does down to "target=". len Date: Sat, 28 Dec 1996 18:01:08 -0600 From: len bullard To: Terry Allen CC: eliot@isogen.com, w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh Terry Allen wrote: > The implication for XML is only that the syntax of a URN in > XML should be whatever the final URN syntax draft says it is. Thanks Terry. I have fielding's comments but did not think it appropriate to repost them. Mainly, we need to know that the dust hasn't settled. > And that the dust hasn't settled quite yet. Damm! More magic dust! > 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: Sat, 28 Dec 1996 16:18:15 -0800 (PST) From: Terry Allen To: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org Subject: Re: unmarked linkend awareness by XML engines David Durand writes in response to Steve Newcomb: | >> Which documents are | >> processed is not necessarily our concern. | > | >I disagree with this assertion. If XML supports ilinks, there must | >certainly be a way of establishing a finite list of links for which | >the XML engine is responsible for knowing the anchors (er, | >"linkends"). | | No, this is at least in part the user's responsibility. The engine must be | responsible for being able to provide information about links _contained | in_ a document. Other links to that document will only be found if the user | has explicitly or implicitly (via some strategy) specified what other | documents may contain ilinks of interest (for example by opening a bookmark | set of ilinks, or a guided tour set of ilinks, or an annotation set of | links, etc.). So far so good. | >(Otherwise, the XML engine must be responsible for all | >the XML links on the entire Web, which I think we all agree is an | >insupportable scenario.) This means establishing, somehow, a finite | >list of documents that contain such links. HyTime calls such a finite | >list a "Bounded Object Set" (BOS). In HyTime, the BOS is always | >application-definable, but it is also expressible interchangeably, as | >a suggestion, in terms of an arbitrarily pruned entity tree. If XML | >supports ilinks, or n-directional linking, or, therefore, what I have | >been imprecisely terming "anchor awareness," I think it's necessary to | >have a way of expressing this pruned entity tree (BOS) notion in XML, | >too. BTW, Steve, what is the current specification of a BOS? Has it been changed by the TC? | No, we simply have to face the fact that end users are the only ones who | can decide what documents need to be in their processing set. We can't No. As an author and publisher I must be able to indicate *my* view of what that set of documents is, and, of the links in the set, what are relevant to my author-primary view of my own intellectual property. I must also be able to assert (not enforce) via my markup that this view is mandatory (if it is). Consider the case of nuclear reactor documentation in XML governed by an effectivity policy before you assert that the end user must be king. Mechanisms of policy enforcement need not be specified (because enforcement is a function of applications), but the assertion that there is a policy must be supported (because linked metadata is the obvious way to support it). | check the whole world, and we can't just leave it to the author (without | damaging the ability to create external annotations), so we have to leave XML should not have as a design goal the ability to enable promiscuous external annotations unauthorized by the document's owner. The owner may wish to enforce a policy that he does not permit the work to be viewed with annotations (e.g., by not serving to clients that do not guarantee to respect his policy). We are under no obligation to enable grafitti. We may be powerless to prevent it, too. | it to the user (via their application). In other words, XML as a standard | cannot enforce this kind of scoping for the user. All that we need to | specify is how ilinks behave in documents where they are _parsed_ by an XML | processor. In HyTime terms, the BOS will always be the entire web (one of | the reasons I always thought the notion was limited in usefulness). | However, the set of documents an XML processor will be required to | processes is an application (user) decision. As an example we could not | force a browser to pre-fetch linked documents in case they might reference | ilinks that _might_ be of interest. But we must have some mechanism to indicate to the user agent what the bounds of a single work are, something lacking on the Web today. This, too, may lie without the scope of XML linking, but we still need it. An example directly contrary to your point about prefetching: there must be a way in which I can specify that an XML application *must* fetch the linked copyright notice and display it before the main text of my fine literary work. It may be that XML's linking mechanism is not the place to do this, but if not, where do you think *is* the right place? 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: Sat, 28 Dec 1996 18:35:26 -0500 To: "W. Eliot Kimber" , w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: anchor awareness (was Re: Richer & richer semantics?) At 4:26 PM 12/27/96, W. Eliot Kimber wrote: >Of course, since we don't have to worry about replacing HTML or even >emulating it, it's a moot point. Er, we don't have an official goal of replacing HTML (though it may be on some private agendas). On the other hand if we can't emulate it we are dead in the water again. Do not pass go, do not collect more than 200 users. We _must_ be able to emulate html, vile and brain-damaged though it may be. We already faced this in the syntax, let's not waste time on it again in linking semantics. -- 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: Sat, 28 Dec 1996 18:35:22 -0500 To: cbullard@HiWAAY.net, "W. Eliot Kimber" From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Anchors Aweigh Cc: w3c-sgml-wg@www10.w3.org At 2:35 PM 12/28/96, len bullard wrote: >No, this is not the XML standard; it is a way to discuss >the XML standard for hyperlinking in examples that a >programmer would find clear. I plead for help from >the object programmers on the list. I am one of the object programmers on this list. One of the problems I see with this is that I want to know what the data is, not how someone else thinks they should design my applications. I would be more snaguine about OO modelling of links if I had ever: A. Seen an object model for hypertext that more than the author agreed was reasonable. B. saw any proposed, meaningful applications of inheritance in defining the semantics of the two kinds of links we are considering (multi-end clink, multi-end ilink). C. any reason to apply the operational aspects (methods) of OO programming. We don't even need "set" methods in XML, so I don't see that OO field lists, with "get" methods only, are any different from simple lists of attributes. We don't need to sprinkle OO magic dust over declarative linking to make XML fly, we just need to decide on a syntax, and some simple metadata. (I think this is Gavin's model, and I'm not surprised that if this is so, we are in agreement again...) -- 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: Sat, 28 Dec 1996 18:35:09 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: unmarked linkend awareness by XML engines At 12:51 PM 12/28/96, Steven R. Newcomb wrote: >(Jon Bosak:) > "Will XML engines will be responsible for `knowing' that a linkend > is a linkend when such a linkend is *not* marked up as a linkend?" > >I still haven't yet seen consensus explicitly emerge on this question, >although there has been plenty of good and relevant discussion. I say absolutely not. In some sense the entire web is a candidate, and this knowledge is impossible. Link targets will in general not know that they are targets. We will have a bag of kludges and heuristics to deal with this fact (Altavista, anyone), but we cannot change it. >(Dave Durand:) > >.... Points of agreement deleted. > >> Which documents are >> processed is not necessarily our concern. > >I disagree with this assertion. If XML supports ilinks, there must >certainly be a way of establishing a finite list of links for which >the XML engine is responsible for knowing the anchors (er, >"linkends"). No, this is at least in part the user's responsibility. The engine must be responsible for being able to provide information about links _contained in_ a document. Other links to that document will only be found if the user has explicitly or implicitly (via some strategy) specified what other documents may contain ilinks of interest (for example by opening a bookmark set of ilinks, or a guided tour set of ilinks, or an annotation set of links, etc.). >(Otherwise, the XML engine must be responsible for all >the XML links on the entire Web, which I think we all agree is an >insupportable scenario.) This means establishing, somehow, a finite >list of documents that contain such links. HyTime calls such a finite >list a "Bounded Object Set" (BOS). In HyTime, the BOS is always >application-definable, but it is also expressible interchangeably, as >a suggestion, in terms of an arbitrarily pruned entity tree. If XML >supports ilinks, or n-directional linking, or, therefore, what I have >been imprecisely terming "anchor awareness," I think it's necessary to >have a way of expressing this pruned entity tree (BOS) notion in XML, >too. No, we simply have to face the fact that end users are the only ones who can decide what documents need to be in their processing set. We can't check the whole world, and we can't just leave it to the author (without damaging the ability to create external annotations), so we have to leave it to the user (via their application). In other words, XML as a standard cannot enforce this kind of scoping for the user. All that we need to specify is how ilinks behave in documents where they are _parsed_ by an XML processor. In HyTime terms, the BOS will always be the entire web (one of the reasons I always thought the notion was limited in usefulness). However, the set of documents an XML processor will be required to processes is an application (user) decision. As an example we could not force a browser to pre-fetch linked documents in case they might reference ilinks that _might_ be of interest. We may well want to consider adding additional notations to express that some document _may_ be processed when a document is processed. Sort of a "This document best when parsed along with ..." notation. -- 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: Sat, 28 Dec 1996 18:35:30 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Suggestion: A link model A few suggestions for things that I think we need. I am describing these somewhat like architectural forms, and somewhat like algebraic data types. I am using prose, to avoid the prejudicing effect of inventing a new notation, or abusing an old one. I have built on some HyTime concepts, because they best reflect the relationship of markup and hypertext. However, I'm still unsure as to whether HyTime architectural forms are appropriate. However, the set of declarations here seems sufficient for a lot of stuff. A separate list like this should also be made for link behaviors, but I strongly urge that we separate the behavior from the markup. I think folding it into the DSSSL stylesheet would be best, but a separate linking-behavior stylesheet would also be OK. We require four primary kinds of objects (these are things that occur in documents and would get single tags): clink, ilink, location, anchor. LINK (abstract superclass of ilink and clink) A link has 1-n linkends. Linkends record a relationship to other locations. The linkend locations can be specified by the ID of an element in the containing document, or a location indicated by a TEI extended pointer. If the location is a "location" object, the designated destination is the object pointed to by that location (1 level of location ladder only, for simplicity). A link has an optional "link explainer". This is a string, suitable for user-consumption, describing the intent of this particular link. A link has (perhaps optional?) link-meta information, specifying further user and application information about the link's data type. CLINK: Linkend override: One linkend is the point (if empty) or scope (if content containg) where the clink markup occurs. ILINK An ilink has no properties other than those of the "abstract link". LOCATION A location may point via an ID of an element within its containing document, a TEI extended pointer, or a HyTime query (we need a list of necessary location methods the TEI does not accomodate, and a way for extending the kinds of location by the author, if desired. Some subset of HyTime location address seems right here, but how small (or null) the subset should be is not yet clear to me.) This is a place for discussion, and extensibility. ANCHOR An anchor is an element that exists _solely_ to facilitate the addressing of a document portion by clinks or ilinks. Other than being addressable, it should have no effect on processing. Dependent objects: LINK-META We need to associate some meta-information with the ends of links. This allows multi-ended links to identify the function of link ends with something more meaningful than sequential order. Link-meta contains (for each link end) A link-type. These should be specifiable by default (say for links with fixed numbers of endpoints), on the instance (for links with variable number of endpoints), and maybe by some combination (Steve DeRose and I proposed methods to extend HyTime to accomodate this -- we don't know what's happened in the TC process). A linkend explainer. This is a user-readable string (like an alt string) that should be displayed to explain the meaning of the data located by this link end. It should be displayed, if the interaction style enables such display. SUMMARY These are the things I want in XML linking. I could live without explicit anchors and locations, but I think many will want them. Also, locations are a convenient place to extend link elements without complicating the syntax for simple links. Anchors are really formally unnecessary, as they can simply be any elements that do not affect formatting. However, users and authors might be served if it is possible to say that an element _should not_ affect presentation. -- David (who sprinkled a little OO magic dust after all) I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Sat, 28 Dec 1996 14:16:45 -0800 (PST) From: Terry Allen To: cbullard@hiwaay.net, eliot@isogen.com Subject: Re: Anchors Aweigh Cc: w3c-sgml-wg@www10.w3.org Len writes: Also note, at this time, URN definitions conflict with URL definitions (per Roy Fielding's post to uri.bunyip). Prepending the prefix appears to be illegal. Someone more familiar with theseissues should investigate if this has implications for use of URNs and FPIs in XML. As I understand it, there are some minor issues in aligning URN and URL syntax. Roy has objected to URN:, but the URN WG was overwhelmingly in favor of requiring it at the San Jose meeting, and it was pointed out that if URL: had been required much fuss could have been avoided. So this is an exercise in standards alignment rather than some deep problem (URLs and URNs don't have to share a syntax, but to the extent they do, so much the better). The implication for XML is only that the syntax of a URN in XML should be whatever the final URN syntax draft says it is. And that the dust hasn't settled quite yet. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Date: Sat, 28 Dec 1996 16:40:45 -0800 (PST) From: Terry Allen To: w3c-sgml-wg@www10.w3.org Subject: URLs/MIME only? [was Anchors Aweigh] Len Bullard writes: | you see, what I would really like is the HyTime contingent | to explain how the Hytime terms, properties, groves, grove | plans, etc. work in an object framework. I know it can | be done with TEI, IADS, IDE/AS, DynaText, MIL-PRF-87269, | the Philly DTD, MIL-PRF-28001 and every other DTD to | which an element type for a link has ever been added. | These systems don't interoperate. HTML and VRML do | and they aren't even in the same syntax, but they agree | on what a hyperlink is and does down to "target=". They do so because the behavior of the link is implied by its context and because the addressing is completely contained within the URL. The commonality is in the use of URLs. So *purely* as a point for discussion, let me pose the following: The Web uses URLs (and to some degree, nascent URNs) for link addressing. Linking methods are expressed mostly within URLs, and URL schemes are not necessarily tied to the data formats of the target entities. XML is specifically intended for use on the Web. Why should XML specify any mechanisms for hyperlinking other than those already in use? How are XML agents to interoperate with other Web agents if they do not confine their expression of linking semantics to URLs (maybe plus URNs), HTTP headers (generated from metadata?), and MIME types? 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: Sat, 28 Dec 1996 16:02:48 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: clink/ilink direction (Was: anchor awareness) At 4:11 PM 12/27/96, W. Eliot Kimber wrote: >At 05:04 PM 12/27/96 -0500, David G. Durand wrote: >> A "grove" is just a new name for what everyone else in the world calls >>a "parse tree". > >Not exactly correct: groves are a new name for what everyone else in the >world calls a direct graph data structure. It happens that one obvious >application of directed graphs is the representation of parse trees, but >that's not the only thing groves are used for. Groves are useful because >the provide the following features on top of the basic directed graph of >nodes concept: trees are directed graphs. Are you saying that groves can include cyles of nodes (ie node that are their own ancestors), or multiple inheritance (directed _acyclic graphs_)? If not, groves are part of that subset of directed graphs known as trees, and you are spreading more smoke into the air, instead of shedding light on the issues. >1. Optimization for the representation of parsed SGML documents and things > more or less like SGML documents. viz, trees. >2. A clear and convenient semantic distinction between "content" nodes and > other nodes (thus the notion that a single grove contains multiple > distinct "content trees", thus "grove"). Rooted forest? (just interested in mapping HyTime's creative terms into standard math/CS terminology) Actually this sentence means very little to me, except that it seems to reflect the fact that SGML processors need access to so-called "insignificant" information, so that we need to label all nodes with a significant/insignificant flag. >3. Provides a standardized abstraction mechanism divorced from the > implementation issues. Ah, kind of like a parse tree. In fact, exactly like. >Thus, in the XML discussion, groves are useful because they are more >complete than ESIS for discussing processing the results of parsing and >they provide a common, implementation-independent data structure for >discussing location addressing. ESIS is certainly incomplete. I assume that this refers to point 2 (more complete than ESIS). And implementation independence just means that there is a defined data model. > >We can't do either coherently without some sort of common abstraction. >Groves exist. Ergo, why not use groves in our discussions? My inclination agaist groves stems from: 1. The complexity of groves (reflecting the complexity of full SGML parsing). 2. The unique terminology of HyTime, which does not correspond with standard terms for standard entities. 3. The fact that I have not yet seen anything in XML that would not fit usefully in a standard parse tree model, so I fail to see the avantage of adopting a new, relatively-unknown, highly-complex solution to a simple problem. >Now we could avoid parse trees by using byte offsets, but >>given that addressing bytes in markup does not usually make sense, we will >>need to have the parse tree anyway -- that's what structural addressing is >>founded on. As far as I can tell, the details of groves are irrelevant to >>XML, unless we decide that we have to explain how XML linking can be >>treated as HyTime linking. > >I don't think they're irrelevant because I don't think you can discuss >location addressing in an open environment without something like groves. >We had to invent groves to solve exactly that problem in trying to >rationalize DSSSL and HyTime. XML will have the same problem and will need >the same solution. XML will need parse trees (probably the same as groves, unless you give me unexpected answers to my queries).Groves are (over?)-designed to accomodate the many complexities of SGML parsing that XML has eliminated. This means that the details of groves are probably not all that relevant. We may need look to them for inspiration, and possibly compatibility, but I doubt we will need to look deeper, unless we have to hack the grove notion for compatibility with the linking semantics of XML as thoroughly as we hacked SGML for compatibility with the syntax of XML). -- 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: Sat, 28 Dec 1996 14:35:44 -0600 From: len bullard To: "W. Eliot Kimber" CC: w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh W. Eliot Kimber wrote: > > TEI expresses itself and the interface between a HyTime > engine and a TEI engine is well defined in terms of the property sets, > groves, and grove plans both act on. This is good. If (for example only), one wants to create the object-oriented implementation of these engines would one create: o A class(es) of TEI objects including a TEI engine o A class(es) of HyTime objects (including property sets) The idea, I think, is to specify an interface as what a programmer thinks of it as: a virtual or real method interface. No, this is not the XML standard; it is a way to discuss the XML standard for hyperlinking in examples that a programmer would find clear. I plead for help from the object programmers on the list. > Without reference to Tim's original post, I think the issues are: > > 1. What syntax(es) to use for representing addresses? > 1.A HyTime location addresses (some or all) only (must include > URLs as a query notation that must be supported, in addition > to being used for entity external identifiers.). Please note the URL is under revision. It includes it's own notion of querying so, does this imply that to the Hytime view, a URL is simply a system for querying? IOW, others are possible but any sensible implementor uses the URL. For the WWW, the URL is the lynchpin. Also note, at this time, URN definitions conflict with URL definitions (per Roy Fielding's post to uri.bunyip). Prepending the prefix appears to be illegal. Someone more familiar with theseissues should investigate if this has implications for use of URNs and FPIs in XML. > 1.B TEI locators only We pick victims. TEI implementations go on (what there are of them), the majority of SGML hypertext implementations fall. It may be the best choice, but it is not without consequence. > 1.C Some combination of 1.A and 1.B This appears to me to be best. TEI goes on at current pace; other apps have room. Now, what happens to interoperation? > 1.D Only in style sheets See below. > 2. How to bind addresses to links > 2.A direct only > 2.B Indirect only > 2.C Direct and indirect 2.C > 3. Whether or not to define links that can be completely independent. It appears that everyone wants this. Please advise if that is an erroneous assumption. If so, we assume that it is a goal. > 4. What syntax to use to represent links (probably separate from > addresses). Here the choices seem to be: > 4.A SGML elements of the HyTime model without trickery (ID/IDREF > primary addressing method plus indirection) Pardon if I hash this: I've not time to review the new HyTime work. If I understand, using 4.a: Id points to Idref of target. Target classes may be actual nodes (e.g, an element with a valid SGML ID), or to a locator which in turn by convention indicates a semantic for locating the target (e.g, relloc, dataloc, etc.) and the needed property values to be passed to the locator resolver. > 4.B SGML elements of the HyTime model with refloc/queryloc > stuff to make use of non-HyTime addresses easier for authors. Ok. Depending on what is "trickery" this seems to be 4.A. What is the difference? > 4.C SGML elements of some other model that can't be reconciled > with HyTime (I don't think such a thing can be made, but > I won't rule it out). If no example is presented, take the position it is absurd so not worth considering. > 4.D Define only in style specifications 4.D contravenes existing widely adopted practice. "only" is a non-starter. I have no opinion that use of stylesheets is "good or bad" for defining links. It does make sense but it is not what the user knows. I agree we should not bind XML to existing practice, but neither should we get so advanced we "drop the dancers on their posteriors" as we say in the music business when a tune is too progressive to work in performance. There is always a way out of the "no win" scenarios. I also don't believe in the Kobayashi Moru. > 5. What formalism to use in defining links and link types: > 5.A Strict requirement of HyTime's linktype/anchor role model > 5.B No required model (no need to define link types or anchor > roles) > 5.C Both 5.A and 5.B (be formal or not, we don't care). Note this > is HyTime as of the TC. How does an XML application designer inform an XML user that an XML element type is a link or an ilink? > 5.D Some other model that I'm not aware of Absurd. > 6. What base behaviors to define for links or link types, if any. 6. is convenient. If no base behaviors are defined, then XML should if only in an informative appendix, show how base behaviors can be defined and used interoperably. Users of existing systems do understand the meaning of 7. How to allow authors or users to define or modify link behaviors, > if allowed at all: > 7.A Style sheets only (e.g., DSSSL language for describing link > behavior. > 7.B Attributes on link elements > 7.C Some other mechanism If by an XML author, we mean the traditional author, I think this is an application issue. An XML implementor may choose to forgo DSSSL, CSS, whatever, and hardwire behavior in the class methods. OTH, using such means to modify behaviors is certainly an established practice in other web languages such as VRML. Ralph mentioned the SMSL project in another post. SMSL is an ISO project. XML is a W3C project. Should we establish scopes that enable these projects to be mutually reinforcing? Can we? len Date: Sat, 28 Dec 1996 22:00:43 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: URLs/MIME only? At 4:40 PM 12/28/96, Terry Allen wrote: >So *purely* as a point for discussion, let me pose the >following: > > The Web uses URLs (and to some degree, nascent URNs) > for link addressing. Linking methods are expressed > mostly within URLs, and URL schemes are not necessarily > tied to the data formats of the target entities. I would go along with the HyTime crowd and restate this as "Web _locations_ are defined in terms of URLs." There is only one link semantics (document replacement), perhaps two, if we consider frames and targets semantic (though I imagine that in XML all this could be handled, and better, in style sheets). In trying to convince the distributed authoring people that document versions should be explicitly encoded in the URL, I was informed repeatedly that URLs are opaque, and that it's evil to interpret their contents, and certainly no more semantics should be added to URL formats. > XML is specifically intended for use on the Web. > Why should XML specify any mechanisms for hyperlinking > other than those already in use? I assume you mean location, not linking (in keeping with the pedantry at the beginning of the message). We need some other kinds of location: 1. Addressing of parts of single resources. 2. Addressing into document that do not have anchor tags at the places we want to address. 3. Creation of single documents that may span more than one URL. The goal is not to replace the URL, as to be able to supplement it with additional structural information to make more precise linking possible. I suppose we could declare a format for "#" strings that encodes our location ladder. In fact, doing so would solve a serious user-interface problem for prospective browsers -- but I am not so sure that new magic URL hackery is really very nice. There is something in this proposal, I think, but it doesn't feel right to me yet. For instance link="#foo" would refer to an ID "foo" in the current document. link="#(TEI ROOT CHILD (4 CHAP))" would refer to the fourth chapter of the current document (but of course as a URL, it should really be: link="#(TEI%20ROOT%20CHILD%20(4%20CHAP))" In the foregoing I am using ( to indicate an "extended address, with a token for the type of address (TEI would proably be augmented by at least some HyTime addressing modes). This would work as a relative URL, as long as the base URL is taken as the URL of the main entity of the document, and not the entity it happens to reside in. The syntax is ugly for the common IDREF case, but if we are to allow queries at all this will not work anyhow, so it's not much of an objection. What do others think? I started to disagree, but I'm more ambivalent now... > How are XML agents to interoperate with other Web agents if > they do not confine their expression of linking semantics to > URLs (maybe plus URNs), HTTP headers (generated from metadata?), > and MIME types? I think that we will have all of these available -- but they don't give you very much, and I'd rather this group were defining markup, than making HTTP or URL scheme extension proposals. I still wish we were using HTTP headers instead of Processing Instructions (the one SGML feature I have never even contemplated using). -- 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: Sat, 28 Dec 1996 22:00:32 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: unmarked linkend awareness by XML engines At 4:18 PM 12/28/96, Terry Allen wrote: >David Durand writes in response to Steve Newcomb: >| No, we simply have to face the fact that end users are the only ones who >| can decide what documents need to be in their processing set. We can't > >No. As an author and publisher I must be able to indicate *my* >view of what that set of documents is, and, of the links in the set, >what are relevant to my author-primary view of my own intellectual >property. I must also be able to assert (not enforce) via my >markup that this view is mandatory (if it is). Consider the case >of nuclear reactor documentation in XML governed by an effectivity >policy before you assert that the end user must be king. Mechanisms >of policy enforcement need not be specified (because enforcement >is a function of applications), but the assertion that there is a >policy must be supported (because linked metadata is the obvious >way to support it). "Indicating" is one thing, but enforcement is another. I suggested that such indications would be useful, but that is different from requiring that those indications must be followed by anyone. Enforcement is pointless, because intentionally non-conformant clients can violate any such restriction anyway. I also don't think that nuclear reactor documentation with contractual display format requirements is primary in "SGML on the Web". Users of XML for such applications will be perfectly capable of creating appropriate application conventions and DTDs to accomodate this without our help. I'm not opposed to being able to suggest to an application what it should do, just the pretense that it can be required. Most particularly, I want to keep the ability to annotate -- regardless of the author's wishes, and it should also be possible to publish those annotations, for those readers who wish to view them. The author should neither be able to prevent the creation or processing of such ilinks, nor a user, force others to see them. > >| check the whole world, and we can't just leave it to the author (without >| damaging the ability to create external annotations), so we have to leave > >XML should not have as a design goal the ability to enable promiscuous >external annotations unauthorized by the document's owner. The owner >may wish to enforce a policy that he does not permit the work to be >viewed with annotations (e.g., by not serving to clients that do not >guarantee to respect his policy). We are under no obligation to >enable grafitti. We may be powerless to prevent it, too. Grafitti is what you cannot avoid seeing -- but if you don't read my ilinks, then you don't see my annotations. No problem, but the power is at the reader's end anyway, we might as well admit it. This no-annotation stuff strikes at the heart of what gives hypertext its great potential, in my view. Philosophy aside, we should pass no laws we cannot enforce, so no-annotation policies are in the wastebasket, I think. And annotations are so usefun and fundamental, that we cannot create any credible linking system that does not enable their creation. >| it to the user (via their application). In other words, XML as a standard >| cannot enforce this kind of scoping for the user. All that we need to >| specify is how ilinks behave in documents where they are _parsed_ by an XML >| processor. In HyTime terms, the BOS will always be the entire web (one of >| the reasons I always thought the notion was limited in usefulness). >| However, the set of documents an XML processor will be required to >| processes is an application (user) decision. As an example we could not >| force a browser to pre-fetch linked documents in case they might reference >| ilinks that _might_ be of interest. > >But we must have some mechanism to indicate to the user agent what the >bounds of a single work are, something lacking on the Web today. This, >too, may lie without the scope of XML linking, but we still need it. This is already done today, as it should be, by authoring and display convention. The fact that most people don't bother to distinguish internal >from external links may be evidence that they don't care, but it's not very hard to do. >An example directly contrary to your point about prefetching: there must >be a way in which I can specify that an XML application *must* fetch >the linked copyright notice and display it before the main text of >my fine literary work. It may be that XML's linking mechanism is >not the place to do this, but if not, where do you think *is* the >right place? If you want a copyright notice for a document delivered over the web, you had better put it in the document, as the first text, because the network infrastructure is to frail for you to ensure that your readers will see it if it's anywhere else. I'm being rather harsh and flip with some very serious issues, but I don't see that the philospophical discussions will be solved here, nor do I think there are any technical solutions that we can offer to the problems you raise. -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Sun, 29 Dec 1996 12:16:52 +0700 To: dgd@cs.bu.edu (David G. Durand) From: James Clark Subject: Re: clink/ilink direction (Was: anchor awareness) Cc: w3c-sgml-wg@www10.w3.org At 16:02 28/12/96 -0500, David G. Durand wrote: >At 4:11 PM 12/27/96, W. Eliot Kimber wrote: >>At 05:04 PM 12/27/96 -0500, David G. Durand wrote: >>> A "grove" is just a new name for what everyone else in the world calls >>>a "parse tree". >> >>Not exactly correct: groves are a new name for what everyone else in the >>world calls a direct graph data structure. It happens that one obvious >>application of directed graphs is the representation of parse trees, but >>that's not the only thing groves are used for. Groves are useful because >>the provide the following features on top of the basic directed graph of >>nodes concept: > >trees are directed graphs. Are you saying that groves can include cyles of >nodes (ie node that are their own ancestors), or multiple inheritance >(directed _acyclic graphs_)? If not, groves are part of that subset of >directed graphs known as trees, and you are spreading more smoke into the >air, instead of shedding light on the issues. Groves are directed graphs (not acyclic), but they can also be considered as trees. More precisely: - A subset of the edges are distinguished as representing "origin-to-subnode" relationships. If you delete all edges other than these, then the graph becomes a single tree. - A subset of the "origin-to-subnode" edges are distinguished as representing parent-child relationships. If you delete all edges other than these, then the graph becomes a set of disjoint trees: one of these trees is the normal ESIS-like element structure tree; each attribute assignment (name plus value) is also its own tree. James Date: Sat, 28 Dec 1996 23:48:33 -0600 From: len bullard To: Terry Allen CC: w3c-sgml-wg@www10.w3.org Subject: Re: URLs/MIME only? [was Anchors Aweigh] Terry Allen wrote: > > Len Bullard writes: > | These systems don't interoperate. HTML and VRML do > | and they aren't even in the same syntax, but they agree > | on what a hyperlink is and does down to "target=". > > They do so because the behavior of the link is implied > by its context and because the addressing is completely > contained within the URL. The commonality is in the > use of URLs. Yes. If we propose to use independent links because we see a clear need for them, how do we best express that using URLs? > So *purely* as a point for discussion, let me pose the > following: > > The Web uses URLs (and to some degree, nascent URNs) > for link addressing. Linking methods are expressed > mostly within URLs, and URL schemes are not necessarily > tied to the data formats of the target entities. Correct. > XML is specifically intended for use on the Web. Assumption of project; may not be intent of users. I hate to limit a market like that. Don't get me wrong, I understand this assumption, but I feel other types of hypermedia will emerge for which XML will be useful. The target is still the Web. > Why should XML specify any mechanisms for hyperlinking > other than those already in use? We need control of our markup back. We need independent links. We can define forms for declaring links so we can interoperate with them (objects or XML element types). I agree we do not need to redefine URLs, URNs, URIs, etc. Precluding the use of other protocols isn't necessary. Consider someone may want to use XML documents in stateful protocols. All the address field has to know is which protocol is needed. Right? The whole area of generic identifiers and attribute sets for ilinks and clinks is up for grabs. We can enumerate a set of candidates from existing apps, or we can define a way for any one of these candidates to be identified by type in XML markup. It may be the case that all that is common is the URL in XML and as you say, context is the key. The application knows it is an anchor because of from sharing tag libraries for the convenience of authoring. Registry concepts are applicable. If the consortium decides (this is consortium stuff), they can support the registry of interoperable hyperlink element types. So where it can be How are XML agents to interoperate with other Web agents if > they do not confine their expression of linking semantics to > URLs (maybe plus URNs), HTTP headers (generated from metadata?), > and MIME types? URLs. Absolutely. Why URNs now? HTTP headers, yes. MIME? I don't like using file extensions to identify types when archiving. Call me old fashioned, but when the markup goes to cold storage, I want it to have as much information about the original system that it was built for as possible. However, this is library work. I don't think the network cares. len Date: Sun, 29 Dec 1996 09:51:00 +0000 To: w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Kill the BOS of XML For the record, HyTime's Bounded Object Set (BOS) concept was created to allow an SDIF package to be created that would contain all the files referenced in a group of related documents (e.g. for storage on a CD-ROM). By definition XML as defined by the SGML on the Web team is not concerned with creating SDIF packages of sets of documents, only in providing pointers to files stored in their original storage locations. Therefore, I would suggest, the concept of BOS has no relevance in the design of XML links. Martin Bryan ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Sun, 29 Dec 1996 09:50:57 +0000 To: dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: unmarked linkend awareness by XML engines At 18:35 28/12/96 -0500, David G. Durand wrote: >In HyTime, the BOS is always >>application-definable, but it is also expressible interchangeably, as >>a suggestion, in terms of an arbitrarily pruned entity tree. If XML >>supports ilinks, or n-directional linking, or, therefore, what I have >>been imprecisely terming "anchor awareness," I think it's necessary to >>have a way of expressing this pruned entity tree (BOS) notion in XML, >>too. > >No, we simply have to face the fact that end users are the only ones who >can decide what documents need to be in their processing set. We can't >check the whole world, and we can't just leave it to the author (without >damaging the ability to create external annotations), so we have to leave >it to the user (via their application). In other words, XML as a standard >cannot enforce this kind of scoping for the user. All that we need to >specify is how ilinks behave in documents where they are _parsed_ by an XML >processor. In HyTime terms, the BOS will always be the entire web (one of >the reasons I always thought the notion was limited in usefulness). >However, the set of documents an XML processor will be required to >processes is an application (user) decision. As an example we could not >force a browser to pre-fetch linked documents in case they might reference >ilinks that _might_ be of interest. This is where my call for thinking about link management comes in. Firstly lets not get confused by this much misunderstood term "users", for which I take Gavin to mean "reader". What is important is that authors, at the time of creating links, obtain sufficient information to ensure that a reader can reconstitute the environment (BOS) the author was working in. To do this the author must: a) Create a formal entity definition for each document referenced. This entity declaration must contain the fullest possible information about the referenced document. In particular it must record what the HyTime extensions to SGML refer to as the SOIBase - a clear definition of which machine the file was originally obtained from b) Create an independently referencable set of links that use the recorded entity declarations as their BOS. The main point is that the entity definitions and the link information need to be stored as a separately referencable document/fragment that can be extracted for evaluation outside of the accompanying text so that link validation can be done efficiently without having to scan through vasts amounts of data. If the link information is stored externally from the data (which it ideally should) there should be a way of pointing to the relevant file(s) from the XML document element, e.g. Unless we get the idea of _formally_ recording the sources of our links as part of the authoring process we will get hung up on the red-herring of the Web being the BOS - it isn't. The BOS is defined by the set of files identified by each file visited. While in total this could be as wide as the Web if we tried to visit too many files at once we, in practice, only need to deal with that part of the Web associated with the files currently being viewed. Providing we can obtain this information easily the process of managing it will be easy. Martin Bryan ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ From: lex@www.copsol.com (Alex Milowski) Subject: Re: clink/ilink direction (Was: anchor awareness) To: w3c-sgml-wg@www10.w3.org Date: Sun, 29 Dec 1996 10:00:36 -0600 (CST) David G. Durand wrote: > > A "grove" is just a new name for what everyone else in the world calls > a "parse tree". Now we could avoid parse trees by using byte offsets, but > given that addressing bytes in markup does not usually make sense, we will > need to have the parse tree anyway -- that's what structural addressing is > founded on. As far as I can tell, the details of groves are irrelevant to > XML, unless we decide that we have to explain how XML linking can be > treated as HyTime linking. I think this is a fine idea, but a relatively > low priority, as HyTime implementations are a micro-niche even within the > SGML community. > I would say that some kind of grove specification is essential to XML. The grove defines what is important from that markup scheme and what relationships exist within the document. It levels the playing field for applications and insures that they "get it right"! HyTime or not, we should define a subset of the DSSSL/HyTime groves for XML's use. As I understand it, groves will be making their way back into the SGML standard in its revision. Groves are not irrelevant--they are quite the opposite and extremely important. If we do this now, we will find it extremely useful to extend what XML and XML applications can do in the future. ============================================================================== R. Alexander Milowski http://www.copsol.com/ alex@copsol.com Copernican Solutions Incorporated (612) 379 - 3608 Date: Sun, 29 Dec 1996 09:17:45 -0800 (PST) From: Terry Allen To: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org Subject: Re: URLs/MIME only? David Durand writes: | At 4:40 PM 12/28/96, Terry Allen wrote: | >So *purely* as a point for discussion, let me pose the | >following: | > | > The Web uses URLs (and to some degree, nascent URNs) | > for link addressing. Linking methods are expressed | > mostly within URLs, and URL schemes are not necessarily | > tied to the data formats of the target entities. | I would go along with the HyTime crowd and restate this as "Web | _locations_ are defined in terms of URLs." There is only one link semantics | (document replacement), perhaps two, if we consider frames and targets | semantic (though I imagine that in XML all this could be handled, and | better, in style sheets). [ ...] | > XML is specifically intended for use on the Web. | > Why should XML specify any mechanisms for hyperlinking | > other than those already in use? | | I assume you mean location, not linking (in keeping with the pedantry at ??? Here's the "pedantry": === === Len Bullard writes: | you see, what I would really like is the HyTime contingent | to explain how the Hytime terms, properties, groves, grove | plans, etc. work in an object framework. I know it can | be done with TEI, IADS, IDE/AS, DynaText, MIL-PRF-87269, | the Philly DTD, MIL-PRF-28001 and every other DTD to | which an element type for a link has ever been added. | These systems don't interoperate. HTML and VRML do | and they aren't even in the same syntax, but they agree | on what a hyperlink is and does down to "target=". They do so because the behavior of the link is implied by its context and because the addressing is completely contained within the URL. The commonality is in the use of URLs. === end "pedantry" === I'm talking about linking to locations. There's a URL scheme proposed for linking by byte ranges. There are URL schemes for linking to parts of multipart MIME messages. Still purely for discussion: | the beginning of the message). We need some other kinds of location: | 1. Addressing of parts of single resources. | 2. Addressing into document that do not have anchor tags at the places | we want to address. | 3. Creation of single documents that may span more than one URL. | | The goal is not to replace the URL, as to be able to supplement it with | additional structural information to make more precise linking possible. | | I suppose we could declare a format for "#" strings that encodes our | location ladder. In fact, doing so would solve a serious user-interface Indeed, that syntax is already available. Here's what the revised syntax draft, v00, says (after remarking that # is a delimiter and neither it nor what follows is part of the URL): When a URL reference is used to perform a retrieval action on the identified resource, the optional fragment identifier, separated from the URL by a crosshatch ("#") character, consists of additional reference information to be interpreted by the user agent after the retrieval action has been successfully completed. As such, it is not part of a URL, but is often used in conjunction with a URL. The format and interpretation of fragment identifiers is dependent on the media type of the retrieved resource. So the point is that URLs give you a way to do this already, the fragment identifier mechanism is bound to be developed by non-XMLlers, and as you show in the rest of your response (deleted), it's not hard to do for pointers into XML documents. What architectural advantage is there in the Web context for XML in developing alternate mechanisms that may not be interoperable? 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: Sun, 29 Dec 1996 09:44:15 -0800 (PST) From: Terry Allen To: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org Subject: Re: unmarked linkend awareness by XML engines >David Durand writes in response to me: | >| No, we simply have to face the fact that end users are the only ones who | >| can decide what documents need to be in their processing set. We can't | > | >No. As an author and publisher I must be able to indicate *my* | >view of what that set of documents is, and, of the links in the set, | >what are relevant to my author-primary view of my own intellectual | >property. I must also be able to assert (not enforce) via my | >markup that this view is mandatory (if it is). Consider the case | >of nuclear reactor documentation in XML governed by an effectivity | >policy before you assert that the end user must be king. Mechanisms | >of policy enforcement need not be specified (because enforcement | >is a function of applications), but the assertion that there is a | >policy must be supported (because linked metadata is the obvious | >way to support it). | | "Indicating" is one thing, but enforcement is another. I suggested that | such indications would be useful, but that is different from requiring that | those indications must be followed by anyone. Enforcement is pointless, | because intentionally non-conformant clients can violate any such | restriction anyway. Please reread carefully. I can enforce in any number of ways outside of XML, but I must be able to state policy and be sure the user sees it before I can enforce anything. | I also don't think that nuclear reactor documentation | with contractual display format requirements is primary in "SGML on the | Web". A very weak counterargument. Substitute the Walt Disney movie "Snow White". Do you think Disney is going to allow someone to publish XML annotations to Snow White (conceivably not animated by family values) that can be overlaid on their intellectual property? No, they're going to find a solution in which you can't see Snow White if you're adding on annotations. | Users of XML for such applications will be perfectly capable of | creating appropriate application conventions and DTDs to accomodate this | without our help. That doesn't square with what you wrote and I objected to: | >| No, we simply have to face the fact that end users are the only ones who | >| can decide what documents need to be in their processing set. So if XML users will be able to creat appropriate application conventions and DTDs, how? | I'm not opposed to being able to suggest to an application what it | should do, just the pretense that it can be required. Most particularly, I I make no pretense that I can enforce my policy via XML. What I said was: === | >I must also be able to assert (not enforce) via my | >markup that this view is mandatory (if it is). === | want to keep the ability to annotate -- regardless of the author's wishes, | and it should also be possible to publish those annotations, for those | readers who wish to view them. The author should neither be able to prevent | the creation or processing of such ilinks, nor a user, force others to see | them. See "Snow White." | This no-annotation | stuff strikes at the heart of what gives hypertext its great potential, in | my view. Others have different views, and they include large publishers who so far have not felt their intellectual property to be safe on the Web. | Philosophy aside, we should pass no laws we cannot enforce, so | no-annotation policies are in the wastebasket, I think. And annotations are | so usefun and fundamental, that we cannot create any credible linking | system that does not enable their creation. Please reread careful to distinguish stating policy from enforcing policy, and recall the discussion of whether Sun could police its FPI name space. | >An example directly contrary to your point about prefetching: there must | >be a way in which I can specify that an XML application *must* fetch | >the linked copyright notice and display it before the main text of | >my fine literary work. It may be that XML's linking mechanism is | >not the place to do this, but if not, where do you think *is* the | >right place? | | If you want a copyright notice for a document delivered over the web, | you had better put it in the document, as the first text, because the | network infrastructure is to frail for you to ensure that your readers will | see it if it's anywhere else. That's not an acceptable state of affairs in the long run, is it? If no improvements are made, publishers are likely to resort to methods of publication that (as now, in print) bind the intellectual property (in some binary unreadable format) to individual instances of applets that can be relied upon to enforce their display policies. There's a whole software-protection industry just waiting to help them do it. | I'm being rather harsh and flip with some very serious issues, but I | don't see that the philospophical discussions will be solved here, nor do I | think there are any technical solutions that we can offer to the problems | you raise. I haven't been philosphizing, I've been stating the requirements of publishers who wish to protect their intellectual property. You haven't offered anything in response except "you can't do that." Now, where in the XML architecture can I 1) state my conditions-of-use policy? 2) indicate the bounds of my multimedia work? As the electricity has just failed, I leave it at that. 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: 29 Dec 1996 19:45:17 +0000 (GMT) From: Peter Flynn Subject: Re: Anchors Aweigh 1996 09:34:55 -0600) To: w3c-sgml-wg@www10.w3.org Len BUllard wrote: So far, this discussion seems to have only two alternatives: TEI or HyTime and HyTime is a standard which Eliot assures us is able to express TEI comfortably. I'm sure it is, but will it be understandable by people who want to implement systems using XML? I know many people with many decades experience in the text and computing fields who have grave doubts about getting HyTime understood, whereas the TEI extended pointer notation is a concrete implementation which can be grasped in half an hour. I am by no means dismissing HyTime, but I really, badly want to be convinced that an XML which uses it is going to be comprehensible by the user and the implementor. ///Peter Date: 29 Dec 1996 19:19:29 +0000 (GMT) From: Peter Flynn Subject: Re: Anchor terminology Martin Bryan on 27 Dec 1996 09:21:18 +0000) To: w3c-sgml-wg@www10.w3.org Nelson's spokesman, Martin Bryan, said Lets stick to old English usage, as expressed by our sailors if we are going to be consistent! You mean like "abandon ship!"...:-) ///Peter Date: Sun, 29 Dec 1996 16:07:51 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: unmarked linkend awareness by XML engines At 9:44 AM 12/29/96, Terry Allen wrote: Summary: 1. Yes, I misread Terry. He clearly distinguished stating a policy from enforcing it. 2. [in great detail, point by point]: Neither a social contract for defining such policies, nor a viable technical infrastructure for supporting them currently exist. Therefore users who feel these needs must fend for themselves. We should not standardize what is not known to be useful, nor possible to be implemented >Please reread carefully. I can enforce in any number of ways outside >of XML, but I must be able to state policy and be sure the user >sees it before I can enforce anything. Indeed, I did not read carefully. You clearly distinguished between suggestion and enforcement, and agreed that at the moment the former is all we can do. But I'm still going to argue against stating these policies, absent any way to enforce them and agreement as to which policies are correct. I do agree with Martin that we need a way to identify document groups whose correct interpretation according to the author's intention dictates that they should be processed together. >| I also don't think that nuclear reactor documentation >| with contractual display format requirements is primary in "SGML on the >| Web". > >A very weak counterargument. All I was attempting to do was to falsify a weak example of why we need these policies, by pointing to the stated purpose of this group. >Substitute the Walt Disney movie "Snow White". Do you think >Disney is going to allow someone to publish XML annotations to Snow White >(conceivably not animated by family values) that can be overlaid on >their intellectual property? No, they're going to find a solution >in which you can't see Snow White if you're adding on annotations. This is their preprogative. We have no business, in my view, trying to create new social mechanisms in advance of any workable social/legal consensus on what is desirable. Never mind that we would be creating such policies without a technical infrastructure to support them. Of course, personally, I consider such policies worthy of opposition anyway... But, if there were a set of mechanisms in use, and subject to some widespread agreement, and support, then I would be forced to agree that we should support them. But since neither accepted policies nor workable mechanisms exist, I don't see why this is our problem. >| Users of XML for such applications will be perfectly capable of >| creating appropriate application conventions and DTDs to accomodate this >| without our help. > >That doesn't square with what you wrote and I objected to: >| >| No, we simply have to face the fact that end users are the only ones who >| >| can decide what documents need to be in their processing set. > >So if XML users will be able to creat appropriate application conventions >and DTDs, how? People with contractual requirements will have to create their own software that enforces them, and somehow ensure that only that software is used on their data. This is not a change form the present state of affairs. If support for such policies requires additional markup, it is easy to add. For instance, the military (or some research organizations!) could add a SECURITY="TOP-SECRET" attribute and ensure that their applications process it correctly. But it's not _our_ problem, it's _their_ problem. >| want to keep the ability to annotate -- regardless of the author's wishes, >| and it should also be possible to publish those annotations, for those >| readers who wish to view them. The author should neither be able to prevent >| the creation or processing of such ilinks, nor a user, force others to see >| them. > >See "Snow White." If you don't want home taping of your show, don't sell the broadcast rights. If you don't want satirical linking or guided tours of your data, don't publish on the web. You decide what policies you require, and what the economic tradeoffs of those policies are. Since I believe such policies to be unenforceable given current technology (aside from possible custom encryption applets, which we will certainly allow), I don't see that this is an issue for this group. > >| This no-annotation >| stuff strikes at the heart of what gives hypertext its great potential, in >| my view. > >Others have different views, and they include large publishers >who so far have not felt their intellectual property to be safe >on the Web. This doesn't bother me. If they can manage to develop open technology through the IETF or W3C that supports them, then they can standardize an application convention to support that, or add something to XML 2.0. >| Philosophy aside, we should pass no laws we cannot enforce, so >| no-annotation policies are in the wastebasket, I think. And annotations are >| so usefun and fundamental, that we cannot create any credible linking >| system that does not enable their creation. > >Please reread careful to distinguish stating policy from enforcing >policy, and recall the discussion of whether Sun could police >its FPI name space. I don't think that even stating a policy that is technically unenforceable is good for anything except maybe generating lawsuits. I don't see why we need to worry about this. >That's not an acceptable state of affairs in the long run, is it? If >no improvements are made, publishers are likely to resort to methods of >publication that (as now, in print) bind the intellectual property >(in some binary unreadable format) to individual instances of applets >that can be relied upon to enforce their display policies. There's >a whole software-protection industry just waiting to help them >do it. SHTTP or variants may address this. Like most security issues this is mostly related to transport and authentication. I don't see that we need to address this, especially since there is no infrastructure in place that we can be called upon to support. If we can't guarantee reliable transport (and we know this is the case) the only place that a copyright notice can be guaranteed to be recieved is if it occurs early in the byte-stream of a document. Any provider can construct a DTD that enables this information to be included at the beginning. No link can ever guarantee such security because the network might break before the link can be followed but after the data is downloaded. Now I can imagine encryption scenarios that would solve this (copyright notice contains a key to decypt the document body), but since they are not deployed anywhere, I don't see whay we should worry about supporting them. We don't prevent such things, just remain silent. >I haven't been philosphizing, I've been stating the requirements of >publishers who wish to protect their intellectual property. You >haven't offered anything in response except "you can't do that." >Now, where in the XML architecture can I If there's no effective way to acomplish an end, what is the point of promulgating a bunch of rules and policies about that end. I don't understand why we need to develop a new social structure and policy language that is unenforceable for the forseeable future. > 1) state my conditions-of-use policy? This is just not our problem. Persuade me that we can do even one useful thing with this information, in the lines of guaranteeing that it is used. > 2) indicate the bounds of my multimedia work? Add an "external link" icon to some of your links. Define two types of link in your DTD. Add a uniform header to all your documents. Add a copyright notics to all your documents. We do need a way to specify documents that should be processed together if they are to be viewed as intended. For instance, Martin's separate link file scenario should be accomodated properly, as default behavior. >As the electricity has just failed, I leave it at that. Well, things are going dim around me too, but it's probably just too much coffee... -- David I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Sun, 29 Dec 1996 16:14:58 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org Martin Bryan on Sun, 29 Dec 1996 09:50:57 +0000) Subject: Re: unmarked linkend awareness by XML engines I agree with Martin Bryan that SDIF is irrelevant to this discussion. The BOS concept, however, is very relevant. It is a way of limiting the number of links for which an application is responsible. It gives an application much more power to make information useful and accessible, by limiting the amount of information over which such power must be exercised. (Dave Durand:) > No, we simply have to face the fact that end users are the only ones > who can decide what documents need to be in their processing set. Right. But that doesn't mean users won't find it valuable to have an author's *suggested* BOS on hand. On the contrary, most serious users of documents are delighted to have the document's author provide all possible help. > Other links to that document will only be found if the user has > explicitly or implicitly (via some strategy) specified what other > documents may contain ilinks of interest (for example by opening a > bookmark set of ilinks, or a guided tour set of ilinks, or an > annotation set of links, etc.). But, then, we agree! This is precisely what a BOS does; it's a guided tour. > We can't check the whole world, and we can't just leave it to the > author (without damaging the ability to create external > annotations), so we have to leave it to the user (via their > application). I strongly agree with you, but you evidently think I disagree. I think maybe you're making a false assumption about what I'm proposing. According to HyTime, the BOS *suggestion* presumably takes effect when the user begins a session by entering a particular document. Nothing requires that the user accept the document author's suggestion. Indeed, if the user insists on making the whole Web the BOS of his session, he can sit there and wait until his beard hits the floor. Far be it from HyTime to stop him from engaging in such folly, however. That session-start document contains the suggested BOS expressed as a set of We may well want to consider adding additional notations to express > that some document _may_ be processed when a document is > processed. Sort of a "This document best when parsed along with ..." > notation. How is this different from HyTime BOS notation? I don't see any difference, Dave. I think we're actually on the same side of this question. Let me again rephrase the question I want answered: "Do we want XML to be able to make hot links available in documents when those documents do not themselves contain those hot links?" It's do-able if we have, as Dave puts it, "additional notations to express that some document _may_ be processed when a document is processed." Or, as HyTime puts it, the bounded object set (BOS) concept. --Steve Steven R. Newcomb President voice +1 716 271 0796 TechnoTeacher, Inc. fax +1 716 271 0129 (courier: 23-2 Clover Park, Internet: srn@techno.com Rochester NY 14618) FTP: ftp.techno.com P.O. Box 23795 WWW: http://www.techno.com Rochester, NY 14692-3795 USA P.S. FYI, in HyTime jargon, the session-start document is called the "hub document". Date: Sun, 29 Dec 1996 17:01:23 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org Subject: Re: unmarked linkend awareness by XML engines (Dave Durand:) > "Indicating" [a BOS] is one thing, but enforcement is > another. ... Enforcement is pointless, because intentionally > non-conformant clients can violate any such restriction anyway. Right. But indicating is useful. > And annotations are so useful and fundamental, that we cannot create > any credible linking system that does not enable their creation. (Note that annotations of read-only documents is something HTML can't do.) > If you want a copyright notice for a document delivered over the > web, you had better put it in the document, as the first text, > because the network infrastructure is too frail for you to ensure > that your readers will see it if it's anywhere else. Hmmmm. The ownership of information frequently changes hands, and the licensing arrangements surrounding many information assets also change frequently; even daily. I don't think it's desirable to require valuable information assets to be edited each time that happens. Much too dangerous, especially if human lives depend on the accuracy of their content. Much better to provide a session-start document instead that contains the copyright and license information, and that links to the valuable asset. The user naturally and normally starts the session by entering the session-start document, because that's the only way documented by the provider. (Similarly, in books, one knows that the natural and normal procedure is to start at the upper left hand corner of page one and read forwards, but nothing prevents you from starting somewhere in the middle and reading backwards if you prefer.) By means of a hyperlink, the session start document automagically traverses the user to the valuable read-only asset. Upon arrival at the read-only asset, the BOS is still pretty much guaranteed to include the session-start document; otherwise, the user couldn't have arrived at the read-only asset. If the user is running an application which is like any typical Web browser, the session-start document is still in a local cache, so the frailty of the Web network is not even an issue. The session-start document contains links which effectively place one or more hot links at various points in the read-only asset back to the session-start document. When traversed, those hot links can take the user to the copyright notice or the license agreement, or whatever. The valuable read-only asset never needs to be edited unless its substantive content must change. The session-start document can be changed at the pleasure of the owner of the read-only asset, with no danger to the main asset. In fact, it can easily be made to bear a license stamp unique to each licensee. Dave is right when he says that there is ultimately no techno-fix for policing the rights of information owners. However, there are things we can do to make commerce in information-use licenses easier. True independent linking can really help a lot, I think. --Steve Steven R. Newcomb President voice +1 716 271 0796 TechnoTeacher, Inc. fax +1 716 271 0129 (courier: 23-2 Clover Park, Internet: srn@techno.com Rochester NY 14618) FTP: ftp.techno.com P.O. Box 23795 WWW: http://www.techno.com Rochester, NY 14692-3795 USA Date: Sun, 29 Dec 1996 15:24:18 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Suggestion: A link model At 06:35 PM 12/28/96 -0500, David G. Durand wrote: [...] > Link-meta contains (for each link end) > A link-type. These should be specifiable by default (say for links with >fixed numbers of endpoints), on the instance (for links with variable >number of endpoints), and maybe by some combination (Steve DeRose and I >proposed methods to extend HyTime to accomodate this -- we don't know >what's happened in the TC process). I'm not sure I understand "these should be specifiable by default"--isn't the link type the same for all the link ends of a given link? In HyTime, the anchor roles of a particular link type must be the same for all instances of the type *in the same document.* This is partly because in the new HyTime design, addressing of anchors is done by attributes whose names correspond to the anchor roles--therefore the anchor role names must be unique within the type and they must be fixed or you couldn't declare the attributes. Note that we do now have way to indicate that it is *not an error* to for a given anchor role to consist of zero objects (i.e., that you can choose to not address anything for a particular anchor role). That means that you can make any anchor-addressing attribute optional if it is not an error for that anchor to be null. 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: Sun, 29 Dec 1996 15:24:15 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Suggestion: A link model At 06:35 PM 12/28/96 -0500, David G. Durand wrote: >A few suggestions for things that I think we need. I am describing these >somewhat like architectural forms, and somewhat like algebraic data types. >I am using prose, to avoid the prejudicing effect of inventing a new >notation, or abusing an old one. Even though David and I often disagree on details and use of terminology (and, to a larger degree, the existence of HyTime as a "good thing", which is, ultimately, a religious argument that cannot be resolved to anybody's satisfaction), I do completely agree with David's suggestions here: they are essentially identical to those I plan to complete just as soon as the holidays and Evil Cedar Pollen Allergy release me). I don't really care how the design is conveyed in the spec: architectural forms, whatever, as long as it's clear and precise. 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: Sun, 29 Dec 1996 17:43:13 -0600 From: len bullard To: Peter Flynn CC: w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh Peter Flynn wrote: > > I am by no means dismissing HyTime, but I really, badly want to be > convinced that an XML which uses it is going to be comprehensible by > the user and the implementor. I agree about XML hyperlinking being comprehensible. I'm not sure Eliot has completed his proposal. I know he will try very hard to show this. No doubt some positions are congealing. I see in these discussions that some consensus points are emerging. It seems likely to me that as the holidays are coming to a close, our illustrious editors will pull the issues into a presentation. len Date: Sun, 29 Dec 1996 17:51:44 -0600 From: len bullard To: "Steven R. Newcomb" CC: w3c-sgml-wg@www10.w3.org Subject: Re: unmarked linkend awareness by XML engines Steven R. Newcomb wrote: > > Dave is right when he says that there is ultimately no techno-fix for > policing the rights of information owners. However, there are things > we can do to make commerce in information-use licenses easier. True > independent linking can really help a lot, I think. I agree. I also point out that all of Dave's arguments which are in technical fact, true, are the same arguments used prior to PICS to prevent a serious technical answer being given to a serious social problem created by the management of that technology. Content policy can be noted and enforced as well as anything else. The beastie is just a machine. Whether with XML, XML link management systems, or other handlers, such enforcement of policy will occur. Inevitable and irrefutable. But not worth hassling with here and now. Application conventions of consortium apps will arise in response to customer pressure just as PICS has. len Date: Sun, 29 Dec 1996 15:47:51 -0800 To: w3c-sgml-wg@www10.w3.org From: Tim Bray Subject: Can we be more concrete? 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. If nobody else advances one I will, but others may find this disturbing coming from one who frankly admits failure to understand the relevancy of any number of the issues in question. To make it concrete (and I apologize to those who are reading this particular example for the second time, I sent it to someone, but not *I think* the SGML-WG): At SGML'96 this outfit had a multimedia authoring system called "Nereus". They had some circuit board photos and you could click on the parts and a little menu would pop up saying Locate Part Show Measurements Describe Part and they all did the obvious things. This was nothing more than a multi-ended link, accessible from some, not all, of its ends, each link having a defined role and label, and a defined behavior. I can imagine a syntax to describe this level of functionality, with a handy basket of boiler-plate roles and behaviors, and simple rules for rolling your own. I can imagine documenting this with a little DTD with elements & attributes beginning "-XML-". I can imagine defining some architectural meta-DTD stuff to allow you to do this in any old SGML document. I can imagine not writing any addressing mechanisms in beyond URL and ID attribute. I think this could all be written down in a dozen pages. I think it could be implemented by the XML's nominal CS grad in XML's nominal week. I think this could be awfully useful, and it would be substantially better than what our web brethren live with today. But it wouldn't say anything about object orientation or anchor awareness or pseudo-nodes or grove plans or stylesheets. To conclude, and I apologize for bluntness: I *suspect* that some of this discussion consists of handwaving, and I *know* that some of it is vitally important, and I can't tell the difference, and I think we need to enrich our diet with healthy servings of examples and draft spec language. Happy New Year, Tim Date: Sun, 29 Dec 1996 17:34:07 -0900 To: W3C-SGML-WG@www10.w3.org From: "W. Eliot Kimber" Subject: Re: locating capabilities vs. anchor awareness At 02:25 AM 12/28/96 +0000, Lou Burnard wrote: >A first draft of a brief tutorial intro to the TEI extended >pointer syntax is now available at > >http://users.ox.ac.uk/~lou/wip/XR.htm Lou, Thanks for making this summary available. The summary reinforces my opinion that TEI extended pointers are probably a good thing for XML. The only wrinkles I see in integrating TEI pointers with HyTime are: 1. TEI pointers use a slightly different "grove plan" than HyTime, to wit, TEI extended pointers only see elements (and not pseudo elements) in the tree rooted at the document element. This doesn't cause any problems with specification, it just might confuse people (any location address can specify the grove plan to be used when resolving it). 2. The XREF element's to and from attributes cannot be directly mapped to a HyTime contextual link because HyTime expects there to be a single attribute for each link end, but TEI allows two (three if you count "doc"). The only ways to resolve this that I can see are: A. Allow To, From, and Doc and then use a separate fixed query as the value of the HyTime anchor-addressing attribute that then refers to the values of the To/From attributes. This is pretty twisted but it could be made to work (e.g., I could create an SDQL "resolve TEI pointer" function and then use that as the value of the anchor-addressing attribute). B. Allow the DOC specification directly in the TEI extended pointer, e.g.: to="DOC (P3) ID (ABCD)" and limit XREF to "to" attribute. This seems like a useful thing regardless--maybe it's already there and it just wasn't mentioned in the tutorial? A few minor points wrt to mentions of HyTime and overlaps with HyTime terminology and functionality in the tutorial (and I assume in the current official TEI specs): location path/location ladder/step - Both HyTime and TEI pointers have the concept of location ladders and location paths (I don't know who influenced whom here). In the original HyTime standard, the terms location ladder and location path were not always used consistently. In the TC, we've taken pains to sort out the terms. A "location ladder" is the equivalent of a single TEI extended pointer: it specifies the list of nodes selected by successive narrowing of the set of possible nodes, e.g. "first para of third chapter of second part of doc A". A "location path" is a series of "steps", each step the bottom rung of a single location ladder, i.e., a series of indirections where one location address refers to another (this would be like one XPTR element pointing to another XPTR element). These terms seem to be slightly different from the way Lou has used them. In particular, we use "rung" to distinguish stages in a location ladder from steps in a location path--TEI appears to use the term "step" where HyTime uses "rung" and doesn't appear to necessarily distinguish rungs in ladders from steps in paths (this may be because in TEI extended pointers, the location ladder is always contained in a single pointer specification, whereas in HyTime a ladder consists of multiple address elements). - From the tutorial: "The token and str methods are defined as behaving in exactly the same way as their HyTime equivalents tokenloc and strloc respectively." Note that tokenloc and strloc were replaced by "dataloc" in the final HyTime standard. Dataloc survives in the TC, although the original "quantum" attribute is now "filter". The filter value corresponding to TEI's "token" is "norm", meaning SSEP-delimited tokens. - HyQ: HyQ is dead and replaced by SDQL from the DSSSL standard. - Spans: The TEI "from" and "to" attributes let you address data by pointing to the start and end points and addressing everything in between. HyTime calls this form of address a "span". Any location address in HyTime can indicate that it is addressing a span, in which case, every pair of nodes addressed is taken to be the start/end (to/from) of a span. Thus, the concept is there, but the syntax is different [my understanding is that spans were added specifically to reflect the TEI functionality.] Note that when using a query in HyTime, spanning is a function of the query's semantics--HyTime doesn't care how the query arrives at the node list it returns. Thus, if we assume that XPTR elements are treated as queries in a HyTime context, the TEI to/from attribute syntax is fine because the TEI engine will simply return the entire list of nodes addressed, not just the separate to and from values. - "HERE" keyword. With the TC, HyTime now has the equivalent of the "HERE" keyword, which is the ability of the location source of a location address to be the "referrer", i.e., the non-location address element that first points to it. When used with the relloc (relative location address) element in particular, it lets you do things very much like TEI extended pointers by making it possible to have a single location ladder that locates the "next" or "previous" element. [I originally suggested this addition to HyTime specifically to mirror the TEI functionality.] - DOC attribute. The TEI "doc" attribute corresponds to the HyTime location source attribute when it refers to a document or subdocument entity. In original HyTime, the locsrc attribute could only be an IDREF. With the TC, any location address element type can be declared as an ENTITY attribute, so that you can specify entities directly as location sources. Given the above, the TEI XPTR element form can be declared to a HyTime engine like so: The TEI XREF element, using option B given above, can be declared like so: Note that neither of these definitions change the element instances at all. 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: Sun, 29 Dec 1996 18:35:21 -0600 From: len bullard To: Tim Bray CC: w3c-sgml-wg@www10.w3.org Subject: Re: Can we be more concrete? Tim Bray wrote: > > and they all did the obvious things. > > This was nothing more than a multi-ended link, accessible from some, > not all, of its ends, each link having a defined role and label, > and a defined behavior. > > I can imagine a syntax to describe this level of functionality, with > a handy basket of boiler-plate roles and behaviors, and simple rules > for rolling your own. I think we can all imagine that and have in one system or another. Bring on the strawman and people will explain their positions. Even if it does not help you as an editor, it may help all of us understand your editing better. len Date: Sun, 29 Dec 1996 17:56:21 -0800 To: w3c-sgml-wg@www10.w3.org From: Ralph Ferris Subject: Re: Anchor terminology At 07:19 PM 12/29/96 +0000, Peter Flynn wrote: >Nelson's spokesman, Martin Bryan, said > > Lets stick to old English usage, as expressed by our sailors if we are going > to be consistent! > >You mean like "abandon ship!"...:-) > >///Peter Probably more like: "When at anchor here I ride, My bosom swells with pride! And I snap my fingers at the foe-man's taunts ..." - Gilbert and Sullivan, "HMS Pinafore" --Ralph To: w3c-sgml-wg@www10.w3.org Subject: Re: clink/ilink direction (Was: anchor awareness) Date: Sun, 29 Dec 1996 19:13:39 -0800 From: Joe English dgd@cs.bu.edu (David G. Durand) wrote: > W. Eliot Kimber: > >David G. Durand: > >> A "grove" is just a new name for what everyone else in the world calls > >>a "parse tree". > > > >Not exactly correct: groves are a new name for what everyone else in the > >world calls a direct graph data structure. [...] > > trees are directed graphs. Are you saying that groves can include cyles of > nodes (ie node that are their own ancestors), or multiple inheritance > (directed _acyclic graphs_)? Sort of. Groves are like trees in that every node with the exception of a unique root node has a single parent. However, nodes in a grove also have a collection of named properties, whose values can be either "plain data" or a list of references to other nodes. Nodal properties (those whose value is a list of nodes) are classified as either "subnode properties" or "reference node properties"; every node except for the root is a member of a subnode property of exactly one other node in the grove (i.e., its parent), but there are no restrictions on reference node properties. If you consider only the subnode properties, you have a tree; if you consider the reference node properties as well, you have a directed (possibly cyclic) graph. Further, non-leaf nodes have a single distinguished subnode property designated as the "content property"; if you consider only the content properties you get the "principal tree" of the grove. For example in the SGML grove plan, attribute nodes are subnodes of element nodes, but they are not part of the principal tree. > >3. Provides a standardized abstraction mechanism divorced from the > > implementation issues. > > Ah, kind of like a parse tree. In fact, exactly like. A grove is nothing like a parse tree in the sense of the term with which I am familiar (a representation of a derivation of a string of terminals with respect to a grammar); they're more like an abstract syntax tree (i.e., a representation of the information derived from the parse tree) augmented with cross-references between nodes. > My inclination agaist groves stems from: > 1. The complexity of groves (reflecting the complexity of full SGML parsin > g). The grove data structure taken by itself is really quite simple and elegant. The SGML property set is horrendously complex, but if you only consider the "important" parts (e.g., ESIS plus a few extra properties that got left out) groves are very useful. (Cost 2 uses a grove-like data structure for its internal representation, so I can attest to their utility.) --Joe English jenglish@crl.com Date: Sun, 29 Dec 1996 20:42:51 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Can we be more concrete? At 03:47 PM 12/29/96 -0800, Tim Bray wrote: >To make it concrete (and I apologize to those who are reading >this particular example for the second time, I sent it to someone, but >not *I think* the SGML-WG): At SGML'96 this outfit had a multimedia >authoring system called "Nereus". They had some circuit board photos >and you could click on the parts and a little menu would pop up saying > > Locate Part > Show Measurements > Describe Part What do we need to build a system that can do this (or rather, what data do we need in the documents that would drive this system)?: 1. A way to address regions of a graphic: I'll use a modified client-side image map syntax, just to pick something. 2. A way to represent the data to be related to the graphic: XML documents, natch--I leave the definition of these documents to whoever wants to figure out to make the PCIS (Pinnacles) DTD XML conforming (which it might be out of the box) [PCIS is the semiconductor interchange DTD]. 3. A way to represent the relations between the regions of the graphic and the data: HyTime-style hyperlinks, of course. [I say HyTime-style because it doesn't matter whether they actually conform to HyTime or not for the purposes of this discussion, but it happens that my design does conform]. Assuming that everything in the document is an "anchor" as we've defined it for XML, i.e., has an ID by which it can be addressed and further assuming that the URL notation "#name" is interpreted as an ID reference for XML, all I need to do is define the hyperlinks themselves: ]> XYZ Framizitzer Cicuit A bunch of transistors A bunch of nand gates Cache ROM Now I've related parts of the graphics (addressed by the Area elements) to the descriptions of those parts and to the characteristics of those parts. Nothing very hard here. HyTime is never mentioned, groves are never mentioned. The addressing methods should be familiar to every Webhead. The only thing I've added is declaring the image map as a notation so my processor can distinguish it from all the other ways I might do the same thing. The behavior of these links would be defined by the presenting application, either built into its understanding of the semantics, or defined through a separate style spec. A tool like HyBrowse will provide some default behaviors and can be modified via style. At a minimum, from any link end, I'd expect to be given a list of the other link ends, distinguished by link type and anchor role (if not by other metadata as well). I don't see how it could get much simpler than this. Note that the image map could be in a separate document--I showed it in the same document for simplicity. Presumably in a real application like this, the image map would be bound to the image and not replicated. There are other HyTime-conforming ways you could do this, but the above is my initial guess at the best approach, both in terms of simplicity of execution and completeness of semantic description. 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: Sun, 29 Dec 1996 21:05:15 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Can we be more concrete? Cc: goldfarb@alink.net I wrote: >3. A way to represent the relations between the regions of the graphic > and the data: HyTime-style hyperlinks, of course. [I say HyTime-style > because it doesn't matter whether they actually conform to HyTime or > not for the purposes of this discussion, but it happens that my > design does conform]. I see that this isn't quite fair to TEI--a closer study of the actual TEI spec (section 14) shows that TEI has a Link element distinct from XREF that is essentially the same as a HyTime ilink. However, unless I've missed something (quite likely, given the lateness of the hour), it doesn't appear that TEI has an exact equivalent of HyTime's clink (although maybe Link can be used in that way?). Note that except for the doc/to/from on TEI's XRef vs one addressing attribute on HyTime's clink, TEI's approach and HyTime's are very similar, at least at the level of raw syntax: both provide mechanisms for indirect addressing from separate linking elements using plain ID references. In fact, I'd argue that, when combined with TEI extended pointers as a query notation, HyTime's design is slightly more convenient because you can use extended pointers directly from independent links without going through indirection if you don't otherwise need it--but that's a quibble and something TEI could add quite easily if it wanted to--in any case, this isn't a TEI vs. HyTime debate. In fact, I would hazzard to guess that there is in fact so little difference between HyTime and TEI on the issues of linking that TEI could be defined as entirely HyTime conforming (including the use of TEI extended pointers as a query notation, which is what they are anyway) with little or no change to its current core definition. This suggests that both designs are either fundamentally sound or equally flawed, and I don't think they are flawed in their fundamental approach to linking and addressing. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 30 Dec 1996 09:36:09 +0000 To: "Steven R. Newcomb" , w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: unmarked linkend awareness by XML engines At 16:14 29/12/96 -0500, Steven R. Newcomb wrote: > >I agree with Martin Bryan that SDIF is irrelevant to this discussion. >The BOS concept, however, is very relevant. It is a way of limiting >the number of links for which an application is responsible. The word "responsible" is one that gives me great problems. If I create a page that has a link to some text on a page you have created, in what way am I "responsible" for the contents of this page. Obviously I have no copyright to it. I have no right to add any contents to it. I have no right to add any ids to it to identify the text that I was referring to. I have no mechanism for ensuring you do not a) remove the text I was referring to, b) remove links in the text that I was referring to, c) add links to the text I was referring to, d) add or remove any other part of the document. > It [the BOS concept] gives >an application much more power to make information useful and >accessible, by limiting the amount of information over which such >power must be exercised. Not unless you have proper versioning control and fully record the state of the referenced file at the time you created the links. In practice what you suggest however does not "limit the amount of information over which power is exercised" but unnecessarily extends it to a level where it is unmanageable. >(Dave Durand:) > >> No, we simply have to face the fact that end users are the only ones >> who can decide what documents need to be in their processing set. > >Right. But that doesn't mean users won't find it valuable to have an >author's *suggested* BOS on hand. On the contrary, most serious users >of documents are delighted to have the document's author provide all >possible help. Only so long as that help remains up-to-date. On the web that typically means for a few weeks at the most. >> Other links to that document will only be found if the user has >> explicitly or implicitly (via some strategy) specified what other >> documents may contain ilinks of interest (for example by opening a >> bookmark set of ilinks, or a guided tour set of ilinks, or an >> annotation set of links, etc.). > >But, then, we agree! This is precisely what a BOS does; it's a >guided tour. Not according to the model you give below - there is no guidance, simply a mass copying of pointers found in related documents. >> We can't check the whole world, and we can't just leave it to the >> author (without damaging the ability to create external >> annotations), so we have to leave it to the user (via their >> application). > >I strongly agree with you, but you evidently think I disagree. I >think maybe you're making a false assumption about what I'm proposing. I strongly disagree with both of you. We cannot expect link management to be done by either an authoring system or an XML browser (which I presume is what David is referencing when he talks about a user's application here). Link management has to be a separate function, run at regular intervals between link creation and link navigation. >According to HyTime, the BOS *suggestion* presumably takes effect when >the user begins a session by entering a particular document. Nothing >requires that the user accept the document author's suggestion. How an earth can a browser or its user determine which of the "BOS suggestions" are relevant? >Indeed, if the user insists on making the whole Web the BOS of his >session, he can sit there and wait until his beard hits the floor. How will he ever know that he was insisting on this? Surely he is not going to be given a browser that has functions that say "follow all links in all documents linked to this one"? Even crawlers run on supercomputers are not stupid enough to adopt this approach: I don't see anyone realistically suggesting that this approach would work on a 286! >Far be it from HyTime to stop him from engaging in such folly, >however. That session-start document contains the suggested BOS >expressed as a set of how deeply those entities can recursively declare other entities which >will become part of the BOS. The resulting pruned entity tree >contains all the links for which the HyTime application is recommended >to be responsible by the author of the session-start document. In Web terms what the "UWOS" [Unbounded Web Object Set] needs to state is the set of entities for which access _must_ be provided by the application to make sense of the "document" being accessed by the browser via that start-page. The concept to "arbitrary limits on how deeply these entities can recursively declare other entities" is both irrelevant and highly dangerous on the web. I agree a UWOS has benefits - I disagree that a UWOS is a bounded object set. >If, in the course of traversing the links in the session-start >document, the user encounters another document, the user certainly has >the option of accepting *that* document's suggestion as to what the >BOS should be (making that document effectively the session-start >document), or, of adding that document's BOS to his existing, >session-dependent BOS, or of simply ignoring the suggestion and >keeping the present BOS, or of doing something else entirely. This will not work, for a number of reasons. Firstly look at the situation where I make a reference to just part of one of your documents. The links in the part of the document that I refer to _may_ be relevant to the BOS, but those that occur in the rest of your document are unlikely to be relevant (otherwise I would have referred to that part of the document as well). How can I determine which of the entries in the referenced document's set would be relevant? If I copy them all then my object set is no longer "bounded" - it is distinctly unbounded as far as my document is concerned! Now look what happens when you edit the referenced document, and delete or change some of the links in it. If those links are in the area I have referenced then the copy of the entity list that I took when authoring is now out of date. How do I determine this? If they are outside the area that I am referring to I don't care about the changes, even if this means that the "complete copy" of the entity set I took earlier is now out of date. But how can I tell that the change in the entity set is one that does not affect my UWOS? (What I need is to be able to reference the BOS of the referenced document independently of the document itself in such a way that I can identify when it has been changed so that I can then revalidate my own document's references.) >The existence of a BOS suggestion *enables* ilinks by making them >practical and scalable, which in turn *enable* the creation of >annotations of read-only materials which can be seen in the context of >the read-only document. A BOS dos not "*enable* the creation of annotations of read-only materials" because it fails completely to do the main thing that is required. If I reference your read-only material by an existing link, how can I determine whether there are already sets of annotations associated with this document? The only way I can know that a set of annotations exists for a document at present is to access the annotations separately first. What I really need to be able to is to have the document identify for me which sets of annotations point to it. In other words the document needs to "keep a record" of all files which reference it in their UWOS. All a BOS associated with a set of annotations could possibly tell you is the set of files the annotations refer to. > If the user begins his session with the >annotation document and traverses to the annotated document, because >the annotation document is necessarily in the user's BOS, all the >annotations in the annotation document can then be made available by >the application as hot links from within the annotated (read-only) >document. (I don't need to point out that you can't do this with >HTML, or that that is one hell of a useful capability.) While such link inheritance based on traversal routes is undoubtedly useful it fails to meet one set of needs. What I, as a writer, want to know is not what links I have added to the referenced document, but what other people have thought to have been of relevance. For a researcher, rather than a document deliverer, this is the important aspect of the web. (We should not forget that much of the use of the Web is by researchers and should try to meet their needs as well where possible.) (Before you start responding to this paragraph, I know that I am treading on dangerous grounds re the right to view/manage links - what I am pointing to is that writers/reasearchers have different uses for links than those found in controlled document delivery environments, and that XML should try to allow for these as well.) >> We may well want to consider adding additional notations to express >> that some document _may_ be processed when a document is >> processed. Sort of a "This document best when parsed along with ..." >> notation. > >How is this different from HyTime BOS notation? I don't see any >difference, Dave. I think we're actually on the same side of this >question. I think David is pointing more to my idea of "the files that you need access to to make sense of this document", rather than a bounded object set. What I think is is more relevant is to use the History of links visited by the author of the annotations o create a list of the files that must be made available to users, rather that just saying that any file linked to any file that is referenced should be recorded as part of the BOS. >Let me again rephrase the question I want answered: > >"Do we want XML to be able to make hot links available in documents >when those documents do not themselves contain those hot links?" Yes - but this is totally different from the concept of a BOS. This is inheritence of anchors dependent on the route by which you get to the document. This must be a good thing. >It's do-able if we have, as Dave puts it, "additional notations to >express that some document _may_ be processed when a document is >processed." Or, as HyTime puts it, the bounded object set (BOS) >concept. No - Dave has it correct - the HyTime BOS is not bounded enough! ---- 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, 30 Dec 1996 09:36:14 +0000 To: "Steven R. Newcomb" , w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: unmarked linkend awareness by XML engines At 17:01 29/12/96 -0500, Steven R. Newcomb wrote: >Much better to provide a session-start document instead that contains >the copyright and license information, and that links to the valuable >asset. The user naturally and normally starts the session by entering >the session-start document, because that's the only way documented by >the provider. (Similarly, in books, one knows that the natural and >normal procedure is to start at the upper left hand corner of page one >and read forwards, but nothing prevents you from starting somewhere in >the middle and reading backwards if you prefer.) By means of a >hyperlink, the session start document automagically traverses the user >to the valuable read-only asset. Upon arrival at the read-only asset, >the BOS is still pretty much guaranteed to include the session-start >document; otherwise, the user couldn't have arrived at the read-only >asset. This only works if your read-only asset inherits the BOS of all the documents in the chain used to reach it, or the BOS of a start point document that covers the whole of a document set. What you are talking about in the first of these is the browser's History list. But how on earth do I know which entry in my History list is the one that contains the copyright notice and any necessary disclaimers? On the Web there is no guarantee that you will access a document via its session start document. In fact, for any reasonably large data set you can normally guarantee that you won't. So the question becomes "how do you identify the BOS" associated with this page if it resides with the session start document". What you need to do is to have a pointer to the BOS that says "This Web page should be used with this BOS". (Isn't this the catalog for the file set?) >If the user is running an application which is like any >typical Web browser, the session-start document is still in a local >cache, so the frailty of the Web network is not even an issue. The >session-start document contains links which effectively place one or >more hot links at various points in the read-only asset back to the >session-start document. When traversed, those hot links can take the >user to the copyright notice or the license agreement, or whatever. How? The problem is which set of links should be used. If I annotate one of your documents the session start document will point to my copyright notice. When looking at a hot-link I have added to your document, according to your methods, I need to know both who created the link and, more importantly, who created the text being referenced. This is only possible if your page contains a pointer to your copyright information and my link contains a pointer to my copyright notice. >The valuable read-only asset never needs to be edited unless its >substantive content must change. The session-start document can be >changed at the pleasure of the owner of the read-only asset, with no >danger to the main asset. In fact, it can easily be made to bear a >license stamp unique to each licensee. I don't see how this last would work if the locator for the copyright info is stored as part of the read-only asset. Unique use of a license over the web implies dynamic allocation of some information that needs to be maintained by the browser in some safe way. This has to be done using some form of cookie. Can cookies reroute locators? ---- 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, 30 Dec 1996 07:56:50 -0500 From: gtn@ebt.com (Gavin Nicol) To: cbullard@hiwaay.net CC: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh Len writes: >> I never said I saw a set of IDL interfaces as being a the desired >> output from this WG, and ideed, even quired whether it was in our >> charter to do anything about semantic definition. > >I will be interested to see if we can avoid it forever. >A No stylesheet is involved. An Agreed these are a particular application's behavior, but >they are the common things done with links and what any >Web user will expect to do with XML links. This is actually a very important point, and one that you repeat a number of times in various forms. My personal view is that a link definition is just the same as any other data until interpreted, and that we can separate definition and definition of interpretation. Date: Mon, 30 Dec 1996 08:39:34 -0500 From: gtn@ebt.com (Gavin Nicol) To: cbullard@hiwaay.net CC: mtbryan@sgml.u-net.com, w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh >I don't think you can avoid behavior for long. Maybe. I can't articulate very well the exact model I have in my head, but... If we go with the link-as-data model (late semantic binding), what we *really* need to define here is what comprises a grove, the primitives used to locate objects within it, traverse it, and transform it, a way of grouping/ordering the primitives, a way of manipulating/interacting with the result of such primtives (or a group of them), and a way of binding primtives to nodes in a grove. Interestingly enough, most of this has already been done elsewhere... Date: Mon, 30 Dec 1996 07:58:40 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Can we be more concrete? Realized last night I forgot to associate the image map in my example with the image. I also forgot the coordinates. Oops. Below are the necessary corrections: At 08:42 PM 12/29/96 -0900, W. Eliot Kimber wrote: > > > > > > > ID ID #REQUIRED > coords CDATA #REQUIRED > notation (imagemap) #FIXED "imagemap" [...] A bunch of transistors A bunch of nand gates Cache ROM Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 30 Dec 1996 10:19:26 -0600 From: len bullard To: Gavin Nicol CC: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh Gavin Nicol wrote: > > Len writes: > > >> I never said I saw a set of IDL interfaces as being a the desired > >> output from this WG, and ideed, even quired whether it was in our > >> charter to do anything about semantic definition. > > > >I will be interested to see if we can avoid it forever. > >A >No stylesheet is involved. An >Agreed these are a particular application's behavior, but > >they are the common things done with links and what any > >Web user will expect to do with XML links. > > This is actually a very important point, and one that you repeat a > number of times in various forms. > > My personal view is that a link definition is just the same as any > other data until interpreted, and that we can separate definition and > definition of interpretation. My definition is the same. What will be needed is the definition of interpretation such that two XML systems do it somewhat the same way. For that, we could use object definitions nicely, because it fits well with EAPIs and communicates to implementors precisely what is needed. My feeling, and only that because I've seen no proposals, is that using DSSSL for this may be just as hard or harder. For independent links, my concept is more like the catalog as an independent file (entity) which the document instance has a pointer to. Easy to explain, easy to use, and already in use in exisiting applications for SGML and stylesheets. len Date: Mon, 30 Dec 1996 10:27:16 -0600 From: len bullard To: Gavin Nicol CC: w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh Gavin Nicol wrote: > > If we go with the link-as-data model (late semantic binding), what we > *really* need to define here is o what comprises a grove, Already done. *The* XML grove, no. Is there such a thing, or is a grove for XML plus a grove and or grove plan for each XML application needed? o the primitives used to locate objects within it, traverse it, and transform it, Primitives? Need to clarify. Functions? o a way of grouping/ordering the primitives collections? sets? lists? o a way of manipulating/interacting with the result of such primtives ( or a group of them), and a way of binding primtives to nodes in a grove. Functions again? > Interestingly enough, most of this has already been done elsewhere... As you say, and as I say to Tim, "most of us can imagine this and already have" in our existing systems, but not here yet. Proposals are needed. To get the credibility needed for acceptance, not only the spec, but appendices on implementation and/or working code will be needed. len Date: Mon, 30 Dec 1996 11:34:28 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: More proposals -- and some critical implementation issues Despite my distrust of uncritically accepting HyTime as a starting point, I think there's a lot of good stuff available in HyTime. The fact that my proposed link types correspond to HyTime basic constructs is a good indicator of that fact. But now we come to the hard part: Architectural forms. The notion of laying a semantic architecture on top of a DTD, is a brilliant one, since it allows better abstraction than a DTD can accomodate. But there is a real problem in using architectural forms in XML. Since a AF is determined by examining the attribute list, an XML parser operating without a DTD will fail to pass the "STOOOPID" test, because the markup for elements will be ludicrously redundant-seeming: We can't use default values, because then essentially all browsers will have to fetch DTDs to recognize links... And we already decided we don't want to force that for such simple processing (especially given the likelihood that fetching of stylesheets will be required). So how do we resolve this riddle? We punt. No, not really. We define AFs as the way to recognize link markup in general, and we use attribute defaulting to make the markup sufficiently compact. So what about browsers? We put all the operational semantics of links into the stylesheet language, so that a stylesheet can allow simple navigation applications to detect and render links. Analytical applications will have to fetch the DTD, if they need complete information about possible link elements. I think XML should have a much simpler way of indicating AFs than HyTime's set of attributes. XML AF attribute names should simply be fixed, for instance, when a form is defined. This will inconvenience the few prior users of HyTime (like the TEI), who have assumed that attributes may be renamed, but will simplify the user's and implementors life significantly. It may also mean that existing linking DTDs will need some XML-compatibility changes... This is a good way to take advantage of partitioning the problem, and gets us some significant benefits: 1. no hardwired tag names. 2. With the addition of extra attributes we can be HyTime compatible. 3. Browsers don't need DTD information to (at least) render links. 4. Link behavior (in stylesheet) separated from link indication (DTD). So, given that, I propose for discussion: XML linking architecture is indicated by an attribute: -XML-ARCH-LINK We have AFs something like this: AF declarations: > > I didn't deal with explainers here, as they may involve some complication (they don't fit nicely as attributes, but extra elements may be too complex). I still think they are important, but wanted to get something out fast. I need to learn more DSSSL to give stylesheet examples or proposals. Others are welcome to contribute if they have ideas. -- 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: Mon, 30 Dec 1996 10:37:36 -0600 From: len bullard To: "W. Eliot Kimber" CC: w3c-sgml-wg@www10.w3.org Subject: Re: Can we be more concrete? W. Eliot Kimber wrote: > > Realized last night I forgot to associate the image map in my example with > the image. I also forgot the coordinates. Oops. Below are the necessary > corrections: > > At 08:42 PM 12/29/96 -0900, W. Eliot Kimber wrote: > > > > [...] > > > > > > > image CDATA #REQUIRED > > > > > > > > > > ID ID #REQUIRED > > coords CDATA #REQUIRED > > notation (imagemap) #FIXED "imagemap" > > [...] > > > A bunch of transistors > A bunch of nand gates > Cache ROM > > > Cheers, > > E. Ok. You may need to specify an origin (upper left, lower left, etc.). Now you have the sort of thing done in the systems I've seen with this exception. The coordinates may not be in the calling document. They may be part of the records of the image handler software. The calling document may be calling a named region using a convention. For example, a road map has border coordinates that divide the printed map into say, two inch square regions (the two inch is relevant only to the printing). The handling software may use this convention to impose a grid dividing the map into a set of squares. The author "names" each square (named location), and the image handler keeps the association of name to pixel coordinates. What the calling document passes is the name, perhaps the handler name, and a command string telling the handler to open up at the image zoomed to that region. Right now, to do this sort of thing, we keep two different sets of independent links (e.g, structs). One for the image handler's view of a document set; one for the SGML handler's document set. What we need is for these to be one set. len Date: Mon, 30 Dec 1996 12:19:34 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Link Behaviors >>o the primitives used to locate objects within it, traverse it, and >transform it, >Primitives? Need to clarify. Functions? As far as I can tell, we need query functions, and the ability to specify a few behaviors: Offer choice of options (menu or list as appropriate to display device) transclude content navigate, replacing current document, navigate, creating a new display area (as appropriate to display device) Highlight linkend (since it may not be in the markup, this cannot be part of normal rendering) Can anyone think of any other link behavior we need? >Proposals are needed. And starting, I think. > To get the credibility needed for acceptance, >not only the spec, but appendices on implementation and/or working >code will be needed. I have not seen any suggestion that is remotely problematic enough to necessitate this yet. It may happen, but not yet. -- 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: Mon, 30 Dec 1996 12:19:25 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Suggestion: A link model At 3:24 PM 12/29/96, W. Eliot Kimber wrote: >In HyTime, the anchor roles of a particular link type must be the same for >all instances of the type *in the same document.* This is partly because >in the new HyTime design, addressing of anchors is done by attributes whose >names correspond to the anchor roles--therefore the anchor role names must >be unique within the type and they must be fixed or you couldn't declare >the attributes. Steve DeRose and I have strongly argued against this mis-feature of HyTime many times. It is a pointless restriction that means that one _cannot_ define multi-ended links where the number of linkends is defined by the application. I thought that this was slated to go away in the TC. (At least I hoped there was a chance that someone would want to represent pop-up menus as multi-ended links). I strongly urge that we not adopt this "feature" of HyTime. I expect Eliot to claim that the above is false. I do not believe that composite anchors (discontinuous selections) are the same as multiple link endpoints, and so I do not accept the proposal that he is likely to make. I also think that _for XML_ this will not work, as I think that discontinuous link endpoints (HyTime (unrevised) multlocs) should not be part of XML. They are a bit too esoteric for our audience, I think. >Note that we do now have way to indicate that it is *not an error* to for a >given anchor role to consist of zero objects (i.e., that you can choose to >not address anything for a particular anchor role). That means that you >can make any anchor-addressing attribute optional if it is not an error for >that anchor to be null. > What is the syntax for this? In (uncorrected) HyTime, they are both lists of IDs, in 1-1 correspondence, so you cannot "leave one out". I really hope to get to read the TC soon, but I'd rather get a degree and see XML on its way. -- 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: Mon, 30 Dec 1996 12:19:38 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Grove plans? At 10:27 AM 12/30/96, len bullard wrote: >Gavin Nicol wrote: >> >> If we go with the link-as-data model (late semantic binding), what we >> *really* need to define here is > >>o what comprises a grove, >Already done. *The* XML grove, no. Is there such a thing, or is a >grove for XML plus a grove and or grove plan for each XML application >needed? We will have to define an XML grove (plan?) for DSSSL support, but there should be only _one_ grove (plan?) for XML. That was the import of all the RS/RE discussion. We want _one_ abstract syntax. The "benefit" of more than one is the ability to handle SGML's confusing parsing model (which we have already simplified) and the ability to mystify people with a bunch of new terms for old concepts. I am not a number. I am an undefined character. _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Date: Mon, 30 Dec 1996 12:19:41 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: clink/ilink direction (Was: anchor awareness) At 7:13 PM 12/29/96, Joe English wrote: >Groves are like trees in that every node with the exception >of a unique root node has a single parent. However, nodes >in a grove also have a collection of named properties, >whose values can be either "plain data" or a list of >references to other nodes. Nodal properties (those whose >value is a list of nodes) are classified as either "subnode >properties" or "reference node properties"; every node >except for the root is a member of a subnode property of >exactly one other node in the grove (i.e., its parent), but >there are no restrictions on reference node properties. If >you consider only the subnode properties, you have a tree; >if you consider the reference node properties as well, you >have a directed (possibly cyclic) graph. > >Further, non-leaf nodes have a single distinguished subnode >property designated as the "content property"; if you >consider only the content properties you get the >"principal tree" of the grove. For example in the >SGML grove plan, attribute nodes are subnodes of element >nodes, but they are not part of the principal tree. Thanks for the first clear explanation I have seen. >David Durand wrote: >> Ah, kind of like a parse tree. In fact, exactly like. > >A grove is nothing like a parse tree in the sense >of the term with which I am familiar (a representation >of a derivation of a string of terminals with respect to >a grammar); they're more like an abstract syntax tree >(i.e., a representation of the information derived from >the parse tree) augmented with cross-references between nodes. You are correct. I used the terminology sloppily, while wearing my implementor hat: I think of the tree that my Yacc grammars build as a parse tree, but it is actually an abstract syntax tree (with annotations). So a grove is what everyone else calls an abstract syntax tree. The point about new terminology for old concepts still holds, I think. Many ASTs in implementations (as opposed to textbooks) are so annotated (with cross-references). >> My inclination agaist groves stems from: >> 1. The complexity of groves (reflecting the complexity of full SGML parsin >> g). > >The grove data structure taken by itself is really quite >simple and elegant. The SGML property set is horrendously >complex, but if you only consider the "important" parts >(e.g., ESIS plus a few extra properties that got left out) >groves are very useful. (Cost 2 uses a grove-like data >structure for its internal representation, so I can attest >to their utility.) But this really supports my point. I have taken most of the "use groves" stuff to refer to the property set. Since we are defining an abstract syntax representation, we need not constrin application data structures at all, just what objects and relationships are available. I would advise using standard terminology instead of new terminology so that people will understand things. If that ends up being logically equivalent to some grove plan, fine, but I'm not clear that groves per se offer much to the non-HyTime/DSSSL expert, but a lot of new terminology. So I agree with your points, but I still don't find them convincing. All we need is ASTs where internal nodes have labelled slots to get all the data content of a grove. And Len and Gavin are right, that using OO terminology is likely to make this clearer to programmers than using grove terminology (as long as we keep the operational aspects separate). -- 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: Mon, 30 Dec 1996 18:14:03 +0100 From: "Norbert H. MIKULA" To: w3c-sgml-wg@www10.w3.org Subject: Problems with WD-xml-961114 (productions) Hi, I am working on an XML parser in Java. During this effort I came across a few productions that I couldn't really understand. ad 56: Default := '#REQUIRED' | '#IMPLIED' | ('#FIXED'? QuotedCData) shouldn't it read like Default := '#REQUIRED' | '#IMPLIED' | ('#FIXED'? S QuotedCData) The "S" is not really needed for the parsing but I think it should be there the enhance readability. ad 59: csdata := (internalsubset) shouldn't it read like csdata := (internalsubset)* ad example on page 19 unless "-" is a member of extender or ignorable; I have to admit that I didn't check; the example "&Pub-Status; doesn't really make sense to me. I hope I didn't miss postings to w3c-sgml-wg that had to do with the same problems and are already solved. (I apologize for questions are obviously of stupied nature) Thanx for clarification ..... PS: I am refering to WD-xml-961114 which was handed around at SGML '96. For some reason the online version, http://www.w3.org/pub/WWW/TR/WD-xml-961114.html doesn't seem to be consistent with that one (although it has the same date-stamp) http://www.textuality.com/sgml-erb/WD-xml.html seems to be. -- Best regards, Norbert H. Mikula ===================================================== = SGML, DSSSL, Intra- & Internet, AI, Java ===================================================== = mailto:nmikula@edu.uni-klu.ac.at = http://www.edu.uni-klu.ac.at/~nmikula ===================================================== Date: Mon, 30 Dec 1996 10:16:25 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: More proposals -- and some critical implementation issues At 11:34 AM 12/30/96 -0500, David G. Durand wrote: > The notion of laying a semantic architecture on top of a DTD, is a >brilliant one, since it allows better abstraction than a DTD can >accomodate. But there is a real problem in using architectural forms in >XML. Since a AF is determined by examining the attribute list, an XML >parser operating without a DTD will fail to pass the "STOOOPID" test, >because the markup for elements will be ludicrously redundant-seeming: > > > >We can't use default values, because then essentially all browsers will >have to fetch DTDs to recognize links... Note that as currently defined (and implemented by SP), there are defaulting rules for associating element types with architectural forms, specifically, an element whose type is the same as a form in the active architecture is taken to be of that form. Thus, if we define an XML architecture and assume that all XML processors use it, then, assuming "ilink" is a form in the architecture, it is unnecessary to specify the redundant architecture attribute. [...] > We put all the operational semantics of >links into the stylesheet language, so that a stylesheet can allow simple >navigation applications to detect and render links. Analytical applications >will have to fetch the DTD, if they need complete information about >possible link elements. I don't think this is punting--I think it's a natural way to solve the problem. There's nothing that says you can't put the architectural recognition in your style sheet (you can do it today with DynaText, albeit inefficiently, by using the #DEFAULT style and having a buch of switch() functions conditioned on form name for the relevant properties). A style sheet is nothing more than a processor specification, after all. > I think XML should have a much simpler way of indicating AFs than >HyTime's set of attributes. XML AF attribute names should simply be fixed, >for instance, when a form is defined. This will inconvenience the few prior >users of HyTime (like the TEI), who have assumed that attributes may be >renamed, but will simplify the user's and implementors life significantly. >It may also mean that existing linking DTDs will need some >XML-compatibility changes... So you would disallow attribute renaming? I suppose that's ok, especially if we prefix all XML attributes with "-xml-". Renaming is disallowed by default--you can choose not to define a renaming attribute, and if you don't, no way to rename. > I need to learn more DSSSL to give stylesheet examples or proposals. >Others are welcome to contribute if they have ideas. I have it on my to-do list to create DSSSL style sheet that implements the InfoMaster architecture. Don't know when I'll get to it, but the basic approach would, I think, be to replace the use of the element function with a new function, archform, that checks the architectural form just as element checks the element type. I haven't had time to work out the details of the function, but it can't be that hard. Another approach would simply be to apply the style sheet to the architectural instance rather than to the base document instance, which you can do with Jade by using the -A flag to specify the architecture name. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 30 Dec 1996 11:35:02 -0600 From: len bullard To: "David G. Durand" CC: w3c-sgml-wg@www10.w3.org Subject: Re: Link Behaviors David G. Durand wrote: > > As far as I can tell, we need query functions, and the ability to specify a > few behaviors: Yes. > Offer choice of options (menu or list as appropriate to display device) > transclude content PickOne. PickMany. (someone near MID group will remember why the Logo, "more meta than thou" was used). '=) > navigate, replacing current document, goto > navigate, creating a new display area (as appropriate to display device) spawn - do it, then it is the framework's problem > Highlight linkend (since it may not be in the markup, this cannot be > part of normal rendering) > > Can anyone think of any other link behavior we need? gosub - navigate, do what you do, return here It is convenient to be able to specify a chain: an entry point which is fixed for sequences of instructions. In MID, we used an element type and that may be best left as an application convention. >> Proposals are needed. > And starting, I think. Yes. Looking good. > > To get the credibility needed for acceptance, > >not only the spec, but appendices on implementation and/or working > >code will be needed. > > I have not seen any suggestion that is remotely problematic enough to > necessitate this yet. It may happen, but not yet. I keep it in mind because I haven't experienced a successful project of this type that didn't need it. We tend to forget that even with our individual differences, we know a lot we assume others know. Having seen that error before, I've learned the value of the point and click proof. API appendices make it explicit what is always expected of a language handler. Given that XML is a metanotation, is this needed? An API is also a data declaration of function/message calls. Is it the case that defining a standard XML handler is a separate effort from XML-the-language? Is it the case that several groups may undertake this as a standards effort with the usual ensuing lack of interoperability? len Date: Mon, 30 Dec 1996 10:36:26 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Can we be more concrete? At 10:37 AM 12/30/96 -0600, len bullard wrote: >of name to pixel coordinates. What the calling document passes is >the name, perhaps the handler name, and a command string telling >the handler to open up at the image zoomed to that region. > >Right now, to do this sort of thing, we keep two different sets of >independent links (e.g, structs). One for the image handler's >view of a document set; one for the SGML handler's document set. >What we need is for these to be one set. In the HyTime model, these would be location addresses, not links. I'm not sure I understand the point of your comment: I thought my proposal was sufficient (not that I was trying to propose a useful scheme for doing image addressing--it was just a quick example). Certainly the image map could be another document, e.g.: ]> ... If I understand you correctly, the "name" in your discussion would be the ID of the areas in the image map document. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 30 Dec 1996 12:08:46 -0600 From: len bullard To: "W. Eliot Kimber" CC: w3c-sgml-wg@www10.w3.org Subject: Re: Can we be more concrete? W. Eliot Kimber wrote: > > At 10:37 AM 12/30/96 -0600, len bullard wrote: > > >of name to pixel coordinates. What the calling document passes is > >the name, perhaps the handler name, and a command string telling > >the handler to open up at the image zoomed to that region. > > > >Right now, to do this sort of thing, we keep two different sets of > >independent links (e.g, structs). One for the image handler's > >view of a document set; one for the SGML handler's document set. > >What we need is for these to be one set. > > In the HyTime model, these would be location addresses, not links. yes. Pixel addresses are absolute locations in concrete documents. > I'm not > sure I understand the point of your comment: I thought my proposal was > sufficient (not that I was trying to propose a useful scheme for doing > image addressing--it was just a quick example). It is. I wanted to point out what was missing. As soon as pixel coordinates are separated from content, the origin is needed for complete independence, or the maintainer makes assumptions about the image notation handler. IOW, sometimes, the notation declaration *is* needed and I am getting confused if the notation of the content type (e.g, the tiff, gif, VRML is indicated). > Certainly the image map could be another document, e.g.: > > > ]> > > > ... > > > If I understand you correctly, the "name" in your discussion would be the > ID of the areas in the image map document. Can be, but it could just be a label. Whatever, it is unique in some known namespace. BTW, are you assuming the use of a URL resolver? In the #prefix convention, a lot of strings are appended to the locator, and that assumes one knows what strings are available. So, for management's sake, how does the example look if one is pointing out of a document instance into the independent link set document using a URL? Is it as simple as appending the name of the linkset document plus the link id to the URL with the proviso that the linkset document handler knows to goto/gosub/spawn the target? Sounds like a catalog. From a management perspective, BOS management is catalog management and all the document instance needs to know is the name of its catalog. "Stylesheet is a processor specification": I like that. Style is overloaded like everything else. That distinction is good where for some XML systems, they might not wish to also send a stylesheet. len Date: Mon, 30 Dec 1996 11:11:05 -0900 To: dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Suggestion: A link model At 12:19 PM 12/30/96 -0500, David G. Durand wrote: >At 3:24 PM 12/29/96, W. Eliot Kimber wrote: >>In HyTime, the anchor roles of a particular link type must be the same for >>all instances of the type *in the same document.* This is partly because >>in the new HyTime design, addressing of anchors is done by attributes whose >>names correspond to the anchor roles--therefore the anchor role names must >>be unique within the type and they must be fixed or you couldn't declare >>the attributes. > > Steve DeRose and I have strongly argued against this mis-feature of >HyTime many times. It is a pointless restriction that means that one >_cannot_ define multi-ended links where the number of linkends is defined >by the application. I thought that this was slated to go away in the TC. >(At least I hoped there was a chance that someone would want to represent >pop-up menus as multi-ended links). I strongly urge that we not adopt this >"feature" of HyTime. The HyTime design team obviously disagrees with Steve and David on this point (and in fact, is about the only point on which we *do* disagree in any fundamental way). I think we may be seeing a collision of conflicting requirements that cannot be satisfied by a single solution. We think we have provided an adequate, general, and consistent solution to the problem of representing menus through the use of combinations of hylinks and agglinks. > I expect Eliot to claim that the above is false. I do not believe that >composite anchors (discontinuous selections) are the same as multiple link >endpoints, and so I do not accept the proposal that he is likely to make. I >also think that _for XML_ this will not work, as I think that discontinuous >link endpoints (HyTime (unrevised) multlocs) should not be part of XML. >They are a bit too esoteric for our audience, I think. I disagree that multiple locations should not be a part of XML--I think they are a significant value add, being one of the things that will distinguish XML linking from HTML linking. It's also possible that we have a terminology conflict here. In HyTime, "multiple link endpoints" requires that you have multiple anchor roles, one for each link end. Allowing variable numbers of link ends means requiring variable anchor roles *AND* (here's the catch) requires that a unique anchor role be specified for each distinct link end. Our reasoning is that the analysis of the roles within a link type is best done at the time the type is declared. It would, we think, be undully onorous to require authors to make up (probably arbitrary) anchor role names when all they want to do is add to the list of things linked. Thus, we provide the agglink form which lets you relate an unlimited number of things together without first defining a distinct role name for each. We also feel, obviously, that the anchor roles are a *constant* property of a link type--if you want a different set or number of roles, it's a new type, so declare a new type (which, by the way, XML makes pretty easy since you can omit the formal declaration altogether if you want to). Or, create a new document in which the same type has a different definition. >>Note that we do now have way to indicate that it is *not an error* to for a >>given anchor role to consist of zero objects (i.e., that you can choose to >>not address anything for a particular anchor role). That means that you >>can make any anchor-addressing attribute optional if it is not an error for >>that anchor to be null. >> > >What is the syntax for this? In (uncorrected) HyTime, they are both lists >of IDs, in 1-1 correspondence, so you cannot "leave one out". Not any more. Please review my summary of TC changes: the new syntax for hyperlinks is that there is one attribute per anchor role, the so-called "anchor-addressing attributes". We have also clarified that it is possible for most location address elements to address empty lists. This provides at least two ways for an anchor to fail to address anything: either by simply omitting the anchor-addressing attribute or using a location address that returns an empty node list. Here are examples of both: ... Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 30 Dec 1996 13:31:38 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: More proposals -- and some critical implementation issues At 10:16 AM 12/30/96, W. Eliot Kimber wrote: >At 11:34 AM 12/30/96 -0500, David G. Durand wrote: >>We can't use default values, because then essentially all browsers will >>have to fetch DTDs to recognize links... > >Note that as currently defined (and implemented by SP), there are >defaulting rules for associating element types with architectural forms, >specifically, an element whose type is the same as a form in the active >architecture is taken to be of that form. Thus, if we define an XML >architecture and assume that all XML processors use it, then, assuming >"ilink" is a form in the architecture, it is unnecessary to specify the >redundant architecture attribute. I thought of that but I think it is probably namespace pollution: especially since an AF name _might_ collide with an element name. And unlike HyTime, I don't think we should have required markup to turn on linking functionality, so that the namespace pollution couldn't be turned off easily. >I don't think this is punting--I think it's a natural way to solve the >problem. There's nothing that says you can't put the architectural >recognition in your style sheet (you can do it today with DynaText, albeit >inefficiently, by using the #DEFAULT style and having a buch of switch() >functions conditioned on form name for the relevant properties). Punting was really a joke, referring to the fact that we are letting the DTD slide in a case where it seems to be required. Of course its the natural way to solve the problem, I suggested it, didn't I? >So you would disallow attribute renaming? I suppose that's ok, especially >if we prefix all XML attributes with "-xml-". Renaming is disallowed by >default--you can choose not to define a renaming attribute, and if you >don't, no way to rename. It just seems complicated, and I'm not sure the benefit is worth it. I do agree that there is benefit, but I could live without it, I think. > >> I need to learn more DSSSL to give stylesheet examples or proposals. >>Others are welcome to contribute if they have ideas. > >I have it on my to-do list to create DSSSL style sheet that implements the >InfoMaster architecture. Don't know when I'll get to it, but the basic >approach would, I think, be to replace the use of the element function with >a new function, archform, that checks the architectural form just as >element checks the element type. I haven't had time to work out the >details of the function, but it can't be that hard. What I don't understand is how we specify navigation behavior in DSSSL. Is there a way to attach new "methods" to elements? Functional properties or lexical closures maybe? If so, we have a great hook... > >Another approach would simply be to apply the style sheet to the >architectural instance rather than to the base document instance, which you >can do with Jade by using the -A flag to specify the architecture name. I think the notion of architectural instances is too confusing, especially since we are trying for a single abstract syntax tree. An architectural instance is inherently another abstract syntax tree for the same document, but accoridng to the architectural form's abstract syntax. This is a big bunch of stuff to add to every XML processor. -- 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: Mon, 30 Dec 1996 11:51:04 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Can we be more concrete? At 12:08 PM 12/30/96 -0600, len bullard wrote: >> In the HyTime model, these would be location addresses, not links. > >yes. Pixel addresses are absolute locations in concrete documents. What I meant was that *however* you did the addressing, it would be a location address and never a link (using the strict distinction between linking and addresing that HyTime makes). >> I'm not >> sure I understand the point of your comment: I thought my proposal was >> sufficient (not that I was trying to propose a useful scheme for doing >> image addressing--it was just a quick example). > >It is. I wanted to point out what was missing. As soon as pixel >coordinates are separated from content, the origin is needed for >complete independence, or the maintainer makes assumptions about >the image notation handler. IOW, sometimes, the notation declaration >*is* needed and I am getting confused if the notation of the >content type (e.g, the tiff, gif, VRML is indicated). Yes, because I was using a URL directly to address the image (and not an entity whose system identifier was a URL), I lost the notation declaration. Of course, we can depend on MIME types to make the proper association, right? >BTW, are you assuming the use of a URL resolver? In the #prefix >convention, >a lot of strings are appended to the locator, and that assumes one knows >what strings are available. I'm not sure what you mean. I thought use of URLs (and therefore support for their resolution) was a hard requirement for XML. So, for management's sake, how does the >example look if one is pointing out of a document instance into the >independent link set document using a URL? Is it as simple as appending >the name of the linkset document plus the link id to the URL with the >proviso that the linkset document handler knows to goto/gosub/spawn >the target? Again, I'm not sure what you mean. Do you mean linking from a document to an independent link? You'd address it just as you would anything else: but note that addressing a link doesn't necessarily cause anything to happen: you're just addressing the link as another element. In HyTime, at least, links only cause behavior when traversal between link ends happens. Sounds like a catalog. From a management perspective, >BOS management is catalog management and all the document instance >needs to know is the name of its catalog. I think you can think of it that way: the BOS is nothing more than a list of the entities that need to be examined for possible links and link ends. As the HyTime BOS is determined by the entities *declared*, not the entities referenced, you can define a BOS using a trivial document that declares all the entitites in the BOS and then contains a single contextual link to the first starting point of the real data (and even this last isn't strictly required, although it's sort of implied by the current wording of the standard--but an application is free to provide whatever access behaviors it wants, including letting the reader select from a list of available documents, e.g., what DynaText does when you open a collection.), e.g.: ... ]> Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 30 Dec 1996 14:15:13 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org Martin Bryan on Mon, 30 Dec 1996 09:36:14 +0000) Subject: Re: unmarked linkend awareness by XML engines > >Upon arrival at the read-only asset, > >the BOS is still pretty much guaranteed to include the session-start > >document; otherwise, the user couldn't have arrived at the read-only > >asset. > This only works if your read-only asset inherits the BOS of all the > documents in the chain used to reach it, or the BOS of a start point > document that covers the whole of a document set. Yes, but it is literally impossible for such inheritance NOT to take place without deliberate user intervention. If a user is in a document, then that document is by definition in the BOS. If a user traverses to another document, he can only get there by adding that document to the BOS. When he arrives at the traversed-to document, removal of the traversed-from document from the BOS can only be done deliberately and consciously. There is no automatic removal of items >from the BOS. But what HyTime says (or doesn't say) is irrelevant here. The important thing is that this concept works, it works solidly, it's as foolproof as it can be, it answers Terry's heartfelt and very real requirement, it imposes no unreasonable demands on applications, it's relatively easy to implement, and it provides very significant power that is now unavailable to Web users. > What you are talking about in the first of these is the browser's > History list. But how on earth do I know which entry in my History > list is the one that contains the copyright notice and any necessary > disclaimers? Because the session-start (hub) document was in fact browsed by the user, the links it contains are known to the application, and their linkends in other documents, when the user stumbles across them for whatever reason, are therefore also known to the application, full stop. There is no need to look anything up. None of this imposes a requirement for a history list. The application is responsible for knowing where the links are that it is providing the hotspots for, and, since it knows where the links are, it also knows their other linkends and can take you there, if possible, on demand. > On the Web there is no guarantee that you will access a document via > its session start document. In fact, for any reasonably large data > set you can normally guarantee that you won't. So the question > becomes "how do you identify the BOS" associated with this page if > it resides with the session start document". What you need to do is > to have a pointer to the BOS that says "This Web page should be used > with this BOS". (Isn't this the catalog for the file set?) When you use the BOS concept, the only thing that matters is the user's decisions as to which documents (and therefore, which link sets) are known to the application. As I said before, upon arrival at any document, the user has the option of adding that document's BOS to the actual BOS in effect for this session, or of replacing the active BOS with that document's BOS (which means that the application will "forget" about the links that exist in documents that are not present in the new BOS). At any time, the user can create and/or use *any* BOS. If the user fails to use any suggested BOS, the user does so at his own risk. If this means that he may unknowingly violate some term of his license agreement, that's tough for him. Ignorance does not excuse malfeasance, especially when pains have been taken to ensure that access to the relevant knowledge is easily available. > >If the user is running an application which is like any > >typical Web browser, the session-start document is still in a local > >cache, so the frailty of the Web network is not even an issue. The > >session-start document contains links which effectively place one or > >more hot links at various points in the read-only asset back to the > >session-start document. When traversed, those hot links can take the > >user to the copyright notice or the license agreement, or whatever. > > How? The problem is which set of links should be used. If I annotate one of > your documents the session start document will point to my copyright notice. Oops. I do not understand why your annotation of my document has anything to do with this discussion, so I'm now going to try to bring your scenario together with mine. If Martin annotates Steven's valuable read-only document, then Martin must put Martin's annotations in Martin's own document. (I'm assuming here that Martin's rights do not include the right to change Steven's document.) Privately, Martin loans his annotations to David. If David wants to read Steven's document as annotated by Martin, David must include Martin's document in David's session's BOS, as well as Steven's document, in order to see Martin's annotations in the context of Steven's document. If David does not include Martin's annotation document in David's session's BOS, he can't see Martin's annotations in the context of Steven's document, or in any other context, for that matter. The BOS *is* the user's context in some very fundamental sense. Steven and Len are both publishers. Steven's valuable document was not always Steven's; Steven bought all the right, title, and interest in the valuable document from Len. At the same time, in effect, Steven bought all of Len's customers for that valuable document, because Len's former customers still need access to the valuable document and now they're going to pay Steven for usage rights similar to those they had when Len owned it. The document used to be in Len's catalog, but now it's in Steven's. (Len's catalog provides a forwarding address to Steven's catalog, as a courtesy to Len's former and current customers.) Not wishing to endanger the value of the document that Steven bought from Len, Steven doesn't edit it, but instead Steven provides it with a separate session-start document. Steven's and Len's catalogs do not give the address of the document itself; they only give the address of the session-start document, so customers pretty much have to start there. (If they don't start there, that's their problem, because ignorance of what's in the advertised session-start document will not excuse them from abiding by its terms.) In order to gain access to the valuable document, they *must* add at least some of Steven's session-start document's suggested BOS to their BOS in order to get to the valuable document, because the suggested BOS is the only place where the actual address of the valuable document can be found, and you can't traverse to something that's not in your BOS. In any case, the links in the session start document must be processed by the application because, by definition, you can't be in a document without it itself being in your BOS. Therefore, any annotation links in the session-start document that can take users from the valuable document back to session-start document, where Steven's license arrangements with the user are documented, are guaranteed to be in the user's BOS. Imagine now that Martin publishes his annotations. "Wow," Eliot says, reading about this new publication. "I never did understand what that document of Len's was trying to say, and I generally understand Martin's explanations. I'm going to try reading it again along with Martin's annotations." So Eliot buys the right to use Martin's annotations from Martin, and the right to use Steven's valuable document from Steven (or maybe from Martin because by arrangement with Steven, Martin resells those rights along with his annotations). Eliot enters Steven's document by means of the session-start document that Steven provided, and he adds Martin's annotations to his BOS manually. (Or, more likely, he starts with Martin's annotations document, which is easier because it includes Steven's session-start document in its suggested BOS. Or, maybe Martin didn't hear that Len had sold the document to Steven, so Martin's annotations document's suggested BOS includes only Len's old address for the document; this causes no problem, because what's at that address now is a placeholder document whose suggested BOS includes Steven's session-start document, and perhaps some XML/Web-specific way of saying "Any entity declarations that give the address of this document should be changed to reflect its new address: http://www.steven.org/Old_Len_Document.xml". Of course, this new address is not actually the address of the valuable document; it's the address of the session-start document that Steven wants all users to have in their BOSs when viewing the valuable document.) When Eliot arrives at the valuable document, both Steven's copyright notice (and other licensing information) and Martin's annotations are available as hot links from within the valuable document. The valuable document, of course, need contain no evidence that any of this is going on. One of the great beauties of doing things this way is that Martin's annotation links can't go stale just because Steven bought the annotated document from Len. Steven didn't have to edit the document in order to change the licensing information. No matter how Martin's links addressed the contents of the valuable document -- even (*gulp*) by counting all the byte offsets to each linkend -- Martin's annotation document only needs to change exactly one entity declaration in order to keep working, and that's absolutely the only change necessary. (For purposes of this discussion, I'm ignoring the possibility of any sort of public cataloging utility that might obviate any necessity for Martin even to change the entity declaration.) If ilinks, anchor awareness, and the BOS concept are supported, anybody can annotate anything, even when the thing being annotated is read-only. (Aside to Terry: The owner of the thing being annotated certainly has the right to forbid the publication of such annotations as a condition of licensed use. I don't think you can -- or would want to -- prevent people from doing something which is just like writing in the margins of books that they have purchased. The publication of such marginalia is another matter, of course.) --Steve Steven R. Newcomb President voice +1 716 271 0796 TechnoTeacher, Inc. fax +1 716 271 0129 (courier: 23-2 Clover Park, Internet: srn@techno.com Rochester NY 14618) FTP: ftp.techno.com P.O. Box 23795 WWW: http://www.techno.com Rochester, NY 14692-3795 USA Date: 30 Dec 1996 19:22:26 +0000 (GMT) From: Peter Flynn Subject: Re: Anchor terminology from Ralph Ferris on 29 Dec 1996 17:56:21 -0800) To: ralph@fsc.fujitsu.com Cc: w3c-sgml-wg@www10.w3.org "When at anchor here I ride, My bosom swells with pride! And I snap my fingers at the foe-man's taunts ..." - Gilbert and Sullivan, "HMS Pinafore" I prefer the last 6 lines of Goethe's _Torquato Tasso_, where the shipwrecked sailor clings hopelessly to the very rocks on which his ship has been wrecked :-) Perhaps the irony of this will not be lost in the pursuit of backward compatibility ad infinitum... ///Peter Date: Mon, 30 Dec 1996 12:33:02 -0900 To: dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: More proposals -- and some critical implementation issues At 01:31 PM 12/30/96 -0500, David G. Durand wrote: >At 10:16 AM 12/30/96, W. Eliot Kimber wrote: >>At 11:34 AM 12/30/96 -0500, David G. Durand wrote: >What I don't understand is how we specify navigation behavior in DSSSL. Is >there a way to attach new "methods" to elements? Functional properties or >lexical closures maybe? If so, we have a great hook... Remember that DSSSL only defines the creation of flow objects--a second process then interprets the flow objects into a final presentation. It's the methods associated with the flow objects that would determine behavior. DSSSL provides the Link flow object class:
Link Flow Object Class A link flow object represents a hypertext link that can be interactively traversed, typically by clicking on the areas representing the flow object and its content. A link has a single principal port, which can contain both inlined and displayed flow objects. Link flow objects can be nested, and the innermost link is effective. It has the following characteristic: destination: is either #f or an object of type address or a list of one or more objects of type address. See . This characteristic is not inherited and shall be specified. A value of #f is used for a nested link and indicates that the contents of the flow object shall not be considered part of the containing link.
Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 30 Dec 1996 11:33:25 -0800 (PST) From: Terry Allen To: w3c-sgml-wg@www10.w3.org Subject: Policy in XML (concrete) Upon reflection and the return of electricity (it's good to have a battery- powered TV if you want to watch yearend football in the North Bay), I think the answer to my question, "Where in the XML architecture do I state my use policy" is "nowhere." My policy may apply to many data types, and I don't want to have to find a specific way to state it wrt each data type. Instead, I may want to state it by implementation. E.g., I may wish to allow access to my stuff only through a copyright notice that must appear first; I can do that by disallowing any access that does not evidence previous receipt of the copyright notice. At the same time (or not) I might allow access to pieces of my stuff only through ilinks of my own ("link to me only with mine I's") so as to control what is being linked to. And I might require the requestor to include the URI of the link end from which the request emanates (e.g., by requiring the HTTP Referer [sic] header, see HTTP 1.1 sect 14.37), perhaps even the entire chain of links, and perhaps all the other link ends, too. That information would give me quite a bit to work if I want to check on the conditions under which my stuff is being used. I could, for example, check, or spot-check, to see if the referring document includes "3. Should the *methods* associated with objects *always* be informed when they are addressed as an anchor? This is a bit more subtle, because it can be difficult or impossible to do this in all environments (e.g., when the anchors are addressed by a query against the entire Web). In other words, in the general case its useful or necessary to defer resolving some anchor addresses until the anchor is traversed to (or access to the anchor is otherwise requested). This means that there will always be anchors that do not know they are anchors at the time link is created, only at the time an attempt is made to address the anchor. In order to make what I suggest work, it may be necessary to refine what the URI in Referer means. But I don't now see any requirements on XML or its linking mechanisms, although XML linking may require the specification of new URL schemes in any event. 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: Mon, 30 Dec 1996 11:47:37 -0800 (PST) From: Terry Allen To: w3c-sgml-wg@www10.w3.org Subject: BOS clarification? I'm having trouble matching up what Eliot and Steve are saying about BOS with what I know from the 1992 version of 10744, section 6.2.4.2. In part: A bounded object set can be determined authomatically by the HT engine by constructing an "entity tree", starting with the SGML doc entity of the hub doc as the root. The entity tree includes external entities declared in the hub doc, then external entities declared in those entities, and so on. ... A limit can be placed on the depth of the entity tree by the "bounding level" att of the hub document. ... Does this not mean that every external entity declared in the hub doc (and every external entity in those entities) is part of the BOS? And might it not be the case that I declare as entities in my hub doc certain public text (part of the US Constitution, for example) that are not part of my copyrighted intellectual property? (I might declare them for the use of links that refer or traverse to them, rather than for transclusion.) The bounding level att works only when my work happens to end at the same level throughout, so appears not to be a solution. So isn't BOS applicable to the problem of defining the extent of my intellectual property/literary work only if I can contrive not to declare as external entities anything that doesn't belong to the work? 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: Mon, 30 Dec 1996 15:10:26 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Suggestion: A link model At 11:11 AM 12/30/96, W. Eliot Kimber wrote: >The HyTime design team obviously disagrees with Steve and David on this >point (and in fact, is about the only point on which we *do* disagree in >any fundamental way). I think we may be seeing a collision of conflicting >requirements that cannot be satisfied by a single solution. We think we >have provided an adequate, general, and consistent solution to the problem >of representing menus through the use of combinations of hylinks and agglinks. >> I expect Eliot to claim that the above is false. I do not believe that >>composite anchors (discontinuous selections) are the same as multiple link >>endpoints, and so I do not accept the proposal that he is likely to make. I >>also think that _for XML_ this will not work, as I think that discontinuous >>link endpoints (HyTime (unrevised) multlocs) should not be part of XML. >>They are a bit too esoteric for our audience, I think. > >I disagree that multiple locations should not be a part of XML--I think >they are a significant value add, being one of the things that will >distinguish XML linking from HTML linking. I like them too, but the case is not as strong as it is for ilink (which has been spontaneously proposed many times in WWW contexts). Aggregate link endpoints are not nearly as popular, so I think we could leave them out. They also present display problems, particularly for the rather retarded user-interface models typical of current browsers. >It's also possible that we have a terminology conflict here. In HyTime, >"multiple link endpoints" requires that you have multiple anchor roles, one >for each link end. Allowing variable numbers of link ends means requiring >variable anchor roles *AND* (here's the catch) requires that a unique >anchor role be specified for each distinct link end. I don't see any terminology problem here. I just disagree that anchor roles have to be fixed. > Our reasoning is that >the analysis of the roles within a link type is best done at the time the >type is declared. It would, we think, be undully onorous to require >authors to make up (probably arbitrary) anchor role names when all they >want to do is add to the list of things linked. It's unduly onerous to require a static type declaration when they do not have a fixed set of linktypes and roles. Strong typing is useful, but not everyone wants it. If you don't want it, how can you turn it off? > Thus, we provide the >agglink form which lets you relate an unlimited number of things together >without first defining a distinct role name for each. What if I want to dfine distinct role names for each, but not in advance? That is the feature request, and blusterung about link types does not change the answer that you are giving "No, because _we believe_ that it is not what yolu really want." >We also feel, obviously, that the anchor roles are a *constant* property of >a link type--if you want a different set or number of roles, it's a new >type, so declare a new type (which, by the way, XML makes pretty easy since >you can omit the formal declaration altogether if you want to). Or, create >a new document in which the same type has a different definition. So, HyTime is incapable of representing a hypertext system that does not limit link types to a static list. This is not a limitation that we should take over into XML. It is not a limitation that has been justified either. I am _not_ questioning that strong linktypes can be useful, just that they must be mandatory for what is supposed to be an inclusive standard (HyTime). And the equivalent information (rev and rel) in HTML is not strictly controlled in the way that you are asking. Nor are the HTTP Link: header values. These might be relevant hypertext functions that XML would wish to subsume! >Not any more. Please review my summary of TC changes: the new syntax for >hyperlinks is that there is one attribute per anchor role, the so-called >"anchor-addressing attributes". We have also clarified that it is possible >for most location address elements to address empty lists. This provides >at least two ways for an anchor to fail to address anything: either by >simply omitting the anchor-addressing attribute or using a location address >that returns an empty node list. Here are examples of both: This is truly unfortunate. The original design was susceptible of improvement, this one is not. XML should define a mechanism for assigning anchroles to the endpoints of an agglink, in that case, and maybe the HyTime committee will see fit to include it. In fact, I think the solution I proposed will still work, but just won't be HyTime compatible any more, since HyTime is too inflexible to accomodate it. Can we make agglink equivalents of both clinks and ilinks? -- 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: Mon, 30 Dec 1996 14:56:54 -0600 From: len bullard To: "W. Eliot Kimber" CC: w3c-sgml-wg@www10.w3.org Subject: Re: Can we be more concrete? W. Eliot Kimber wrote: > > Yes, because I was using a URL directly to address the image (and not an > entity whose system identifier was a URL), I lost the notation declaration. > Of course, we can depend on MIME types to make the proper association, right? So they tell me. I have to read the URL draft just received. > >BTW, are you assuming the use of a URL resolver? In the #prefix > >convention, > >a lot of strings are appended to the locator, and that assumes one knows > >what strings are available. > > I'm not sure what you mean. I thought use of URLs (and therefore support > for their resolution) was a hard requirement for XML. It is, I believe. It comes under "gotta live with what is working". Can't say I like the #hack. How does this fit with the concept of separately storing queries so that they can be reused by multiple links in multiple documents? I want to point to a query multiple times much like a function is prototyped, then called whereever needed. As to *available*, I am thinking about a scenario where the author is "blind" to the existence of multiple representations. For example, the "graphic" in one system is a set of 2D drawings, in another, a 3D model is used. The author only knows they want to point at the "flywheel assembly view" so, in the first case, they have to locate a gif with inserts, in the second case they have to get a camera view. What I want the author to use to link is the logical name for the part, e.g, the reference designator for the flywheel assembly. Nothing so far indicates I can't use indirection for this. Just want to point out it is needed. Why? Because I want to pick up the document and put it on a portable device not connected to the network. I want the associations for the graphics on the portable device (might not be 3D capable) to be immediate and automatic. > So, for management's sake, how does the > >example look if one is pointing out of a document instance into the > >independent link set document using a URL? Is it as simple as appending > >the name of the linkset document plus the link id to the URL with the > >proviso that the linkset document handler knows to goto/gosub/spawn > >the target? > > Do you mean linking from a document to > an independent link? Yes. > You'd address it just as you would anything else: but > note that addressing a link doesn't necessarily cause anything to happen: > you're just addressing the link as another element. In HyTime, at least, > links only cause behavior when traversal between link ends happens. Good so far. > Sounds like a catalog. From a management perspective, > >BOS management is catalog management and all the document instance > >needs to know is the name of its catalog. > > I think you can think of it that way: the BOS is nothing more than a list > of the entities that need to be examined for possible links and link ends. Ok. The rest seems to work as I assume it would. len Date: Mon, 30 Dec 1996 14:43:47 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: BOS clarification? At 11:47 AM 12/30/96 -0800, Terry Allen wrote: > >I'm having trouble matching up what Eliot and Steve are saying about BOS >with what I know from the 1992 version of 10744, section 6.2.4.2. In part: > > A bounded object set can be determined authomatically by the HT engine > by constructing an "entity tree", starting with the SGML doc entity of > the hub doc as the root. The entity tree includes external entities > declared in the hub doc, then external entities declared in those > entities, and so on. ... A limit can be placed on the depth of the > entity tree by the "bounding level" att of the hub document. ... > >Does this not mean that every external entity declared in the hub doc >(and every external entity in those entities) is part of the BOS? And >might it not be the case that I declare as entities in my hub doc >certain public text (part of the US Constitution, for example) that >are not part of my copyrighted intellectual property? (I might >declare them for the use of links that refer or traverse to them, >rather than for transclusion.) Yes and yes. The BOS is orthogonal to any notion of transclusion or any other semantic that might be associated with a particular link. >The bounding level att works only when my work happens to end at >the same level throughout, so appears not to be a solution. To fix this problem, we've given you a way to explicitly include in the BOS entities that might therwise be excluded. This is intended primarily to let you include things like graphics that are semantically part of a document when they would otherwise be excluded from the BOS. You can also explicitly *exclude* entities. >So isn't BOS applicable to the problem of defining the extent >of my intellectual property/literary work only if I can contrive >not to declare as external entities anything that doesn't belong >to the work? I think you're right. I think I would prefer to have an application specific "stuff that I own" document whose semantic is to define the scope of my intellectual work. This document could be used as a hub document (and thus would define a BOS), but wouldn't necessarily depend on the BOS facility of HyTime to convey the semantics of ownership. It would also be a natural place to apply access policies. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 30 Dec 1996 14:43:51 -0900 To: dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Suggestion: A link model At 03:10 PM 12/30/96 -0500, David G. Durand wrote: >At 11:11 AM 12/30/96, W. Eliot Kimber wrote: [...] >> Thus, we provide the >>agglink form which lets you relate an unlimited number of things together >>without first defining a distinct role name for each. > >What if I want to dfine distinct role names for each, but not in advance? >That is the feature request, and blusterung about link types does not >change the answer that you are giving "No, because _we believe_ that it is >not what yolu really want." I think I understand David's feature request. We have certainly discussed the issue of variable anchor roles at some length during the TC design, but it was usually in a difference context which I don't think is as well justified as David's. I see also that this is a primary point of potential failure in trying to design an XML linking approach that happens to also be HyTime conforming. >This is truly unfortunate. The original design was susceptible of >improvement, this one is not. XML should define a mechanism for assigning >anchroles to the endpoints of an agglink, in that case, and maybe the >HyTime committee will see fit to include it. > >In fact, I think the solution I proposed will still work, but just won't be >HyTime compatible any more, since HyTime is too inflexible to accomodate >it. Can we make agglink equivalents of both clinks and ilinks? It would certainly be possible for XML to use the agglink form and then define an XML-specific way to associate anchor roles with members of the aggregate, but that would be a hack--it would be better to fix the design at its core (which has been David's point all along, of course). This will take some careful thought, but there might be a way to make it work. I should point out that I think the new hylink syntax, where each role has its own addressing attribute is much easier to use and explain than the old ilink syntax, where you had to explain (and validate) the positional correspondence between anchor roles and anchor addresses (complicated by the fact that indirect addressing could obscure what was being addressed--you didn't just count IDs in the linkends attribute value). The feature David wants would require the ilink-style addressing syntax with a single attribute for all the link ends--a syntax that in my experience of teaching HyTime is a difficult one for people to use. Let me also ask this: do we agree that when we *don't care* about anchor roles, that an aggegate link is sufficient? Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 30 Dec 1996 14:55:16 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Can we be more concrete? At 02:56 PM 12/30/96 -0600, len bullard wrote: >W. Eliot Kimber wrote: >> I'm not sure what you mean. I thought use of URLs (and therefore support >> for their resolution) was a hard requirement for XML. > >It is, I believe. It comes under "gotta live with what is working". >Can't say I like the #hack. How does this fit with the concept of >separately storing queries so that they can be reused by multiple >links in multiple documents? I want to point to a query multiple times >much like a function is prototyped, then called whereever needed. Assuming that XML provides/supports/requires indirect addressing, then you should be able to use the #name syntax to address a location address that is a query, e.g.: Basset hounds are slobber monsters. basset+hound Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 30 Dec 1996 17:49:06 -0500 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu CC: cbullard@HiWAAY.net, eliot@isogen.com, w3c-sgml-wg@www10.w3.org Subject: Re: Anchors Aweigh > We don't need to sprinkle OO magic dust over declarative linking to make >XML fly, we just need to decide on a syntax, and some simple metadata. (I >think this is Gavin's model, and I'm not surprised that if this is so, we >are in agreement again...) This is pretty much my model, though I think it would be an interesting project (as you note, perhaps outside the scope of this WG) to model the WWW, and various forms of linking as objects. Date: Mon, 30 Dec 1996 17:22:02 -0600 From: len bullard To: "W. Eliot Kimber" CC: w3c-sgml-wg@www10.w3.org Subject: Re: Can we be more concrete? W. Eliot Kimber wrote: > > Assuming that XML provides/supports/requires indirect addressing, then you > should be able to use the #name syntax to address a location address that > is a query, e.g.: > > > Basset hounds are slobber monsters. > > > > > basset+hound > That works for me. len Date: Mon, 30 Dec 1996 15:32:57 -0800 (PST) From: Terry Allen To: eliot@isogen.com, w3c-sgml-wg@www10.w3.org Subject: Re: Can we be more concrete? Eliot replies to Len: | >> I'm not sure what you mean. I thought use of URLs (and therefore support | >> for their resolution) was a hard requirement for XML. | >It is, I believe. It comes under "gotta live with what is working". | >Can't say I like the #hack. How does this fit with the concept of | >separately storing queries so that they can be reused by multiple | >links in multiple documents? I want to point to a query multiple times | >much like a function is prototyped, then called whereever needed. | Assuming that XML provides/supports/requires indirect addressing, then you | should be able to use the #name syntax to address a location address that | is a query, e.g.: | | | Basset hounds are slobber monsters. | | | | | basset+hound | Yes, assuming that you proclaim that it is part of the XML MIME type that unqualified fragment addressing into XML entities points to IDs (not controversial, but I think a necessary step). And this is a good start on a scenario. So, what indicates the semantics of the link to the query? It isn't the HTTP method. Is it the semantics of ? What indicates whether the query shall be displayed per se, the result of the query shall be trancluded (and in what format), or the result of the query shall be presented as a menu list, or the most desireable (per some set of preferences) of the list results shall be traversed to? 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: Mon, 30 Dec 1996 18:24:04 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re: Can we be more concrete? At 03:32 PM 12/30/96 -0800, Terry Allen wrote: >Eliot replies to Len: >| Assuming that XML provides/supports/requires indirect addressing, then you >| should be able to use the #name syntax to address a location address that >| is a query, e.g.: >| >| >| Basset hounds are slobber monsters. >| >| >| >| >| basset+hound >| > >Yes, assuming that you proclaim that it is part of the XML MIME >type that unqualified fragment addressing into XML entities points to IDs >(not controversial, but I think a necessary step). And this >is a good start on a scenario. Yes, that's my assumption. >So, what indicates the semantics of the link to the query? It isn't >the HTTP method. Is it the semantics of ? In the HyTime model, it's the semantics of addresses in general: that any reference to a location address is a reference to whatever the location address addresses (recursed until you either get only non-location addresses, reach the "reflevel" limit, or have a circular reference). This behavior of addresses is independent of linking (in other words, the same address resolution behavior would result from an ID reference that was not a "link" as we're defining it here). What >indicates whether the query shall be displayed per se, >the result of the query shall be trancluded (and in what >format), or the result of the query shall be presented as >a menu list, or the most desireable (per some set of preferences) >of the list results shall be traversed to? That would be the semantics of Crossref and/or the refsub anchor role and/or the data addressed by the query and/or whatever the browser chooses to do. The semantics could be defined in the XML link spec or in a style sheet or some combination thereof. Certainly XML could provide attributes for hinting at the desired behavior if we felt that was appropriate. Cheers, E. -- W. Eliot Kimber (eliot@isogen.com) Senior SGML Consulting Engineer, Highland Consulting 2200 North Lamar Street, Suite 230, Dallas, Texas 75202 +1-214-953-0004 +1-214-953-3152 fax http://www.isogen.com (work) http://www.drmacro.com (home) "Rats in the morning, rats in the afternoon...if they don't go away, I'll be re-educated soon..." --Austin Lounge Lizards, "1984 Blues" Date: Mon, 30 Dec 1996 17:18:43 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org Martin Bryan on Mon, 30 Dec 1996 09:36:09 +0000) Subject: Re: unmarked linkend awareness by XML engines > The word "responsible" is one that gives me great problems. > If I create a page that has a link to some text on a page you have created, > in what way am I "responsible" for the contents of this page. Obviously I > have no copyright to it. I have no right to add any contents to it. I have > no right to add any ids to it to identify the text that I was referring to. > I have no mechanism for ensuring you do not a) remove the text I was > referring to, b) remove links in the text that I was referring to, c) add > links to the text I was referring to, d) add or remove any other part of the > document. Of course you are right in everything you say. You're arguing with a point I don't believe and never intended to make. I meant to say that a HyTime *application* is responsible for keeping track of the linkends of all the links in the BOS. "Responsible" means only that if the user stumbles across one of those linkends, the application must be able to inform the user that it is indeed a linkend, perhaps by rendering it as a hotspot. It must also be able to provide traversal services to the other linkends. No more and no less. This has nothing to do with copyright or other any other rights issues. It has only to do with what a HyTime application is expected to know about the current BOS, full stop. > > It [the BOS concept] gives > >an application much more power to make information useful and > >accessible, by limiting the amount of information over which such > >power must be exercised. > > Not unless you have proper versioning control and fully record the state of > the referenced file at the time you created the links. In practice what you > suggest however does not "limit the amount of information over which power > is exercised" but unnecessarily extends it to a level where it is unmanageable. For the life of me, Martin, I can't see why you say this. It's quite manageable. I can only conclude that you don't understand what I'm trying to say, and/or that we have disturbingly different understandings about what a HyTime BOS is. > Not according to the model you give below - there is no guidance, simply a > mass copying of pointers found in related documents. What "mass copying of pointers"? I have no idea what you are talking about. There is nothing in my mind about copying anything at all. Please explain what you are thinking. > We cannot expect link management to be > done by either an authoring system or an XML browser (which I presume is > what David is referencing when he talks about a user's application here). > Link management has to be a separate function, run at regular intervals > between link creation and link navigation. What do you mean by "link management"? If it's link maintenance and periodic testing, then it's not what I have been talking about (although it's a good idea for anyone who owns links to dynamic documents). > >According to HyTime, the BOS *suggestion* presumably takes effect when > >the user begins a session by entering a particular document. Nothing > >requires that the user accept the document author's suggestion. > > How an earth can a browser or its user determine which of the "BOS > suggestions" are relevant? If you're only in one document at a time, there's only one suggestion in effect at a time. If you accept the document's suggested BOS, then you are trusting the author of that document to take you where you want to go. There's no "which". There's only one "whether" per document, and therefore only one "whether" at a time. What's the problem? > >Indeed, if the user insists on making the whole Web the BOS of his > >session, he can sit there and wait until his beard hits the floor. > > How will he ever know that he was insisting on this? Surely he is not going > to be given a browser that has functions that say "follow all links in all > documents linked to this one"? Even crawlers run on supercomputers are not > stupid enough to adopt this approach: I don't see anyone realistically > suggesting that this approach would work on a 286! We can only assume that people who insist on things know what they're insisting on and are prepared to live with the consequences. On the other hand, if an author of a document provides a suggested BOS of such immensity that it causes users' computers to stop dead for hours at a time, then that's a pretty bad document and a pretty irresponsible author, or it's a document intended for the use of a pretty specialized audience. Ordinary users would do well not to take that author's suggestions seriously. > In Web terms what the "UWOS" [Unbounded Web Object Set] needs to state is > the set of entities for which access _must_ be provided by the application > to make sense of the "document" being accessed by the browser via that > start-page. Are you proposing a new term, "UWOS"? What do you mean by this? In what sense is it "unbounded" if only certain entities need to be accessed? > The concept to "arbitrary limits on how deeply these entities > can recursively declare other entities" is both irrelevant and highly > dangerous on the web. Why is it irrelevant, and why is it dangerous to limit how deeply entities can recursively declare other entities? On the contrary, I think it would be highly dangerous *not* to limit such recursion. > >If, in the course of traversing the links in the session-start > >document, the user encounters another document, the user certainly has > >the option of accepting *that* document's suggestion as to what the > >BOS should be (making that document effectively the session-start > >document), or, of adding that document's BOS to his existing, > >session-dependent BOS, or of simply ignoring the suggestion and > >keeping the present BOS, or of doing something else entirely. > > This will not work, for a number of reasons. > > Firstly look at the situation where I make a reference to just part of one > of your documents. The links in the part of the document that I refer to > _may_ be relevant to the BOS, but those that occur in the rest of your > document are unlikely to be relevant. So what? If they do not have any linkends in the BOS, then they have no effect. > (otherwise I would have referred to that part of the document as > well). There is no reason to make any such assumption. Maybe the author of the annotation document got tired and went to bed. > How can I determine which of the entries > in the referenced document's set would be relevant? If I copy them all then > my object set is no longer "bounded" - it is distinctly unbounded as far as > my document is concerned! There is no requirement that you add any traversed-to document's suggested BOS to your BOS. You insist that I am saying this, but I have repeatedly and very explicitly said exactly the opposite. Yes, the traversed-to document itself is necessarily in the BOS. BUT THE TRAVERSED-TO DOCUMENT'S SUGGESTED BOS IS NOT ADDED TO THE BOS UNLESS THE USER DECIDES TO DO THAT! The user is under no compulsion to do any such thing, and neither is the application. One way to keep down the number of documents in the BOS is to add them only when the user requests them, perhaps by attempting to traverse a link to a document which is not currently in the BOS. The fact that the document is not currently in the BOS only means that the application is not currently responsible for the links contained in that document. Once you do enter that document, however, the application becomes responsible for the links in that document that have linkends in any documents that are already in your BOS, as well as any linkends in the new document of links that are already in your BOS. > Now look what happens when you edit the referenced document, and > delete or change some of the links in it. If those links are in the > area I have referenced then the copy of the entity list that I took > when authoring is now out of date. How do I determine this? If they > are outside the area that I am referring to I don't care about the > changes, even if this means that the "complete copy" of the entity > set I took earlier is now out of date. But how can I tell that the > change in the entity set is one that does not affect my UWOS? What is all this about copying? What's being copied, where is it being copied to, and why? I didn't say anything about copying. If you are discussing the creation of documents that record the BOSs that are accumulated in sessions, that's an interesting idea, but I have never suggested it. > (What I need is to be able to reference the BOS of the referenced > document independently of the document itself in such a way that I > can identify when it has been changed so that I can then revalidate > my own document's references.) The BOS is forgotten as soon as the session is over. It doesn't exist anywhere but transiently and very dynamically in the memory of a computer running a HyTime application. Are you worrying about the fact that a BOS's physical addresses can go stale during a session? If so, I submit that we don't need to worry about that now. Your remark seems to indicate that you think I am suggesting that the each session-start document contain a copy of all of the suggested BOSs of all the entities in its own suggested BOS. I am not suggesting that, and I have never intended to suggest that. > >The existence of a BOS suggestion *enables* ilinks by making them > >practical and scalable, which in turn *enable* the creation of > >annotations of read-only materials which can be seen in the context of > >the read-only document. > If I reference your read-only material by an existing link, how can > I determine whether there are already sets of annotations associated > with this document? The answer to this question is obvious: you can't. Without recourse to something else -- such as a publisher's catalog, or the online equivalent of _Books In Print_, you can't know whether, for example, someone has published a commentary on Winston Churchill's _The Gathering Storm_. You certainly can't tell from any copy of _The Gathering Storm_, even those printed after the publication of the commentary. Despite the fact that the commentator would love to make an advertisement for his commentary appear right inside all copies of _The Gathering Storm_, fortunately or unfortunately, he doesn't have write access to that document, so he can't. I can't believe you would suggest that everyone have write access to everything, so I'm now wondering if you're suggesting that XML should undertake some sort of cataloging task to produce something like _Books In Print_? If so, I think this idea is impractical for the XML project and unnecessary in any event. People are already doing that and making money at it. I'm suggesting something quite practical and valuable, and, I would argue, badly needed. Please see my last note giving an example of how Martin's annotations of Len's old document, now owned by Steven, are used with that document by David under one scenario and by Eliot under another. > The only way I can know that a set of annotations exists for a > document at present is to access the annotations separately > first. What I really need to be able to is to have the document > identify for me which sets of annotations point to it. In other > words the document needs to "keep a record" of all files which > reference it in their UWOS. All a BOS associated with a set of > annotations could possibly tell you is the set of files the > annotations refer to. I take it all back. Incredibly, you *are* suggesting that everybody have write access to everything. To put in bluntly, this proposal will be as popular with publishers and information owners as a turd in a punch bowl. > I think David is pointing more to my idea of "the files that you > need access to to make sense of this document", rather than a > bounded object set. What I think is more relevant is to use the > History of links visited by the author of the annotations to create > a list of the files that must be made available to users, rather > that just saying that any file linked to any file that is referenced > should be recorded as part of the BOS. I have not proposed that "any file linked to any file that is referenced should be recorded as part of the BOS." I have repeatedly said something quite different and much more subtle. Hello? Whether a document may be created by recording the author's travels in browsing sessions is irrelevant, as is the broader question of how documents are created in general. > >Let me again rephrase the question I want answered: > > > >"Do we want XML to be able to make hot links available in documents > >when those documents do not themselves contain those hot links?" > > Yes - but this is totally different from the concept of a BOS. This is > inheritence of anchors dependent on the route by which you get to the > document. This must be a good thing. Martin, please explain to me what you think a HyTime BOS is, so we can determine why we evidently have such different ideas about it. But please do it offline -- not in this list. Most of these people don't care about what HyTime says anyway. I think, in fact, we agree about the ideas we're talking about (with the exception of providing write access to everything by everybody), but we incomprehensibly disagree about what HyTime BOSs are. > >It's do-able if we have, as Dave puts it, "additional notations to > >express that some document _may_ be processed when a document is > >processed." Or, as HyTime puts it, the bounded object set (BOS) > >concept. > > No - Dave has it correct - the HyTime BOS is not bounded enough! ... and please explain why you think the HyTime BOS is not bounded enough. This remark absolutely baffles me. --Steve Steven R. Newcomb President voice +1 716 271 0796 TechnoTeacher, Inc. fax +1 716 271 0129 (courier: 23-2 Clover Park, Internet: srn@techno.com Rochester NY 14618) FTP: ftp.techno.com P.O. Box 23795 WWW: http://www.techno.com Rochester, NY 14692-3795 USA Date: Mon, 30 Dec 1996 20:42:29 -0600 From: len bullard To: "W. Eliot Kimber" CC: w3c-sgml-wg@www10.w3.org Subject: Re: Can we be more concrete? W. Eliot Kimber wrote: > That would be the semantics of Crossref and/or the refsub anchor role > and/or the data addressed by the query and/or whatever the browser chooses > to do. The semantics could be defined in the XML link spec or in a style > sheet or some combination thereof. Certainly XML could provide attributes > for hinting at the desired behavior if we felt that was appropriate. As the year closes, what is looks like from here: 1. Ilinks - yes (spec to be defined). Links can point out to ilinks and ilinks can point in to "non-aware" content. Ilinks can be in separate documents where they effectively work as catalogs of relationships. Policy for the accessing of an ilink is application-specific or separately standardized just as policy for the access of ANY content is a management policy for a server-owner. (you can hit some sites as often as you like. without the password, no washee). 2. Semantics - per application ?? An
I suppose we could declare a format for "#" strings that encodes our >location ladder. In fact, doing so would solve a serious user-interface >problem for prospective browsers -- but I am not so sure that new magic URL >hackery is really very nice. There is something in this proposal, I think, >but it doesn't feel right to me yet. For instance I have proposed something like this many times. I think a real question here is whether to do it as a fragment (ie. the document is the primary object) or a pure URL (the element is the object). I tend toward the latter. What I proposed was a simple format: /foo.sgm/4/2/99 - Child numbers /foo.sgm/chap=1/sect=2/para=45 - Typed children This is easy to read, understand, and is useful for things like addresses in OODB, and RDB as well. >I still wish we were using HTTP headers instead of Processing Instructions >(the one SGML feature I have never even contemplated using). Amen to that! I was talking to someone who is planning to implement XML the other daya, and there is already misunderstanding about what that PI should do (ie. can it occur in places beyond the header, and if so, what does it do?). Headers are headers.... I guess my real avenue for promoting the *.mim format is to write a *.mim storage object handler for SP.... Date: Mon, 30 Dec 1996 23:55:27 -0500 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu CC: w3c-sgml-wg@www10.w3.org Subject: Re: More proposals -- and some critical implementation issues David writes: >So, given that, I propose for discussion: > >XML linking architecture is indicated by an attribute: > >-XML-ARCH-LINK > >We have AFs something like this: > > Playing the devil's advocate.... Assuming that link behaviour *will* be put out into stylesheets, we must ask if we need any fixed forms at all (ie. the sylesheet can decide what comprises a link, and what does not, and what the structure of a link definition needs to be in order to be semantically interpretable). I would say that for interoperability would be the main benefit. Date: Tue, 31 Dec 1996 00:11:18 -0500 From: gtn@ebt.com (Gavin Nicol) To: dgd@cs.bu.edu CC: w3c-sgml-wg@www10.w3.org Subject: Re: Link Behaviors >>Primitives? Need to clarify. Functions? > >As far as I can tell, we need query functions, and the ability to specify a >few behaviors: Here I was talking of things like simple traversal (tree-walking) and data retrieval (get attr value etc.) Date: Tue, 31 Dec 1996 11:15:23 +0000 To: dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: More proposals -- and some critical implementation issues At 13:31 30/12/96 -0500, David G. Durand wrote: >Punting was really a joke, referring to the fact that we are letting the >DTD slide in a case where it seems to be required. Of course its the >natural way to solve the problem, I suggested it, didn't I? I thought that it was sufficient to say that if you transmitted the DTD and expect the browser to parse that then you could define a fixed XML attribute in the DTD but if you did not transmit the DTD (because the browser could not process it) then you had to add the XML attribute to all instances of elements that are to exhibit linkedness. The idea of leaving it to the style sheet to say "this is a link" appals me as I cannot manage my links properly this way. (I could live with the link definition being defined as an SGML link attribute, but I suspect that would bring a ton of brickbats on my head!) ---- 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, 31 Dec 1996 11:15:25 +0000 To: Peter Flynn , ralph@fsc.fujitsu.com From: Martin Bryan Subject: Re: Anchor terminology Cc: w3c-sgml-wg@www10.w3.org At 19:22 30/12/96 +0000, Peter Flynn wrote: > "When at anchor here I ride, > My bosom swells with pride! > And I snap my fingers at the foe-man's taunts ..." > - Gilbert and Sullivan, "HMS Pinafore" > >I prefer the last 6 lines of Goethe's _Torquato Tasso_, where the >shipwrecked sailor clings hopelessly to the very rocks on which his >ship has been wrecked :-) Perhaps the irony of this will not be lost >in the pursuit of backward compatibility ad infinitum... But remember, if the anchor had been firmly attached to the seabed (the place where anchors temporarily reside when being used) there would have been no shipwreck - its only when they are moved from a known spot on the seabed that you run into trouble. My point was that anchors refer to where the link chain is attached to, not to the ship that let go of the anchor. ---- 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, 31 Dec 1996 11:19:08 +0000 To: "Steven R. Newcomb" , w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: unmarked linkend awareness by XML engines At 14:15 30/12/96 -0500, Steven R. Newcomb wrote: >> >Upon arrival at the read-only asset, >> >the BOS is still pretty much guaranteed to include the session-start >> >document; otherwise, the user couldn't have arrived at the read-only >> >asset. > >> This only works if your read-only asset inherits the BOS of all the >> documents in the chain used to reach it, or the BOS of a start point >> document that covers the whole of a document set. > >Yes, but it is literally impossible for such inheritance NOT to take >place without deliberate user intervention. Why? Can't I have a history file that automatically records all the BOS entries that I have traversed to in the session? (Let the computer do the work, not the user.) We seem to be talking at cross purposes again. What you call "the BOS" seems to be what I call the History - the list of entities visited during a session. To me a Bounded Object Set is the set of things that _could be_ accessed from a page, not the list that _has been_ accessed. Is this what you are recording? >If a user is in a >document, then that document is by definition in the BOS. If a user >traverses to another document, he can only get there by adding that >document to the BOS. When he arrives at the traversed-to document, >removal of the traversed-from document from the BOS can only be done >deliberately and consciously. There is no automatic removal of items >from the BOS. If you are saying that at each document you should add to your session BOS references to all entities pointed to by the current document then you are going to end up with horrendous BOS configurations if you use the web in the way I do. Typically I access 100+ documents from anything up to 50 servers at a session. I need the BOS to be segmented, perhaps on a per server basis, not as a whole. When I return to a particular document I would expect my BOS list to be truncated accordingly. >Because the session-start (hub) document was in fact browsed by the >user, the links it contains are known to the application, and their >linkends in other documents, when the user stumbles across them for >whatever reason, are therefore also known to the application, full >stop. There is no need to look anything up. The presumption that every user will come to the session-start (hub) document goes totally against the way the Web is used. You cannot guarantee where users will start looking at a document set accessible via the web. They may arrive at a set of XML links to a particular "document" from a link within a non-XML document. This is not their session-start point: it is simply the start point for the traversal of a document set defined from a particular set of links. (We need to define what we mean by a session - I suspect you are using it in terms of "arriving at a known set of related files that have a HyTime hub document": this is obviously not my definition!) >When you use the BOS concept, the only thing that matters is the >user's decisions as to which documents (and therefore, which link >sets) are known to the application. As I said before, upon arrival at >any document, the user has the option of adding that document's BOS to >the actual BOS in effect for this session, or of replacing the active >BOS with that document's BOS (which means that the application will >"forget" about the links that exist in documents that are not present >in the new BOS). At any time, the user can create and/or use *any* >BOS. If the user fails to use any suggested BOS, the user does so at >his own risk. How can the user (who have no overall view of the data they are using) assess such a risk? The scenarios you provided were great. The only problem I have is if I publish my annotations is monthly part, and my users subscribe to my annotations and choose one of these parts to start from. How can I arrange for them to see all of the annotations from all of the monthly commentaries unless I share an updatable BOS between them. If the BOS is separated from the annotations I have no problems. If it has to be part of the annotations I am in difficulty. ---- 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, 31 Dec 1996 11:19:01 +0000 To: "Steven R. Newcomb" From: Martin Bryan Subject: Re: unmarked linkend awareness by XML engines Cc: w3c-sgml-wg@www10.w3.org >> Not unless you have proper versioning control and fully record the state of >> the referenced file at the time you created the links. In practice what you >> suggest however does not "limit the amount of information over which power >> is exercised" but unnecessarily extends it to a level where it is unmanageable. > >For the life of me, Martin, I can't see why you say this. It's quite >manageable. I can only conclude that you don't understand what I'm >trying to say, and/or that we have disturbingly different >understandings about what a HyTime BOS is. Both: Firstly you are misusing the term HyTime BOS - as your other message shows. (I think of what you are talking about as a Session BOS - which I equate with Browser History - which makes much more sense of what you were saying.) A HyTime BOS is a BOUNDED object set created by recursively (to a controllable level) identifying all entities referenced from a particular hub document. As such it is simply a catalog of all entities referenced from a particular start point. You cannot build such catalogs for Web pages. What I thing you are talking about was a record of _all_ the files referenced during a session: a sort of history with embedded catalogs. This is what I was referring to as an Unbounded Web Object Set (UWOS). I think what David was talking about, and what I concur with, is a restricted list of files: those that _must_ be accessible to make sense of a particular document. Let me put this in context. For the last 2-3 weeks I've been struggling with maintaining a set of web pages for the European Commission. I have something like 20 possible hub documents, which cross refer to each other heavily, and also point out to many other source documents on the web. I can maintain the links between my own sets with difficulty. One problem I have is that I have to keep reordering my data as I split it up into finer fragments in an attempt to ensure that I do not cover more than 20 or 30 standards per section (delivered document). For example, I recently split the multimedia section so that video encoding standards were listed seperately from control standard. Checking that all of my pages referring to the original composite file now point to the correct part of the split file is pain enough. How do I let others pointing to my pages know I have changed them? The real problem I have is with maintaining links to other servers. For example, I point to the EWOS server for the specifications they create. This month they have reordered their site, putting a message at the original site to tell people that the site has been reordered but not taking them there. Now all my links to EWOS are invalid. I need to change all the links in the 20 odd files. How the hell do I do this easily? I want my locators clearly separated from my hub documents so that I can manage them. I don't want people to have to access through the site's home page (which is a 11 language selector) but want them to be able to start from any 'chapter' of the site and then access any other chapter the site may be connected to. However, I want the site's copyright rules made available to everyone accessing the site, no matter which point they start from, and I want people to be able to access all the information about using the site from any start point. (I do this easily by having standard headers and footers to my documents that point to the relevant location. This is no big deal, but needs to be borne in mind for XML - where an equivalent of the proposed HTML Banner is required for electronic headers/footers.) >> Not according to the model you give below - there is no guidance, simply a >> mass copying of pointers found in related documents. > >What "mass copying of pointers"? I have no idea what you are talking >about. There is nothing in my mind about copying anything at all. >Please explain what you are thinking. The recording of the BOS of preceding documents in a viewed link chain as part of the document's inherited history. >> We cannot expect link management to be >> done by either an authoring system or an XML browser (which I presume is >> what David is referencing when he talks about a user's application here). >> Link management has to be a separate function, run at regular intervals >> between link creation and link navigation. > >What do you mean by "link management"? If it's link maintenance and >periodic testing, then it's not what I have been talking about >(although it's a good idea for anyone who owns links to dynamic >documents). As the above scenario shows, link management to me is the combination of link testing and link address maintenance. I want this subject on the XML agenda at an early stage >> >According to HyTime, the BOS *suggestion* presumably takes effect when >> >the user begins a session by entering a particular document. Nothing >> >requires that the user accept the document author's suggestion. >> >> How an earth can a browser or its user determine which of the "BOS >> suggestions" are relevant? > >If you're only in one document at a time, there's only one suggestion >in effect at a time. This presumes that each document has a BOS associated with it. I was presuming, following the HyTime model, that a BOS would only be created for the hub documents of a site. > If you accept the document's suggested BOS, then >you are trusting the author of that document to take you where you >want to go. There's no "which". There's only one "whether" per >document, and therefore only one "whether" at a time. What's the >problem? I presumed that if I went to a linked document I would inherit the BOS of the document I linked from (otherwise how could I determine links in read-only documents). If I followed a link from that read-only document to another document I presumed I would have available to me the BOS suggestions of the start document, the BOS suggestions of the read-only document and the BOS suggestions of the new document. Is this not what you intended? Are you now saying that only the latest set of BOS suggestions is in force? If so how do you inherit links in read-only documents? >> >Indeed, if the user insists on making the whole Web the BOS of his >> >session, he can sit there and wait until his beard hits the floor. >> >> How will he ever know that he was insisting on this? Surely he is not going >> to be given a browser that has functions that say "follow all links in all >> documents linked to this one"? Even crawlers run on supercomputers are not >> stupid enough to adopt this approach: I don't see anyone realistically >> suggesting that this approach would work on a 286! > >We can only assume that people who insist on things know what they're >insisting on and are prepared to live with the consequences. I could not presume this for my readers - they could have no idea of the complexity of my document's links. I would need to put a warning up to tell them not to try to resolve all the links in the set as they would never finish the task. > On the >other hand, if an author of a document provides a suggested BOS of >such immensity that it causes users' computers to stop dead for hours >at a time, then that's a pretty bad document and a pretty >irresponsible author, or it's a document intended for the use of a >pretty specialized audience. Ordinary users would do well not to take >that author's suggestions seriously. The point is that what I want to do as an author is to specify a set of "must know" documents and say that the other links are to be used on a need to know basis. >> In Web terms what the "UWOS" [Unbounded Web Object Set] needs to state is >> the set of entities for which access _must_ be provided by the application >> to make sense of the "document" being accessed by the browser via that >> start-page. > >Are you proposing a new term, "UWOS"? What do you mean by this? >In what sense is it "unbounded" if only certain entities need to >be accessed? See above. It is unbounded in the sense that there are no constraints on where you have to look. You do not need to look for all links at all levels up to a specific point. It is a set of objects in unbounded web space. (I considered using Non-bounded, but could not pronoince NWOS!) > The concept to "arbitrary limits on how deeply these entities >> can recursively declare other entities" is both irrelevant and highly >> dangerous on the web. > >Why is it irrelevant, and why is it dangerous to limit how deeply >entities can recursively declare other entities? On the contrary, I >think it would be highly dangerous *not* to limit such recursion. It is highly dangerourns if the requirement is, as in the HyTime BOS definition, that you must identify all linked files to any level if no constraints are applied. If, however, you are referring to just resolving what you now call a Session BOS it is not dangerous. >> >If, in the course of traversing the links in the session-start >> >document, the user encounters another document, the user certainly has >> >the option of accepting *that* document's suggestion as to what the >> >BOS should be (making that document effectively the session-start >> >document), or, of adding that document's BOS to his existing, >> >session-dependent BOS, or of simply ignoring the suggestion and >> >keeping the present BOS, or of doing something else entirely. >> >> This will not work, for a number of reasons. >> >> Firstly look at the situation where I make a reference to just part of one >> of your documents. The links in the part of the document that I refer to >> _may_ be relevant to the BOS, but those that occur in the rest of your >> document are unlikely to be relevant. > >So what? If they do not have any linkends in the BOS, then they >have no effect. This is OK if they do not have any linkends in my BOS, but if they have linkends in the referenced documents BOS and that is inherited then they are likely to be irrelevant. Again we seem to be talking about different things! >> (otherwise I would have referred to that part of the document as >> well). > >There is no reason to make any such assumption. Maybe the author of >the annotation document got tired and went to bed. He should not publish an incomplete review!!! >> How can I determine which of the entries >> in the referenced document's set would be relevant? If I copy them all then >> my object set is no longer "bounded" - it is distinctly unbounded as far as >> my document is concerned! > >There is no requirement that you add any traversed-to document's >suggested BOS to your BOS. You insist that I am saying this, but I >have repeatedly and very explicitly said exactly the opposite. Yes, >the traversed-to document itself is necessarily in the BOS. BUT THE >TRAVERSED-TO DOCUMENT'S SUGGESTED BOS IS NOT ADDED TO THE BOS UNLESS >THE USER DECIDES TO DO THAT! The user is under no compulsion to do >any such thing, and neither is the application. This is the point of our misunderstanding. How can a user know whether he should add it or not? >One way to keep down the number of documents in the BOS is to add them >only when the user requests them, perhaps by attempting to traverse a >link to a document which is not currently in the BOS. The fact that >the document is not currently in the BOS only means that the >application is not currently responsible for the links contained in >that document. Once you do enter that document, however, the >application becomes responsible for the links in that document that >have linkends in any documents that are already in your BOS, as well >as any linkends in the new document of links that are already in your >BOS. A user of a document set needs guidance from the author to know whether he should extend his BOS when he does a specific traversal. My readers cannot know the relevance of my links to future traversal possibilities until after they have traversed them. As an author I could suggest that this set could usefully be added. (For example, if they are referencing another of my hub documents that is constantly referred to from this one I want to suggest that they add the BOS as otherwise they will constantly be swapping BOS sets.) >> Now look what happens when you edit the referenced document, and >> delete or change some of the links in it. If those links are in the >> area I have referenced then the copy of the entity list that I took >> when authoring is now out of date. How do I determine this? If they >> are outside the area that I am referring to I don't care about the >> changes, even if this means that the "complete copy" of the entity >> set I took earlier is now out of date. But how can I tell that the >> change in the entity set is one that does not affect my UWOS? > >What is all this about copying? What's being copied, where is it >being copied to, and why? I didn't say anything about copying. If >you are discussing the creation of documents that record the BOSs that >are accumulated in sessions, that's an interesting idea, but I have >never suggested it. I'm thinking in terms of recording History's (nested BOS sets) in the way you currently can Bookmarks, to save having to regenerate them each time you revisit the site. (This is important for my users, who will often want to break off a session and return to it at a later date with all the BOS information in place.) >> (What I need is to be able to reference the BOS of the referenced >> document independently of the document itself in such a way that I >> can identify when it has been changed so that I can then revalidate >> my own document's references.) > >The BOS is forgotten as soon as the session is over. It doesn't exist >anywhere but transiently and very dynamically in the memory of a >computer running a HyTime application. Are you worrying about the >fact that a BOS's physical addresses can go stale during a session? >If so, I submit that we don't need to worry about that now. Agreed, but I was hoping that a Session BOS would be reusable. You obviously are not thinking along such lines, but might like to reconsider. >Your remark seems to indicate that you think I am suggesting that the >each session-start document contain a copy of all of the suggested >BOSs of all the entities in its own suggested BOS. I am not >suggesting that, and I have never intended to suggest that. Sorry to misinterpret you. > >The existence of a BOS suggestion *enables* ilinks by making them >> >practical and scalable, which in turn *enable* the creation of >> >annotations of read-only materials which can be seen in the context of >> >the read-only document. > >> If I reference your read-only material by an existing link, how can >> I determine whether there are already sets of annotations associated >> with this document? > >The answer to this question is obvious: you can't. Without recourse >to something else -- such as a publisher's catalog, or the online >equivalent of _Books In Print_, you can't know whether, for example, >someone has published a commentary on Winston Churchill's _The >Gathering Storm_. You certainly can't tell from any copy of _The >Gathering Storm_, even those printed after the publication of the >commentary. Despite the fact that the commentator would love to make >an advertisement for his commentary appear right inside all copies of >_The Gathering Storm_, fortunately or unfortunately, he doesn't have >write access to that document, so he can't. I can't believe you would >suggest that everyone have write access to everything, so I'm now >wondering if you're suggesting that XML should undertake some sort of >cataloging task to produce something like _Books In Print_? If so, I >think this idea is impractical for the XML project and unnecessary in >any event. People are already doing that and making money at it. But wouldn't it be nice to ask AltaVista to search for all XML locators that pointed to a particular electronic copy of The Gathering Storm? My wife, who is a reference librarian, would just love such a facility to help her deal with just the sort of query you have used to ridicule my idea above. The point is that XML on the Web should allow us to overcome some of the restrictions we find in today's unautomated world. >> The only way I can know that a set of annotations exists for a >> document at present is to access the annotations separately >> first. What I really need to be able to is to have the document >> identify for me which sets of annotations point to it. In other >> words the document needs to "keep a record" of all files which >> reference it in their UWOS. All a BOS associated with a set of >> annotations could possibly tell you is the set of files the >> annotations refer to. > >I take it all back. Incredibly, you *are* suggesting that everybody >have write access to everything. To put in bluntly, this proposal >will be as popular with publishers and information owners as a turd in >a punch bowl. Yes, but publishers and information owners are only a small part of the Web community. If you are saying that XML is only for publishers and information owners then you better make this clear to the world upfront. Most of us believe that XML has a wider potential. I personally prefer to think of the web as a research tool. Thats how I use it every day. >> I think David is pointing more to my idea of "the files that you >> need access to to make sense of this document", rather than a >> bounded object set. What I think is more relevant is to use the >> History of links visited by the author of the annotations to create >> a list of the files that must be made available to users, rather >> that just saying that any file linked to any file that is referenced >> should be recorded as part of the BOS. > >I have not proposed that "any file linked to any file that is >referenced should be recorded as part of the BOS." I have repeatedly >said something quite different and much more subtle. Hello? You used the term HyTime BOS. By definition, therefore, you did say, indirectly, "any file linked to any file that is referenced should be recorded as part of the BOS." >Whether a document may be created by recording the author's travels in >browsing sessions is irrelevant, as is the broader question of how >documents are created in general. > >Martin, please explain to me what you think a HyTime BOS is, so we can >determine why we evidently have such different ideas about it. Hopefully my initial comments have done that. ---- 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, 31 Dec 1996 15:50:56 +0000 To: w3c-sgml-wg@www10.w3.org From: digitome@iol.ie (Digitome Ltd.) Subject: Re:Can we be more concrete... For the record, I am an ordinary software developer. I consider myself absolutely average as an exponent of that art. I am anxious to do my bit to try and ensure that the simplicity and clarity of XML is carried on into the realms of hypertext, rendering and beyond. If I irk anyone with my ignorance in what follows, I apologise in advance. However, in my defense I will say that I believe I am representative of the "Humble Software Developer" who needs to be sold on XML. If I have grave misunderstandings, I am not alone. Anyway, here goes:- 1. The simple things should be simple It will cut no ice with the software development community if XML Hypertext allows links from arbitrary tachyons to a range of faces on a hypercube *IF* this is at the expense of making "link this word to that file" an intellectual safari. There are many exceptional hypertext exponents on this list who know >from experience what sorts of Hypertext functionality is sorely missing from the Web. The sort of things that will make the eyes of current Web masters glaze over. What are these things? Is there an 80/20 rule applicable to Hypertext? 20% of hypertext concepts used 80% of the time? Should we not start by saying "here are the things that we *know* people are crying out for. Here are the things that will capture the imagination of Web implentors and users alike. Here are the things that will sell Web masters on XML". Can we isolate these things and concentrate on making them "no-brainers" to implement? 2. Hypertext as an XML application? Is Hypertext an application of XML or a raison d'etre of XML? I feel it is an application - one of myriads that can be envisaged. I think hypertext semantics/functionality should be *outside* the XML documents themselves for this reason. I am concerned about the architectural form approach because:- . Architectural Forms is an intellectual safari . Anything that can be expressed in an architectural form can also be described as an XML document. (I think!) >From a developers' perspective the idea of using the XML parser to process XML documents that "talk about" other XML documents in various ways sounds clean and appealing. It whould make it simple to do the simple things. 3. Terminology HyTime supports such a rich set of ways to link things to other things that the seemingly straightforward terms like "anchor", "link" become very difficult to tie down as we have seen in the recent discussion. 3.1 If a sub-set of HyTime functionality is decided upon does the terminology problem get any easier? 3.2 Users will never care how the pop-up list of hot-spots arrived onto there browser screen. They will never care that an anchor is not an anchor until it is referenced by a link. The will think an "anchor role" is a form of acrobatics performed by sailors:-) The people who need to be clear on the terminology are the implementors, the programmers, the techies out there that we want to reach with XML (me!). These guys understand the concept of a tree, the notion of an address and the notion of an indirect address. They understand associative arrays, dynamic binding, namespaces, pointers etc. Should we not be building on this existing terminology base rather than invent a new one? This, after all, is the terminology of the target market. If this was done could we maintain a link (sorry) to the "correct" HyTime terminology and include it in an appendix? Sean Mc Grath digitome@iol.ie Date: Tue, 31 Dec 1996 09:06:03 -0900 To: w3c-sgml-wg@www10.w3.org From: "W. Eliot Kimber" Subject: Re:Can we be more concrete... At 03:50 PM 12/31/96 +0000, Digitome Ltd. wrote: >etc. Should we not be building on this existing terminology base >rather than invent a new one? This, after all, is the terminology of >the target market. If this was done could we maintain a link (sorry) >to the "correct" HyTime terminology and include it in an appendix? As I said in an earlier post, even if the final XML design is HyTime conforming, it's not necessary to expose that in the base spec--thus there's no direct requirement to use HyTime terminology in the spec. It will be necessary to provide the mapping from XML terms to HyTime terms at some point, either as an appendix to the spec or as a separate TR. I say this because I recognize several realities that constrain the direct exposure of HyTime in the XML linking spec: 1. There is, for whatever reason, significant hostility to HyTime in general. Why invite trouble? HyTime, as a standard, is a somewhat different animal from SGML, in that HyTime is designed, in part, to be retrofitted to existing document types and applications: it defines semantics more than syntax, therefore, there's less urgency in building in HyTime from the start (although I still think that's a good thing--but then I would). 2. HyTime, is, by the nature of its scope and generality, complex and somewhat difficult to understand (although I hope we've improved on that with the TC). Because what XML needs is relatively simple compared to the totality of what HyTime (or any other industrial-strength hypertext scheme) can do, there's no reason to unduly burden the XML Link spec with complexities it doesn't need. One of the points of XML is to hide the complexities of the architectures from which it is derived until you're ready to move beyond XML. Note that we, as designers of the spec, will have to expose to ourselves some of these complexities so that we can come to clear agreement on the simplifications the final spec embodies. In other words, we have to know how the simplicity and constraints of XML Link relate to the more general features and concepts of the specs from which they're derived (whether that's HyTime, TEI, or whatever). It's a cliche', but a true one, that only experts can write good basic texts. Thus, in the process of applying our collective expertise (which is pretty vast) to the problem of creating a basic text for XML Link, we'll have to chew on many expert-level issues, in part to be sure of those we can avoid in the spec. 3. The terminology of hypermedia is, in general, murky, and HyTime doesn't necessarily help--many of the common terms are overloaded and not necessarily intuitive to the uniformed observer. Therefore, we should give greater weight to usability of the spec than to terminological conformance to one particular standard. As an aside, there's no point in trying to defend the terminology used in the HyTime standard: it's there and that's that, for good or ill. But I think it's important to remember that HyTime was developed over a period of years during which many of the important concepts and terms of hypertext were being developed, so that, at the beginning, there were not always clear precedents for the use of a particular term. In some cases, the choices were arbitrary, in others, they made sense within the HyTime system. In some cases they were chosen out of ignorance of alternatives. This is the way all standards are developed--it's unavoidable given human nature and human failings. 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, 31 Dec 1996 09:55:31 -0900 To: gtn@ebt.com (Gavin Nicol), dgd@cs.bu.edu From: "W. Eliot Kimber" Subject: Re: URLs/MIME only? Cc: w3c-sgml-wg@www10.w3.org At 10:21 PM 12/30/96 -0500, Gavin Nicol wrote: >> I suppose we could declare a format for "#" strings that encodes our >>location ladder. In fact, doing so would solve a serious user-interface >>problem for prospective browsers -- but I am not so sure that new magic URL >>hackery is really very nice. There is something in this proposal, I think, >>but it doesn't feel right to me yet. For instance > >I have proposed something like this many times. I think a real >question here is whether to do it as a fragment (ie. the document is >the primary object) or a pure URL (the element is the object). I tend >toward the latter. What I proposed was a simple format: > > /foo.sgm/4/2/99 - Child numbers > /foo.sgm/chap=1/sect=2/para=45 - Typed children This seems like a reasonable use of URLs. Given my limited understanding of URLs from reading the RFCs, specifying locations of objects is in the spirit of URLs, which are clearly defined as being "locations" and not names. It also explicitly says the locations are not necessarily filenames, even though they may coincidently have the same syntax as filenames in some systems--this suggests there's no reason a URL can't address inside a storage object. The only problem with this approach is the same one HyTime and DSSSL faced: what objects make up the nodes of the tree you're addressing. We currently have three different tree views of SGML documents in established specs: 1. DSSSL default grove plan: characters and elements are children of elements 2. HyTime default grove plan: pelements and elements are children of elements 3. TEI implicit grove plan: elements only are children of elements Nothing in the first URL shown above indicates which of these three tree views are to be used. You would either need a way to indicate the grove plan or require the use of a single grove plan, which would somewhat limit the utility of the scheme, but maybe not fatally. Another choice, of course, would be to use TEI locators as queries: /foo.sgm?DESCENDANT%20(1%20chap%202%20SECT%2045%20para) 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, 31 Dec 1996 12:13:43 -0500 From: gtn@ebt.com (Gavin Nicol) To: eliot@isogen.com CC: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org Subject: Re: URLs/MIME only? >The only problem with this approach is the same one HyTime and DSSSL faced: >what objects make up the nodes of the tree you're addressing. We currently >have three different tree views of SGML documents in established specs: > >1. DSSSL default grove plan: characters and elements are children of elements >2. HyTime default grove plan: pelements and elements are children of elements >3. TEI implicit grove plan: elements only are children of elements > >Nothing in the first URL shown above indicates which of these three tree >views are to be used. You would either need a way to indicate the grove >plan or require the use of a single grove plan, which would somewhat limit >the utility of the scheme, but maybe not fatally. In the very early versions of DynaWeb, I included support for these types of URL (and in fact, we also supported combinations of typed/untyped). I used (2) from the above list, and it seemed a reasonable choice. Date: Tue, 31 Dec 1996 12:14:58 -0500 From: gtn@ebt.com (Gavin Nicol) To: eliot@isogen.com CC: dgd@cs.bu.edu, w3c-sgml-wg@www10.w3.org Subject: Re: URLs/MIME only? >Another choice, of course, would be to use TEI locators as queries: > /foo.sgm?DESCENDANT%20(1%20chap%202%20SECT%2045%20para) 1) Not easy to type 2) Not easy to remember 3) Not intuitively applicable to OODB and RDB (though in fact, it could be used for them). Date: Tue, 31 Dec 1996 13:11:52 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: Suggestion: A link model At 2:43 PM 12/30/96, W. Eliot Kimber wrote: >It would certainly be possible for XML to use the agglink form and then >define an XML-specific way to associate anchor roles with members of the >aggregate, but that would be a hack--it would be better to fix the design >at its core (which has been David's point all along, of course). > >This will take some careful thought, but there might be a way to make it work. Great! >I should point out that I think the new hylink syntax, where each role has >its own addressing attribute is much easier to use and explain than the old >ilink syntax, where you had to explain (and validate) the positional >correspondence between anchor roles and anchor addresses (complicated by >the fact that indirect addressing could obscure what was being >addressed--you didn't just count IDs in the linkends attribute value). The >feature David wants would require the ilink-style addressing syntax with a >single attribute for all the link ends--a syntax that in my experience of >teaching HyTime is a difficult one for people to use. I agree that it is a much more fortunate and natural syntax for fixed anchor roles. >Let me also ask this: do we agree that when we *don't care* about anchor >roles, that an aggegate link is sufficient? Sure, in fact, I think we could easily make agglink work for both cases: Add back and anchrole attribute to agglink, and require that it contain at least one role. Add a rule stating that if the agglink has more anchors than anchor roles, then the last role applies to all the anchors whose locations are expressed last. You can think of this as an "anchor model" where the last anchor role has an implicit * on it. Of course it would be nice if there were a way to to integrate this with the clink/ilink distinction. One way would be to say the any content of an agglink is an anchor like a clink's but if the content model is EMPTY, then it functions link an ilink. I don't know if this kind of case-switching is part of the HyTime meta-language, but it's not too complicated. -- 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, 31 Dec 1996 13:12:30 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: More proposals -- and some critical implementation issues At 6:15 AM 12/31/96, Martin Bryan wrote: >At 13:31 30/12/96 -0500, David G. Durand wrote: > >>Punting was really a joke, referring to the fact that we are letting the >>DTD slide in a case where it seems to be required. Of course its the >>natural way to solve the problem, I suggested it, didn't I? > >I thought that it was sufficient to say that if you transmitted the DTD and >expect the browser to parse that then you could define a fixed XML attribute >in the DTD but if you did not transmit the DTD (because the browser could >not process it) then you had to add the XML attribute to all instances of >elements that are to exhibit linkedness. Since we have gone to great lengths to enable an Explorer or Navigator-equivalent to avoid processing DTDs, we can't afford to require them for linking behavior to work. This is only my opinion, but it's sure a hard case to make as part of a sales pitch. Same for the attribute values -- the redundancy will be noticable, and make XML look foolish, when it is in fact merely being punctilious. >The idea of leaving it to the style >sheet to say "this is a link" appals me as I cannot manage my links properly >this way. (I could live with the link definition being defined as an SGML >link attribute, but I suspect that would bring a ton of brickbats on my head!) I was not suggesting stylesheets as the primary linking strategy, but as a way for authors to deal with the practical facts of life. _I_ might be willing to live with the attribute values, but I doubt most users would... I think that we could even (if technically feasible) try to define things so that link-style processing could not be invoked by markup if the archform were not present _if a DTD were parsed_. The problem is that we then need two processing semantics for identical markup: and that also seems very problematic to me. I agree that having only code as the definition of links is a horrible fate: you can't even gurantee whether or not something is a link, in that case. As I mentioned to Gavin, Hypercard is the horrible example of a system that made this mistake. -- 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, 31 Dec 1996 13:13:10 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict) I've been reading Steve and Martin's notes, and I may have some idea of the disconnect going on: A HyTime BOS is determined by a "hub document" and references recursively followed out from that document, to a fixed depth. Martin (and I) are assuming that whenever a document is displayed, it should be regarded as the "hub document". In that case the BOS is the entire web (if no limit is in effect) or, at least, a pretty indisciminate lot of documents, depending on how what kinds of links we have. We have to actually fetch all of these documents, because otherwise we might miss significant ilinks. But, without fetching them and parsing them, we can't tell which of the outgoing references are really needed (because they contain ilinks) and which are just referred to. Now, at least in the pre-TC world, HyTime's hub document is an application-determined role and not an explicitly marked construct (though the TC seems to have introduced a way to suggest hubs?). So a browser _could_ work this way. And given the way the web currently works, this is not an _un_-resonable way for things to work, though it is not the only way they could worl. Steve is assuming that I can tell that only _some_ documents are "real" hub documents, so that I can tell, when I follow a link, if I have left the region governed by one hub, and entered the region governed by another hub. At this point my application could merge the document sets defined by the hubs, save them in a history, or anything else it wants to. My contention is that the notion of (even restricted) recursive document requirement could be harmful. I think we all agree that for ilinks to be useful, we need a way to pull in documents known to contain ilinks. And we all agree that there should be a way for a user to explicitly add a set of ilinks to their working document set. I have never been persuaded that the notion of a single starting point document is essential, though it's certainly useful in some cases. And I think that requring automatic following of all links (even to one level) is impractical. So I suggest: 1. We have identified a clear requirement for XML documents to be able to idnetify other documents that need to be processed along with them (mostly for ilink resolution). 2. The term BOS is not that useful in describing browser behavior, as it is unfamiliar outside of HyTime, and the HyTime notion can be applied to the web in at least two distinct ways. I suggest that we use a new term "working document set" to mean a set of documents that need to be processed together, and within which ilinks in all the documents are supposed to be accessible. Applications may mess with the working document set, under arbitrary user control; but an author can augment the browser's working set for a particalar document by declaring "companion documents", which will be added to the working document set when that particular document is processed. 3. The notion of explicit "hub documents" is foreign to the web, and easy to synthesize from the "companion document" mechanism, so we might as well leave it be. Note: To get the effect of a well-known hub document, we declare that hub as the companion for all of its desired members -- and in the hub itself, we declare all the desired members as _its_ companions. _Viola_ wherever we start, we automatically pull in whatever documents the "hub" indicates as essential. -- 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, 31 Dec 1996 13:13:22 -0500 To: digitome@iol.ie (Digitome Ltd.), w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re:Can we be more concrete... At 10:50 AM 12/31/96, Digitome Ltd. wrote: >1. The simple things should be simple > >It will cut no ice with the software development community if XML >Hypertext allows links from arbitrary tachyons to a range of faces on >a hypercube *IF* this is at the expense of making "link this word to >that file" an intellectual safari. I definitely agree. I think nothing that has been proposed will actually make things complex. The problem is that we have to rationalize all of the (slightly) divergent models of the participants -- and that is more complex than the actual proposals. >There are many exceptional hypertext exponents on this list who know >from experience what sorts of Hypertext functionality is sorely >missing from the Web. The sort of things that will make the eyes of >current Web masters glaze over. What are these things? Is there an >80/20 rule applicable to Hypertext? 20% of hypertext concepts used >80% of the time? So far we really have agreed on the 80% (I think): clinks. (ordinary links), stored at one endpoint pointing somewhere else. ilinks. Links separately stored from both endpoints Multi-way links (an extension of both sorts of link) for annotation and knwoledge representation. Logical document part addressing. Now that we have structured XML documents, we want to be able to use that structure as an addressing mechanism. >Should we not start by saying "here are the things >that we *know* people are crying out for. Here are the things that >will capture the imagination of Web implentors and users alike. Here >are the things that will sell Web masters on XML". Can we isolate >these things and concentrate on making them "no-brainers" to implement? I hope these things meet those criteria. To make that clear, we will have to show examples of how to solve problems with the new constructs, but I am sure that that is easy and will happen. >2. Hypertext as an XML application? > >Is Hypertext an application of XML or a raison d'etre of XML? I feel >it is an application - one of myriads that can be envisaged. I think >hypertext semantics/functionality should be *outside* the XML >documents themselves for this reason. I am concerned about >the architectural form approach because:- It's a _critical application_ I think, because of the (erroneous) identification of HTML and Hypertext in the minds of the world at large. > >. Architectural Forms is an intellectual safari >. Anything that can be expressed in an architectural form > can also be described as an XML document. (I think!) In practice they are very simple -- it's jsut a way to base processing on attribute values. The explanations to date have concentrated on explaining how to use architectural forms to describe markup. But in the XML linking spec, we will only have to describe how to set attributes to make links -- the application of a fixed set of AFs to an arbitrary document. This should be a lot easier to explain than the general case. AFs are becoming a very productive method of DTD standardization, and we might as well use them. >3. Terminology >HyTime supports such a rich set of ways to link things to other >things that the seemingly straightforward terms like "anchor", >"link" become very difficult to tie down as we have seen in the >recent discussion. I think we are moving to curb the eventual concept space to a small number of easily definable items. I think we can avoid use of Hytime terminology except where it is the best choice, and must define our terms clearly and independently of HyTime in any case. >3.1 >If a sub-set of HyTime functionality is decided upon does >the terminology problem get any easier? I think we are converging on that subset, and will be able to settle on a subset of (possibly simplified) HyTime terms for XML linking. >3.2 >Users will never care how the pop-up list of hot-spots arrived onto >there browser screen. but XML authors will, and implementers will >They will never care that an anchor is not an >anchor until it is referenced by a link. I have been using Tim's revised terminology, where an anchor is an element introduced solely to be referenced. We should only care enough that we have the words we need to write the definition. > The will think an "anchor >role" is a form of acrobatics performed by sailors:-) Well, we could change the term to "jelly roll" for a tastier standard. >The people who need to be clear on the terminology are the >implementors, the programmers, the techies out there that we want to >reach with XML (me!). yes, I hope we introduce no more than we need to satisfy this need. >These guys understand the concept of a tree, >the notion of an address and the notion of an indirect address. That's why I prefer the terms "parse tree" or "abstract syntax tree" to "grove", "grove plan" and their friends. Maybe we should be calling "locations", "addresses", and "queries", "pointers". In practice, I think we will be OK as long as we don't have the terms "locator", "location", "location address", "external location address pointer", etc. all floating around with slightly different meanings. > If this was done could we maintain a link (sorry) >to the "correct" HyTime terminology and include it in an appendix? Or even a separate document, for those who need 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: Tue, 31 Dec 1996 13:12:26 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: More proposals -- and some critical implementation issues At 11:55 PM 12/30/96, Gavin Nicol wrote: >David writes: >>So, given that, I propose for discussion: >> >>XML linking architecture is indicated by an attribute: >> >>-XML-ARCH-LINK >> >>We have AFs something like this: >> >> > >Playing the devil's advocate.... Ok, (beelze)-bub! > >Assuming that link behaviour *will* be put out into stylesheets, we must >ask if we need any fixed forms at all (ie. the sylesheet can decide >what comprises a link, and what does not, and what the structure of >a link definition needs to be in order to be semantically interpretable). > >I would say that for interoperability would be the main benefit. Experience with solely executable link specifications (Hypercard is the canonical horrible example) has shown that it makes analysis somewhere between difficult (got to read code to find out what it does), to impossible (this is a turing-complete problem, and thus uncomputable, in general). So I think we need declarations so we don't have to write analysis programs to determine whether code such as: If (subroutine to determine that Goldbach's conjecture is true) then goto document X else ignore click. is a link, or not! If we hve such computation links they should be a special case, rather than the only case, so that common links are easily processable. -- 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, 31 Dec 1996 13:12:02 -0500 To: w3c-sgml-wg@www10.w3.org From: dgd@cs.bu.edu (David G. Durand) Subject: Re: URLs/MIME only? At 10:21 PM 12/30/96, Gavin Nicol wrote: >> I suppose we could declare a format for "#" strings that encodes our >>location ladder. In fact, doing so would solve a serious user-interface >>problem for prospective browsers -- but I am not so sure that new magic URL >>hackery is really very nice. There is something in this proposal, I think, >>but it doesn't feel right to me yet. For instance > >I have proposed something like this many times. I think a real >question here is whether to do it as a fragment (ie. the document is >the primary object) or a pure URL (the element is the object). I tend >toward the latter. What I proposed was a simple format: > > /foo.sgm/4/2/99 - Child numbers > /foo.sgm/chap=1/sect=2/para=45 - Typed children > >This is easy to read, understand, and is useful for things like >addresses in OODB, and RDB as well. I think there is a significant advantage for using the # string. (I never thought I'd say that!) The location mechanisms we are referring to (element addressing, etc) are essentailly XML specific (but necessary, despite all that). So it makes sense that the XML browser should be responsible for locating the sub part of a document. The WWW has taken several positions that affect this: 1. A URL is the finest granularity of object that HTTP and browsers are required to deal with. 2. That any kind of semantics in a url that is client interpretable shall only be related to protocol negotiation. 3. All other semantics in a URL are server-only. These positions are slightly modified by # strings: 4. A client gets an opaque address inside a # string that can be interpreted to find a sub-part of the addressed resource, possibly based on the MIME type of the resource. This severely handicaps our position with respect to adding locators to URLs. I have never seen these position articulated in exactly these words, but the intent is very clear from conversations I have had with Dan Connolly, Hernik Frystyk, and other W3C notables. I don't necessarily agree that this is a necessary set of restrictions, but I think we can live within them. >>I still wish we were using HTTP headers instead of Processing Instructions >>(the one SGML feature I have never even contemplated using). > >Amen to that! > >I was talking to someone who is planning to implement XML the other >daya, and there is already misunderstanding about what that PI should >do (ie. can it occur in places beyond the header, and if so, what does >it do?). I think it can occur anywhere and do anything, right? >Headers are headers.... I guess my real avenue for promoting the *.mim >format is to write a *.mim storage object handler for SP.... Maybe writing the handler would have a salutary effect! The rest of you can tune out if you wish, just a little chit-chat among the members of the choir. -- 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, 31 Dec 1996 09:56:52 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org Terry Allen on Mon, 30 Dec 1996 11:47:37 -0800 (PST)) Subject: Re: BOS clarification? > I'm having trouble matching up what Eliot and Steve are saying about BOS > with what I know from the 1992 version of 10744, section 6.2.4.2. In part: > > A bounded object set can be determined authomatically by the HT engine > by constructing an "entity tree", starting with the SGML doc entity of > the hub doc as the root. The entity tree includes external entities > declared in the hub doc, then external entities declared in those > entities, and so on. ... A limit can be placed on the depth of the > entity tree by the "bounding level" att of the hub document. ... > > The bounding level att works only when my work happens to end at > the same level throughout, so appears not to be a solution. Yeah, this didn't work. The HyTime Technical Corrigendum does it differently. In the TC, there is a common data attribute that optionally appears on each entity declaration which separately declares for that entity how deeply to recurse. There are a couple of other features, too. > Does this not mean that every external entity declared in the hub doc > (and every external entity in those entities) is part of the BOS? And > might it not be the case that I declare as entities in my hub doc > certain public text (part of the US Constitution, for example) that > are not part of my copyrighted intellectual property? (I might > declare them for the use of links that refer or traverse to them, > rather than for transclusion.) > > So isn't BOS applicable to the problem of defining the extent > of my intellectual property/literary work only if I can contrive > not to declare as external entities anything that doesn't belong > to the work? No. I'm embarrassed that I was so unclear. I was not proposing that the BOS represents a set of intellectual property. I was proposing that an ilink (now "hylink" in HyTime) be used to express the fact that document A contains the intellectual property notices that govern documents B, C, and D. The hylink can be in document A, B, C, D, or E. Whatever document the hylink is in must be guaranteed to be in the BOS, or the application won't know about it and therefore can't display the legal notices. (That's where the BOS notion comes in.) I was also saying that any document which contains a link that is used to traverse to another document is itself guaranteed to be in the BOS, unless the user takes special pains to delete it from the BOS after arriving. So, BOS discipline can be relied upon to guarantee that legal notices (and, needless to say, any other annotations) can be made available from within read-only documents which themselves contain no evidence that such notices/annotations exist. There are additional details, but that's the fundamental idea. Best regards, --Steve Steven R. Newcomb President voice +1 716 271 0796 TechnoTeacher, Inc. fax +1 716 271 0129 (courier: 23-2 Clover Park, Internet: srn@techno.com Rochester NY 14618) FTP: ftp.techno.com P.O. Box 23795 WWW: http://www.techno.com Rochester, NY 14692-3795 USA Date: Tue, 31 Dec 1996 15:14:44 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org Martin Bryan on Tue, 31 Dec 1996 11:19:08 +0000) Subject: Re: unmarked linkend awareness by XML engines > >When you use the BOS concept, the only thing that matters is the > >user's decisions as to which documents (and therefore, which link > >sets) are known to the application. As I said before, upon arrival at > >any document, the user has the option of adding that document's BOS to > >the actual BOS in effect for this session, or of replacing the active > >BOS with that document's BOS (which means that the application will > >"forget" about the links that exist in documents that are not present > >in the new BOS). At any time, the user can create and/or use *any* > >BOS. If the user fails to use any suggested BOS, the user does so at > >his own risk. > > How can the user (who have no overall view of the data they are using) > assess such a risk? Users are going to make these decisions on whatever basis they make them. Let me make this question a little more concrete. "Do I want to wait while this whole goddam recommended BOS is assembled, or do I just want to see what's at the other end of this hyperlink, and to hell with whatever may be linked to it by other things in the recommended BOS?" This is just like asking how a user can assess whether to spend some unknown portion of his irreplaceable lifetime traversing a hyperlink on the World Wide Wait. Sometimes it's worth it. Sometimes it's not. Usually such decisions are based on extremely practical considerations, like the fact that a perfectly good hot meal is getting cold. > The scenarios you provided were great. The only problem I have is if I > publish my annotations is monthly part, and my users subscribe to my > annotations and choose one of these parts to start from. How can I arrange > for them to see all of the annotations from all of the monthly commentaries > unless I share an updatable BOS between them. If the BOS is separated from > the annotations I have no problems. If it has to be part of the annotations > I am in difficulty. So declare the BOS in a separate document that serves as the hub. Sounds like that solves the problem, to me. --Steve Steven R. Newcomb President voice +1 716 271 0796 TechnoTeacher, Inc. fax +1 716 271 0129 (courier: 23-2 Clover Park, Internet: srn@techno.com Rochester NY 14618) FTP: ftp.techno.com P.O. Box 23795 WWW: http://www.techno.com Rochester, NY 14692-3795 USA Date: Wed, 01 Jan 1997 11:09:46 +0000 To: dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict) At 13:13 31/12/96 -0500, David G. Durand wrote: > So I suggest: > > 1. We have identified a clear requirement for XML documents to be able >to idnetify other documents that need to be processed along with them >(mostly for ilink resolution). The essential requirement > > 2. The term BOS is not that useful in describing browser behavior, as it >is unfamiliar outside of HyTime, and the HyTime notion can be applied to >the web in at least two distinct ways. I suggest that we use a new term >"working document set" to mean a set of documents that need to be processed >together, and within which ilinks in all the documents are supposed to be >accessible. Applications may mess with the working document set, under >arbitrary user control; but an author can augment the browser's working set >for a particalar document by declaring "companion documents", which will be >added to the working document set when that particular document is >processed. Nice term - could be usefully abbreviated to WORKDOCS. Authors could add COMDOCS, better still, USEFULDOCS (i.e. "useful companion documents") > > 3. The notion of explicit "hub documents" is foreign to the web, and >easy to synthesize from the "companion document" mechanism, so we might as >well leave it be. If you mean "drop it" I concur. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Wed, 01 Jan 1997 11:09:44 +0000 To: dgd@cs.bu.edu (David G. Durand), w3c-sgml-wg@www10.w3.org From: Martin Bryan Subject: Re: More proposals -- and some critical implementation issues At 13:12 31/12/96 -0500, David G. Durand wrote: >At 6:15 AM 12/31/96, Martin Bryan wrote: >>I thought that it was sufficient to say that if you transmitted the DTD and >>expect the browser to parse that then you could define a fixed XML attribute >>in the DTD but if you did not transmit the DTD (because the browser could >>not process it) then you had to add the XML attribute to all instances of >>elements that are to exhibit linkedness. > >Since we have gone to great lengths to enable an Explorer or >Navigator-equivalent to avoid processing DTDs, we can't afford to require >them for linking behavior to work. This is only my opinion, but it's sure a >hard case to make as part of a sales pitch. Same for the attribute values >-- the redundancy will be noticable, and make XML look foolish, when it is >in fact merely being punctilious. > Why will the redundancy be noticeable? How many users look at the code coming into their Netscape browser? The redundancy will only be present when the file is being transmitted to a dumb browser that cannot handle the DTD. If it can handle the DTD there will be no redundancy as the attributes won't need to be added before transmission. Browsers would only need to be able to identify a few extra attributes, those identifying XML link AFs. They will need to be able to recognize these in any case to process XML links. Nobody is suggesting, surely, that Netscape and Explorer should be able to handle multi-headed XML links without modification. If we are constrained by what these browsers can do at present then we might as well give up now. ---- Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK Phone/Fax: +44 1452 714029 WWW home page: http://www.u-net.com/~sgml/ Date: Wed, 1 Jan 1997 17:40:43 -0500 From: "Steven R. Newcomb" To: w3c-sgml-wg@www10.w3.org Subject: [dgd@cs.bu.edu: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)] ------- Start of forwarded message ------- > I've been reading Steve and Martin's notes, and I may have some idea of > the disconnect going on: Thanks for your help, David. I've been pretty boggled by that discussion, and I'd like to apologize to Martin for any offense. ... > Steve is assuming that I can tell that only _some_ documents are "real" > hub documents, so that I can tell, when I follow a link, if I have left the > region governed by one hub, and entered the region governed by another hub. > At this point my application could merge the document sets defined by the > hubs, save them in a history, or anything else it wants to. You're correct. I was assuming that a hub document (er, session-start document) would tell you that it needs the rest of its BOS (er, working document set) to be complete and work right. Then a user could say whether he was willing to incur the overhead and delay of assembling that BOS (er, working document set). > My contention is that the notion of (even restricted) recursive document > requirement could be harmful. How so, if it's restricted? > I think we all agree that for ilinks to be > useful, we need a way to pull in documents known to contain ilinks. And we > all agree that there should be a way for a user to explicitly add a set of > ilinks to their working document set. I have never been persuaded that the > notion of a single starting point document is essential, though it's > certainly useful in some cases. And I think that requring automatic > following of all links (even to one level) is impractical. No argument. Suggesting it is one thing; requiring it is another. > So I suggest: > > 1. We have identified a clear requirement for XML documents to be able > to idnetify other documents that need to be processed along with them > (mostly for ilink resolution). > > 2. The term BOS is not that useful in describing browser behavior, as it > is unfamiliar outside of HyTime, and the HyTime notion can be applied to > the web in at least two distinct ways. I suggest that we use a new term > "working document set" to mean a set of documents that need to be processed > together, and within which ilinks in all the documents are supposed to be > accessible. Applications may mess with the working document set, under > arbitrary user control; but an author can augment the browser's working set > for a particalar document by declaring "companion documents", which will be > added to the working document set when that particular document is > processed. I don't see why it's helpful to invent yet another "de novo" term, "working document set", when we have an internationally standard HyTime term "bounded object set", that means exactly the same thing, except that it includes the notion of bounded recursion -- something I believe we're going to deeply regret not having, in any case, if we can't do it in XML. (In fact, isn't it already there, by virtue of the fact that external entities can declare external entities recursively, essentially *without* bounds?) On the other hand, "working document set" is pre-overloaded and likely to cause confusion in just those situations where you really need a no-nonsense technical term, like "bounded object set" for a very specific technical concept. There's something to be said for a term that advertises the fact that you must sit down and learn exactly what it means in order to use it. Anyway, there is no winning the terminology war. The more we try to be precise, or, on the other hand, intuitively understandable, the more people we offend by making them feel either ignorant (if they don't already know the field), or ignored (if they do), or confused (either way). One of the things the XML group must face is the fact that the "on-ramp to SGML" (as I recall Tim putting it) is necessarily going to have some upward slope. We're all in favor of having a smoothly upward slope, and as little slope as possible. Maybe it's best to use the term "working document set", because it's easier then for folks to get on the on-ramp, but I don't think so -- I think it's just confusion waiting to happen. But I have another concern. If at the end of the ramp there's a huge step up to HyTime, or if the ramp doesn't even take you anywhere near HyTime, we have blown a unique opportunity to interconnect the world's knowledge bases. The XML on-ramp to SGML is pretty much already designed. Since we're now considering hyperlinks, I hope what we're working on, among other things, is an on-ramp to HyTime. Am I wrong to hope for this? Is there any design, conceptual, or terminological question the XML group faces that is so moot that it will be decided on the basis of consistency with HyTime? If so, which way will it be decided? Basically, though, I agree with what David says. I think there are three distinct flavors of "working document set" (just as there are three distinct flavors of "bounded object set (BOS)"): (1) the set that was intended by the author ("HyTime BOS" in HyTime), (2) the set that an application, with or without the complicity of its user, tries to assemble ("application BOS" in HyTime), and (3) the set that an application actually winds up using (I'm proposing the term "effective BOS" for this one). > 3. The notion of explicit "hub documents" is foreign to the web, and > easy to synthesize from the "companion document" mechanism, so we might as > well leave it be. There's no explicit "hub document" in HyTime, either; it's just the document you nominally started with when assembling a hyperdocument >from a bounded object set. I don't yet see the conceptual difference between HyTime's hub document concept and the idea of having a document declare its companion documents. And I don't see the difference between allowing the use of a pruned entity tree rooted in the hub document's SGML document entity to determine the bounded object set (er, working document set), versus providing a list of all the "companion" documents that would have resulted from traversing that same tree, except: * It's more trouble to specify the explicit companion list, instead of just the entities that declare the companions in their own entity declarations; and * I have much more maintenance difficulty because changes in any of the physical addresses of any of the companion documents must be reflected in the hub document's entity declarations. I can't delegate that maintenance to the maintainer of a companion document. > Note: To get the effect of a well-known hub document, we declare that > hub as the companion for all of its desired members -- and in the hub > itself, we declare all the desired members as _its_ companions. _Viola_ > wherever we start, we automatically pull in whatever documents the "hub" > indicates as essential. But doesn't this mean you must have all this already-redundant information kept in synchronized copies all over the place? Sounds like a dreadful and unnecessary hyperdocument maintenance headache. Ouch! Also, doesn't this mean that an author can't specify companion documents that he can't write on? Sounds impractical. Happy New Year (1997 has *got* to be better than 1996)! --Steve Steven R. Newcomb President voice +1 716 271 0796 TechnoTeacher, Inc. fax +1 716 271 0129 (courier: 23-2 Clover Park, Internet: srn@techno.com Rochester NY 14618) FTP: ftp.techno.com P.O. Box 23795 WWW: http://www.techno.com Rochester, NY 14692-3795 USA